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

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

See how it feels to have your efforts be misrepresented by others? ;-)
For what it's worth I was merely referring to you calling the status quo 
"a dead end" and "this mess", which I don't think is helpful.

Once more you claim that I don't take these issues seriously when I've 
always given every raised issue air time whether they were raised from you 
or anyone else, formally or not for that matter. Prove me wrong or quit 
the accusations at once.

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

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

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.

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

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

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 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.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group