Re: ldp-ISSUE-73 (rdf:member): LDPCs to list all their rdf:member [Linked Data Platform core]

> In PUT/PATCH situations ( when you PUT/PATCH on an existing LDPR ) 
> you are only creating #URLs , not creating new LDPRs. 

The spec defers to HTTP on PUT, which allows resources (LDPRs or not, the 
latter aka "binary") to be created.
We had explicit WG conversations about that.  FWIW, I'm not crazy about it 
but I don't see sufficient reason to constrain HTTP either.
So I don't agree with anything starting with "only" above.

> In PUT/PATCH situations ( when you PUT/PATCH on an existing LDPR ) 
> ... To be clear 
> you are only adding relations to a graph. 

This the usual case in my mind for them, but (because of PUT per above) 
not the "only" thing going on.
OTOH, *if* you start with an existing resource whose URL you want to 
include in the container's membership triples, I think PUT/PATCH are the 
ways to do that, and the spec reflects this today.  "out of band means" is 
always possible for membership triple modification too, and for that very 
reason we tend to ignore it, but I'll include it here just to be explicit.

> Only POST creates LDPRs 
> explicity. PUT may be able to create a new LDPR - but that is not 
> the preferred method of doing things at all. If a PUT did  makes a 
> new resource that were to be  an rdf:member of a container ( ie 
> ldp:contains(ed) as per ISSUE-79 ) then it should also be listed. 

I'm not going to stack assumptions on other raised issues.  I keep to the 
"membership triples" language specifically to avoid having to call out 
differences between resources created by the container and those listed as 
members (regardless of actual predicate choice) of the container, and to 
avoid tangling syntax with semantic intent.  If your intent is to say that 
all members of the container should be "listed" using a single predicate 
chosen a priori by the LDP spec (regardless of who/what/when/how the 
members were created), I can understand that but it is not _clearly_ what 
you are saying.  Every time you talk about create in relation to 
membership triples I cannot be sure we are talking about the same 
semantic.  The set of members listed in a container (membership triples) 
is a superset of the set of members created by said container; the two 
sets may be equal, or may not, depending upon options that LDP explicitly 
gives to implementations.



Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario