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

Thanks for the clarification. Just to be further clear, what about  
changing “1.0”^^xsd:float to “1”^^xsd:float?

Michael, could you give an example of what your concern was re:  
internal representation of literals, and how it might play out?

-Alan

On Jul 1, 2008, at 11:00 AM, Boris Motik wrote:

> 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
>

Received on Tuesday, 1 July 2008 15:13:59 UTC