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

Re: builtins operating on rif:iri

From: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Fri, 24 Apr 2009 15:04:35 +0100
Message-ID: <49F1C6F3.9030500@hplb.hpl.hp.com>
To: Sandro Hawke <sandro@w3.org>
CC: Jos de Bruijn <debruijn@inf.unibz.it>, public-rif-wg@w3.org
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.  :-)

Sure is.

> 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?   
> Thinking about that led me here:
> PositiveEntailmentTest(BLD)
> PREMISE:  p :- isNumeric(foo) and (eg:foo > 0 or eg:foo < 0 or eg:foo = 0)

Surely that's not entailed, there are interpretations in which foo fails 

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

2 and thus 3 makes the lists useless for representing RDF lists at least 
in Core (which is the one I care about) which leaves me preferring 
option 1 as well.

Since in Core we can't assert equality anyway then I wonder if we could 
allow implementations to make a UNA for Core? :-)

Part of the problem is that index-of is too powerful. It in effect is 
testing for absence as well as presence. Perhaps it could be restricted 
to be slightly less problematic, for example just return *an* index 
rather than all indicies.

Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
Received on Friday, 24 April 2009 14:05:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:55 UTC