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

Hello,

 

I just wanted to make a point regarding round-trippability of datatype constants. (I'll call them "constants" because that's the
term we were using so far. We may, and probably should, change the spec to use the term "literal").

 

The spec is currently perfectly round-trippable regarding constants. Each constant consists of a lexical representation and a
datatype URI. Two constants are structurally equivalent if these two components are structurally equivalent. Thus, it should be
clear that "1"^^xsd:float is not structurally equivalent to "1"^^xsd:integer.

 

Thus, from the point of view of the structural specification, replacing "1"^^xsd:float with "1"^^xsd:integer in an ontology is
tantamount to replacing UnionOf( A ComplementOf( A ) ) with owl:Thing. A tool could choose to do any of these equivalent
replacements, but then it should be clear that it is modifying the structural aspect of the ontology. Hence, it seems to me that the
spec is perfectly clear w.r.t. this as it is. In order to avoid any misunderstanding, however, we probably should stress the
conditions on the structural equivalence of constants in the section on constants. Once this is clarified, there should be no
question as to what round-trippability means.

 

Regards,

 

            Boris

 

  _____  

From: Alan Ruttenberg [mailto:alanruttenberg@gmail.com] 
Sent: 01 July 2008 15:42
To: Michael Smith
Cc: Boris Motik; 'OWL Working Group WG'
Subject: 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