Re: Issue 79 ldp:contains drafted

On 8 Jul 2013, at 23:47, Steven Battle <steven.a.battle@gmail.com> wrote:

> Henry,
> I like this use of ldp:contains. Personally, I'd go further and permit the client to assert ldp:contains when it wishes to places an existing resource under the control of a container regardless of whether it was originally created by that container. Conversely, I'd allow ldp:contains to be deleted by the client, so as to remove an object from a container. Together these operations would support the use-case of moving a resource between containers. See UC&R 4.2.3. I believe this would be consistent with everything you'e written below.

So we agree with the following: 

ldp:contains a owl:InverseFunctionalProperty;
   rdfs:domain ldp:Container;
   rdfs:range xxx:InformationResource .

ie:  a resource an only be contained in one container.

I want to say 

  ldp:contains rdfs:subPropertyOf ldp:created .

but you don't. You want to tie containership only to deletion semantics.
Delete a resource and you MUST delete the relation from the LDPC that
was the subject of a true ldp:contains statement about it.

The problem I see pretty soon, is that when you go down that road, someone
is then going to question the owl:InverseFunctionalProperty part of your
requirement. They will say: why restrict things that much? Why not have
a contains relation that has many different subjects?  Then the deletion 
semantics will come up. Well, someone could then  argue: should a server not just be 
consistent in any case with relations like that. And then you are back
to rdf:member, perhaps with a completely generic rule: If you delete a resource 
then any triple that uses that URI or  #URIs declared within that resource
should  be deleted from every document on the server. But as you can see
this is much more ambitious.

I can argue for the  owl:InverseFunctionalProperty because I tie it to ldp:created .

What we are missing is the LDPC deletion piece that Tim Berners Lee suggested
we put in, but that we then removed because we felt recursive deletion was too
strong. I suggest we add a note to LDPC deletion:

   An ldp:Container can only be deleted if all it's ldp:created members are 
deleted. 

  You presumably would like to put this in terms of ldp:contains, with the 
possibility of having the ldp:contains relation moved.

  So in summary: the advantage of ldp:created or an ldp:contains based on it
is 
   + that it is very simple to implement
   + weak consistency requirements: The resource that creates a resource 
    is the only one that needs to track what happens when a resource is deleted.
    This is both easy to understand and easy to implement. 
   + If you add ISSUE-50 then you even make it easy for an admin to know
     where to search for container memberships: it is easy to find the URI 
    space responsible.

As soon as you move to more complex scenarios of moving deletion 
responsibility, you create new issues eg:
   - new issues that slowly move you from MUST language to  SHOULD or MAY 
    language
   - we have no protocolar way to specify how to move an ldp:contains
relation
  - It seems that these properties could easily be added in other ways, 
    such as by using rdfs:member with strong consistency requirements 
    across the server.

> Steve.
> 
> On 8 Jul 2013, at 21:05, Henry Story <henry.story@bblfish.net> wrote:
> 
>> 
>> On 8 Jul 2013, at 21:32, John Arwe <johnarwe@us.ibm.com> wrote:
>> 
>>> Henry, search for -79 you should get 2 hits. 
>> 
>> I see in this version of 
>> https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html
>> 
>> [[
>> 5.4.14 LDPCs that create new member resources may add triples to the container as part of member creation to reflect its factory role. LDP defines the ldp:contains predicate for this purpose. An LDPC that tracks members created through the LDPC must add a triple whose subject is the container's URI, whose predicate is ldp:contains, and whose object is the newly created member resource's URI; it may add other triples as well.
>> ]]
>> 
>> [[
>> 5.6.1 When a LDPC member resource originally created by the LDPC (for example, one whose representation was HTTP POST'd to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server is aware of the member's deletion (for example, the member is managed by the same server), the LDPC server must also remove it from the LDPC by removing the corresponding membership triple.
>> ]]
>> 
>> [[
>> 5.6.3 When the conditions in 5.6.1 hold, and the LDPC tracks member resources that it created using the ldp:contains predicate, the LDPC server must also remove the deleted member's ldp:contains triple.
>> ]]
>> 
>> I would suggest that a container is always aware of ldp:contains membership. Everything else should be rdfs:member : that is really the distinction between the two. In the case of a deleted ldp:contains resource the ?c ldp:contains ?r triple MUST be removed from the LDPC. In the case of ldp:member relations this is somewhere between a MAY and a SHOULD as you put it above. 
>> 
>>> 
>>> We did not discuss the case where an LDPC tracks its members via ldp:contains and a member is created through means outside of LDP... should there be a corresponding ldp:contains triple or not, and is that Should/Must/etc. 
>> 
>> The important thing about ldp:contains is that it should allow us to talk about things that the container created and that when a DELETE on
>> the resource is done, the resource is removed. 
>> 
>> Somehow I want to say that if the resource was created some other way that would have been indistinguishable
>> from a POST creation then this would come to the same thing. The reason to put this in terms of the HTTP Verbs is
>> that otherwise ldp:creation could end up meaning something like rdf:member causing this constant confusion. 
>> 
>>> At the moment I left things as we discussed and minuted them, so LDP is simply silent on this case. 
>> 
>> My guess is that the above is enough...
>> 
>> thanks for the work, 
>> 
>>    Henry
>> 
>>> est Regards, John
>>> 
>>> Voice US 845-435-9470  BluePages 
>>> Tivoli OSLC Lead - Show me the Scenario 
>>> 
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
> 

Social Web Architect
http://bblfish.net/