W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2013

Re: What does "being a member" mean?

From: Arnaud Le Hors <lehors@us.ibm.com>
Date: Wed, 13 Nov 2013 11:21:43 -0800
To: Henry Story <henry.story@bblfish.net>
Cc: Linked Data Platform WG <public-ldp-wg@w3.org>
Message-ID: <OF8FD02E23.0DD40A17-ON88257C22.00693F0B-88257C22.006A5C58@us.ibm.com>
Henry Story <henry.story@bblfish.net> wrote on 11/13/2013 09:34:24 AM:

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

You only say that because you have a different view of what a "member" is 
than what is currently in the spec.

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

If you want to introduce a different type of relationship than what is 
currently considered membership in the spec you ought to find a new name 
for it. Otherwise you're only making things worse by overloading the term.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group
Received on Wednesday, 13 November 2013 19:22:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:46 UTC