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

I'm not sure there is much point to this discussion since we seem to be 
keep talking passed each other.

Henry Story <henry.story@bblfish.net> wrote on 11/14/2013 12:24:25 AM:

> > > Here is another example:
> > > 
> > > [[
> > > </shopping/cart/> a ldp:Container;
> > >     ldp:membershipSubject <#>;
> > >     ldp:membershipPredicate wish:shouldNotContain;
> > >     ldp:membershipObject foaf:primaryTopic.
> > > ]]
> > > 
> > > Instead of taking what I am saying as FUD, please look at it 
carefully,
> > > and you'll see I am offering you a solution and a simplification to 
the
> > > spec that also satisfies all the use cases, and even makes use of 
the
> > > membershipXXX rules in a way that is constructive. 
> > 
> > Again, I have read your proposal. But unlike you I don't think the
> above is a real problem. If people choose to shoot themselves in the
> foot they can indeed do so. 
> 
> Here is the definition from the spec of "membership triple"
> 
> [[
> 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: ...
> ]]
> 
> • The fact that the spec calls things "membership triples" to triples
> that have clearly nothing to do with membership, other than perhaps
> being deduced by an ldp:member relation that I am trying to define
> may have a lot to do with the problems people have in understanding the 
spec.

How does it have nothing to do with membership? If this is what we choose 
to define membership it has everything to do with membership, doesn't it?

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

Yes, it does, and what's the problem with that? For that matter I can 
actually imagine a perfectly legitimate use for the container you have in 
your previous example above: What if I want to have a container of all the 
resources that have a "wish:shouldNotContain" property?
You can't just say that in general that it makes no sense. Maybe it does, 
maybe it doesn't. This is clearly going to depend on the application.

It seems that you have a problem with the spec because the way it defines 
memberhip doesn't fit your view of what ought to be considered membership.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group