Re: Extending SPARQL XML result format

Would the JSON format be easier to extend without concern for fragile
clients?

Dan

On Wed, 11 Jul 2018, 08:15 Thomas Francart, <thomas.francart@sparna.fr>
wrote:

> 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/0366da2c37b64978893897eba068fdb6b47ea782/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:17:48 UTC