W3C home > Mailing lists > Public > public-ldp-wg@w3.org > February 2013

Re: The Intuitive/ Requirement

From: Raúl García Castro <rgarcia@fi.upm.es>
Date: Wed, 27 Feb 2013 10:09:18 +0100
Message-ID: <512DCD3E.5010702@fi.upm.es>
To: Henry Story <henry.story@bblfish.net>
CC: public-ldp-wg@w3.org
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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:45 UTC