W3C home > Mailing lists > Public > public-owl-dev@w3.org > January to March 2007

Re: IFP and datatype properties

From: Ian Horrocks <horrocks@cs.man.ac.uk>
Date: Thu, 8 Mar 2007 17:11:19 +0000
Message-Id: <9F9FBCDA-7F9C-4F06-8E70-60197AF858F4@cs.man.ac.uk>
Cc: Alex Tucker <alex@floop.org.uk>, public-owl-dev@w3.org
To: Alan Ruttenberg <alanruttenberg@gmail.com>

On 8 Mar 2007, at 16:57, Alan Ruttenberg wrote:

> If I understand the issue, Uli or Ian please correct me, the issue  
> is that datatypes in general don't have the same property of  
> classes that you can invent a new one at will from an infinite set-  
> some datatypes are (large) finite sets and this (at least)  
> complicates things from the point of view of checking consistency  
> and satisfiability.

This is one of the nasty features. Even with infinite datatypes, it  
could be computationally very costly if "keys" are used in a "nasty"  
way, e.g. in TBox constructions. Of course exactly the same problems  
could be caused by "nasty" uses of nominals - the point is that  
nominals aren't typically used in this way.


> I don't believe there is an issue for inverse functional object  
> properties.
> -Alan
> On Mar 8, 2007, at 11:53 AM, Alex Tucker wrote:
>> Alan,
>>> What i have done, for non-compound keys, is create a uri with the
>>> value embedded as a string, use and object property and make that
>>> inverse functional.
>> We've been following a similar pattern, essentially preferring
>> ObjectProperties over DatatypeProperties for the most part.  However,
>> Ian's assertion that the "tractability of reasoning ... depends on  
>> the
>> fact that they are typically *not* used in this way," worries me a
>> little, if, as users, we've all been expecting IFPs to cope.
>> Alex.
Received on Thursday, 8 March 2007 17:11:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:58:14 UTC