Re: Where I am about floats, etc.

On 7 Jul 2008, at 08:18, Ivan Herman wrote:

> Bijan Parsia wrote:
> [skip]
>> I think I'm specifically against including xsd:float and  
>> xsd:double as types at all at this stage, and even as our specing  
>> them out as optional. (We shouldn't forbid them; just be silent.)
> I know this is a side issue compared to the main thrust of the  
> discussion but I would still like to understand what 'non including'

That we add no more support than we had in OWL 1.

> and 'be silent' means in this case.

That we don't even say that they are optionally supported. Obviously,  
any system that wants to support them, may.

> What happens to legacy data?

I don't think it's any worse off. We may be generally better off as  
we won't encourage people to support or request support for things  
we've not specced out.

> My feeling is that being silent is not really possible. We should  
> specify what happens if a tool gets an ontology/data that is  
> perfectly o.k. in OWL2 DL or OWL2 EL++ but using, say, xsd:float  
> (or other, non included XSD datatypes, for that matter): should we  
> rule that the data is still o.k. in terms of, say, OWL2 EL++ with  
> an additional warning that the reasoning on datatypes might be  
> shaky, or would that data ruled to be incorrect and state it it OWL  
> Full?

I don't know about OWL Full, but in general, if a tools doesn't  
support a datatype there's a range of things it can do. I think we  
should spec that you are not a conforming OWL 2 processor when you do  
that (say, by being an extension).

> I think something has to be said in the specification somewhere.

I agree, but this is definitely a subcase of what do we say about  
extensions and partial support.

> Personally, I would opt for the former, b.t.w., I suspect that  
> there are already a bunch of OWL1 DL data out there and we would  
> not want to refuse them from a DL point of view...

I guess they would be OWL 1DL with "optional" extensions. We've seen  
that implementations vary in how they treat doubles (and there is  
conflict over what the spec requires and, even then, what  
implementations should do).

> Bijan, how does Pellet treat such cases? I guess you have met this  
> issue in practice...

For double, Pellet does it's own reading (which, apparently, at least  
in disjointness, varies from other implementations). Pellet does have  
a mode (which is, alas, currently on by default; I've filed a bug  
report) in which it drops "unusable" axioms (e.g., transitivity  
axioms if you have a number restriction on a nonsimple role). Brrr.  
Still makes my skin crawl :)

Having an "approximate this ontology" mode or "lax" mode is fine  
(we've discussed this for OWL-R). Whether we spec all that out now  
(sigh; good idea, lots of effort) or leave it for the moment is  
something we should decide on.


Received on Tuesday, 8 July 2008 14:55:26 UTC