Re: What does "being a member" mean?

On 11 Nov 2013, at 23:20, Arnaud Le Hors <lehors@us.ibm.com> wrote:

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

I am not at all ignoring that. My definition contains 
an "or": 
 - either an LDPR is created through a POST
 - or if an LDPR is DELETEd the LDPC needs to remove the membership triples

(see http://www.w3.org/2012/ldp/wiki/Member )

[[
@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org//2000/01/rdf-schema#> .

ldp:member a rdf:Property;
  rdf:domain ldp:Container;
  rdf:range ldp:Resource; 
  rdfs:comment """
    An ldp:member of a ldp:Container is a LDPR which is created when a POST succeeds 
    on it (creating also the membership triples in the LDPC) or which when DELETED 
   removes the membership triples as specified by the "Linked Data Platform 1.0" spec.""" .
]]

I'd be happy to get better suggestions for a definition. The above seems to get close
to dealing with this prior creation problem. I wonder how people solve this with the file
system: after all you can copy a whole disk drive bit by bit and still have a directory 
structure on your file system, even though the directories where never created in the
given way. The Standards for the unix file system cannot be specifying the bytes on the disk
to make this work, they have to specify the interface, as each manufacturer could implement
the file system in completely different ways. I think we are doing the same here.

The other way of looking at things is that ldp:member is fundamental concept to the spec, 
just as ldp:Resource and ldp:Container are. 

In any case it is clear  that the spec ties creation,
deletion, editing even of an ldp:member LDPR to the LDPC 
( eg: membership triples of an LDPC need to change if the 
object of the  membership triples is edited in an ldp:member 
LDPR )

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

yes, and on the wiki I also have a definition of ldp:created 
http://www.w3.org/2012/ldp/wiki/Member  

[[
ldp:created a rdf:Property;
  rdf:domain ldp:Container;
  rdf:range ldp:Resource; 
  rdfs:comment """
     relates an ldp:Container to a LDPR which is created when a POST on the LDPC succeeds.
     (to decide: does DELETEing the LDPR makes the relation false? possible reason: because there would be no reference for the object of the relation. )
  """ . 
]]

These two definitions are very close to one another. 

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

Perhaps with the definition of ldp:member given above, and some work on the spec, we can
get the ldp:member to be the only relation needed. At least we should now be able
to discuss the differences.

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

Social Web Architect
http://bblfish.net/

Received on Tuesday, 12 November 2013 10:04:56 UTC