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

Hello,

I would say that "1.0"^^xsd:float and "1"^^xsd:float are also structurally different constants: the lexical value in both of them is
different. Thus, strictly speaking, if a tool chooses to replace one constant with the other one, it is changing the ontology.

I don't see why the internal representation of literals is important here. If, for example, you implemented the algorithm from my
ISWC paper for reasoning with datatypes, you need to convert the constant into a data value at the time of reasoning. Thus, you
might store the constants as "1.0"^^xsd:float and "1"^^xsd:float for the most part, and then convert them to the number 1 only when
you do reasoning.


Finally, I don't see a big problem even if an implementation chooses to normalize, say, "1.0"^^xsd:float to "1"^^xsd:float. Such an
implementation is not in violation of the OWL 2 specification simply because we never specify whether tools are allowed to do that
or not. I think it is important here to distinguish the question whether a specification is round-trippable (it is) from the
question whether some tool is (it may or may not be). A tool can provide a negative answer to the second question and everything is
still fine.

Regards,

	Boris

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