- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Mon, 29 Jun 2015 11:41:07 +0200
- To: John Walker <john.walker@semaku.com>
- Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, public-linked-data-fragments@w3.org, Miel Vander Sande <Miel.VanderSande@UGent.be>
Hi John, Thanks for the helpful remarks. > I'd have thought that using FROM and FROM NAMED would be a more natural fit than > SERVICE and enable everything that is needed. My thoughts also. (I never really liked SERVICE.) One issue though: what if we extend the Triple Pattern Fragments interface to use quads? It's not entirely hypothetical. Quads are part of RDF 1.1, so maybe we need them at some point. A student here at iMinds already used a quad-based TPF interface for time-sensitive Linked Data. At the moment, I don't think we should change the TPF spec to quads, but I can imagine a "quad" feature that servers/clients could support. > When I read §13.2 Specifying RDF Datasets [1] of SPARQL 1.1 Query Language it > states "If a query provides such a dataset description, then it is used in place > of any dataset that the query service would use if no dataset description is > provided in a query." > Also "The RDF dataset may also be specified in a SPARQL protocol request ..." That's very relevant, thanks for digging. > As such the current method using to execute federated queries is equivalent to > using multiple FROM clauses in the query (or multiple default-graph-uri > parameters in the request), whereby the query is executed over the RDF merge of > those graphs. > > I can appreciate that a TPF interface is not the same as an RDF dataset, so to > interpret as such would be non-standard, but certainly would be useful. I would thus add flags for that reason. So that the client has an on/off switch: "interpret FROM clauses as TPF interfaces” (or something like that). This slight deviation from the spec is then explicit. > Alternatively one can specify a new clause specifically for TPF interfaces, > similar to how Update introduces USING and USING NAMED. That would be a last resort for me, because then you also break compatibility with parsers (whereas a slight semantic deviation maintains compatibility with most things that exist). But it is indeed a possibility. Other thoughts? Ruben
Received on Monday, 29 June 2015 09:41:38 UTC