- From: John Walker <john.walker@semaku.com>
- Date: Mon, 29 Jun 2015 14:03:07 +0200 (CEST)
- To: Ruben Verborgh <ruben.verborgh@ugent.be>
- Cc: public-linked-data-fragments@w3.org, Markus Lanthaler <markus.lanthaler@gmx.net>, Miel Vander Sande <Miel.VanderSande@UGent.be>
Hi Ruben,
> On June 29, 2015 at 11:41 AM Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
>
>
> 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.
Given the unclarity on semantics of RDF data sets and the meaning of a graph
name, that's definitely a loaded question :)
I would say that constructing an RDF dataset on the fly using FROM and FROM
NAMED over multiple TPFs would suffice, unless one wants to access the graph
names in a query.
Of course that can still be done in combination with FROM NAMED, but requires
the names of all the graphs (or TPFs) to be know up front so the query/dataset
can be constructed.
Out of interest how did the quad-based TPF interface work?
I assume it allows an extra graph parameter in the request e.g.
http://example.org/fragments{?s,p,o,g}
What was the response, triples or quads?
Also as a technical point I thought HDT only supports triples, so how was this
done on the backend?
I could imagine the quads interface would act like a proxy to access multiple
TPF interfaces.
John
Received on Monday, 29 June 2015 12:03:39 UTC