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

On 31 May 2013, at 18:25, John Arwe <johnarwe@us.ibm.com> wrote:

> > 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. 

The language is tangled because in this group I have to fight the idea that foaf:knows expresses container
membership. But I think you get the gist of what I mean. If we accepted ISSUE-70 then we'd have a syntactic
way of making the distinction, and things would start being incredible simple. My feeling is that because of 
the idea that any relation can express membership of a container, we have drifted to a more and more
complicated spec, for no good reason.

> 
> 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario 
> 
> 

Social Web Architect
http://bblfish.net/