I wasn't sure how to parse these, I'm a little slow today I guess. After trying a few ways, I decided they mostly use spaces to separate convention identifiers, and slashes to designate hierarchy. (Except the first two embed a space within "OceanSITES x.x", which I think should be a hyphen.)
Then I finally got your point, that / (slash) is also a delimiter, but one with an explicit meaning. > I guess the $64,000 question is whether any application program cares about > such subtleties and I think the answer is probably not. As of today, certainly no application program cares about such subtleties, since no standard or community practice exists to make use of them. But even if we state the question as "what is likely to be the most useful in the future, while being usable now?" (likely what you meant), I can't find a use case where the computer would use the order information, other than for display -- the context being of some educational value to users of the data sets, as you say. But this leads to an implementation question, using the examples (modified with hyphens per the above comment): > (A) CF-x.x OceanSITES-x.x SeaDataNet-x.x -- 3 conventions are listed > (B) CF-x.x/OceanSITES-x.x/SeaDataNet-x.x -- 1 conventions are listed, > with its relationship to two others > (C) CF-x.x/SeaDataNet-x.x CF-x.x/OceanSITES-x.x -- 2 conventions are > listed, each with its relationship to a third >From these strings, in the first and third case we don't really know either >way about some of the relationships -- the fact that SeaDataNet-x.x is listed >separately from OceanSITES-x.x may mean it is truly independent, but it could >just as well be derivative, unless we explicitly preclude that usage. Stated >another way, do I have to list every derivative relationship in my Convention >Attribute? That is, if SeaDataNet profiles OceanSites which profiles CF, do I >have to use form (B) for a SeaDataNet Convention identifier, or are forms (A) >and (C) equally acceptable? If all agree form (B) is the only acceptable form, then the profiles can reflect that explicitly when they define the identifier (the SeaDataNet profiler ID will always be of the form (B), and every time CF or OceanSITES updates their profile, SeaDataNet needs to double-check that no conflicts have been created with their profile, and perhaps put out an updated 'version conformance' list each time to reflect that check being successful). Validation software could reasonably expect to validate appropriate sequences, and reject invalid ones. If we say any of these forms is OK, then I expect slash will become an equivalent to space over time. Users will start using the (B) form, but get things out of order (which software won't have any reason to catch), and soon the attribute will just be treated as a list that supports multiple separators. John On Dec 31, 2011, at 03:50, Lowry, Roy K. wrote: > We therefore end up with several possibilities for the Convention Attribute: > > CF-x.x OceanSITES x.x SeaDataNet-x.x > CF-x.x/OceanSITES x.x/SeaDataNet-x.x > CF-x.x/SeaDataNetx.x CF-x.x/OceanSITES x.x > > These have subtly different semantics. The first says nothing about the > convention relationship. The second states SeaDataNet is a profile of > OceanSITES which is in turn a profile of CF. The third states that the file > is conformant to two independent profiles of CF. > > I guess the $64,000 question is whether any application program cares about > such subtleties and I think the answer is probably not. Most will simply > search for the convention required by the application within the attribute > string. Therefore we should be more concerned to ensure that our convention > designators avoid including well-known designators - like 'CF' - as > substrings than with delimiters. Therefore,having information about the > relationship between conventions recorded within the file is useful > provenance metadata that could be achieved at virtually no cost. John Graybeal <mailto:[email protected]> phone: 858-534-2162 Product Manager Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org Marine Metadata Interoperability Project: http://marinemetadata.org _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
