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

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

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


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.



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/