Re: Comments on the Triple Patterns Fragments draft

>> The most important HTTP-specific things are:
>> - 404 if the fragment (page) is empty
> 
> Hmmm…..

Please clarify your sentiment :-)

The reasons for "404 for empty" are as follows:

1) From the HTTP spec (the RFC2616 one):
    404 Not Found – The server has not found anything matching the Request-URI.
So if we ask for the fragment "?x rdf:type ex:Alien" (assuming aliens don't exist),
then the fragment is empty, i.e., no triples that match the selector were found.
In that sense, "the server has not found anything matching the Request-URI".
The resource "list of aliens" does not exist.

2) It can reduce bandwidth for simple triple checks;
we don't have to retrieve and parse a representation through GET,
we can just check if it exists with HEAD.
The following example shows such a very common case:
http://www.slideshare.net/RubenVerborgh/the-lonesome-lod-cloud/28
(The HEAD request happens on slide 40.)

3) It allows to implement the spec with a simple file-based server.
Just create files for all fragments that are non-empty;
the rest will result in 404 and that's it.
(See for instance https://github.com/lmatteis/ldstatic).


Now the argument against 1) would be:
"the fragment exists, it's just empty".
Could be, yes… but let's signal the emptiness with 404.

> 
>> - 404 if the selector is invalid (i.e. literal as subject)
> 
> Shouldn't that actually be a 400 Bad Request?

400 Bad Request = The request could not be understood
by the server due to malformed syntax. (RFC2616)

That's not really the case, I imagine the dialog as:
- client: Do you have triples with subject "1"^^xsd:integer?
- server: No, I have nothing. Doesn't exist.

>> Concretely, I have received an e-mail from somebody that said
>> there's insufficient information in the spec to implement a server,
>> while I am sure everything is in place.
> 
> What was (s)he missing? What was unclear?

I will contact the person and ask to move the discussion to the list.
Here's an extract from the mail:

>>> it would be helpful if, for example, in the "triple-pattern-fragments” documents, that is, in the protocol specification for servers, there were a passage equivalent to the discussion which corresponded to that about sparql query results from the “linked-data-fragments” document (http://www.hydra-cg.com/spec/latest/linked-data-fragments/#sparql-query-results) which detailed all alternative protocol requests and respective responses. the passage in the “linked-data-fragments” document is, as it stands, not sufficent to guide implementation.

My reply was:

>> I'm a bit surprised by this, as this is exactly the purpose of section 4 of the triple pattern fragments specification
>> (http://www.hydra-cg.com/spec/latest/triple-pattern-fragments/#server).
>> Could you perhaps tell me what kind of information is concretely missing?
>> 
>> Note that the specification is quite liberal, e.g., it will not tell you want kind of URL to use.
>> You are free (4.2.1) to choose:
>> - http://myserver.com/fragments?subject=S&predicate=P&object=O
>> - http://myserver.com/myapi/fragments.php?s=S&p=P&o=O
>> - http://myserver.com/S/P/O
>> - …
>> as long as you put the corresponding hypermedia control (3.4) in the representation.
>> I will add examples to the specification to clarify this.

As a response, I made the following clarifications:
https://github.com/HydraCG/Specifications/compare/b22972b...14305c4

>> However, non-experts perhaps expect to see much more HTTP stuff,
>> such as for example in the SPARQL protocol spec.
> 
> That might be true but it doesn't have to be normative. Adding examples
> helps a lot in these cases.

Actually, I recently got inspired by Many Sporny (http://manu.sporny.org/2014/json-ld-origins-2/):

>>>> The JSON-LD 1.0 specification starts out by primarily using examples to introduce key concepts. It starts at basics, assuming that the audience is a web developer with modest training, and builds its way up slowly into more advanced topics. The first 70% of the specification contains barely any normative/conformance language, but after reading it, you know what JSON-LD can do.

So I would add an introduction that puts things into context
and makes them understandable at a high level.

> I'm not a big fan of splitting things in too many documents. Don't be afraid
> to include lots of examples in the spec as necessary. Often, they are
> actually the most valuable part of a spec (despite being non-normative).

+1, will start doing that the coming days.

Ruben

Received on Wednesday, 30 July 2014 09:05:21 UTC