Re: The Intuitive/ Requirement

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?
Regards.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group


Henry Story <henry.story@bblfish.net> wrote on 02/26/2013 01:37:44 AM:

> From: Henry Story <henry.story@bblfish.net>
> To: public-ldp-wg@w3.org, 
> Date: 02/26/2013 01:39 AM
> Subject: The Intuitive/ Requirement
> 
> Hi all,
> 
>    following on the discussions on irc at yesterday's teleconf, I 
> propose what I call
> an intuitive requirement on LDP - which I believe we all have stated
> we accept. Having
> described it I propose naming LDPCs that follow this intuitive 
> requirement, and I then
> explain why this would be very helpful to clients. Finally I defend 
> this proposal 
> against certain types of criticims that usually surface when such a 
> proposal is made.
> ( I would also like to state that the argument I put forward below 
> helped me change
>  my mind on this since TPAC )
> 
> 1. The Requirement
> ------------------
> 
> It seems accepted by the group as a requirement on the LDP 
> specification, though it would be good to make it explicit, that LDP
> must allow implementations to follow what I would like to call the 
> intuitive requirement, nameley that:
> 
>   a. all the path components of URLs naming LDPCs end in a "/"
>   b. all paths compontents to Non LDPCs [1] are named with URIs not 
> ending in a "/" 
>   c. all resources created by an LDPC with URI U following the above
> constraints have a URL which is the concatenation of U with a string
> whose regep is [^/]+/? Ie a string with non slash characters, 
> optionally ending with a slash
> 
> Intuitively I am trying to capture the following:
>   - http://my.example/xxx/ is a container
>   - POSTing a non LDPC to it will create a resource with a name such as 
>     http://my.example/xxx/yoyo 
>   - POSTing an LDPC to it will create a resource with a name such as
>     http://my.example/xxx/yoyo/
> 
> This is not to say that representations of LDPCs should not contain 
> the statement
> <> a ldpc:Container . This is still very important.
> 
> 
> 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/
>