- From: Dan Connolly <connolly@w3.org>
- Date: 29 Apr 2002 09:23:20 -0500
- To: Ian Horrocks <horrocks@cs.man.ac.uk>
- Cc: Pat Hayes <phayes@ai.uwf.edu>, www-webont-wg@w3.org
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. > 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. 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. > 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 Monday, 29 April 2002 10:23:05 UTC