Re: Issue 80: terminology

Dave Reynolds wrote:
> Chris Welty wrote:
>>
>> Great- let's try to resolve this at the upcoming Telecon. Would anyone
>> object to a resolution to add literal-not-identical to dtb?
> 
> OK by me. It is already in there already so the resolution is retain it
> but rename it (and remove literal-equal).
> 
>> 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?
> 
> lni(?x, ?y) should be true if ?x and ?y are literals and map to
> different value spaces. That's the way DTB is currently written.

Agreed.


Jos

> Some types are in a subtype hierarchy and share a value space and lni
> should respect this. Thus:
> 
> lni("1"^^xsd:int, "1"^^xsd:integer) false (same value space, same value)
> lni("1"^^xsd:int, "2"^^xsd:integer)  true (same value space, diff value)
> lni("1"^^xsd:int, "1.0"^^xsd:float)  true (different value spaces)
> lni("1"^^xsd:int, "2.0"^^xsd:float)  true (different value spaces)
> 
> Dave
> 
>> 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
>>>
> 
> 

-- 
+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 11:10:00 UTC