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

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

> > I'll edit it to 
> > 
> > [[
> > An LDPC MUST list all the resources created in it as a relation 
> > between the container and the created LDPR via
> > the rdf:member relation.
> > ]]
> > 
> > if that helps.
> 
> 'created' is one problem.  Think of the PUT/PATCH cases where existing resources are added to containers, they are not container-created ones. 
> 'LDPR' is another.  Members MAY be LDPRs.  "Think of the binaries!" ;-) 

In PUT/PATCH situations ( when you PUT/PATCH on an existing LDPR ) you are only creating #URLs , not creating new LDPRs. To be clear you are only adding relations to a graph. 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. 

The point of this is that if we don't want inferencing as per ISSUE-78 a client should be able to just do a search on 
SELECT ?m
WHERE { <> ldp:contains ?m } 
to find the results.  Not requiring inferencing measn it should be able to get partial results on an incomplete
stream. The more inferencing you require the more likely you need the full graph to get your results.

> We've opened, discussed, and resolved issues on those with your participation, no?  I'm not sensing intent to re-open those if I try to read between the lines, so please be explicit if you do intend to re-open them.  

I hope the first paragraph of my response above helps.

> Otherwise I'll assume this is just imprecision of the same ilk as omitting a final / in examples' URIs. 
> To move this along, I'll counter with this rewording : 
> 
> An LDPC MUST list all the resources in it as a relation between the container and the member resource via the rdf:member relation. 
> 
> That's my best guess at expressing your intent w/o restricting it to less than what the spec currently licenses. 
> 
> 
> > If you look further in Model 2, 
> 
> Ok, will loop back around on that when I get time.
> 
> > which he put together with you,
> 
> Another unfounded (and incorrect) assumption. 

Well sorry that was the claim made in the original email. I was going on that.
"Roger and I were discussing some examples to include in the primer and came
up with two slightly different models; "
http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0169.html

Ok clearly I made a bit of a jump there. Sorry.
> > Now issue-73 is not arguing that one should remove those rdf:membershipXXX
> > relations. 
> 
> That is my understanding (at least as of yesterday - not sure exactly when that became clear, so if I said otherwise before it's evidence of the conversation clarifying intent).  I actually helped explain that to someone else yesterday offline. 
> 

:-)  yes, building good standards is a lot of work ...

> 
> > I'll open an issue on
> > the misleading nameing of rdf:membershipXXX perhaps, so that these issues
> > remain clearly seperated. 
> 

That's ISSUE-79 ldp:contains now
http://www.w3.org/2012/ldp/track/issues/79

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

Social Web Architect
http://bblfish.net/