W3C home > Mailing lists > Public > public-hydra@w3.org > July 2014

Re: Suggestion on URLs for triple pattern fragments

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Sat, 26 Jul 2014 07:40:54 -0700
Message-Id: <2B9113F1-9AA8-4710-950F-AFB04FAEC9BF@greggkellogg.net>
Cc: "john.walker" <john.walker@semaku.com>, "public-hydra@w3.org" <public-hydra@w3.org>
To: Ruben Verborgh <ruben.verborgh@ugent.be>
On Jul 26, 2014, at 4:42 AM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
> 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.

Also, if the API Documentation is retrieved using a format which supports prefixes, then the server is advertising the prefixes it understands. If the typical case is JSON-LD, then the context used with the documentation may be considered to be in effect.

Alternatively, we could use a mechanism like RDFa's initial context, and maintain a set of prefix definitions at a well-known location.


>> 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 14:41:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:42 UTC