Dear John,
Do the Seadatanet vocabularies correspond to what you are expecting? You can have a look at
http://seadatanet.maris2.nl/v_bodc_vocab/welcome.aspx
In Seadatanet a vocabulary is identified via URN notation as following 'SDN:Reference:Version:Key'
where
- SDN is a constant character string indicating that the identifier is unique within SeaDataNet (mandatory),
- Reference is the reference of the vocabulary list or European Directory (mandatory). For examples C161 for International Hydrographic Bureau (1953) sea areas (Vocabulary List C161),
- Version is the version number of the list or directory. The version number is mandatory for Vocabulary lists which supports versioning
- Key is the unique identifier within the list or the directory.(mandatory).
SeaDataNet uses (alpha)numerical coding (Key) for communication, but is not multilingual. All thesaurus terms (abbreviations and definitions) are in English and partners "map" their local terms to the central SDN thesaurus value. Besides the coding also the value (abbreviation) itself is included in the XML to make it beter human readible/understandable.
Hierarchy of terms in also embedded in the SeaDataNet thesauri, for example for the parameters.
A dedicated Parameter Discovery Vocabulary (PDV) (P021) was defined in a cooperation between BODC and IFREMER, which is maintained by BODC. The PDV contains a hierarchical structure to support the CDI User Interface. The hierarchy contains the following levels:
P081: Discipline (at present 9 items)
P031: Agreed Parameter Groups (at present 43 items)
P021: Parameter Discovery Vocabulary (at present 335 items)
P011: BODC Parameter Usage Vocabulary (at present 20.000 + items)
The SDN webservices provides the relations between the different levels of the parameter hierarchy.
Each level has a Broader Term - Narrow Terms relation. This implicates that each Discipline is related to a multiple of Agreed Parameter Groups, each of which on it's turn is related to a multiple of PDV terms. The lowest level in the hierarchy is the BODC Parameter Usage Vocabulary (at present > 20.000 items). Each of these belong to a Parameter Group / PDV term.
Cheers
Olivier Lauret
-----Message d'origine-----
De?: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] De la part de John Graybeal
Envoy??: lundi 23 juin 2008 21:55
??: CF Metadata
Objet?: [CF-metadata] vocabulary-specific standard names
All,
MMI will soon make a recommendation to some netCDF users, and perhaps to the community, about storing their parameter name associations within a CF netCDF file. And so we'd like advice.
In particular, we face a scenario where the user has a set of local parameter names, which may be mapped to, or even equivalent to, terms in multiple community vocabularies. Here are 3 use cases, simplest first:
1. A term is not found in the CF standard names list, and for whatever reason can not be in that list.
2. Local custom requires association with a different vocabulary than CF.
3. There are multiple applicable vocabularies, which together fully describe this parameter, but individually are not sufficient.
In each case each individual name may be associated with a single external vocabulary, but some names have different associated vocabularies than others. In the third case (and perhaps the second), a single name may be associated with multiple external vocabularies.
It should be assumed that the association can be made by reference to a URI; that is, it is not necessary to specify both a vocabulary AND a term within that vocabulary, the URI can encompass both. (As opposed to a solution which requires a namespace for each vocabulary, then the term is specified within that namespace -- this has a certain appeal but isn't as important as compatibility with URIs.
Is there any particular operational practice or recommendation as to best practice, to enable associating the local parameter with terms in multiple community vocabularies, not just CF vocabularies? If not, does anyone want to recommend one to me? (I am willing to recommend it to CF if it makes sense to me, but I'm not skilled enough to try to originate a really good approach all by myself.)
I have reviewed the trac tickets but do not believe that any of them directly address this concern. Thank you for any advice.
John
--
----------
John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Interoperability Project: http://marinemetadata.org
Shore Side Data System: http://www.mbari.org/ssds
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Cliquez sur l'url suivante
https://www.mailcontrol.com/sr/!b+MEfrCgznTndxI!oX7UkccJfXxjPVW858GvV3mpaAlxM5itLQSJdDOV1lHDGg!Qnc9nYIKs9!ZM0Vr2cPI!w==
si ce message est ind?sirable (pourriel).
Received on Thu Jun 26 2008 - 08:44:56 BST
