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

Hi Stian,

On 31 Mar 2014, at 11: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 )

This would only be unclear if you assume that there can be multiple different base URIs for different patterns of relative URIs. That would be madness. All relative URIs are interpreted relative to the same base.

Besides “” and “#fragment”, patterns such as “/“ and “/foo” can also be very useful.

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

The problem with that are not the relative URIs, but that the client makes unfounded guesses about the server’s behaviour.

I’d say that encouraging relative URIs makes clients *less likely* to engage in this kind of fragile guesswork, because it allows them to employ useful patterns like “#fragment” without having to guess the final URI.

> 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

Are you proposing this *only* for formats that don't support relative URIs?

Because otherwise, it’ll be even less clear what “/“ or “/foo” or “..” refer to, as it’s unclear whether they will be resolved against your hack URI, or the container URI, or the new item URI.

Best,
Richard




> 
> <app://3dc5a45a-38cf-4f7b-abfa-44bb3f6b8d66/>
> <http://www.w3.org/2000/01/rdf-schema#type>
> <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 12:59:51 UTC