Re: builtins operating on rif:iri

Sandro Hawke wrote:
>>>>> 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?   

The only currently defined "built-in" that accepts rif:iris is
pred:iri-string, and its design has been thought through quite a bit.
So I don't expect any further surprises there.

I did not think about safeness in the context of list built-ins, because
none has been defined so far.

> 
> 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?)

I believe this is not a valid test case:  p is not entailed, because
there are models in which foo is not assigned to a number and thus the
body is false and the rule is true, and so p is not necessarily true.

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

I am thinking of a variant of 3.  You can only really talk about
built-ins when talking about concrete values, so I think it makes sense
to define the list built-ins only for concrete values.  The truth value
of built-ins would simply be undefined if you introduce lists that
contain elements that are not data values.

In BLD and beyond you can simply use lists with variables to do whatever
processing you want.


Best, Jos

> 
> ?
> 
>     -- Sandro
> 

-- 
+43 1 58801 18470        debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
Many would be cowards if they had courage
enough.
  - Thomas Fuller