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 17:13:23 +0200
Message-ID: <CAPugn7X1-mQ9j_31Dk3UrDizySSaOt_xn7qci22oSJKuzpq4gg@mail.gmail.com>
To: Martynas Jusevičius <martynas@atomgraph.com>
Cc: Olivier Rossel <olivier.rossel@gmail.com>, Gregory Williams <greg@evilfunhouse.com>, public-sparql-dev@w3.org
Hello

My concern (if any) is not about Jena, which is doing exactly what it is
supposed to do; my concern is with the SPARQL XML Result Format
recommendation, which do not allow any extension point.

I guess I could also define my own result format, and respond with either
the standard SPARQL result XML format, or my own "extended" result format,
based on content negociation.
The SPARQL protocol does not say explicitely that other types of results
formats are allowed besides SPARQL/XML, JSON, CSV or TSV, but I guess it
should be possible to do this.

"

The response body of a successful query operation with a 2XX response is
either:

   - a SPARQL Results Document in XML
   <http://www.w3.org/TR/rdf-sparql-XMLres/>, JSON
   <http://www.w3.org/TR/sparql11-results-json/>, or CSV/TSV
   <http://www.w3.org/TR/sparql11-results-csv-tsv/> format (for SPARQL
   Query forms SELECT <http://www.w3.org/2001/sw/DataAccess/rq23/#select>
   and ASK <http://www.w3.org/2001/sw/DataAccess/rq23/#ask>); or,
   - an RDF graph [RDF-CONCEPTS
   <https://www.w3.org/TR/2013/REC-sparql11-protocol-20130321/#rdf-concepts>]
   serialized, for example, in the RDF/XML syntax
   <http://www.w3.org/TR/rdf-syntax-grammar/> [RDF-XML
   <https://www.w3.org/TR/2013/REC-sparql11-protocol-20130321/#rdf-xml>],
   or an equivalent RDF graph serialization, for SPARQL Query forms DESCRIBE
   <http://www.w3.org/2001/sw/DataAccess/rq23/#describe> and CONSTRUCT
   <http://www.w3.org/2001/sw/DataAccess/rq23/#construct>).

The content type of the response to a successful query operation must be
the media type defined for the format of the response body.
"

Best Regards
Thomas


2018-07-11 15:25 GMT+02:00 Martynas Jusevičius <martynas@atomgraph.com>:

> Probably better to take Jena-specific questions to its own list:
> https://jena.apache.org/help_and_support/
>
> On Wed, Jul 11, 2018 at 2:49 PM, Thomas Francart
> <thomas.francart@sparna.fr> wrote:
> > Olivier, you have the reference to the code in the stacktrace excerpt I
> > posted. See
> > https://github.com/apache/jena/blob/0366da2c37b64978893897eba068fd
> b6b47ea782/jena-arq/src/main/java/org/apache/jena/riot/
> resultset/rw/ResultsStAX.java#L281
> >
> > Thomas
> >
> > 2018-07-11 14:46 GMT+02:00 Olivier Rossel <olivier.rossel@gmail.com>:
> >>
> >> Did you check which code in Jena triggers the schema validation? I don't
> >> see this as a so strong requirement.
> >>
> >> Le mer. 11 juil. 2018 à 14:37, Thomas Francart <
> thomas.francart@sparna.fr>
> >> a écrit :
> >>>
> >>> 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
> >
> >
> >
> >
> > --
> >
> > 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 15:14:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 15:14:10 UTC