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

Henry Story <henry.story@bblfish.net> wrote on 11/12/2013 06:49:31 AM:

> ...
> So a quick reason why your argument won't work: the blank nodes in 
> RDF don't group triples.
> Once the turtle is parsed the client can never see the difference 
> between a [] blank node
> and a _:b453 blank node. This means that the client would be in 
> exactly the same position,
> namely from the point of view of a client the 
> 
> <container> some:relation member1, member2;
>     ldp:membershipRule _:b234 .
> ....
> (pages and pages later)
> ....
> _:b234 ldp:membershipSubject <#something>
>        ldp:membershipPredicate o:paper;
>        ldp:membershipObject owl:sameAs .

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.

> 
> ----------------
> The introduction of the blank nodes was probably a mistake on my part.
> I was trying to jump a bit too far in one go.
> ---------------
> 
> The issue is really with how one infers ldp:member from the 
> membership predicates.
> I go into detail with this here:
>   http://www.w3.org/2012/ldp/wiki/MembershipInferencing

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

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.

> 
> In my proposal "2.2 think in terms of causality" there is no
> inferencing needed from the membership triples to the ldp:member 
> relations. Because:
> 
> 1. We publish all the ldp:member relations
> 2. we change the ldp:membershipXXX relations to ldp:creationXXX
> relations. 
> 
> the ldp:creationXXX relation specify a causal consequence of posting.
> They never remove the causal consequence of POST creating an ldp:member.
> They just add new consequences.  As a result there is a default 
behaviour
> without monotinicity problems.
> 
> A client could read a whole file and find all the ldp:members . If 
> at the end it
> finds the ldp:membershipXXX relations it will know what the consequence 
of 
> POSTing to  the container is. But it won't have an issue with any of the
> information it found.
> 
> I hope this helps. What I am trying to do here is show how there is 
something
> valuable in the membershipXXX relations. It's just we need to think of 
them
> not as inferencial statements, but as stating causal consequences 
ofcreation.
> That makes a lot of the rest much simpler.
> 
> Henry

Given the problem with the premise on what a member is I'm not sure it 
makes much sense to argue over the rest but if I understand this 
correctly, the proposal is essentially to 1) have a direct link using a 
built-in predicate, such as ldp:member, for ever member, and 2) forget the 
whole membershipxx stuff, or merely consider it as added sugar. While this 
would certainly simplify the spec, it would also fail to address several 
use cases that have been brought up and accepted by the WG. Unless I'm 
missing something this proposal isn't really new. We've been through that 
before and the WG did not agree to it. Discarding the whole membership 
stuff would make it impossible for people with existing vocabulary to take 
advantage of LDP without a complete revamp of their data. Having both 
would mean having two links per member, one with ldp:member and one with 
ldp:membershipPredicate or equivalent, doubling the number of triples 
required.

I know Henry is trying to help and I appreciate that but this all looks 
like throwing the baby with the bath water to me and quite frankly I don't 
see on what ground we would reopen this issue. I don't think the issues at 
hand justify such a lobotomy. Technically speaking we already are in Last 
Call and our scope of work is limited to addressing the comments we 
received and the issues we have uncovered. This is no time to doing a 
redesign and risking to introduce a whole new set of problems. I'll 
understand if you find this frustrating.

Best regards.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group