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/