Nabble - w3.org - public-webont-comments

[OWL-Guide] error in use of "varietals" Sec 3.1.3.

2008-08-27T13:44:02Z

[OWL-Guide] error in use of "varietals" Sec 3.1.3.

In my opinion, the use of the phrase "grape varietals" is erroneous. The correct term in botanical taxonomy is "variety" (or "cultivar"). "Varietal" is an adjective applicable only to wines; thus, "varietals" in the plural is an elliptic reference to "varietal wines". Cabernet Sauvignon (wine) is a "varietal wine" - made from grapes grown on Cabernet Sauvignon grapevines, not ablend. Chianti is a non-varietal wine made from a flexible blend of grape varieties in a particular region of Italy.

I hate to be pedantic, but there's a certain irony in seeing taxonomic terms abused when the whole focus is about the precise construction of a taxonomy.

This message may contain confidential information. If you are not the designated recipient, please notify the sender immediately, and delete the original and any copies. Any use of the message by you is prohibited.

Newbie question about OWL test cases

2008-07-31T09:26:13Z

Hi All,

The language levels of both the premises and conclusions of the test
case AnnotationProperty002 are Lite, but why the languge level of the
whole test case is Full?

Thanks in advance
Wei

--
Wei Tai

SKOS and OWL

2008-07-30T07:59:09Z

Dear OWL WG members,

The SKOS vocabulary is intended for the representation of simple
knowledge organisation schemes such as thesauri, term lists and
controlled vocabularies. SKOS is designed to fit into existing
Semantic Web standards, and to achieve this, an RDF Schema which
defines the SKOS vocabulary has been produced.

The development of this schema has highlighted issues relating to OWL
species which are relevant to current work on OWL 2. In particular,
the current schema is in OWL Full. It would be desirable if the SKOS
vocabulary could be represented in OWL DL (or the equivalent of OWL DL
in the OWL 2 space).

Concepts in a SKOS vocabulary are defined as instances of the
owl:Class skos:Concept. They may be related to other skos:Concepts
using object properties such as skos:broader, skos:narrower and
skos:related -- known as SKOS semantic relations. SKOS also provides a
set of lexical labelling properties, such as skos:prefLabel and
skos:altLabel. These are datatype properties, with RDF plain literals
as values. Documentation properties including skos:note,
skos:changeNote, skos:definition are also provided, allowing the
decoration of concepts with additional information. In some
circumstances, the expected value of a documentation property is a
literal value (e.g. a simple textual note). In other circumstances,
the value may be an object, for example the value of skos:changeNote
may be a structured object containing information about a change along
with provenance or date information. Documentation properties are
defined as subproperties of skos:note.

An additional use case for SKOS is as an annotation vocabulary for OWL
ontologies. For example the SKOS vocabulary itself uses
skos:changeNote and skos:definition to attach provenance and
documentation information to the SKOS vocabulary terms. This then
pushes the ontology out of OWL DL as object properties are being
applied to classes. We envisage that SKOS properties will also be used
to attach lexical information to OWL ontologies (for example,
providing alternate names or labels for classes). Again, with the
current situation, this results in OWL Full ontologies.

One solution to this would be the provision of rich annotations. The
SKOS documentation properties are essentially annotations and would
ideally be represented as such, but with the addition of subproperty
relationships between the properties (i.e, skos:note as a
superproperty). The lexical labelling properties could also be
considered as annotation properties. SKOS is intended to be
extensible, however, so again allowing the possibility of providing
subproperties of the lexical labelling properties is desirable.

Support for punning, both in terms of class/instance and data/object
property would also provide solutions to some of these issues. Rich
annotations would, however, be our preference.

Cheers,

Sean

--
Sean Bechhofer
School of Computer Science
University of Manchester
sean.bechhofer@...
http://www.cs.manchester.ac.uk/people/bechhofer

Re: I18N issues an OWL2

2008-07-10T02:39:50Z

Bijan Parsia wrote:

> (too many lists! :))
>
> I'd like to raise a point that Dan Brickley (cced) often champions. If
> it's more appropriate in a narrower scope, please narrow it for me!
>
> In some applications, like FOAF, it's common to compare as equal two
> strings with different language tags (esp. for such purposes as being a
> database key like identifier). I can think of several ways to do this
> (e.g., always comparing the strings and opting in to distinguishing the
> languages), but I thought I'd raise the issue.
>
> Cheers,
> Bijan.

Well, with the built-in functions in DTB [1]... you should be able to do
so, there are functions for extracting the string: by casting rif:text
to xs:string [2]) as well as extracting the lang-tag (by adopting
SPARQL's lang function [3]. Note that the former would be even easier
with the langtag-as-dataype proposal, and for the latter, we'd need a
function which returns the datatype of a literal... we have to discuss
this, since sparql's datatype function [4] is not straightforwardly
applicable to RIF semantically... at least there are some implications
in defining it, I guess.

Axel

1.http://www.w3.org/2005/rules/wiki/DTB
2.http://www.w3.org/2005/rules/wiki/DTB#xs:string
3.http://www.w3.org/2005/rules/wiki/DTB#func:lang_.28adapted_from_SPARQL.27s_lang_function.29
4.http://www.w3.org/TR/rdf-sparql-query/#func-datatype

--
Dr. Axel Polleres, Digital Enterprise Research Institute (DERI)
email: axel.polleres@... url: http://www.polleres.net/

Everything is possible:
rdfs:subClassOf rdfs:subPropertyOf rdfs:Resource.
rdfs:subClassOf rdfs:subPropertyOf rdfs:subPropertyOf.
rdf:type rdfs:subPropertyOf rdfs:subClassOf.
rdfs:subClassOf rdf:type owl:SymmetricProperty.

Re: I18N issues an OWL2

2008-07-10T01:18:54Z

(too many lists! :))

I'd like to raise a point that Dan Brickley (cced) often champions.
If it's more appropriate in a narrower scope, please narrow it for me!

In some applications, like FOAF, it's common to compare as equal two
strings with different language tags (esp. for such purposes as being
a database key like identifier). I can think of several ways to do
this (e.g., always comparing the strings and opting in to
distinguishing the languages), but I thought I'd raise the issue.

Cheers,
Bijan.

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

2008-07-09T02:12:41Z

- Original Message From: "Michael Kay"

> At the same time it's true that most modern languages do the same as
> Schema+QT: they treat integer, double and float as separate primitive
> types
> with no hierarchic relationship, and then define operators such as "=" and
> "+" to operate across a value space that is effectively the union of these
> types.

I'll admit that most of this is going over my head, but... don't most
programming languages promote one type into another to do cross-type
comparisons? For example int -> float (probably double in C) in order to
compare an int with a float, and float to double to compare floats and
doubles.

Is there any mileage in XML schema defining how the value of one type can be
promoted into a value of another in order to do the comparisons looked for?
That way the types can remain largely disjoint, but the various operations
can be provided.

Apologies if this is out of place. I'll get back to my grease gun now!

Regards,

Pete Cordell
Codalogic
For XML C++ data binding visit http://www.codalogic.com/lmx/

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

2008-07-08T23:55:51Z

> It's also violated within XML
> Schema itself - " xx " as an instance of xs:token maps to a different
value from "
> xx " as an xs:string.
>
> Not so. ' xx ' is not in the lexical space of token.

Well, yes, but isn't that just a fig-leaf to hide the fact that the
principle has been violated in spirit?

What exactly is the practical benefit / intent of the principle, and is this
benefit still achieved if it applies to the intermediate lexical form rather
than the raw lexical form?

Michael Kay

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

2008-07-08T19:02:14Z

At 7:54 PM +0100 2008-07-08, Michael Kay wrote:

>(b) it claims the existence of a "principle that if a string
>maps to a given value in a particular type then it should map to the same
>value
>in all supertypes". I don't see that principle as being in any way
>fundamental, and I certainly don't see it as "fundamental to subtyping in
>programming languages". It's also violated within XML Schema itself - " xx "
>as an instance of xs:token maps to a different value from " xx " as an
>xs:string.

Not so. ' xx ' is not in the lexical space of token. The literal that
is considered for lexical space membership is the one that is obtained
by whitespace processing.

Whether this is good or bad is a matter of opinion, I suppose. But that's
the way whitespace works. (Took me a few years to really internalize
this, myself.)

Whether the primciples themselves are good is a matter of opinion.
But I hope we don't change things from one version of the spec to the
next without serious thought. (E.g., there was serious thought given
to the decision to allow equality to differ from identity, to have
two zeros in float and double, and to retain timezone information in
the date/time datatypes.)
--
Dave Peterson
SGMLWorks!

davep@...

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

2008-07-08T13:47:41Z

> Boris has a new proposal that's interesting:
> <http://www.w3.org/mid/002501c8e115$ef500220$7212a8c0@wolf>
> It seems usefully influenced by some of your points. I'm not sure
> what I think about it yet.

We had a little pow-wow here in Oxford on the topic. I fully endorse
that proposal.

smime.p7s (3K) Download Attachment

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

2008-07-08T11:54:03Z

>
> The best explanation that I know of was written by Mark
> Reinhold, a member of the original schema WG (...and, if
> memory serves me, was a member of the team that wrote the
> Java floating-point spec).
>
> During the development of the Schema 1.0 (i.e., a few years
> before we went to Rec) we had MANY discussions about the
> numeric types, and especially about float and double. As
> part of that discussion, Mark wrote a note entitled
> "Floating-point datatypes are not real datatypes"
> [1] that goes into great detail on this point. It also
> serves as a good entry point to the archives for the
> discussions the WG had on these issues.
>

Thanks for the pointer, Paul. I confirms much of what people have said about
the original rationale.

In my view the note makes two basic assumptions that are open to question:

(a) it takes the view that all restriction must be facet-based; I can't see
any particular necessity in the theory that if a type is magic then it has
to be primitive.

(b) it claims the existence of a "principle that if a string
maps to a given value in a particular type then it should map to the same
value
in all supertypes". I don't see that principle as being in any way
fundamental, and I certainly don't see it as "fundamental to subtyping in
programming languages". It's also violated within XML Schema itself - " xx "
as an instance of xs:token maps to a different value from " xx " as an
xs:string.

At the same time it's true that most modern languages do the same as
Schema+QT: they treat integer, double and float as separate primitive types
with no hierarchic relationship, and then define operators such as "=" and
"+" to operate across a value space that is effectively the union of these
types.

Michael Kay
http://www.saxonica.com/

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

2008-07-08T11:11:51Z

On 8 Jul 2008, at 18:42, Rob Shearer wrote:
[snip]

