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

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

> Henry Story <henry.story@bblfish.net> wrote on 11/13/2013 02:13:33 PM:
> 
> > On 13 Nov 2013, at 22:06, Arnaud Le Hors <lehors@us.ibm.com> wrote:
> 
> > The issues I wrote up are in the first section of the wiki:
> > http://www.w3.org/2012/ldp/wiki/MembershipInferencing
> > 
> > I think I can generate quite a lot more, because they are all related to 
> > the same underlying problem. ( I found a new one below )
> > 
> > 
> > > Steve proposed to reintroduce some default value to simplify the 
> > spec a bit. We can agree not to do that and move on. There is no 
> > dead end to speak of. 
> > 
> > Then you are back to breaking RDF again. 
> 
> The only way for me to make sense of what you just wrote is that you misread what I wrote. I'm saying that we can agree not to reintroduce any default values and move on. How is that breaking RDF? 

reintroducing a default value would get us back to breaking RDF again.
It's good that we agree not to do that.

> 
> > 
> > I proposed a way out of all your difficulties in the last
> > section of "Think in terms of causal consequence instead of logical 
> > consequence"
> > http://www.w3.org/2012/ldp/wiki/MembershipInferencing
> > 
> > It requires us to rething what these "membership triples": these
> > so clearly have nothing to do with membership since you could have 
> > { <#x> :doesNotHaveAsMember <#y> } 
> > as a "membership triple" .
> > 
> > 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 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.
• How can they be anything than "membership triples" other than because they are
the the consequences of the ldp:membershipXXX triples and some statements about ldp:member
as I am defining it?
• The group has been having an ongoing discussion about naming those relations
for the past month or more, and that does not reveal a problem?
• The fact that the spec is getting more and more complex because of corner
cases to do with interpretation of membership semantics is not a problem?

All of those are ongoing issues in this group. How can this not be an issue?
If something is shooting the spec in the foot it is these issues I am addressing
in the membership wiki http://www.w3.org/2012/ldp/wiki/MembershipInferencing


> 
> > ...
> > The problem is not with that but with the missing ldp:member which cannot be
> > deduced from only statements between objects, as I argue in the 
> > MembershipInferencing wiki 
> > http://www.w3.org/2012/ldp/wiki/MembershipInferencing
> > 
> > The problem is that the spec is getting clients to have to deduce 
> > from relations between
> > things to which documents those relations were written in, which is 
> > the exact opposite of
> > what common sense and logic tells us is possible. If I take a 
> > picture of a Jane walking down the street
> > the picture shows that she is walking down the street, but the 
> > statement that Jane is walking
> > down the street says nothing about which pictures if any could show 
> > her to be doing so. 
> > Well the membership triples are making statements about the world, 
> > and from that one cannot deduce
> > which documents those statements find themselves without 
> > presupposing those statements to be somehow
> > written in the relations themselves. Either that or the reasoning is
> > completely tied to the documents
> > and so not RDF at all.
> > 
> > But having said that let me repeat again that you can find a way out
> > of that problem
> > by going to the section "Think in terms of causal consequence 
> > instead of logical consequence"
> > http://www.w3.org/2012/ldp/wiki/
> > MembershipInferencing#Think_in_terms_of_causal_consequence_instead_of_logical_consequence
> > 
> > 
> > > 
> > > > 
> > > > I have adapted my defintion to be a little closer to yours 
> > above, soas to make
> > > > it easier to see this point:
> > > > 
> > > > CONSTRUCT {
> > > >   ?ldpc ldp:member ?member .
> > > > } WHERE { 
> > > >     ?ldpc ldp:membershipSubject ?subject;
> > > >           ldp:membershipPredicate ?relation;
> > > >           ldp:membershipObject ?memberRelation .
> > > > 
> > > >    ?subject ?relation ?object .
> > > >  
> > > >    GRAPH ?resource {
> > > >       ?resource ?memberRelation ?object . 
> > > >    }
> > > > }
> > > > 
> > > > The membership triples can relate objects that are physical 
> > things to other 
> > > > objects that are physical things. Like people to cats. But an 
> > ldp:member only
> > > > relates informatin resources to other information resources.
> > > > 
> > > 
> > > I totally understand your point but what I'm saying is that what 
> > you're proposing is to redefine what the members of a container are.
> > I do not see any reason to do that and I fear that such a change 
> > would require a major overhaul of the spec to change every reference
> > to "member". As I said in my earlier email, if you want to introduce
> > a new type of relationship in the spec, you ought to use a new name for it. 
> > 
> > You have "membership triples" that have nothing to do with membership at all. 
> 
> This is only true if you choose not to take what we have as defining membership. 

Not at all. I did not redefine "membership triple" to show that this is a problem.

I only introduced a new term. If you wish to call it ldp:manages it would not 
change anything to the fact that you can have { <#> :doesNotHaveAsMember <#y> } as
a membership triples as defined currently by the spec.


> 
> > I am proposing ldp:member which is not defined in the ontology or 
> > anywhere in the spec
> > in such a way that it fills a gap that our applications need for the
> > reasons given in the 
> > wiki.
> > 
> > > 
> > > > 
> > > > > 
> > > > > Then in the first section it reads: 
> > > > > "But when it is not such a URI it is not possible to find the member. " 
> > > > > 
> > > > > This is incorrect. The member is <urn:isbn:0470396792>. What is 
> > > > true, is that the resource that was created as the result of the 
> > > > POST isn't listed in the container. 
> > > > 
> > > >  <urn:isbn:0470396792> is the "member" not the ldp:member. The 
> > > > distinction is important, and in fact the whole
> > > > of LDP is built on it.
> > > 
> > > Are you seriously suggesting that we introduce ldp:member in the 
> > spec and have it be different from what the spec calls "member"? How
> > would that possibly help clarify the spec? Why would we do that when
> > we could simply use a different name? Maybe you can call it 
> > ldp:linkedResource, ldp:relatedResource, or ldp:ManagedResource if 
> > you want, since that seems to be what people have been referring to.
> > Just don't use the one name we are already using for something else. 
> > 
> > Well if you want to use ldp:manages, why not?
> > But as argued above "membership triple" seems to be the one that is 
> > seriously misnamed. 
> > ... 
> 
> I honestly don't understand your reasoning. You start by choosing a different definition of what membership is about and then you go into saying the spec is broken because it doesn't match that definition. I don't agree with that. 

I just wrote above that "you can call it ldp:manages" if you wish. Or we
can take Alexandre Bertails and extend ldp:created to mean that - but then we
would have other confusions created that would harm the point I am trying to 
make.

The idea that introducing a new URI ldp:member/ldp:manages is creating the confusion
in the spec and that my arguments are based on that is to have completely misunderstood
at what level the argument is about. My argument is not at the syntactic level, but
at the logical level. 

> 
> I don't personally have any preconceived opinion of what ought to be considered membership in general. My position is merely based on our history. 
> 
> This whole work started from the agreement that it was useful to define a form of container from which various related resources could be found. The spec we started from allowed one to do so by specifying how to find the triples that list the members of a container using membershipSubject and membershipPredicate. As far as I recall, no one argued that this made no sense. We had ample discussions on what membership meant related to creation and deletion but not on what the members were. This was accepted as what defines membership. 
> 
> To address the use cases of the various WG members we extended the model and introduced two additional variables/parameters, namely membershipPredicateInverse and membershipObject. I don't understand why this should lead us to declare this no longer defines what the members of a container are. 

 The group started from an agreement that it was useful to define a form of container from which members could be found
that was related to the RESTful actions that were defined in the initial IBM specification which got stuck last
October in discussions about wether we should use it as a basis, and which I helped push through as to get going. 
At that point I had not carefully looked at the membershipXXX relations that existed, and neither had many others.

Notice it was quite easy to explain why people thought of them as membership relations because these had default values
for a relation that was rdfs:member. So anyone who did not look at that part of the spec would not notice this problem.

But all of this history does not make the problem go away. The spec is defining things to be "membership relations" of
a LDPC even if the relation can say that something is a member of some other LDPCs, or a relation that has nothing
to do with membership, not as defined by me, but even has nothing to do with rdfs:member at all, which is the
highest level membership relation in rdf.

> 
> It is true that the addition of membershipObject had the side effect of making it possible to end up with a container that does not have a link to the document that gets created via POST. But Alexandre agreed that ldp:created gives him that and the only problem with it right now is that it is optional. 
> 
> Again, how does that justify changing what's considered membership? 

I am not changing what is considered membership. I am defining a new term ldp:member/manages .
At the same time I am pointing out that "membership triples" is confusing. 
I can open a seperate issue that "membership triples" is confusing without mentioning ldp:member.

> I suggest we leave the membership stuff alone and fix the problem we have. If you want to rename ldp:created to something more general that's fine with me.

We can try ldp:manages if you wish for the moment. ldp:created only gets at
half the problem. I'd like to have the two distinctions so that we can speak clearly
on this list and not fall into word games constantly.

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

Social Web Architect
http://bblfish.net/

Received on Thursday, 14 November 2013 08:24:59 UTC