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

On 29 May 2013, at 16:43, John Arwe <johnarwe@us.ibm.com> wrote:

> > 5.3.1 The representation of a LDPC must contain a set of triples 
> > with a consistent subject and predicate whose objects indicate 
> > members of the container. The subject of the triples may be the 
> > container itself or may be another resource (as in the example 
> > above). See also 5.2.3. 
> > 
> > But it does not say that 
> >  - all the members are there 
> 
> I think the implication is clear, but certainly no objection to making that completely explicit. 
> I realize that clarity is sometimes difficult to assess when you already know what it's supposed to say ;-) 
> 
> >  - that the relation be rdf:member 
> 
> As the main subject of a new issue, fair enough. 

The first line of the text on this issue says:

[[
An LDPC MUST list all the resources that were created in it with a POST as rdf:member .
]]

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

if that helps.

> 
> > It is clear from the examples Nandana put together with the bug 
> > tracking examples, that the LDPCs never 
> > listed any of the members themselves. Nobody seemed to think that 
> > was odd. See for example 
> > 
> >   http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0169.html 
> 
> Staring at the target of that link, I disagree.   I see it listed explicitly (I'm looking at model 1, just to anchor this discussion concretely).  Once (below) with /Bug1 as a member, another /ProductA as a member of a different container.
> 
> <http://example.org/app/BugTracker/ProductA> a ldp:Container, bt:Product;
> ldp:membershipPredicate bt:hasBug ;
> bt:hasBug <http://example.org/app/BugTracker/ProductA/Bug1> . 
> 
> 
That comes from Nandana's Model1 which he put together with you.
That is the example that does not use a ldp:membershipSubject, and so the problems are not so obvious.

> Now I can imagine you objecting with: since /Bug1 is an information resource, and a Bug *cannot* be an information resource, then the LDPC /ProductA never listed "the bug" as a member.  And my response is that absent more doc, you cannot know the server's intent or vocabulary designers' intent.  If the server intends /ProductA to be a container of bug reports, then it has definitely listed the LDPC's members.  You might dislike the choice of predicate names, members, etc, but it's up to the definer of the vocabulary and (depending on the freedom given at that level) possibly on the server implementation's behavior to say what bt:hasBug's behavior is. 
> 
> Whether or not I agree with your inferences (would make the same ones myself), using only what's written there you cannot magically divine intent.  You can (did) ask, Nandana clarified, things changed to improve separation, all fine and good.  You can argue, based on your inferences (amply demonstrated in the email archive), that things are wrong.  It does not mean the inferences are always right.  You of all people should recognize the danger of mixing the distinct classes together. 
> 
> Returning to the example you cited above, what makes you think "that the LDPCs never listed any of the members themselves", using _the definition of membership triples in the LDP spec_ ?  That seems to be a point of disconnect.
> 
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:

~~~~~~~~~~~~
<http://example.org> 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> .
~~~~~~~~~~~~

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.


Henry

> 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario 
> 
> 
> Henry Story <henry.story@bblfish.net> wrote on 05/29/2013 10:06:35 AM:
> 
> > From: Henry Story <henry.story@bblfish.net> 
> > To: John Arwe/Poughkeepsie/IBM@IBMUS, 
> > Cc: Linked Data Platform (LDP) Working Group <public-ldp-wg@w3.org> 
> > Date: 05/29/2013 10:07 AM 
> > Subject: Re: ldp-ISSUE-73 (rdf:member): LDPCs to list all their 
> > rdf:member [Linked   Data Platform core] 
> > 
> > On 29 May 2013, at 15:08, John Arwe <johnarwe@us.ibm.com> wrote: 
> > 
> > > yes. the language would need to be tuned. I was just trying to make 
> > 
> > "tuned"??  it completely changes the meaning for Pete's sake. 
> > 
> > If it completely changes the meaning of my proposed ISSUE-73, then 
> > you are tuning it wrong :-) 
> > 
> > The spec already requires all members to be listed - that is the 
> > intent and purpose of membership triples. 
> > 
> > Well it says this: 
> > 
> > 
> > I suggest something along the lines of: 
> > 
> > 5.3.1 The representation of a LDPC must contain a set of triples 
> > whose subject is the container, with rdf:member predicate and whose 
> > object is an  LDPRs that was either created by the container, or 
> > that acts as if it were created by the container. An LDPC SHOULD 
> > list all members of the container. 
> > 
> > The proposal as written says the container must list all members it 
> > created via rdfs:member ... which is (the created-only part at 
> > least) is not something the spec exactly covers today, so that's a 
> > reasonable point of discussion.  Today's spec covers a superset 
> > (created by the container + those added via other means). 
> > 
> > The main point of ISSUE-73 is that membership of a container be 
> > limited to the rdf:member property. The ldp:membershipXXX relations 
> > are doing something else entirely. They are just ways of specifying 
> > that certain relations will also be created when a member is created, 
> > as shown in the detailed example I put forward on the BugTracker 
> > 
> >   http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0218.html 
> > 
> > 
> > The "tuned" version then nets out to "remove ldp:membershipPredicate
> > and force the use of rdfs:member", correct? 
> > 
> > yes. 
> > 
> >    Just so we're clear about what we're talking about, rather than 
> > hiding it in a list of pro's. 
> > 
> > Best 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/

Received on Wednesday, 29 May 2013 16:06:36 UTC