Re: The Intuitive/ Requirement

On 27 Feb 2013, at 10:09, Raúl García Castro <rgarcia@fi.upm.es> wrote:

> El 26/02/13 10:37, Henry Story escribió:
>> 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/
>> 
> 
> Hi Henry,
> 
> I'm in favor of documenting the intuitive approach in a separate document, and of even having a separate ontology that extends the ldp one.
> 
> (I would prefer that the name of the intuitive container is not "Container". Only a difference of an 'i' in the namespace can cause confusion and mistakes.)
> 
> However, I think that the intuitive approach should be clearly documented including potential caveats such as the following.
> 
> The "requirement" disables the possibility of converting a resource into a container (I don't have a concrete use case but the specification currently does not limit this).

Yes, the same URI would not be both. 

But is this really a huge problem? There are probably a lot of ways of dealing with this.

1. A redirect.

For example where

 http://intuitive.example/people/george

redirects to

 http://intuitive.example/people/george/

2. A link  

 http://intuitive.example/people/george

to the new container

 <george/>

3. weakening of the restriction on ldpi:Container

I am not sure where this leads to, but at least for the use case of POSTing graphs with relative
URIs one could create a slightly less intuitive LDPC subclass call it ldpi2:Container

ldpi2:Container owl:subClassOf ldp:Container;
   rdfs:comment """
    POSTing content to an ldpi2:Container whose URL is cu MUST create a resource with a name
 matching the regexpression [^/]+, and whose URL is constructed as follows:
  - if cu ends with the '/' character then the result  cu + name 
  - if cu does not end with '/' then the result is cu + '/' + name 
  """ .

Now this means though that POSTing the graph

 POST /people/george HTTP/1.1
 Slug: card
 Content-Type: text/turtle

  <> a foaf:PersonalProfileDocument;
     :containedIn <.> .

onto the ldpi2:Container <http://i2.example/people/george>
would create the resource

  <http://i2.example/people/george/card>

but the <.> in the content then refers to 

  <http://i2.example/people/george/>

So it seems to me that this shows that Turtle and the URI definition have already made
some choices for us, namely that a container does end in a '/' , and that at best the
above show that </people/george> and </people/george/> should be identical . 


> Once we have aggregate and composite containers, things are not so intuitive because finding a URI that ends with '/' could refer to an aggregate or to a composite container (which have different behaviour).

yes, but I think this could just as well lead one to the opposite conclusion, namely that the
aggregation model presented recently is not intuitive. 

> Furthermore, when using the URI of an aggregate container when building the resource URI (http://my.example/xxx/yoyo), if the aggregate container is deleted and later someone tries to access the container URI (http://my.example/xxx/) it will fail.

I don't understand your point here.

> 
> Kind regards,
> 
> -- 
> 
> Dr. Raúl García Castro
> http://delicias.dia.fi.upm.es/~rgarcia/
> 
> Ontology Engineering Group
> Departamento de Inteligencia Artificial
> Universidad Politécnica de Madrid
> Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
> Phone: +34 91 336 36 70 - Fax: +34 91 352 48 19

Social Web Architect
http://bblfish.net/