Re: SPARQL results in RDF
Hi Hugh,
I recently stumbled over this post by the TopBraid/SPIN guys. Maybe
this is appropiate for your usecase.
http://composing-the-semantic-web.blogspot.ch/2013/06/spin-vocabulary-for-column-metadata.html
Regards,
Jerven
On Sun, Sep 22, 2013 at 1:29 AM, Hugh Glaser h...@ecs.soton.ac.uk wrote:
Thanks Jerven, you may well be right!
SELECT DISTINCT * WHERE
{ ?s foo:bar ?o }
would do.
And things like
SELECT DISTINCT * WHERE
{ ?v1 foo:bar ?o . ?v1 ?p1 ?v2 . ?v2 ?p2 ?v3 }
and then probably get back an identifier for each result, so that I can find
out what are the values of the ?p* and ?v*
I think essentially the sort of thing that dbpedia/virtuoso is giving me.
(By the way, Kingsley, replying to this has caused me to notice that the
rdfxml does not rapper very nicely - sorry to report!
rapper: Error - URI file:///home/hg/sparql.rdf:8 - property element
'solution' has multiple object node elements, skipping.)
Best
Hugh
On 21 Sep 2013, at 23:32, Jerven Bolleman jerven.bolle...@isb-sib.ch
wrote:
Hi Hugh,
I think you disregarded the CONSTRUCT queries a bit to quickly. This is what
you use when you want to get back triples.
If you want back result columns you use SELECT. If you want describe to the
concept of result columns in RDF then you are
on your own.
Maybe if you explain what you want to represent then we can have a bit more
of an informed discussion.
Regards,
Jerven
On Sep 21, 2013, at 8:38 PM, Hugh Glaser h...@ecs.soton.ac.uk wrote:
Many thanks, William, and for confirming so quickly.
(And especially thanks for not telling me that CONSTRUCT does what I want!)
I had suddenly got excited that RDF might actually be useable to represent
something I wanted to represent, just like we tell other people :-)
So it is all non-standard, as I suspected.
Ah well, I'll go back to trying to work with XML stuff, instead of using my
usual RDF tools :-(
Very best
Hugh
On 21 Sep 2013, at 19:14, William Waites w...@styx.org
wrote:
Hi Hugh,
You can get results in RDF if you use CONSTRUCT -- which is basically
a special case of SELECT that returns 3-tuples and uses set semantics
(does not allow duplicates), but I imagine that you are aware of this.
Returning RDF for SELECT where the result set consists in n-tuples
where n != 3 is difficult because there is no direct way to represent
it.
Also problematic is that there *is* a concept of order in SPARQL query
results while there is not with RDF.
Also the use of bag semantics allowing duplicates which also does not
really work with RDF.
These, again, could be kludged with reification, but that is not very
elegant.
So most SELECT results are not directly representable in RDF.
Cheers,
-w
---
Jerven Bollemanjerven.bolle...@isb-sib.ch
SIB Swiss Institute of Bioinformatics Tel: +41 (0)22 379 58 85
CMU, rue Michel Servet 1 Fax: +41 (0)22 379 58 58
1211 Geneve 4,
Switzerland www.isb-sib.ch - www.uniprot.org
Follow us at https://twitter.com/#!/uniprot
---
--
Jerven Bolleman
m...@jerven.eu
Re: SPARQL results in RDF
On 25/09/2013 00:23, Tim Harsch wrote:
That idea seems very similar to the DELETE WHERE already in SPARQL 1.1, so
maybe to be consistent with that existing syntax it should be CONSTRUCT WHERE
Hmmm... something like:
http://www.w3.org/TR/2013/REC-sparql11-query-20130321/#constructWhere
Stuart
--
On Mon, Sep 23, 2013 at 3:08 PM, Tim Berners-Lee ti...@w3.org
mailto:ti...@w3.org wrote:
1) I can see Hugh's frustration that the RDF system is incomplete
in a way. You tell everyone you have a model which can
be used for anything and then make something which doesn't use it.
What's wrong with this picture?
Standardising/using/adopting
http://www.w3.org/2001/sw/DataAccess/tests/result-set
would solve that.
(The file actually defines terms like
http://www.w3.org/2001/sw/DataAccess/tests/result-set#resultVariable
without the .n3)
2) Different (I think) from what you want Hugh, but something I have
thought would be handy would b a CONSTRUCT * where it returns the sub
graphs it matches as turtle, ideally without duplicates.
This would be nice for lots of things, such as extracting a subset of a
dataset.
CONSTRUCT * WHERE { ?x name ?y; age ?a; ?p ?o.} FILTER { a 18 }
Tim
On 2013-09 -23, at 07:03, Andy Seaborne wrote:
DAWG did at one time work with result sets encoded in RDF for the testing
work.
As the WG progressed, it was clear that implementation of testing
was based on result set comparison, and an impl needed to grok the XML
results encoding anyway. Hence the need for the RDF form dwindled but it's still
there:
http://www.w3.org/2001/sw/DataAccess/tests/result-set.n3
Apache Jena will still produce it if you ask it nicely.
Andy
--
Epimorphics Ltdwww.epimorphics.com
Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT
Tel: 01275 399069
Epimorphics Ltd. is a limited company registered in England (number 7016688)
Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT,
UK
Re: SPARQL results in RDF
You'll get me using CONSTRUCT soon :-)
(By the way, Tim's actual CONSTRUCT WHERE query isn't allowed because of the
FILTER).
In the end, I just wrote a little service to process the XML into turtle, so I
do want I want now.
The problem is that the only result format I can rely on an endpoint giving is
XML:- CSV and TSV (the other standards) which would have been easier are not
always supported, it seems.
One thing I was trying to do (as Tim distinguished) was have the result set,
bindings and all, in RDF, if for nothing else than credibility and PR.
Because it is true that people I explain Linked Data, RDF and conneg to and
then go on to RDF stores just can't understand how I can tell them about this
wonderful RDF, but when they ask or even try to do a conneg to the endpoint
they don't get RDF.
I think one answer is to ignore SELECT completely, and just talk about
CONSTRUCT.
It makes a lot more sense - in fact I might do that myself.
One fly in the ointment for that is that (as far as I can tell), even though I
get RDF turtle or whatever back from an endpoint, it doesn't allow me to conneg
for Accept:application/rdf+xml
At least dbpedia seems to give 406 Unacceptable.
Is there some adjustment that could be made here?
I know it would be a fudge, but if I request Accept:application/rdf+xml on a
SPARQL endpoint, using a CONSTRUCT, would it be so bad to actually return
RDFXML?
Thanks for all the interesting discussion.
Hugh
On 25 Sep 2013, at 10:05, Stuart Williams s...@epimorphics.com wrote:
On 25/09/2013 00:23, Tim Harsch wrote:
That idea seems very similar to the DELETE WHERE already in SPARQL 1.1, so
maybe to be consistent with that existing syntax it should be CONSTRUCT
WHERE
Hmmm... something like:
http://www.w3.org/TR/2013/REC-sparql11-query-20130321/#constructWhere
Stuart
--
On Mon, Sep 23, 2013 at 3:08 PM, Tim Berners-Lee ti...@w3.org
mailto:ti...@w3.org wrote:
1) I can see Hugh's frustration that the RDF system is incomplete
in a way. You tell everyone you have a model which can
be used for anything and then make something which doesn't use it.
What's wrong with this picture?
Standardising/using/adopting
http://www.w3.org/2001/sw/DataAccess/tests/result-set
would solve that.
(The file actually defines terms like
http://www.w3.org/2001/sw/DataAccess/tests/result-set#resultVariable
without the .n3)
2) Different (I think) from what you want Hugh, but something I have
thought would be handy would b a CONSTRUCT * where it returns the sub
graphs it matches as turtle, ideally without duplicates.
This would be nice for lots of things, such as extracting a subset of a
dataset.
CONSTRUCT * WHERE { ?x name ?y; age ?a; ?p ?o.} FILTER { a 18 }
Tim
On 2013-09 -23, at 07:03, Andy Seaborne wrote:
DAWG did at one time work with result sets encoded in RDF for the
testing work.
As the WG progressed, it was clear that implementation of testing
was based on result set comparison, and an impl needed to grok the XML
results encoding anyway. Hence the need for the RDF form dwindled but it's
still there:
http://www.w3.org/2001/sw/DataAccess/tests/result-set.n3
Apache Jena will still produce it if you ask it nicely.
Andy
--
Epimorphics Ltdwww.epimorphics.com
Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT
Tel: 01275 399069
Epimorphics Ltd. is a limited company registered in England (number 7016688)
Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20
6PT, UK
Re: SPARQL results in RDF
On 25/09/2013 11:26, Hugh Glaser wrote: You'll get me using CONSTRUCT soon :-) (By the way, Tim's actual CONSTRUCT WHERE query isn't allowed because of the FILTER). Good catch... yes - I've been bitten by that kind of thing too... that not all that's admissible in a WHERE 'body', is admissible in a CONSTRUCT 'body'. Stuart -- Epimorphics Ltdwww.epimorphics.com Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT Tel: 01275 399069 Epimorphics Ltd. is a limited company registered in England (number 7016688) Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT, UK
Re: SPARQL results in RDF
On 25/09/13 12:03, Stuart Williams wrote: On 25/09/2013 11:26, Hugh Glaser wrote: You'll get me using CONSTRUCT soon :-) (By the way, Tim's actual CONSTRUCT WHERE query isn't allowed because of the FILTER). Good catch... yes - I've been bitten by that kind of thing too... that not all that's admissible in a WHERE 'body', is admissible in a CONSTRUCT 'body'. As far as I'm aware it is -- Tim's original simply misplaced a curly brace. The filter ought to be in the WHERE body. CONSTRUCT is essentially SELECT with a tabular data - rdf system bolted at the end of the pipeline. Damian
Re: SPARQL results in RDF
Hi Damian, On 25/09/13 14:16, Damian Steer wrote: On 25/09/13 12:03, Stuart Williams wrote: On 25/09/2013 11:26, Hugh Glaser wrote: You'll get me using CONSTRUCT soon :-) (By the way, Tim's actual CONSTRUCT WHERE query isn't allowed because of the FILTER). Good catch... yes - I've been bitten by that kind of thing too... that not all that's admissible in a WHERE 'body', is admissible in a CONSTRUCT 'body'. As far as I'm aware it is -- Tim's original simply misplaced a curly brace. The filter ought to be in the WHERE body. CONSTRUCT is essentially SELECT with a tabular data - rdf system bolted at the end of the pipeline. I think the point people were making is that the syntactic shortform CONSTRUCT WHERE with implicit template only applies when you have a simple basic graph pattern [1]. If the WHERE clause is more complex, e.g. with a FILTER, then you need an explicit construct template. Dave [1] http://www.w3.org/TR/sparql11-query/#constructWhere
Re: SPARQL results in RDF
On 25/09/13 14:57, Sven R. Kunze wrote: On 09/25/2013 03:53 PM, Dave Reynolds wrote: Hi Damian, On 25/09/13 14:16, Damian Steer wrote: On 25/09/13 12:03, Stuart Williams wrote: On 25/09/2013 11:26, Hugh Glaser wrote: You'll get me using CONSTRUCT soon :-) (By the way, Tim's actual CONSTRUCT WHERE query isn't allowed because of the FILTER). Good catch... yes - I've been bitten by that kind of thing too... that not all that's admissible in a WHERE 'body', is admissible in a CONSTRUCT 'body'. As far as I'm aware it is -- Tim's original simply misplaced a curly brace. The filter ought to be in the WHERE body. CONSTRUCT is essentially SELECT with a tabular data - rdf system bolted at the end of the pipeline. I think the point people were making is that the syntactic shortform CONSTRUCT WHERE with implicit template only applies when you have a simple basic graph pattern [1]. If the WHERE clause is more complex, e.g. with a FILTER, then you need an explicit construct template. Dave [1] http://www.w3.org/TR/sparql11-query/#constructWhere How did you come to that conclusion? Based on the part of the specification given by link [1] above, which says (my emphasis): A short form for the CONSTRUCT query form is provided for the case where the template and the pattern are the same and the pattern is just a basic graph pattern **(no FILTERs and no complex graph patterns are allowed in the short form)**. Dave
Re: SPARQL results in RDF
On 09/25/2013 04:02 PM, Dave Reynolds wrote: On 25/09/13 14:57, Sven R. Kunze wrote: On 09/25/2013 03:53 PM, Dave Reynolds wrote: Hi Damian, On 25/09/13 14:16, Damian Steer wrote: On 25/09/13 12:03, Stuart Williams wrote: On 25/09/2013 11:26, Hugh Glaser wrote: You'll get me using CONSTRUCT soon :-) (By the way, Tim's actual CONSTRUCT WHERE query isn't allowed because of the FILTER). Good catch... yes - I've been bitten by that kind of thing too... that not all that's admissible in a WHERE 'body', is admissible in a CONSTRUCT 'body'. As far as I'm aware it is -- Tim's original simply misplaced a curly brace. The filter ought to be in the WHERE body. CONSTRUCT is essentially SELECT with a tabular data - rdf system bolted at the end of the pipeline. I think the point people were making is that the syntactic shortform CONSTRUCT WHERE with implicit template only applies when you have a simple basic graph pattern [1]. If the WHERE clause is more complex, e.g. with a FILTER, then you need an explicit construct template. Dave [1] http://www.w3.org/TR/sparql11-query/#constructWhere How did you come to that conclusion? Based on the part of the specification given by link [1] above, which says (my emphasis): A short form for the CONSTRUCT query form is provided for the case where the template and the pattern are the same and the pattern is just a basic graph pattern **(no FILTERs and no complex graph patterns are allowed in the short form)**. Dave I see, Dave. However, my intention was to understand the reason behind that decision. This quote is not a justification, just a description of what's expected to work. I can't see why restricting the set of where clauses is necessary. -- Sven R. Kunze Technische Universität Chemnitz Department of Computer Science Distributed and Self-organizing Systems Group Straße der Nationen 62 D-09107 Chemnitz Germany E-Mail: sven.ku...@informatik.tu-chemnitz.de WWW: http://vsr.informatik.tu-chemnitz.de/people/kunze Phone: +49 371 531 33882
Re: SPARQL results in RDF
The where clauses for CONSTRUCT are not restricted.
CONSTRUCT WHERE {} is a shorthand for CONSTRUCT {} WHERE {} and the first
of those two patterns is restricted. It has to be because the target graph
is created from that pattern by substitution, not any evaluation.
Barry
On Wed, Sep 25, 2013 at 3:10 PM, Sven R. Kunze
sven.ku...@informatik.tu-chemnitz.de wrote:
On 09/25/2013 04:02 PM, Dave Reynolds wrote:
On 25/09/13 14:57, Sven R. Kunze wrote:
On 09/25/2013 03:53 PM, Dave Reynolds wrote:
Hi Damian,
On 25/09/13 14:16, Damian Steer wrote:
On 25/09/13 12:03, Stuart Williams wrote:
On 25/09/2013 11:26, Hugh Glaser wrote:
You'll get me using CONSTRUCT soon :-)
(By the way, Tim's actual CONSTRUCT WHERE query isn't allowed because
of the FILTER).
Good catch... yes - I've been bitten by that kind of thing too... that
not all that's admissible in a WHERE 'body', is admissible in a
CONSTRUCT 'body'.
As far as I'm aware it is -- Tim's original simply misplaced a curly
brace. The filter ought to be in the WHERE body.
CONSTRUCT is essentially SELECT with a tabular data - rdf system
bolted
at the end of the pipeline.
I think the point people were making is that the syntactic shortform
CONSTRUCT WHERE with implicit template only applies when you have a
simple basic graph pattern [1].
If the WHERE clause is more complex, e.g. with a FILTER, then you need
an explicit construct template.
Dave
[1]
http://www.w3.org/TR/sparql11-**query/#constructWherehttp://www.w3.org/TR/sparql11-query/#constructWhere
How did you come to that conclusion?
Based on the part of the specification given by link [1] above, which
says (my emphasis):
A short form for the CONSTRUCT query form is provided for the case where
the template and the pattern are the same and the pattern is just a basic
graph pattern **(no FILTERs and no complex graph patterns are allowed in
the short form)**.
Dave
I see, Dave. However, my intention was to understand the reason behind
that decision. This quote is not a justification, just a description of
what's expected to work.
I can't see why restricting the set of where clauses is necessary.
--
Sven R. Kunze
Technische Universität Chemnitz
Department of Computer Science
Distributed and Self-organizing Systems Group
Straße der Nationen 62
D-09107 Chemnitz
Germany
E-Mail:
sven.ku...@informatik.tu-**chemnitz.desven.ku...@informatik.tu-chemnitz.de
WWW:
http://vsr.informatik.tu-**chemnitz.de/people/kunzehttp://vsr.informatik.tu-chemnitz.de/people/kunze
Phone: +49 371 531 33882
Re: SPARQL results in RDF
On 25/09/13 15:10, Sven R. Kunze wrote: On 09/25/2013 04:02 PM, Dave Reynolds wrote: On 25/09/13 14:57, Sven R. Kunze wrote: On 09/25/2013 03:53 PM, Dave Reynolds wrote: Hi Damian, On 25/09/13 14:16, Damian Steer wrote: On 25/09/13 12:03, Stuart Williams wrote: On 25/09/2013 11:26, Hugh Glaser wrote: You'll get me using CONSTRUCT soon :-) (By the way, Tim's actual CONSTRUCT WHERE query isn't allowed because of the FILTER). Good catch... yes - I've been bitten by that kind of thing too... that not all that's admissible in a WHERE 'body', is admissible in a CONSTRUCT 'body'. As far as I'm aware it is -- Tim's original simply misplaced a curly brace. The filter ought to be in the WHERE body. CONSTRUCT is essentially SELECT with a tabular data - rdf system bolted at the end of the pipeline. I think the point people were making is that the syntactic shortform CONSTRUCT WHERE with implicit template only applies when you have a simple basic graph pattern [1]. If the WHERE clause is more complex, e.g. with a FILTER, then you need an explicit construct template. Dave [1] http://www.w3.org/TR/sparql11-query/#constructWhere How did you come to that conclusion? Based on the part of the specification given by link [1] above, which says (my emphasis): A short form for the CONSTRUCT query form is provided for the case where the template and the pattern are the same and the pattern is just a basic graph pattern **(no FILTERs and no complex graph patterns are allowed in the short form)**. Dave I see, Dave. However, my intention was to understand the reason behind that decision. This quote is not a justification, just a description of what's expected to work. I can't see why restricting the set of where clauses is necessary. You can consult the email archives and telecon meeting minutes for the discussions. The spec is not going to have a justification for every decision; that's not a spec anymore! It gets increasingly difficult to define what the implicit template should be. What about OPTIONALS? UNION? Subquery? There was a consideration of BGP+FILTER. In the end, given the constraints of time and other features, the simple case (simple to explain, to implement and to specify) where the template and the WHERE pattern are the same was put in the spec. Otherwise you need to give the relation of WHERE to template. Andy
Re: SPARQL results in RDF
On 09/25/2013 04:31 PM, Andy Seaborne wrote: On 25/09/13 15:10, Sven R. Kunze wrote: On 09/25/2013 04:02 PM, Dave Reynolds wrote: On 25/09/13 14:57, Sven R. Kunze wrote: On 09/25/2013 03:53 PM, Dave Reynolds wrote: Hi Damian, On 25/09/13 14:16, Damian Steer wrote: On 25/09/13 12:03, Stuart Williams wrote: On 25/09/2013 11:26, Hugh Glaser wrote: You'll get me using CONSTRUCT soon :-) (By the way, Tim's actual CONSTRUCT WHERE query isn't allowed because of the FILTER). Good catch... yes - I've been bitten by that kind of thing too... that not all that's admissible in a WHERE 'body', is admissible in a CONSTRUCT 'body'. As far as I'm aware it is -- Tim's original simply misplaced a curly brace. The filter ought to be in the WHERE body. CONSTRUCT is essentially SELECT with a tabular data - rdf system bolted at the end of the pipeline. I think the point people were making is that the syntactic shortform CONSTRUCT WHERE with implicit template only applies when you have a simple basic graph pattern [1]. If the WHERE clause is more complex, e.g. with a FILTER, then you need an explicit construct template. Dave [1] http://www.w3.org/TR/sparql11-query/#constructWhere How did you come to that conclusion? Based on the part of the specification given by link [1] above, which says (my emphasis): A short form for the CONSTRUCT query form is provided for the case where the template and the pattern are the same and the pattern is just a basic graph pattern **(no FILTERs and no complex graph patterns are allowed in the short form)**. Dave I see, Dave. However, my intention was to understand the reason behind that decision. This quote is not a justification, just a description of what's expected to work. I can't see why restricting the set of where clauses is necessary. You can consult the email archives and telecon meeting minutes for the discussions. The spec is not going to have a justification for every decision; that's not a spec anymore! It gets increasingly difficult to define what the implicit template should be. What about OPTIONALS? UNION? Subquery? There was a consideration of BGP+FILTER. In the end, given the constraints of time and other features, the simple case (simple to explain, to implement and to specify) where the template and the WHERE pattern are the same was put in the spec. Otherwise you need to give the relation of WHERE to template. Andy Alright, I understand that. Thanks. It was just curiosity because that the where clause couldn't be more than a BGP was considered natural and logical; which it wasn't to me. Sven -- Sven R. Kunze Technische Universität Chemnitz Department of Computer Science Distributed and Self-organizing Systems Group Straße der Nationen 62 D-09107 Chemnitz Germany E-Mail: sven.ku...@informatik.tu-chemnitz.de WWW: http://vsr.informatik.tu-chemnitz.de/people/kunze Phone: +49 371 531 33882
Re: SPARQL results in RDF
DAWG did at one time work with result sets encoded in RDF for the testing work. As the WG progressed, it was clear that implementation of testing was based on result set comparison, and an impl needed to grok the XML results encoding anyway. Hence the need for the RDF form dwindled but it's still there: http://www.w3.org/2001/sw/DataAccess/tests/result-set.n3 Apache Jena will still produce it if you ask it nicely. Andy
Re: SPARQL results in RDF
1) I can see Hugh's frustration that the RDF system is incomplete
in a way. You tell everyone you have a model which can
be used for anything and then make something which doesn't use it.
What's wrong with this picture?
Standardising/using/adopting
http://www.w3.org/2001/sw/DataAccess/tests/result-set
would solve that.
(The file actually defines terms like
http://www.w3.org/2001/sw/DataAccess/tests/result-set#resultVariable
without the .n3)
2) Different (I think) from what you want Hugh, but something I have thought
would be handy would b a CONSTRUCT * where it returns the sub graphs it
matches as turtle, ideally without duplicates.
This would be nice for lots of things, such as extracting a subset of a dataset.
CONSTRUCT * WHERE { ?x name ?y; age ?a; ?p ?o.} FILTER { a 18 }
Tim
On 2013-09 -23, at 07:03, Andy Seaborne wrote:
DAWG did at one time work with result sets encoded in RDF for the testing
work.
As the WG progressed, it was clear that implementation of testing
was based on result set comparison, and an impl needed to grok the XML
results encoding anyway. Hence the need for the RDF form dwindled but it's
still there:
http://www.w3.org/2001/sw/DataAccess/tests/result-set.n3
Apache Jena will still produce it if you ask it nicely.
Andy
Re: SPARQL results in RDF
On 9/21/13 7:29 PM, Hugh Glaser wrote: (By the way, Kingsley, replying to this has caused me to notice that the rdfxml does not rapper very nicely - sorry to report! rapper: Error - URIfile:///home/hg/sparql.rdf:8 - property element 'solution' has multiple object node elements, skipping.) We'll get it sorted, the DBpedia instance has been in a little flux following the 3.9 release update. -- Regards, Kingsley Idehen Founder CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen smime.p7s Description: S/MIME Cryptographic Signature
Re: SPARQL results in RDF
On 9/21/13 6:32 PM, Jerven Bolleman wrote: If you want back result columns you use SELECT. If you want describe to the concept of result columns in RDF then you are on your own. I believe he wants to get a description of a SPARQL query solution (or result set). Basically, what you characterizes as being on your own :-) -- Regards, Kingsley Idehen Founder CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen smime.p7s Description: S/MIME Cryptographic Signature
SPARQL results in RDF
I was saying to someone the other day that it is bizarre and painful that you
can't get SPARQL result sets in RDF, or at least there isn't a standard
ontology for them.
But it looks like I was wrong.
http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.orgquery=select+distinct+*+where+{%3Fs+%3Fp+%3Fo}+LIMIT+100format=application%2Frdf%2Bxml
happily gives me what I was expecting, and also gives me NTriples if I want
them.
But the NS is http://www.w3.org/2005/sparql-results#
which doesn't give me what I was expecting (it is ordinary XML).
I did find what I think is the latest version, but it eschews RDF, and only
talks about XML, JSON, CSV and TSV formats.
Can anyone shed any light on where things are on all this please?
Cheers
Hugh
Re: SPARQL results in RDF
Hi Hugh, You can get results in RDF if you use CONSTRUCT -- which is basically a special case of SELECT that returns 3-tuples and uses set semantics (does not allow duplicates), but I imagine that you are aware of this. Returning RDF for SELECT where the result set consists in n-tuples where n != 3 is difficult because there is no direct way to represent it. Also problematic is that there *is* a concept of order in SPARQL query results while there is not with RDF. Also the use of bag semantics allowing duplicates which also does not really work with RDF. These, again, could be kludged with reification, but that is not very elegant. So most SELECT results are not directly representable in RDF. Cheers, -w
Re: SPARQL results in RDF
Many thanks, William, and for confirming so quickly. (And especially thanks for not telling me that CONSTRUCT does what I want!) I had suddenly got excited that RDF might actually be useable to represent something I wanted to represent, just like we tell other people :-) So it is all non-standard, as I suspected. Ah well, I'll go back to trying to work with XML stuff, instead of using my usual RDF tools :-( Very best Hugh On 21 Sep 2013, at 19:14, William Waites w...@styx.org wrote: Hi Hugh, You can get results in RDF if you use CONSTRUCT -- which is basically a special case of SELECT that returns 3-tuples and uses set semantics (does not allow duplicates), but I imagine that you are aware of this. Returning RDF for SELECT where the result set consists in n-tuples where n != 3 is difficult because there is no direct way to represent it. Also problematic is that there *is* a concept of order in SPARQL query results while there is not with RDF. Also the use of bag semantics allowing duplicates which also does not really work with RDF. These, again, could be kludged with reification, but that is not very elegant. So most SELECT results are not directly representable in RDF. Cheers, -w
Re: SPARQL results in RDF
On 9/21/13 2:38 PM, Hugh Glaser wrote: Many thanks, William, and for confirming so quickly. (And especially thanks for not telling me that CONSTRUCT does what I want!) I had suddenly got excited that RDF might actually be useable to represent something I wanted to represent, just like we tell other people :-) So it is all non-standard, as I suspected. Ah well, I'll go back to trying to work with XML stuff, instead of using my usual RDF tools :-( Very best Hugh Hugh, There's nothing wrong with expecting an RDF based description of a SPARQL query result. It's something that should have been part of the deal, that's why we implemented it in Virtuoso. Kingsley On 21 Sep 2013, at 19:14, William Waites w...@styx.org wrote: Hi Hugh, You can get results in RDF if you use CONSTRUCT -- which is basically a special case of SELECT that returns 3-tuples and uses set semantics (does not allow duplicates), but I imagine that you are aware of this. Returning RDF for SELECT where the result set consists in n-tuples where n != 3 is difficult because there is no direct way to represent it. Also problematic is that there *is* a concept of order in SPARQL query results while there is not with RDF. Also the use of bag semantics allowing duplicates which also does not really work with RDF. These, again, could be kludged with reification, but that is not very elegant. So most SELECT results are not directly representable in RDF. Cheers, -w -- Regards, Kingsley Idehen Founder CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen smime.p7s Description: S/MIME Cryptographic Signature
Re: SPARQL results in RDF
Hi Hugh, I think you disregarded the CONSTRUCT queries a bit to quickly. This is what you use when you want to get back triples. If you want back result columns you use SELECT. If you want describe to the concept of result columns in RDF then you are on your own. Maybe if you explain what you want to represent then we can have a bit more of an informed discussion. Regards, Jerven On Sep 21, 2013, at 8:38 PM, Hugh Glaser h...@ecs.soton.ac.uk wrote: Many thanks, William, and for confirming so quickly. (And especially thanks for not telling me that CONSTRUCT does what I want!) I had suddenly got excited that RDF might actually be useable to represent something I wanted to represent, just like we tell other people :-) So it is all non-standard, as I suspected. Ah well, I'll go back to trying to work with XML stuff, instead of using my usual RDF tools :-( Very best Hugh On 21 Sep 2013, at 19:14, William Waites w...@styx.org wrote: Hi Hugh, You can get results in RDF if you use CONSTRUCT -- which is basically a special case of SELECT that returns 3-tuples and uses set semantics (does not allow duplicates), but I imagine that you are aware of this. Returning RDF for SELECT where the result set consists in n-tuples where n != 3 is difficult because there is no direct way to represent it. Also problematic is that there *is* a concept of order in SPARQL query results while there is not with RDF. Also the use of bag semantics allowing duplicates which also does not really work with RDF. These, again, could be kludged with reification, but that is not very elegant. So most SELECT results are not directly representable in RDF. Cheers, -w --- Jerven Bollemanjerven.bolle...@isb-sib.ch SIB Swiss Institute of Bioinformatics Tel: +41 (0)22 379 58 85 CMU, rue Michel Servet 1 Fax: +41 (0)22 379 58 58 1211 Geneve 4, Switzerland www.isb-sib.ch - www.uniprot.org Follow us at https://twitter.com/#!/uniprot ---
Re: SPARQL results in RDF
Thanks Jerven, you may well be right!
SELECT DISTINCT * WHERE
{ ?s foo:bar ?o }
would do.
And things like
SELECT DISTINCT * WHERE
{ ?v1 foo:bar ?o . ?v1 ?p1 ?v2 . ?v2 ?p2 ?v3 }
and then probably get back an identifier for each result, so that I can find
out what are the values of the ?p* and ?v*
I think essentially the sort of thing that dbpedia/virtuoso is giving me.
(By the way, Kingsley, replying to this has caused me to notice that the rdfxml
does not rapper very nicely - sorry to report!
rapper: Error - URI file:///home/hg/sparql.rdf:8 - property element 'solution'
has multiple object node elements, skipping.)
Best
Hugh
On 21 Sep 2013, at 23:32, Jerven Bolleman jerven.bolle...@isb-sib.ch
wrote:
Hi Hugh,
I think you disregarded the CONSTRUCT queries a bit to quickly. This is what
you use when you want to get back triples.
If you want back result columns you use SELECT. If you want describe to the
concept of result columns in RDF then you are
on your own.
Maybe if you explain what you want to represent then we can have a bit more
of an informed discussion.
Regards,
Jerven
On Sep 21, 2013, at 8:38 PM, Hugh Glaser h...@ecs.soton.ac.uk wrote:
Many thanks, William, and for confirming so quickly.
(And especially thanks for not telling me that CONSTRUCT does what I want!)
I had suddenly got excited that RDF might actually be useable to represent
something I wanted to represent, just like we tell other people :-)
So it is all non-standard, as I suspected.
Ah well, I'll go back to trying to work with XML stuff, instead of using my
usual RDF tools :-(
Very best
Hugh
On 21 Sep 2013, at 19:14, William Waites w...@styx.org
wrote:
Hi Hugh,
You can get results in RDF if you use CONSTRUCT -- which is basically
a special case of SELECT that returns 3-tuples and uses set semantics
(does not allow duplicates), but I imagine that you are aware of this.
Returning RDF for SELECT where the result set consists in n-tuples
where n != 3 is difficult because there is no direct way to represent
it.
Also problematic is that there *is* a concept of order in SPARQL query
results while there is not with RDF.
Also the use of bag semantics allowing duplicates which also does not
really work with RDF.
These, again, could be kludged with reification, but that is not very
elegant.
So most SELECT results are not directly representable in RDF.
Cheers,
-w
---
Jerven Bollemanjerven.bolle...@isb-sib.ch
SIB Swiss Institute of Bioinformatics Tel: +41 (0)22 379 58 85
CMU, rue Michel Servet 1 Fax: +41 (0)22 379 58 58
1211 Geneve 4,
Switzerland www.isb-sib.ch - www.uniprot.org
Follow us at https://twitter.com/#!/uniprot
---
