- From: Alexandre Bertails <bertails@w3.org>
- Date: Thu, 30 May 2013 17:40:25 -0400
- To: Arnaud Le Hors <lehors@us.ibm.com>
- CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
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. 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. Alexandre. > -- > Arnaud Le Hors - Software Standards Architect - IBM Software Group
Received on Thursday, 30 May 2013 21:41:51 UTC