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

On 27 Mar 2014, at 15:08, Reto Gmür <reto@wymiwyg.com> wrote:

> 
> >> I think Henry makes a good case that the use of relative IRIs is the Right Thing here. It’s practical, it has precedent with the way HTML works, it’s webby, and it’s supported by the relevant RFCs.
> >
> > Ok, let's look into this:
> > - "practical": it requires hack on the client (throwaway URI to serialize against) and prevents framework to be effectively used on the server side. As for expressiveness it allows less flexibility (creating multiple resources in one post) as Antoine's proposal
> 
> It works just fine, without hacks, if client and server use RDF libraries that support relative IRIs.
> 
> But not when using tools which act on the RDF data model level. 
> 
> What LDP does is like if I ask people calling me to use SIP with H.264 as codec omitting the domain of the target. Something you can do with the right (hacker) library but certainly not with a normal phone.
> 
> 
> > - "it has precedent": I don't know of any protocol which requires the sender to send URIs that are relative to something that isn't defined yet. So I don't know where the precedent is.
> 
> There are protocols (WebDAV, APP) where messages with relative IRIs can be POSTed and it works just as expected.
> 
> Neither in WebDAV nor in APP I see where the client is required to send post IRIs relative to a yet undefined base (i.e. that the client couldn't also send as absolute URI). In Antoine's proposal you can use relative URIs but you don't have to. 

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.  An HTML document that was posted with a link <a href="">this doc</a>
would refer to the document created.  All of this just falls out naturally, out of concepts of
relative URLs and the act of creating a new resource for which the URL is not known in
advance, and which it is the responsibility of the server to create.

>  
> 
> > - "supported by the relevant RFCs": The RFC says the sender is responsible that the base URI can be established, this seems quite different from "the receiver defines a base URI" to me.And I haven't got an answer to  http://lists.w3.org/Archives/Public/public-ldp/2014Mar/0033.html yet.
> 
> If the protocol implemented by the server asserts that the server will choose an appropriate base IRI, then a client has met its responsibility by using that protocol.
> 
> It that is enough to satisfy the requirement I don't see how the earlier requirement "the base URI is defined by the context of the application" without also satisfying the requirement that the client is responsible. I think your interpretation of the requirement makes it pointless.

You have to read carefully:
"the clieet is responsible that the base URI can be established"

The client is responsible to figure out what?
  A: that the base URI _CAN_ be established.
 
It is NOT responsible 
  B:  that the base URI BE established

Those are two very different statements. The LDP spec says what an LDPC is. A client will know that
if a resource is an LDP then that resource WILL be able to establish the base URI. If a client knows that
a resource is an LDPC then it will have established that that resource CAN establish the base URI
even though the client still does not know what the base URI will be at the point of posting.

> 
> 
> >> Given all this, it appears to me that using relative IRIs to good effect in LDP is a step in the right direction.
> >
> > Well the goal of LDP is not to establish faits accomplis to push the RDF specification to adopt new features but in my understanding to apply the existing standards where possible. As for this use case there are alternatives that do not go beyond the current standard and they do not provide any disadvantage (except if you need the dirt) I don't think we should go beyond the existing standard.
> 
> As you have seen in this thread, one can argue in either direction by pointing to existing standards.
> 
> It comes down to a question whether you prefer to do the Right Thing vis-a-vis RDF Concepts or vis-a-vis RFCs 2616 and 3986.
> 
> You are arguing that it doesn't violate RFC3986 where I disagree, I didn't read any argument that any of the two RFCs you mention would suggest that the base URI should not be the resource against which the request is sent (as with Antoine's proposal) but that the base should be the resource the server has yet to create.
> 
> Cheers,
> Reto

Social Web Architect
http://bblfish.net/