- From: Sandro Hawke <sandro@w3.org>
- Date: Fri, 24 Apr 2009 09:14:41 -0400
- To: Jos de Bruijn <debruijn@inf.unibz.it>
- cc: kifer@cs.sunysb.edu, public-rif-wg@w3.org
> >>> negative-entailment > >>> PREMISE: > >>> CONCLUSION: index-of(list(eg:foo eg:bar), eg:foo) = list(1) > > >> No. eg:foo is mapped to the same object in every interpretation. Let's > >> call this object a. And let's say eg:foo is mapped to b. Then > >> list(eg:foo eg:bar) represents the sequence (a,b). And certainly the > >> object a appears in the first position of this sequence. > >> > >> So, this should be a positive entailment test. > > > > Well, I'd agree that in all interpretations, there's a match in the > > first position. But in some interpretations there's also a match in the > > second postion (namely interpretations where eg:foo=eg:bar). So, in > > some interpretations, the left side of the equals is interpretated as > > list(1) and in others it's list(1 2). So, I think that means the > > equality doesn't hold in all interpretations, and the proposed > > conclusion is not entailed... > > You are right. My mistake. Which kind of makes my point about how this is counter-intuitive. :-) I'm not sure if this challenge comes up with giving rif:iri and rif:local to non-list built-ins. In a sense, they are like variables, and might be unbound, too. Did you think about that in the defn' of safeness? Thinking about that led me here: PositiveEntailmentTest(BLD) PREMISE: p :- isNumeric(foo) and (eg:foo > 0 or eg:foo < 0 or eg:foo = 0) CONCLUSION: p. That's going to be a real bear to pass. (How can an LPD system pass it?) Anyway, back on lists, which option shall we go with: 1. This is just a user-education issue. Highlight the above test case as an example in the spec. 2. Require that list elements be Consts. (And say that Lists are Consts; give them a lexical space.) 3. Option 2, but only for Core. Somehow enable this Const requirement to be relaxed in extension. This would probably be my option, except that I don't know how to do it, which leaves me preferring option 1. 4. ... something more clever? ? -- Sandro
Received on Friday, 24 April 2009 13:14:51 UTC