Re: The Intuitive/ Requirement

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).

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).
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.

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

Received on Wednesday, 27 February 2013 09:09:43 UTC