W3C home > Mailing lists > Public > public-rif-wg@w3.org > April 2009

Re: builtins operating on rif:iri

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
Message-ID: <21008.1240578881@ubehebe>

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

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:05 GMT