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

If LPD suggested an optional, alternative two-stage reource creation,
which is commonly recommended as a safer (idempotent ) way to create
resources, then you could also establish the URI in advance of
creating the resource.

(Sadly, I don't remember the name of this REST pattern)



POST http://example.com/lpd
# Empty body

HTTP/1.1 202 Accepted (?)
Location: http://example.com/lpd/1562



#  The resource does not yet exist:
# HEAD http://example.com/lpd/1562
#
# HTTP/1.1 404 Not Found



## Client generates RDF, with absolute URIs, using
<http://example.com/lpd/1562> and PUT to create.


PUT http://example.com/lpd/1562
Content-Type: text/turtle

<http:/example.com/lpd/1562> a ex:Example .

HTTP/1.1 201 Created


The server is of course free to return this resource in different
content types and using relative URIs.

GET http://example.com/lpd/1562
Accept: text/turtle

HTTP/1.1 200 OK

<> a ex:Example


The added advantage to this is that you now have a idempotent way to
create resources, where the client can be sure about the creation or
not. (POST transmission might fail while waiting for response). If the
POST fail mid-transmission, then the server might have wasted the
number /lpd/1562 (which still gives 404) as it would not be PUT to. If
the PUT fails, the client can simply try to PUT again, as PUT is
idempotent A dead-easy way for the server to do this is to just to
incremenet an atomic counter or to return a fresh UUID every time.




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:39:18 UTC