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

On April 29, Dan Connolly writes:
> On Sun, 2002-04-28 at 12:59, Ian Horrocks wrote:
> > What you seem to want is to use datatype values as "keys", and I can
> > see why this might be useful. 
> 
> Good; thanks.
> 
> > 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,
> 
> That is: 'in order to function as Ian would like'. We don't
> have a requirement for complete-and-tractible reasoning.

I protest at this. The charter says that we should have "a formal
semantics to clearly delineate what is, and is not, entailed". The
semantics therefore define the correct functioning of a
reasoner. Whether or not we want or are required to build one is
another issue.

> > 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
> 
> Implementors of complete reasoners, yes, I can see that.

And possibly also for implementors of sound reasoners.

> But I'm having trouble seeing this as a problem users are likely
> to run into in practice. If you could pose a test case that's
> pretty clearly something folks want to do, that might help.
> 
> If this sort of class is a problem,
> I'd prefer to limit cardinality constraints to
> 0/1/2/infinity than give up the sameState functionality.

I believe that I already described the problem. If you use
UnambiguousProperty combined with a datatype to implement keys then a
reasoner will need to understand some of the properties of the
datatype in order to function correctly (i.e., in accordance with the
semantics); I gave an example above. 

I don't pretend to know at this stage all the possible uses that
people might put the language to, which is one reason why I always
argue for designing a language which we can work with (at least in
principal) whatever people write down in it.

Ian

> 
> 
> > and might be a source (admittedly not the only possible source) of
> > crippling intractability:
> 
> I don't find intractibility crippling at all.
> 
> > 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:
> > >   http://www.w3.org/2002/03owlt/sameStateP.rdf
> > >   http://www.w3.org/2002/03owlt/sameStateC.rdf
> > > 
> > > 
> > > > 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.
> > > 
> > > http://www.w3.org/2001/sw/WebOnt/webont-issues.html
> > > 
> > > It is in the list of objectives.
> > > 
> > >   Effective decision procedure
> > >   http://www.w3.org/TR/2002/WD-webont-req-20020307/#section-objectives
> > > 
> > > Perhaps that's enough? or perhaps each objective should
> > > have a corresponding issue?
> > > 
> > > -- 
> > > Dan Connolly, W3C http://www.w3.org/People/Connolly/
> > > 
> > > 
> -- 
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> 
>

Received on Thursday, 2 May 2002 13:54:26 UTC