Re: Issue 80: terminology

Great- let's try to resolve this at the upcoming Telecon. Would anyone  
object to a resolution to add literal-not-identical to dtb?

One point of ambiguity remains I think: is lni(?x,?y) true if ?x and?y  
are both literals but of different types, or do ?x and ?y have to be  
of the same type (but different values) for the pred to be true?

Truth table for Lni(?x,?y):
?x and?y are literals of the same type and the same value in the value  
space: FALSE
?x and ?Y are literals of the same type and different values in the  
vspace: TRUE
?x and ?y are literals of different types:
?x or ?y is a non-literal: FALSE


-Chris (sent from my iPhone)

On Mar 26, 2009, at 5:59 AM, Jos de Bruijn <debruijn@inf.unibz.it>  
wrote:

> I guess many people do feel having literal-non-identity is important  
> in
> RIF.  So, let's go for option (1) from [4], i.e., we have
> literal-non-identity and we have the individual (in)equality operators
> based on the XPath operators.
>
>
> Jos
>
> Dave Reynolds wrote:
>> We had a useful but not fully conclusive discussion on this at the  
>> last
>> telecon and tried to clarify our terminology. I felt afterwards we
>> didn't quite have it right so here's an attempt to articulate that.
>>
>> There are actually three notions of "equality" buried in here.
>>
>> (1) Identity. Two literals are identical if they correspond to the  
>> same
>> value in the value space.
>>
>> (2) Equality. XSD defines algorithms for equality which mean that two
>> non-identical points in a given value space can be equal. However,  
>> for
>> XSD this equality is restricted to be within a datatype[1] and so
>> doesn't include the "1"^^xsd:int = "1.0"^^xsd:float case.
>>
>> (3) Equivalence[3]. XPath F&0 defines equality operators (a different
>> notion from the mathematical equality functions which characterize  
>> the
>> XSD value spaces). These can span multiple datatypes, specifically
>> numeric-equal does.  This is the one that does type promotion and
>> permits "1"^^xsd:int = "1.0"^^xsd:float.
>>
>>
>> Now, in XML Schema 1.0, which is the version we current reference in
>> DTB, equality and identity are the same[2]. So the issues we were
>> worrying about in the telecon don't apply.
>>
>> In XML Schema 1.1 some datatypes have a non-identity equality.
>> Specifically xsd:dateTime and float/double. Though with float/ 
>> double the
>> exceptions (-0 = +0, Nan != NaN) are perhaps not so interesting.
>>
>> For OWL then they define xsd:dateTimeStamp to have a value space
>> corresponding to a timeline instead of following the XML Schema 1.1
>> structural model and so for OWL's definition identity and equality
>> coincide again.
>>
>> So my contention is that the way literal-not-equal is defined in  
>> DTB at
>> present (non-identity) corresponds to the equality notion in OWL  
>> for all
>> the relevant datatypes and I keep my preference for options 2 or 1  
>> [4].
>>
>> This contention is trivially true if we stick to XML Schema 1.0  
>> because
>> there is no distinction between equality and identity there. If we  
>> move
>> to XML Schema 1.1 (is there a proposal to do this? I assume so) there
>> are differences but the main problematic datatype is not included in
>> OWL[5].
>>
>> Dave
>>
>> [1] http://www.w3.org/TR/xmlschema11-2/#value-space
>> "For purposes of this specification, the value spaces of primitive
>> datatypes are disjoint, even in cases where the abstractions they
>> represent might be thought of as having values in common."
>>
>> [2] http://www.w3.org/TR/xmlschema11-2/#value-space
>> "Note: In the prior version of this specification (1.0), equality was
>> always identity.  This has been changed to permit the datatypes  
>> defined
>> herein to more closely match the "real world" datatypes for which  
>> they
>> are intended to be used as transmission formats."
>>
>> [3] I don't know what a good name for this is so I'm using  
>> "equivalence"
>> for now. You could call it "programmatic equality" or "pragmatic
>> equality" or something.
>>
>> [4] http://lists.w3.org/Archives/Public/public-rif-wg/2009Mar/0076.html
>>
>> [5] OK, that does leave the corner cases of float/double (-0 = +0,  
>> Nan
>> != NaN) I haven't checked how OWL handle these. If those are the only
>> differences then I personally don't care either way.
>
> -- 
> +43 1 58801 18470        debruijn@inf.unibz.it
>
> Jos de Bruijn,        http://www.debruijn.net/
> ----------------------------------------------
> Many would be cowards if they had courage
> enough.
>  - Thomas Fuller
>

Received on Thursday, 26 March 2009 10:30:52 UTC