W3C home > Mailing lists > Public > public-sparql-dev@w3.org > July to September 2018

Re: Extending SPARQL XML result format

From: Thomas Francart <thomas.francart@sparna.fr>
Date: Wed, 11 Jul 2018 14:37:22 +0200
Message-ID: <CAPugn7Xr4ZYmkp6XMbdFHzAGO3zZc+6yhoo8JJYeWQgj-jQbPA@mail.gmail.com>
To: Gregory Williams <greg@evilfunhouse.com>
Cc: Olivier Rossel <olivier.rossel@gmail.com>, Martynas Jusevičius <martynas@atomgraph.com>, public-sparql-dev@w3.org
Hello

Trying to parse the following extended SPARQL result XML works in RDF4J but
fails in Jena.
Conclusion : SPARQL XML result format is not extensible from the standard
point of view, neither from a practical point of view if one of the major
RDF library fails in dealing with this (with reason, since the standard
does not allow it). Using other namespaces does not help. I will consider
using a "Link" header in the HTTP response, as suggested.

Best Regards
Thomas

XML :

<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
  <meta xmlns="http://sparna.fr/sparql-results-extension#">
    <timeMillis xmlns="http://sparna.fr/sparql-results-extension#">
123456</timeMillis>
  </meta>
  <head>
    <variable name="concept"/>
    <variable name="prefLabel"/>
  </head>
  <results>
    <result>
      <binding name="concept">
        <uri>http://vocabularies.unesco.org/thesaurus/concept9331</uri>
      </binding>
      <binding name="prefLabel">
        <literal xml:lang="en">Teacher education</literal>
      </binding>
    </result>
  </results>
</sparql>

Code with RDF4J :

TupleQueryResultParserRegistry.getInstance().get(TupleQueryResultFormat.SPARQL).get().getParser().parseQueryResult(new
FileInputStream("/path/to/sparql-result-extended.xml"));

Code with Jena :

ResultSetMgr.read(new FileInputStream("/path/to/sparql-result-extended.xml"),
ResultSetLang.SPARQLResultSetXML);

Exception :

Caused by: org.apache.jena.sparql.resultset.ResultSetException: skipToHead:
Unexpected tag: {http://sparna.fr/sparql-results-extension#}meta
    at
org.apache.jena.riot.resultset.rw.ResultsStAX.staxError(ResultsStAX.java:466)
    at
org.apache.jena.riot.resultset.rw.ResultsStAX.skipTo(ResultsStAX.java:282)





2018-07-09 19:36 GMT+02:00 Gregory Williams <greg@evilfunhouse.com>:

> FWIW, the hacky but standards compliant way I’ve dealt with this in the
> past is by using the link element with a data: URI.
>
> .greg
>
> On Jul 9, 2018, at 10:10 AM, Thomas Francart <thomas.francart@sparna.fr>
> wrote:
>
> Hello
>
> Thanks for your answers, here is slightly more extended description of the
> use-case : I am preparing a "SPARQL query mediator", that is a
> SPARQL-compatible service that will send the same query to multiple sources
> and aggregate the results into a single resultset. It can also articulate
> part of the query with other datasources (like if the SERVICE keyword was
> used). This involves preprocessings on the query, and post-processing on
> the result sets.
>
>    - I would like the SPARQL client to know if one of the source has
>    reached a LIMIT number of results (I plan to limit the number of results to
>    X for each source)
>    - I was also thinking about proving the "explain" of the query
>    processing if the SPARQL client asked for it (which sources were queried,
>    how the query got transformed, etc;)
>
> So the information could be pretty structured and does not seem to fit
> well in HTTP headers.
>
> Thanks for your ideas. I might try parsing with additionnal XML elements
> and let you know.
>
> Best Regards
> Thomas
>
>
> 2018-07-09 13:56 GMT+02:00 Olivier Rossel <olivier.rossel@gmail.com>:
>
>> Can't the HTTP headers contain such informations, instead of the XML
>> resultSet ?
>>
>> Le lun. 9 juil. 2018 à 13:38, Martynas Jusevičius <martynas@atomgraph.com>
>> a écrit :
>>
>>> Have you tried parsing?
>>>
>>> I think if you used XML elements in your own namespace, it should not
>>> be a problem.
>>>
>>> But probably better to start by explaining what your use case is,
>>> rather than the solution you think you need.
>>>
>>> On Mon, Jul 9, 2018 at 1:31 PM, Thomas Francart
>>> <thomas.francart@sparna.fr> wrote:
>>> > Hello
>>> >
>>> > I would like to extend a SPARQL XML result format with custom header
>>> > information; such as query execution time, warning if a search limit
>>> was
>>> > reached during query execution, or other king of meta-information
>>> about the
>>> > resultset.
>>> >
>>> > From the definition of the SPARQL XML result format at
>>> > https://www.w3.org/TR/rdf-sparql-XMLres/#schemas, I don't see the XML
>>> schema
>>> > allows this; there is no extension point. Could someone confirm ?
>>> >
>>> > In practice, would it be possible to have something like :
>>> >
>>> > <?xml version="1.0"?>
>>> > <sparql xmlns="http://www.w3.org/2005/sparql-results#">
>>> >
>>> >   <meta>
>>> >
>>> >     <!-- here put some meta information -->
>>> >
>>> >   </meta>
>>> >
>>> >
>>> >   <head>
>>> >
>>> >     ...
>>> >
>>> >   </head>
>>> >
>>> >   <results>
>>> >     ...
>>> >   </results>
>>> >
>>> > </sparql>
>>> >
>>> >
>>> >
>>> > Would SPARQL result parsers choke on this ? RDF4J ? Jena ?
>>> > Is anyone already using this technique ?
>>> >
>>> > Thanks
>>> > Thomas
>>> >
>>> > --
>>> >
>>> > Thomas Francart - SPARNA
>>> > Web de données | Architecture de l'information | Accès aux
>>> connaissances
>>> > blog : blog.sparna.fr, site : sparna.fr, linkedin :
>>> > fr.linkedin.com/in/thomasfrancart
>>> > tel :  +33 (0)6.71.11.25.97, skype : francartthomas
>>>
>>>
>
>
> --
>
> *Thomas Francart* -* SPARNA*
> Web de *données* | Architecture de l'*information* | Accès aux
> *connaissances*
> blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/
> thomasfrancart
> tel :  +33 (0)6.71.11.25.97, skype : francartthomas
>
>


-- 

*Thomas Francart* -* SPARNA*
Web de *données* | Architecture de l'*information* | Accès aux
*connaissances*
blog : blog.sparna.fr, site : sparna.fr, linkedin :
fr.linkedin.com/in/thomasfrancart
tel :  +33 (0)6.71.11.25.97, skype : francartthomas
Received on Wednesday, 11 July 2018 12:38:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 12:38:12 UTC