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

Hi all,

On Mar 27, 2014, at 19:04, 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. 


Yes, agreed.  Relative URIs are an absolutely critical concept for any Linked Data system that can create or modify data.

We (Callimachus) were unable to come up with other reasonable ways to create data where the URI was not known a priori.  The alternative would seem to be to negotiate for a URI creation with a service and then modify it - but that has implications of its own which aren’t very nice, including a loss of efficiency, an extra round trip, possible contentions, and the need for a more complicated client.  Further, it doesn’t eliminate the need for relative URIs when modifying the content via a PUT unless the data is also negotiated and the URI filled in at runtime on the client. Yuck.

I’d like to think that LDP has accepted this pattern at this point.

Regards,
Dave
--
http://about.me/david_wood