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

Re: builtins operating on rif:iri

From: Jos de Bruijn <debruijn@inf.unibz.it>
Date: Thu, 23 Apr 2009 18:04:14 +0200
Message-ID: <49F0917E.7070902@inf.unibz.it>
To: Sandro Hawke <sandro@w3.org>
CC: kifer@cs.sunysb.edu, public-rif-wg@w3.org

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

> 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
  - Thomas Fuller

Received on Thursday, 23 April 2009 16:04:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:07:55 UTC