Re: Comments on the Triple Patterns Fragments draft

Hi Kjetil,

> Yeah, I agree, cumbersome... Perhaps just ask the httpbis group?

Asked:
http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/1418.html
And answered by Roy Fielding:
http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/1419.html

Will refer to RFC7230.

> So, actually, what I had in mind is that you could implement a triple store 
> on top of TPFs... Just point it at a URI, and the store API 
> (RDF::Trine::Store, Jena, Sesame SAIL, etc) could figure out if it could use 
> it and then configure itself.

Here's more or less that idea implemented in Jena:
https://github.com/LinkedDataFragments/Client.Java

> it could be interesting to use a non-HTTP protocol and use 
> Andy Seaborne's RDF Binary using Trift:
> https://github.com/afs/rdf-thrift/blob/master/rdf-binary-thrift.md
> (lighter in weight than HDT)…

"lighter" also as in "faster"? Will need to check that!

>> The other option is "Vary: Access-Control-Allow-Origin" I presume.
> 
> Actually, I have experience with this, what does it do?

It tells the client and intermediaries that a cached response
may only be used if the value for the given headers in the new request
is the same as their value in the request of the cached response.

Example: given a client on domain D1, a client on domain D2, a server S.

If D1 requests a fragment from S, and it does not use *, the header will be:
    Access-Control-Allow-Origin: D1
This fragment will subsequently be cached by the browser (or some proxy server).
If D2 then requests the fragment, it will be retrieved from the cache with:
    Access-Control-Allow-Origin: D1
And now it breaks, because D1 ≠ D2.

However, if the headers are
    Access-Control-Allow-Origin: D1
    Vary: Access-Control-Allow-Origin
Then D2 will have to request a new fragment,
since the Access-Control-Allow-Origin is different from the cached one,
and "Vary" instructs us that it may only be reused
for identical values of "Access-Control-Allow-Origin".

With "Access-Control-Allow-Origin: *", none of this is necessary
and caching is more efficient.

>> Aren't there better ways to deal with authentication?
> 
> My general impression is that it is "strong ways, ways that users will 
> actually use, ways that developers will actually use, choose any two" ;-)

I've never seen authentication with Access-Control-Allow-Origin,
so I will just assume that this is the hard way then ;-)

>> But why make this a special case?
> 
> Because I'm not quite sure how I would do it… :-)

Paging, man… :-)
See also Olaf's response.

> A 400 to say that "it is 
> an error to try to download all my data this way" with Location header, is 
> that even allowed?

No mention of 4x codes for Location in RC2616:
http://tools.ietf.org/html/rfc2616#section-14.30
It probably will not be respected.

> Or a 301 perhaps to say that they shouldn't use that URI 
> again but not interrupt their flow, or perhaps a 303 since the data dump may 
> not have control information like the fragment, or…?

Just put the metadata/controls in the fragment?

Or a nice trick:
create an empty fragment with only metadata and controls,
and add a "next page" link, which points to the dump.
Not 100% correct (the next page wouldn't have metadata/controls)
but it would work.

> Besides what do you mean 
> by "first 100 triples", there is generally no concept of order in my RDF 
> (which is a reason I don't quite like the paging concept either, but I have 
> no better suggestion).

The current spec says you're free to define your own order,
as long as it is consistent.

> some will have implemented their Linked Data as something that returns 
> { Request-URI ?p ?o . } so in this case, it would be natural that this 
> fragment is just a redirect to Request-URI.

That would actually be perfectly fine, clients would support it.
Things like this are a main reason for me to use hypermedia,
i.e., the client makes no assumptions whatsoever
about the server's URI structure.

The limitation here is probably the expressivity of the hypermedia control,
i.e., you would not a control that says "if only ?s, then just dereference".
Not impossible, but just not supported by Hydra at the moment.
Note that you are free to redirect from
    http://example.org/dataset?s=http%3A%2F%2Fexample.org%2Fentities%2FJohn
to
    http://example.org/entities/John
and everything will work as expected.
However, this is only possible if the fragments server
also controls the domain on which the entities are placed;
i.e., this won't work is foaf:Person or rdf:type would be subjects.

Best,

Ruben

Received on Tuesday, 22 July 2014 20:19:10 UTC