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

On 29 May 2013, at 22:52, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Henry Story <henry.story@bblfish.net> wrote on 05/29/2013 09:06:01 AM:
> 
> > ... 
> > The intent as you can see from the SPARQL example is that one use 
> > rdf:member as the relation.
> > 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.
> > ]] 
> 
> This reads as if this only concerns resources that were created via the container (presumably using POST) and doesn't necessarily apply to a member resource that would be added via PATCH. I don't think that's what you mean, is it?

I am not saying that the only thing that it must list are the members, but that it MUST list
those members that were created by the container. 

I can't sepak in general about relations added via a PATCH 
( one can only add relations not resources with a PATCH ).
It really depends on the server. Perhaps you are thinking 
that a server may not allow the adding of a relation 
{ <> rdf:member <m1231> } if that <m1231> does not exist? 
That would make sense.

> 
> > ...
> > If you look further in Model 2, which he put together with you,
> > you'll see that the </app/BugTracker/products/> container 
> > contains no members:
> > 

[fixed example below]

> > ~~~~~~~~~~~~
> > <http://example.org/app/BugTracker/products/> a ldp:Container;
> >  ldp:membershipSubject <http://example.org/app/BugTracker>;
> >  ldp:membershipPredicate bt:tracksProduct .
> > ~~~~~~~~~~~~
> > 
> > But that one is meant to guess from looking at the BugTracker resource that
> > members were created.
> > 
> > ~~~~~~~~~~~~
> > <http://example.org/app/BugTracker> a bt:BugTracker;
> >  tracksProduct </app/BugTracker/products/ProductA> ,
> >            </app/BugTracker/products/ProductB> ;
> >         hasBug </app/BugTracker/bugs/1> .
> > ~~~~~~~~~~~~ 
> 
> Saying that the container contains no members is incorrect. And there is no guessing involved to find otherwise. 
> 
> The membershipSubject of the container tells you the subject of the triples you need to look for and its membershipPredicate tells you the predicate of the triples you need to look for. 
> 
> So to find the members of the container you need to look for triples of the form: 
> membershipSubject membershipPredicate member 
> 
> Where membershipSubject membershipPredicate have been substituted to their appropriate value. 
> 
> The triples that match this pattern tell you which members the container contains. 

Could I phrase this then as your accepting the following rule


{ ?ldpc a ldp:Container;
           ldp:membershipPredicate ?p;
           ldp:membershipSubject ?s .
  ?s ?p ?o . } => { ?ldpc rdf:member ?o }

?

If so then we are starting to make explicity what is implicit in the spec.

Let us take the example from Model 2 of 
http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0169.html

~~~~~~GET http://example.org/app/BugTracker/products/ ~~~~~
<> a ldp:Container;
 ldp:membershipSubject <http://example.org/app/BugTracker>;
         ldp:membershipPredicate bt:tracksProduct .
~~~~~~~~~~~~~~~~~~~

Here the members of the container are not listed. So one has to do an HTTP
GET on another resource to find the content of this one. And when one receives
the content from <http://example.org/app/BugTracker> one has to merge those
two graphs, and then apply the rule above to get the rdf:member relations 
of the Container one is looking at.  

Would it not be simpler just to list all the rdf:member of the LDPC in 
<http://example.org/app/BugTracker/products/> and then if someone 
wants to find out what precise relations were created he go to the 
<http://example.org/app/BugTracker> relation, which he has to fetch
anyway if he wants more info on that resource?


> 
> > 
> > Now issue-73 is not arguing that one should remove those rdf:membershipXXX
> > relations. (Though they are seriously misleading.) I'll open an issue on
> > the misleading nameing of rdf:membershipXXX perhaps, so that these issues
> > remain clearly seperated.
> 
> That you think the names are misleading only shows that so far we have failed to properly convey what they are meant for. 
> 
> This again makes me wonder how much of this discussion is due to misunderstanding. If anything this shows that we at least need to clarify the intent! 

I think the construction is upside down, which is why it is complex. Make the LDPC
simple, and  you don't loose any functionality but things just will make more sense.

Henry


> Thanks.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 
> 

Social Web Architect
http://bblfish.net/

Received on Thursday, 30 May 2013 08:03:56 UTC