Re: Keeping the simple case simple (was Re: optimizing container pages serialization to enable streaming)

On 11/14/2013 04:31 PM, Arnaud Le Hors wrote:
> Henry Story <henry.story@bblfish.net> wrote on 11/14/2013 10:37:28 AM:
>
>  > ...
>  > Anybody using english should be puzzeled that one can have a
>  > "membership triple" be any
>  > of the relations listed below. Even more surprising is that we
> don'thave the
>  > key ldp:member relation defined which most people need.
>  >
>  > > >
>  > > > How can { <#> :doesNotHaveAsMember <#y> }
>  > > >     or  { <#x> a :Photon . }
>  > > >     or  { <#z> loves #y }
>  > > >
>  > > > have anything to do with membership? Yet the spec allows any of
>  > > > those to be membership triples.
>  > > > ...
>  > ...
>
> Well, at least I think we're finally touching on the point of real
> contention here.
>
> What we have in the spec is as if we had decided that we will have a
> concept of group of people and to determine which people are part of the
> group - the members - we will specify the characteristics these people
> must have. Thus, I can define a group of people that are taller than 6',
> a group of people that have blond hair, or a group of people that wear a
> red tag on their chest. I can even define a group of people who claim
> not to want to be affiliated to any groups. And, yes, that means I can
> have a group whose members are the people who don't want to be members
> of any groups. I don't see any problems with this and think that's a
> very powerful mechanism.

Can you show an example where you define the "group of people that
have blond hair" and how it relates with ldp:membershipX?

> What I hear you saying is that you think this makes no sense. The only
> way we can define a group of people is by agreeing that we are going to
> tag every member of the group with a label that reads "member". That's
> the only way to define who's a member of a group. And then, if we want
> to recognize that they have other common characteristics that are worth
> recognizing at the level of the group we can do that too but, that's
> secondary.

So the notion of membership is defined as "belongs to some group". And
an LDPC is seen as something that manages members of such a group,
while an LDPR is something that complies with the group properties.
Am I right?

Alexandre.

> Furthermore you claim that people outside our circle can only
> comprehend your approach. Well, I don't agree with that and, based on
> the feedback I've received from giving several presentations on LDP at
> conferences, I have no reason to think people don't understand the
> concept of membership we have in the spec.
>
> Analogies always have their limits and I don't particularly care to push
> that one further but I think this illustrates the situation here.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group

Received on Thursday, 14 November 2013 22:07:14 UTC