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

Re: ISSUE-80: Meta builtins

From: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Mon, 16 Mar 2009 10:21:12 +0000
Message-ID: <49BE2818.7000009@hplb.hpl.hp.com>
To: Chris Welty <cawelty@gmail.com>
CC: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
Chris Welty wrote:
> Status:
> At the March 3 telecon we discussed the issue of a general literal 
> equality/non-equality predicate.  There was consensus that we could drop 
> (or, really, not add) pred:literal-equal, however it turned out that 
> some who agreed (or didn't object) assumed that meant *also* dropping 
> pred:literal-not-equal, and of course some thought it meant keeping 
> not-equal.
> It is pred:literal-not-equal that reduces the 13 inequality rules in [1] 
> to a single rule.
> Lets see if we can resolve this one at the upcoming telecon.

The parenthetical comment on option (2) in the issue write up (and 
below) confuses me. pred:literal-equal as originally proposed and as 
currently defined in DTB is not the same as "=" it is more like:

    pred:literal-equal(?x, ?y) iff
        isLiteral(?x) AND isLiteral(?y) and ?x = ?y

Though I agree there is redundancy there.

My preference order is:

(2) Leave pred:literal-equal as is

[on the grounds of symmetry with pred:literal-not-equal, accepting there 
is some redundancy.]

(1) Drop pred:literal-equal  (retaining pred:literal-not-equal)

[This still leaves me able to shorten the OWL 2 RL and similar rules.]

(3) Redefine pred:literal-equal to perform all the datatype specific 
equality tests (and redefine pred:literal-not-equal compatibly so that 
for any pair of literals exactly one of these predicates is true).

[This means I can't use those predicates for the OWL 2 RL rules easily 
(assuming OWL opt for disjoint value spaces). However, there may still 
be value in such predicates for other users.]

(0) Drop both pred:literal-equal and pred:literal-not-equal

I will not formally object to any of these options though there is a 
significant gap in my preference order between the first two and the 
last two.


> -Chris
> [1] http://www.w3.org/2005/rules/wiki/OWLRL#Rules_for_supported_datatypes
> Chris Welty wrote:
>> Issue-80 was prompted by DaveR's attempt at using RIF-Core to specify 
>> the rules in OWL-RL.  He suggested it would be much easier, and also 
>> promote datatype extensibility, if the builtins were more general.  We 
>> resolved to have a two-argument pred:isLiteralOfType (and its 
>> negation), and are currently considering literal equality, which is 
>> more complicated.
>> Basically we need a pred:literal-not-equal, or at the very least a 
>> not= for each datatype.  It seems to make sense to have a 
>> pred:literal-equal as well (for symmetry, if nothing else), but what 
>> does it do? Is it redundant with RIF's = predicate?  Does it do 
>> numeric comparison?  Is it simply lexical?
>> At the moment pred:literal-equal is defined to be subsumed by RIF's 
>> =.  It does not do xs:numeric-equal, which includes type promotion.  
>> Thus we would need to keep that, unless this predicate were changed.  
>> RIF= for datatype checks identity in the value space.
>> Jos believed he read somewhere that it is possible for a datatype to 
>> have multiple values in their value spaces that are identical.  
>> Probably this is from dateTime, which is pretty hard to understand - I 
>> wasn't able to nail it down precisely (the spec says datetimes are 
>> compared based on their timeline values).  Thus if RIF= already 
>> provides value space identity, pred:literal-equal could provide the 
>> datatype specific equality that F&O specifies for e.g. numerics, 
>> date-times, etc.
>> Note:  [XS2] says "Equality" in this Recommendation is defined to be 
>> "identity" (i.e., values that are identical in the ˇvalue spaceˇ are 
>> equal and vice versa). Identity must be used for the few operations 
>> that are defined in this Recommendation. Applications using any of the 
>> datatypes defined in this Recommendation may use different definitions 
>> of equality for computational purposes; [IEEE 754-1985]-based 
>> computation systems are examples. Nothing in this Recommendation 
>> should be construed as requiring that such applications use identity 
>> as their equality relationship when computing.
>> Solutions:
>> 1) Drop pred:literal-equal
>> 2) Leave pred:literal-equal as is (redundant with RIF =)
>> 3) Redefine pred:literal-equal to perform all the datatype specific 
>> equality tests including numeric, and remove those datatype specific 
>> tests from DTB.
>> -Chris
>> [Xs2] http://www.w3.org/TR/xmlschema-2/
Received on Monday, 16 March 2009 10:22:06 UTC

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