- 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