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

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

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

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

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

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.

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