> Hmmm...I think your interpretation might actually be the intent:
> [the ·value space·s of all ·primitive· datatypes are disjoint (they
> do not share any values)](http://www.w3.org/TR/xmlschema-2/#equal).
> I'm not crazy about their definitions (a claim about disjointness
> isn't the same as defining multiple colors of numbers), but they
> did seem to intend disjoint spaces.

Yep. Again, this isn't dispositive, but I do hope it makes it clear
where I was coming from.

One reason for this, of course, is to make typing of certain
operations easier. I.e., if you have actual floating point
arithmetic, it can help to make it a type error to use decimals with
it. (And vice versa, if you want to reserve binary floats for
situations where people are aware of the issues with floating point
arithmetic).

> The new version of the XSchema spec is much [clearer](http://
> www.w3.org/TR/xmlschema11-2/#order), and explicitly endorses "other
> applications" which join the value spaces:
>
> For purposes of this specification, the value spaces of primitive
> datatypes are disjoint, even in cases where the abstractions they
> represent might be thought of as having values in common. In the
> order relations defined in this specification, values from
> different value spaces are ·incomparable·. For example, the
> numbers two and three are values in both the decimal datatype and
> the float datatype. In the order relation defined here, the two in
> the decimal datatype is not less than the three in the float
> datatype; the two values are incomparable. Other applications
> making use of these datatypes may choose to consider values such as
> these comparable.

Yep.

> Regardless, my experience is that users both want and expect a
> single number line (modulo NaN and +-inf). I feel that the last
> sentence of the above section of the new XSchema spec blesses these
> semantics with xsd constants.

We have to be careful since that's just a working draft. But it does
seem to be the way they're going.

> And current tools are inconsistent in their interpretation, so any
> choice we make is going to force *some* implementation(s) to change.

Yep. For sure.

> Is anyone really still pushing for multiple number lines, one of
> which includes Integers and one of which includes (for example)
> floats?

It's still open. I'm still unsure where I stand. My last position was
to drop floats and doubles entirely so as to avoid this issue :) (and
others).

(Some of these are user issues. I think encouraging people to use
one, owl type might be overall better. Also, there are lots of other
issues with floats (bounds, NaN, discreteness). Boris has a new
proposal that's interesting:
<http://www.w3.org/mid/002501c8e115$ef500220$7212a8c0@wolf>
It seems usefully influenced by some of your points. I'm not sure
what I think about it yet.

I've not talked with other Pellet people about it yet, nor asked on
the Pellet list. I need to think some more on it.

We also need to figure out some stuff about conformance. E.g., if we
spec minimum sizes on integers, how should implementations handle
larger integers in the data? How do we label stuff, etc.)

I think we, as a group, have a better understanding (I certainly do).
But I'm not sure if we've got consensus yet. I hope you'll be willing
to review the detailed work when it's further along.

Cheers,
Bijan.

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

2008-07-08T10:42:16Z

>>> I understand the misreading. I'm happy that you tested, it's good

>>> information to have. But Pellet has that behavior because I read
>>> the XML Schema specs and interpreted them in what I think is the
>>> obvious way. Thus, I think Pellet's behavior is spec compliant.
>>
>> I read the spec differently: both values spaces are defined
>> mathematically in terms of "numbers". The mathematical value 1 is
>> in the [float](http://www.w3.org/TR/xmlschema-2/#float) value space
>> because it is the value 1x2^0, is in the [decimal](http://www.w3.org/TR/xmlschema-2/#integer
>> ) value space because it is the value 1x10^{-0}, and it is in the
>> [integer](http://www.w3.org/TR/xmlschema-2/#integer) value space
>> because it is in the set \{...-2,-1,0,1,2,...\}. As these are all
>> mathematical and not lexical definitions it appears that the
>> Integer and float value spaces overlap.
>
> This would be true if XML Schema had a purely structural type
> system. But it also includes nominal types:
> http://www.w3.org/mid/D245D6CC-4F7B-41CC-BCF4-FAE7CD7CFFC9@...
>
> My reading of the spec:
> http://www.w3.org/mid/6572A0FC-B943-4ACE-9E42-6D914E2C383C@...
>
> Since all primitive datatypes are disjoint, double and decimal and
> float are all disjoint.
>
> (Interestingly, McQueen (mis)read it the same way! <http://www.w3.org/mid/8E57FB57-80B1-4016-A7F0-46DE8CEB8289@...
> >. That does suggest that the de facto understanding is strongly
> against mine, but I think mine was honestly come by.)

Hmmm...I think your interpretation might actually be the intent: [the
·value space·s of all ·primitive· datatypes are disjoint (they do not
share any values)](http://www.w3.org/TR/xmlschema-2/#equal). I'm not
crazy about their definitions (a claim about disjointness isn't the
same as defining multiple colors of numbers), but they did seem to
intend disjoint spaces.

The new version of the XSchema spec is much [clearer](http://www.w3.org/TR/xmlschema11-2/#order
), and explicitly endorses "other applications" which join the value
spaces:

For purposes of this specification, the value spaces of primitive
datatypes are disjoint, even in cases where the abstractions they
represent might be thought of as having values in common. In the
order relations defined in this specification, values from different
value spaces are ·incomparable·. For example, the numbers two and
three are values in both the decimal datatype and the float datatype.
In the order relation defined here, the two in the decimal datatype is
not less than the three in the float datatype; the two values are
incomparable. Other applications making use of these datatypes may
choose to consider values such as these comparable.

Regardless, my experience is that users both want and expect a single
number line (modulo NaN and +-inf). I feel that the last sentence of
the above section of the new XSchema spec blesses these semantics with
xsd constants. And current tools are inconsistent in their
interpretation, so any choice we make is going to force *some*
implementation(s) to change. Is anyone really still pushing for
multiple number lines, one of which includes Integers and one of which
includes (for example) floats?

-rob

smime.p7s (3K) Download Attachment

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

2008-07-07T19:16:57Z

I'm suggesting two things.
1. epsilon-delta arguments are applicable to determining how many numbers
you can distinguish.
2. once that number gets sufficiently large, there's no point in considering
the larger
number of "theoretical" answers, because you can't measure them, so they
just don't matter.

Dick

----- Original Message -----
From: "Dave Peterson" <davep@...>
To: "Richard H. McCullough" <rhm@...>; <paul@...>;
"Alan Ruttenberg" <alanruttenberg@...>
Cc: "Rob Shearer" <rob.shearer@...>;
<public-webont-comments@...>; <public-owl-wg@...>;
<www-xml-schema-comments@...>
Sent: Monday, July 07, 2008 6:38 PM
Subject: Re: ISSUE-126 (Revisit Datatypes): A new proposal for the real <->
float <-> double conundrum

>
> Let me put one thing to bed once and for all: No one that I'm aware of
> believes that (*absent artificial "coloring" for distinction*) the value
> space of float is not a subset of the value space of double, or that
> the value space of double is not a subset of the value space of decimal.
> The problem is in the details of all the additional baggage a datatype
> carries, over and above its value space.
>
> At 4:38 PM -0700 2008-07-07, Richard H. McCullough wrote:
>>I suggest that you consider following the example of classical
>>mathematical analysis -- the delta-epsilon arguments -- or the example of
>>engineering approximations.
>
> I'm very interested in knowing how Leibnizian epsilon-delta arguments
> impact the question of how one can or should derive double, and then
> float, from decimal.
>
>>Domains may be disjoint in theory, but when you make real measurements,
>>and consider measurement precision/errors, they're not really disjoint.
>
> True. But there's a lot of difference between saying you have "numbers"
> whose exact value you don't know (a la precisionDecimal) and saying that
> you have a fixed finite set of numbers into which you must jam all your
> values. Some of the Schema WG members won't even talk to me about
> precision any more because I get into too much detail as to just what
> precision is in engineering measurement contexts. Best don't get me
> started. ;-)
> --
> Dave Peterson
> SGMLWorks!
>
> davep@...
>
>

Dick McCullough
http://mKRmKE.org/
Ayn Rand do speak od mKR done;
knowledge := man do identify od existent done;
knowledge haspart proposition list;
mKE do enhance od "Real Intelligence" done;

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

2008-07-07T18:38:21Z

Let me put one thing to bed once and for all: No one that I'm aware of
believes that (*absent artificial "coloring" for distinction*) the value
space of float is not a subset of the value space of double, or that
the value space of double is not a subset of the value space of decimal.
The problem is in the details of all the additional baggage a datatype
carries, over and above its value space.

At 4:38 PM -0700 2008-07-07, Richard H. McCullough wrote:
>I suggest that you consider following the example of classical
>mathematical analysis -- the delta-epsilon arguments -- or the
>example of engineering approximations.

I'm very interested in knowing how Leibnizian epsilon-delta arguments
impact the question of how one can or should derive double, and then
float, from decimal.

>Domains may be disjoint in theory, but when you make real measurements,
>and consider measurement precision/errors, they're not really disjoint.

True. But there's a lot of difference between saying you have "numbers"
whose exact value you don't know (a la precisionDecimal) and saying that
you have a fixed finite set of numbers into which you must jam all your
values. Some of the Schema WG members won't even talk to me about
precision any more because I get into too much detail as to just what
precision is in engineering measurement contexts. Best don't get me
started. ;-)
--
Dave Peterson
SGMLWorks!

davep@...

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

2008-07-07T16:38:57Z

I suggest that you consider following the example of classical mathematical
analysis -- the delta-epsilon arguments -- or the example of engineering
approximations.
Domains may be disjoint in theory, but when you make real measurements,
and consider measurement precision/errors, they're not really disjoint.

Dick
----- Original Message -----
From: "Dave Peterson" <davep@...>
To: <paul@...>; "Alan Ruttenberg" <alanruttenberg@...>
Cc: "Rob Shearer" <rob.shearer@...>;
<public-webont-comments@...>; <public-owl-wg@...>;
<www-xml-schema-comments@...>
Sent: Monday, July 07, 2008 1:21 PM
Subject: Re: ISSUE-126 (Revisit Datatypes): A new proposal for the real <->
float <-> double conundrum

>
> At 10:38 AM -0600 2008-07-07, Paul "Sparrow Hawk" Biron wrote:
>>Alan Ruttenberg wrote:
>>>
>>>I'm sorry for the overgeneralization and didn't mean to insult. It's just
>>>that as much as I think about it, I can't understand the idea that the
>>>value space of floats and the value space of decimal are disjoint.
>>>Fundamentally these represent some of the same real numbers and this
>>>isn't reflected in the spec. In addition, many numbers that can be
>>>finitely expressed and be calculated with find no place in *any* of the
>>>value spaces, e.g. 1/3. It is this sense of "mathematical" that I was
>>>referring to.
>>
>>The best explanation that I know of was written by Mark Reinhold, a member
>>of the original schema WG (...and, if memory serves me, was a member of
>>the team that wrote the Java floating-point spec).
>>
>>During the development of the Schema 1.0 (i.e., a few years before we went
>>to Rec) we had MANY discussions about the numeric types, and especially
>>about float and double. As part of that discussion, Mark wrote a note
>>entitled "Floating-point datatypes are not real datatypes" [1] that goes
>>into great detail on this point. It also serves as a good entry point to
>>the archives for the discussions the WG had on these issues.
>
> Thanks, Paul, for the history. That discussion happened during a 9-month
> period when I had to be away from Schema, so I wasn't really aware of it.
>
> Interesting to note that the whole discussion of a parent for decimal,
> float, and double (and even precisionDecimal) was reopened and discussed
> during the early XSD 1.1 development, and again rejected (with and without
> including precisionDecimal). Apparently for much the same reasons.
> --
> Dave Peterson
> SGMLWorks!
>
> davep@...
>
>

Dick McCullough
http://mKRmKE.org/
Ayn Rand do speak od mKR done;
knowledge := man do identify od existent done;
knowledge haspart proposition list;
mKE do enhance od "Real Intelligence" done;

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

2008-07-07T13:21:32Z

At 10:38 AM -0600 2008-07-07, Paul "Sparrow Hawk" Biron wrote:

>Alan Ruttenberg wrote:
>>
>>I'm sorry for the overgeneralization and didn't mean to insult.
>>It's just that as much as I think about it, I can't understand the
>>idea that the value space of floats and the value space of decimal
>>are disjoint. Fundamentally these represent some of the same real
>>numbers and this isn't reflected in the spec. In addition, many
>>numbers that can be finitely expressed and be calculated with find
>>no place in *any* of the value spaces, e.g. 1/3. It is this sense
>>of "mathematical" that I was referring to.
>
>The best explanation that I know of was written by Mark Reinhold, a
>member of the original schema WG (...and, if memory serves me, was a
>member of the team that wrote the Java floating-point spec).
>
>During the development of the Schema 1.0 (i.e., a few years before
>we went to Rec) we had MANY discussions about the numeric types, and
>especially about float and double. As part of that discussion, Mark
>wrote a note entitled "Floating-point datatypes are not real
>datatypes" [1] that goes into great detail on this point. It also
>serves as a good entry point to the archives for the discussions the
>WG had on these issues.

Thanks, Paul, for the history. That discussion happened during a 9-month
period when I had to be away from Schema, so I wasn't really aware of it.

Interesting to note that the whole discussion of a parent for decimal,
float, and double (and even precisionDecimal) was reopened and discussed
during the early XSD 1.1 development, and again rejected (with and without
including precisionDecimal). Apparently for much the same reasons.
--
Dave Peterson
SGMLWorks!

davep@...

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

2008-07-07T09:38:36Z

Alan Ruttenberg wrote:
>
> I'm sorry for the overgeneralization and didn't mean to insult. It's
> just that as much as I think about it, I can't understand the idea that
> the value space of floats and the value space of decimal are disjoint.
> Fundamentally these represent some of the same real numbers and this
> isn't reflected in the spec. In addition, many numbers that can be
> finitely expressed and be calculated with find no place in *any* of the
> value spaces, e.g. 1/3. It is this sense of "mathematical" that I was
> referring to.

The best explanation that I know of was written by Mark Reinhold, a
member of the original schema WG (...and, if memory serves me, was a
member of the team that wrote the Java floating-point spec).

During the development of the Schema 1.0 (i.e., a few years before we
went to Rec) we had MANY discussions about the numeric types, and
especially about float and double. As part of that discussion, Mark
wrote a note entitled "Floating-point datatypes are not real datatypes"
[1] that goes into great detail on this point. It also serves as a good
entry point to the archives for the discussions the WG had on these issues.

pvb

[1] http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/1999Oct/0025.html

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

2008-07-07T06:59:28Z

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

Cerebra did not make them disjoint. Neither does KAON2. And testing
reveals that neither does FaCT++. The only reasoner I can find that
makes them disjoint is Pellet. This sheds a lot of light on your
definition of "existing implementation and use".

If you intend to attempt to enshrine bugs in Clark & Parsia products
in the OWL standard, I suggest that you do it as a representative of
Clark & Parsia and not as a representative of Manchester, which has an
interest in FaCT++.

-rob

smime.p7s (3K) Download Attachment

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

2008-07-07T04:46:57Z

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

Rational numbers, and linear equations, and n-ary data predicates, all
seem *much* more relevant to data representation and model checking
than satisfiability reasoning; these are systems people want to use to
store and compute particular values based on input, not to check
satisfiability. (The n-ary datatype use cases, for example, don't
offer much insight into how such a feature could be used to draw
valuable new inferences.) And yet the XSchema group---the data
representation and model-checking crowd---decided that such notions
were far too ambitious for even them.

Again, I urge the OWL working group to follow that example and focus
on the small set of features which will actually benefit users, and
make sure that they get those features right.

-rob

smime.p7s (3K) Download Attachment

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

2008-07-06T23:15:12Z

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.

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

2008-07-06T17:02:14Z

>>>> 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. That's
the whole point---the reals include lots and lots of values that
cannot necessarily be represented lexically.

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

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

>>>> 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·." In XSD the lexical and value spaces
and very tightly bound together. This should *not* be true for OWL.

> From what I can tell, you want all the literals that have
> "xsd:float" (to pick an example) to map to (a subset) of the reals
> (as the value space) and constrain/enable certain syntax. So
> "1.0"^^xsd:float would be a syntax error.

That looks like a valid [float][http://www.w3.org/TR/xmlschema-2/
#float] to me. But `"rob"^^xsd:float` looks like a syntax error.
Again, all these syntax issues should be deferred to the XSD spec.

>> . I want `real` to be a value space with no lexical connotations.
>
> 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.

The "value spaces" in OWL serve a fundamentally different purpose than
the "value spaces" defined in XSD. See my first message. XSD is
concerned with representing values. Future incarnations can add more
representations for more values, and existing data sets can be
seamlessly extended with these new values.

OWL is concerned with spaces of values. If the OWL 2.0 value space for
numbers does not include, for example, the rationals, then the system
can *not* be seamlessly extended to include the rationals, because
they've already been excluded. The value spaces from XSD are
inappropriate for OWL because they fail in exactly the wrong way. OWL
extensions trim down value spaces. XSD extensions build up value spaces.

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.

>> I want to be able to specify a particular point in this value space
>> using a string such as "1.0e0^^xsd:float".
>
> Yeah, I'm kinda against that. But I would support "1.0e0^^owl:real".

That's craziness. You're crazy. Stop being crazy.

>> The XSD lexical forms are not "the lexical space for reals". There
>> is no such thing as "the lexical space for reals".
>
> Bravo! ;)
>
>> 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*? That
just cuts off any possibility of future extension!

>>> If we want exactness for the rationals, we need either to allow
>>> repeating (e.g., 0.333repeating) (usually done with a macron) or
>>> fraction syntax (e.g., 1/3).
>>
>> I don't intend to support exactness for rationals. A conformant
>> implementation should only be required to provide exact support for
>> `xsd:int` and `xsd:float` values.
>
> I don't think that would fly.

Who is the vast army of users in need of support for exact rationals?
I strongly strongly suspect that if they really existed they would
have pushed on the XSchema folks to give them a lexical
representation---XML is kind of big as a data representation language,
you know.

> Also, perhaps I misrecall, but don't you want arbitrarily sized
> floats?

An `xsd:float` has a limited size, by definition.

> """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. (But of course an individual value is
a valid data domain, and complex data domains could be built using
facets with individual values.)

-rob

smime.p7s (3K) Download Attachment

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

2008-07-06T16:02:35Z

On Jul 6, 2008, at 10:55 PM, 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. 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.

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

>>> But my main point is that users have no interest in the "holes"
>>> introduced by the xsd:float value space: providing them access to
>>> a value space of numbers representable in float representation is
>>> not useful, and could lead to lots of confusion, particularly if
>>> users could easily use such a space "by accident".
>>
>> Well, you'll get exactness holes with binary or decimal notation,
>> regardless of density issues.
>
> I thought I had made my proposal clear on this: the value space
> does not have holes.

Sure.

> The representations supported for particular values are not
> sufficient to address all the points in that space, but the space
> itself does *not* have holes.

I just meant things that you can't write down 1/3 in decimal. That's
all.

>>> I don't know what you mean by "lexical space of the reals".
>>
>> 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. From what I can tell, you want
all the literals that have "xsd:float" (to pick an example) to map to
(a subset) of the reals (as the value space) and constrain/enable
certain syntax. So "1.0"^^xsd:float would be a syntax error.

>> XSD offers exact syntax only for binary and decimals (I believe
>> it's exact for binary). I was wondering what sort of lexical space
>> you want.
>
> XSD offers a well-defined mapping from lexical representation to
> IEEE floats.

Yes. I just hadn't checked the spec, hence my hesitation.

> XSD defines an *exact* value for each valid lexical representaion.
> You may not like the way the mapping is defined (because the value
> of "1.1e0^^xsd:float" on the real number line is not equal to the
> value of "1.1^^xsd:decimal"),

No that's fine.

> but there is no imprecision whatsoever about what each string
> represents.

You've got the wrong string. I only hedged because I hadn't looked
and I don't like to speak with certainy without looking. My point was
only that there are numbers which can not be exactly represented in
binary or in decimal.

> I am satisfied with the work the XSchema group did on floating-
> point lexical representations.
>
>>> But implementations should allow users to specify particular
>>> points in that value space using the lexical representations for
>>> `xsd:float` and `xsd:int` values.
>>
>> So you want a very broad lexical space for our real type, i.e.,
>> "1", "1.0", and "12.78e-2".
>
> No. I want `real` to be a value space with no lexical connotations.

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.

> I want to be able to specify a particular point in this value space
> using a string such as "1.0e0^^xsd:float".

Yeah, I'm kinda against that. But I would support "1.0e0^^owl:real".

> The XSD lexical forms are not "the lexical space for reals". There
> is no such thing as "the lexical space for reals".

Bravo! ;)

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

>> If we want exactness for the rationals, we need either to allow
>> repeating (e.g., 0.333repeating) (usually done with a macron) or
>> fraction syntax (e.g., 1/3).
>
> I don't intend to support exactness for rationals. A conformant
> implementation should only be required to provide exact support for
> `xsd:int` and `xsd:float` values.

I don't think that would fly.

[snip]
>> Given that more and more languages (e.g., Java) now bundle a
>> decimal type with their core libraries, I'm not so clear on the
>> first.
>
> I'm not sure Java is an example of "more and more languages". In
> fact it is the flagship "you only ever need one language" proposal.

I picked java because it didn't have it for a long time and now it
does. To pick another example, Python now has a bundled decimal
class. Both of these are quite recent additions to popular languages.
SQL supports it. Visual Basic seems to.

> And even in super-OO Java you have to program differently if you're
> going to play with polymorphic numbers than you would if you stuck
> to ints and floats.
>
> I'd like to write a distributed OWL reasoner in Erlang. But
> Javascript and C are perhaps more persuasive counterexamples to
> your argument.

Javascript is a bit odd in not supporting integers either :) There
are high quality decimal libraries for C++ (e.g., from IBM) and the
committee is considering decimal support (<http://open-std.org/JTC1/
SC22/WG21/>)

>> I'd like to hear more about the second.
>
> The most efficient bignum and decimal libraries are an order of
> magnitude slower than corresponding int and float calculations.
> Hardware is good with ints and floats.

Sure, but I wouldn't have thought that this would be a significant
factor. Obviously, if the user writes really big or really small
numbers, you have to deal with them anyway. If you only have user-
defined types (no equations), then the operation (and number there
of) is pretty limited (inclusion and cardinality testing). I'm a bit
skeptical that it makes a huge practical difference. Perhaps because
it doesn't come up too much.

Also, perhaps I misrecall, but don't you want arbitrarily sized floats?

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

Implementations could always throw a warning or error if they hit a
too large number.

>>> ---thus a vocabulary for what it means to "support" a numeric xsd
>>> type for particular values would be useful.
>>
>> This is what we're after. Anything we spec will be tightly
>> specced. At the moment, we only have required and optional as
>> modalities of support. I think supporting various levels of
>> precision (or variant mapping) would be quite hard to understand.
>
> But presumably you're making clear that implementations which
> implement some "optional" functionality, but do so in a way which
> contradicts the optional semantics, are non-compliant.

That's always a problem with optional :(

> If so, then specifying what support for additional lexical
> representations means (i.e. exact) would make clear that a product
> which parsed `xsd:decimal` but internally converted to floating
> point would not "support `xsd:decimal`" by the terms of the OWL 2.0
> spec.

They can convert as long as the observable behavior is the same.

> The implementors could always claim "partial support", however.

If they are going to vary in observable ways, I would prefer that
they would make that clear in documentation and by giving warnings. A
"strict" mode would also be quite welcome to me as a user.

>> One this model, users would just have to decide between integers
>> and reals. We could have quite a wide lexical space for reals (and
>> even for integers, i.e., allow 1.0 to mean the integer 1).
>
> I'm getting really confused what you're talking about---constants
> appearing in XML and RDF OWL 2.0 files should be typed; there's no
> need at all to guess the type based on syntax.
>
> And of course "1.0e0^^xsd:float" and "1^^xsd:integer" are exactly
> the same point on the real number line.

Sure.

But I was talking about owl:real. It seems reasonable to allow
"1.0e0^^owl:real:" and "1^^owl:real". (xsd:integer could be a subtype
of owl:real as well).

>> But "0.1"^^xsd:float would not be required, but also we wouldn't
>> change the meaning along the lines you suggest (we'd just be
>> silent about it). It's fairly simple to migrate old ontologies to
>> the new one with a simple converter. If enough implementations did
>> it silently, that would be information for a future group.
>
> No idea what this means. But I'm guessing I disagree with it.

Me too :)

Cheers,
Bijan.

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

2008-07-06T14:55:36Z

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

>> But my main point is that users have no interest in the "holes"
>> introduced by the xsd:float value space: providing them access to a
>> value space of numbers representable in float representation is not
>> useful, and could lead to lots of confusion, particularly if users
>> could easily use such a space "by accident".
>
> Well, you'll get exactness holes with binary or decimal notation,
> regardless of density issues.

I thought I had made my proposal clear on this: the value space does
not have holes. The representations supported for particular values
are not sufficient to address all the points in that space, but the
space itself does *not* have holes.

>> I don't know what you mean by "lexical space of the reals".
>
> 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.

> XSD offers exact syntax only for binary and decimals (I believe it's
> exact for binary). I was wondering what sort of lexical space you
> want.

XSD offers a well-defined mapping from lexical representation to IEEE
floats. XSD defines an *exact* value for each valid lexical
representaion. You may not like the way the mapping is defined
(because the value of "1.1e0^^xsd:float" on the real number line is
not equal to the value of "1.1^^xsd:decimal"), but there is no
imprecision whatsoever about what each string represents. I am
satisfied with the work the XSchema group did on floating-point
lexical representations.

>> But implementations should allow users to specify particular points
>> in that value space using the lexical representations for
>> `xsd:float` and `xsd:int` values.
>
> So you want a very broad lexical space for our real type, i.e., "1",
> "1.0", and "12.78e-2".

No. I want `real` to be a value space with no lexical connotations.
I want to be able to specify a particular point in this value space
using a string such as "1.0e0^^xsd:float".
The XSD lexical forms are not "the lexical space for reals". There is
no such thing as "the lexical space for reals". 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.

> If we want exactness for the rationals, we need either to allow
> repeating (e.g., 0.333repeating) (usually done with a macron) or
> fraction syntax (e.g., 1/3).

I don't intend to support exactness for rationals. A conformant
implementation should only be required to provide exact support for
`xsd:int` and `xsd:float` values.

>> I expect most implementations will also support points represented
>> as `xsd:double` and `xsd:long` as well.
>
> You mean their syntax, i.e., their lexical space.

Supporting these syntaxes means that reasoners must also support
reasoning with the particular values representable in those syntaxes.
Support for additional syntaxes does not change the underlying
semantics of the real number line, but it might make implementation of
those semantics a bit harder.

> (Sorry for using the XSD terminology, but I think it's a bit clearer
> if we stick to it for the moment.)
>
>> I
>> do *not* think a conformant implementations should have to deal
>> with arbitrary points represented as `xsd:decimal` (since the vast
>> majority of users don't need the extra representational power, and
>> there is substantial implementation burden and performance penalty
>> for dealing with such values correctly).
>
> Given that more and more languages (e.g., Java) now bundle a decimal
> type with their core libraries, I'm not so clear on the first.

I'm not sure Java is an example of "more and more languages". In fact
it is the flagship "you only ever need one language" proposal. And
even in super-OO Java you have to program differently if you're going
to play with polymorphic numbers than you would if you stuck to ints
and floats.

I'd like to write a distributed OWL reasoner in Erlang. But Javascript
and C are perhaps more persuasive counterexamples to your argument.

> I'd like to hear more about the second.

The most efficient bignum and decimal libraries are an order of
magnitude slower than corresponding int and float calculations.
Hardware is good with ints and floats.

>> ---thus a vocabulary for what it means to "support" a numeric xsd
>> type for particular values would be useful.
>
> This is what we're after. Anything we spec will be tightly specced.
> At the moment, we only have required and optional as modalities of
> support. I think supporting various levels of precision (or variant
> mapping) would be quite hard to understand.

But presumably you're making clear that implementations which
implement some "optional" functionality, but do so in a way which
contradicts the optional semantics, are non-compliant. If so, then
specifying what support for additional lexical representations means
(i.e. exact) would make clear that a product which parsed
`xsd:decimal` but internally converted to floating point would not
"support `xsd:decimal`" by the terms of the OWL 2.0 spec. The
implementors could always claim "partial support", however.

> One this model, users would just have to decide between integers and
> reals. We could have quite a wide lexical space for reals (and even
> for integers, i.e., allow 1.0 to mean the integer 1).

I'm getting really confused what you're talking about---constants
appearing in XML and RDF OWL 2.0 files should be typed; there's no
need at all to guess the type based on syntax.

And of course "1.0e0^^xsd:float" and "1^^xsd:integer" are exactly the
same point on the real number line.

> But "0.1"^^xsd:float would not be required, but also we wouldn't
> change the meaning along the lines you suggest (we'd just be silent
> about it). It's fairly simple to migrate old ontologies to the new
> one with a simple converter. If enough implementations did it
> silently, that would be information for a future group.

No idea what this means. But I'm guessing I disagree with it.

-rob

smime.p7s (3K) Download Attachment

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

2008-07-06T13:54:02Z

On Jul 6, 2008, at 8:07 PM, Rob Shearer wrote:

>>> Most importantly, I do not think there is necessarily a direct
>>> correlation between the lexical representations used to represent
>>> particular values and the value spaces in which those particular
>>> values live. I.e. users want to be able to specify particular
>>> values within the `real` value space using `xsd:float`,
>>
>> You mean the type name or the lexical syntax (e.g., "12.78e-2")?
>
> 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.

> ---that's what I suggest using it for. The easiest approach is that
> xsd names on their own are not valid "datatypes"; particular values
> encoded using xsd, however, are (because particular values are
> single-element value spaces).
>
>> I'm personally more comfortable with allowing the latter than
>> pushing "xsd:float" as a synonym for the real value space. Your
>> milage obviously varies.
>>
>>> but they do *not* have any interest in use of the `xsd:float`
>>> value space.
>>
>> Some do at least to the extent of wanting NaN (and perhaps -0).
>> I'd personally prefer not to shove them into the real type
>> (certainly NaN; I suppose we could make our reals the affine reals
>> and handle +inf).
>
> I'd endorse including only one zero, but I agree there's an issue
> with NaN.

And the infinities, though we could always go for the affine real line.

> My principled stand is that it's inconsistent (a value space of
> size zero), but I'd definitely want to analyze the use cases to see
> who loses important functionality from that decision.
>
> But my main point is that users have no interest in the "holes"
> introduced by the xsd:float value space: providing them access to a
> value space of numbers representable in float representation is not
> useful, and could lead to lots of confusion, particularly if users
> could easily use such a space "by accident".

Well, you'll get exactness holes with binary or decimal notation,
regardless of density issues.

> That's the situation we've fallen into with floats in OWL 1.0.
>
>>> Thus we've got two orthogonal concepts which happen to coincide
>>> for strings and integers but not for real numbers.
>>>
>>> My proposed solution would be to use brand-new OWL names for all
>>> value spaces, but use xsd syntax to specify particular values.
>>
>> Could you say what you think the lexical space of the reals should
>> include?
>
> I don't know what you mean by "lexical space of the reals".

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. XSD offers exact syntax only for binary and
decimals (I believe it's exact for binary). I was wondering what sort
of lexical space you want.

> I don't propose defining the reals lexically;

Sure.

> I propose defining the value space mathematically.

Well, of course. But that's what XSD does as well. The decimals are a
well defined mathematical set.

> But implementations should allow users to specify particular points
> in that value space using the lexical representations for
> `xsd:float` and `xsd:int` values.

So you want a very broad lexical space for our real type, i.e., "1",
"1.0", and "12.78e-2". If we want exactness for the rationals, we
need either to allow repeating (e.g., 0.333repeating) (usually done
with a macron) or fraction syntax (e.g., 1/3).

> I expect most implementations will also support points represented
> as `xsd:double` and `xsd:long` as well.

You mean their syntax, i.e., their lexical space.

(Sorry for using the XSD terminology, but I think it's a bit clearer
if we stick to it for the moment.)

> I
> do *not* think a conformant implementations should have to deal
> with arbitrary points represented as `xsd:decimal` (since the vast
> majority of users don't need the extra representational power, and
> there is substantial implementation burden and performance penalty
> for dealing with such values correctly).

Given that more and more languages (e.g., Java) now bundle a decimal
type with their core libraries, I'm not so clear on the first. I'd
like to hear more about the second.

>> At least, as a first cut? (It seems decimal, scientific, and
>> rational notation would all be useful, the first two for common
>> ways of writing and the third for full coverage of the rationals.)
>
> The WG should consider that some implementations might allow lots
> of xsd syntaxes but lose precision on some of them (allow use of
> `xsd:decimal` in ontology files for user convenience, but convert
> them to floats during parsing)

Obviously, this can cause quite serious interoperability problems.
Some I'm inclined against it on first blush.

> ---thus a vocabulary for what it means to "support" a numeric xsd
> type for particular values would be useful.

This is what we're after. Anything we spec will be tightly specced.
At the moment, we only have required and optional as modalities of
support. I think supporting various levels of precision (or variant
mapping) would be quite hard to understand.

> My big concern here is that an ontology will be developed and
> tested with a reasoner with "full" `xsd:decimal` support but then
> when it's used with an implementation with "imprecise"
> `xsd:decimal` support everything goes pear-shaped.

That would be bad :) There could be subtler problems if people mapped
decimal syntax to binary in variant ways (i.e., which float do you
take 0.1 to?)

> Spitting out warnings during parsing isn't a great solution...
>
> And of course some implementations might offer additional value
> spaces as well, but I'd like the spec to make it very clear that
> this is a very different thing than the above. For one thing, I'd
> suggest outlawing any use of names within the xsd namespace for
> value spaces, even spaces implementors have added as extensions.
> "Support for `xsd:decimal`" should mean `xsd:decimal` syntax for
> points on the real number line and nothing else.\

This doesn't seem likely. Existing implementations already do
different things with different xsd types. It'll be very hard to get
buy in from the RDF community. It seems like a more likely strategy
is to fix a (required) set of OWL types (or core types) which are
easy to understand and robust with respect to intuitive behavior, and
leave the more specialized types for future people to standardize.

One this model, users would just have to decide between integers and
reals. We could have quite a wide lexical space for reals (and even
for integers, i.e., allow 1.0 to mean the integer 1). But
"0.1"^^xsd:float would not be required, but also we wouldn't change
the meaning along the lines you suggest (we'd just be silent about
it). It's fairly simple to migrate old ontologies to the new one with
a simple converter. If enough implementations did it silently, that
would be information for a future group.

Thanks again.

Cheers,
Bijan.

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

2008-07-06T12:17:17Z

FYI
When I designed the mKR language, I purposely avoided placing any
constraints
on the space,time,view specification of context. This permits the user to
choose
whatever level of detail is appropriate in a given situation. The resulting
descriptions
are always useful, and sometimes just plain fun!

Some of my specifications:
space, time = here, now
time = past, present, future
time = yesterday, today
space = my house, the store
view = Aristotle, feminist
view = RDF, OWL, mKR, CycL, Amazon, Google

Dick
----- Original Message -----
From: "Dave Peterson" <davep@...>
To: "Michael Kay" <mike@...>; "'Alan Ruttenberg'"
<alanruttenberg@...>; "'Rob Shearer'" <rob.shearer@...>
Cc: <public-webont-comments@...>; <public-owl-wg@...>;
<www-xml-schema-comments@...>
Sent: Sunday, July 06, 2008 6:51 AM
Subject: RE: ISSUE-126 (Revisit Datatypes): A new proposal for the real <->
float <-> double conundrum

>
> At 10:13 AM +0100 2008-07-06, Michael Kay wrote:
>> >
>>> I don't see that moments in time, segments of time, and
>>> repeating intervals make up a sensible datatype. That's my
>>> particular problem with the idea.
>>
>>Well, one can certainly conceive of a generalization of these types that
>>is
>>a three-dimensional space whose axes are the start instant (perhaps
>>unknown), the duration (perhaps zero), and the interval between repeats
>>(perhaps infinite). Alternatively, and perhaps more conveniently, you can
>>think of it as a seven-dimensional space containing year, month, day,
>>hour,
>>minute, second, and timezone-offset, allowing components at either end to
>>be
>>omitted, where the absence of a high-order component indicates a repeating
>>interval and the absence of a low-order component indicates a time span.
>>
>>E.g., how does one define order? Is 14:00:00 less than or equal to 1997?
>>
>>You could define an ordering (if you wanted to) by filling in the gaps,
>>treating 14:00:00 as say 0000-01-01T14:00:00 and 1997 as
>>1997-01-01T00:00:00. Or you could say that the new primitive type is
>>unordered, only the subtypes are ordered, as we do with the two duration
>>subtypes.
>>>
>>> I'm curious how the simplification would be effected for QT.
>>
>>Difficult to do retrospectively, but with such a type, instead of XSLT
>>defining three functions format-date, format-time, and format-dateTime, it
>>could have defined a single function which would work perfectly well on
>>all
>>eight types, as well as on other logically-consistent subtypes like
>>gHourMinute.
>
> Good ideas all. Fodder for Schema 2.0, I'd say. It takes time to
> think these things out; equality didn't diverge from identity in 1.0
> because we didn't have time to think out the ramifications. Sigh--
> even standards creation is a publish-or-perish world, and if a version
> of the standard doesn't get out the door in a reasonable time, even
> if the possible improvements haven't been thought out yet, the
> creating standards group finds its resources gone and no standard
> at all gets out.
>
> One does the best one can, and hopes one hasn't closed off too many
> useful possibilities for the next round--or left things totally
> screwed up by not closing up some loopholes that leave the standard
> useless. A fine balancing act.
>
> (This, of course, is preaching to the choir WRT Mike Kay himself;
> he's been involved in the production of at least several standards.)
> --
> Dave Peterson
> SGMLWorks!
>
> davep@...
>
>

Dick McCullough
http://mKRmKE.org/
Ayn Rand do speak od mKR done;
knowledge := man do identify od existent done;
knowledge haspart proposition list;
mKE do enhance od "Real Intelligence" done;

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

2008-07-06T12:07:28Z

>> Most importantly, I do not think there is necessarily a direct
>> correlation between the lexical representations used to represent
>> particular values and the value spaces in which those particular
>> values live. I.e. users want to be able to specify particular
>> values within the `real` value space using `xsd:float`,
>
> You mean the type name or the lexical syntax (e.g., "12.78e-2")?

XSD offers a lexical syntax for points that happen to lie on the real
number line---that's what I suggest using it for. The easiest approach
is that xsd names on their own are not valid "datatypes"; particular
values encoded using xsd, however, are (because particular values are
single-element value spaces).

> I'm personally more comfortable with allowing the latter than
> pushing "xsd:float" as a synonym for the real value space. Your
> milage obviously varies.
>
>> but they do *not* have any interest in use of the `xsd:float` value
>> space.
>
> Some do at least to the extent of wanting NaN (and perhaps -0). I'd
> personally prefer not to shove them into the real type (certainly
> NaN; I suppose we could make our reals the affine reals and handle
> +inf).

I'd endorse including only one zero, but I agree there's an issue with
NaN. My principled stand is that it's inconsistent (a value space of
size zero), but I'd definitely want to analyze the use cases to see
who loses important functionality from that decision.

But my main point is that users have no interest in the "holes"
introduced by the xsd:float value space: providing them access to a
value space of numbers representable in float representation is not
useful, and could lead to lots of confusion, particularly if users
could easily use such a space "by accident". That's the situation
we've fallen into with floats in OWL 1.0.

>> Thus we've got two orthogonal concepts which happen to coincide for
>> strings and integers but not for real numbers.
>>
>> My proposed solution would be to use brand-new OWL names for all
>> value spaces, but use xsd syntax to specify particular values.
>
> Could you say what you think the lexical space of the reals should
> include?

I don't know what you mean by "lexical space of the reals". I don't
propose defining the reals lexically; I propose defining the value
space mathematically. But implementations should allow users to
specify particular points in that value space using the lexical
representations for `xsd:float` and `xsd:int` values. I expect most
implementations will also support points represented as `xsd:double`
and `xsd:long` as well. I do *not* think a conformant implementations
should have to deal with arbitrary points represented as `xsd:decimal`
(since the vast majority of users don't need the extra
representational power, and there is substantial implementation burden
and performance penalty for dealing with such values correctly).

> At least, as a first cut? (It seems decimal, scientific, and
> rational notation would all be useful, the first two for common ways
> of writing and the third for full coverage of the rationals.)

The WG should consider that some implementations might allow lots of
xsd syntaxes but lose precision on some of them (allow use of
`xsd:decimal` in ontology files for user convenience, but convert them
to floats during parsing)---thus a vocabulary for what it means to
"support" a numeric xsd type for particular values would be useful. My
big concern here is that an ontology will be developed and tested with
a reasoner with "full" `xsd:decimal` support but then when it's used
with an implementation with "imprecise" `xsd:decimal` support
everything goes pear-shaped. Spitting out warnings during parsing
isn't a great solution...

And of course some implementations might offer additional value spaces
as well, but I'd like the spec to make it very clear that this is a
very different thing than the above. For one thing, I'd suggest
outlawing any use of names within the xsd namespace for value spaces,
even spaces implementors have added as extensions. "Support for
`xsd:decimal`" should mean `xsd:decimal` syntax for points on the real
number line and nothing else.

-rob

smime.p7s (3K) Download Attachment

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

2008-07-06T11:06:30Z

On Jul 5, 2008, at 1:04 PM, Rob Shearer wrote:

>>> I'm providing you with my experience: every user I've ever spoken
>>> to about this topic has wanted the real number line.
>>> They are used to using the xsd datatypes `float` and `double` to
>>> represent number values, so they use these without values in OWL
>>> to mean "some number".
>>
>> Do they mean bounded numbers? (i.e. with min and max sizes?) Do
>> they distinguish between double and float? Do they care about
>> NaNs? (Alan's users care about the latter.)
>
> Whether it's "forall R > 1.0^^xsd:float" or "forall R `xsd:float`"
> they seem to intend a dense number line.

So you had user defined restrictions on floats, interesting.

> In the first case `float` is just the easiest way to specify the
> value; in the second you can certainly argue that they should have
> used `decimal`...but that's a pointless argument because my
> reasoner didn't really support decimal.

That's interesting. I think part of what we need to is select a set
of sane datatypes to require. String, Integer, reals seem reasonable.

>>> My experience is that the use of xsd datatypes as value spaces in
>>> OWL 1.0 causes users to write what they don't mean.
>>
>> For me, this would suggest removing them or enforcing them more
>> clearly.
>
> I'd suggest removing them.

That's where I'm heading too.

>>> My experience is that *every* ontology using `xsd:float` and
>>> `xsd:double` without values would be better off using
>>> `xsd:decimal`, but that the user intent was "some real
>>> number" (and I should note that I'm against requiring support for
>>> `xsd:decimal` values).
>>
>> Values? Or the datatype? In OWL 1, all these types were optional
>> and poorly speced and had no documentation whatsoever. Part of the
>> goal here is to spec well and document clearly any types we require.
>
> I would like to use doubles internally to represent points on the
> real number line.

For what lexical syntax?

> Some homogeneous mix of internal representations is a pain. And I
> seriously doubt that many users really care about the extra
> representation power of `decimal`. It makes sense as an optional
> feature reasoners can support, but it seems completely unnecessary
> to require it in the spec---it's exactly the sort of thing I'd put
> off implementing indefinitely under users asked for it.
>
> The reason `decimal` keeps coming up is just that it's dense.

That's true. But there are several issues floating about, including
the possibility of interaction between floats and cardinality. It
seems to me that for most users, that will be a rare occurrence, even
accidently. It certainly requires ranges of floats (since it's
unlikely that the cardinalities required to cause a problem would be
feasible anyway). E.g., if we had unbounded binary numbers then such
floats would be no harder than integers.

> So are we using the xsd spec as an excuse to conflate density with
> complex internal representations?

I don't think so.

[snip]
> Referring any user over to that spec to understand value spaces is
> obnoxious and counter-productive:

We definitely don't intend to do that, I hope. Part of our current
effort is to make sure we carefully document the types we require and/
or sanction.

> even WG members seem to be having trouble grokking it. (And bravo
> to anyone making the pedantic point that a particular value is a
> degenerate value space.)
>
> I contend that OWL users only want a tiny tiny number of different
> value spaces to play with: integers, strings, and reals.

I certainly agree that these are key. I think the group agrees too.
The other types are something of a legacy.

> It is possible, however, they they will want a larger number of
> ways to lexically represent particular values within these three
> spaces.

This wouldn't surprise me at all.

> Most importantly, I do not think there is necessarily a direct
> correlation between the lexical representations used to represent
> particular values and the value spaces in which those particular
> values live. I.e. users want to be able to specify particular
> values within the `real` value space using `xsd:float`,

You mean the type name or the lexical syntax (e.g., "12.78e-2")? I'm
personally more comfortable with allowing the latter than pushing
"xsd:float" as a synonym for the real value space. Your milage
obviously varies.

> but they do *not* have any interest in use of the `xsd:float` value
> space.

Some do at least to the extent of wanting NaN (and perhaps -0). I'd
personally prefer not to shove them into the real type (certainly
NaN; I suppose we could make our reals the affine reals and handle
+inf).

> Thus we've got two orthogonal concepts which happen to coincide for
> strings and integers but not for real numbers.
>
> My proposed solution would be to use brand-new OWL names for all
> value spaces, but use xsd syntax to specify particular values.

Could you say what you think the lexical space of the reals should
include? At least, as a first cut? (It seems decimal, scientific, and
rational notation would all be useful, the first two for common ways
of writing and the third for full coverage of the rationals.)

[snipped lots of useful details]

Thanks very much for those. I find them extremely helpful.

> Thanks for the feedback.
>>
>> Cheers,
>> Bijan.
>
> And if you're going to request further comment from a member of the
> public, could you please do it on a list to which the public can
> post? Shifting back to the WG list excludes me from comment.

D'oh! Sorry. That was an accident. My apologies.

> (Which is fine if you don't address questions directly to me.)

Thanks again for the discussion.

Cheers,
Bijan.

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

2008-07-06T06:51:57Z

At 10:13 AM +0100 2008-07-06, Michael Kay wrote:

> >
>> I don't see that moments in time, segments of time, and
>> repeating intervals make up a sensible datatype. That's my
>> particular problem with the idea.
>
>Well, one can certainly conceive of a generalization of these types that is
>a three-dimensional space whose axes are the start instant (perhaps
>unknown), the duration (perhaps zero), and the interval between repeats
>(perhaps infinite). Alternatively, and perhaps more conveniently, you can
>think of it as a seven-dimensional space containing year, month, day, hour,
>minute, second, and timezone-offset, allowing components at either end to be
>omitted, where the absence of a high-order component indicates a repeating
>interval and the absence of a low-order component indicates a time span.
>
>E.g., how does one define order? Is 14:00:00 less than or equal to 1997?
>
>You could define an ordering (if you wanted to) by filling in the gaps,
>treating 14:00:00 as say 0000-01-01T14:00:00 and 1997 as
>1997-01-01T00:00:00. Or you could say that the new primitive type is
>unordered, only the subtypes are ordered, as we do with the two duration
>subtypes.
>>
>> I'm curious how the simplification would be effected for QT.
>
>Difficult to do retrospectively, but with such a type, instead of XSLT
>defining three functions format-date, format-time, and format-dateTime, it
>could have defined a single function which would work perfectly well on all
>eight types, as well as on other logically-consistent subtypes like
>gHourMinute.

Good ideas all. Fodder for Schema 2.0, I'd say. It takes time to
think these things out; equality didn't diverge from identity in 1.0
because we didn't have time to think out the ramifications. Sigh--
even standards creation is a publish-or-perish world, and if a version
of the standard doesn't get out the door in a reasonable time, even
if the possible improvements haven't been thought out yet, the
creating standards group finds its resources gone and no standard
at all gets out.

One does the best one can, and hopes one hasn't closed off too many
useful possibilities for the next round--or left things totally
screwed up by not closing up some loopholes that leave the standard
useless. A fine balancing act.

(This, of course, is preaching to the choir WRT Mike Kay himself;
he's been involved in the production of at least several standards.)
--
Dave Peterson
SGMLWorks!

davep@...

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

2008-07-06T02:13:35Z

>
> I don't see that moments in time, segments of time, and
> repeating intervals make up a sensible datatype. That's my
> particular problem with the idea.

Well, one can certainly conceive of a generalization of these types that is
a three-dimensional space whose axes are the start instant (perhaps
unknown), the duration (perhaps zero), and the interval between repeats
(perhaps infinite). Alternatively, and perhaps more conveniently, you can
think of it as a seven-dimensional space containing year, month, day, hour,
minute, second, and timezone-offset, allowing components at either end to be
omitted, where the absence of a high-order component indicates a repeating
interval and the absence of a low-order component indicates a time span.

E.g., how does one define order? Is 14:00:00 less than or equal to 1997?

You could define an ordering (if you wanted to) by filling in the gaps,
treating 14:00:00 as say 0000-01-01T14:00:00 and 1997 as
1997-01-01T00:00:00. Or you could say that the new primitive type is
unordered, only the subtypes are ordered, as we do with the two duration
subtypes.
>
> I'm curious how the simplification would be effected for QT.

Difficult to do retrospectively, but with such a type, instead of XSLT
defining three functions format-date, format-time, and format-dateTime, it
could have defined a single function which would work perfectly well on all
eight types, as well as on other logically-consistent subtypes like
gHourMinute.

Michael Kay
http://www.saxonica.com/

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

2008-07-05T20:31:26Z

At 12:41 PM +0100 2008-07-05, Michael Kay wrote:

>Since the types date, time, dateTime, gYear, gYearMonth, gMonth, gMonthDay,
>and gDay are disjoint in both their value spaces and lexical spaces, I would
>have thought it quite easy to define a primitive type that is essentially
>the union of all of these (it might or might not be abstract), and derive
>these 8 types from this new type by restriction. Where exactly is the
>difficulty?

I don't see that moments in time, segments of time, and repeating
intervals make up a sensible datatype. That's my particular problem
with the idea. E.g., how does one define order? Is 14:00:00 less
than or equal to 1997?

However, it could be done, even if the value space seemed to contain
apples and oranges, so to speak. Just as the anySimpleType and
anyAtomicType are artificially constructed datatypes. Why hasn't
it been suggested before?

I'm curious how the simplification would be effected for QT.
--
Dave Peterson

davep@...

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

2008-07-05T05:04:57Z

>> I'm providing you with my experience: every user I've ever spoken
>> to about this topic has wanted the real number line.
>> They are used to using the xsd datatypes `float` and `double` to
>> represent number values, so they use these without values in OWL to
>> mean "some number".
>
> Do they mean bounded numbers? (i.e. with min and max sizes?) Do they
> distinguish between double and float? Do they care about NaNs?
> (Alan's users care about the latter.)

Whether it's "forall R > 1.0^^xsd:float" or "forall R `xsd:float`"
they seem to intend a dense number line. In the first case `float` is
just the easiest way to specify the value; in the second you can
certainly argue that they should have used `decimal`...but that's a
pointless argument because my reasoner didn't really support decimal.

>> My experience is that the use of xsd datatypes as value spaces in
>> OWL 1.0 causes users to write what they don't mean.
>
> For me, this would suggest removing them or enforcing them more
> clearly.

I'd suggest removing them.

>> My experience is that *every* ontology using `xsd:float` and
>> `xsd:double` without values would be better off using
>> `xsd:decimal`, but that the user intent was "some real number" (and
>> I should note that I'm against requiring support for `xsd:decimal`
>> values).
>
> Values? Or the datatype? In OWL 1, all these types were optional and
> poorly speced and had no documentation whatsoever. Part of the goal
> here is to spec well and document clearly any types we require.

I would like to use doubles internally to represent points on the real
number line. Some homogeneous mix of internal representations is a
pain. And I seriously doubt that many users really care about the
extra representation power of `decimal`. It makes sense as an optional
feature reasoners can support, but it seems completely unnecessary to
require it in the spec---it's exactly the sort of thing I'd put off
implementing indefinitely under users asked for it.

The reason `decimal` keeps coming up is just that it's dense. So are
we using the xsd spec as an excuse to conflate density with complex
internal representations?

>> And my expectation is that users would be much less confused if
>> this distinction between the types used for specific values and the
>> types used for value spaces were clear.
>
> I don't understand this distinction. Every datatype are used for a
> value space. Some value spaces are finite and some are infinite.
> Some are dense and some are not. etc. So, please clarify what you
> mean by this distinction.

A particular value is a point on the number line. XSD offers plenty of
different lexical representations for such points. I support using XSD
types to specify such points.

A "value space" (for numerics, at least) is a (possibly infinite) set
of points on the number line. Although each xsd type is associated
with some value space, I think xsd is a really really crap spec for
value spaces. The entire spec is oriented in terms of lexical
representation, not value spaces: the type hierarchy, for example, is
a hierarchy of lexical representations, not a hierarchy of value
spaces. Referring any user over to that spec to understand value
spaces is obnoxious and counter-productive: even WG members seem to be
having trouble grokking it. (And bravo to anyone making the pedantic
point that a particular value is a degenerate value space.)

I contend that OWL users only want a tiny tiny number of different
value spaces to play with: integers, strings, and reals.
It is possible, however, they they will want a larger number of ways
to lexically represent particular values within these three spaces.
Most importantly, I do not think there is necessarily a direct
correlation between the lexical representations used to represent
particular values and the value spaces in which those particular
values live. I.e. users want to be able to specify particular values
within the `real` value space using `xsd:float`, but they do *not*
have any interest in use of the `xsd:float` value space.

Thus we've got two orthogonal concepts which happen to coincide for
strings and integers but not for real numbers.

My proposed solution would be to use brand-new OWL names for all value
spaces, but use xsd syntax to specify particular values.

>> To repeat: as an implementor, I did willfully implement semantics
>> contradictory to the spec,
>
> The spec made all the types except string and integer optional, and
> didn't say much about them.
>
> It's true that they did defer to the XSD spec, so perhaps you meant
> you violated that? Could you be specific in how you violated it? For
> example:
>
> If an integer typed value appeared as the object of a float ranged
> property, was the KB inconsistent?

No---I made the integer number line a subset of the real number line.

> If a float typed value was outside the range of xsd:float and used
> in an assertion, was the KB inconsistent?

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.

> If a float typed value was NaN (i'm not sure what the constant is
> there), was the KB consistent?

I don't entirely recall; I think NaN become either "any real" or "no
real". Despite asking around a bit, I couldn't find any users who had
strong opinions on the topic, however.

> I presume from what you said having a min cardinality which was
> larger than the size of the floats on a float ranged property was
> consistent. But I'm skeptical that this ever occurred in the wild
> (in this way :))

Other than a little internal test in our suite to remind me of the
issue I also doubt that my use of the real number line instead of the
float number line ever arose.

> Did you have a user defined type derived from float that was fairly
> small in range (e.g., -1.0 to 1.0) that interacted with a
> cardinality restriction? Did you support user defined types?

We supported ranges, but I doubt any users wrote a range so small (and
a cardinality restriction so big) that the issue ever arose. The hard
data is that I never got any bug reports on the topic; the soft data
is that when I interrogated users about their intent they were
surprised by the notion that the set of floats was finite. (They
understood this in principle but had no intention of deriving
inconsistency as a result.)

>> and I will do so again for OWL 2.0 if the spec is "broken" in the
>> same way.
>
> I think we can take this as read for the moment :)
>
>>> When I am working as a user, I generally, both in programming
>>> languages and in kbs, am very careful about computational types
>>> and numerical methods. Its easy to find extensive discussions in
>>> programming language circles about the pitfalls of floats. All
>>> things being equal, it doesn't seem to be that difficult to
>>> recommend that they use a more suitable type such as decimal.
>>> Indeed, that is what's been happening as more and more programming
>>> languages bundled in decimal types.
>>
>> I am also a very careful programmer, and am familiar the details of
>> the IEEE spec.
>>
>> All the good programmers I've ever worked with are aware of the
>> basic problems with floats but almost always use them when they
>> mean "any real number" anyway.
>
> But the systems don't respect that.

The systems respect their own semantics, and as a programmer I
determined that the needs I had for reals were served sufficiently
well by the language semantics for floats. And occasionally a tiny bit
of extra code (i.e. turning a few equality tests into distance tests).

> Ye old Pascal used the name "real" for binary floats, but nobody
> would go for that today. People certainly think there are bounds, at
> least, and they are aware of the exactness problems.
>
>> The mental model I use, and that I encouraged among junior
>> programmers, was that floats were "real numbers, but assume that
>> they wiggle around a little all the time". Not technically correct,
>> but a safe and useful mental model for programming.
>
> For some programming. For lots, not (since the error ranges can go
> *really* wide unexpectedly). For lots of things this does matter
> quite a bit. For other things it doesn't.
>
>> The point being that density of the number line is *not* an issue
>> programmers encounter as a matter of course, and one for which
>> their natural intuition might well be wrong.
>
> That's true. Bounds and inexactness are more obvious because of the
> standard rounding action of float operations. But we aren't doing
> rounding here, we are (potentially) doing counting. I agree that
> people's intuitions are bad about counting, but I don't think it's
> that hard to grasp that floats are more like an enumeration of
> integers. It has to be explained of course.

To what end do we want to explain this? Help me finish this
conversation:

user: Why is this KB inconsistent?
me: You've said that this needs to be a float, and there's this
cardinality restriction, and there are only so many floats.
user: When I wrote float I just meant a number. Isn't that obvious?
me: Well, yes, it is obvious, but it's possible you meant something
else, and the spec says...
user: But if it's completely obvious what I meant, then why didn't the
system just do what I meant?
me: ...

In almost all cases we know that the user doesn't mean what he wrote.
So why would we pass it through, produce a bug, and then try to teach
the user the crazy semantics she never actually wanted to begin with?

>>>>> No user ever intended to restrict the semantic space to a
>>>>> nowhere-dense number line. If the OWL spec presupposes that most
>>>>> of our users would a prefer a number line which does not include
>>>>> 1/3, my choice as an implementor would be to once again ignore
>>>>> the spec and be intentionally non-compliant.
>>>
>>> An alternative choice is to signal that a repair is required and
>>> perhaps do it.
>>
>> I hereby signal that a repair to the OWL spec is required.
>
> I meant repair of the ontology :)

I didn't support `xsd:decimal`.

>> (Are we really pretending that everybody thought datatypes in OWL
>> 1.0 were fine and dandy?)
>
> Not at all. We're trying to do a much better job here. The design
> choice we're faced with is whether to include floats at all (as
> required), and if so, exactly what to spec them as. We'll include an
> owl:real type (I hope) which will *really* be the reals, and perhaps
> require decimal as well. A lot of the time, programmers use floats
> for reals because there is no other choice (or they think
> computation performances is critical). We're in a somewhat different
> situation.
>
> Clear education material is definitely needed.
>
>>>>> Doing what all my users want and expect in this case turns out
>>>>> to be way way easier than doing what a broken spec would
>>>>> require. Any working group who would produce such a spec would
>>>>> clearly be putting their own interests (ease of spec authoring
>>>>> and political considerations) above their duty to their intended
>>>>> users.
>>>
>>> I think your rhetoric flew ahead of reality here. It's not
>>> actually easier to spec this (as the ongoing battle has shown :)).
>>> As you well know, it's much easier to give in to Boris than not
>>> to :) I don't believe I'm particularly motivated by political
>>> considerations per se. I do think that departing from existing
>>> behavior (disjointness) and normal meaning (in computer science)
>>> needs to be done carefully.
>>
>> Let me expand upon my rhetoric:
>>
>> 1. Users want a (dense) real number line.
>
> Agreed. (But we have decimal and are going to offer real.)
>
>> 2. Users expect a (dense) real number line when they write
>> `xsd:float` in OWL 1.0 ontologies.
>
> Unclear to me. Further, it's unclear to me whether we should respect
> that or work against it.

This is an easy point for the WG to establish. Grab a whole load of
OWL 1.0 ontologies that use `xsd:float` without values, track down the
authors, and ask them. Absence cajoling from the interrogator, I'm
willing to bet big money on the results.

>> 3. OWL 1.0 implementations reason as though the `xsd:float` value
>> space is dense.
>> 4. The OWL 1.0 specifications state that the `xsd:float` value
>> space is nowhere-dense.
>
> By reference to xsd, yes.
>
>> If you disagree about the first two points then it's certainly
>> worth discussion: Alan's [investigation](http://lists.w3.org/Archives/Public/public-owl-wg/2008Jul/0103.html
>> ) seems to support my experience on point 1.
>
> See above.
>
>> I have yet to see a single counter-example to point 2---and I've
>> asked many users what they meant when they wrote their datatype
>> restrictions.
>
> Let me stipulate that for a minute. I trust you would contend this
> for programming languages too.

I don't contend that for programming languages at all. Programmers
understand that their data types require concrete representation, and
there is no reasonable concrete representation for all reals.

OWL does *not* need concrete representations to reason about data types.

> But programming languages don't silently substitute a dense value
> space for floats. I would contend that most people expect exact
> computations from their reals too, but again, programming languages
> don't do that (though, amazingly to me, calculator do! I did some
> testing last year and many even simple online calulators use reals
> internally so you can go from 1/3 * 3 and get 1 again.)

Double or nothing on the last bet that they don't use reals
internally. Rationals, maybe. Be clear: OWL can handle the real value
space. Standard programming languages cannot manipulate arbitrary reals.

> There are lots of features of OWL that aren't obvious to many users
> (the open world assumption, the unique name assumption). This isn't
> a reason to blithely ignore user instincts, of course. Far from it!
> But it is not immediate.

OWL includes OWA and discards UNA because its authors assume that most
of its users will benefit from these choices. In those cases user
needs and user expectations seem to be at odds, so hard choices need
to be made. If users both want and expect real numbers you'd be crazy
to do anything else.

[snip]

>>> (Note that this will likely be the algebraic reals and only
>>> rational constants. So, no transcendentals. I'd be interested in
>>> your view on that. I can imagine adding the trans. but would
>>> prefer to defer it until a later iteration.)
>>
>> This getting ridiculous---so you're saying you think there is a
>> substantial user base who need to be able to specify that a value
>> is the solution to some algebraic equation?
>
> Yes. Remember that we are (considering) adding linear and perhaps
> polynomial inequations. This has been requested by users (including
> those working on commerical projects, see:
> http://www.w3.org/2007/OWL/wiki/N-ary_Data_predicate_use_case
> for some examples)

It would be crazy to make that stuff a core part of OWL.

> If we rule out the irrationals, then we have intuitively solvable
> equations which are not solvable in the rationals.
>
> For writing down values, it seems that the rationals are enough for
> a wide range of cases where you are looking for a dense line. Until
> you expand the range of constants (usually with equations of some
> form) it's hard to see the utility to users of additional reals
> (e.g., the square root of two isn't really a constant, but a radical).
>
>> I have absolutely no idea what perspective the working group is
>> taking here---what implementor
>
> RacerPro already has some form of linear inequations over the
> algebraic reals (and, I believe, the algebraic complex numbers). FaCT
> ++ and Pellet developers have indicated that they have interest in
> implementation. We have several classes of users (some of which are
> represented on the page above.)
>
> The working group does not yet have consensus on these features. It
> also does not have a complete design.
>
>> or user has expressed interest in anything other than the real
>> number line???
>
> The algebraic reals just are the above (i.e., the solutions to
> polynomials with rational coefficients). The transcendental reals
> are still more. Without transcendental coefficents or constants, you
> can't "get" to them. So, practically speaking, it makes no
> difference to the consistency of any knowledge base whether we spec
> the type as being all reals or being algebraic reals.
>
> I personally would like to separate them to make augmenting the
> lexical space a bit easier in the future. That is, if we're not
> going to have transcendental constants, I think it makes sense to
> *call* the type we're introducing something like "algebraic
> reals" (and even restrict the value space). That leaves it open for
> a future group to introduce the reals as a super type (both in the
> lexical and in the value spaces).

But why on earth do we need special value spaces for *any* of these
sets? Once again, what percentage of users is going to want to say
"number that can be expressed as some rational"? Surely all these
wacky numerics just provide more evidence than unadorned OWL
ontologies should just be referencing the entire real number line
instead of "accidentally" restricting it to some counter-intuitive
subset!

>> Can you guys please just come up with a version of the [`numeric`](http://www.w3.org/TR/xmlschema-2/#rf-numeric
>> ) notion? Pretty please?
>
> That's interesting and potentially helpful for some things (like
> spliting off the strings from the numbers in general), but I don't
> see it helps with our current situation.
>
>>>>> I don't particularly care what each of these three is called; as
>>>>> long as OWL specifies the internal semantics of these three
>>>>> types of spaces, then it's straightforward to "implement" the
>>>>> datatypes users will actually want in terms of them. But, of
>>>>> course, the ability to use XML Schema Datatypes to encode
>>>>> specific values within each of these spaces would be quite
>>>>> convenient
>>>
>>> Do you mean the lexical spaces?
>>
>> I mean the only time I explicitly want XML Schema is when my
>> implementation is parsing specific values provided by the user. If
>> you happen to re-use the XML Schema spec for other things that is
>> for your own convenience, not mine.
>
> So what is your position on user defined types? We reuse that from
> XSD too.

No use of XSD to specify value spaces at all. Only particular values.

> The core types, and even things like float, seem coherent from an
> OWL point of view (excepting certain facets and corner issues). That
> is, you can coherently reason over them.

The fact that a system is internally coherent is a pretty low bar. The
goal should be a semantic model which matches user needs and
expectations. Not always possible, but `float` and `rational` value
spaces seem to be headed in exactly the opposite direction.

>>>>> ---and would use the XML Schema specification for *exactly* what
>>>>> it's good at.
>>>
>>> The additional question is whether to require additional types
>>> that are not the above three. Among these are float and double. My
>>> belief is that if we are going to add such datatypes as required,
>>> and we are going to take them from xsd, then they should reflect
>>> the semantics of those types and our advice to users is to only
>>> use them if they specifically intend those semantics.
>>
>> I'd guess that using xsd names for value spaces will just (continue
>> to) confuse users.
>
> Seems so.
>
>> More importantly, and yet again, I have never ever encountered a
>> user who would prefer to use the `float` or `double` value spaces
>> if a `real` value space were available.
>
> But that suggests (to me) we not provide the float or double types.

For value spaces, I agree.

>> If there are users who feel the other way, then please produce
>> them---merely hypothesizing their theoretical existence does not
>> seem useful. (I grant that the class is satisfiable. I contend that
>> its size is vanishingly small in practice.)
>
> Again, there are many aspects of the types, e.g., disjointness,
> size, NaN, lexical space, and discreteness. As far as I can tell,
> users have picked on several of these (while champions have claimed
> that some parts that other people have dismissed are critical).
>
> That all being said, my personal concern with "getting floats right"
> involve future, hypothetical use. Which is a big fucking weakness of
> my position. But I would prefer not to require them at all than to
> require them with "wrong" semantics. I would prefer directing people
> who want a real type to the real type. I think that is generally
> better for a number of reasons, including education. It's rather odd
> to introduce primitive types with different names with no different
> semantics not even *intended* different semantics.
>
> Oh, of course, one reason is if the lexical spaces are different. I
> don't have a problem giving the lexical space of our real a lot of
> lexical freedom (in the initial proposal we suggested a fraction
> like syntax, but we could add all sorts of variants; but you have to
> be careful because other syntaxes sometimes require infinite
> expansions).
>
>>> The n-ary predicate definition system will, at most, be over the
>>> core three types above (e.g., polynomial or linear inequations
>>> with rational coefficients over the reals ). However, one can
>>> pretty easily imagine a predicate definition system that was
>>> focused on the floats and was sensitive to the various semantics.
>>> It wouldn't have to be direct floating point based equations, but
>>> an interval arithmetic system which was designed to help reason
>>> about measurements and computations (and their errors).
>>
>> I care not a whit for n-ary datatypes. I might implement them if
>> they're in the spec; I might not. But if the spec says you need to
>> use n-ary datatypes to get real numbers,
>
> No no no. The real datatype will be available, simpliciter. It's use
> in n-ary is an *additional* motivation for it.
>
>> and leaves the issues raised with the `float` value space in place,
>
> ?
>
>> I will ignore the spec and implement the real number line for unary
>> datatypes.
>
> With transcendentals? With what lexical space?

In theory, yes. My documentation will reference the whole real number
line. But my parser will probably only handle `xsd:float` and
`xsd:double` for values.

>> Just like I did for OWL 1.0. As a member of the public, that is my
>> feedback to the working group.
>
> Thanks! Please not that all this is not settled yet.
>
>
>>> I grant entirely that that use case is quite speculative at the
>>> moment. But given that 1) we have alternatives for the "any
>>> number" type and 2) cardinality reasoning with the floats is not
>>> very much more difficult that with user defined finite ranges over
>>> the integers (except for the fact that users have to do much more
>>> work to get there), I don't think we should muck with the
>>> semantics of floats.
>>
>> I strongly disagree with 2.
>
> Really? <http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm
> >
>
> There's some special casing for various "odd" bits (NaN, etc.) but
> this shows that sizing float ranges can be reduced to sizing integer
> ranges. Thus, it's not fundamentally different.
>
>> I don't want my implementation to care about the difference between
>> `double` and `float`,
>
> So you want them exactly identical?
>
>> and I consider any line of code I write involving the internals of
>> float representation to be a wasted line of code, because my users
>> really don't care.
>>
>> Much more importantly, it's my job to turn your spec into user-
>> facing documentation
>
> This is my job too :) Both inside and outside the working group.
>
>> and support, and there is not a chance in hell I'm going to explain
>> this issue to my users. They don't care, and they don't want the
>> semantics you are describing. Experience with OWL 1.0 has
>> demonstrated this.
> [snip]
>
> Can you say exactly what the semantics are you want? I get that you
> want them dense (and think that I'm dense :)). But I'm unclear on:
> disjointness (from each other and from decimal and its subtypes
> like integer)

You keep referring to the value spaces specified in xsd. I don't care
about those value spaces. I don't think they are relevant.

But integers should probably live on the same number line as the rest
of the reals.

> range

Infinite in both directions for the number line, but if particular
values can only be specified with xsd datatypes then users will only
be able to specify particular values within some range.
For integers, I'd support limiting particular values to `xsd:long`
(and would consider a spec which only required `xsd:int` reasonable).
If you required support for any `xsd:Integer` I probably wouldn't
implement it unless there was great user demand.

> NaN like constants

I don't have a strong opinion; no contact with users who have NaN needs.

> Thanks for the feedback.
>
> Cheers,
> Bijan.

And if you're going to request further comment from a member of the
public, could you please do it on a list to which the public can post?
Shifting back to the WG list excludes me from comment. (Which is fine
if you don't address questions directly to me.)

-rob

smime.p7s (3K) Download Attachment

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

2008-07-05T04:41:59Z

> >Similarly, there seems to be missing an underlying type for the date
> >types - although there is reference to timeOnTimeline, this
> value type
> >is not surfaced in the type hierarchy.
>
> I'd very much like to hear how you'd do this; unlike the
> number datatypes, where I could envisage how to pull them
> together, I can't envisage a reasonable way for all the d/t
> datatypes to be derived from a universal one. And I did try.

Since the types date, time, dateTime, gYear, gYearMonth, gMonth, gMonthDay,
and gDay are disjoint in both their value spaces and lexical spaces, I would
have thought it quite easy to define a primitive type that is essentially
the union of all of these (it might or might not be abstract), and derive
these 8 types from this new type by restriction. Where exactly is the
difficulty?

The QT operations on dates and times could be greatly simplified if this
were done (well, perhaps not retrospectively...)

>
> base64Binary and hexBinary are different because they use
> entirely different lexical mappings. Different lexical
> mappings mean different datatypes.

This is certainly an unfortunate feature of the system. Clearly one would
like all operations defined on one of these types to be equally applicable
to the other. Having two different external representations of the values is
really a very weak justification for making them different types. Of course
it's too late to change this; but I'm sure it could have been done better. I
would hope that if we introduced hexadecimal notation as an alternative
lexical representation of integers we would find some way of doing it that
didn't involve introducing a new primitive type.

Michael Kay
http://www.saxonica.com/

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

2008-07-05T04:24:45Z

On Jul 5, 2008, at 1:58 AM, Dave Peterson wrote:

>> Towards the end of understanding the terminology, I've been trying
>> to understand what the value space of XML Schema means, given that
>> it doesn't mean what one would expect in a mathematical sense.
>
> I'll have to take exception to that. I'm sure it doesn't mean what
> you
> would expect in a mathematical sense. But it does very definitely
> mean
> what I would expect in a mathematical sense. (Credentials: Phd, U.C.
> Berkeley, 1965, primarily in Analysis and Foundations of Mathematics;
> Assistant Professor of Mathematics and Computer Science, and Associate
> Professor of Mathematics at various times during my career.) So
> please
> don't generalize to an arbitrary "one" and imply that that's the only
> possible reasonable expectation.

I'm sorry for the overgeneralization and didn't mean to insult. It's
just that as much as I think about it, I can't understand the idea
that the value space of floats and the value space of decimal are
disjoint. Fundamentally these represent some of the same real numbers
and this isn't reflected in the spec. In addition, many numbers that
can be finitely expressed and be calculated with find no place in
*any* of the value spaces, e.g. 1/3. It is this sense of
"mathematical" that I was referring to.

I have looked at the functions and operators specification. I
understand how you come to your previous points about different
choice of equality, as the specification promotes decimal to float.
As a matter of clarity, I probably would have called the comparison
not "equality" but "equality as floats" and "equality as doubles".

Considering the definition of equality, I would ask: Is that
something someone would do if they weren't constrained to use
floating point numbers? It is a perfectly reasonably thing to do if
you don't have have any more expressive numeric types, as it is a
perfectly reasonable thing to do to throw an exception when a
multiplication of integers exceeds the limit of the integer datatype.
However we now have libraries that support arbitrary precision
integer and rational numbers. Floats can be promoted to the latter
without loss of precision, as can decimal. Again, no addressing of
this in the spec, nor any theoretical justification of how it is even
possible to do an exact (sometimes) promotion of a decimal value to a
float value if their value spaces are disjoint. Maybe there's a way
to make sense of this. I'm trying.

To offer a concrete suggestion (I'll get to putting something into
the bug tracker...), and speaking to the possibility of harmonizing
the OWL specification and the XSD specification, something to
consider would be to add xsd:real and xsd:rational. This could at
least prevent the (strong) possibility of OWL defining those types
itself. Personally, I think it would be cleaner to have all the
numeric types handled in the XML Schema documents. I realize that
this might be a bit of work, but at least that work would have
interested parties from both the OWL and XSD WGs.

I'd also consider reviewing the part of the spec that says:
> Should a derivation be made using a derivation mechanism that
> removes ·lexical representations· from the·lexical space· to the
> extent that one or more values cease to have any ·lexical
> representation·, then those values are dropped from the ·value space·.
>
>

I've still no understanding of why that is a desirable thing to do,
and we've discussed aspects that some might consider undesirable.

>> Similarly, there seems to be missing an underlying type for the
>> date types - although there is reference to timeOnTimeline, this
>> value type is not surfaced in the type hierarchy.
>
> I'd very much like to hear how you'd do this; unlike the number
> datatypes,
> where I could envisage how to pull them together, I can't envisage a
> reasonable way for all the d/t datatypes to be derived from a
> universal
> one. And I did try.

I had in mind subtyping the dates into those with and those without a
timezone, and having each descend from a separate timeOnTimeline.

>> One thought is that whether a correct interpretation is more along
>> the lines of considering the value spaces as data structures.
>
> I'm curious what you mean by "data structure" here. Reading on, it
> sounds
> like you mean various possible machine representations of the values.
> Let me assure you that that's not what is meant by a value space. In
> fact, I can think of several extremely different-appearing
> representations
> of, for example, the integers, that are nonetheless isomorphic. They
> are all potential machine representations of the values for the same
> datatype. XSD does not have anything to say about machine
> representations,
> except to say that if an implementation has two different
> representations
> of the same value, it is obligated to generally treat them the same.

Again, it is trying to wrestle with the disjointness of float and
decimal value spaces that is leading me to look for some explanation.
While XSD does not explicitly speak about machine representation,
that does not mean that those concepts do not (overly) influence the
specification. To explain myself a bit further on this kind of
analysis - I spend a lot of time developing ontologies, and searching
for unspoken, but operant, knowledge and constraint and then exposing
it is a common aspect of this work.

What I specifically mean by data structure in this case was the
little data structure that is a floating point number, composed of
part: integer mantissa, integer exponent, sign bit, +some symbols
encodings. I compared that to integer which doesn't have these parts.
However decimal seems to necessarily be composed of different kinds
of parts.

>> Another thought is that the value spaces are another aspect of
>> lexical expression. This would account well for there being a
>> difference between base64Binary and hexBinary, but not explain why
>> these are not pattern facet restrictions on string.
>
> base64Binary and hexBinary are different because they use entirely
> different
> lexical mappings. Different lexical mappings mean different
> datatypes.

But not disjoint value spaces.

> Except for our decision to paint the two value spaces different colors
> so we can tell them apart,

Why would one want to tell them apart? Why not consider a single
lexical mapping that has a disjunction? More than one lexical can map
to the same float, more than one lexical representation of a bit
sequence can map to it.

> the value spaces of these two datatypes are
> the same. (In this case, I suspect that the obvious equality across
> these two value spaces would not bother anyone. But we weren't going
> to do that for some obvious datatype pairs and not others.

It's the obviousness, and the spec's decision to not respect that
obviousness that is my concern.

> They are not pattern-facet restrictions on string for the same
> reason that
> float and double are not pattern-facet restrictions on string. The
> value
> spaces are different. String values are character strings; the
> xxxBinary
> values are bit-strings. Bits aren't characters.

Fair enough. My mistake.

>> Finally, I wonder if you have comments on a couple of other
>> aspects of datatypes that appear in XML schema. Specifically, data
>> types that are derived by list and time and date types. Clearly
>> such concepts or similar are relevant to OWL given work on, e.g.
>> workflow, or in spatial reasoning. Where do they fit into your
>> view of OWL class space?
>
> You both should definitely look up the latest Public Working Draft (a
> Last Call draft) for XSD. I think it might clear up some of the
> questions,
> hopefully providing a better understanding or description of list
> datatypes and date/time datatypes.

Have been. Will be doing more.

-Alan

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

2008-07-05T02:40:47Z

>>> Putting aside the issue of whether or not it's possible to use
>>> (only) the XML Schema datatypes to represent meaningful and
>>> implementable OWL datatype value spaces, I expect that there is
>>> consensus that when users were writing `xsd:float` and
>>> `xsd:double` without values in OWL 1.0, what they really meant was
>>> "any number".
>
> I don't know what users meant :) I would think that they should use
> xsd:decimal if that was their intend (or perhaps the new
> owl:rational/real).

I'm providing you with my experience: every user I've ever spoken to
about this topic has wanted the real number line.
They are used to using the xsd datatypes `float` and `double` to
represent number values, so they use these without values in OWL to
mean "some number".

My experience is that the use of xsd datatypes as value spaces in OWL
1.0 causes users to write what they don't mean. My experience is that
*every* ontology using `xsd:float` and `xsd:double` without values
would be better off using `xsd:decimal`, but that the user intent was
"some real number" (and I should note that I'm against requiring
support for `xsd:decimal` values). And my expectation is that users
would be much less confused if this distinction between the types used
for specific values and the types used for value spaces were clear.

To repeat: as an implementor, I did willfully implement semantics
contradictory to the spec, and I will do so again for OWL 2.0 if the
spec is "broken" in the same way.

> When I am working as a user, I generally, both in programming
> languages and in kbs, am very careful about computational types and
> numerical methods. Its easy to find extensive discussions in
> programming language circles about the pitfalls of floats. All
> things being equal, it doesn't seem to be that difficult to
> recommend that they use a more suitable type such as decimal.
> Indeed, that is what's been happening as more and more programming
> languages bundled in decimal types.

I am also a very careful programmer, and am familiar the details of
the IEEE spec.

All the good programmers I've ever worked with are aware of the basic
problems with floats but almost always use them when they mean "any
real number" anyway. The mental model I use, and that I encouraged
among junior programmers, was that floats were "real numbers, but
assume that they wiggle around a little all the time". Not technically
correct, but a safe and useful mental model for programming. The point
being that density of the number line is *not* an issue programmers
encounter as a matter of course, and one for which their natural
intuition might well be wrong.

>>> No user ever intended to restrict the semantic space to a nowhere-
>>> dense number line. If the OWL spec presupposes that most of our
>>> users would a prefer a number line which does not include 1/3, my
>>> choice as an implementor would be to once again ignore the spec
>>> and be intentionally non-compliant.
>
> An alternative choice is to signal that a repair is required and
> perhaps do it.

I hereby signal that a repair to the OWL spec is required. (Are we
really pretending that everybody thought datatypes in OWL 1.0 were
fine and dandy?)

>>> Doing what all my users want and expect in this case turns out to
>>> be way way easier than doing what a broken spec would require. Any
>>> working group who would produce such a spec would clearly be
>>> putting their own interests (ease of spec authoring and political
>>> considerations) above their duty to their intended users.
>
> I think your rhetoric flew ahead of reality here. It's not actually
> easier to spec this (as the ongoing battle has shown :)). As you
> well know, it's much easier to give in to Boris than not to :) I
> don't believe I'm particularly motivated by political considerations
> per se. I do think that departing from existing behavior
> (disjointness) and normal meaning (in computer science) needs to be
> done carefully.

Let me expand upon my rhetoric:

1. Users want a (dense) real number line.
2. Users expect a (dense) real number line when they write `xsd:float`
in OWL 1.0 ontologies.
3. OWL 1.0 implementations reason as though the `xsd:float` value
space is dense.
4. The OWL 1.0 specifications state that the `xsd:float` value space
is nowhere-dense.

If you disagree about the first two points then it's certainly worth
discussion: Alan's [investigation](http://lists.w3.org/Archives/Public/public-owl-wg/2008Jul/0103.html
) seems to support my experience on point 1. I have yet to see a
single counter-example to point 2---and I've asked many users what
they meant when they wrote their datatype restrictions.

I admit I haven't done a comprehensive survey on point 3, but it's a
point of fact and not opinion so we should be able to gather evidence
one way or the other.

The crux of my rhetoric is that points 1--3 (if you accept them)
completely and utterly trump point 4. "Existing behavior" is *not*
what the OWL 1.0 spec says. It's what OWL users (implementors and
ontology authors) are doing.

> Given that some people have already asked for NaN support (of some
> form) and that one of the most championed use cases is managing
> scientific computation results, I don't think we can be too quick to
> alter things.

I agree that it's an issue, and as a member of the public I don't
intend to get mightily bogged down in details of the solution to be
chosen. I'd think that NaN occurs quite rarely, and that semantics
such as "any real" would suffice, but I don't have strong opinions on
the issue.

>>> (Note that in the course of the discussion I read on public-owl-wg
>>> the notions of "dense" and "continuous" seem to have become
>>> confused. I think the notion of density is probably the only one
>>> that makes a difference in terms of current OWL semantics, since
>>> number restrictions can cause inconsistencies in non-dense number
>>> lines, but continuity is really what users have in their heads.)
>>>
>>> The [XML Schema datatype spec](http://www.w3.org/TR/xmlschema-2/)
>>> is focused on representing particular values, not on classes of
>>> values. The notion of "value spaces" is used within the spec, but
>>> only in service of representation of values
>
> I'm not sure what you mean. It seems clear that the spec is all
> about classes of values (i.e., types) and their relations.

I mean that the problems that spec is designed to solve involve
values, not sets of values. The most complex reasoning the XML Schema
people have in mind is model checking, not satisfiability and
consistency reasoning. Thus we can't necessarily expect their spec to
have addressed all the issues which arise in our quite different
context.

>>> I strongly encourage the working group to publish a spec which
>>> provides for the following types of semantic spaces:
>>>
>>> 1. A countably infinite, nowhere-dense datatype. I.e. the integers.
>>>
>>> 2. A countably infinite, dense datatype. I.e. strings.
>>>
>>> 3. An uncountably infinite, dense, continuous datatype. I.e. the
>>> reals.
>
> These are all on the agenda. The first two were in OWL1 and the
> third is being worked on as part of the n-ary data predicate
> proposal, but is separate from it (i.e., I believe it will be added
> regardless of the fate of n-ary).
>
> (Note that this will likely be the algebraic reals and only rational
> constants. So, no transcendentals. I'd be interested in your view on
> that. I can imagine adding the trans. but would prefer to defer it
> until a later iteration.)

This getting ridiculous---so you're saying you think there is a
substantial user base who need to be able to specify that a value is
the solution to some algebraic equation? I have absolutely no idea
what perspective the working group is taking here---what implementor
or user has expressed interest in anything other than the real number
line???

Can you guys please just come up with a version of the [`numeric`](http://www.w3.org/TR/xmlschema-2/#rf-numeric
) notion? Pretty please?

>>> I don't particularly care what each of these three is called; as
>>> long as OWL specifies the internal semantics of these three types
>>> of spaces, then it's straightforward to "implement" the datatypes
>>> users will actually want in terms of them. But, of course, the
>>> ability to use XML Schema Datatypes to encode specific values
>>> within each of these spaces would be quite convenient
>
> Do you mean the lexical spaces?

I mean the only time I explicitly want XML Schema is when my
implementation is parsing specific values provided by the user. If you
happen to re-use the XML Schema spec for other things that is for your
own convenience, not mine.

>>> ---and would use the XML Schema specification for *exactly* what
>>> it's good at.
>
> The additional question is whether to require additional types that
> are not the above three. Among these are float and double. My belief
> is that if we are going to add such datatypes as required, and we
> are going to take them from xsd, then they should reflect the
> semantics of those types and our advice to users is to only use them
> if they specifically intend those semantics.

I'd guess that using xsd names for value spaces will just (continue
to) confuse users.
More importantly, and yet again, I have never ever encountered a user
who would prefer to use the `float` or `double` value spaces if a
`real` value space were available. If there are users who feel the
other way, then please produce them---merely hypothesizing their
theoretical existence does not seem useful. (I grant that the class is
satisfiable. I contend that its size is vanishingly small in practice.)

> The n-ary predicate definition system will, at most, be over the
> core three types above (e.g., polynomial or linear inequations with
> rational coefficients over the reals ). However, one can pretty
> easily imagine a predicate definition system that was focused on the
> floats and was sensitive to the various semantics. It wouldn't have
> to be direct floating point based equations, but an interval
> arithmetic system which was designed to help reason about
> measurements and computations (and their errors).

I care not a whit for n-ary datatypes. I might implement them if
they're in the spec; I might not. But if the spec says you need to use
n-ary datatypes to get real numbers, and leaves the issues raised with
the `float` value space in place, I will ignore the spec and implement
the real number line for unary datatypes. Just like I did for OWL 1.0.
As a member of the public, that is my feedback to the working group.

> I grant entirely that that use case is quite speculative at the
> moment. But given that 1) we have alternatives for the "any number"
> type and 2) cardinality reasoning with the floats is not very much
> more difficult that with user defined finite ranges over the
> integers (except for the fact that users have to do much more work
> to get there), I don't think we should muck with the semantics of
> floats.

I strongly disagree with 2. I don't want my implementation to care
about the difference between `double` and `float`, and I consider any
line of code I write involving the internals of float representation
to be a wasted line of code, because my users really don't care.

Much more importantly, it's my job to turn your spec into user-facing
documentation and support, and there is not a chance in hell I'm going
to explain this issue to my users. They don't care, and they don't
want the semantics you are describing. Experience with OWL 1.0 has
demonstrated this.

> Your feedback and insight are, as always, appreciated. I hope you
> see that my position doesn't *quite* fall into the error you are
> rightly concerned with. There's still the problem of educating
> people about float and double, but that is a problem of long
> standing :)
>
> I'll also admit up front that I *like* float and double as they are.
> I think that IEEE binary floating point is a amazingly clever thing.
> But then, I've always worked in programming languages that had
> bigints and fractions available, so been spoiled for choice :)

I'm a big fan of balanced ternary. But I don't intend to implement
that, either.

-rob

smime.p7s (3K) Download Attachment

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

2008-07-04T22:58:47Z

[Since this discussion is going to other lists, let me explain that I'm
a member of the Schema WG, and I work primarily on datatypes. Although
this message was directed from Alan Ruttenberg to Rob Shearer, I'm
going to inject comments since it went to the general WG lists as
well.]

At 4:56 PM -0400 2008-07-04, Alan Ruttenberg wrote:

>Thanks for your comments Rob. It occurs to me that both the XML
>Schema and the OWL working groups are in progress, that this is an
>issue that touches both groups, that having the specifications be
>able to be read in conjunction without confusion as to their
>relationship would be beneficial to overall efforts of the W3C
>towards harmonization and the implementors and users of those
>specifications.
>
>Perhaps we can take advantage of the felicitous timing to ensure
>that our respective specifications are consistent with each other by
>ensuring that terms are used in the same way, if necessary adding
>clarification, and by attempting to have any additional datatype
>concepts needed for a good OWL specification be incorporated into
>the XML Schema specification.

I'll leave comments on this aspect to others who are more up on precise
development/publication schedules.

>Towards the end of understanding the terminology, I've been trying
>to understand what the value space of XML Schema means, given that
>it doesn't mean what one would expect in a mathematical sense.

I'll have to take exception to that. I'm sure it doesn't mean what you
would expect in a mathematical sense. But it does very definitely mean
what I would expect in a mathematical sense. (Credentials: Phd, U.C.
Berkeley, 1965, primarily in Analysis and Foundations of Mathematics;
Assistant Professor of Mathematics and Computer Science, and Associate
Professor of Mathematics at various times during my career.) So please
don't generalize to an arbitrary "one" and imply that that's the only
possible reasonable expectation.

>Similarly, there seems to be missing an underlying type for the date
>types - although there is reference to timeOnTimeline, this value
>type is not surfaced in the type hierarchy.

I'd very much like to hear how you'd do this; unlike the number datatypes,
where I could envisage how to pull them together, I can't envisage a
reasonable way for all the d/t datatypes to be derived from a universal
one. And I did try.

>One thought is that whether a correct interpretation is more along
>the lines of considering the value spaces as data structures.

I'm curious what you mean by "data structure" here. Reading on, it sounds
like you mean various possible machine representations of the values.
Let me assure you that that's not what is meant by a value space. In
fact, I can think of several extremely different-appearing representations
of, for example, the integers, that are nonetheless isomorphic. They
are all potential machine representations of the values for the same
datatype. XSD does not have anything to say about machine representations,
except to say that if an implementation has two different representations
of the same value, it is obligated to generally treat them the same.

>Another thought is that the value spaces are another aspect of
>lexical expression. This would account well for there being a
>difference between base64Binary and hexBinary, but not explain why
>these are not pattern facet restrictions on string.

base64Binary and hexBinary are different because they use entirely different
lexical mappings. Different lexical mappings mean different datatypes.
Except for our decision to paint the two value spaces different colors
so we can tell them apart, the value spaces of these two datatypes are
the same. (In this case, I suspect that the obvious equality across
these two value spaces would not bother anyone. But we weren't going
to do that for some obvious datatype pairs and not others.

They are not pattern-facet restrictions on string for the same reason that
float and double are not pattern-facet restrictions on string. The value
spaces are different. String values are character strings; the xxxBinary
values are bit-strings. Bits aren't characters.

>Finally, I wonder if you have comments on a couple of other aspects
>of datatypes that appear in XML schema. Specifically, data types
>that are derived by list and time and date types. Clearly such
>concepts or similar are relevant to OWL given work on, e.g.
>workflow, or in spatial reasoning. Where do they fit into your view
>of OWL class space?

You both should definitely look up the latest Public Working Draft (a
Last Call draft) for XSD. I think it might clear up some of the questions,
hopefully providing a better understanding or description of list
datatypes and date/time datatypes.
--
Dave Peterson
SGMLWorks!

davep@...