Re: ISSUE-71: second bug tracking example

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.

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.


> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group

Received on Thursday, 30 May 2013 21:41:51 UTC