- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Sun, 7 Apr 2002 13:17:44 -0400
- To: Ian Horrocks <horrocks@cs.man.ac.uk>
- Cc: www-webont-wg@w3.org
>------- start of forwarded message ------- >From: Ian Horrocks <horrocks@cs.man.ac.uk> >To: Dan Connolly <connolly@w3.org> >Date: Fri, 5 Apr 2002 18:33:48 +0100 >Subject: Re: SEM: semantics for current proposal (why R disjoint V?) >Reply-To: Ian Horrocks <horrocks@cs.man.ac.uk> > >On April 5, Dan Connolly writes: >> On Fri, 2002-04-05 at 07:08, Ian Horrocks wrote: >> > On March 21, Dan Connolly writes: >> > > On Thu, 2002-03-21 at 14:28, Ian Horrocks wrote: >> > > > On March 21, Libby Miller writes: >> > > > > > >> > > > > > As noted in the design discussions for DAML+OIL, I don't >> > > > > > see sufficient justification for making V disjoint >> > > > > > from R. >> > > > > > >> > > > > > It seems silly not to be able to talk about the intersection >> > > > > > of two sets of strings, or UniqueProperty's whose >> > > > > > range is dates, or whatever. >> > > > >> > > > This means that any OWL reasoner has to take on responsibility for >> > > > reasoning about types >> > > >> > > I gather when you say "OWL reasoner" you mean a complete >> > > reasoner. >> > > >> > > I'm not very interested in such a thing. >> > > >> > > Regular old horn-clause/datalog reasoners >> > > (with some built-in predicates like >> > > string:lessThan and such) seem >> > > to get me what I need pretty well. >> > >> > Dan, >> > >> > It seems that, on the basis of a few toy examples where using ad-hoc >> > reasoning seems give the results you want/expect, you conclude that >> > this will be appropriate/adequate for all applications. >> >> No, just for an interesting class of applications. >> >> By the way, if you consider >> formalizing the operations of W3C[1] >> to be a toy example, I'm interested to know what >> sort of applications you would take seriously. > >I didn't intend to be pejorative - I was only referring to the examples >I have seen in email. It wasn't completely clear to me from [1] where >the ontology comes in or what kind of reasoning is being performed, >but I am guessing that you are not using a very large or complex >ontology. > >> >> > I don't find >> > this argument very convincing. >> >> As I say, I didn't make that argument. >> >> I'm arguing that we can advance the state of the art >> without a completeness requirement. >> >> > Even w.r.t. ontology level reasoning I expect things to rapidly get >> > large and complex enough that humans wont be able to check all >> > inferences - we will just have to trust that the reasoner got it >> > right. Soundness is therefore essential, and completeness highly >> > desirable. >> >> Yes, soundness is essential. >> >> I don't see why completeness is all that interesting >> in the general case. I expect various reasoners >> to be complete for various classes of problems. > >This is one of the problems with incompleteness - it is notoriously >difficult to characterise "classes of problem" for which such a >reasoner is complete. See [1] for a discussion of this issue. > >> > For example, when multiple processes are interacting, some >> > action may be taken by one process on the basis of a non-inference by >> > another process, >> >> That's non-monotonic reasoning. Part of life in the semantic >> web is: don't do that (without explicit license). > >I don't see that this is non-monotonic. I'm not even talking about >changing any facts. I'm talking about the problems that can arise when >a "negation" is inserted by a process that uses the result of a query >to another process. If that query was not made with an explicit reference to a closed world assumption as part of the query, then the assumption of the truth of the negation from the failure of the query is a nonmonotonic inference step. >E.g., a missile defense system might be programmed >to fire at any incoming aircraft not identified as a friendly. Good example of a nonmonotonic inference which illustrates its dangers. There is a recent true-life example, by the way, involving an unexpected default assumption (see end of this message). >Firing >at a friendly aircraft due incompleteness in the identification >process might reasonably be considered as unsound behaviour on the >part of the overall system. > >> > so incompleteness can easily lead to "unsoundness". >> >> Unsoundness can result from all sorts of bugs; this >> is just one of them. >> >> Actually, unsound/heuristic reasoning can be pretty interesting, > > as long as it's not confused with formal reasoning; e.g. >> >> I conclude based on your recent buying patterns >> that the following products are likely to be >> interesting to you: X, Y, Z. >> >> I didn't arrive at this conclusion based on >> sound reasoning, so take the recommendations >> with a grain of salt. >> >> or >> >> I conclude, based on a search of my extensive >> holdings, that there are no court cases >> in that jurisdiction involving chimpanzees and volkswagens. >> >> Digitally signed, >> The BigLaw online service. > >This might be true, but I fail to see the relevance. The question I am >addressing is, should we design the language in such a way that it is >possible to build sound and complete reasoners for usin in >applications where this is an important issue. No, thats not the question, because that is trivial: there have been sound and complete reasoners for full first-order logic available for the last 30-odd years. Some of them are even quite efficient, these days, on almost all inputs. Pat PS. the example mentioned is described here: Washington Post March 24, 2002 Pg. 21 >'Friendly Fire' Deaths Traced To Dead Battery Taliban Targeted, but U.S. Forces Killed >By Vernon Loeb, Washington Post Staff Writer >The deadliest "friendly fire" incident of the war in Afghanistan was >triggered in December by the simple act of a U.S. Special Forces air >controller changing the battery on a Global Positioning System device he was >using to target a Taliban outpost north of Kandahar, a senior defense >official said yesterday. >Three Special Forces soldiers were killed and 20 were injured when a >2,000-pound, satellite-guided bomb landed, not on the Taliban outpost, but >on a battalion command post occupied by American forces and a group of >Afghan allies, including Hamid Karzai, now the interim prime minister. >The U.S. Central Command, which runs the Afghan war, has never explained how >the coordinates got mixed up or who was responsible for relaying the U.S. >position to a B-52 bomber, which fired a Joint Direct Attack Munition (JDAM) >at the Americans. >But the senior defense official explained yesterday that the Air Force >combat controller was using a Precision Lightweight GPS Receiver, known to >soldiers as a "plugger," to calculate the Taliban's coordinates for a B-52 >attack. The controller did not realize that after he changed the device's >battery, the machine was programmed to automatically come back on displaying >coordinates for its own location, the official said. Minutes before >the fatal B-52 strike, which also killed five Afghan >opposition soldiers and injured 18 others, the controller had used the GPS >receiver to calculate the latitude and longitude of the Taliban position in >minutes and seconds for an airstrike by a Navy F/A-18, the official said. >Then, with the B-52 approaching the target, the air controller did a second >calculation in "degree decimals" required by the bomber crew. The controller >had performed the calculation and recorded the position, the official said, >when the receiver battery died. >Without realizing the machine was programmed to come back on showing the >coordinates of its own location, the controller mistakenly called in the >American position to the B-52. The JDAM landed with devastating precision. >The official said he did not know how the Air Force would treat the incident >and whether disciplinary action would be taken. But the official, a combat >veteran, said he considered the incident "an understandable mistake under >the stress of operations." >"I don't think they've made any judgments yet, but the way I would react to >something like that -- it is not a flagrant error, a violation of a >procedure," the official said. "Stuff like that, truth be known, happens to >all of us every day -- it's just that the stakes in battle are so enormously >high." >Nonetheless, the official said the incident shows that the Air Force and >Army have a serious training problem that needs to be corrected. "We need to >know how our equipment works; when the battery is changed, it defaults to >his own location," the official said. "We've got to make sure our people >understand this." That last is a wonderful example of bad system thinking, by the way. -- --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes
Received on Monday, 15 April 2002 10:57:40 UTC