Re: IFP and datatype properties

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.

Ian


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