Re: What does "being a member" mean?

On 13 Nov 2013, at 00:32, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Henry Story <henry.story@bblfish.net> wrote:
> 
> > 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 ) 
> 
> I think there is a problem with this proposal in that it limits members to being LDPRs. This doesn't match what we have in the spec today and what we've been talking about all along. 
> 
> The spec clearly defines that an LDPR is an "HTTP resource whose state is represented in RDF" and although this definition now needs updating to match the more complex membership mechanism we've developed I think the intent of what the members of a container appear in the definition of an LDPC: "An LDPR representing a collection of same-subject, same-predicate triples which is uniquely identified by a URI that responds to client requests for creation, modification, and enumeration of its members." See http://www.w3.org/TR/2013/WD-ldp-20130730/#terminology 

That's not a big problem. We can define the class of things that are both LDPRs and Binaries, and I can rewrite 
the definition. 

The word Resource is very general, and is used in Web Architecture to refer in a very generic way. So that if one
had to find something that was both an LDPR and a Binary what word would one use? 

I would suggest calling the superclass ldp:Resource, and finding a name for the Graph resources, perhaps 
ldp:RDFResource . The definition then would hold as is.

So the question is now: how do we call the set of LDPRs and LDP binaries?


> 
> So, as the spec stands, the members of a container are the resources listed as members. These are the resources listed using the membershipXXX stuff. Some of these may have been created by POSTing to the container some may not. Some may be LDPRs, some may not (binaries for example). 
> 
> In the case where one uses ldp:insertedContentRelation the member is the resource found using the object of that property in the POSTed resource. This actually was the whole point of adding this feature to the spec. Roger wanted to make zaza the cat the member of his container as opposed to the information resource that talks about zaza, 

yes, but that is what is making the spec so hard to read, and use for clients. The membershipXXX speak as if
they were ways of getting the members of a container, whereas they can in fact set relations on any type
of resource whatsoever even if these have no relation to rdf:member-ship whatsoever.

In fact that is why I propose we define ldp:member as above. If we can find a term for the superclass of LDPRs
and LDPBinaries then my definition will work fine.

> 
> Going back to Alexandre's orginal question, in his example below this means <urn:isbn:0470396792> is the member: 
> >     $ GET http://example.com/shopping/__cart/
> >     <http://example.com/shopping/cart/>
> >
> >     [[
> >     </shopping/cart/> a ldp:Container;
> >         ldp:containerResource <#>;
> >         ldp:containsRelation order:contains;
> >         ldp:insertedContentRelation foaf:primaryTopic.
> >
> >     <#> order:contains <urn:isbn:0470396792>
> >     ]] 
> 
> Similarly, we agreed that when POSTing a binary to a container, it is the binary that is listed as a member, and metadata associated to it is to be found from the binary. See section 5.9.2: http://www.w3.org/TR/2013/WD-ldp-20130730/#ldpc-5_9_2 (side note: I wonder why this is under OPTIONS rather than POST, looks like a bug to me). 

yes.

> 
> Given that, I don't see a problem with what figuring out what the members of a container are. 

You are using member in a different way from the intended definition of ldp:member.  Of course if member means
any relation to some thing then there is no difficulty finding the member. But we who are implementing servers
and clients are looking not for those relations as our main use case, but for what I am trying to get at
with ldp:member .

> Now, I understand Alexandre and others also want to be able to find the resources that are created as a result of a POST, including in the above example. I think that's a fair request but I don't think that requires revisiting what being a member means. 

It just requires us to define ldp:member . No need to revisit what the english word "member" means, or what the spec currently
means by membership triples.


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

Social Web Architect
http://bblfish.net/

Received on Wednesday, 13 November 2013 17:34:57 UTC