Re: The Intuitive/ Requirement

On 26 Feb 2013, at 16:40, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Hi Henry, 
> As I said on yesterday's call I think this is good practice and we could consider putting it in the deployment guide but what issue do you want to open? What use case does this address the current spec doesn't? 

Agreeing on good/best practice is already a very positive thing. I hope I helped make
this best practice more explicit in this thread. Should I post an issue to have this added
to the best practices document?

As pointed out in my mail below the current spec does not make it possible
to post a Turtle document with relative URLs and get what one wants. This is why 
I proposed that one could define a subclass of LDPCs which I called intuitive 
LDPCs, that  would allow this to work correctly. 

As Sandro pointed out yesterday we are not making much progress currently, probably
because our intuitions are aligned. So this is an attempt to help us here.

Apart from  adding this to the  best practices document one could perhaps 
define such a subclass of LDPCs in our ontology, for those that would like to use them
this would be very useful. It would follow Tim Berners Lee's suggstion at the TPAC
meeting to take relative URIs seriously.

So it looks like there are two things this thread could lead to
 - best practice entry
 - ontology improvement

> > [snip]
> > 2. Naming such a container 
> > --------------------------
> > 
> > I would like to argue next that it is advantageous for clients to 
> > know when they are confronted with an LDPC with such a property. To 
> > do this one could define in an intuitive ldp ontology, (whose prefix
> > I will call ldpi) the following definition:
> > 
> >  ldpi:Container owl:subClassOf ldp:Container;
> >     rdfs:comment """
> >      an ldpi:Container MUST have a URL by which the resoure can be 
> > interacted with that ends in a '/'. Call this url U .
> >      Creation of a non ldpi:Container inside such a container will 
> > result in a resource whose canonical URL is U concatenated with a 
> > non zero length string not containing a '/'. 
> >     Creation of an ldpi:Container inside such a container will 
> > result in a resource whose URL is U concatenated with a non zero 
> > length string not containing a '/' followed by a '/'
> >    """ .
> > 
> > 2.1 Better relative URI support
> > -------------------------------
> > 
> > The advantages to a client of knowing that it is dealing with an 
> > ldpi:Container is that it will know how relative URLs will behave, 
> > when POSTing content to it. So for example it will be possible to 
> > POST content such as
> > 
> >  <> a foaf:PersonalProfileDocument;
> >    foaf:primaryTopic <#i> .
> >  
> >  <#i> foaf:name "Tim";
> >       foaf:depiction <img/happyMe.jpg>;
> >       foaf:knows <../george/card#me> .
> > 
> > Without the knowledge that one is dealing with an ldpi:Container it 
> > would not be possible to post such content, since the URL of the 
> > resource created by such a container, and which will be used to 
> > resolve relative URLs of documents POSTed to it, could be a url with
> > a different directory hierarchy. To illustrate this imagine we had a
> > server that contained the following resources
> > 
> >   http://unintuitive.example/people/tim/
> >   http://unintuitive.example/people/tim/img/happyMe.jpg
> >   http://unintuitive.example/people/george/card
> > 
> > and the above Turtle were posted to 
> > 
> >   http://unintuitive.example/people/tim/
> > 
> > but the resulting resource were to be
> > 
> >   http://unintutive.example/people/xoxo/hehe/card
> > 
> > then none of the URIs in the POSTed turtle would resolve to 
> > the intended resources. 
> > 
> > On the other hand, if http://unintuitive.example/people/tim/ 
> > were to be an ldpi:Container then posting such a document would
> > always mean the intended links would resolve correctly.
> > 
> > 2.2 Generally more intuitive
> > ----------------------------
> > 
> >  Generally this would also just align with people's intuitions
> > in such a way as to make the concept of an ldpi:Container extreemly
> > easy to teach: it would tie in nicely with relative urls and directory
> > structures that developers are very familiar with
> > 
> > There may be other useful consequences, which I have not thought of right
> > now.
> > 
> > 
> > 3. Responses to expected criticism
> > ----------------------------------
> > 
> > URIs MUST be opaque
> > -------------------
> > 
> > It is usually argued that this is bad because URIs must be opaque.
> > 
> > But clearly that cannot be the case or else the above turtle would be
> > illegal and the URI specification would be mistaken  since it goes into
> > great detail on this subject, as for example in 
> >   http://tools.ietf.org/html/rfc3986#section-5.2.4
> > 
> > The importance of the opaqueness of URIs comes from semantics: one should
> > not deduce the meaning of a URI from its form.  But here we are not 
> > deducing semantics from the URI: the ldpi:Container needs to state that it
> > is an ldpi:Container for the above proposal to work. There is nothing that
> > disallows a resource to make claims about how interactions with it will
> > create new URIs. Indeed that is how HTML forms work.
> > 
> > I think this makes the point well enough.
> > 
> > I think it would be worth opening an issue on this.
> > 
> >    Henry
> > 
> > [1] ie the mysterious ldpx
> >     http://www.w3.org/2012/ldp/wiki/images/b/b5/LDP-RCX.pdf
> > 
> > Social Web Architect
> > http://bblfish.net/
> > 

Social Web Architect
http://bblfish.net/