Re: Why restrict a resource to only one LDPC?

On 22 Apr 2013, at 04:10, "McFall, Gregory" <gregory.mcfall@pearson.com> wrote:

> Section 5.2.2 of http://www.w3.org/TR/2013/WD-ldp-20130307 states
> 
> The same resource, identified by its canonical URI, must be a member of only a single LDPC.  The same resource can not be a member of multiple LDPCs..
> 
> What is the reason for such a restriction?   
> It seems perfectly reasonable for a given Person resource to appear in two different containers such as:
> 
> http://example..com/resources/persons/
> and
> http://example.com/resources/corporations/292837/employees/

There should be no reason why  a resource cannot appear in two documents at 
once. But there is a reason why they should not be CONTAINED in two 
collections at once.  This is really the core of ISSUE-59 I believe, and why we need 
to retain the delete semantics, that we agreed at the first TPAC meeting [1].

An LDPC is a creator of URI resource pairs: of new URIs which refer to new
resources on which GET, POST, PUT, DELETE and PATCH actions can 
be done. An LDPC can create them, and is responsible for them, because
this is a name ownership issue. Just like owning the domain name university.example
allows the owner of that domain to delegate to different departments responsibility
for subnamespaces http://university.example/computing/ to the computer department
and http://university.example/philosophy/ to the philosophy department, and these in 
turn can create subsections such as http://university.example/philosophy/students/
and give partial responsibility of resources created therein to their students. 

These are the only types of things that LDP can really concern itself with being a protocol:
creation of resources on which GET/POST/PUT/DELETE/PATCH can be done.

So there is nothing stopping a GET/POST/DELETE/PATCH (GPPDP) resource 
being used in a different context. Let us say that we have

the LDPC 

   http://example..com/resources/persons/

create 

   http://example..com/resources/persons/joe

Now we have your other resource that you wished to think of as an
LDPC, but perhaps that is the mistake. Instead of 

   http://example.com/resources/corporations/292837/employees/

create

   http://example.com/resources/corporations/292837/employees

and this can include the triples 

   <#e> employee <http://example..com/resources/persons/joe>, <http://example..com/resources/persons/jack>, ...

That is what you want to relate here is not the GPPDP resource but a company
to its employees. And you do that by POSTing a document that speaks about the
company and the empoyees as above, by using PATCH or PUT to update it,
by using DELETE to remove the description if you ever need to. 

If you stop thinking about collections as the be all and end all of every RDF URI
creation then you'll see that you can do pretty much everything needed. I for
example showed this here:

  http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal

Henry


[1] http://www.w3.org/2012/ldp/track/issues/59

> 
> Regards,
> Greg McFall

Social Web Architect
http://bblfish.net/