Re: Suggestion on URLs for triple pattern fragments

Hi John,

Thanks for taking the effort to write all of this down!

> I was thinking that it might be good to stick with existing conventions like the
> N-Triples encoded RDF value syntax (as used by Sesame) that expect the IRI to be
> enclosed in angle brackets, e.g., <http://example.org/bar>.

The reasoning for not having angular brackets is as follows:
- subjects can only be IRIs, so the angular brackets don't have an added value there
- predicates can only be IRIs, so the angular brackets don't have an added value there
- objects can be IRIs or literals, so there is a need to distinguish
If you look at it like that, it seems that IRIs are the "regular" case,
and literals are the "special" case.
So this is why I've reserved the simplest syntax for the regular case,
with only the need to differentiate for the complex case.

In particular, syntaxes like Turtle need the angular brackets,
because the prefixed names (e.g., foaf:name) is the common case.
Such cases do not occur with the HTTP interface, as prefixed names are not used.

Another drawback of angular brackets in URLs is that they need to be escaped anyway;
so there won't be a point at which you'll actually see the <URL> thing.

Note that servers are free to additionally support angular brackets, e.g.:
- http://data.linkeddatafragments.org/dbpedia?subject=http%3A%2F%2Fdbpedia.org%2Fresource%2FAustria
- http://data.linkeddatafragments.org/dbpedia?subject=%3Chttp%3A%2F%2Fdbpedia.org%2Fresource%2FAustria%3E

> Furthermore this could enable the use of CURIE syntax in triple pattern
> fragments URLs.

CURIEs can be supported with the existing mechanism, too:
- http://data.linkeddatafragments.org/dbpedia?subject=dbpedia%3AAustria
This is the case with RDFa too, BTW:
See also https://github.com/HydraCG/Specifications/issues/30#issuecomment-37763839

The drawback for supporting them is that you have to agree with the server on prefixes.

> Based on the example with URI template
> http://example.org/dataset?s={subject}&p={predicate}&o={object} a client could
> make requests like:
> 
> http://example.org/dataset?s=%3Chttp%3A%2F%2Fexample.org%2Fbar%3E
> http://example.org/dataset?p=rdf%3Atype
> http://example.org/dataset?p=rdf%3Atype&o=foaf%3APerson

So it's still possible for servers to _additionally_ support this, as indicated above.
However, we should remember that the clients we target are automated;
i.e., for them, constructing any of the above URIs is equally easy,
as they don't have to type out the characters like we do.

Humans are the reason I support other syntaxes as well;
my automated clients will always use the expanded forms.

> A server would somehow need to advertise which namespace prefixes it supports.
> One could even define a minimal set of prefixes that an implementation must
> support as part of the standard.

Just sending full URLs avoids that. Better for caching, too.

> I think adding support for CURIE syntax would help make it a lot easier to hack
> together the URL for a fragment and make them more human readable.

Agree; but I'm not convinced such support should be mandatory;
and I'm not convinced it needs a place in the spec (for machines).

Best,

Ruben

Received on Saturday, 26 July 2014 11:43:01 UTC