Re: federated client released

Hi John,

> 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.

Exactly!

> Out of interest how did the quad-based TPF interface work?

Well, we haven't fully nailed it down yet.

> I assume it allows an extra graph parameter in the request e.g.
> http://example.org/fragments{?s,p,o,g}

Yes, that's already the base case.
(And in this context, it really sucks that RDF 1.1 didn't define rdf:graph,
 just like we already have rdf:subject and the others.)

However, one of the issues we have there is:
what is nothing is filled in for graph?
Does this mean "give anything" (as it does for the others?)
Or does it mean "give default"?
And in both cause, how do you express the other thing?

> What was the response, triples or quads?

Would need to be quads I guess.
With conneg, the "normal" TPF interface also supports quads,
and it uses a non-default graph for metadata/controls.
That way, they are easily separated from the data.

> Also as a technical point I thought HDT only supports triples, so how was this
> done on the backend?

Well, TPF is of course independent from HDT.
One option to implement this is multiple HDT files,
plus perhaps one separate HDT file to query graph names.
Or just implement it on top of something that is not HDT.

I'm not trying to be vague here, but can't say much yet
because the student's work still needs official grading etc.
The student who worked on it will become our colleague in August,
so by then, he'll be able to send you all of the details.

> I could imagine the quads interface would act like a proxy to access multiple
> TPF interfaces.

Exactly!
(Plus the one index then for graph name queries.)

Best,

Ruben

Received on Monday, 29 June 2015 12:29:10 UTC