Re: [CF-metadata] Web reference to a standard name?
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: // (e.g. .../P071/16/CFSN0023) Or: / (e.g. .../parameter/air_temperature) You have: // 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
Re: [CF-metadata] CF name for predicted water level?
On 2010-12-17 16:57, Christopher Barker wrote: > I think the OP's question really is: > > should one use a different standard name for a predicted, rather than a measured, quantity? > I think the answer is no, as I've seen all sorts of model output without anything in the standard name indication anything about it being a forecast -- I think that information should be provided by the file-wide meta-data, i.e. your users should know what the general content of the file are. I think that in the case of the NOAA/CO-OPS data, the distinction is more subtle than observed vs predicted. The prediction is explicitly based only on certain effects (especially tides) and does not account for storm surge and other phenomena. Secondly, in our case both datasets are associated with individual water-level stations and are offered by the same SOS (Sensor Observation Service, an Open Geospatial Consortium specification), so we need separate names to distinguish these two in the list of datasets offered for that station. Apparently the suggested name sea_surface_height_amplitude_due_to_equilibrium_ocean_tide was satisfactory. Regards, Jeff DLB -- Jeff de La Beaujardière, PhD U.S. National Oceanic and Atmospheric Administration (NOAA) Sr Systems Architect, Integrated Ocean Observing System (IOOS) Program Office 1100 Wayne Ave #1225, Silver Spring MD 20910 USA +1 301 427 2427 jeff.delabeaujardi...@noaa.gov ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] bounds not allowed for scalar coordinate variables
Hi Karl, The discussion concerning the introduction of the scalar coordinate variable is available in the archive (July 2003 under the subject "size-one axes"). There was never a decision to disallow the "bounds" attribute. Although it could be more explicitly stated in the current document, I think several sections support the use of "bounds" with scalar coordinate variable. In addition to the statement Jonathan points out in section 5.7 I find: The definition of a scalar coordinate variable is (section 1.2): A scalar variable that contains coordinate data. Functionally equivalent to either a size one coordinate variable or a size one auxiliary coordinate variable. The first paragraph of section 7.1 contains A boundary variable will have one more dimension than its associated coordinate or auxiliary coordinate variable. Scalar coordinate variables are auxiliary coordinate variables, and if the "bounds" attribute were not allowed then they could not be functionally equivalent to size one auxiliary coordinate variables. The statement you called out occurs in section 2.4 on dimensions and was written long before we adopted the scalar coordinate variable. I assume that rewording that statement to be more precise just fell through the cracks. But on that point I don't agree with Jonathan's assertion: > I believe that by "coordinate variable" it means either > a size-one (Unidata) coord var or a scalar coord var. In very early drafts we tried using "coordinate variable" in a more general sense than its definition in the NetCDF User's Guide (NUG). But distinquishing between coordinate variables in the strict NUG sense, and in the general sense became very awkward. We therefore resolved to use the term "coordinate variable" only in the NUG sense. I think the document is very consistent about this, which is why the statement that you point out is confusing and should be modified to explicitly mention scalar coordinate variables. Brian On Thu, Dec 16, 2010 at 02:52:07PM +, Jonathan Gregory wrote: > Dear Karl > > > Does anyone remember, why we didn't allow the "bounds" attribute to be > > attached to a scalar coordinate variable? Currently CF requires the > > user to include a dimension a size one if he wants to define coordinate > > bounds: > > > > "The advantage of using a coordinate variable is that all its attributes > > can be used to describe the single-valued quantity, including boundaries." > > I don't think the text means that a scalar coord var can't have bounds. In > the sentence you quote, it is not contrasting a (Unidata) coord var with a > scalar coord var. I believe that by "coordinate variable" it means either > a size-one (Unidata) coord var or a scalar coord var. It is contrasting the > use of coordinate vars of either type with attributes, as means of attaching > single values, I guess. Indeed, in 5.7, it says "Scalar coordinate variables > have the same information content and can be used in the same contexts as a > size one coordinate variable." > > I often attach bounds to scalar coord vars and I don't believe the conformance > requirements exclude that. > > > [Note that we also, don't allow an "axis" attribute to be attached to a > > scalar coordinate variable, and I also don't remember why we did this.] > > Where do you find that? It is possible that this would be excluded because > scalar coord vars are (formally) auxiliary coord vars, which are specifically > excluded from having the axis attribute in the intro to 5. There were good > reasons for that but we ought to be revisit it. Steve Hankin has raised that. > I think scalar coord vars should be allowed to have the axis attr. That is > necessary if they are to have the same info content etc., as quoted above. > > Best wishes > > Jonathan > ___ > 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
Re: [CF-metadata] CF name for predicted water level? [SEC=UNCLASSIFIED]
Hello All.
I would be interested to hear if anyone can expand on the recent discussion of
standard names for predicted water level. In particular with regard to the
several variations of water level data that I am storing in netCDF format, but
for which I am not yet able to comfortably assign standard names.
For example:
* water level actually observed by tide gauges.
* Jeff DLB's "water_surface_height_above_reference_datum" sounds
appropriate but isn't in the current table.
* sea_surface_height_amplitude_due_to_ different versions of ocean tide
* variations of included tidal constituents
* variations on qualitative source of the tidal estimate: insitu harmonic
analysis, gridded tide model
* sea_surface_height_amplitude_due_to_
* non-tidal ocean dynamics
My inclination is to use the most general relevant standard name
("sea_surface_height") and differentiate the variations via 'long_name',
'description' and other metadata but would be happy to hear suggestions.
Also, I note an instance where the descriptive text in the tables (at
http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/16/cf-standard-name-table.html)
has me a little confused.
* sea_surface_height_amplitude_due_to_equilibrium_ocean_tide:
"...equilibrium ocean tide refers to the long period ocean tide."
* sea_surface_height_amplitude_due_to_non_equilibrium_ocean_tide: "...non
equilibrium ocean tide refers to the long period ocean tide."
Cheers
***
Andy Taylor
Ocean Observation, Assessment & Prediction Research Program
Centre for Australian Weather & Climate Research: A partnership between the
Bureau of Meteorology & CSIRO
GPO Box 1289, Melbourne VIC 3001 AUSTRALIA
Tel: +61 3 9669 4650 Fax: +61 3 9669 4660
a.tay...@bom.gov.au
***
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Web reference to a standard name?
On Sat, Dec 18, 2010 at 1:40 AM, John Graybeal wrote: > > 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. > This is an important example, and this argument is the one I cryptically referred to earlier. I would argue that versioning is not the best way to handle this particular problem. One of the core principles of CF evolution that has been frequently stated in these pages is to not invalidate current (and earlier) dataset metadata -- many proposed CF changes have been rejected by arguing that they unnecessarily invalidate datasets described under the current version of CF. This particular case of sophistication -- two new terms giving more precise subsets of an old term -- is essential in describing Science's evolving understanding of a particular topic. And in the sense of making the best choice of cfatt:standard_name in tagging a dataset, it allows a new choice to be made in describing the data, so that it is true that the appearance of sea_surface_temperature as such an attribute has changed. As a practical matter, it is not sufficient to know when a dataset is tagged to figure out what set of terms was being chosen from -- the requester of the change would probably use the standard before it was official, people like me would probably lag the implementation of the standard by some considerable time -- if one is serious about versions, then the version has to be part of the tag, which in CF, it is not. Fortunately, no one is arguing that sea_surface_temperature ceases to describe the dataset because there are more precise terms, it is just that in tagging a dataset, we use the most precise term available. Roy, in fact, is serving relationships between terms, and I would expect that sea_surface_temperature skos:broaderThan sea_surface_skin_temperature would be one of them. What this means in RDF is that having the relationship dataset term:isDescribedBy sea_surface_skin_temperature implies the relationship dataset term:isDescribedBy sea_surface_temperature, and an infering triple-store would return both relationships in a query, presuming that it understood skos. There are two examples of this which are particularly important, First of all, someone with incomplete information (most of us, in the long run, it is science, after all) could successfully tag a dataset with a term more general than the expert would use, and still make a correct statement. Similarly, someone adhering to the original standard could make a correct statement about the data at some earlier date. Most importantly, *additional* metadata could be included, such as a precise specification of the sensor/platform that produced the measurement, that would allow someone to infer at a later date (when the standard has become more specific, as in this example), a more specific standard_name to tag the dataset with. Yes, at that point the one best choice would have changed, but none of the earlier statements would be invalidated. Benno > > 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
