Re: ISSUE-75 (was ISSUE-71: second bug tracking example)

I changed the subject because this is more about ISSUE-75 than ISSUE-71.

Alexandre Bertails <bertails@w3.org> wrote on 05/30/2013 02:40:25 PM:

> On 05/30/2013 05:21 PM, Arnaud Le Hors wrote:
> > Alexandre Bertails <bertails@w3.org> wrote on 05/30/2013 01:58:50 PM:
> >
> >  > ...
> >  > > This being said, I think there are ways you can address the
> > monotonicity
> >  > > issue and keep membershipPredicate. We could require
> > membershipPredicate
> >  > > to be specified rather than have a default value for one, 
couldn't we?
> >  >
> >  > You cannot assume that the RDF triples are ordered and that you'll 
see
> >  > the membershipPredicate before it's used. That means that the
> >  > semantics for the predicate defined with membershipPredicate can be
> >  > undefined for some time.
> >
> > I understand, and I can see why this might be undesirable but that's a
> > completely different problem though, isn't it?
> >
> > My understanding of the non-monotonicity issue Henry raised is based 
on
> > the fact that in a first instance, because you haven't seen any
> > definition of membershipPredicate, you could infere that rdf:member -
> > the default value - is the membershipPredicate. If there is no default
> > value that problem goes away, doesn't it?
> 
> No, that's exactly the same problem: in both cases, you change your
> knowledge about the container and its members because the
> membershipPredicate is changing the semantics.

I'm clearly not an expert in RDF semantics but I don't see how this is 
exactly the same. In Henry's scenario there is a problem because inference 
breaks down. In this scenario you just can't infer anything. I'll leave it 
to the experts to have the final say on that one.

> 
> With your idea, a client needs to assume that any predicate can become
> the membership predicate *at any moment*. That means that a client
> cannot process the triples as-they-arrive but needs to be ready to
> buffer the whole content before knowing what to do.
> 
> That also means that the graph must be finite, so it makes streaming
> the content of the container (with WebSocket for example) not possible
> and this is a serious limitation for extensibility.
> 
> Also, it opens the door to other problems, like what to do in the
> presence of conflicting information? The membershipPredicate can be
> sent several times, I know this is silly, but this would have to be
> specified so that the behaviour of the client is predictable.

I agree with all of the above but I don't think this has anything to do 
with entailment which is what ISSUE-75 is about.

Furthermore there are many other aspects in LDP that can make streaming 
difficult I guess. What about the ordering information for example? What 
about even simply knowing that you're dealing with a container in the 
first place? You could be parsing a whole resource before discovering a 
triple that tells you that you're dealing with an ldp:Container, couldn't 
you? I don't see how membershipPredicate makes the situation any worse in 
this regard.

It seems to me that this all comes with RDF for better and for worse.

Regards.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group