W3C home > Mailing lists > Public > public-ldp@w3.org > March 2014

Re: Practical issues arising from the "null relative URIs"-hack

From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
Date: Mon, 31 Mar 2014 13:53:06 +0300
Message-ID: <CAPRnXtk=PdaYPPgO6NR5d_iTGAF4GykBVQnJPCFJ_qdNYezhFw@mail.gmail.com>
To: Reto Gmür <reto@wymiwyg.com>
Cc: Kingsley Idehen <kidehen@openlinksw.com>, "public-ldp@w3.org" <public-ldp@w3.org>
One would also have to be very careful about creating the relative
URIs, because effectively only safe relative reference to use is ""
and "#anchors". It is unclear if a relative reference like "../other"
should be interpreted with the base URI according to the URI you POST
to (e.g. http://example.com/coll1 *) ) or the final resource that is
created (unknown: http://example.com/col1/item5,
http://example.com/col1/items/5, http://example.com/col1/items/5 or
even http://other.example.com/5 )

*) If the base URI is the resource you post to, then you have no way
in the posted document to refer to the not-yet-existing resource

Therefore any hint of using relative URI references would have to be
very specific about only using "" and "#anchors", and would easily
become quite fragile if clients do the 'wrong hack' and try to
preemptively guess the final URI in advance and relativize

In many ways it might be better to specifically recommend the details
of the hack - say require the use of a fresh  app:// base URI [
http://www.w3.org/TR/app-uri/ ]  that is also declared in the header:

POST http://example.com/coll1
Content-Location : app://3dc5a45a-38cf-4f7b-abfa-44bb3f6b8d66/
Content-Type: text/nquads ## Now supported

<http://example.com/Example> .

Note, HTTP 1.1 says:

  The meaning of the Content-Location header in PUT or POST requests
is undefined; servers are free to ignore it in those cases.

On 31 March 2014 12:51, Reto Gmür <reto@wymiwyg.com> wrote:
> On Fri, Mar 28, 2014 at 2:42 PM, Kingsley Idehen <kidehen@openlinksw.com>
> wrote:
>> On 3/28/14 7:02 AM, Reto Gmür wrote:
>> On Fri, Mar 28, 2014 at 12:04 AM, Kingsley Idehen <kidehen@openlinksw.com>
>> wrote:
>>> On 3/27/14 4:42 PM, Reto Gmür wrote:
>>>> If you consider RFC5995 ( Using POST to Add Members to WebDAV )
>>>> http://tools.ietf.org/html/rfc5995
>>>> you need only consider that it does not say anything about relative URIs
>>>> to understand
>>>> that because it says nothing it does exactly what we are proposing. If
>>>> you were to use
>>>> a RFC5995 compliant server to POST some Turtle with relative URIs in it,
>>>> then you'd
>>>> get exactly the LDP intended result. A turtle document that was posted
>>>> with a <> URI would refer
>>>> to the document created.
>>> Granted. The same happens if you send an email with text/turtle
>>> content-type. Still, a bit far fetched to see this use as the intended
>>> design or even as to see  an established design pattern in that, imho.
>>> This is an established design pattern, that's poorly understood. Relative
>>> URIs are really a major route to taking a lot of confusion and tedium out of
>>> Linked Data exploitation.
>> I doubt about the this being established (given that it violates RFC3986).
>> But maybe you're right and relative URIs would be elegant and powerful. But
>> then they should be in the RDF data model rather than having LDP breaking
>> the abstraction. (I'm a bit afraid relative URIs in RDF might also add more
>> confusion by people expecting the URIs so be relative to the position of the
>> resource in the graph).
>> What is need to create the body of a POST request using RDF toolkits with
>> the current design:
>>   var i = new
>> NamedResource("http://some.temporary.uri/that/must/not/be/used/elsewere/in/representation")
>>   graph.addTriple(i, RDFS.descrition, "This is the resource that will be
>> created")
>>   ..add more triples
>>   var turtleToPost =
>> graph.serializeAsTurtleWithBaseUri("http://some.temporary.uri/that/must/not/be/used/elsewere/in/representation")
>> In my opinion, using this throwaway URI and hoping it doesn't escape from
>> the context of our code is a dirty hack.
>> If the RDF would support relative URIs things would be straight forward:
>>   var i = new NamedResource("") //Currently illegal and not supported by
>> most toolkits!!!
>>   graph.addTriple(i, RDFS.descrition, "This is the resource that will be
>> created")
>>   ..add more triples
>>   var turtleToPost = graph.serializeAsTurtle()
>> Of course if RDF would support relative URIs we could use any
>> serialization and also the problem I initially illustrated would be gone.
>> The current question is not about using relative URIs or not but if the
>> spec should be defined in terms of RDF or in terms of some particular
>> serializations. The latter prevents RDF tools from being used, at least from
>> being used  in a straight forward way.
>> Cheers,
>> Reto
>> To be clearer, an actual RDF graph isn't comprised or relative URIs. Those
>> URIs have to be absolute. Put differently, the final product of an RDF
>> document processing pipeline has to be a graph comprised of absolute URIs.
> The problem is that with RDF tools you cannot create (unless you use a
> throwaway URI hack as described above) what needs to be posted against an
> LDP server.
>> There is still a subtle conflation of notation for describing an RDF graph
>> and the actual serialization that manifests when said has been processed by
>> a processor. For instance, a Turtle doc with relative URIs is basically an
>> RDF description that a processor will transform into a final RDF document
>> that's comprised of a graph with absolute URIs.
>  That's why I think that relying on turtle documents with undefined
> based-URI conflicts with the turtle spec that says: "A Turtle document
> defines an RDF graph composed of set of RDF triples"
> Cheers,
> Reto
>> If I import data into Virtuoso (for instance) from a Turtle doc comprised
>> of relative URIs, the RDF graph that manifests in the DBMS isn't comprised
>> of relative URIs. It can't be.
>> [1] http://bit.ly/1fWnvCP -- Linked Data Deployment Tutorial based on
>> Relative URIs using Turtle.
>> --
>> Regards,
>> Kingsley Idehen	
>> Founder & CEO
>> OpenLink Software
>> Company Web: http://www.openlinksw.com
>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter Profile: https://twitter.com/kidehen
>> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
>> LinkedIn Profile: http://www.linkedin.com/in/kidehen

Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718
Received on Monday, 31 March 2014 10:53:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:16:37 UTC