Re: 404 Re: Comments on the Triple Patterns Fragments draft

Hi Erik,

> an empty result set is not an error, at least not in the overwhelming majority of database-ish interaction schemes.

I'd argue that they are mostly thinking in an RPC-style.
That is: client says "execute this query", server says "200, I did it".

However, I don't consider triple pattern fragments really as querying;
I like to think of them more in a resource-oriented way:
client: "do you have the resource 'things that are aliens'?”
server: "404, don't have that one."

> (and i think it's rather strange to think of such a query as "an error the client has to fix").

"You asked for something I don't have, maybe somebody else has it.”

For example, Wiktionary doesn't have people, but DBpedia has:
- http://data.linkeddatafragments.org/wiktionary?predicate=rdf%3Atype&object=foaf%3APerson
- http://data.linkeddatafragments.org/dbpedia?predicate=rdf%3Atype&object=foaf%3APerson

> i think it would be much better to not treat it any differently than a query with a non-empty result.

What about the aforementioned cases 2 and 3 if we go that way?

2) With "empty => 404", checking for a simple triple pattern
requires simply a HEAD request, not a GET + body parsing.

3) With "empty => 404", triple pattern fragments
    can be implemented by a simple file server.


However, there are different ways to spec it though:
a) server MUST return 404 if the fragment is empty
b) server SHOULD return 404 if the fragment is empty
c) server MAY return 404 if the fragment is empty
d) server MUST NOT return 404 if the fragment is empty

Which one would you recommend?

Case 2 only works with option a, unless we change b or c to:
b'/c') server SHOULD/MAY return 404 if the fragment is empty,
    but MUST do so consistently, i.e., it either returns 404
    for all empty fragments, or returns 200 for all empty fragments.

Case 3 works with options a, b, c, but not d.

Best,

Ruben

Received on Wednesday, 30 July 2014 12:29:49 UTC