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

On 05/30/2013 07:32 PM, Arnaud Le Hors wrote:
> I changed the subject because this is more about ISSUE-75 than ISSUE-71.
> Alexandre Bertails <> wrote on 05/30/2013 02:40:25 PM:
>  > On 05/30/2013 05:21 PM, Arnaud Le Hors wrote:
>  > > Alexandre Bertails <> 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.

That's true when speaking strictly about RDF entailment. In my case, I
was just speaking about semantics as in formal semantics, not as in
semantic Web. That's what I need to know as an implementer.

It's also true that removing all the default values and asking to make
them explicit would remove some of the concerns, but that may not be
enough, see below.

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

I'm not sure if my last point is about entailment: 5.2.5 entails a
cardinality of exactly one membershipPredicate. Does having two of
them breaks something?

And if you don't care too much about all the implications, you still
have the solution to consider that the Turtle document that you GET is
finite and assume a closed-world assumption. Then you can reason about
the absence of membershipPredicate and impose the client to start
doing things only after it has gotten all the triples. That would
simplify things a lot but add a strong constraint.

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

Do you really need to know that [[ <XYZ> a ldp:Container ]] in order
to interpret the rdf:member predicate? That's an interesting question.

It's a bit like dynamic typing vs structural typing: you don't always
need to know that an object is of the type Duck in order to call the
quack() method on it if you know that it's there. That's the same for
an RDF resource.

5.2.7 just states the existence of the type ldp:Container if it's one,
it doesn't mean that I have to wait for that information before doing
interesting things with rdf:member-s for example.


> 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

Received on Friday, 31 May 2013 02:21:15 UTC