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

Re: Extending SPARQL XML result format

From: Jörn Hees <j_hees@cs.uni-kl.de>
Date: Mon, 9 Jul 2018 20:08:17 +0200
Cc: Thomas Francart <thomas.francart@sparna.fr>
Message-Id: <771AE0F1-5F34-42C2-8CA1-E4969685602C@cs.uni-kl.de>
To: public-sparql-dev@w3.org
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 Monday, 9 July 2018 18:08:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 July 2018 18:08:45 UTC