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

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

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

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.

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

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.

I have adapted my defintion to be a little closer to yours above, so as 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.


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

(It is odd to call the relation member even in english
since the relation can be one such as foaf:likes which has nothing to do with rdfs:member or even more general 
membership.)

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

I hope the above responses have cleared your worries. Getting the ldp:member definition right should
not be a big issue. I am sure we can get to an agreement here.

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

That is proposal "list ldp:member explicitly & no ldp:membershipXXX triples"
http://www.w3.org/2012/ldp/wiki/MembershipInferencing#list_ldp:member_explicitly_.26_no_ldp:membershipXXX_triples

There are two other very different proposals listed there. 

> 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 don't see how it can fail to address any use cases. If you think of your rules as _if_and_only_if rules then you can go from ldp:member relations to all your membership triples using a construct which would look like this:

CONSTRUCT {
   ?subject ?relation ?object . 
} WHERE { 
    ?ldpc ldp:membershipSubject ?subject;
            ldp:membershipPredicate ?relation;
            ldp:membershipObject ?memberRelation;
            ldp:member ?resource .
 
   GRAPH ?resource {
      ?resource ?memberRelation ?object . 
   }
}

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

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

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.

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

Social Web Architect
http://bblfish.net/

Received on Wednesday, 13 November 2013 18:20:20 UTC