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

builtins operating on rif:iri

From: Sandro Hawke <sandro@w3.org>
Date: Thu, 23 Apr 2009 11:37:31 -0400
To: kifer@cs.sunysb.edu
cc: public-rif-wg@w3.org
Message-ID: <20464.1240501051@ubehebe>

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

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

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.

      -- Sandro
Received on Thursday, 23 April 2009 15:37:41 GMT

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