Re: What does "being a member" mean?

We've heard, repeatedly, that the notion of membership is not bound to 
whether a resource is created by POSTing to an LDPC. Steve Speicher said 
it again today on the call:
"there are a number of existing data structures that, when I bring them 
online [in LDP], I didn't create anything "

John added:
"I thought that "membership triples" today were there to tell clients how 
to enumerate members of the container; does not matter how they came to be 
members (post, put,... , out of band)."

I don't think ignoring that is helpful.

As I said on the call, there are two sets of resources we talk about: the 
resources listed as members of an LDPC, using the membership predicate 
stuff, and the resources that are created by POSTing to an LDPC. The 
latter is included in the former but is not necessarily the same.

Resources that have been created by other means may be listed as members, 
in which case they would be part of the first set and not the second one.

The first set can be found via ldp:containsRelation (formerly called 
ldp:membershipPredicate).
The second one can be found via ldp:created.

I understand that ldp:created is currently a MAY and this means in some 
cases you can't quite get the second set right. I'm fine with looking at 
that problem.

Regards.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group


Henry Story <henry.story@bblfish.net> wrote on 11/11/2013 10:45:54 AM:

> From: Henry Story <henry.story@bblfish.net>
> To: Steve Battle <steve.battle@sysemia.co.uk>, 
> Cc: Alexandre Bertails <bertails@w3.org>, Linked Data Platform WG 
> <public-ldp-wg@w3.org>
> Date: 11/11/2013 10:46 AM
> Subject: Re: What does "being a member" mean?
> 
> 
> On 11 Nov 2013, at 19:22, Henry Story <henry.story@bblfish.net> wrote:
> 
> > 
> > On 11 Nov 2013, at 18:36, Steve Battle <steve.battle@sysemia.co.uk> 
wrote:
> > 
> >> I thought that "being an LDPR" meant "being a member of an LDPC".
> >> 
> >> Questions about Barbers and people who don't shave themselves
> >> notwithstanding, there's at least one LDPC, and hence an LDPR by
> >> implication, that is not a member of a LDPC.
> > 
> > This shows that the notion of an LDPR is logically prior to that 
> > of membership, and that LDPCs are causally prior to their members .
> > 
> > Anyway there are some definitions in the spec:
> > 
> > [[
> > Linked Data Platform Container (LDPC)
> > An LDPR representing a collection of membership triples which is 
> uniquely identified by a URI that responds to client requests for 
> creation, modification, and enumeration of its members.
> > 
> > Membership triples
> > A set of triples in an LDPC's state that lists its members. A 
> container's membership triples all have one of the following patterns:
> > membership-constant-URI   membership-predicate   member-URI
> > member-URI   membership-predicate   membership-constant-URI
> > The difference between the two is simply which position member-URI
> occupies, which is usually driven by the choice of membership-
> predicate. Most predicates have a natural forward direction inherent
> in their name, and existing vocabularies contain useful examples 
> that read naturally in each direction. rdfs:member and 
> dcterms:isPartOf are representative examples.
> > Each container exposes properties that allow clients to determine 
> which pattern it uses, what the actual membership-predicate and 
> membership-constant-URI values are, and (for containers that allow 
> the creation of new members) what value is used for the member-URI 
> based on the client's input to the creation process.
> > ]]
> > 
> > The spec then tells us how to "create, modify and enumerate" 
> members. But the spec does this by 
> > describing actions on LDPRs using GET, POST and DELETE. GET 
> enumerates the members, DELETE deletes
> > a member, POST creates one.
> > 
> > What is missing in the spec is the definition of the ldp:member 
> relation that relates the LDPC to
> > the LDPRs on which the above actions can be exercised to change 
> the membership triples. We can define
> > it and thereby make things much clearer. Let me propose the 
> following ldp:member definition
> > 
> > ldp:member a rdf:Property;
> >   ldp:domain ldp:Container;
> >   ldp:range ldp:Resource; 
> >   ldp:comment """
> >     An ldp:member of a ldp:Container is a LDOR which is created 
> when a POST succeeds 
> >     on it (creates via the membership triples) or which when 
> DELETED removes the membership 
> >     triples."""
> > 
> > ldp:created refs:subPropertyOf ldp:member;
> >   ldp:comment "relates an ldp:Container to a LDPR which is created
> when a POST succeeds" .
> > 
> > The ldp:member relation is useful to make it clear what the LDPRs 
> on which to act
> > to change the membership triples.
> > 
> > If we can agree on this then we can have clearer conversations 
perhaps.
> 
> I put up the definition, with some obvious fixes, in the wiki here:
> 
>   http://www.w3.org/2012/ldp/wiki/Member
> 
> So that we can re-use it in later discussions.
> 
> > 
> > Henry
> > 
> >> 
> >> Steve.
> >> 
> >> -----Original Message-----
> >> From: Alexandre Bertails [mailto:bertails@w3.org]
> >> Sent: 11 November 2013 16:49
> >> To: Linked Data Platform WG
> >> Subject: What does "being a member" mean?
> >> 
> >> Guys,
> >> 
> >> I think we have a problem with semantics :-)
> >> 
> >> Can somebody tell me what "being a member" means?
> >> 
> >> I thought that "being an LDPR" meant "being a member of an LDPC".
> >> 
> >> How is that different from "being managed by an LDPC"? And from
> >> "ldp:created"?
> >> 
> >> Are the LDP interactions driven by "being a member" or by "being an
> >> LDPC/LDPR"?
> >> 
> >> Is the notion of membership achieved through membershipXXX? If not, 
what's
> >> the name for the feature captured by the membershipXXX relations?
> >> 
> >> If a POST succeed, does it mean that the new resource is created, or
> >> managed, or a member of the LDPC? What about a binary resource then, 
as
> >> it's currently not considered as an LDPC?
> >> 
> >> Sorry if those are obvious questions, but when I hear the 
conversations we
> >> have in the meetings, it looks pretty confused :-/
> >> 
> >> Alexandre.
> >> 
> > 
> > Social Web Architect
> > http://bblfish.net/
> 
> Social Web Architect
> http://bblfish.net/
> 
> 

Received on Monday, 11 November 2013 22:20:58 UTC