Dear all
Just to update you - I've gained a little more understanding of SPARQL and have
an update to the query B from my earlier e-mail (below) which gives (for
example) the following results:
standardName
pollutant source
"surface_upward_mass_flux_of_carbon_dioxide_expressed_as_carbon_due_to_emission_from_crop_harvesting"
@en "Carbon dioxide" "harvest"
Thanks
Adam
--Query B (updated)
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 ?standardName ?pollutant ?source WHERE
{
BIND("surface_upward_mass_flux_of_carbon_dioxide_expressed_as_carbon_due_to_emission_from_crop_harvesting"
AS ?stdname)
{SELECT ?standardName ?urisn ?urip ?urig ?source WHERE
{
<http://vocab.nerc.ac.uk/collection/P07/current/> skos:member ?urisn.
?urisn skos:prefLabel ?standardName.
?urisn skos:broader ?urip
FILTER CONTAINS (str(?urip),"eionet").
OPTIONAL
{
?urisn skos:related ?urig
FILTER CONTAINS (str(?urig),"gemet")
}
}} FILTER (str(?standardName) = str(?stdname))
SERVICE <http://cr.eionet.europa.eu/sparql>
{
?urie j.0:pollutant ?pollutant
FILTER (?urie=?urip).
?urige rdfs:label ?source
FILTER (?urige=?urig)
}
}
-----Original Message-----
From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of
Leadbetter, Adam
Sent: 29 October 2012 13:33
To: Schultz, Martin; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Extensions to the Standard Name table
Dear Martin and all
I've done some mappings between the CF Standard Names at
http://vocab.nerc.ac.uk/collection/P07/ and both the EEA Atmospheric Pollutants
vocabulary and GEMET. The mapped Standard Names can be found by running Query
'A' below in http://vocab.nerc.ac.uk/sparql/. I've tried, and failed, to get a
decent response time from the federated query (I'm still learning SPARQL so
it's likely I'm doing something wrong) but I have attached a Query B which
shows you the mappings to the EEA pollutant name & the mappings to GEMET for a
given Standard Name. It can be a bit slow, so you may need to show it some
patience.
If anyone knows SPARQL better than I do, and can do improve Query B then please
feel free to do so.
This is currently implemented as a "proof of concept" using some loose
mappings, and it may be that you have suggestions on better terms to map to. If
this the sort of thing you wanted and is of use to the CF community we can
certainly expand the number of mappings done but we could also investigate
firming up the mappings using more specific relationships.
Let me know what you think
Thanks
Adam
--Query A
PREFIX skos:<http://www.w3.org/2004/02/skos/core#>
PREFIX rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>
SELECT DISTINCT ?standardName WHERE
{
<http://vocab.nerc.ac.uk/collection/P07/current/> rdf:type skos:Collection.
<http://vocab.nerc.ac.uk/collection/P07/current/> skos:member ?uri.
?uri skos:prefLabel ?standardName.
?uri ?relationship ?eionet
FILTER CONTAINS (str(?eionet),'eionet') }
--Query B
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 ?standardName ?pollutant ?urig WHERE {
BIND("surface_upward_mass_flux_of_carbon_dioxide_expressed_as_carbon_due_to_emission_from_crop_harvesting"
AS ?stdname)
{SELECT ?standardName ?urisn ?urip ?urig WHERE
{
<http://vocab.nerc.ac.uk/collection/P07/current/> skos:member ?urisn.
?urisn skos:prefLabel ?standardName.
?urisn skos:broader ?urip
FILTER CONTAINS (str(?urip),"eionet").
OPTIONAL
{
?urisn skos:related ?urig
FILTER CONTAINS (str(?urig),"gemet")
}
}} FILTER (str(?standardName) = str(?stdname))
SERVICE <http://cr.eionet.europa.eu/sparql>
{
?urip j.0:pollutant ?pollutant.
}
}
____________________________________________________________
Dr. Adam Leadbetter
Data Scientist
British Oceanographic Data Centre
Joseph Proudman Building
6 Brownlow Street
Liverpool
L3 5DA
Tel: 0151 795 4878
-----Original Message-----
From: Schultz, Martin [mailto:m.schu...@fz-juelich.de]
Sent: 22 October 2012 15:07
To: Leadbetter, Adam; Lowry, Roy K.; cf-metadata@cgd.ucar.edu
Subject: AW: [CF-metadata] Extensions to the Standard Name table
Great! Looking forward to test this!
Cheers,
Martin
-----Ursprüngliche Nachricht-----
Von: Leadbetter, Adam [mailto:al...@bodc.ac.uk]
Gesendet: Montag, 22. Oktober 2012 14:45
An: Lowry, Roy K.; Schultz, Martin; cf-metadata@cgd.ucar.edu
Betreff: RE: [CF-metadata] Extensions to the Standard Name table
Hi Martin
I'll aim to have the small demonstrator with mappings in place towards the end
of this week, or early next week.
Thanks
Adam
________________________________________
From: Lowry, Roy K.
Sent: 21 October 2012 17:17
To: Schultz, Martin; cf-metadata@cgd.ucar.edu
Cc: Leadbetter, Adam
Subject: RE: [CF-metadata] Extensions to the Standard Name table
OK Martin,
I'm on leave for the next 2 weeks, but will try and get a demonstration mapping
with 4 or 5 contaminants mapped the week after I get back (unless Adam can do
something in the mean time).
Cheers, Roy.
________________________________
From: Schultz, Martin [m.schu...@fz-juelich.de]
Sent: 21 October 2012 15:00
To: Lowry, Roy K.; cf-metadata@cgd.ucar.edu
Cc: Leadbetter, Adam
Subject: AW: [CF-metadata] Extensions to the Standard Name table
Hello Roy,
this sounds indeed convincing. If there is indeed some funding to
establish this by January, and if we can then somehow ensure continuity
(someone would have to update the mapping whenever there are changes to the
standard_name table, and we should be in a position to add more rows to the
table even after funding will have ended), then this sounds like a good plan.
Cheers,
Martin
Von: Lowry, Roy K. [mailto:r...@bodc.ac.uk]
Gesendet: Sonntag, 21. Oktober 2012 10:21
An: Schultz, Martin; cf-metadata@cgd.ucar.edu
Cc: Leadbetter, Adam
Betreff: RE: [CF-metadata] Extensions to the Standard Name table
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-boun...@cgd.ucar.edu] On Behalf Of Schultz,
Martin [m.schu...@fz-juelich.de]
Sent: 20 October 2012 11:43
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@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." <r...@bodc.ac.uk<mailto:r...@bodc.ac.uk>>
To: "cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>"
<cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>>
Subject: [CF-metadata] Extensions to the Standard Name table
Message-ID:
<40829b0e077c1145a6de44d39b3830a921f5722...@nerckwmb1.ad.nerc.ac.uk<mailto:40829b0e077c1145a6de44d39b3830a921f5722...@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#<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#<http://www.w3.org/2000/01/rdf-schema>>
SELECT ?urie ?labele ?urin ?labeln WHERE {
BIND("Carbon monoxide" AS ?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.
_______________________________________________
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
