Re: [RIFRAF] ACTION 173: Initial Ontology for Action Language Discriminators

Hassan Aït-Kaci <hak@ilog.com> wrote on 04/25/2007 09:45:48 AM:

> Axel (and Leora) - the correct word is "INERTIA". It is used to mean
> that things stay unchanged unless explicitly transformed - i.e. frame
> axiom. See e.g. 
http://www.cs.utexas.edu/users/tag/cc/tutorial/describing.html


Ah, inertia!! 
Thanks, Hassan. The joke's on me about that one; I started working on the 
frame problem back in the late 80s. And still I had trouble recognizing 
"inertia" in its jumbled form....  :-)

Anyway, Alex, as regards your comment, reinterpreted now ( ;) ), yes, it 
is certainly the case that different action languages treat the principle 
of inertia in different ways. I alluded to that in point 3.k, but I will 
certainly make the point more explicit in the ontology. And, once I add in 
individual languages to the ontology, I'll be sure to specify which 
languages have explicit vs. implicit formulations.

Leora

> .
> 
> -hak
> 
> Axel Polleres wrote:
> 
> > 
> > Leora Morgenstern wrote:
> > 
> >>
> >>
> >> public-rif-wg-request@w3.org wrote on 04/25/2007 04:24:57 AM:
> >>
> >>  >
> >>  > Leora Morgenstern wrote:
> >>  > >
> >>  > > Attached please find the initial pass at an ontology for action
> >>  > > languages (Action 173).   > >
> >>  > >
> >>  > > Some remarks on the ontology.
> >>  > >
> >>  > > 1.I built my ontology on top of the ontology that Allen Ginsberg 
had
> >>  > > created for Action 173 (ontologizing semantic discriminators). 
This
> >>  > > approach has the advantage of dealing with at least some 
integration
> >>  > > issues from the start, instead of deferring them to a later 
date.
> >>  > >
> >>  > > 2. As discussed during earlier telecons, I broadened the 
original
> >>  > > mandate for this action, which was to create an ontology for
> >>  > > discriminators for  ECA (event-condition-action) rules, which 
are 
> >> used
> >>  > > mainly to describe updates to databases. I looked at the more 
> >> general
> >>  > > problem of discriminators for AI action languages.
> >>  > > These more general action languages would seem to be needed to 
> >> represent
> >>  > > the use cases in the UCR document. (For example, in the use case 

> >> Ruleset
> >>  > > Integration for Medical Decision Support, one reasons about 
various
> >>  > > medical events, such as Bob’s Hb1AC levels increasing, 
the 
> >> doctor
> >>  > > prescribing various medications, Bob’s reactions to them, 

> >> and Bob’s
> >>  > > taking a medical test.) ECA rules, which are much narrower in 
> >> scope, can
> >>  > > be considered a subset of general action rules.
> >>  > >
> >>  > > Examples of such general AI action languages include the 
situation
> >>  > > calculus, the event calculus, the fluent calculus, temporal 
action
> >>  > > logics, and  the action description languages \cal{A}, and 
\cal{C}
> >>  > >
> >>  > > 3. These languages share certain features, but differ on other 
> >> features.
> >>  > > A list of features of interest follows:
> >>  > >     > > a. Division into sets of sentences: domain description, 
> >> observation
> >>  > > sentences, queries. /(It is almost universally accepted to have 
> >> at the
> >>  > > first two classes of sentences in action languages.)/
> >>  > > b. Intervals vs. time points. vs. both /(E.g., the event 
calculus 
> >> has
> >>  > > both time points and intervals; sitcalc has situations/time 
points,
> >>  > > \cal{A} has time points.)/
> >>  > > c. Discrete time vs. continuous time /(Situation calculus: 
discrete
> >>  > > time; fluent calculus,  event calculus: continuous time)/
> >>  > > d. Branching time vs. linear time; branching forward only vs. 
> >> branching
> >>  > > both forward and backward /(Event calculus: linear time; 
situation
> >>  > > calculus: forward branching time.)/
> >>  > > e. Causation as an explicit relation vs. concept explicit in 
rule 
> >> and/or
> >>  > > material implication. /(Explicit in \cal{C}; implicit in 
temporal 
> >> action
> >>  > > logics, EC, SC.)/
> >>  > > f. Causal rules; state constraints
> >>  > > g. Concurrency: concurrency disallowed; concurrent processes 
> >> allowed,
> >>  > > but can’t have them starting at exactly the same time
> >>  > > (asynchronicity).  /(Fluent calculus, event calculus: 
concurrency
> >>  > > allowed; vanilla sitcalc; only one action at a time; extended
> >>  > > (Reiter-style) situation calculus: asynchronicity.)/
> >>  > > h. Explicit agent vs. implicit agent
> >>  > > i. Single agent vs. multiple agent
> >>  > > j. Determinism vs. non-determinism
> >>  > > k. Solving the frame problem: monotonic solutions (explanation 
> >> closure
> >>  > > axioms; Reiter) vs. nonmonotonic solutions (using 
> >> circumscription, or
> >>  > > answer-set semantics, e.g. together with an appropriate 
> >> formulation of
> >>  > > the commonsense law of inertia)
> >>  >
> >>  > Note that a further distinction in the action languages you 
> >> mention, is
> >>  > that interia is not always implicit.
> >>
> >> Could you let me know what "interia" is? I googled, but that didn't 
help.
> > 
> > 
> > basically frame axioms, ie that atoms (also called fluents in these 
> > languages) keep there value if not affected by any action over a state 

