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 <skw@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 <timbl@w3.org
>> <mailto:timbl@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 Ltd                        www.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
>

Received on Wednesday, 25 September 2013 10:27:42 UTC