Re: ISSUE-126 (Revisit Datatypes): A new proposal for the real <-> float <-> double conundrum

On Jul 7, 2008, at 1:02 AM, Rob Shearer wrote:

>>>>> XSD offers a lexical syntax for points that happen to lie on  
>>>>> the real number line
>>>>
>>>> It offers several and we're free to define one for owl:real. If  
>>>> we use any decimal notation, we have exactness problems (e.g.,  
>>>> 1/3), but decimal is very user friendly. So, I was thinking that  
>>>> the valid syntax for a real would be decimal floating points and  
>>>> ratios of integers. We could include scientific notation as well.
>>>
>>> Why on earth would the OWL group come up with their own syntax  
>>> for encoding numbers?
>>
>> I'm presuming we're sticking with the basic xsd framework. So  
>> types have a lexical space and a values space.
>
> NO. There is no lexical space to represent all of the reals.

I didn't say or imply there was. There's, afaict, no requirement that  
the lexical space cover the entire mapping space. Indeed, in the  
current owl:real, where we are talking about a value space over the  
algebraic reals (which *are* denumerable), we only allow rational  
constants. (We need the additional reals as possible solutions to  
equations with rational constants.)

> That's the whole point---the reals include lots and lots of values  
> that cannot necessarily be represented lexically.

I'm skeptical that than's the whole point, as it doesn't seem relevant.

>> So, owl:real has a value space of the reals. But what should the  
>> lexical space be? I'd propose that at least the union of the xsd  
>> numeric types lexical spaces be the lexical space for our new  
>> type. I would add additional syntax for exact rationals (such as  
>> 1/3). The first part is isomorphic to your proposal about xsd  
>> syntax, I believe.
>
> Again, I have no intention of implementing rationals.
>
> And if you want to come up with some syntax for encoding rational  
> numbers in XML I suggest you join the XSchema working group,  
> because that's way beyond the OWL charter.

I'm not sure why you say that. Designing an OWL type seems well  
within our purview. Consider rdf:Literal.

>>> The XSchema guys have already done that, and people have  
>>> implemented parsers for their spec. If there's going to be a  
>>> syntax for rationals or algebraics, then that seems to be right  
>>> up their alley.
>>
>> They don't seem interested, alas.
>
> And I very much hope the OWL WG takes that as a sign that they  
> should be even less interested.

The reason (one memeber) gave (privately) is that they didn't think  
that reals beyond decimals were necessary for a schema language. I  
think we agree that they are for an ontology language. So, my  
conclusion is the opposite of your hope.

>>>>> XSD datatypes have a lexical space (e.g., the syntax) and a  
>>>>> value space. You are suggesting, I thought, that we adopt a  
>>>>> value space that is the reals and something about using xsd  
>>>>> syntax (i.e., lexical spaces) for the syntax.
>>>
>>> For the syntax of particular values. I keep trying to stress that  
>>> values spaces should be kept separate from the syntax used for  
>>> particular values.
>>
>> Sure. But that's true in XSD as well.
>
> No it's [not](http://www.w3.org/TR/xmlschema-2/#value-space): "Each  
> value in the value space of a datatype is denoted by one or more  
> literals in its ·lexical space·."

Oh, ick. I had interpreted that as contingent for the set defined,  
not as a general principle for all types in an extended system. Ick.

Yes, well, as the current design for owl:real shows, we are already  
ignoring this constraint :(

> In XSD the lexical and value spaces and very tightly bound  
> together. This should *not* be true for OWL.

Well, not exactly, but certainly moreso than I thought.

They seem to be loosening this in Schema 1.1:
	http://www.w3.org/TR/xmlschema11-2/#value-space
"""Each value in the value space of a ·primitive· or ·ordinary·  
datatype is denoted by one or more character strings in its ·lexical  
space·, according to ·the lexical mapping·; ·special· datatypes, by  
contrast, may include "ineffable" values not mapped to by any lexical  
representation. """
[snip]
>> I'd be surprised if we could get consensus on abandoning the  
>> lexical space/value space language and understanding. It's pretty  
>> deeply embedded into RDF.
>
> It's impossible to have a real number line and have lexical  
> representations for all values.

Yes, so we have to at least relax the Schema 1.0 constraint that  
every value have a corresponding literal. Thanks for pointing that out.

[snip]

> To make this clearer, perhaps we should abandon the "value space"  
> terminology altogether and instead talk about OWL "data domains". I  
> suggest that OWL have a string data domain and a number data  
> domain. The integer data domain is a subset of the number data  
> domain. There is absolutely no need for a float data domain. OWL  
> implementations should support particular values encoded using the  
> `xsd:int` and `xsd:float` lexical representations. These values are  
> all in the number domain.

This goes against existing implementation and use, wherein xsd:float  
is disjoint from xsd:int. (The non-real values of float are a problem  
as well.)

[snip]
>>> There is such a thing as "the space of lexical representations  
>>> which a conformant implementation must support for particular  
>>> values in the real value space", but this space is much smaller  
>>> than the real value space.
>>
>> Our initial proposal for owl:real is to support for syntax, pairs  
>> of integers with the second being non-zero (i.e., standard  
>> fraction syntax for rationals) and (at least) the algebraic reals  
>> for the value space. If you don't have equations or special  
>> constants, you can't address the irrationals or transcendentals  
>> anyway. We are aiming to support some classes of equation, but  
>> only with rational constants.
>
> But why on earth would you cut down the value space at *all*?

Once you let the value space vary from the lexical space, there's  
less need. I think it helps to have the concept if that's what you  
are actually using. At the time, we were motivated in part by not  
wanting to spook people.

(If our principle is the most broad relevant type, then complex seems  
to be the right supertype. The algebraic reals have a lot of nice  
properties which make them pretty suitable for our purposes.)

> That just cuts off any possibility of future extension!
[snip]

I'm not sure why. We're free to introduce new types or extend old types.

>> For the restriction "forall R `xsd:float`" I simply bounded the  
>> real number line at the min and max values of floats. Still a  
>> dense, infinite number line, but with bounds. I hated this usage,  
>> however, and would prefer if it became illegal."""
>>
>> So you did bound...but you "hate it"? Which, the bounds? the  
>> universal quantifier?
>
> I hated that the user was saying `float` and I was interpreting it  
> as "real between `FLT_MIN` and `FLT_MAX`". I hope OWL 2.0 allows  
> only OWL data domains in such a context.

So you do want arbitrarily sized floats. Ok.

> (But of course an individual value is a valid data domain, and  
> complex data domains could be built using facets with individual  
> values.)

We may be reaching diminishing returns on the public debate. We can  
continue in private if you like, and then summarize back.

Thanks for the discussion.

Cheers,
Bijan.

Received on Monday, 7 July 2008 06:15:57 UTC