See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/277892587

Description Logic as Programming Language

Conference Paper · October 2014

DOI: 10.1145/2661136.2661139

CITATIONS READS
0 52

1 author:

James Skene
Auckland University of Technology
28 PUBLICATIONS   991 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

TAPAS - Trusted and quality-of-service Aware Provision of Application Services View project

All content following this page was uploaded by James Skene on 24 May 2016.

The user has requested enhancement of the downloaded file.

 Description Logic as Programming Language
James Skene
Auckland University of Technology, New Zealand
jskene@aut.ac.nz
Abstract
This paper introduces the use of Description Logic as a pro-
gramming language, giving: a logic with appropriate con-
cept constructors and sentential forms; some example pro-
grams; requirements for the results of program execution; a
tableau algorithm that provably produces the desired results;
principles for discarding sentences once no longer needed
so that algorithms that take more time than space can be im-
plemented; a worked example of program execution; and a
discussion of outstanding theoretical challenges.
Categories and Subject Descriptors D.3.1 [Programming
Languages]: Formal Definitions and Theory
Keywords Programming Languages; Description Logic.
1. Introduction
Description Logic (DL) is a family of logics, formed by
picking different basic constructors, but all based on the
idea that objects can be described in terms of the concepts
that they participate in – essentially propositions such as
Dog(fred), which asserts that the author’s dog Fred is a
dog – and binary relationships between them called roles,
e.g. Owner(james, fred). Constructors, such as intersection
written u, build more complex concepts for use in assertions
such as (Dog u Female)(fred), to state that Fred is both
a dog and female. DLs are used in applications such as
medical ontologies and the semantic web [11]. For example,
in a sufficiently expressive DL we can state that all websites
about dogs are about pets and that the author’s website is
about Fred – known to be a dog – and now when you ask
for all pet websites, you should get the author’s website
among others. Clearly DLs have their place in applications,
but the topic of this paper is how to use a DL as a basis for
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specific permission and/or a
fee. Request permissions from permissions@acm.org.
Onward! 2014, October 20–24, 2014, Portland, OR, USA.
Copyright
c 2014 ACM 978-1-4503-3210-1/14/10. . . $15.00.
http://dx.doi.org/10.1145/2661136.2661139
controlling what calculations a computer completes. Why
might this be a good idea?
Many programming languages, modelling languages and
data representations give programmers the opportunity to
base their designs on what they know of the kinds of en-
tities that are present in the domain that they are working
with – and the structure and relationships those entities have.
By breaking down large or complex programming problems
along these lines they can be addressed in a piecemeal fash-
ion, building software for each part according to the pro-
grammer’s understanding of it and verifying that it operates
according to expectations before tackling the larger prob-
lem in aggregate. This is a data-oriented, modular, or even
declarative view of programming. The other popular way to
decompose programming problems is in terms of what se-
quences of actions need to be accomplished and their or-
ganisation into processes and procedures – the imperative
viewpoint. Nowhere have these two approaches been com-
bined more successfully than in modern Object-Oriented
(OO) programming languages, which typically permit state-
ments of two kinds, describing the allowable structure and
relationships of objects on the one hand, using types, asser-
tions and other specification elements, and giving commands
to cause objects to be created and operate within these con-
straints on the other.
We know from languages such as Smalltalk and Javascript
that declarative elements are inessential to object-oriented
programming. Programs can give the steps to build an ob-
ject rather than a type specification of what parts it has. On
the other hand, maybe programming can be accomplished
only by describing the types of objects needed – perhaps
standing for actions where necessary – and allowing the ex-
ecution environment to infer the results of execution from
this information? This work started from that question, and
in this paper we show how a particular DL, which we call
ALP, captures the semantics of domains of objects in a way
that makes this kind of programming possible.
Although expressive, ALP lacks the features that a pro-
grammer would expect from a full-blown language for any
real practical purpose. However, we can show two impor-
tant things. First, a tableau algorithm applied to programs
written in this language will generate explicit representations
of the corresponding domains of objects – and some easily-
justified and independent assumptions suggest this should
be the goal of execution. Second, because descriptions of
some objects become available sooner than others during ex-
ecution, and their influence over their neighbours is finite,
such an algorithm can output and discard information as it
progresses. This allows the tableau algorithm, more usually
a theorem-proving approach that delivers a result only on
termination, to be adapted to serve as the engine for long-
running and even non-terminating calculations.
Clearly what we propose differs considerably from a con-
ventional view of OO programming, discarding – for the
time being at least – ideas such as encapsulation and mes-
sage passing that might be considered essential when dis-
cussing object-orientation. But it nevertheless retains the
idea that programming can be accomplished by capturing the
characteristics of domains of – for want of a better word –
objects. Programming using a DL in this way is also similar
but distinctively different to traditional declarative program-
ming paradigms, in which programs are given using other
sorts of abstractions: functions, equations or rules of infer-
ence.
But why bother, other than as an academic exercise to es-
tablish a kind of equivalence between imperative and declar-
ative descriptions of objects? Beyond supporting program-
mers who might prefer to express themselves in this way
rather than some other, the possible benefits include facilitat-
ing software development processes that progress – at least
initially – by refinement of specifications, such as Model-
Driven Architecture (MDA) [4]. Because specification lan-
guages such as UML class diagrams [13] that are used early
on in these processes cannot later be executed, at some point
they must switch to a programming language, usually an im-
perative one. If instead an interpreter could reason with the
specification, automatically creating systems of objects with
the intended structure, this switch could be avoided.
These potential benefits would be unrealistic if DLs were
without merit for actually writing programs, and therefore
nobody would wish to go on to develop a practical language
on these foundations. But in fact ALP seems to have some
nice properties in terms of the economy and flexibility with
which abstractions can be defined and combined. We do not
attempt to systematically examine or prove the benefits of
the language in this paper. However, after describing ALP
formally in Section 2, we give a number of examples in
Section 3 that show what can be achieved. We also draw
some parallels with features of other languages.
Then in Section 4 we give detailed requirements for exe-
cutions based on the idea that required categories of objects
in domains described by ALP programs should be enumer-
ated along with their necessary features. In Section 5 we
present our first main theoretical result, that a tableau algo-
rithm will provably deliver these results. Our second theoret-
ical contribution is to show in Section 6 how outputs can be
generated and memory reclaimed as execution progresses.
Beyond this in Section 7 we discuss what remains to be done
to prove that the language can be executed efficiently.
In Section 8 we present a fully worked example of pro-
gram execution. This was accomplished with the aid of
a prototype implementation, the performance of which is
briefly mentioned.
This work stands at the intersection of research concern-
ing programming languages, program specification and De-
scription Logics. In Section 9 we discuss related work in
these contexts. It is not the first work to consider DLs in a
programming context. Efforts have been made to integrate
Description Logic with rule-based logic programming and
the closed-world assumption, resulting in the field referred
to as Description Logic Programming. In contrast, our work
demonstrates that general purpose programming is possi-
ble using Description Logic alone. This results in a logic-
programming language with an open-world assumption, and
a form other than Horn clauses.
2. A Description Logic for programming
2.1 Abstract syntax
As is usual with DLs, ALP consists of a concept language
establishing the membership of complex concepts in terms
of participation in more primitive concepts, and relationships
defined by roles. Various sentential forms can then be de-
fined to describe constraints on a domain in which objects
participating in those concepts may reside.
Given an infinite alphabet of atomic concepts {A, B, . . .}
and another of atomic roles {P, Q, . . .}, the concept lan-
guage for ALP is constructed according to the following
syntax.
C, D → > | ⊥ | A | ¬C | (C u D) | (C t D) |
∃R.C | ∀R.C | #R ≤ 1 | #R > 1 | R ⊆ S
R, S → P | R ◦ S
We call a concept that is not an atomic concept a complex
concept. More specifically, ¬C is a complement, (C u D)
a intersection, (C t D) a union, ∃R.C an existential quan-
tification, ∀R.C a value restriction, #R ≤ 1 a maximum
number restriction, #R > 1 a minimum number restriction,
and R ⊆ S a containment role-value map. > is the top con-
cept and ⊥ the bottom concept. If a role is of the form R ◦ S
then it is a composite role.
Sentences for our purposes are of four kinds. Given a
set of instance variables {a, b, . . .} we can make: instance
assertions of the form C(a); role assertions of the form
R(a, b); role denials of the form ¬R(a, b); and inequalities
of the form a 6= b. We state that a program K is a non-empty
ordered sequence of sentences.
Given a sentence p let V(p) be the set of instance vari-
ables involved in p, determined as follows: V(C(a)) = {a};
V(R(a, b)) = {a, b}; V(¬R(a, b)) = {a, b}; and V(a 6=
b) = {a, b}. Given a program K and instance variable a we
call the subset of sentences in K involving a the subprogram
for a, i.e. K(a) = {p ∈ K | a ∈ V(p)}.
2.2 Descriptive semantics
The semantics of the concept language are given by an
interpretation function ·I mapping concepts to subsets of the
domain of the interpretation >I (the interpretation of the top
concept in I), and roles to subsets of the pairs >I × >I .
Any interpretation of complex concepts must satisfy the
following constraints:
⊥I = ∅
(¬C)I = >I \ C I
(C u D)I = C I ∩ DI
(C t D)I = C I ∪ DI
(∃R.C)I = {oa ∈ >I | ∃ob .((oa , ob ) ∈ RI ∧ ob ∈ C I )}
(∀R.C)I = {oa ∈ >I | ∀ob .((oa , ob ) ∈ RI → ob ∈ C I )}
(#R ≤ 1)I = {oa ∈ >I | |{ob | (oa , ob ) ∈ RI }| ≤ 1}
(#R > 1)I = {oa ∈ >I | |{ob | (oa , ob ) ∈ RI }| > 1}
(R ⊆ S)I = {oa ∈ >I | ∀ob .((oa , ob ) ∈ RI → (oa , ob ) ∈ S I )}
(R ◦ S)I = {(oa , ob ) ∈ (>I × >I ) |
I I
∃oc .((oa , oc ) ∈ R ∧ (oc , ob ) ∈ S )}
An interpretation I satisfies a program K iff there exists
an assignment function ·A from a superset of V(K) to the
elements of >I such that the following constraints are met
for every sentence p ∈ K dependent on the form of p.
p∈K Constraint
C(a) aA ∈ C I
R(a, b) (aA , bA ) ∈ RI
¬R(a, b) (aA , bA ) 6∈ RI
a 6= b aA 6= bA
If an interpretation I satisfies a program L then infor-
mally we state that the domain >I conforms to K, or alter-
natively that K describes the domain. We freely interchange
the terms domain and interpretation when discussing the ob-
jects that a program might describe, on the basis that there
is normally a reason for judging that some real or imaginary
objects (the domain) participate in certain concepts (the in-
terpretation). For example, the author’s dog can be consid-
ered to participate in some concept Dog because she is a
dog.
Given two programs K and L we state that K entails L,
denoted K |= L iff for every interpretation I then I satisfies
K iff I satisfies L.
A program K is inconsistent if it contains a sentence
⊥(ai ) or entails a program L containing such a sentence.
Note that such programs cannot be satisfied by any domains,
since a domain would have to contain an object to be as-
signed to the instance variable ai , but this object cannot also
be a member of the bottom concept ⊥ since that concept is
defined to be empty.
The semantics of ALP can alternatively be given by
translating the language into First-Order Logic with equality
(FOL); a straightforward translation maps atomic concepts
to unary relations and roles map to binary relations.
3. Programming with ALP
What can be done with the formal elements defined in the
previous section? First, supposing that we restrict ourselves
to a single instance variable, atomic concepts and the usual
propositional operators (u, t, ¬) then we have the same
power to describe a single subject that propositional logic
gives us.
(Dog u (¬Awake t Hungry))(fred)
Here we intend to state that Fred is a dog and if she is
awake she is hungry. The conventional symbols of Descrip-
tion Logic are not much fun to read or write, so here is an
equivalent program in the concrete syntax of our interpreter.
(Dog and (not Awake or Hungry)) (fred)
The sense in which this is a description of a domain of
objects is given by the descriptive semantics. For a given
situation that you can conceive of as a set of objects (come
to the author’s house and look around for example), that
situation is described by the program if you can match up
an object to the instance variable fred such that you judge
the object to be a dog that either is not awake or is hungry
(or possibly both, but not neither). Note that due to the
open-world nature of the language, lots of possible situations
might be described by the same program: maybe next door
has a hungry dog also – note the name of variable (and hence
the dog) should be irrelevant to our thinking about what is
described, only the concepts are significant. Note also that
in OO terms, the subprogram for fred (namely all of the
sentences involving the fred instance variable, in this case
the single sentence making up the whole program) can be
thought of as either an object (representing Fred the dog
specifically) or a class, because if we went to a home for
stray dogs it would be described by the program even if it
contained multiple hungry dogs. We would just have to pick
one and say ‘that is fred’.
In what sense is this a program? Suppose that at runtime
more information about Fred’s status is supplied as input
in the form of an additional fact, Awake (fred). Now the
subprogram for fred is as below.
(Dog and (not Awake or Hungry)) (fred)
Awake (fred)
We can reasonably expect an interpreter for ALP to do
some work for us at this point. We actually want to know
all about Fred in a convenient form. The subprogram above
gives everything we know about Fred, but not very clearly.
Is Fred hungry or not? We might expect the interpreter to
reformulate the subprogram into the following:
Dog (fred)
Hungry (fred)
Awake (fred)
This is computation in the same sense that another lan-
guage might calculate from the expression 1 + 2 the value 3
yielding a result equal to the original but more explicit. What
it means to be explicit in the context of ALP is discussed in
more detail in the next section, but note that achieving it in
this case requires some non-trivial work on the part of the
interpreter – in particular the possibility that Fred is simul-
taneously both awake and not awake must be investigated,
found to be inconsistent and discounted.
Now let us look at a system of two objects – the author
and his dog. We could use an extra variable james by adding
a role assertion owner(james, fred) to the program for this
purpose, but instead we will shift the focus of the program
to the author.
(ComputerScientist and
some owns (Dog and Female)) (james)
Here some owns (Dog and Female) is the concrete syntax
equivalent of ∃owns.(Dog u Female). Note that the instance
variable fred has disappeared, and Fred’s existence is merely
implied by the description of james. But we will expect
the interpreter to make Fred’s existence explicit again by
inventing an instance variable to represent Fred and using
it in sentences that describe Fred directly. We will come to
refer to each subprogram calculated as an output, so this
program will have two as follows. . .
ComputerScientist (james)
owns(james, a 2)
. . . and. . .
Dog (a 2)
Female (a 2)
owns(james, a 2)
Fred is now represented by the automatically generated
variable a 2 – but as we have stated the choice of variable
name is not meaningful. During execution the processing of
the existential quantification (∃) will act a bit like the new
operator in an object-oriented program, causing something
that we know must exist to occupy some space in working
memory. Since we can always use this trick (and others) to
generate multiple objects, our interpreter only accepts a sin-
gle (usually complex) concept as input, which it assumes ap-
plies to an instance a 1. Programs may therefore be written
using only the concept language of ALP not the sentential
forms, although these will appear in output. We would pre-
fer to give the program above as follows, taking advantage
of some syntactic sugar that groups consecutive concepts
into intersections (u) during parsing, with braces to control
precedence.
ComputerScientist
some owns {
Dog
Female
}
We had some conceptual modelling choices to make
when writing this program. We have chosen to represent
Fred’s doghood by an atomic concept, but could equally
have expressed it in terms of her relationship to the author,
i.e. she is his dog.
ComputerScientist
some dog Female
Now we have lost the concept of ownership from the
model. Maybe it was significant, in that everything the
author owns is shabby, including poor Fred. We can get
back the ownership role for fred using a role-value mapping
dog ⊆ owns, which in the concrete syntax is represented us-
ing a colon, and may be interpreted as ‘the author’s dogs are
things he owns’. The rule about the condition of the things
the author owns can be stated using a value restriction (∀).
all owns Shabby
some dog Female
dog : owns
Here dog : owns is acting a bit like a type declaration for
a field in a traditional OO language, or alternatively like the
statement that the class of dogs of the author is a subclass of
the things he owns. The value restriction works like a class
definition, in that it gives at least part of the nature of what he
owns without stating that he owns anything. The subprogram
for the dog will now look like this on output:
Shabby (a 2)
Female (a 2)
dog(a 1, a 2)
owns(a 1, a 2)
Multiple value restrictions may be applied to an instance
across any and each of several roles. Perhaps the author
adopts the policy of only owning female dogs. If we express
this rule using a value restriction, then it is only necessary
to state that he owns a dog, with no more information given
about it. Here something represents the top concept >.
all owns Shabby
all dog Female
some dog something
dog : owns
This demonstrates a pleasing compositional nature for
ALP programs. If we discover more facts about the enti-
ties being described, they can be added providing they are
consistent with what has already been stated. For example,
maybe the author does not care to bathe dogs. We could ap-
pend all dog Dirty to the above program and then Dirty (a 2)
would form part of the output. This hints at possible uses for
this kind of language in software engineering by refinement
of specification.
Although we expect the interpreter to generate a subpro-
gram to represent Fred, having stated she exists, in fact the
above program states that the author has at least one dog, and
therefore also describes situations in which he has more than
one (provided they are all shabby and female). This could
be corrected by a number restriction #dog <= 1, although
this in no way globally restricts the total number of dogs,
only the relationship between owner and dog; the description
would still apply to other owners of of other dogs, provided
they each owned only one. Hence number restrictions do not
eliminate the class/object duality for subprograms, although
the role dog now identifies one object from the perspective
of any object conforming to a 1.
Consider the following program, in which fred is now a
role rather than a variable.
#fred <= 1
some fred Female
fred : dog
#lassie <= 1
some lassie something
lassie : dog
Now it seems reasonable enough to assume that the au-
thor has two dogs, Fred and Lassie, and instance variables,
say a 2 and a 3 will be introduced to stand for them. And
such a scenario is described by the above program, but it
also describes a situation in which the author has only one
dog that may be referred to as Fred or Lassie, and even one in
which the author considers himself to be a dog and refers to
himself by those names. This because no logical reason has
yet been given for any objects to be distinct in the domain.
If necessary the program could be made somewhat less am-
biguous by asserting #dog <= 1, forcing facts about Fred
and Lassie to be unified into a single subprogram, or alterna-
tively all all lassie not Female forcing them to remain apart.
Here is a way to get a lot of dogs:
all dog {
Female
some puppy something
} ({ all a Zero ({ all b Zero some r Zero some c Zero } or
dog.puppy : dog
some dog something
A reasonable execution strategy would be to invent a
dog a 2 in relation dog(a 1, a 2) to the first object a 1, which
now perhaps stands for the author or maybe just the situation
under discussion. This will then be qualified by the value re-
striction, resulting eventually in some puppy something(a 2)
which will then yield puppy(a 2, a 3). Now because the
role assertions dog (a 1, a 2) and puppy(a 2, a 3) hold then
dog.puppy(a 1, a 3) also holds and so the role-value map-
ping can be applied to determine dog(a 1, a 3). Now a 3 can
be qualified as a dog, giving rise to a subprogram a 4 for her
puppies eventually.
This program now models a dog dynasty extending in-
finitely into the future – among other possibilities, such as a
dog that is her own mother – and it may not be reasonable
to expect execution of it to terminate. It demonstrates where
a lot of the expressive power of ALP comes from, beyond
propositional reasoning about individual instances. The con-
cept dog.puppy : dog results in a composite role being rela-
belled to an atomic one, fetching a new member of the clo-
sure of the relationship puppy back into a direct relationship
dog with a 1, which then qualifies it with a description that
again extends the graph of instances.
Leaving dogs behind, can we now write more useful
programs? Unfortunately ALP has no direct support for
arithmetic, so conventional data processing is inconvenient.
But it is not impossible. In the following we define two
three digit numbers with the intention that each digit will be
described by a distinct subprogram, linked by the next role
identifying the next more significant digit. The numbers are
x = 210, y = 102.
some x {
Zero some next {
One some next {
Two all next nothing }}}
some y {
Two some next {
Zero some next {
One all next nothing }}}
Note the use of all next nothing to deny the existence of
more significant digits, with nothing representing the bottom
concept ⊥ that contains no objects. Now we will try to
add these two numbers together. To structure the algorithm
we will model things with the ability to add two digits
together, and other things that can recursively add two lists
of digits together, handling carry in from the addition of less
significant digits if necessary, and making use of the first lot
of things. By analogy to digital electronics we will call these
half adders and full adders respectively. Here is a definition
for the half adders.
all ternary half adder {
({ all b One some r One some c Zero } or
{ all b Two some r Two some c Zero }))} or
({ all a One ({ all b Zero some r One some c Zero } or
({ all b One some r Two some c Zero } or
{ all b Two some r Zero some c One }))} or
{ all a Two ({ all b Zero some r Two some c Zero } or
({ all b One some r Zero some c One } or
{ all b Two some r One some c One }))}))
}
Apparently we are dealing with ternary (base 3) numbers.
We could now try to add the first digits of x and y together
as follows. . .
#a half adder <= 1 next.r : r.next
a half adder : ternary half adder } or
x : a half adder.a {
y : a half adder.b // Or we are done and the carry is the msd
all a.next nothing
Here we do not need to say some a half adder something. all input adder.c all next nothing
This is because qualifying x with the role a half adder.a must input adder.c : r.next
result in an intermediate object, the half adder, being hy- })
pothesised. Subsequently we would expect the result to be }
given by a half adder.r with any carry out referred to by
a half adder.c. But in this case we would be disappointed. In full adder.next : full adder
fact, what would result are nine alternatives representing ev- adder : full adder
ery possible sum. This is because we have not yet stated that all adder some c in Zero
Zero, One, and Two are mutually exclusive concepts. What For simplicity this adder assumes its parameters have the
is needed is some type information for our numbers. same number of digits, but places no limit on what that
all ternary number { length might be. The first carry in is wired to Zero in the
definition of adder. Interestingly this is a generic adder – it
({ Zero not One not Two } or will add numbers with any natural base, but it needs to be
({ not Zero One not Two } or specialised with an appropriate half adder. This is another
{ not Zero not One Two })) example of the flexibility of abstractions in ALP.
#next <= 1
} ternary adder : adder
ternary number.next : ternary number ternary adder.half adder : ternary half adder

