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

Re: Extending SPARQL XML result format

From: Bijan Parsia <bijan.parsia@manchester.ac.uk>
Date: Wed, 11 Jul 2018 14:12:37 +0000
To: Karima Rafes <karima.rafes@gmail.com>
CC: Thomas Francart <thomas.francart@sparna.fr>, "public-sparql-dev@w3.org" <public-sparql-dev@w3.org>
Message-ID: <185098EE-17DB-4A47-888E-792A3CBC0AF0@manchester.ac.uk>
We could certainly fork the Schram to experiment with extensions.

On Jul 11, 2018, at 15:10, Karima Rafes <karima.rafes@gmail.com<mailto:karima.rafes@gmail.com>> wrote:

A need also very close...
At the next extended, we need to think to insert a place in the XML for the errors' messages of different SPARQL services for federated queries, with a mode verbore ;)

It's maybe a good idea to start to prepare a new version of SPARQL results...


2018-07-11 15:49 GMT+02:00 Bijan Parsia <bijan.parsia@manchester.ac.uk<mailto:bijan.parsia@manchester.ac.uk>>:
Other hacks:

1) Wrap the result in a custom format and strip it off before passing the results to a results processor
        Pro: pretty easy and clean
        Con: Clients which are unaware of this will bork hard

2) Dork the schema to allow for the meta data and dork the schema location to point to your dorked schema
        Pro: Lets you use the format of choice. Should work with most processors even validating ones
        Con: If the process makes assumptions about the PSVI you could get borkage.

I think link with datauri is likely to be the most robust if a bit unpleasant for e.g. inspecting the results by hand.
Received on Wednesday, 11 July 2018 14:13:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 14:13:04 UTC