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