Now let us define z to be the result of adding x and y.

ternary half adder.a : ternary number
ternary half adder.b : ternary number #add x and y <= 1
ternary half adder.r : ternary number add x and y : ternary adder
ternary half adder.c : ternary number x : add x and y.a
y : add x and y.b
Equipped with half-adders we can can construct an adder add x and y.r : z
for any number of digits as follows.
The outputs of one possible execution of the above code
all full adder { (in fact that accomplished by our interpreter) are plotted
in Figure 1. The figure was generated from output of the
#c in <= 1 #a <= 1 #b <= 1 #r <= 1 #next <= 1
interpreter using dot [5] with some manual reformatting and
// Add the inputs removal of roles for clarity.
input adder : half adder
#input adder <= 1 4. Requirements for executions
a : input adder.a 4.1 Make required categories of objects explicit
b : input adder.b
We were vague in the previous section about what results an
// Add the carry in interpreter for ALP should produce from a program. Here
carry adder : half adder we look at that question more closely.
#carry adder <= 1 We assume that the programmer produces a description
input adder.r : carry adder.a of a domain of objects, using ALP or a derived language,
c in : carry adder.b with the intent that the results that it1 is interested in will be
exhibited in the common characteristics of the sets of real
// Result is the result of the carry adder
or imaginary objects that may be considered to conform to
carry adder.r : r
its description. By real objects we mean objects in the real
({ world that are being described, like the author. By imaginary
// Either there are more digits to process objects we refer to objects that are invented for the conve-
some a.next something nience of the programmer, like the half and full adders in the
// Next adder uses the same kind of half adder previous section.
next.half adder : half adder As we have seen the semantics of ALP do not constrain
a.next : next.a the identities of the objects in any domain that conforms to
b.next : next.b
input adder.c : next.c in 1 he, she, etc.
 an ALP program. Therefore if any non-empty domain con-
a_1
forms then an unlimited number may be considered to do
add_x_and_y so, formed by the substitution of objects with different iden-
ternary_number ternary_number adder
x y full_adder tities but participating in the same concepts and roles. There-
ternary_adder
fore we must assume that whatever results the programmer
a_2 a_3
a_8
requires can always be stated in terms of the required cat-
Zero Two
egories of objects that a program plus its input entails, i.e.
a b
half_adder those categories of objects for which members can be found
input_adder
ternary_number in all domains conforming to the program. A category of
z
a_10 c_in objects can be identified by a set of criteria X (not neces-
carry_adder
sarily expressed in ALP) that we can match objects against,
r
half_adder such that to belong to the category an object must meet ev-
a_14 a_26
ery criterion in the set. For example, the author’s dog is in a
next next next
Two Zero
category X = {is a dog, is female}. If we avoid specifying
a b equivalent criteria, we can make the category more specific
by adding a criterion to the the set, is shabby, for example,
c a_20
a_18
Zero and more general by removing one.
Why focus only on required categories of objects and
c r
their common characteristics and not on objects and their
a_4 a_6
a_28
a_19 characteristics that might be present in some domains of
One Zero Two
objects conforming to a description but not others? Given
a b
half_adder a conforming domain for an ALP program we can add
input_adder
unrelated objects or indeed involve objects and their relatives
a_36 c_in in irrelevant concepts and relationships without affecting the
domain’s ability to satisfy the program, so since the program
carry_adder
r
half_adder doesn’t make these details relevant we must assume that they
a_51 a_17
are irrelevant.
next next next next
One Zero ALP programs must contain at least one sentence that
a b
must involve at least one instance variable, so every consis-
tent program requires at least one object in any conforming
c a_66
a_40
Zero
domain (to be assigned to the variable), and therefore defines
at least one required category of objects. Probably the least
c r interesting ALP program possible is {>(a)}, which only
a_5 a_7 a_65
establishes that in conforming domains a minimum of one
a_84
Two One One
object must exist, without saying any more about it. More
half_adder specific programs can also be written, for example {A(a)},
a b
input_adder
as can programs implying more than one required category,
a_90 c_in for example {A(a), ¬A(b)}.
The objective of executing such a program is therefore to
carry_adder
r help the programmer – or a subsequent automated system
half_adder

that relies on the output of execution – to understand clearly

a_95 a_52
next
Zero Zero what it is that they want to know in relation to the required
categories of objects implied by a program plus its input,
a b
which we assume is provided at runtime in the form of
c a_115 additional sentences. As we saw in Section 3 this might
c a_92
Zero
require some reformulation, but into what form?
r We assume that the programmer would prefer as output
a_112
statements enumerating the required categories of objects
Zero implied by a program and itemising the criteria identifying
next
those categories. We justify this assumption somewhat by ar-
guing that results will be more understandable in this form.
a_96 The required categories should be enumerated so none will
One
be overlooked, nor any spurious categories assumed. Each
Figure 1. Instances in the addition of two ternary numbers. criterion should be given in a clear way in relation to a puta-
tive member of a category (see below). Once a program plus
its input is in this form there will be a straightforward proce-
dure for checking – or possibly constructing – a domain for
conformance: for each required category, identify the pres-
ence in the domain of a conforming object; and to ensure an
object conforms just ensure that it meets each of the criteria
identifying the category.
We expect that the programmer will prefer the criteria
used to identify the outputs to be decomposed into a few
short general statements. Considering two statements p and
q each giving a criterion that an object should meet to be
considered a member of a category, p is more general than
q iff q describes a subset of the objects that p does. In so
far as more general criteria constrain objects less and hence
convey less information than more specific constraints, we
expect that p is easier to understand than q. For example
A(a) is a more general constraint over objects assignable to
a than (A u B)(a). It is also shorter and easier to understand.
If in fact {(A u B)(a)} held then we would prefer to output
{A(a), B(a)}. The hoped-for advantage of this policy is that
the more general statements should individually be more
easily understood, and once apprehended individually, their
effect in combination can then be understood – and that
this leads to an understanding of a result more readily than
attempting to instead digest the implications of fewer more
complex statements.
Shorter statements have the advantage over longer ones
that they require less effort (individually) to parse, and for
this reason we would also prefer output to be shorter where
possible. Similarly if there is a choice between larger or
smaller sets of statements, the smaller set should be pre-
ferred. There is clearly a tension in our requirements. Pre-
ferring multiple short, general statements means accepting
that more statements will need to be output. A balance must
be struck bearing in mind that the overall objective is to con-
vey the results in a manner that is easy to understand, and
perhaps also further process.
Therefore the activity of executing a program of this
kind will be characterised by the occasional emission of
statements to the effect that a distinct required category of
objects has been identified, and what criteria identify the
category. Execution can conclude only once descriptions of
all such categories implied by the program and its input have
been produced. The conclusion of execution thus permits
the inference that any category that has not been output is
not required by the program. This general characterisation of
execution requires several qualifications to be fully practical,
dealt with in the next few sections.
It is reasonable to suggest that the job of a computer pro-
gram is to produce exactly the output that the programmer
requires in whatever language of symbols it prefers, and that
outputting descriptions of objects falls short of this. How-
ever it should be clear that this more general kind of output
could be obtained from execution as we have characterised
it, by writing a program the output of which models a stream
of symbols, for example.
4.2 Avoid redundant output
Sometimes execution should forego outputting a required
category of objects. Since any category identified by n cri-
teria has at least 2n − 1 generalisations (before we consider
how further generalisations could be produced by reformu-
lating the criteria) we do not want to waste time describing
results in a manner that is more general than the programmer
intended.
If we have two categories of objects, identified by sets of
criteria X and Y , and X is a generalisation of Y because a
proper subset of Y , then X should not be output according to
the following argument. If there is not a category of objects
in all conforming domains that are members of X but not
also Y , then X need not be output on the basis that it merely
omits detail, and what it does contain will be given by the
output of Y in any case. If in every conforming domain there
are some objects in X but not in Y then the more general
category X seems to have some significance. But these other
objects form a second more specific category Z such that Y
and Z partition X, and the additional criterion in Z is that
at least one criterion from Y is not satisfied. As required
categories, Y and Z must both be output (assuming they
themselves cannot be made more specific). Should we then
describe the more general category X? It would be a waste
of time to do so, since the details of its criteria are a subset
of those already given for Y and Z, and no object identified
by X has an existence independent of its membership of
either Y or Z. We will overlook for now the possibility of
outputting X in order to simplify the presentation of Y and
Z.
Thus it is more accurately the task of execution to iden-
tify all, and preferably only (but see below), the maximally
specific required categories of objects – those at the lowest
possible level of abstraction. If the programmer is in fact in-
terested in some generalisation of these then outputting their
criteria will provide a superset of what was desired.
4.3 Deliver results when ready
Programs might run for a long time, but often to be useful
should deliver some results before they terminate. For ex-
ample, this is the case for interactive programs, which must
alternate outputs with the receipt and processing of input.
This raises several challenges for programming in the man-
ner that we are considering. First, interesting domains of ob-
jects will usually consist of collections of related objects. If
every object in a category X must be related to an object in
category Y , then a full description of X must include one
of two things: either a full description of the criteria gov-
erning Y , so that when presented with a putative member of
X we can check that it is related to an appropriate object; or
alternatively the criteria in X must make reference to the cat-
egory Y for the same reason, but now to determine whether
an object is in X we must refer to the criteria reported for Y
as well.
The latter option must be preferred. If we chose the for-
mer it would be impossible to output X until the criteria
governing Y had been fully calculated. Since all objects de-
scribed by a program will be in the service of some overall
system we anticipate that all required categories of objects
in typical programs will tend to be related to all others tran-
sitively, so unless cross-references are used then no output
could be produced until execution had completed.
A second consideration is that if the criteria identifying
a category will be output before execution terminates then
ideally it will be with the guarantee that subsequent execu-
tion will not find a refinement of this category, and more-
over that the program will not be found to be inconsistent.
In the former case the criteria should not be output yet, since
the category will subsequently be replaced by a more spe-
cific one. In the latter case the criteria should not be output
at all since the program can have no results, there being no
domains that can conform to the impossible description pro-
vided by the program. Noting that we want our language to
be Turing complete, to avoid restricting the functions that
can be calculated, neither of these decisions can be made in
general according to the following pair of theorems.
Theorem 1. Given a program K written in a Turing-
complete DL, and a set of criteria X that identifies a re-
quired category of objects in domains conforming to K,
there is no way in general to decide if K is consistent before
outputting X.
Proof. Suppose we could tell whether K were consistent
before outputting X. The language is Turing-complete, so
given an arbitrary Turing Machine (TM), M , we could pro-
duce a program modelling M , adapted so that if M enters
a halting state then the program is inconsistent. The criteria
for X will also be given literally in the program, so an early
action on executing the program would be to output X, pro-
vided only that the TM will not halt. Otherwise, execution
would continue without outputting X. But then, by observ-
ing whether X is output or execution continues we could tell
whether M would halt, and hence have a means to answer
the halting problem. But the halting problem is undecidable
in general, so there can be no general mechanism for deter-
mining whether K is consistent before outputting X.
Theorem 2. Given a program K written in a Turing-
complete DL, and a set of criteria X that identifies a re-
quired category of objects in domains conforming to K,
there is no way in general to tell if X will subsequently be
refined before outputting X.
Proof. The proof is as above, except that in K, if the TM
enters a halting state then instead of an inconsistency arising,
a criterion is added to X.
However, in the face of these negative general results we
can look for special cases that we can handle well never-
theless, and relax our requirements somewhat. An impor-
tant special case is that when an output depends on facts
that are obviously inconsistent, because they contain an ex-
plicit statement indicating a contradiction for example, then
it should clearly not be emitted, and in fact execution should
cease for that line of reasoning since no good outputs will
subsequently be found.
When might it be clear that an output can be safely emit-
ted, without a contradiction subsequently being discovered?
For many outputs the answer may well be only on conclu-
sion of execution, since once an output is ready the remain-
ing program may have a sophisticated task to perform and
determining that no contradiction will subsequently arise is
essentially the same problem as verifying the program over-
all, which as we prove above is impossible in general.
However, we can argue that the requirement is too strong.
Suppose that a required category of objects X has been cal-
culated from a program K, but subsequently some other re-
quired category Y is found that is identified by contradictory
criteria, and so can contain no objects. Now it is known that
there is no domain satisfying K. But what is invalid about
the category of objects described by X may only be that
they are required to coexist with the impossible objects in
Y . So it does not seem unreasonable that the execution of K
might output X on a tentative basis prior to calculating Y ,
and this might even be useful, provided that the programmer
understands that later the overall description of the domain
may prove to be illogical. Programs can do useful work even
though they subsequently crash.
What remains is determining whether X is ready in
the sense that it will not be subsequently refined. Here
we weaken the requirement that execution finds only the
maximally-specific required categories of objects providing
it still finds all of them and not too many surplus gener-
alisations. And assuming that execution has decided that a
required category of objects X exists and has started ac-
cumulating its identifying criteria then X should be output
once no more criteria will be found for it. Any determination
that this point has been reached must be based on an anal-
ysis of how pending processing might come to modify the
category, and once these possibilities have been discounted
then the category can be output.
4.4 Dealing with alternatives
An ALP program can, through the use of unions, specify
several alternative possible structures for a conforming do-
main, in terms of what required categories of objects are
present and their interrelationships. For example, the pro-
gram {((A u ∃R.B) t C)(a)} describes either domains con-
taining objects related by R and participating in concepts
A and B or singletons participating in C. On the one hand,
it seems like neither of these alternatives can be regarded
as required since the other might hold. However, the pro-
gram nevertheless establishes maximally specific required
categories of objects, expressible disjunctively, since in any
conforming domain there must be a category of objects de-
scribed by either {A(a), R(a, b)} or {C(a)} and another
given by either {B(b), R(a, b)} or {C(b)}. These categories
are formed by pairing up criteria for categories from each
alternative domain according to the following intuition: if
we do not see an object from a category required in the first
alternative, then the second alternative must hold so we will
see an object from one of its categories – and vice versa.
This presents a problem, since the number of maximally
specific required categories for the program overall hence
grows in proportion to the product of the number of cat-
egories in each alternative. There will therefore often be
impractically many maximally specific required categories
where a program describes domains of several different
structures.
One answer to this problem is to require the programmer
to keep the number of results within bounds. One way to
achieve this is not to specify alternatives, or if they are
specified to ensure that one turns out to be inconsistent.
For example in the program {(A t B)(a), ¬B(a)} if B(a) is
assumed then a contradiction is quickly discovered. This is a
mechanism for achieving conditional computation in ALP,
which we saw used in examples in Section 3.
In other cases both alternatives will remain open and
the programmer may be legitimately concerned with the
details of both. In this case we expect that the program-
mer will be prepared to accept descriptions of the cate-
gories in each alternative, rather than all combinations of
these. For our original example, one set of output might
be {{A(a), R(a, b)}, {R(a, b), B(b)}} under the assump-
tion (A u ∃R.B)(a); and the other set of output would be
{{C(a)}} under the assumption C(a).
In fact, execution generally will not be able to tell at the
point that an output is ready whether an alternative will re-
main consistent or not, for reasons discussed above. So two
modes of execution are possible depending on what the pro-
grammer wants: either results can be output immediately la-
belled with the assumptions upon which they depend, in case
those assumptions later prove to be inconsistent in which
case execution should signal this fact; or alternatively out-
puts should be deferred until their assumptions are vindi-
cated when all corresponding alternatives are discovered to
be inconsistent. Other possibilities deserving future investi-
gation would be the ability to aggregate information where
several alternatives remain open (like some Prolog meta-
predicates such as findall) or to select a main line of rea-
soning in preference to others (like Prolog’s ‘cut’ operator),
but both of these would require a more expressive language.
4.5 Permit efficient implementations of
well-understood algorithms
A practical programming language should permit the body
of computer science knowledge relating to algorithms to be
brought to bear to write programs that will do useful work
on a conventional modern computer. There are at least three
important aspects to this. First, for any well-understood al-
gorithm a theoretically equivalent implementation should be
available in the language, in terms of both functionality and
limits on time and space utilisation as functions of some
measures of the input. Usually a claim that an algorithm has
O(f (x)) time complexity and O(g(x)) space complexity is
based on a machine model featuring random access mem-
ory and the ability to perform certain arithmetic functions in
constant time within bounds [16]. So a possible theoretical
demonstration of this property for our language would be a
proof that it could simulate such a machine, in time propor-
tional to the number of instructions executed, and space pro-
portional to the number of memory locations accessed. Since
most modern computers are random access machines this
would also be a demonstration that the language was able
to utilise the hardware on which it was interpreted some-
what effectively. It would also have the effect of proving the
weaker property of Turing completeness.
Second, the overheads in such a demonstration need to
not only be constantly bounded (or nearly) per step or mem-
ory location, but affordable. For ALP or any high-level lan-
guage this depends not only on how efficiently results can
be calculated, both in theory and in terms of the quality of
the implementation of an interpreter, but also on the amount
of performance overhead that the programmer is prepared to
accept in return for the advantages of writing its program in
this way rather than some other, directly in machine code for
example. But if a language will hardly ever be used because
its programs run too slowly, that is clearly not good enough.
And finally, notwithstanding that an equivalent imple-
mentation, and even a fast one, might be available for any
algorithm in the language, it should also be fairly obvious
how to translate the description of the algorithm to obtain
such an implementation. We hope that this will be the case
for the kind of language that we are discussing, because im-
plementing the algorithm should be a matter of modelling
the entities and relationships given in the description of the
algorithm, however presented. We saw this in the adder ex-
ample in Section 3 where the structure of the algorithm was
straightforwardly derived from domain knowledge of elec-
tronic adders and half adders. There is a sense in which the
extent to which this property is established for a program-
ming language is a measure of its overall amenity for pro-
gramming, and evaluating this for ALP will go beyond what
we can accomplish in this paper.
5. Executing ALP programs
5.1 Constructing semantic tableaux
Each instance variable in an ALP program establishes a
required category of objects, namely those that may be as-
signed to it, and a set of criteria that those objects must meet,
namely the semantic constraints corresponding to the sen-
 ¬>(a) C(a), ¬C(a) and retain that binding in the conclusion specification be-
M⊥1 M⊥2 low the line to yield conclusion sentences. Each conclusion
⊥(a) ⊥(a)
leaf for an M-rule is then the union of the conclusions with
R(a, b), ¬R(a, b) a 6= a the premise leaf (the M in the names of these rules stands
M⊥3 M⊥4
⊥(a) ⊥(a) for monotonic). In the rule Mt1 two leaves are formed con-
taining alternative conclusions shown separated by a bar (|).
(C u D)(a) ¬(C u D)(a) The conclusion for R#≤1 indicates that all occurrences of
Mu1 Mu2
C(a), D(a) (¬C t ¬D)(a) the variable c in the premise leaf are replaced with b. The
premise p for the rule M◦2 must be one of the following
(C t D)(a) ¬(C t D)(a)
Mt1 Mt2 sentences: ∀Q.C(a), Q ⊆ U (a), ¬Q(a, d), #Q ≤ 1(a),
C(a) | D(a) (¬C u ¬D)(a) ∃Q.C(a), where Q = R ◦ S or Q = R ◦ S ◦ T , referred to as
∃R.C(a) ¬∃R.C(a) the guard for the rule. In the rules M∃1 , M#>1 , M⊆2 and M◦1
M∃1 M∃2 that have instance variables in their conclusions that do not
R(a, b), C(b) ∀R.¬C(a)
appear in their premises, the new variables must be bound to
∀R.C(a), R(a, b) ¬∀R.C(a) literal instance variables that are not used in any sentence in
M∀1 M∀2 the premise leaf.
C(b) ∃R.¬C(a)
A rule may only be applied for a given binding of
#R ≤ 1(a), R(a, b), R(a, c) ¬#R ≤ 1(a) premises it is not then also possible to bind the conclusions
R#≤1 M#≤2
b/c #R > 1(a) to the premise leaf (matching bound variables and binding
any yet unbound) before the binding of new instance vari-
#R > 1(a) ¬#R > 1(a)
M#>1 M#>2 ables; i.e. a deduction should introduce new sentences, and
R(a, b), R(a, c), b 6= c #R ≤ 1(a) not just by creating new variables in the same roles as exist-
R ⊆ S(a), R(a, b) ¬R ⊆ S(a)
ing ones. A leaf is said to be closed iff it contains a sentence
M⊆1 M⊆2 of the form ⊥(a). No rule can be applied to a closed leaf,
S(a, b) R(a, b), ¬S(a, b) since it represents a contradiction that no interpretation can
R ◦ S(a, b) p, R(a, b), S(b, c) satisfy, so further reasoning would be futile. Otherwise a leaf
M◦1 M◦2 is open.
R(a, c), S(c, b) R ◦ S(a, c)
Within a particular sequence of tableaux if a leaf Li is a
¬¬C(a) conclusion of a rule applied to a leaf Li−1 then we say that
M¬
C(a) Li is a descendant of Li−1 (which we will now be happy to
call a node when the sequence of tableaux are considered as
Figure 2. Deductive rules for executing ALP a whole). If for a sequence of nodes L1 , . . . Ln each Li is
the descendant of Li−1 where 1 < i ≤ n then Ln is also
a descendant of L1 , and we call such a sequence a line of
tences in the subprogram for the variable. So subprograms reasoning. If Lj is a descendant of Li then Li is an ancestor
offer an obvious vehicle for the calculation and communi- of Lj .
cation of results. What is needed is an algorithm that refor- At each step, a number of rules may be applicable to a
mulates the initial program, plus input in the form of extra number of leaves. In this section we only assume that the
sentences, into an explicit form, introducing additional sub- procedure is fair for the program K in that it guarantees that
programs where necessary to capture required categories, if a rule is applicable to a leaf Li in a tableau derived from
and decomposing complex criteria into more general ones. K then after a finite number of further deductions the rule
A tableau algorithm can do this. will no longer be applicable to any descendant Lj of Li .
Execution will proceed by constructing a sequence of The first tableau in any sequence for a program K is {K}.
semantic tableaux. Each tableau in the sequence consists of Execution terminates when no rule can be applied to any
a list of programs {L1 , . . . , Lm }. We will call each program leaf in the current tableau, either because all are closed, or
in the list a leaf, and treat it as a set. The next tableau in the because all rules are inapplicable.
sequence is calculated by applying one of the deductive rules
shown in Figure 2 to the current tableau. 5.2 Properties of fair executions
The name of each rule is shown on its right-hand side. Our main concern with functionality of the algorithm is that
Each deduction targets a leaf of the current tableau called either it discovers that the program is inconsistent or that
the premise leaf. All other leaves appear in the subsequent each maximally specific required category of results in each
tableau unmodified. However, the premise leaf is replaced viable alternative – namely those lines of reasoning remain-
by one or two conclusion leaves. The rules each give a ing open on termination – has at some point during the exe-
premise specification above the line, the variables in which cution a subprogram expressing its constraints in full, a prop-
bind to parts of literal sentences present in the premise leaf, erty that we will refer to as explicitness. A proof of this prop-
erty can be obtained by first proving some more conventional
properties for this kind of algorithm: that it is sound, i.e. the
set of domains represented by the leaves in the latest tableau
does not change as execution progresses, or in other words
the meaning of the original program is retained; and that it
is complete in the sense that if K is inconsistent then this
will surely be discovered after a finite number of deductions.
The proof of soundness is needed for the proof of complete-
ness. Completeness is a necessary condition for explicitness
as we have defined it. But our proof of completeness also
proceeds by showing that when no more rules can be applied
to an open leaf it is satisfiable, and this is done by showing
that it can be satisfied by a carefully constructed domain that
we call the canonical interpretation for a program. The spe-
cial property of the canonical domain, that it contains only
enough objects to assign to each variable, leads directly to a
proof of explicitness, since these objects must be members
of maximally specific required categories whilst only satis-
fying subprogram constraints. This observation is the main
theoretical innovation in this section.
5.2.1 Soundness
Soundness is proven by considering each rule in turn and en-
suring that the premises entail the conclusions. For example,
here is the proof for M¬ .
Theorem 3. L |= L ∪ {C(a)} if ¬¬C(a) ∈ L.
Proof. Consider I satisfying L. Since I satisfies ¬¬C(a)
there is an assignment A such that aA ∈ >I \ (>I \ C I ).
Since C I ⊆ >I it is the case that >I \ (>I \ C I ) =
C I . Hence I also satisfies C(a) with assignment A and
so satisfies L ∪ {C(a)}. Conversely if ¬¬C(a) ∈ L and I
satisfies L ∪ {C(a)} then clearly I must satisfy all sentences
in L. Therefore L |= {C(a)}.
The soundness property to be proven for Mt1 is a little
different, as the set of interpretations that satisfy the premise
may be split between the conclusions.
Theorem 4. If {(C t D)(a) ∈ L} then an interpretation
I satisfies L iff it satisfies one or both of L ∪ {C(a)} and
L ∪ {D(a)} .
The rule R#≤1 is also an interesting case as it applies
renaming to the premise, but we must omit the details here.
Armed with soundness results for all rules, the soundness
of the algorithm overall can be proven straightforwardly by
induction over the sequence of deductions.
Theorem 5 (Soundness). For every interpretation I and ev-
ery tableau θ constructed starting from {K}, then I satisfies
K iff there is a leaf L in θ such that I satisfies L.
5.2.2 Completeness
Theorem 6. If a program K is unsatisfiable then the execu-
tion of K will generate a tableau in which all branches are
closed, and hence halt, in a finite number of steps.
Proof.
1. a leaf is complete iff it is closed or no rule can be applied;
2. a tableau is complete iff all of its leaves are complete;
3. if an open leaf L is complete but not closed then it is
satisfiable (it may be infinitely large). This is proven by
Theorem 7 below;
4. soundness: in every tableau generated for K, an interpre-
tation satisfies some branch L iff it satisfies K. This is
proven by Theorem 5 above;
5. if all branches in a tableau for K are complete and there is
an open leaf L then by 3 and 4, K is satisfiable; otherwise
K is not satisfiable;
6. for any program K there is a fair procedure for choos-
ing what deduction to apply next during execution that
will generate a complete tableau via a finite or infinite
sequence of deductions. This is proven by Theorem 8 be-
low;
7. if a closed leaf is derived then this occurs a finite number
of deductions after execution started, see Theorem 8;
8. assume K is unsatisfiable. By 6 execution will in a finite
or infinite sequence of deductions produce a complete
tableaux starting from {K}. Assume at least one leaf
in this tableau is open. Then that branch is satisfiable
by 4, but then K is satisfiable by 5. Therefore either K
is satisfiable or all leaves in the completed tableau are
closed;
9. since for an unsatisfiable program all leaves in the com-
plete tableau are closed by 8, and all closed leaves are
derived after a finite number of deductions by 7, the to-
tal number of deductions applied to construct the com-
plete tableau must be finite. This is by considering the
tree of nodes defined by the descendant relationship. It
is finitely branching, with each node having one or two
successors. All branches are terminated by a closed leaf,
the ancestors of which represent the sequence of deduc-
tions required to derive a contradiction. The length of
each branch is therefore bounded above by the number
of deductions that had occurred in total when its leaf
was derived, which is finite. Hence all branches are of
finite length. Hence by König’s lemma (for trees) [8] the
tree contains a finite number of nodes in total. Since each
node might be the conclusion of at most one deduction,
the total number of deductions to construct the tree and
hence the final tableau must be finite.
Theorem 7. If a branch L is complete in a tableau and L is
open then L is satisfiable.
A full proof of this theorem is not difficult but too long to
be given here. It proceeds as follows: Let IC be the canonical
interpretation for L as follows. Let the domain be >IC =
{oa | a ∈ V(L)}, i.e. containing one element {oa , ob , . . .}
corresponding to each instance variable {a, b, . . .} = V(L).
A satisfactory assignment for the canonical interpretation
will be given by aA = oa for all variables a ∈ V(L).
Now let the interpretation of any atomic concept in IC
be those objects that correspond to instances stated to par-
ticipate in that concept by an instance assertion of the form
A(a) ∈ L, namely AIC = {oa | A(a) ∈ L}. Also, let the
interpretation of any atomic role be those pairs of objects
corresponding to instances asserted to participate in the role,
namely P IC = {(oa , ob ) | P (a, b) ∈ L}. The interpretation
of complex concepts follows by the semantic rules.
The remaining part of the proof proceeds by proving
that IC satisfies L. This involves considering each senten-
tial form. Inequalities are the most straightforward given the
construction of the canonical interpretation. Role assertions
and denials take more work because we must also prove that
composite role assertions are constructed by the rule M◦2
where needed to detect contradictions. Instance assertions
proceed by strong induction over the complexity of the con-
cept being asserted for the instance (according to a ranking
function) usually on the basis that if a complex concept is
asserted then corresponding simpler sentences will also be
present in L, because a deductive rule has surely been ap-
plied, and they can be assumed by the inductive hypothesis
to be satisfied.
Theorem 8. There is a fair procedure for executing any
ALP program, and this will generate a complete tableau
in a finite or infinite sequence of deductions.
Proof of this theorem is accomplished by exhibiting a
fair procedure for picking deductions to apply, and proving
that it is fair. One possibility is to queue the deductions:
initially and at any point thereafter there will be finitely
many possible, so finitely many ahead of any new ones that
become possible.
Now note that given that K is finite we can number the
initial sentences and any subsequently deduced in an ascend-
ing sequence. Notwithstanding the fact that execution may
continue indefinitely, no rule produces an infinite number of
conclusions in a single deduction, so any sentence derived
will have a finite number in the sequence. Therefore if any
leaf closes by the derivation of ⊥(a) it will do so after a fi-
nite number of deductions. Similarly after an infinite number
of deductions have been applied all open leaves will be com-
plete since the last premise to be derived to activate any rule
would be finitely numbered and fairly the rule would then
have been applied a finite number of deductions later.
5.2.3 Explicitness
Theorem 9. In an open and complete program L, there is a
subprogram identifying the criteria for every maximally spe-
cific required category of objects in a conforming domain.
Proof. A canonical domain can be constructed for an open
and complete program according to Theorem 7. The criteria
governing the participation of an object oa in concepts and
roles is determined solely by statements such as A(a) and
R(a, b) in L(a) giving the corresponding instance variable’s
participation in atomic roles and concepts, with participation
in complex concepts and roles following according to the se-
mantic rules. Therefore oa participates in a required category
of objects governed only by constraints present in L(a).
Moreover in the canonical domain there are exactly as
many objects as there are subprograms. Therefore the same
can be stated of any object oi : that it participates in a required
category of objects the criteria for which are given by L(i).
Now suppose there were a maximally specific required
category of objects X implied by L that has identifying char-
acteristics not equivalent to those expressed by any L(i) ⊆
L. Since X is a required category of objects it will have at
least one member in the canonical domain also, say oj . But
oj only need meet the criteria given by L(j), so X cannot be
more specific than L(j). But if X is not equivalent to L(j)
then it must be more general than L(j) in which case it is not
maximally specific. This is a contradiction, therefore there is
no such category X.
6. Generating output and garbage collection
6.1 Subprogram readiness
Suppose that when executing a program K some open leaf
L is produced containing the subprogram L(a) for some
instance variable a. Given that L(a) is non-empty, if L(a)
must be the same in any complete, open descendant of L,
assuming only that the execution procedure is fair, then we
state that L(a) is ready, and can be output.
Subprograms change due to the application of deductive
rules. Clearly for a rule r to be applied to a leaf Li , deriving
Li+1 such that Li+1 (a) 6= Li (a), r must first have been ap-
plicable in Li , in that Li had premises for r that would result
in new conclusions. If a rule r is applicable to a particular set
of premise sentences in Li , but was not applicable to them
in the immediate ancestor of Li (say Li−1 ), we state that r
has been activated for those premises in Li .
For a given node Li we state that a subprogram Li (a) is
progressing iff a deductive rule is applicable in Li to modify
the sentences in the subprogram for a in a descendant of
Li , say Li+1 such that Li+1 (a) 6= Li (a); otherwise it is
standing.
Note that if a subprogram Li (a) is progressing and hence
a rule r might change the subprogram, then within a finite
number of deductions all descendants of Li will either close
(in which case the subprogram will become irrelevant) or
the rule will have been applied, hence modifying the sub-
program. This is proven by Theorem 8. Therefore if a sub-
program Li (a) is progressing it is obviously not ready since
it will necessarily change in all descendants of Li that re-
main open. So if a subprogram is ready then it must be stand-
ing. Unfortunately the reverse does not necessarily hold be-
cause a subprogram might go from standing to progressing
depending on changes to other subprograms.
 All of the deductive rules given in Figure 2 require as
premises sentences from one or more subprograms. We state
that a subprogram Li (b) is relevant to a subprogram Li (a)
if a deductive rule could be applied taking as a premise
any sentence in Li (b) (possibly in combination with some
other sentences) to derive the conclusion leaf Li+1 such that
Li+1 (a) 6= Li (a). Now consider the following result:
Theorem 10. If a subprogram Li (a) is standing in Li but in
progress in a direct descendant Li+1 of Li , then it is because
the deduction that formed Li+1 from Li added at least one
sentence p to Li (b) (i.e. p ∈ Li+1 (b) \ Li (b)) such that
R(a, b) ∈ Li or R(b, a) ∈ Li .
Proof. It must be that Li+1 (a) = Li (a) since Li (a) is not
progressing. The rule that becomes applicable in Li+1 there-
fore cannot be one for which all premises are members of
Li (a) – e.g. Mu1 , Mu2 , . . . – unless it becomes active by the
removal of a conclusion rather than the addition of a premise.
But the former is not possible. Sentences are only removed
by renaming so given that Li (a) will not be renamed in one
step (because then it would be progressing) only M∃1 , M⊆2 ,
and M#>1 could be activated this way. But either matching
conclusions were absent in Li so the rules were already ap-
plicable, meaning that Li (a) was progressing, or the rules
would already have been applied resulting in subprograms
related to Li (a) by a sentence in Li (a), e.g. R(a, b). This
could only be removed by renaming though the application
of R#≤1 but for this to be possible Li (a) would again would
need to be progressing.
Therefore the rule that becomes applicable must take
sentences from several subprograms as its premises. The
possibilities are M∀1 , R#≤1 , M⊆1 , and M◦2 . We can verify
that these rules will again not be activated as a result of
renaming since a will not be renamed (because Li (a) is
not progressing) and the naming of the other variables is
irrelevant to whether a will progress. So given that one
of these rules has become applicable it is because of the
addition of at least one sentence p ∈ Li+1 , p 6∈ Li+1 (a).
Furthermore, the rules all require as premises role assertions
linking the instances appearing in the rule. Therefore, if p
has been derived to make r applicable to some new premises
and hence Li+1 (a) to be in progress then R(a, b) ∈ Li+1
or R(b, a) ∈ Li+1 . But these statements would form part
of Li+1 (a) so cannot have been newly added to Li+1 , since
Li+1 (a) = Li (a), so p 6= R(a, b) and p 6= R(b, a).
Therefore it is characteristic of this set of rules that if a
subprogram for a resumes progress after a period of standing
it is due to some fact having been added to a subprogram
for b with which a relationship has already been established.
Given that Li contains two subprograms Li (a) and Li (b),
then if R(a, b) ∈ Li then we state that Li (a) is a referrer for
Li (b). Conversely Li (b) is a referent of Li (a). Suppose we
define the neighbourhood of a in Li as the graph of instances
connected by role assertions. Then it is easy to prove that a
subprogram is ready when all subprograms for instances in
its neighbourhood are standing – but we omit further formal
proofs from this discussion.
Unfortunately, as discussed in Section 4.3 for many or
even most programs this point will not come sooner than
when all execution has been completed, since commonly
all instances are related transitively. We must apply some
further analysis to determine when referrers or referents may
progress but no longer have the potential to cause a related
subprogram to progress.
6.1.1 Irrelevant referents
The proof of Theorem 10 shows that only four rules can
cause a subprogram Li (a) to progress as a result of a change
in a related subprogram Li (b). Of these only M◦2 will cause
Li (a) to progress if Li (b) is a referent of Li (a).
The rule M◦2 combines role relationships into composite
role relationships, given that a guard sentence p is present
indicating that knowledge of referents via a composite role
is relevant to an instance. Note that the guard sentence p be-
longs to Li (a). It is the extension to the original role S(b, c)
that might be added to Li+1 (b) to make Li+1 (b) relevant
to Li+1 (a) given that Li (a) is standing. When will this not
happen? If none of the guard sentences are present for any
extension S to R in Li (a), then whatever happens to the sub-
program of b will be of no concern to that for a, assuming
that Li (a) does not progress due to a referrer. Indeed it is to
obtain this independence that the guard sentences are speci-
fied for the rule.
Given that L(a) is standing if R(a, b) ∈ Li and there
is an appropriate guard sentence in Li (a) involving the role
R ◦ S then we will state that Li (a) is open to R ◦ S via
Li (b), and we would prefer Li (a) to be closed to all roles
via its referents as a prerequisite for readiness. In fact we
can judge that Li (a) is closed to roles from a referent even
in the presence of guard sentences by also checking whether
Li (b) has the potential to add the extension role S(b, c). See
the next subsection.
6.1.2 Irrelevant referrers
We also need to consider whether a referent can be output
even though its referrer might change. This is often needed
when a single referrer remains unready for a long time to
supply value restrictions (via M∀1 ) to a large number of
referents. See Section 8 for an example of this happening.
The referrer needs to be able to obtain new referents, but we
need to be sure that this activity will not cause the referrer to
modify its older referents so they can be output and removed
from memory.
Suppose that Li (b) is now the referrer and Li (a) the refer-
ent due to the assertion R(b, a) ∈ Li . Considering the rules
M∀1 , R#≤1 , Mv1 , and M◦2 that may be activated to cause
a subprogram to progress, all may be activated by a change
in Li (b) causing Li (a) to progress. And application of these
rules can have a profound effect on a referent. For exam-
ple, it may be that M∀1 will be applied to ∀R.C(b) to derive
C(a), a completely new instance assertion concerning a. Or
if R(b, c) were derived in Li+1 (b) and #R ≤ 1(b) held then
the application of R#≤1 could eliminate the subprogram for
a, or combine it with that for c.
However, in the scenario described above we must do bet-
ter than wait until all referrers transitively are ready before
declaring Li (a) ready. The intuition behind the following
analysis is that referrers will have their most powerful effect
on referents early in the lifetime of the referent, and after
that the effects may be more limited.
Suppose therefore that in a particular execution the effect
on Li (b) (the referrer) of its referrers has already been cal-
culated, so it is not going to change much itself. Its initial
implications for Li (a) have also been calculated, so Li (b)
is not currently relevant to Li (a). What happens after this?
Li (b), if it will change at all, will next change due to the
application of M◦2 , as discussed in the previous subsection.
Suppose this has just added the new relationship R ◦ S(b, c)
to Li (b). What rules may be activated as a result? The rules
that could take the new sentence as a premise are M∀1 , M◦1 ,
M◦2 , M⊥3 , R#≤1 and M⊆1 , and the possible results of ap-
plying these are that a contradiction is derived, a value re-
striction is applied to the new referent c, two referents of
Li (b) are combined by renaming, another new referent role
assertion is added to Li (b) by generalisation, or a new refer-
ent is derived for some referrer of Li (b). Note two important
facts about these possibilities: only the second is any imme-
diate concern in relation to the readiness of Li (a), the others
cannot possibly effect it in one deduction, or alternatively a
contradiction is found so the entire line of reasoning can be
discontinued; also, Li (b), assuming the line of reasoning re-
mains open, will only change immediately by the addition
of yet another referent relationship, which could only cause
some of the same rules to be activated again.
In light of the second observation, if Li (b) is progressing,
but only a subset of the above rules are active, we state that
Li (b) is only processing referents. This condition of the sub-
program for b will persist until one of its referrers becomes
relevant. Now suppose that Li (b) is only processing refer-
ents. The only rule that can be activated that might cause
Li+1 (a) to progress is R#≤1 . But we can be quite specific
about when this will not happen. If Li (b) contains no value
restriction #R ≤ 1(b) or is not open to the role R then as
long as it continues to be only processing referents the rule
will not be activated. If Li (b) does contain #R ≤ 1(b) and
is open to R then we will call it an aggregator for Li (a). So
if Li (b) is only processing referents and is not an aggregator
for Li (a) then we can be assured that Li (a) will not imme-
diately begin to progress as a result of a change in Li (b). We
state that Li (b) has passed Li (a) if these conditions are met.
Now let us state that Li (a) is currently objective if all
its referrers have passed it. Now we will state that Li (a) is
objective if it and all of the subprograms in the transitive
closure of its referrers are currently objective. Objectivity
is so called because an objective subprogram will never
change as a result of changes in its referrers, and remains
only processing referents. Since this means that only role
assertions (or possibly a contradiction) will be added to
the subprogram, it means in particular that no new guard
sentences will be added to the subprogram. This makes it
easier to assess which roles it remains open to. Once an
objective subprogram becomes closed to all roles it is ready.
6.2 Garbage collection
The execution algorithm has a number of opportunities to
discard information as it progresses. Probably the most ob-
vious is that prior tableaux can be discarded (or updated)
as execution progresses. Also clear is that closed leaves will
play no further part in computation and can be removed from
the latest tableau. Having taken these measures, memory us-
age will be dominated by the subprograms retained in open
lines of reasoning. It is therefore important to discard those
that will play no further part in computation.
A ready subprogram will never again change. Crucially
this means that it can have no more new neighbours. There-
fore at some point thereafter all deductions involving the
subprogram and modifying its neighbours will have been
applied. At this point we state that the subprogram is ex-
hausted. The sentences of an exhausted subprogram may be
removed, provided they are not also sentences in another
subprogram also. Some precautions must be taken so that
rules like M∀1 do not become applicable again when sen-
tences are removed. This can be achieved by replacing the
instance variable with a special token in any role assertions
from the subprogram that are retained by its neighbours.
A further refinement to the execution algorithm is possi-
ble that reduces its memory footprint while improving the
quality of results produced. Many of the rules that operate
on a single subprogram reformulate a sentence into a better
but equivalent form, e.g. Mu1 . But then the original sentence
is no longer desirable in the subprogram, and in fact is re-
dundant, so should be removed. Therefore a number of the
monotonic rules originally presented can be replaced with
discharging rules such as Du1 in which the conclusions re-
place the premises in the conclusion node, rather than join-
ing them.
7. Further theoretical considerations
Three important areas remain to be addressed in order to
prove in theory that this kind of programming is practical.
First, although the discussions in the previous two section
establish the possibility that the desired results can be gen-
erated and output at some point before termination, it is
not clear that any algorithm can accomplish this efficiently.
In future work we will exhibit one. For now we will offer
the following arguments. First, the cost of applying rules
is mainly in finding matching premises for rules, and then
checking whether the conclusions have previously been gen-
erated. Indexing sentences based first on subprogram, then
sentence type, then atoms involved tends to reduce this to
O(log(n)) where n is the number of sentences in memory at
any one time.
The analysis of an algorithm to assess readiness is much
more difficult, and performance will depend on the structure
of the graph of subprograms currently in memory, and hence
the program being executed. Objectivity may be expensive
to assess if any subprogram has a long list of referrers that
are not obviously objective themselves, as when progressing
subprograms form circular lists for example. But objectiv-
ity is cheap to assess in other situations, because if a sub-
program only has objective referrers and these have passed
it (or more obviously are all standing) then it is objective.
Subjectivity is also useful in that a subprogram is subjective
if it has any subjective referrers, so we can potentially avoid
checking large parts of the subprogram graph on the basis
that a subjective referrer means that all within must be sub-
jective. The cost of assessing readiness should then mainly
depend on the number of objective subprograms in memory,
of which the ready subprograms will be a subset. However,
the bulk of the working data of the program will be subjec-
tive, because progressing subprograms with work to do will
refer to it.
The second thing we have not considered is what order
the rules should best be applied in, beyond being fairly ap-
plied. In theory, some programs can be written such that the
order is determined logically, i.e. only one rule is applicable
at a time, although perhaps not all algorithms can be imple-
mented efficiently this way; and certainly not clearly. It is
more natural to write non-deterministic programs but then
some fair executions take a long time while others are ef-
ficient. Schemes that avoid these problems are not hard to
come up with, for example maintaining a queue of premises.
But ultimately we want something that also reflects the pro-
grammer’s intuition about what should happen next and ad-
mits some non-determinism to allow interpreters to take ad-
vantage of opportunities for parallelisation.
Finally as mentioned in the requirements, it would be de-
sirable, equipped with results in the above areas, to show
that ALP, or more likely an enhancement of it with sup-
port for arithmetic, could simulate a random access machine
efficiently. This is future work.
8. Worked example
The following program simulates a traffic light.
all traffic light {
green : next.yellow
yellow : next.red
red : next.green
} and the generalisation of this role back to traffic light (19)
traffic light.next : traffic light
some traffic light.green something
Here it is again as a DL sentence:
(∀traffic light.
(green ⊆ next ◦ yellow u
(yellow ⊆ next ◦ red u
red ⊆ next ◦ green)) u
(traffic light ◦ next ⊆ traffic light u
∃traffic light ◦ green.>))(a1 )
Under our execution algorithm the program is non-
terminating. A trace execution of the program, up to a point,
generated with the aid of our interpreter for ALP, is shown
in Figure 3, and proceeds as follows. Note that some of the
deductions are discharging but have the same premises and
conclusions as their monotonic counterparts. The initial con-
cept is asserted for a1 . It is a right-associating conjunction
with three parts, so initially Mu1 is applied twice to dis-
member it into shorter instance assertions. These establish
the general rules for traffic lights related to a1 (2), the rule
that the next thing of a traffic light is also a traffic light (4),
and the fact that there is something that is the green of a
traffic light (5).
Next the application of D∃1 hypothesises a new category
of objects a2 related to a1 by traffic light ◦ green, a com-
posite role (7). The rule M◦1 then adds an intermediate in-
stance a3 related to a1 by the role traffic light (8) and to a2
by green (9). We can interpret a3 as describing the first state
of the traffic light, a1 as describing the scenario in total, and
a2 , which has an slightly unusual role in this program, as
corresponding to the light shining from the traffic light. See
Figure 4 for a graph of subprograms in the execution gener-
ated from output from the interpreter.
Having completed this initial setup, execution now set-
tles into the cyclical behaviour of calculating next states for
the traffic light. First any instance related to a1 by the role
traffic light – a3 in the first iteration – has the value re-
striction applied by rule M∀1 defining its nature as a traf-
fic light (10). The concept for this restriction is again a
conjunction with three parts, one for each possible current
colour of the traffic light, and this will be dismembered into
instance assertions for the subprogram. One of these role-
value mappings will then be applicable by M⊆1 to map the
role for its colour to a composite role next ◦ Colour where
Colour is the appropriate illumination in the next state (13).
We call the application of this rule generalisation. The new
composite role is again decomposed to add an intermedi-
ate object, a4 say (16), representing the next state of traf-
fic light. The final steps in the cycle are the application
of the rule M◦1 due to the presence of the guard sentence
traffic light ◦ next ⊆ traffic light(a1 ) to establish a compos-
ite role traffic light ◦ next(a1 , a4 ) (18 - we call this fetching)
so the value restriction can be applied to a4 in the next cycle
(20).
 1. (∀traffic light.(green ⊆ next ◦ yellow . . . Assumed.
2. ∀traffic light.(green ⊆ next ◦ yellow u . . . Du1 (1)
a_1
3. (traffic light ◦ next ⊆ traffic light u . . .
4. traffic light ◦ next ⊆ traffic light(a1 ) Du1 (3) traffic_light
5. ∃traffic light ◦ green.>(a1 )
6. >(a2 ) D∃1 (5) a_3 traffic_light

7. traffic light ◦ green(a1 , a2 )

next traffic_light
8. traffic light(a1 , a3 ) M◦1 (7)
9. green(a3 , a2 ) a_4 traffic_light

10. (green ⊆ next ◦ yellow u (yellow ⊆ next . . . M∀1 (8, 2)

next traffic_light
11. green ⊆ next ◦ yellow(a3 ) Du1 (10)
12. (yellow ⊆ next ◦ red u red ⊆ next ◦ green . . . a_5

13. next ◦ yellow(a3 , a2 ) M⊆1 (11, 9)

green next
14. yellow ⊆ next ◦ red(a3 ) Du1 (12)
15. red ⊆ next ◦ green(a3 ) yellow a_6
16. next(a3 , a4 ) M◦1 (13)
red next
17. yellow(a4 , a2 )
18. traffic light ◦ next(a1 , a4 ) M◦2 (16, 4, 8) green a_7
Instance a3 ready and exhausted.
19. traffic light(a1 , a4 ) M⊆1 (18, 4) yellow next

20. (green ⊆ next ◦ yellow u (yellow ⊆ next . . . M∀1 (19, 2) a_2 a_8
21. green ⊆ next ◦ yellow(a4 ) Du1 (20)
22. (yellow ⊆ next ◦ red u red ⊆ next ◦ green . . .
23. yellow ⊆ next ◦ red(a4 ) Du1 (22) Figure 4. Eight instances from the traffic-light example.
24. red ⊆ next ◦ green(a4 )
25. next ◦ red(a4 , a2 ) M⊆1 (23, 17)
26. next(a4 , a5 ) M◦1 (25)
a1 has passed it. The subprograms for the states contain
no guard sentences, so are never open to roles, so become
27. red(a5 , a2 )
ready once objective and standing, and shortly thereafter
28. traffic light ◦ next(a1 , a5 ) M◦2 (26, 4, 19) exhausted. The subprograms for a1 and a2 never become
Instance a4 ready and exhausted. ready, the former because it always remains open to the role
traffic light ◦ next so that it can apply its value restriction,
Figure 3. Initial execution of the traffic-light example. and the latter because it always has a subjective referrer,
i.e. the subprogram for the next state currently being cal-
As execution progresses the subprograms for each state of culated. The order and timing in which subprograms for
the traffic light become available for output and subsequent states are output and cleared from memory can vary depend-
garbage collection. Here are the sentences that will be output ing on the order in which deductions are applied, due to a
for a3 : race between Mu1 and M⊆1 in the processing of the state
for green, but provided neither of these rules is systemati-
cally deferred the subprograms will be output promptly and
8. traffic light(a1 , a3 )
in order. The memory footprint of the program is hence con-
9. green(a3 , a2 )
stantly bounded with at most two states in memory at once.
11. green ⊆ next ◦ yellow(a3 ) With such a small memory footprint this program is ac-
13. next ◦ yellow(a3 , a2 ) tually not a good benchmark for the interpreter, since hav-
14. yellow ⊆ next ◦ red(a3 ) ing large numbers of facts to process is the principal chal-
15. red ⊆ next ◦ green(a3 ) lenge for algorithms that apply the deductive rules and cal-
culate readiness. Nevertheless we note that our implementa-
16. next(a3 , a4 )
tion, written in Prolog and executed using SWIProlog on an
Intel I7 PC running at 2.7 GHz (with one core being utilised)
Note that a1 swiftly becomes objective, having no ref- will output ∼440 state subprograms per CPU second, corre-
erents of its own. Then each state becomes objective once sponding to ∼4400 deductions per second. This is obviously
very slow when we consider how a simple implementation
of the same simulation written in machine-code would run.
But on the other hand it suggests that execution of ALP
programs is not beyond the bounds of practicality.
9. Related work
ALP introduces no new constructors or sentential forms to
the field of Description Logic. All have been considered be-
fore, and with the exception of role-value maps, frequently.
Tableau algorithms are also the usual approach for reason-
ing with expressive DLs [2], and our proof of completeness
follows a typical pattern. However they are usually used to
find contradictions in order to establish the validity of some
complementary fact, for example proving the subsumption
of one concept by another by disproving the existence of an
object asserted to be a member of the former but not the lat-
ter. Explicitness is hence not usually proven, but is no doubt
a property of most such algorithms. It seems clear that the
method works to find contradictions by first making argu-
ments explicit.
What is perhaps novel about ALP is the particular set
of choices that it embodies. Most DLs are not, by virtue
of the constructors chosen, Turing complete, because this
would make the decision procedures desired in their appli-
cations undecidable. But we want Turing completeness so as
not to restrict the set of algorithms that can be implemented
in the language. The (logical) completeness result of Theo-
rem 6 establishes the semi-decidability of ALP. If we were
to also show that ALP could simulate any TM, and hope-
fully the examples we have shown suggest that this is a re-
alistic prospect, then it would be clear that ALP is also un-
decidable, and this is essentially due in ALP as in TMs to
the halting problem, as illustrated by Theorem 1. However,
thanks to the results presented in Section 6, ALP programs
do not have to terminate to produce useful output in finite
time.
Role-value maps contribute profoundly to the expressive-
ness of ALP. We have seen that they allow programs to
progress by repeatedly qualifying newly discovered mem-
bers of the closure of a relationship. Role-value maps are
considered so undesirable from a computational perspec-
tive that the standard nomenclature for DLs, which com-
bines the letters AL with a suffix consisting of letters indi-
cating the additional concept constructors does not include
one for them [1]. However, if we represent role-value maps
with R then the language would be called ALUCEFR◦ .
Notwithstanding that this might be shortened by consider-
ing equivalences between some of the constructors, we find
this unwieldy, hence our use of ALP which may be con-
sidered to stand for attributive language for programming.
Role-value maps are for us a convenient and natural way
to obtain the repetition needed in most algorithms, and they
also closely resemble type declarations in conventional pro-
gramming languages, e.g. the example in Section 3 in which
the dogs of the author are a type of thing he owns.
Other constructors were also selected in part for their con-
ceptual modelling appeal and similarity to OO languages –
value restrictions for example, are a bit like classes; negation
is obviously desirable for denying bad properties; unions fol-
low inevitably if you want negation and intersection and to
avoid artificial constraints on the way that concepts are com-
bined – and in part from experience writing programs – max-
imum number restrictions have a role in achieving efficient
calculation since they allow two subprograms in the same
role to be merged avoiding repeated calculations, provided
R#≤1 is promptly applied.
Another point of difference from other DL work is our
focus on instance and role assertions as the main senten-
tial forms rather than terminological axioms, which describe
subsumption relationships between the membership of con-
cepts as a whole. So with a terminological axiom it would
be possible to assert that all dogs are female, for example.
ALP programs can give general rules for the dogs of the
author say, but not for all dogs. This limitation is intended
to avoid two potential software engineering problems: first
combining ALP programs will hopefully be less problem-
atic due to conflicting uses of the same terminology, since
the meaning of some name only applies within a local col-
lection of connected subprograms (although more work on
modularity is also needed); second, programs, regarded as
models of part or all of some system containing elements
of problem and solution domains, need not also define the
boundary of the system domain, which would be required
to make statements such as all dogs are female make sense,
since all dogs are manifestly not female.
The other notable fragment of FOL that has been used
as a basis for programming is Horn clauses, which under-
pins the semantics of Prolog, the best-known logic program-
ming language [9]. The Closed World Assumption (CWA)
informs the semantics of Prolog such that if a fact is not
a consequence of a Prolog program K then it is denied.
For example given the program thing a(A). the queries
?- thing a(a(1)), ?- thing a(a(2)), . . . succeed but
?- thing b(b(1)) fails. Note that if we take the world of
the program to be the set of terms satisfying the rule then
this program has an infinite world, which is closed only in
terms of the kinds of things it can contain.
This is clearly not the case for the semantics of ALP as
we have presented them. Suppose K = {A(a)}, then K 6|=
B(b) but in any interpretation satisfying K there may be an
object participating in B or not. So we state that ALP is
designed according to the Open World Assumption (OWA).
This seems to us to be preferable for the following reason at
least: if the abstractions presented in a program also model
the problem domain, then the CWA is problematic, because
additional detail is denied. At whatever level of detail the au-
thor models his dog in Prolog you can still claim that his Pro-
log program does not represent her by identifying something
true about her that he has not stated, and pointing out that
his program denies that fact. There is a sense in which ALP
is also more open-world than FOL. In FOL we can make
statements such as ∀x.(Dog(x) → Female(x)), which is the
equivalent to the terminological axiom discussed above, and
has the effect of closing the domain against all male dogs.
Description logic has been combined with logic program-
ming with Horn clauses in several works. In [6] a restricted
DL is translated into Horn clauses. In [3] the Prolog environ-
ment can transfer control to a DL reasoner to check special
predicates. Both works are aiming to provide execution plat-
forms for semantic web languages that specify rules and on-
tologies. The DLs considered are less expressive than ALP
and control is due to the rules.
Another relevant fragment of FOL is relational logic,
which underpins the semantics of the model finder Alloy [7].
Alloy generates and visualises possible satisfying domains,
up to some limit on the number of objects present, to help
the programmer to verify that a specification indeed mod-
els the domains it expects. By making some possible do-
mains explicit Alloy achieves something similar to our ex-
ecution algorithm, relying on the resolution-based model-
finder KodKod [15] rather than a tableau method. Alloy’s
results are delivered as examples rather than descriptions of
required categories of objects, so where ALP might output
two subprograms related by a role Alloy would deliver a set
of pairs of some finite cardinality; this supports the checking
of more complex constraints on the cardinality of a relation
than ALP can express, but it happens whether those con-
straints are present or not.
Alloy’s language is more expressive than ALP in other
ways too, however it has not been intended for programming
so the Alloy interpreter currently only attempts to realise fi-
nite domains in a non-interactive manner. However, since
Alloy preceded this work and has a similar perspective on
declarative OO specification to our own, would it or rela-
tional logics have been better places for us to start looking
for a programming language than DLs? Perhaps, but the sim-
plicity of ALP has certainly been an advantage in showing
that explicitness and output prior to termination can be ac-
complished, and perhaps these properties can now be sought
for more expressive logics and systems. Moreover, in com-
parison to DLs there is not for us such a compelling rela-
tionship between the semantics of relational logic, given in
terms of tuples of atoms, and the problem domain; and the
mapping from Alloy’s syntax to relational logic is also not
simple. It is not so obvious what the procedure is for deter-
mining whether a real world situation conforms to an Alloy
specification.
UML class diagrams in tandem with the Object Con-
straint Language (OCL) [12] form another expressive spec-
ification language the uses of which fall short of full exe-
cutability. The specification elements in class diagrams are
more conventionally object-oriented than Alloy or ALP,
namely structural type information in the form of classes, in-
heritance relationships, fields and/or associations with mul-
tiplicity constraints, and some other constraints such as vis-
ibility, ordering and containment. OCL adds the ability to
define object invariants and pre- and post-conditions for
methods. These elements match closely the specification el-
ements available from programming languages such as C++
and Java, which embody the structural elements in their type
systems and support the specification of invariants and pre-
and post-conditions by means of assertions. Hence specifi-
cation elements find use in static or runtime checking, with
type information also useful for generating objects or code.
In contrast in ALP the line between type information and
object-invariant is blurred because every subprogram gives a
description of a non-empty category of immutable objects
at some level of abstraction, making distinctions between
type and value information somewhat arbitrary. For exam-
ple, we can state Number(a1 ) or Three(a1 ) using the same
kinds of concepts and sentences, in this case atomic concepts
and instance assertions. And of course in ALP there is no
distinction between this kind of structural information and
commands that advance the state of the computation.
A recent work to attempt executable OO specifications
is [10], which integrates Kodkod into Java, transferring con-
trol to the model finder to accomplish some calculations,
but this can only be used to implement steps in long run-
ning executions. This work uses a specification language that
supports in syntax the notion that objects may change state,
whereas again Alloy and ALP must model state changes
where necessary using more generic kinds of relationships
between immutable objects.
10. Conclusion
The intent of this paper is to establish some initial credibility
for the use of Description Logic as a programming language.
We have only shown a language that captures the semantics
of objects for our purposes. Although this is almost certainly
enough for Turing completeness for practical purposes and
to harness the power of modern computing platforms a more
expressive language, including innate support for arithmetic,
string manipulation, etc. will need to be built on these foun-
dations.
Alan Perlis’s 54th Epigram of Programming is Beware of
the Turing tar-pit in which everything is possible but nothing
of interest is easy [14]. Will DLs prove to be a tar-pit or
tar sands, newly ripe for exploitation? We believe that any
programming language will stand or fall depending on how
the structures that it offers align with how the programmer
wants to think about its problems and solutions. In other
words, how intuitive the provided building blocks are. In
this respect DLs seem to have considerable potential due
to their ability to directly model a problem domain, and
in a way that can then be put into operation to generate
 useful results, as we have seen in the examples presented
in this paper. The fact that tableau algorithms can generate
concise explicit descriptions of domains of objects from an
open-world logical language – while taking account of the
structure of the domain to deliver results in a piecemeal
fashion and manage memory usage – seems like too good
a prospect to ignore.
Acknowledgments
Some of this work was accomplished while the author was
employed at Auckland University, first as a visiting fellow
and then funded by the New Zealand Foundation for Re-
search, Science and Technology (grant UOAX0903), which
became part of the Ministry for Research, Science and Tech-
nology in 2011. Thanks for support to both these institutions,
in addition to AUT, the author’s current employer. The exam-
ple of the author’s dog was inspired by the novel Spurious by
Lars Iyer.
References
[1] F. Baader. A. description logic terminology. In F. Baader,
D. Calvanese, D. L. McGuinness, D. Nardi, and P. F. Patel-
Schneider, editors, The Description Logic Handbook, pages
525 – 536. Cambridge, second edition, 2007.
[2] F. Baader and U. Sattler. An overview of tableau algorithms
for description logics. Studia Logica, 69(1):5–40, 2001.
[3] T. Eiter, G. Ianni, T. Lukasiewicz, and R. Schindlauer. Well-
founded semantics for description logic programs in the
semantic web. ACM Transactions on Computational Logic
(TOCL), 12(2):1 – 41, Jan. 2011.
[4] D. Frankel. Model Driven Architecture - Applying MDA to
Enterprise Computing. OMG Press. Wiley Publishing, Inc.,
2003.
[5] E. R. Gansner and S. C. North. An open graph visualization
system and its applications to software engineering. Software
- Practice and Experience, 30(11):1203–1233, 2000.
View publication stats
[6] B. N. Grosof, I. Horrocks, R. Volz, and S. Decker. Description
logic programs: Combining logic programs with description
logic. In Proceedings of the 12th International Conference on
World Wide Web, WWW ’03, pages 48–57. ACM, 2003.
[7] D. Jackson. Software Abstractions: Logic, Language, and
Analysis. The MIT Press, 2006.
[8] D. E. Knuth. The Art of Computer Programming, Volume 1
(3rd Ed.): Fundamental Algorithms. Addison Wesley, 1997.
[9] R. Kowalski. Predicate logic as programming language.
Information Processing Letters, 74:569 – 574, 1974.
[10] A. Milicevic, D. Rayside, K. Yessenov, and D. Jackson.
Unifying execution of imperative and declarative code. In
Proceedings of the 33rd International Conference on Software
Engineering, ICSE ’11, pages 511–520. ACM, 2011.
[11] D. Nardi and R. J. Brachman. An introduction to description
logics. In F. Baader, D. Calvanese, D. L. McGuinness,
D. Nardi, and P. F. Patel-Schneider, editors, The Description
Logic Handbook, pages 1 – 44. Cambridge, second edition,
2007.
[12] Object Constraint Language – OMG Available Specification
– Version 2.0. The Object Management Group (OMG),
formal/2006-05-01 edition, May 2005.
[13] OMG Unified Modeling Language (OMG UML), Superstruc-
ture – Version 2.4.1. The Object Management Group (OMG),
formal/2011-08-06 edition, 2011.
[14] A. J. Perlis. Epigrams on programming. SIGPLAN Notices,
17(9):7–13, 1982.
[15] E. Torlak. A Constraint Solver for Software Engineering:
Finding Models and Cores of Large Relational Specifications.
PhD thesis, Massachusetts Institute of Technology, 2009.
[16] P. van Emde Boas. Machine models and simulation. In
J. van Leeuwen, editor, Handbook of Theoretical Computer
Science, Volume A: Algorithms and Complexity (A), pages
1–66. Elsevier, 1990.