Version numbers are good for identifiers that may change and bad for ones that
shouldn't change.
I agree there may be multiple terms from different vocabularies to represent
each concept.
However, what we want to avoid is multiple terms from a single vocabulary for
the same concept.
E.g., if the WGS84 latitude/longitude coordinate system is known as EPSG 4326:7.6, 4326:7.5.9, 4326:7.5.1, 4326:6.15, EPSG
4326:6.3, etc, and every one of them mean exactly the same thing, and there are similar but invalid values such as 4326:6.16,
then applications have a big problem keeping up with all the possible values. For that reason, the valid values do not include
the version number of the EPSG database, and if a CRS definition requires major revision then it is assigned a new number and
the old one is deprecated.
When identifiers do change, such as for a dataset that has been modified after quality control, or for a WMO number that has
been reassigned to a different hull, then version numbers are useful.
Regards,
Jeff DLB
On 2010-12-18 01:40, John Graybeal wrote:
While I appreciate the argument that having a single unique string to represent
each concept in earth science would be ideal, I can promise that no matter what
we do with versioning of terms, in 10 years there will be a plethora of URIs
representing any given concept (more or less). Hate to say that, but it is
inevitable. So in the end, managing the clutter of 'excess' terms will have to
be done with user interfaces to hide them, and good semantic tools to map them
all together. (Admittedly, neither anywhere near commonly available yet. But
it will happen in the fullness of time.)
The proliferation/versioning topic was one we thought hard about in MMI, and
there are some writeups on the site that may be of interest to a few. [1] It
includes a bit more detail than we have pursued here.
In case anyone cares: Knowing which vocabulary version a term came from can
reveal more than you might realize. While we probably didn't say this
explicitly anywhere, the thought in my head for versioning every term when the
file changed will seem like an angels on a pin argument to all you practical
data folks. It goes as follows: if additional terms are added that are more
detailed than the original term (say, sea_surface_skin_temperature and
sea_surface_foundation_temperature added to the original term
sea_surface_temperature), I would expect people to use the more specific term
when possible. (Similarly, 'gay' still means happy, but you don't hear people
use it that way.) Thus, even though the definition of a term hasn't changed,
its application and implicit meaning can change. Historians have to account for
this when reading and understanding older material, and historical data
analysts the same.
John
[1]
http://marinemetadata.org/apguides/ontprovidersguide/ontguideconstructinguris
(see the Versioned and Unversioned URLs section toward the bottom)
On Dec 17, 2010, at 08:37, Lowry, Roy K. wrote:
Hi Richard,
This echoes a discussion in BODC this afternoon and a thought I had some while
ago in that having terms inherit the version number of the list in which they
reside was not the best of ideas. However, we concluded that maintenance of
list versions was a good idea, particularly if the list governance permits
deprecation.
I'm not aware of anybody maintaining version numbers at the term level for the
Standard Names. Establishing them retrospectively wouldn't be a pleasant task
and I don't think there's anything to be gained from their introduction from
this point onwards.
Cheers, Roy.
-----Original Message-----
From: cf-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Hattersley, Richard
Sent: 17 December 2010 16:13
To: John Graybeal; Jeff deLaBeaujardiere
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Web reference to a standard name?
It would seem that the two conflicting requirements, which I'll
caricature as "rigorous version control" and "pragmatic usability",
could go some way to being reconciled by using term-specific version
numbers.
Instead of:
<some_prefix>/<cf_vocab_number>/<term> (e.g.
.../P071/16/CFSN0023)
Or:
<some_prefix>/<term> (e.g. .../parameter/air_temperature)
You have:
<some_prefix>/<term>/<term_version>
Where the term_version is only updated when the definition of the term
changes - not when a release of the standard name table occurs. Thus
avoiding the proliferation of identifiers.
This would still leave a discussion on what constitutes a "change", as
it's quite possible one may wish to allow minor edits (eg. spelling
corrections) for pragmatic reasons.
Richard Hattersley AVD Expert Software Developer
Met Office FitzRoy Road Exeter Devon EX1 3PB United Kingdom
Tel: +44 (0)1392 885702 Fax: +44 (0)1392 885681
Email: richard.hatters...@metoffice.gov.uk Website:
www.metoffice.gov.uk
-----Original Message-----
From: cf-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Graybeal
Sent: 17 December 2010 00:16
To: Jeff deLaBeaujardiere
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Web reference to a standard name?
I offer my two cents on versioned terms, prompted by the 'absolutely
right' phrasing :->. I am firmly straddling the fence on this question.
There are multiple science users and many technical opinions that say
not having versions is absolutely wrong. The circumstances that could
make 'current' *not* what you want include:
- you need to understand what definition (or other statements) was in
effect when the tag was applied
- you want to understand the transitions that the definition (or other
statements) has undergone over time
- the meaning of a term actually is significantly different than it used
to be
- additional meanings are associated with a term (e.g., an acronym is
repurposed by another organization) at a later date
I believe the last happens much more often than your confidence suggest
-- perhaps especially in emerging fields or those that are newly
developing documented vocabularies, extremely advanced or subjective
fields, and concepts that get 'culturally adopted', e.g., turned into a
pejorative (slang (that last not our problem, for the most part). I
don't see how the exclusive use of non-versioned terms supports these
situations.
So while I appreciate the motivations for not including versions, I
think versions have to be offered by the system, and ideally should be
used where unique persistent identifiers are required.
John
On Dec 16, 2010, at 13:08, Jeff deLaBeaujardiere wrote:
Actually, my recollection is that EPSG& OGC proposed to include
version numbers, and several of us argued against it and managed to
convince them. I would have to dig up old emails to find out for
certain who was in which camp, however.
Regards,
Jeff DLB
On 2010-12-16 15:57, Lowry, Roy K. wrote:
Hi Jeff,
It's interesting to see the difference of opinion between the
standards developers (the idea of version number in URI came from the
OGC URN specification: interesting how EPSG came to a different
conclusion) and those who have to live with the consequences. The more I
think about it, the more I think you and Benno are absolutely right.
Cheers, Roy.
________________________________________
From: cf-metadata-boun...@cgd.ucar.edu
[cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jeff deLaBeaujardiere
[jeff.delabeaujardi...@noaa.gov]
Sent: 16 December 2010 19:40
To: John Graybeal
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Web reference to a standard name?
On 2010-12-14 12:56, John Graybeal wrote:
Just to be crystal clear, the places where you have '16' could also
have 'current' (if I understand correctly what Roy was saying about
their server), and the mmisw one could also be served with a particular
version ID (analogous to the NERC example).
I think it is of the utmost importance to have a URI that does not
include a version number and always provides the latest answer.
Otherwise you have a proliferation of identifiers mean the same thing
but appear to change every time the overall vocabulary is updated.
You can also have a version-specific entry if desired.
There were similar discussions regarding identifiers for coordinate
reference system identifiers from EPSG (European Petroleum Survey
Group), and it was fortunately recognized that a version-less URI was
essential.
-Jeff
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata--
This message (and any attachments) is for the recipient only NERC is
subject to the Freedom of Information Act 2000 and the contents of
this email and any reply you make may be disclosed by NERC unless it
is exempt from release under the Act. Any material supplied to NERC
may be stored in an electronic records management system.
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
John Graybeal<mailto:jgrayb...@ucsd.edu>
phone: 858-534-2162
System Development Manager
Ocean Observatories Initiative Cyberinfrastructure Project:
http://ci.oceanobservatories.org
Marine Metadata Interoperability Project: http://marinemetadata.org
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
This message (and any attachments) is for the recipient only NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
John Graybeal<mailto:jgrayb...@ucsd.edu>
phone: 858-534-2162
System Development Manager
Ocean Observatories Initiative Cyberinfrastructure Project:
http://ci.oceanobservatories.org
Marine Metadata Interoperability Project: http://marinemetadata.org
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
