-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aliases #1
Comments
Re (1), right now we do not capture the aliases. We can add this capability; the question is whether these should be type With aliases added, we must decide how they should be involved in mappings. There will be a property ( This whole topic introduces the issue of versioning, because a mapped Standard Name may be turned into an alias in a subsequent version of CF. But I'm not able to think through that quite yet. |
For the sake of simplicity (yet, without compromising utility, at least at some basic level), could we just adopt an approach like the following:
And we just delegate to the inference engine at hand, either the one at the ORR, but in general, to any others depending on user needs, the exploitation of the entailments based on the sameAs semantics. Advantages:
|
I thought about that, it is appealing in some ways. Yet I think it breaks the presumption of many users, namely that we are presenting the authentic list of approved CF standard names. Using that approach, a query for standard names will return all sorts of names that are, in fact, deprecated. (Yes, it will be obvious in some ways that they are not 'complete', but I think any implication that they are real standard_names is not good. I mean, the NVS makes them into a wholly separate list, If I Am Not Mistaken.) |
Good point. One next simple approach: introduce a |
This is the response for the alias <?xml version="1.0" ?>
<?xml-stylesheet href="/VocabV2/Concept2Html.xsl" type="text/xsl" media="screen"?>
<rdf:RDF xmlns:dc="http://purl.org/dc/terms/" xmlns:dce="http://purl.org/dc/elements/1.1/" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:void="http://rdfs.org/ns/void#">
<skos:Concept rdf:about="http://vocab.nerc.ac.uk/collection/P07/current/CFSN0227/">
<skos:prefLabel xml:lang="en">surface_temperature_where_land</skos:prefLabel>
<skos:altLabel/>
<skos:definition xml:lang="en">Unless indicated, a quantity is assumed to apply to the whole area of each horizontal grid box. The qualifier where_type specifies instead that the quantity applies only to the part of the grid box of the named type. The surface temperature is the (skin) temperature at the interface, not the bulk temperature of the medium above or below.</skos:definition>
<dc:identifier>SDN:P07::CFSN0227</dc:identifier>
<dce:identifier>SDN:P07::CFSN0227</dce:identifier>
<skos:notation>SDN:P07::CFSN0227</skos:notation>
<owl:versionInfo>1</owl:versionInfo>
<dc:date>2008-11-11 15:25:45.0</dc:date>
<skos:note xml:lang="en">deprecated</skos:note>
<owl:deprecated>true</owl:deprecated>
<dc:isReplacedBy rdf:resource="http://vocab.nerc.ac.uk/collection/P07/current/CFSN0225/"/>
<skos:broader rdf:resource="http://vocab.nerc.ac.uk/collection/P02/current/CDTA/"/>
<skos:broader rdf:resource="http://vocab.nerc.ac.uk/collection/P04/current/G230/"/>
<skos:broader rdf:resource="http://vocab.nerc.ac.uk/collection/P07/current/CFSN0225/"/>
<owl:sameAs rdf:resource="http://mmisw.org/ont/cf/parameter/surface_temperature_where_land"/>
<skos:broader rdf:resource="http://vocab.nerc.ac.uk/collection/P64/current/G230/"/>
<void:inDataset rdf:resource="http://vocab.nerc.ac.uk/.well-known/void"/>
</skos:Concept>
</rdf:RDF> (BTW, note they are already mapping to the alias terms at the ORR although not yet captured there.) |
Determine and implement an appropriate way to capture the
<alias>
entries into the RDF representation.The text was updated successfully, but these errors were encountered: