W3C home > Mailing lists > Public > public-owl-wg@w3.org > November 2007

Re: XML Schema datatypes

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Thu, 15 Nov 2007 12:14:24 +0000
Message-Id: <E17517BA-14EF-4CCB-B9F4-13A715377DF7@cs.man.ac.uk>
Cc: "Web Ontology Language (OWL) Working Group WG" <public-owl-wg@w3.org>
To: Carsten Lutz <clu@tcs.inf.tu-dresden.de>

On 15 Nov 2007, at 10:28, Carsten Lutz wrote:

> On Thu, 15 Nov 2007, Bijan Parsia wrote:
>>>>> *We* are *not* defining a schema language for (stored) data in the
>>>>> sense of XML Schema. So it is a valid question whether or not  
>>>>> the XML
>>>>> Schema datatypes are also good for our (different) purposes. I  
>>>>> believe
>>>>> they are not.
>>>> I think this is too strong. Sometimes users use OWL for *high  
>>>> level* conceptual modeling, but sometimes one is refining the  
>>>> conceptual model a bit based on some more concrete aspects. why  
>>>> should they have to switch out from OWL just because they need  
>>>> to account for representation limits? What about modeling  
>>>> database schemas?
>>> I feel that deductions that actually *rely* on the boundedness or  
>>> fixed
>>> precision are (almost?) never desired.
>> Even if so, they may rely on disjointness of types. For example,  
>> if I'm modeling an attribute with a float value in one schema and  
>> an integer value in another, it's useful to get a class if I claim  
>> classes with these (functional) attributes are equivalent.
> You could also say: If you *claim* these are equivalent, you should
> not get an inconsistency, but rather deduce that the class which has
> floats can only have integer values, stored as floats.

Well, in OWL they are disjoint :)

> That's what you
> would get when using mathematical datatypes instead of machine
> datatypes. In your view, you are reasoning about the representation of
> the class. In my view, I reason about the class.
> I claim that the representation-independent view is much more
> important for an ontology language. Still, you are right that there
> are conceivable applications that want machine datatypes. I admit that
> my view that these should be represented in terms of mathematical
> datatypes is maybe a bit too theoretically motivated.

I didn't quite see that in your argument. What I saw was you  
advocating additional (respectable, in my view) datatypes.

>>>> I don't see that as a fix. And if the issue is merely  
>>>> boundedness then we'd have to chuck user defined datatypes on  
>>>> the integers.
>>> I disagree.
>> If the issue which is sufficient to remove a dataype is that it is  
>> *bounded*, then obviously all bounded types should go. Your more  
>> sophisticated version is that the particular boundedness stemming  
>> from some of the built-in types is undesirable from a modeling  
>> perspective *and* has counterintuitive results.
> Yes, and XML Schema datatypes *force* the user to work with a bound
> that is motivated by data representation. This is different from
> *allowing* them to work with bounds.

Only if don't have enough choice in the base datatypes! xsd:integer  
seems perfectly ok, even if it's rather ickily derived from decimals:

Presumably we could define rationals using xsd lists and integers,  
which wouldn't suffice for all of their properties, but might provide  
some link back.

> Maybe we are not that far apart and could simply sum up the current  
> discussion as: we both want to have mathematical datatypes in OWL 1.1,
> and we believe (maybe to a different extent) that standard users have
> to be educated regarding the consequences of choosing an XML Schema  
> datatype vs a mathematical one.

Yes! That sounds reasonable to me.

> This education issue is not to be taken lightly. If we offer both XML
> schema datatypes and mathematical datatypes, there is a fair chance
> that users will use the XML ones simply because XML is cool and sounds
> more familiar, and then be surprised about the results.

More likely is that tool support (e.g., in Protege4 but also in  
reasoners) will be more comprehensive for XSD types.

Ok, well, moving forward, perhaps you could report an issue on  
"Additional datatypes" to the tracker and perhaps sketch out a  
proposal for what types (and operations on those types) we might  
consider adding? Of course, the racer types are a good start, but I'd  
be interested in a considered proposal.

As for user education, I wouldn't object to a WG note explaining some  
of the issues, esp. if it were under an OpenContent licences so  
people could improve and extend it. Alas, I won't be at the UFDTF  
call today, but I did start a wiki page for this:

Received on Thursday, 15 November 2007 12:12:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:00 UTC