Re: builtins operating on rif:iri

Sandro Hawke wrote:
>>> Oh, hmmm.  Now I realize I'm confused and worried about using rif:iri
>>> (or rif:local) with builtins.
>>>
>>> Does:
>>>          ex:foo = 1
>>> ential:
>>>          external(numeric-equal(ex:foo, 1))
>>> ?
>> Yes. ex:foo is indistinguishable from 1 after you equated them.
> 
> Okay, that's what I would have expected.
> 
> But that means that before I equate them, the truth value of that
> external predicate formula is 'unspecified'....  (It can't be 'false' or

Yes (in those interpretations in which ex:foo does not denote a number).

> the logic would be non-monotonic.)  Similarly,
> external(pred:isInteger(eg:bar)) is 'unspecified' until/unless eg:bar
> ends up equated with some data value, or we otherwise learn a lot more
> about it.

No. in every interpretation, the truth value of pred:isInteger(eg:bar)
is known, because it is known in that particular interpretation whether
eg:bar denotes an integer. However, since eg:bar does not denote an
integer in every interpretation, pred:isInteger(eg:bar) if not entailed.

> 
> So that means list-contains/member will be 'unspecified' a lot of the
> time as well; in practice, it will never be false when there are
> 'objects' in the list.  For example:
> 
>     member(eg:foo, list(eg:foo eg:bar))
> 
> is be true, but:
> 
>     member(eg:baz, list(eg:foo eg:bar))
> 
> is 'unspecified' unless eg:foo, eg:bar, and eg:baz are all equated to
> data values --- and in practice, if you're using them as frame/objects,
> you would never equate them to data values.  (You could also get a false
> via a combination to OWL, from which you could learn they were pairwise
> distinct.)

Same as above.  The truth value is specified in every particular
interpretation.

> 
> All the list operations that compare items have a form of this behavior.
> For instance:
> 
>     index-of(list(eg:foo eg:bar), eg:foo)
> 
> is 'unspecified', unless we can determine, somehow, whether
> eg:foo=eg:bar.
> 
> I guess this unfortunate behavior is inescapable given our no-CWA,
> no-UNA style of Core.
> 
> The effect is that it basically doesn't work to think of 'objects' as
> items in lists in Core or BLD.  (Does this problem go away in PRD?)  
> 
> The two options I can think  of:
> 
>    1. Forbid 'objects' in lists; make lists just be lists of data
>       values.  Given this, we could even define a mapping to a lexical
>       space for lists, making them be another datatype.  (Hey, we could
>       generalize that, and make it another Rec-track document like
>       rdf:text.  Hey, why are you hitting me?  :-)
> 
>    2. Just understand that they don't really work for 'objects', even
>       though the machinery is there.
> 
> I suspect option (2) is better, because it allows lists to grow more
> useful in other dialects -- possibly PRD, and certainly a
> logic-programming dialect with CWA/UNA.

As I said, the truth value is going to be specified in every
interpretation, so I believe we do not have a problem.

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