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

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

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.

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