Re: SEM: semantics for current proposal (why R disjoint V?) (sameState TEST)

What you seem to want is to use datatype values as "keys", and I can
see why this might be useful. 

Unfortunately, the interaction of UnambiguousProperty and datatypes
makes this problematical. Imagine, for example, that a datatype
consisting of integers in the range 0-999 is used as a unique-id/key
for instances of the class Person such that all persons have exactly
one unique-id, all unique-ids are integers in the range 0-999, and
unique-id is an UnambiguousProperty.  In order to function correctly,
a reasoner is now required to understand the properties of datatypes,
e.g., that the cardinality of this particular datatype is 1,000, and
that as a result no model can contain more than 1,000 instances of
Person (note that this would not be the case if unique-ids were reals
in the range 0-999). 

The formal properties of the resulting logic are not well understood
(e.g., it is not clear yet if the language would be
decidable). Moreover, it would cause severe problems for implementors
and might be a source (admittedly not the only possible source) of
crippling intractability: remember that, unlike a database, the
existence of 2,000 individual names would not be an error, but would
lead to the inference that the names must be partitioned into 1,000
sets of "sameIndividuals". Check out the number of ways that 2,000
elements can be partitioned into 1,000 sets - it is a big number!

This is an irresistible opportunity for a very nice citation [1] :-). 
Sadly, Stirling does not seem to have made this work available on
his web site.

Regards, Ian

[1] Stirling, J. Methodus differentialis, sive tractatus de summation
et interpolation serierum infinitarium. London, 1730. English
translation by Holliday, J. The Differential Method: A Treatise of the
Summation and Interpolation of Infinite Series. 1749.

On April 23, Dan Connolly writes:
> On Tue, 2002-04-23 at 17:23, Ian Horrocks wrote:
> > On April 8, Pat Hayes writes:
> [...]
> > > so these issues seem largely irrelevant; whereas the inconvenience 
> > > and artificiality of maintaining the restriction is a real barrier to 
> > > deployment. There is no *semantic* reason for the distinction.
> > 
> > W.r.t. the domains, the interaction between the concept language and
> > the built in datatype predicates is at best unpleasant and may even
> > lead to undecidability (no definitive result at present). I also don't
> > believe that this is "a real barrier to deployment" (can you show me
> > examples where users really need objects that are both individuals and
> > data values?).
> Fair question. It comes up quite a bit in my work.
> I don't make any claims about 'individuals'; but
> I need to have UnambiguousProperty's that
> take literal values.
> For example, U.S. states that have the same 2-letter
> postal code are the same state. So if I know
>   :stateCode a ont:UnambiguousProperty.
>   _:x :stateCode "KS".
>   _:x :population "2688418".
>   _:y :stateCode "KS".
>   _:y :stateBird :WesternMeadowlark.
> then I should be able to conclude
>   _:z :population "2688418".
>   _:z :stateBird :WesternMeadowlark.
> Full details, with namespaces spelled out and all that, in:
> > I believe that a much bigger barrier to deployment
> > would be devising a language where complete (and perhaps even sound)
> > reasoners were difficult or impossible to build.
> Yes, well, we disagree on that.
> Perhaps it belongs in the issues list? I don't see
> it there.
> It is in the list of objectives.
>   Effective decision procedure
> Perhaps that's enough? or perhaps each objective should
> have a corresponding issue?
> -- 
> Dan Connolly, W3C

Received on Sunday, 28 April 2002 14:02:26 UTC