Re: [OWL-S] Proposal for Making Progress on Process Modeling esp. Preconditons and Effects

pat hayes <phayes@ihmc.us> writes:
>
> >  > 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 (?)

No. In Transaction Logic a statement can change the underlying database state.
If you allow those statements to be defined recursively, then you can't
have an algorithm that in all cases will tell you if an action can be
executed or not.
Without recursion, if the database state is a bunch of DL statements then
execution is probably decidable (may be worth looking into). But then the
question is whether such a combo is useful (e.g., what kinds of services can
be represented in such a formalism).


> >  > > 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.

This seems like an interesting trick. Do you have a reference to a paper
that provides the details? I am still confused by what you said. What are
these "background assumptions which support a default"? Do you use a
default reasoning or not? If you do then I don't see anything radically new
here. If you don't then I'd like to understand how to do this sort of
tricks.


> >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.

I didn't say they are the same. But logic programming/query answering is a
kind of reasoning. 

There is close relationship between some aspects of object-oriented
programming and default reasoning.


	--michael

Received on Thursday, 15 January 2004 22:29:58 UTC