=Paper=
{{Paper
|id=Vol-2325/paper-06
|storemode=property
|title=golog++ : An Integrative System Design
|pdfUrl=https://ceur-ws.org/Vol-2325/paper-06.pdf
|volume=Vol-2325
|authors=Victor Mataré,Stefan Schiffer,Alexander Ferrein
|dblpUrl=https://dblp.org/rec/conf/kr/MatareSF18
}}
==golog++ : An Integrative System Design==
https://ceur-ws.org/Vol-2325/paper-06.pdf
golog++ : An Integrative System Design
Victor Mataré Stefan Schiffer Alexander Ferrein
Mobile Autonomous Systems and Cognitive Robotics
FH Aachen University of Applied Sciences
52066 Aachen, Germany
vances in planning. The response then usually has
to justify it as a worthwhile endeavour since there is
Abstract no reason (yet) to just drop the middle ground be-
tween planning and programming. Golog’s verifia-
Golog is a language family with great un- bility, generality, extensibility and transparency (e.g.
tapped potential. We argue that it could be- w.r.t. accountability) are also often mentioned as re-
come a practical and widely usable high-level deeming features.
control language, if only it had an implemen- In our view however, the reasons why Golog is not
tation that is usable in a production environ- really gaining the practical impact it deserves, are be-
ment. In this paper, we do not specify an- yond the scope of most Golog-related research. From
other Golog interpreter, but an extensible a robot manufacturer’s point of view, Golog is sim-
C++ framework that defines a coherent gram- ply not a feasible option due to numerous usability and
mar, developer tool support, internal/exter- engineering issues.
nal consistency checking with clean error han-
dling, and a simple, portable platform inter-
The Status quo and related work
face. The framework specifically does not im-
plement language semantics. For this purpose There is a wealth of different implementations, and
we can simply hook into any of the many exist- although diversity can be a good thing, the Golog
ing implementations that do very well in im- family is missing technical coherence beyond the the-
plementing language semantics, but fall short ory. Each implementation sports unique and valuable
in regards to interfacing, portability, usability features, strengths and weaknesses. Documentation
and practicality in general. (aside from theoretical papers) on any of those is, how-
ever, sparse or nonexistent. To even figure out which
Introduction one might fit a project’s requirements, a programmer
needs to be educated in formal logic to sift through
As of 2018, we can safely say that the Golog [11] the pertinent academic literature. Porting features be-
language family is still far from realizing its potential tween implementations can be tedious and error-prone
as a practical high-level robot control language. The- since there are no explicit extension points and no in-
oretically, the idea of freely interleaving planning with ternal consistency checks. In fact, most implementa-
traditional imperative programming should be at the tions do not even have any external consistency check-
core of how complex robot behavior is implemented ing: Calling an action whose precondition is unsatis-
today, but for practical reasons, most high-level con- fied, for instance, yields the same result as calling an
trol is still either finite state machines or specialized undefined action. While the former is a perfectly valid
imperative code. programming technique, the latter constitutes a mal-
The reasons for this are manifold. In an academic formed program which could easily be rejected with
context, the criticism is often leveled at Golog’s run- an explicit error message pinpointing the exact cause
time complexity and supposed obsoleteness due to ad- of the error. In general, the complete absence of such
error handling in most Golog implementations makes
Copyright c by the paper’s authors. Copying permitted for
private and academic purposes.
debugging a larger codebase impossible within a rea-
sonable time budget.
In: G. Steinbauer, A. Ferrein (eds.): Proceedings of the 11th In-
ternational Workshop on Cognitive Robotics, Tempe, AZ, USA, All of the Prolog-based implementations also tend
27-Oct-2018, published at http://ceur-ws.org to blur the line between the language and its imple-
29
mentation. This issue has been noted before, e.g. PRS/OpenPRS [9] and the ecosystem around them
by [5]. Here, we want to emphasize that the Prolog are worth noting because they also serve the purpose
implementation-level is not just sometimes abused for of a high-level control language, but found much wider
dirty hacks. On the contrary, it is even deliberately use than any Golog dialect. However *PRS does not
exposed as a quasi-legitimate meta-language to encode set itself apart through better theoretical foundations
domain restrictions or to enumerate program elements. or through greater expressivity. The issue where *PRS
While this can certainly be a powerful tool to the ex- clearly has the lead on any Golog dialect is usabil-
pert programmer, it can also make any code unread- ity, developer support, integration, i.e. tool support in
able if used irresponsibly. To the language learner, this general.
metalanguage proves a conundrum, precisely because The same applies to the C-Language Integrated
it is also the implementation language (i.e. it is ef- Programming System [18, CLIPS, cf.]. From a the-
fectively undefined!) and can be used to manipulate oretical view, the language should be less expressive
anything, including the language semantics. and less practical for high-level control application
The last major issue that cannot go unmentioned is than Golog. But nonetheless, it is used much more
interfacing with the real world. Usually, it boils down widely1 . While some of CLIPS’ lead on Golog could
to some Prolog clause like be explained by the more general, rule-based language
execute ( Action , History ) : - impl ( Action ). paradigm, its clear advantages are still a coherent lan-
where impl(Action) is some Prolog code that takes guage specification and well-designed, stable C/C++
care of triggering the real action, e.g. in the behav- bindings.
ioral layer of some robotics framework. One notable It is not like Golog’s potential had not been widely
exception to this otherwise minimalistic approach is noticed. It played a prominent part in the Semantic
IndiGolog [1], which comes with a more elaborate Web hype (cf. e.g. [12] with thousands of citations),
interfacing called the Environment Manager. Its use and it has been used for high-level control of soccer
case is however for one IndiGolog agent to control N playing robots [3] as well as for domestic service robots
disparate execution environments via TCP/IP. Today, [17]. However unlike OWL [7], it never made the leap
this is obsoleted by robotics frameworks that provide out of the academic laboratories. Again, observe how
a coherent, component-based view on a robot [15, 14]. OWL is supported by a rich set of interoperable tools
Such frameworks typically offer network-transparent that help with visualization, error checking and debug-
component APIs [16], so that Indigolog’s 1 : N over ging, while Golog is not.
TCP capability just adds unnecessary complexity, on
top of the cruft of embedding Prolog on the remote How to fix it
end to basically just unmarshal a TCP packet into an
action call. We can summarize the issues outlined above as a gen-
In general, we can see that the interfacing logic eral lack of tool support and usability which makes
of most Golog implementations doesn’t go any fur- Golog infeasible as a practical high-level control lan-
ther than the execution system specified by [6]. For guage. So what features should an implementation
N robot platforms and M Golog implementations, have to make it useful in actual robotics scenarios?
N × M platform interfaces need to be written since Important groundwork on this question has been done
none of the interfacing code is portable between either by [5]. Here, we want to expand on that while shift-
robotics frameworks or Golog implementations. ing the focus towards a more condensed and flexible
All of these problems combined keep Golog from architecture.
gaining a critical mass of supporters that could sustain First of all, we have to differentiate two major user
a community that is interested in a good implementa- roles: The language user (e.g. an application devel-
tion. oper), and the language developer (e.g. a maintainer
Outside of the Golog community, we see more di- or an extension developer). The non-functional re-
verse approaches to high-level interfacing. The Seman- quirements that follow are relevant to these roles in
tic Robot Description Language (SRDL) [10] imple- varying degrees. The requirements Q1 through Q4
ments a framework that describes a robot platform follow directly from general guidelines of usability, as
with its components, and how they can be used to described e.g. by [2]. They apply mainly to the role
realize certain actions. As such, it serves a different of the language user. Q5 to Q8 on the other hand
purpose, namely mapping an abstract action concept are most relevant to the language developer, and they
to a realization strategy on a particular robot plat- 1 See also 418 questions tagged “clips” on stackoverflow
form. To the framework we envision here, actions are (stackoverflow.com/questions/tagged/clips) vs. 2 questions
opaque units, so a system like SRDL could be used as tagged “golog”
an action execution backend. (stackoverflow.com/questions/tagged/golog).
30
correspond directly to the fundamentals of software framework that puts the main emphasis on extensi-
engineering. bility and practicality. With that, the resulting func-
tional requirements are significantly slimmed down in
Non-functional requirements comparison to [5]:
Q1 Familiarity Ensure that commonly known lan-
guage constructs do what the programmer intu- Functional requirements
itively expects. F1 Parse Golog programs written in a specifically
designed syntax.
Q2 Readability Be syntactically “easy on the eye”,
i.e. let the visual structure reflect the syntactic F2 Represent the parsed program in a concise, type-
structure (to help with skimming code). safe object model. Reflect the type safety in all
extension points and in the parser.
Q3 Learnability Actively support the user in devel-
oping an understanding of the language’s syntax F3 Run the program represented by the object
and semantics. Make errors traceable to their model, re-using as much code from the existing
cause, give a clear and specific hint at what is implementations as possible.
wrong.
F4 Execute actions found by running the program
Q4 Visibility Support implementation of visual edit- on any robot or simulation environment.
ing frontends, i.e. code browsing, semantic code
highlighting and interactive debugging. F5 Map sensors to exogenous actions/events as
specified by the program.
Q5 Extensibility Define a clear path to introducing
new language features and robot interfaces while F6 Monitor action execution to support failure han-
ensuring internal consistency as well as possible. dling and self-maintenance.
Q6 Minimalism Don’t bloat. Don’t reinvent the
So here, we deliberately do not specify language se-
wheel. Implement what is missing, re-use good
mantics since that is exactly what we want to keep ex-
code. Use minimal indirection, especially at run-
tensible. What do need is a coherent interfacing frame-
time.
work that takes care of everything other than language
Q7 Separation of concerns Eliminate internal de- semantics, namely the functional requirements F1 to
pendencies where possible. Concentrate external F6, in a manner that satisfies the non-functional re-
dependencies in few, well-specified interfaces. quirements Q1 through Q8. In general, all of the non-
functional requirements should be applied to all of the
Q8 Maintainability Keep external interfaces com- functional requirements to varying degrees. Q7 Sepa-
patible. Be OpenSource. Be contributor friendly ration of concerns and Q8 Maintainability apply
through good nomenclature, readable code and to the system as a whole and are thus equally impor-
concise, instructive documentation. tant to all of the functional requirements.
The YAGI interpreter [5] went a long way towards
The golog++ interfacing framework
Q1, Q2 and Q3 by defining a specialized language
syntax and implementing it in a proper parser. Q5 was From the functional requirements, we can derive three
considered in regard to robot interfaces, but in regard global system concerns: Representation of the Golog
to the language itself, the focus was on specifying and program (including parsing), static and runtime se-
implementing the full language semantics, effectively mantics, and acting/sensing e.g. on a physical robot
spawning yet another golog dialect (hence the name). platform. They are represented in Figure 1 as dashed
This of course conflicts with Q6. Thought was also areas. Since we want to be extensible both in the plat-
put into Q7 and Q8, mainly by employing a clean form interface and in the language semantics, these
coding style and using appropriate design patterns. main concerns are linked together through interfaces
We have to embrace the fact that the majority of that make a compromise between generality and strict-
Golog-related research deals with semantic variants ness.
and extensions. Another significant push in expres- Other than in YAGI, for instance, the parser does
sive power can be expected from the convergence of not instantiate an auto-generated syntax tree that con-
machine learning with knowledge-based systems. So tains unnecessary syntactic detail, but a concise, hand-
what we need at this time is not another Golog im- designed class model (the metamodel component in
plementation, but a language design and interfacing Figure 1). The parser is written in templated C++,
31
golog++ representation $fluent loc ( $x ) {
«component» «component» initially :
metamodel «use» parser ( b ) = table , ( a ) = b
construct }
«Interface»
action stack ( $x , $y ) {
Transition precondition :
acting/sensing semantics $x != $y // Can ’ t stack x on itself
& $x != table // Can ’ t move the table
& ! exists ( $z ) ( // There is no z ...
«Interface» «Interface» «Interface»
PlatformBackend ExecutionContext Semantics
loc ( $z ) == $x // ... that is on x
| loc ( $z ) == $y // ... or on y
)
effect :
«component» «component» «component»
RosPlatformBackend EclipseExecutionContext ReadylogSemantics
loc ( $x ) = $y ;
}
«use» «use»
?function goal ()
«component» «component» { return loc ( a ) == table & loc ( b ) == a ; }
ROS readylog interpreter
search while (! goal ())
pick ( $x ) pick ( $y )
Figure 1: High-level architectural view of the golog++ stack ( $x , $y );
framework with exemplary ROS/ReadyLog backends.
Component and interface boundaries imply separa- Figure 2: A simplified golog++ code example from
tion of concerns and independent extensibility. Core the blocksworld domain. The $ sign declares fluents,
golog++ interfaces and components have a shaded fill. variables and functions as symbol-valued, so loc(·) is a
Exchangeable backend components have a white fill. functional fluent, and e.g. loc(a) = table means that
The dashed/colored areas represent the three system the block a is on the table, where a, b and table are
concerns. all symbols that have to be defined as members of the
so the metamodel is usable and enforced in the gram- fluent’s domain. Here, this happens implicitly through
mar definition as well. An instance of the metamodel the initially: section in the fluent’s definition.
represents the basic action theory and the procedural elements are either void-valued Statements (i.e. in-
code that together form a Golog domain/program. structions in a procedural code block that may fail
Restrictions in the metamodel apply particularly to to execute) or expressions that are syntactically ex-
the extensible type model, syntactic constraints that changeable with constant values of the same type. The
follow from expression types, referential integrity and type system is designed to extensible, and the types
extension consistency. It conforms to the following BooleanExpression, NumericExpression and Symbolic-
(tentative and incomplete) specification: Expression are always defined.
References can refer to any Variable or Global, and
Representation concern (language metamodel) they inherit from a type alias exposed by their target
The golog++ metamodel encompasses two sets of class that determines what type of expression a refer-
classes: The static program representation, and the ence to that class will be. So while Variables and Glob-
runtime state. Elements of the static program repre- als themselves are not constituent expressions, Refer-
sentation are classes that can form a BAT (like Flu- ences to them are.2
ent, Action, EffectAxiom), procedural code (like Func- Certain expressions by definition have a different
tion, Pick, Search, Conditional, etc.), and formula con- type than their constituents. For example poss(ρ) and
stituents like Conjunction, Negation, Quantification do(ρ) are both boolean expressions for a (void-valued)
and so on. Of the runtime state representation, only action or procedure ρ. The ternary expression φ1 ?φ2 :
the Transition interface is shown in Figure 1, since it φ3 has the type (T (φ3 ) = T (φ2 )), if T (φ1 ) = Boolean.
links together the three main system concerns. Oth- For the sake of rigidity and clarity, there is no im-
ers, such as the History, might not even need explicit plicit type conversion, e.g. comparisons can only be
representation in all implementations. made between identical types and the result is always
Declarations and definitions of functions/proce- a boolean value. Every complex formula has the type
dures, actions and fluents are Globals (cf. Figure 3, 2 cf. Figure 3. Note that the UML standard has no syn-
only actions and fluents shown), which means that by tax for describing this pattern, so we emulate it by represent-
themselves they are toplevel entities and cannot be ing TargetT::ExprT as a separate interface that can be either
constituents of another expression. All other program BooleanExpression or SymbolicExpression.
32
of all its parts. Since all type-dependent code (includ- «Interface» «Interface»
Global Expression
ing the parser) is templated, the restrictions specified
above are enforced by the C++ compiler, even within
the grammar definition. Implementing a new expres- «Interface»
BooleanExpression
«Interface»
SymbolicExpression
sion type in the metamodel automatically instantiates
all needed templates where possible. Where manual «substitute» «substitute»
template specialization is required, it is enforced by «Interface»
ExprT
the C++ compiler.
Scopes are also represented explicitly in the static «import»
expression_t
metamodel. Each Scope holds a reference to its parent ExprT: Interface TargetT: Class
Fluent Reference
scope, and it can resolve any symbol that is contained 1 + reference
+ target: TargetT [1]
in itself or in one of its parents. + target *
«bind»
The parser reads a program in golog++ syntax (like EffExprT>
the example in Figure 2) and instantiates these meta-
«bind»
model classes to form a graph that represents the pro- Fluent>
gram as an interconnected C++ object structure. The Action EffectAxiom
EffExprT: Interface
+ precond: BooleanExpression [1] + fluent: Reference [1]
code example in Figure 2 would (among others) pro- + effect: EffectAxiom [*] + action * + value: EffExprT [1]
+ condition: BooleanExpression [1]
duce an instance of the Action class called “stack”, 1 + effect
which accepts two symbol-valued arguments. As pre-
condition, an Action can accept any BooleanExpres-
sion, which in this case would be an instance of the
Figure 3: Simplified UML class diagram showing a
Conjunction class, which is again made up of Com-
small fragment of the golog++ language metamodel.
parisons and a Quantification. Via the nesting of
Most class properties, operations and connectors are
constituents, the program’s object representation thus
omitted to focus just on how the Action, EffectAxiom,
forms a syntax tree. References like the calls to the
Fluent and Reference classes relate to the expression
goal() function and to the stack($x, $y) action in
types.
the main program can interconnect the objects across
the syntactic tree’s branches, thus forming a (possibly following Prolog clause:
cyclical) graph that represents the program’s referen-
tial (call) structure. Each expression in a program is prim_fluent ( loc ( X )) : - member (X , [a , b ]).
represented by a unique object, and none of these ob-
Here, the argument variable X and the domain symbols
jects are copyable since their exact place within the
a, b and table are each constituents of their own, so
syntactic tree is part of their identity.
the fluent’s semantics delegates to their semantics for
producing the respective Prolog terms.
Semantics concern
After compilation, all Semantics implementations
Every language element in the metamodel owns a spe- must be in a state that allows the ExecutionContext
cific implementation of the Semantics interface that to test the main program for the next Transition and
is attached after a program’s object representation is for the final state. These methods are also specified by
fully constructed. The core interfaces (i.e. all shown the ExecutionContext and realized by its implementa-
in Figure 1 and the entire metamodel ) do not make tion. The EclipseExecutionContext shown in Figure 1
any assumptions about how the Semantics interface is for example embeds an eclipse-clp interpreter, loads
realized. To give a program its semantics (i.e. to make ReadyLog [4] and uses its trans/4 and final/2 pred-
it executable), the ExecutionContext recurses twice icates to implement runtime. A Transition created by
along the syntax tree of all Global s and of the main an ExecutionContext implementation is a parameter-
procedure. On the first recursion, every program ele- ized Action. When a legal Transition is found, it is
ment is visited by a factory (leveraging runtime poly- passed to the PlatformBackend for execution.
morphism) that assigs a unique instance of a specific The ExecutionContext also provides access to Exo-
Semantics implementation to it. On the second recur- gEvent objects that are created from sensor data as
sion run, the ExecutionContext delegates to a virtual well as from state changes in platform components
method in its concrete implementation that must use or in action execution. An ExecutionContext imple-
each element’s Semantics to prepare it for execution mentation must consume these events and apply them
(e.g. by compiling, initializing runtime state, etc). to the runtime state implementation of the current
So for the fluent declaration loc($x) in Fig. 2, the golog++ program (usually by incorporating them into
ReadylogSemantics (cf. Fig. 1) would produce the the history).
33
Acting/sensing concern C++ external predicates that implement appropriate
debugging hooks.
The PlatformBackend accepts a Transition object,
Type safety is important to support Q3
and its implementor must use that to trigger an action
Learnability since knowing the type of an ex-
on some target platform. A PlatformBackend imple-
pression allows for a much more descriptive code
mentation must also select and retrieve the sensor data
model. In particular, references can be resolved
and other runtime state that is needed to instantiate
statically, which allows for implementation of proper
the ExogEvent objects as specified by the golog++ pro-
code browsing (Q4 Visibility). Using the type of
gram. A more precise specification of this interface is
an expression to restrict the grammar allows us to
subject to currently ongoing work.
catch many more cases of accidental misuse of symbol
references and other expressions.
Discussion and rationale
Q5 Extensibility, Q6 Minimalism, Q7 Separa-
This specification and its current implementation al- tion of concerns and Q8 Maintainability are again
ready satisfy large portions of the functional and non- a set of non-functional requirements that tend to go
functional requirements. Q1 Familiarity is mostly hand in hand. Together, they form the technical foun-
a given since the procedural semantics of Golog are dation for continued proliferation of any piece of soft-
already aligned with traditional imperative program- ware. In golog++, we achieve Minimalism by deal-
ming. Employing a familiar C-like syntax then makes ing purely with the three main concerns of represen-
the imperative Golog code immediately recognizable tation, semantics and acting/sensing. It is important
to all programmers that know e.g. C/C++, Java or to note that only the representation concern (parsing
JavaScript. A C-like syntax has been chosen over the into an instance of the metamodel) has a stand-alone
Pascal-like variant employed in YAGI since it is more implementation, i.e. it is the only one that does not
widely used, and we expect better visual ergonomics depend on some external implementation of abstract
by using punctuation (i.e. curly braces) as block de- interfaces to run. The metamodel’s static and run-
limiters. Q2 Readability is further helped by using a time state representation forms the (singular!) inter-
C++ class-like notation for Golog action definitions face through which the semantics and acting/sensing
(again inspired by YAGI), with “precondition:” and concerns interact. Consequentially, Q7 Separation
“effect:” as section markers within the action’s defi- of concerns in golog++ means that anything con-
nition block. However we have dispensed with YAGI’s cerned with semantics or acting/sensing can ever only
way of notating a fluent as a 0-arity functional symbol depend on the metamodel, while the metamodel can
that denotes a set of n-tuples. Instead, we returned ever only depend on the abstract acting/sensing and
to the classical SitCalc-like notation with n-ary func- semantics interfaces.
tional or relational fluents, which should be more rec-
ognizable to developers with e.g. a PDDL background. Conclusion and outlook
The goal of Q3 Learnability is of course closely
related to Q1 Familiarity, Q2 Readability and Q4 The golog++ language grammar will be a more ded-
Visibility. A typical Golog developer may likely be icated subject in future work when the syntactic ex-
proficient in other languages, but given its currently tension points are developed. The mid-term vision is
limited pervasion, we have to assume that he/she is to support namespacing and language profiles similar
unfamiliar with the Situation Calculus or any other to OWL [13].
Golog dialect. The most important tools to sup- One use case of the golog++ framework is the Con-
port Q3 are type safety and interactive debugging (i.e. TrAkt project, where the Golog language will be ex-
single-stepping a live program with viewable runtime tended to support platform self-monitoring and au-
state). tonomous, platform-aware failure recovery. To that
Support for interactive debugging is limited in the end, a language specification for platform constraint
current ExecutionContext implementation since the modeling is in development. Its goal is to allow
interpretation of all procedural code is encapsulated domain-independent encoding of platform details so
within the toplevel trans/4 call to the ReadyLog in- that domain modellers don’t have to worry about plat-
terpreter. To achieve full support for interactively form quirks [8]. It will make use of extension points in
single-stepping procedural code, an ExecutionContext the acting/sensing concern (i.e. the abstract platform
implementation would have to handle each procedu- interface) which are yet to be specified. It will also
ral statement individually. An alternative would be to require syntactic extensions and possibly an external
change the implementations of all language elements constraint solver to be embedded via an Execution-
to not assert/1 or compile/1 plain Prolog predicates Context implementation.
representing the Golog program, but to register as The design goals of the framework presented here
34
are flexibility, extensibility, usability and ease of de- [8] T. Hofmann, V. Mataré, S. Schiffer, A. Ferrein,
ployment. Its most important feature is to decouple and G. Lakemeyer. Constraint-based online trans-
Golog reasoning, program representation and plat- formation of abstract plans into executable robot
form interfacing. Consequentially, to serve N plat- actions. In AAAI Spring Symposium 2018 on
forms with M different language semantics, we sim- Integrating Representation, Reasoning, Learning,
ply need N platform interfaces and M semantics, in- and Execution for Goal Directed Autonomy, Stan-
stead of N × M leaky abstractions like before. Decou- ford, CA, USA, 2018.
pling also allows us to use the right tool for the job:
[9] F. F. Ingrand, R. Chatila, R. Alami, and
Modern, templated C++ for metamodeling, interfac-
F. Robert. PRS: A high level supervision and con-
ing and outer control flow, and Prolog (or other AI-
trol language for autonomous mobile robots. In
affine languages) for the implementation of language
IEEE International Conference on Robotics and
semantics and reasoning.
Automation, volume 1, pages 43–49, 1996.
The complete source code of the golog++ frame-
work is freely available at https://github.com/ [10] L. Kunze, T. Roehm, and M. Beetz. Towards se-
MASKOR/gologpp.git. mantic robot description languages. In IEEE In-
ternational Conference on Robotics and Automa-
Acknowledgments tion, pages 5589–5595, 2011.
This work was supported by the German National [11] H. J. Levesque, R. Reiter, Y. Lespérance, F. Lin,
Science Foundation (DFG) under grant number FE and R. B. Scherl. GOLOG: A Logic Programming
1077/4-1. Language for Dynamic Domains. Journal of Logic
Programming, 31(1–3):59–84, April-June 1997.
References
[12] S. A. McIlraith, T. C. Son, and H. Zeng. Semantic
[1] G. De Giacomo, Y. Lespérance, H. J. Levesque, web services. IEEE Intelligent Systems, 16(2):46–
and S. Sardina. Indigolog: A high-level 53, Mar 2001.
programming language for embedded reasoning
agents. In Multi-Agent Programming:, pages 31– [13] B. Motik, B. C. Grau, I. Horrocks, Z. Wu, A. Fok-
72. Springer, 2009. oue, C. Lutz, et al. OWL 2 web ontology language
profiles. W3C recommendation, 27:61, 2009.
[2] A. Dix, J. Finlay, G. D. Abowd, and R. Beale.
Design rules. In Human-Computer Interaction, [14] T. Niemueller, A. Ferrein, D. Beck, and G. Lake-
chapter 7, pages 258–288. Pearson Education meyer. Design principles of the component-based
Limited, 3rd edition, 2004. robot software framework fawkes. In Interna-
tional Conference on Simulation, Modeling, and
[3] A. Ferrein, C. Fritz, and G. Lakemeyer. Using Programming for Autonomous Robots, pages 300–
golog for deliberation and team coordination in 311. Springer, 2010.
robotic soccer. KI, 19(1):24, 2005.
[15] M. Quigley, K. Conley, B. Gerkey, J. Faust,
[4] A. Ferrein and G. Lakemeyer. Logic-based robot T. Foote, J. Leibs, R. Wheeler, and A. Y. Ng.
control in highly dynamic domains. Robotics and ROS: an open-source robot operating system. In
Autonomous Systems, 56(11):980–991, 2008. ICRA workshop on open source software, vol-
[5] A. Ferrein, G. Steinbauer, and S. Vassos. Action- ume 3, page 5. Kobe, Japan, 2009.
based imperative programming with YAGI. In [16] M. Reichardt, T. Föhst, and K. Berns. An
Proceedings of the 8th International Conference overview on framework design for autonomous
on Cognitive Robotics. AAAI Press, 2012. robots. it-Information Technology, 57(2):75–84,
[6] D. Hähnel, W. Burgard, and G. Lakemeyer. 2015.
GOLEX – bridging the gap between logic [17] S. Schiffer, A. Ferrein, and G. Lakemeyer. Cae-
(GOLOG) and a real robot. In O. Herzog and sar – An Intelligent Domestic Service Robot.
A. Günter, editors, KI-98: Advances in Artificial Journal of Intelligent Service Robotics, 23(Special
Intelligence, pages 165–176, Berlin, Heidelberg, Issue on Artificial Intelligence in Robotics: Sens-
1998. Springer Berlin Heidelberg. ing, Representation and Action):259–273, 2012.
[7] P. Hitzler, M. Krötzsch, B. Parsia, P. F. Patel- [18] R. M. Wygant. CLIPS – a powerful development
Schneider, and S. Rudolph. OWL 2 web on- and delivery expert system tool. Computers &
tology language primer. W3C recommendation, industrial engineering, 17(1-4):546–549, 1989.
27(1):123, 2009.
35