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

On 13 Nov 2013, at 22:06, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Henry Story <henry.story@bblfish.net> wrote on 11/13/2013 10:19:48 AM:
> 
> > ...
> > > You're right. The bnode trick, even if kept as anonymous, would 
> > only work with some serialization formats so, forget it. 
> > > Given that, I think we're stuck with the status quo: no default 
> > values, the simple case won't be as simple as we'd like. 
> > 
> > yes, the STATUS QUO is a dead end here, as I argue in 
> > http://www.w3.org/2012/ldp/wiki/MembershipInferencing
> > 
> > But in the last section I show a nice way out of this mess. 
> 
> Everyone is entitled to their own opinion and that includes you Henry but I don't see the mess you're referring to. At this point making such a statement is just spreading FUD. 

For the past two years I have been coding an Open Source LDP servers in Scala, 
and  building a company to help give life to it. 
When I make a criticism I am not spreading FUD, and I would like you to consider
the issues we are coming up a bit more seriously. Calling my contributions FUD 
does not help.

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.

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> :doesNotAsMember <#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.


> 
> > ...
> > > Per my earlier post in another thread the proposed SPARQL doesn't 
> > match what we currently have in the spec. Instead, it should be 
> > something like this: 
> > > 
> > > CONSTRUCT {
> > >  ?ldpc ldp:member ?member .
> > > } WHERE { 
> > >    ?ldpc ldp:membershipSubject ?subject;
> > >            ldp:membershipPredicate ?relation;
> > >            ldp:membershipObject ?memberRelation .
> > > 
> > >   ?subject ?relation ?member .
> > > 
> > >   GRAPH ?resource {
> > >      ?resource ?memberRelation ?member. 
> > >   }
> > > } 
> > 
> > ldp:member relates an ldp:Container to an ldp:Resource ( where I am 
> > hoping we can agree to have that URI refer to
> > LDPRs and Binaries - otherwise please let's agree on a term. I have 
> > updated the definition to cover that issue
> > http://www.w3.org/2012/ldp/wiki/Member )
> > 
> > So your CONSTRUCT rule won't do, because ?member could be an object 
> > that was not created by a POST. 
> 
> This is exactly what we agreed to have when we decided to add ldp:MembershipObject to the spec. And you supported that decision. 
> From: http://www.w3.org/2013/meeting/ldp/2013-06-19#resolution_9 
> 
> RESOLVED: Close ISSUE-72, add ldp:membershipObject to allow overriding the object of the membership triple that gets added when the container creates a new member. LDP constrains the behavior only in the case where the input document contains 0:1 triples whose predicate p is the ldp:membershipObject 's object. 

yes that was one good step forward.

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

> 
> > ...
> > 
> > If you look at the real proposal I put forward  "Think in terms of 
> > causal consequences instead of logical consequence"
> > you'll find me arguing for something that can really remove a lot of
> > the issues that keep popping up.
> > 
> > http://www.w3.org/2012/ldp/wiki/
> > MembershipInferencing#Think_in_terms_of_causal_consequence_instead_of_logical_consequence
> > 
> 
> I've read your proposal, Henry. That one as well as every other one and every email you've sent no matter how tiring this sometimes is. 
> 
> > As I see it the spec is not ready for last call. Trying to ignore 
> > issues is not going to make it go through faster. 
> > ...
> 
> Nobody suggested ignoring any issues and unless you can show evidence of the WG having done so, I'd like you to refrain from insinuating otherwise. It's not the first time that out of frustration you accuse me of trying to ignore issues. I'm ready to defend myself and believe the records can prove that this has not been the case. 
> 
> It is my role as chair to keep us moving. I realize this means I'm not always going to be the most popular guy in the WG and that's fine. But the reality is that we can't afford to aim for the perfect solution and need to accept something that is good enough, especially when there is never going to be a solution that everyone considers perfect. Remember that what we aim for is consensus around a solution that we can all *live* with, not necessarily love. 

Well I am putting arguments forward that I believe will improve the spec.
This working group has been trying for months now to come up with better names for the 
ldp:membershipXXX relations for the very reason that these are confusing.

> 
> Look, I know this process can get frustrating. Just remember that this is true for everyone. There is no reason to believe that anyone has bad intentions here. I certainly don't think that of you and would appreciate that you reciprocate. 

I am. I am proposing an improvement and clarifications to the spec:
1. defining ldp:member ( http://www.w3.org/2012/ldp/wiki/Member )
2. explaining what "membership triples" actuall are: description of the consequence of POSTing to a container
   see "Think in terms of causal consequence instead of logical consequence"
  

> 
> Thank you.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group

Social Web Architect
http://bblfish.net/

Received on Wednesday, 13 November 2013 22:14:07 UTC