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

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

From: <henry.story@bblfish.net>
Date: Mon, 31 Mar 2014 13:46:40 +0200
Cc: Reto Gmür <reto@wymiwyg.com>, "Kingsley (Uyi) Idehen" <kidehen@openlinksw.com>, "public-ldp@w3.org" <public-ldp@w3.org>
Message-Id: <DE399D73-5FBC-4DF7-87F1-C6AA5B9935FC@bblfish.net>
To: Soiland-Reyes Stian <soiland-reyes@cs.manchester.ac.uk>

On 31 Mar 2014, at 12:53, Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk> wrote:

> 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 )

The answer to this is not to develop a protocol to get agreement
over to-be-created URIs in advance, which would be a horrible slow
and an unecessary hack, but instead to refine the meaning of containers
so that creating a resource in an LDPC is predictable, and so that 
all the types of relative URIs can work.

I proposed this as ISSUE-50, and initially called this an ldp:iContainer
for an intuitive container.

    https://www.w3.org/2012/ldp/track/issues/50

This would also solve the problem as to how PUT should work.
Currently it is not at all clear where one can create a resource
with PUT. With ldp:iContainers it would be simple: if a resource
has a path such as http://ldpc.example/ then any PUT to a resource
whose URL fits the regex http://ldpc.example/[^/]* would be created in
the above LDPC. Indeed this could be extended to simply allow that any
successful put on a URL creates all the LDPCs ( always ending in a '/')
that form the path of the given created resource, each one ldp:containing
the other.


> *) 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
> accordingly.
> 
> 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
> 
> <app://3dc5a45a-38cf-4f7b-abfa-44bb3f6b8d66/>
> <http://www.w3.org/2000/01/rdf-schema#type>
> <http://example.com/Example> .

Given that relative URLs are meant exactly for this purpose, work in WebDAV with
all other formats, all this trying to dance around a non existent problem here
is completely ridiculous. The answer is instead to work with the architecture of the
web and to follow through on the consequences, such as defining an iContainer.

Henry

> 
> 
> 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
> 

Social Web Architect
http://bblfish.net/
Received on Monday, 31 March 2014 11:47:15 UTC

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