Re: Comments on the Triple Patterns Fragments draft

Hi Kjetil,

Thanks for your comments!

> 1) RFC 2616 has been superseded by a number of new RFCs. I have yet to read 
> them all myself, but I think we should follow mnot's advice to not use it as 
> normative reference: https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead

Yeah, I considered that when I was writing the spec.
However, I don't know which ones of the new RFCs
are relevant and which ones are not.
Referring to all 6 of them seems rather cumbersome
when I just want to refer to HTTP 1.1 collectively.

Any thoughts on that?

> 2) And oh, BTW, here I go again: Since REST is expressedly not-just-HTTP 
> (and also, just think about the possibility that some may be able to 
> implement the spec not-just-HTTP) I think it is inappropriate to say that 
> "Triple pattern fragments servers are HTTP servers and hence MUST comply 
> with the HTTP specification [RFC2616]."
> It is in the interest of orthogonal specifications and unexpected reuse that 
> this is specified in terms of messages, and that HTTP is mentioned as an 
> implementation example. IMHO. :-) 

While I do wanted to specify an HTTP API in the first place
(that happens to conform to the REST architectural style),
I see a benefit in making this extensible.
On the other hand, specs should ensure interoperability.

Now, the good things is that the actual HTTP interface
only takes up a small part of the document.
I.e., true to the REST spirit [1], the majority of descriptive effort
is put here in the "media type", i.e., the fragment representation.
Section 4 is quite trivial at the moment.

What we could do is scope this more strictly,
i.e., explicitly specifying that Section 4 is for HTTP,
which allows us to specify other interfaces later on.
On the other hand, we might want to keep things simple
and just assume the regular Web protocol.

What do others think?

> 3) I really don't understand why it is required that CORS is given with a wildcard…?

Because we actually ran into this problem [2].
I had successfully tested the KBOdata triple pattern fragments server [3]
against a triple pattern fragments client running on a test server A,
and when I deployed it on production server B, it failed,
because the browser had cached the fragments with a CORS header for A.

The other option is "Vary: Access-Control-Allow-Origin" I presume.

> You're creating a huge minefield here 
> when user credentials are involved: Surely, TPFs are not intended just for 
> public resources?


Aren't there better ways to deal with authentication?

> I would be pretty strongly against the wildcard 
> requirement, and I would be more comfortable with a SHOULD rather than a 
> MUST with regards to the connection to CORS (for the record, I have a full 
> CORS implemention which is on by default in my module).

SHOULD is fine with me.
We could phrase it as SHOULD,
and is it is present and the value is not *,
there MUST be a Vary header then.
Would that be okay?

> 4) As I was implementing LDF, I found that if I have a { ?s ?p ?o . } 
> pattern, i.e. all variables, I would much rather point the user at a data 
> dump.

You're free to do that.
But why make this a special case?
Actually, that fragment *is* simply the data dump.

> My plan was to just throw a 400 in the first release, but subsequently put in 
> a Location header that points to the data dump. A redirect might be more 
> appropriate.

Exactly my thoughts; just a redirect would be nice.
But then again, is this case so bad?

Mostly, ?s ?p ?o will be asked for the metadata (or for the controls!);
just providing the first 100 triples and no paging could also be fine.
(Clients simply won't be able to solve * queries then.)

> I don't support paging for now. :-) Anyway, I think it would be 
> interesting to deal with what I suspect to be a rather common situation, 
> that a certain triple pattern is a resource with another URI already.

Could you clarify this?

> Anyway, great as a first draft, I look forward to implementing this!

Thanks very much, that's really great.
Make sure to announce it, so we can include it in the list of implementations!

Best,

Ruben

[1] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
[2] https://github.com/elephantbirdconsulting/netkernel-contribution/commit/8a0d7de780ebd36c14a81716515f55a0e4ad4221#diff-8dba554f024bc987ac7a44ce21e47181L89
[3] http://data.kbodata.be/fragments

Received on Monday, 21 July 2014 13:16:07 UTC