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

On 14 Nov 2013, at 17:50, Arnaud Le Hors <lehors@us.ibm.com> wrote:

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

People reading the spec should find the usage of the words consistent with english.
We are writing a spec that is meant to be used beyond the small crowd present at its writing.

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't have 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. 
> > ...
> 
> 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? 

Did I say it was not legitimate? 

I was arguing that calling a "X is not a member of Y" statement a "membership triple" just clashes
with common sense. Any triple can be a "membership triple" it seems. 

The main requirement is that one be able to related a membership triple 
via a rule to the ldp:member relation, which is clearly a membership relation. 
Indeed I have just added to my definition 

ldp:member rdfs:subPropertyOf rdfs:member .

( replace ldp:member with ldp:manages if you prefer )

This shows that the "membership triples" are only called membership relation indirectly.  
Understanding this is already a big step forward.


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

I am just going back to simple plain english usage here. The current defintion of 
membership triples is just plain confusing. I am sure we can find a better term 
for these.

I propose a few:

 • implied triples
 • consequence triples
 • binding triples
 ( I am sure we can come up with something better )
 
The real issue here is to understand what their role is. I don't think
this group is clear about the role they have, and as a result the spec 
is difficult to read and topsy turvy.

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

Social Web Architect
http://bblfish.net/

Received on Thursday, 14 November 2013 18:38:01 UTC