> > change. Intertia can be defined "per fluent" in some of these 
languages...
> > 
> >>  >As far as I remember, it is in
> >>  > \cal{A}, but not in \cal{C} (or the related language \cal{K} which 
we
> >>  > developed in Vienna during my thesis...)
> >>  >
> >>  > In that context, it would maybe also, even be worthwhile to look 
into
> >>  > planning languages like PDDL.
> >>  >   The PDDL work might by itself be interesting, since it is also 
> >> kind of
> >>  > a family of languages around a common core, where features can be
> >>  > added/left out, maybe providing some inspiration for the extension
> >>  > mechanism for dialects...
> >>  >
> >>  > Axel
> >>
> >> Axel, I think it would be very interesting to look at PDDL --- I 
agree 
> >> that the way
> >> it has been developed, over time, from a common core, could be a 
model
> >> for how we develop methods for RIF's handling of different dialects 
> >> (down the road).
> >>
> >> I will also look at \cal{K} --- thanks for the reference!
> >>
> >> In the meantime, however, as Chris and Sandro pointed out yesterday, 
I 
> >> need
> >> to refocus this work on RIF's short-term goals and the RIF Core. This 

> >> means
> >> less focus, at least in the short term, on many of the distinctions 
that
> >> I've thus far put in the ontology, which are model-based and/or based 
on
> >> the method of inference.
> > 
> > 
> > fair enough.
> > 
> > best,
> > axel
> > 
> >> Nevertheless, I agree with you that it's important for us, as we 
continue
> >> in this work, to be aware of as many of the languages, systems, and 
> >> issues that are out
> >> there, as possible.
> >>
> >>  >
> >>  > > l. All actions have preconditions and effects. Can also have 
failure
> >>  > > conditions and success conditions. (Success conditions different 

> >> than
> >>  > > preconditions.)
> >>  > >
> >>  > > 4. The different features are sometime superficial, but may 
reflect
> >>  > > different deep-seated foundational assumptions. Different sets 
of
> >>  > > assumptions underlying these languages could make translation 
> >> difficult.
> >>  > >  Of importance is the growing set of results on methods of 
> >> translations
> >>  > > between various pairs of languages (e.g., between TAL and 
sitcalc,
> >>  > > fluent calc and various formalisms).
> >>  > >
> >>  > > 5. The exercise of constructing the ontology brought to light 
some
> >>  > > interesting questions regarding the categorization of these 
> >> features.
> >>  > >  Does the distinction between single agents and multiple agents 
> >> belong
> >>  > > to the model or the theory? What about the distinction between 
the
> >>  > > concurrency and asynchronicity? I’ve done a first effort 
> >> at addressing
> >>  > > these issues, but they remain open for discussion.
> >>  > >
> >>  > > Best regards,
> >>  > > Leora
> >>  >
> >>  >
> >>  > --
> >>  > Dr. Axel Polleres
> >>  > email: axel@polleres.net  url: http://www.polleres.net/

> >>  >
> >>  >
> >>  >
> >>  >
> > 
> > 
> > 
> 
> 
> -- 
> Hassan Aït-Kaci  *  ILOG, Inc. - Product Division R&D
> http://koala.ilog.fr/wiki/bin/view/Main/HassanAitKaci

> 
>