Re: ISSUE-126 (Revisit Datatypes): A proposal for resolution

On Jul 1, 2008, at 9:05 AM, Michael Smith wrote:

> On Jun 19 (in [1]) I mentioned that this is a change from best  
> practice
> advice [2] and impacts existing implementations.  I asked for
> clarification on what the benefit of the change would be so we could
> evaluate this as a trade-off.

Opinion: FWIW, this advise doesn't seem great to me. It's  
tremendously confusing that SPARQL doesn't have equality on the  
values of literals of different types without doing extra work.

>> This elegantly solves the
>> problems that Alan mentioned in his last e-mail. For example, if  
>> the ontology initially contains "1.0"^^xsd:float, this would be
>> read into a constant whose lexical representation is "1.0" and  
>> whose URI is xsd:float. Thus, if you write the ontology back from the
>> structural spec, the constant would be written out as  
>> "1.0"^^xsd:float, and thus the form of the ontology would be  
>> preserved.
>
> This would only be true if one's tool supported some sort of literal
> round-trip guarantee.  The internal representation of literal  
> constants
> is an efficiency trade-off over which I expect tool vendors would be
> making their own decisions.

I think it would be reasonably to have some choices and not others.  
Sounds like we should discuss exactly what this means. For example, I  
would (perhaps naively) expect that the value and type of a literal  
is preserved in a roundtrip. I'd not be concerned if there were extra  
leading 0s.

>> The only thing that changes really is that we'd say that the  
>> extensions of xsd:double and xsd:float are continuous and not  
>> discrete,
>> and we'd tweak them (e.g., by removing NaN) to make them subsets  
>> of owl:real.
>
> It seems that "supporting" xsd:float and xsd:double, but not allowing
> some of their permitted values is likely to confuse users.

I agree. Needs some thought.

>
> -- 
> Mike Smith
>
> Clark & Parsia
>
> [1] http://lists.w3.org/Archives/Public/public-owl-wg/2008Jun/ 
> 0149.html
> [2] http://www.w3.org/TR/swbp-xsch-datatypes/#sec-values