Re: Issue 79 ldp:contains drafted

On 8 Jul 2013, at 22:21, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Guys, 
> As indicated in the closing related note of issue-79, the resolution at the meeting was: 
> 
> Resolution: Closed Issue-79, by adding that on creating a new member resource using POST, LDP servers MAY add a triple a la : <> ldp:created <newly_created_resource> 
> See https://www.w3.org/2013/meeting/ldp/2013-06-19#resolution_6 
> 
> This is what I expect to be reflected in the spec. 

I'd be happier with ldp:contains, given how things have been written out now.
The problem with ldp:created is that it may lead people to think that one should
keep listing ldp:created relations even when the resource has been deleted.

But I can open an issue to translate ldp:created to ldp:contains later.


> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 
> 
> 
> 
> From:        Henry Story <henry.story@bblfish.net> 
> To:        John Arwe/Poughkeepsie/IBM@IBMUS, 
> Cc:        public-ldp-wg@w3.org 
> Date:        07/08/2013 10:06 PM 
> Subject:        Re: Issue 79 ldp:contains drafted 
> 
> 
> 
> 
> 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/