- From: pat hayes <phayes@ihmc.us>
- Date: Thu, 15 Jan 2004 18:11:20 -0600
- To: Michael Kifer <kifer@cs.sunysb.edu>
- Cc: public-sws-ig@w3.org
> > Bijan Parsia <bparsia@isr.umd.edu> wrote: >> >> On Jan 15, 2004, at 1:05 AM, Michael Kifer wrote: >> >> >>>>>> "BP" == Message from Bijan Parsia <<bparsia@isr.umd.edu> > writes: >> > >> > BP> We're especially >> > BP> interested if people have *problems* with this approach. >> > >> > Situation calculus is not sufficient for process modeling. You need >> > something like Golog. But Golog is *second order*, not first order. >> >> I'll let Sheila answer this point. >> >> > I believe that Concurrent Transaction Logic satisfies your needs and >> > fits >> > the intuition that Mark had (but couldn't express :-). It is also >> > first-order unless you need default negation. >> >> I'd be interested in a CTL based axiomization of OWL-S. Are you doing >> one for SWSL? > >I am planning to do it this week as part of my SWSL action item. > > >> What features would SWRL need to support CTL? How easy is it to combine >> OWL and CTL? > >These are two orthogonal things. CTL extends predicate calculus, while OWL >(at least, OWL-DL) is a subset of predicate calculus. Of course, it is >a different issue whether one can make a useful combination out of the two. >In my view, the most important thing(s) about DLs are the subsumption >algorithms. It is not clear how and where you are going to use subsumption >when it comes to process models (i.e., sequencing, parallel composition, >loops, etc.). > Hmmm. Some examples seem to spring to mind. For example, iteration with a while loop subsumes iteration up to some definite limit, things like that. (?) That might be useful when reasoning about whether these rules can handle that problem, given that those other rules can; things like that (?) > > > But I also believe that at some level process modeling requires >> > defaults >> > as Benjamin argued in >> > http://ebusiness.mit.edu/bgrosof/paps/beyond-mon-inh-wking-pap >> > -081603.pdf >> >> From what I recall, and from a quick re-skim, the argument there was >> about *relating* process models, or rather, specializing process models >> in a variety of ways. There isn't a large emphasis on that in OWL-S, at >> least at the moment, at least, not the way he discusses. The issue >> we're trying to face is how to effectively present the semantics of an >> individual process model. >> >> It's true that a non-mon approach, from what I understand, helps with, >> e.g., the frame problem, but that can be handled with various other >> forms of the sitcalc. >> >> I think Benjamin's example (in figure 1) can be handled in OWL-S, with >> simpleprocesses, though perhaps not as elegantly. > >You can (almost) always avoid defaults for any particular example by >blowing up specifications and incorporating exceptions directly into the >spec. The problem with this is that this is inelegant, makes it hard to >write the specs, and makes the specs non-compositional. Being explicit about exceptions is silly. Its better if you can just make the default context explicit, and then you get compositionality back but you are monotonic. And having explicit references to the background assumptions which support a default is often very handy, particularly for fault-tracing when things go wrong. They neednt be transparent references, just things like provenances or time-stamps can go a long way. P was derived from A and not-P was derived from B is enough to get monotonicity back, as long as A=/=B. >New exceptions >must be re-incorporated into the specs, etc. The reason why >object-oriented programming became so successful is because it offers a >way to avoid all this complexity. Yes, but (sorry to keep nagging at you) programming and reasoning are not the same. OO programming uses and relies on a state of the VM. There is no VM for entailment. Pat > > > --michael -- --------------------------------------------------------------------- IHMC (850)434 8903 or (650)494 3973 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32501 (850)291 0667 cell phayes@ihmc.us http://www.ihmc.us/users/phayes
Received on Thursday, 15 January 2004 19:22:20 UTC