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

Re: Extending SPARQL XML result format

From: Martynas Jusevičius <martynas@atomgraph.com>
Date: Tue, 10 Jul 2018 11:32:32 +0200
Message-ID: <CAE35VmyhL59YBB8070HZqK3bhZFcRRLZH09VTHs4pO=NHOLeLg@mail.gmail.com>
To: Jörn Hees <j_hees@cs.uni-kl.de>
Cc: public-sparql-dev@w3.org, Thomas Francart <thomas.francart@sparna.fr>
SPARQL result format is XML and has namespaces, so I would expect
XML-aware parsers to simply ignore the XML elements outside of the
http://www.w3.org/2005/sparql-results# namespace. Isn't that so? XML
namespaces get a lot of hate, but such extensibility is exactly the
use case for them.

It's the JSON format that would have a bigger problem accommodating
custom elements.= IMO.

On Mon, Jul 9, 2018 at 8:08 PM, Jörn Hees <j_hees@cs.uni-kl.de> wrote:
> Hi,
>
>> On 9 Jul 2018, at 13:56, Olivier Rossel <olivier.rossel@gmail.com> wrote:
>>
>> Can't the HTTP headers contain such informations, instead of the XML resultSet ?
>
> I'd actually argue that some important meta information should always be part of the result document so that it's very visible and explicit.
> I remember getting into a lengthy discussion with Kingsley once (https://github.com/openlink/virtuoso-opensource/issues/112) because of Virtuoso's partial answers that are served as a 200 with an additional header.
> The problem is that end-users (and developers) are very likely to miss such crucial meta info.
>
> That said, I definitely agree that I had use-cases before in which i would've loved standardized meta info such as:
> - is the result complete (maybe "exhaustive" is a better term) or should it be treated as partial? (also think of open / closed world in federation  / sponging...)
> - did the server reach any boundaries during processing? (limits/timeouts explicit or implicit)
> - timing info: how long did the server need to generate the results? (independent of http transmission speed, maybe even in wall / cpu time to get a better measure of computational cost)
> - how busy was the server at the time of answering the query? (e.g., number of concurrent queries, cpu load)
> - query planner information (e.g., which execution order was chosen because of how many candidates)
>
> So maybe Thomas isn't really alone in his desire to add some meta info and the next result spec could be extended with some common meta info fields?
>
> Best,
> Jörn
>
>
Received on Tuesday, 10 July 2018 09:32:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 10 July 2018 09:32:57 UTC