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

Re: some new info/issues on lists

From: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Thu, 23 Apr 2009 09:09:01 +0100
Message-ID: <49F0221D.6030803@hplb.hpl.hp.com>
To: kifer@cs.sunysb.edu
CC: Sandro Hawke <sandro@w3.org>, public-rif-wg@w3.org
Michael Kifer wrote:

>> 2.  We got rid of deep-equal because you can just check for list
>>     identity.  But it seems to me there will often be lists of data
>>     values, and data values generally need to be compared with the
>>     appropriate equality predicate for their type (numeric-equal,
>>     datetime-equal, duration-equal, XMLLiteral-equal,
>>     compare+numeric-equal 0, text-compare+numeric-equal 0, etc).  I
>>     suggest bringing back deep-equal for when you want comparison on
>>     data values to be done using datatype equality instead of identity.
>>     (This does suggest having a literal-equal or data-value-equal
>>     predicate; literal-equal(x,y) is the same as deep-equal(list(x),
>>     list(y))).
> Data type constants that are equal will compare as equal. That is, 
> List(1.0 2.0) = List(1.00 2.00).
> We don't have identity, by the way. Identity is not logically definable.

We have previously used "identity" in the XSD sense of "same value in 
the value space", which is exactly how our equality is defined.

I believe what Sandro is pointing out is that for several of our 
datatypes "same value in the value space" is less useful than the XSD/ 
XPath notion of equality. For example:


are not identical under XSD 1.1, not equal in terms of our equality 
semantics (they represent different values in the value space), but they 
are equal in terms of real world time instants[*] and in terms of the 
xsd equality algorithm which is exposed through our builtin 

So when comparing ground lists then the datatype-specific equality 
predicates rather than the RIF "same value in value space" equality 
semantics would probably be desirable.


[*] At least under the common sense, but technically false, notion of 
absolute time.
Received on Thursday, 23 April 2009 08:09:56 UTC

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