Hello Marin,
I'm not sure what would be possible using the string-matching SPARQL approach. It would be perfectly possible to do that from a relational database using SQL (which I do know) and so it may be possible. I'll see if Adam can come up with anything (I've yet to learn the language).
However, I am certain that if we installed a mapping (maybe a day's work) then it could be done - all the query would have to do is identify whether or not there is a mapping from the Standard Name reference to the EEA vocabulary and match on it if it exists.
Installing a mapping in NVS fulfils exactly the same function as adding a link to the Standard Name table. The difference is that the former process simply involves population of operational technological infrastructure (a mapping is a row in an Oracle table) with some funding support if the work is done before the end of January, whereas the latter would require infrastructure development in addition to population.
Cheers, Roy.
________________________________
From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Schultz, Martin [m.schultz at fz-juelich.de]
Sent: 20 October 2012 11:43
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] Extensions to the Standard Name table
Dear Roy,
thanks a lot for this nice example of true interoperability. Yet, two questions remain: 1) what I would be even more interested in is the inverse problem, i.e. given a standard_name, I would like to know which compound it contains. 2) I expect that this is more difficult, in particular if we don?t know a priori that the given standard_name does contain a compound name. Generally, this is where I see the difficulty with your brokered approach: how do you find out which controlled vocabulary list(s) have to be applied in order to identify the components of a standard_name? Think of ?tendency_of_X_due_to_emissions_from_Y? where you want to link both the compound and the emission sector to the respecitve controlled vocabulary table. Then, in another standard_name you will find some marine bacteria or so which relate to yet another vocabulary list, and so on. Unless I miss the point here, I would still argue that it will be more efficient and less ambiguous if the link would be provided in the standard_name
table itself.
What do you think?
Cheers,
Martin
Date: Fri, 19 Oct 2012 12:30:42 +0100
From: "Lowry, Roy K." <rkl at bodc.ac.uk<mailto:rkl at bodc.ac.uk>>
To: "cf-metadata at cgd.ucar.edu<mailto:cf-metadata at cgd.ucar.edu>" <cf-metadata at cgd.ucar.edu<mailto:cf-metadata at cgd.ucar.edu>>
Subject: [CF-metadata] Extensions to the Standard Name table
Message-ID:
<40829B0E077C1145A6DE44D39B3830A921F5722C84 at nerckwmb1.ad.nerc.ac.uk<mailto:40829B0E077C1145A6DE44D39B3830A921F5722C84 at nerckwmb1.ad.nerc.ac.uk>>
Content-Type: text/plain; charset="us-ascii"
Dear All,
Martin Schultz was proposing an extension to the Standard Name table to provide a means of easily identifying the Standard Names associated with a given atmospheric contaminant. What follows provides an alternative way to address his use case. Go to the URL
http://vocab.nerc.ac.uk/sparql/ and copy the SPARQL query at the end of this message into the box, choose your output format and press 'Get Results'. If you don't want 'carbon monoxide' simply replace 'Carbon monoxide' by another valid EEA contaminant name.
For the techies on the list, this is done by a federated SPARQL query involving SPARQL endpoints on vocabulary servers at BODC and the EEA. This is based on string matching, but could be made more robust by implementing an EEA/Standard Names mapping in NVS should this be requested by the CF community.
Cheers, Roy.
PREFIX skos: <
http://www.w3.org/2004/02/skos/core#>
PREFIX j.0: <
http://rdfdata.eionet.europa.eu/airbase/schema/>
PREFIX rdfs: <
http://www.w3.org/2000/01/rdf-schema#>
SELECT ?urie ?labele ?urin ?labeln WHERE {
BIND("Carbon monoxide" AS ?pollutant)
SERVICE<
http://cr.eionet.europa.eu/sparql>
{
?urie skos:inScheme <
http://rdfdata.eionet.europa.eu/airquality/components/>.
?urie skos:prefLabel ?labele.
?urie j.0:pollutant ?pollutant.
}.
<
http://vocab.nerc.ac.uk/collection/P07/current/> skos:member ?urin.
?urin skos:prefLabel ?labeln.
?urin skos:definition ?defn.
FILTER CONTAINS (str(lcase(?defn)),str(lcase(?pollutant)))
}
PD Dr. Martin G. Schultz
IEK-8, Forschungszentrum J?lich
D-52425 J?lich
Ph: +49 2461 61 2831
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Kennen Sie schon unsere app?
http://www.fz-juelich.de/app
--
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20121021/000d12f0/attachment-0001.html>
Received on Sun Oct 21 2012 - 02:21:12 BST
