Patterns for Interfacing between Logic Programs and Multiple

Ontologies

Lu´ıs Cruz-Filipe

1,2,4

, Isabel Nunes

3,4

and Grac¸a Gaspar

3,4

Dept. of Maritime Engineering, Escola Superior N´autica Infante D. Henrique, Pac¸o d’Arcos, Portugal

CMAF, Lisbon, Portugal

Dept. Informatics, Faculty of Sciences, University of Lisbon, Lisbon, Portugal

LabMag, Lisbon, Portugal

Keywords:

Design Patterns, Hybrid Semantic Web Languages, Dl-programs.

Abstract:

Originally proposed in the mid-90s, design patterns for software development played a key role in object-

oriented programming not only in increasing software quality, but also by giving a better understanding of

the power and limitations of this paradigm. Since then, several authors have endorsed a similar task for other

programming paradigms, in the hope of achieving similar beneﬁts.

In this paper we discuss design patterns for hybrid semantic web systems combining several description logic

knowledge bases via a logic program. We introduce eight design patterns, grouped in three categories: three

elementary patterns, which are the basic building blocks; four derived patterns, built from these; and a more

complex pattern, the study of which can shed some insight in future syntactic developments of the underlying

framework. These patterns are extensively applied in a natural way in a large-scale example that illustrates

how their usage greatly simpliﬁes some programming tasks, at the level of both development and extension.

We work in a generalization of dl-programs that supports several (possibly different) description logics, but

the results presented are easily adaptable to other existing frameworks such as multi-context systems.

1 INTRODUCTION

In the mid-nineties, the Gang of Four’s work on soft-

ware design patterns (Gamma et al., 1995) paved

the way for important advances in software qual-

ity; presently, many valuable experienced designers’

“best practices” are not only published but effectively

used by the software development community. From

very basic, abstract, patterns that can be used as build-

ing blocks of several more complex ones, to business-

speciﬁc patterns and frameworks, dozens of design

patterns have been proposed, e.g. (Adams et al., 1996;

Meyer, 1997; Schmidt et al., 2000; Fowler, 2002; Lar-

man, 2004; Mattson et al., 2005; Erl, 2009), establish-

ing a kind of common language between development

teams, which substantially enriches their communica-

tion, and hence the whole design process.

Most of the work around design patterns has been

focused in the object-oriented paradigm, although

some of the patterns are fundamental enough to be

independent of the used modeling and programming

paradigms. Some effort has also been made in adapt-

ing some of these best practices to other paradigms

and in ﬁnding new paradigm-speciﬁc patterns (An-

toy and Hanus, 2002; Sterling, 2002; Oliveira and

Gibbons, 2005; Gibbons, 2006). In this spirit,

we carried the task of identifying several basic and

other, more complex, patterns in the paradigm of dl-

programs (Eiter et al., 2008) – which join description

logics with rules (expressed as a Datalog-like logic

program) –, a powerful and expressive approach to

reasoning over general knowledge bases or ontolo-

gies.

To the best of our knowledge, design patterns have

not been studied in the framework of dl-programs, in

spite of their importance. That is the goal of this pa-

per. In order to enhance both the modular nature of

dl-programs and the relevance of some important de-

sign principles, we resort to multi description logic

programs (Mdl-programs), a straightforward general-

ization of dl-programsto accommodatefor several de-

scription logics.

This work should be seen as quite distinct from

that on ontology design patterns (Gangemi and Pre-

sutti, 2009), a catalogue of which is maintained

at http://ontologydesignpatterns.org/. As their name

Cruz-Filipe L., Nunes I. and Gaspar G..

Patterns for Interfacing between Logic Programs and Multiple Ontologies.

DOI: 10.5220/0004544100580069

In Proceedings of the International Conference on Knowledge Engineering and Ontology Development (KEOD-2013), pages 58-69

ISBN: 978-989-8565-81-5

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

suggests, ontology design patterns are used in ontol-

ogy development, both to build new ontologies from

scratch or from other ontologies, and to update ex-

isting ones. In the setting of Mdl-programs, the on-

tologies are seen as immutable, being used and not

changed; therefore, our patterns focus almost exclu-

sively on the rule part of the Mdl-program, which is

the entity responsible for coordinating the ontologies.

Thus, ontology design patterns and design patterns for

Mdl-programs should in general be seen as two com-

plementary techniques, and not as alternatives.

The remainder of the paper is structured as fol-

lows. Section 2 explains the context and goals of this

work in more detail. Section 4 presents seven dif-

ferent design patterns, and Section 5 illustrates their

combined use by means of a larger example. Sec-

tion 6 explores limitations and future directions of re-

search, and Section 7 summarizes the contributions

presented earlier.

2 MOTIVATION

The usefulness of combining description logics with

rule-based reasoning systems led to the introduction

of dl-programs (Eiter et al., 2008; Eiter et al., 2011),

that couple a description logic knowledge base with

a generalized logic program, interacting by means of

special atoms, the dl-atoms.

Although the two components of a dl-program are

kept independent, giving dl-programs nice modularity

properties, there is a bidirectional ﬂow of information

via dl-atoms.

The purpose of this paper is to study design pat-

terns in dl-programs, as was previously done for other

programming paradigms – object-oriented (Gamma

et al., 1995), service-oriented (Erl, 2009), func-

tional (Norvig, 1996; Antoy and Hanus, 2002; Gib-

bons, 2006), logic (Sterling, 2002) and others. As

several of these authors observed, studying design

patterns in different programming paradigms is far

from being a trivial task: each paradigm has its spe-

ciﬁc features, meaning that patterns that are very

straightforward in one paradigm can be very complex

in another, and vice-versa.

Looking at dl-programs, it is clear that they rep-

resent a completely different programming paradigm

– not only are they closely related to the logic pro-

gramming paradigm, but they involve description

logic knowledge bases, in the presence of which the

study of design patterns attains a different quality: on

the one hand, some patterns become trivial (such as

FAC¸ADE) or meaningless (such as DYNAMIC BIND-

ING or SINGLETON), on the other hand some pat-

terns pose totally new problems that have not been

addressed in other paradigms where they do not arise

(such as PROXY, which we will discuss in Section 6).

We claim that dl-programs, being a dual-

component system, with a description logic and a

logic-based rule language, provide the adequate set-

ting for the study of design patterns for the Seman-

tic Web. We will work with a straightforward gen-

eralization that we will deﬁne precisely in the next

section: Mdl-programs (for Multi Description Logic

programs), which incorporate not one, but a ﬁnite set

of description logic knowledge bases. Mdl-programs

are, therefore, multi-component systems connected

by a logic program. This makes perfect sense when

we consider some of the more elaborate design pat-

terns, whose real power can only be appreciated in

this more general setting. Furthermore, most theoret-

ical results known for dl-programsimmediately trans-

late to similar results about Mdl-programs, fully jus-

tifying the use of the latter.

There are two questions that immediately come

to mind, though. In the ﬁrst place, if one wishes to

consider several ontologies, what are the advantages

of using Mdl-programs instead of merging all the de-

sired ontologies and use the result in a standard dl-

program? Also, why work within the framework of

Mdl-programs instead of within other existing frame-

works, such as the more general HEX-programs(Eiter

et al., 2006a) or multi-context systems (Brewka and

Eiter, 2007)? We feel it is important to provide sat-

isfactory answers to these two pertinent issues before

proceeding.

As regards the ﬁrst point, there are a number of ad-

vantages to keeping ontologies separate, which essen-

tially coincide with the reasons universally invoked to

defend modularity of large-scale systems. Not only is

it much more convenient to have independent knowl-

edge bases (which might even be physically sepa-

rated, or independently managed) than a single, gi-

gantic one, but merging ontologies is in itself a mighty

task with its own speciﬁc problems (Grau et al., 2005;

Bruijn et al., 2006).

Furthermore, ontologies are typically very wide-

spectrum, and in practice one does not need to work

with each of them in its entirety. Therefore, keeping

them separate also reduces the number of compatibil-

ity issues one has to deal with to the essential mini-

mum. Clearly, if there are two concepts in two differ-

ent ontologies that should be identiﬁed (from a par-

ticular application’s perspective) but are logically in-

consistent, this will always be a problem. However, if

that particular inconsistency is irrelevant for the goal

at hand (because the concepts involved are not used),

then not merging the ontologies will simply not raise

PatternsforInterfacingbetweenLogicProgramsandMultipleOntologies

that question – and our approach allows us to bypass

it altogether.

Also, the separation of the knowledge bases al-

lows us to make the most of the positive aspects of

each knowledge base – which is relevant if, say, one

of them is very efﬁcient at performingspeciﬁc reason-

ing tasks, while another features richer concept and

role constructions.

For these reasons, we feel that a setting that keeps

all relevant knowledge bases separate (where their

interaction is externally controlled) is preferable not

only for the purposes of this paper, but also as a gen-

eral principle.

As regards the second point, dl-programs (and

Mdl-programs) limit heterogeneity to two different

frameworks: description logics for the knowledge

bases part and logic programmingfor the rule part; the

latter somehow represents the “conductor” that “coor-

dinates” the other parts. However, they fully support

non-monotonicity (even at the level of the description

logic knowledge bases as will be seen later by ap-

plication of a speciﬁc basic pattern). Mdl-programs

are therefore a simpler framework than other, more

powerful, alternatives – which is an advantage for

our purpose; still, description logics are at the core

of the Semantic Web, with a huge effort being cur-

rently invested in the interchange between OWL –

an extension of the description logic SROIQ and a

W3C recommendation – and a diversity of rule lan-

guages (Kifer and Boley (eds.), 2010).

Furthermore, as we will discuss, Mdl-programs

inherit all the good properties of dl-programs, which

made them interesting in the ﬁrst place, while simul-

taneously keeping enough key ingredients of multi-

context systems and HEX-programsto make the study

of design patterns general.

3 Mdl-programs

Multi-description logic programs, the framework we

will use to introduce our design patterns in, general-

ize the deﬁnition of dl-programs in (Eiter et al., 2008)

to accommodate for several description logic knowl-

edge bases. This is in line with (Wang et al., 2005),

although we will stick to the original operators ⊎ and

∪

in dl-atoms.

A dl-atom relative to a set of knowledge bases

, . . . , L

}

, . . . , S

;Q](t),

The description logics underlying the L

s need not be

the same.

often abbreviated to DL

[χ;Q](t), where: (1) 1 ≤ i ≤

n; (2) each S

, with 1 ≤ k ≤ m, is either a concept or a

role from L

or a special symbol in {=, 6=}; (3) op

∈

{⊎, ∪

}; (4) p

are the input predicate symbols, which

are unary or binary predicate symbols depending on

the corresponding S

being a concept or a role; and

(5) Q(t) is a dl-query in the language of L

, that is, it

is either a concept inclusion axiom F or its negation

¬F, or of the form C(t

), ¬C(t

), R(t

, t

), ¬R(t

, t

= (t

, t

), 6= (t

, t

), where C is a concept, R is a role,

t, t

and t

are terms (variables or constants).

The operators ⊎ and ∪

are used to extend the

knowledge base L

locally, with S

⊎ p

(resp.,

∪

) increasing S

(resp., ¬S

) by the extension

of p

. Intuitively, the dl-atom above adds this infor-

mation to L

and then asks this knowledge base for

the set of terms satisfying Q(t).

A Multi Description Logic program (Mdl-

program) is a pair h{L

, . . . , L

}, P i where: (1) each

is a description logic knowledge base; (2) P is a

set of (normal) Mdl-rules, i.e. rules of the form

a ← b

, . . . , b

, not b

k+1

, . . . , not b

where a is a logic program atom and each b

, for

1 ≤ j ≤ p, is either a logic program atom or a dl-

atom relative to {L

, . . . , L

}. Note that P is a gener-

alized logic program, so negation is the usual, closed-

world, negation-as-failure. This is in contrast with the

, which (being description logic knowledge bases)

come with an open-world semantics.

The semantics of Mdl-programs is a straight-

forward generalization of the semantics for dl-

programs (Eiter et al., 2008) and will not be discussed

here, since it will not be needed explicitly. In partic-

ular, dl-programs can be seen as Mdl-programs with

only one knowledge base.

On top of Mdl-programs, we de-

ﬁne a useful syntactic construction. An

Mdl-program with observers is a tuple

h{L

, . . . , L

}, P , {Λ

, . . . , Λ

}, {Ψ

, . . . , Ψ

}i where:

(1) h{L

, . . . , L

}, P i is an Mdl-program; (2) for

1 ≤ i ≤ n, Λ

is a ﬁnite set of pairs hS, pi where S is

a concept, a role, or a negation of either, from L

and

p is a predicate from P ; (3) for 1 ≤ i ≤ n, Ψ

is a

ﬁnite set of pairs hp, Si where p is a predicate from

P and S is a concept, a role, or a negation of either,

from L

. For each pair in Ψ

or Λ

, the arities of S

and p must coincide. The sets Λ

, . . . , Λ

, Ψ

, . . . , Ψ

will occasionally be referred to as the observers of

The precise semantics is a straightforward adaptation

of (Eiter et al., 2008); the third operator therein introduced

can be deﬁned in terms of ∪

, but not including it simpli-

ﬁes the semantics of Mdl-programs, as discussed in (Wang

et al., 2005).

KEOD2013-InternationalConferenceonKnowledgeEngineeringandOntologyDevelopment

h{L

, . . . , L

}, P i. Intuitively, Λ

contains concepts

and roles in L

that P needs to observe, in the

sense that P should be able to detect whenever new

facts about them are derived, whereas Ψ

contains

the predicates in P that L

wants to observe. For

simplicity, when we consider Mdl-programs with

observers that only have one knowledge base, we will

omit the braces and refer to them as dl-programs with

observers.

The above Mdl-program with observers implicitly

deﬁnes the Mdl-program

, . . . , L

}, P

,...,Ψ

,...,Λ

where P

,...,Ψ

,...,Λ

is obtained from P by: (1) adding

rule p(X) ← DL

[;S](X) for each hS, pi ∈ Λ

, if S is

a concept (and its binary counterpart, if S is a role);

and (2) in each dl-atom DL

[χ;Q](t) (including those

added in the previous step), adding S⊎ p to χ for each

hp, Si ∈ Ψ

and S∪

p to χ for each hp, ¬Si ∈ Ψ

The next sections will discuss examples of Mdl-

programs in detail.

We are currently working on implementing Mdl-

programs with observers, using the

dlvhex

tool (Eiter

et al., 2006b), with the goal of experimenting with the

design patterns proposed herein.

We end this section with two remarks. The ﬁrst

one concerns the asymetry in the generalization from

dl-programs to Mdl-programs. The reader might be

wondering why we do not take this construction a step

further, and deﬁne a system with several description

logic knowledge bases and several logic programs.

The answer lies in the asymetry already present in

dl-programs themselves: the logic program is not

only a component of the system, it is also the com-

ponent responsible for interaction with the outside

world. In particular, the dl-program’s view of L is

the view from each dl-atom – all changes made by

P to the knowledge base only affect the logic pro-

gram’s view of it. Therefore, it is natural to consider

several knowledge bases with a single logic program

as the orchestrator (and where the outside world only

“sees” that program’s view of each knowledge base)

rather than a more democratic system with several

logic programs and severalknowledgebases freely in-

teracting with each other. This does not exclude that,

in the future, it might be worth to study connecting

patterns between two or more Mdl-programs (for in-

stance, using a Mdl-program as a module of another

Mdl-program, as a way to protect and restrict the ac-

cess to certain knowledge bases).

A second aspect concerns the similarities and dif-

ferences between Mdl-programs and multi-context

systems. In both cases, we are faced with several in-

dependent components connected by a set of rules – a

logic program, in the case of Mdl-programs, and the

sets of bridge rules, in multi-context systems. How-

ever, all components of multi-context systems are

observable from the outside world, since models of

multi-contextsystems contain models of each individ-

ual component. It is also interesting to observe that

the ﬂavor of bridge rules is pretty much captured by

the generalization to Mdl-programs with observers:

the pairs in the observer sets achieve the effect of sys-

tematically extending a predicate, concept or role in

one component with information from another com-

ponent, in the same way bridge rules control the in-

formation ﬂow within a multi-context system (Cruz-

Filipe et al., 2013).

4 DESIGN PATTERNS FOR

Mdl-programs

In this section, we present seven design patterns for

Mdl-programs. These are divided in two categories:

the three elementary design patterns are the building

blocks for the four more complex ones. Together,

these seven patterns form a powerful set from which

quite complex programs can be designed in a more

structured way, simplifying the programmer’s task

while at the same time yielding more ﬂexible pro-

grams that are easier to maintain.

The presentation of each design pattern follows a

similar scheme: we motivate the pattern by means of a

simple scenario leading to the development of a well-

designed program; from these we abstract a general

design pattern, presented as a pair problem/solution

within the context of an Mdl-program with observers

h{L

, . . . , L

}, P , {Λ

, . . . , Λ

}, {Ψ

, . . . , Ψ

}i. In the

next section, we develop a larger application, illus-

trating how the seven patterns work together, comple-

menting each other.

4.1 Elementary Design Patterns

We now introduce the three basic design patterns for

Mdl-programs.

4.1.1 Observing a Knowledge Base

We ﬁrst consider the case when the logic program

component systematically wants to import informa-

tion from a knowledge base in order to deﬁne a pred-

icate, keeping track of changes made to the relevant

concept or role in its deﬁning component.

Scenario. The National Zoo keeps an ontology con-

taining information about all the animals currently

PatternsforInterfacingbetweenLogicProgramsandMultipleOntologies

living in its premises, as well as several rules per-

taining to the characteristics of the different species.

This ontology L is used also by the company that pro-

vides food for all the zoo’s feline inhabitants, coupled

with a rule-based program P in a dl-program hL, P i.

In this program, it is necessary that P be constantly

updated with the information about the current feline

population of the zoo, hence the following rule was

included.

feline(X) ← DL[;Feline](X) (1)

Note that feline in the head of the rule is a predicate

from P whereas the Feline in the body is a concept

from L. No confusion can arise from this, since the

only place where concepts or roles from L may occur

in P is within dl-atoms.

The same program can be written as a dl-program

with observers, namely hL, P

′

, {hFeline, felinei},

0i,

where P

′

is P without rule (1). In both cases, any

changes made to Feline in the zoo’s ontology will be

automatically reproduced in P or P

′

. Although the

effect is the same, the latter option makes it very clear

that feline in P

′

is an observer of its homonym from

L, making the global dl-program with observers eas-

ier to understand and maintain.

Pattern Observer Down.

Problem. A predicate p from P needs to be updated

every time the extent (set of named individuals) of

a concept or role S (of the same arity as p) in L

changed.

Solution. Add the pair hS, pi to Λ

4.1.2 Dynamically Modifying the View of a

Knowledge Base

A second scenario occurs when one of the descrip-

tion logics’ functionality relies on the observation of

a predicate from P . Consider the following example.

Scenario. A sweets distributor provides the shops

selling its products containing general information

and reasoning about the different types of sweets on

sale. Being a generic knowledge base, this ontol-

ogy has no concrete facts: in particular, the extent

of the predicate Sweet is empty. Each shop interacts

with the central ontology by means of a particular dl-

program K B = hL, P i, where L is the central ontol-

ogy and P contains facts detailing the speciﬁc brands

of sweets being sold in that particular location. In or-

der for the program to function appropriately, Sweet

(in L) needs to be automatically updated whenever a

new fact is added to the relevant predicate in P , so

that this fact can be taken into account.

The shop Sweets In Heaven uses a predicate

forSale in P to store the information about the brands

available at their shop. In order to use L to reason

about these products, they need to replace all dl-atoms

DL[χ;Q](t) in P with DL[Sweet ⊎ forSale, χ;Q](t)

meaning that L behaves as though its predicate Sweet

was actually extended with all sweets for sale at

Sweets In Heaven. This is exactly the same as

replacing K B by the dl-program with observers

hL, P ,

0, {hforSale, Sweeti}i.

Pattern Observer Up.

Problem. A concept or role S from L

needs to be up-

dated every time the extent of a predicate p (of the

same arity as S) in P is changed.

Solution. Add the pair hp, Si to Ψ

4.1.3 Closing the World

The third building block addresses a very typical situ-

ation in ontology usage: in order for a concept or role

to work as expected, it should be given closed-world

semantics.

Scenario. A digital library has an ontology with in-

formation about all the titles it contains. One of the

concepts it deﬁnes is ForSale, applicable to electronic

books that are available for download for a price.

However, description logics are not able to perform

closed-world reasoning, so a query to the ontology

about ¬ForSale is not sufﬁcient to inform a user that

a given title is not for sale.

With this in mind, the software developers work-

ing for the digital library integrated the ontology L

in the framework of a dl-program hL, P i, where P is

a very simple program containing only the following

rules.

forSale(X) ← DL[;ForSale](X)

notForSale(X) ← not forSale(X)

The information about titles that are not for

sale is now directly available in the predicate

notForSale of P . Furthermore, if the library later

wants to extend P further, then all dl-atoms must

be of the form DL[ForSale ∪

notForSale, χ;Q](t)

– thus querying L extended with the desired

closed-world interpretation of ForSale. For this

reason, it is much safer to write the result-

ing program as the dl-program with observers

hL, P , {hForSale, forSalei}, {hnotForSale, ¬ForSalei}i,

where P contains only the second of the above rules.

KEOD2013-InternationalConferenceonKnowledgeEngineeringandOntologyDevelopment

Pattern Closed-world.

Problem. The concept (or role) S from L

should fol-

low closed-world semantics.

Solution.

Choose predicate symbols s

, s

−

not used in P .

Add hS, s

i to Λ

, hs

−

, ¬Si to Ψ

, and s

−

(X) ←

not s

(X) to P .

4.2 Derived Design Patterns

The examples presented thus far should sufﬁce at this

stage to give the user a feel for dl-programs. We now

present a second set of general-purpose design pat-

terns that can be seen as organized combinations of

the previous ones, but are also useful as components

of more complex patterns. The usage of this design

patterns is exempliﬁed in the next section.

4.2.1 Flexible Deﬁnitions

The next design pattern allows one to deﬁne a predi-

cate in P abstracting from how it is represented in the

knowledge bases.

Scenario. Vineyards are a major tourist atraction of

Wineland. Knowing this, the country’s Tourist In-

formation Ofﬁce has decided to combine information

from the three major regional wine producers’ asso-

ciations in an Mdl-program K B = h{L

, L

}, P i,

where the L

s are the knowledge bases containing in-

formation about the wines produced in each region,

by means of which tourists can access the informa-

tion present in all three.

Since the three knowledge bases were developed

independently, the need arose for a predicate unify-

ing the concept of wine, which is distributed among

them. Therefore, P needs to import all the informa-

tion from the corresponding predicates wine from L

wineBrand from L

and product from L

To unify these three concepts in a single predicate

in P , the Tourist Information Ofﬁce included the three

following rules in its program.

wine(X) ← DL

[;wine](X)

wine(X) ← DL

[;wineBrand](X)

wine(X) ← DL

[;product](X)

This amounts to rewriting the Mdl-program

K B as the Mdl-program with observers

h{L

, L

}, P , {Λ

, Λ

}, {

0}i where:

= {hwine, winei}

= {hwineBrand, winei}

= {hproduct, winei}

Pattern Polymorphic Entities.

Problem. In P there is a predicate p whose instances

are inherited from concepts or roles S

, . . . , S

where each S

comes from the knowledge base

ϕ( j)

, for 1 ≤ j ≤ n.

Solution. For each 1 ≤ j ≤ n, add the pair hS

, pi to

ϕ( j)

Note that POLYMORPHIC ENTITIES consists of a

combined application of several OBSERVER DOWN,

all with the same observer predicate in P .

This pattern captures the essences of the Polymor-

phism and Dynamic Binding patterns from object-

oriented programming (Larman, 2004): these patterns

deal (at different levels) with deﬁnitions that are kept

separate from their usage. In POLYMORPHIC ENTI-

TIES, we deal with a predicate that is kept as indepen-

dent as possible from its deﬁnition. Instead of deﬁn-

ing clauses, the instances are plugged in through the

use of Mdl-programs with observers, thus external-

izing the deﬁnition of the predicate – in the spirit of

Dynamic Binding. The possibility of using different

concepts or roles (possibly even from different knowl-

edge bases) captures the essence of Polymorphism.

4.2.2 Interconnecting Description Logics

Another variant of the Observer design pattern occurs

when a description logic’s functionality relies on the

observation of a predicate in a different description

logic; this can be achieved by combining both the

OBSERVER UP and OBSERVER DOWN patterns, thus

making the logic program P a mediator. A particu-

lar case arises when an ontology designed primarily

for reasoning interacts with a knowledge base that is

mostly about particular instances. In practice, this de-

sign pattern appears mostly in combination with DEF-

INITIONS WITH HOLES, so we will postpone the pre-

sentation of a concrete scenario to the next step.

Pattern Transversal Observer.

Problem. A concept (or role) S from L

needs to be

updated every time the extent of a concept (resp.

role) R from L

is changed (with i 6= j).

Solution. Choose a predicate symbol p not used in P .

Add hR, pi to Λ

and hp, Si to Ψ

Note that TRANSVERSAL OBSERVER consists of a

PatternsforInterfacingbetweenLogicProgramsandMultipleOntologies

combined application of OBSERVER UP together with

OBSERVER DOWN, relative to two different descrip-

tion logics.

4.2.3 Underspeciﬁcation

In a modular system, it makes perfect sense to use

concepts whose deﬁnition is left to other components.

This is the motivation for the next design pattern.

Scenario. A company is designing an ontology to

help with school management. One of the rules in-

cluded in the ontology is

canAskDiplom m a ⊑ graduated ⊓ ¬onHold ,

stating that a student can ask for his diplomma af-

ter graduating if he has no pending issues with the

school. Although graduated is a predicate deﬁned in

this ontology, the company has no way of knowing a

priori which criteria to use to decide whether a stu-

dent still has pending issues with the school, as this

varies from school to school.

Therefore, the ontology will not have any infor-

mation about instances of onHold – the deﬁnition

of this concept will be left to other components that

will be integrated with the ontology through an Mdl-

program via OBSERVER or POLYMORPHIC ENTI-

TIES.

Pattern Deﬁnitions with Holes.

Problem. In L

there is a concept or role S needed

for reasoning but its deﬁnition will be in L

(with

i 6= j) or P .

Solution.

Use S in L

without deﬁning it (so the extent of S

is empty).

Later, connect S to its deﬁnition using OBSERVER

UP, OBSERVER DOWN or TRANSVERSAL OB-

SERVER, possibly coupled with POLYMORPHIC

ENTITIES.

In our example, suppose the company’s ontology

is integrated in an Mdl-program h{L

, L

}, P i,

where L

is the school’s own knowledge base (es-

sentially a database containing information about the

school’s students) and P contains rules connecting

both and performing other reasoning tasks. In that

school, a student is onHold if he is owing money

to the school (stored in L

by means of the concept

inDebt); hence, one can apply TRANSVERSAL OB-

SERVER to deﬁne o nHold as an observer of inDebt.

In a different, elite, school, the same concept is im-

plemented differently, since the school forces its stu-

dents to get extra credit by attending at least ﬁve

seminars; so here onHold is an OBSERVER of (≤

attendedSeminar) ⊔ inD ebt. Note that, in this situa-

tion, the school’s knowledge base would need to pro-

vide an auxiliary concept equivalent to this condition

due to the restrictions on the syntax of dl-queries.

This pattern corresponds to the Template Method

pattern of object-oriented programs (Gamma et al.,

1995), and to the Programming with Holes technique

of (Meyer, 1997).

In the next section we will show an example where

the holes are ﬁlled in by resorting to POLYMORPHIC

ENTITIES.

4.2.4 Distributed Deﬁnitions

The last design pattern in this section applies when a

predicate’s deﬁnition is split between different com-

ponents of the Mdl-program.

Scenario. A company sells cars in several dealers

across town. Each dealer has access to the company’s

car knowledge base L, which speciﬁes several prop-

erties of the available models and the dealers which

sell them. One of the dealers with the company has

his own information stored as a rule-based program

P . To integrate both systems, he uses a dl-program;

however, he still needs to share some concepts be-

tween both components. For example, the concept

car, whose instances include all cars centrally avail-

able for sale, is deﬁned in L, but P has information

about second-hand cars that occasionally go through

the store, stored in a predicate secondHandCar and

which the dealer wants to reason about in his view of

L; P also has information about motor bikes, that also

occasionally go through the store, stored in a predi-

cate mo t orBike, and which should be considered dis-

tinct from cars, when reasoning in P ’s view of L. In

order to achieve full integration between the two com-

ponents, he added two new predicates car

and car

−

to P , connecting them to his predicates by means of

the two rules

car

(X) ← secondHan dCar(X)

car

−

(X) ← motorBike(X)

and with car from L via the two rules

car

(X) ← DL[;car](X)

car

−

(X) ← DL[;¬car](X).

Furthermore, every dl-atom DL[χ;Q](t) needs to be

replaced by DL[car⊎car

, car∪

car

−

, χ;Q](t). In this

way, one can use positive and negative facts about

cars both in L and in P .

Using Mdl-programs with observers, the same

construction can be designed in a simpler way: the

KEOD2013-InternationalConferenceonKnowledgeEngineeringandOntologyDevelopment

only rules one needs to include in P are the two

ﬁrst ones (relating car

with secondHandCar and

car

−

with mo torBike), while the rest is achieved

by taking Λ = {hcar, car

i, h¬car, car

−

i} and Ψ =

{hcar

, cari, hcar

−

, ¬cari}.

Pattern (Named) Lifting.

Problem. The deﬁnition of a predicate should be dis-

tributed among some of the L

s (in the form of

concepts or roles S

) and P (in the form of two

predicates p

and p

−

, corresponding to the pred-

icate and its negation).

Solution.

For each i, add hS

, p

i and h¬S

, p

−

i to Λ

For each i, add hp

, S

i and hp

−

, ¬S

i to Ψ

Note that LIFTING is essentially different from

OBSERVER: in OBSERVER, a predicate is deﬁned in

one component and used in others; in LIFTING, not

only the usage, but also the deﬁnition of the predi-

cate is split among several components, so that one

must look at the whole Mdl-program to understand it.

This is also part of the reason to include the negations

of the predicates involved in the observers: the dis-

tributed predicate must end up with the same seman-

tics, both in P and in all the involved L

s – at least

regarding named individuals.

It is possible to apply LIFTING when P does not

participate in the predicate’s deﬁnition. In this case,

P is simply a mediator, and p

and p

−

can be any

fresh predicate names.

Note that the application of each of the patterns

proposed in this section yields localized changes to

the Mdl-program: they consist of either changing dl-

atoms (by means of adding pairs to Ψ

) or adding

rules to P (either directly, as in the case of CLOSED-

WORLD, or by adding pairs to Λ

). In all cases, these

changes are only reﬂected in P , and they can be di-

vided into two or three distinct types. This is in line

with the whole philosophy of dl-programs: there is an

asymmetry between their componentswhere the logic

program is the orchestrator between all components

as well as its fac¸ade: it is the only entity interacting

with the outside world.

5 A COMPREHENSIVE

EXAMPLE

We now illustrate the usage of the different design

patterns introduced so far by means of a more com-

plex example.

Scenario. The software developers at WISHYOU-

WERETHERE travel agency decided to develop an

Mdl-program to manage several of the agency’s day-

to-day tasks. Currently, WISHYOUWERETHERE has

two active partnerships, one with an aviation com-

pany, another with a hotel chain. Thus, the Mdl-

program to be developed uses three ontologies:

• L

is a generic accounting ontology for travel

agencies, which is commercially available, and

which contains all sorts of rules relating concepts

relevant for the business. This ontology is strictly

terminological, containing no speciﬁc instances of

its concepts and roles.

• L

is the aviation partner’s knowledge base,

containing information not only about available

ﬂights between different destinations, but also

about clients who have already booked ﬂights

with that company.

• L

is a similar knowledge base pertaining to the

hotels owned by the partner hotel chain.

One of the points to take into consideration is

that the resulting Mdl-program with observers

h{L

, L

}, P , {Λ

, Λ

}, {Ψ

, Ψ

should be easily extended so that the travel agency

can establish new partnerships, in particular with

other aviation companies and hotel chains, as long

as those provide their own knowledge bases. At the

end of this section, we will show how the systematic

use of design patterns and observers helps towards

achieving this goal.

By establishing partnerships, WISHYOUWERE-

THERE’s client basis is extended with all the clients

who have booked services of its partners. In this way,

promotions made available by either partner are au-

tomatically offered to every partner’s clients, as long

as the bookings are made through the travel agency.

In return, the partners get publicity and more clients,

since a person may be tempted to ﬂy with their com-

pany or book their hotel due to these promotions,

thereby becoming also their client.

Updating the Client Database. Ensuring that each

partner’s clients automatically become WISHYOU-

WERETHERE’s clients can be achieved by noting that

this is exactly the problem underlying OBSERVER

DOWN. Assuming L

and L

have concepts Flyer

and Guest, respectively, identifying their clients, and

that the agency’s clients will be stored as a predicate

client in P , all that needs to be done is to register

client as an observer of Flyer and Guest, which, ac-

cording to the pattern, is achieved by ensuring that

hFlyer, clienti ∈ Λ

and hGuest, clienti ∈ Λ

PatternsforInterfacingbetweenLogicProgramsandMultipleOntologies

Identifying Pending Payments. The designers of

resorted intensively to DEFINITIONS WITH

HOLES, since many of the concepts they use can

only be deﬁned in the presence of a concrete client

database. In particular, L

contains a role toPay,

about which it contains no membership axioms. The

information about the speciﬁc purchases a client has

made and not paid so far must be collected from the

partners’ knowledge bases, L

and L

There are two ways of completing this deﬁnition.

The more direct one stems from noting that toPay

should be an observer of adequate roles in L

and

. We will assume that these roles are payFlight

and payHotel. Applying twice TRANSVERSAL OB-

SERVER (which is the adequate pattern), one needs to

ensure that

hpayFlight, toPayFi ∈ Λ

htoPayF, toPayi ∈ Ψ

hpayHotel, toPayHi ∈ Λ

htoPayH, toPayi ∈ Ψ

The major drawback of this solution is that it requires

adding two dummy predicates to P whose only pur-

pose is to serve as go-between from both knowledge

bases to L

. An alternative solution is to create a sin-

gle auxiliary predicate toPay in P and make toPay

from L

an observer of this predicate applying OB-

SERVER UP. In turn, we use the POLYMORPHIC

ENTITY pattern to connect toPay to payFlight and

payHotel. The resulting Mdl-program with observers

is such that:

hpayFlight, toPayi ∈ Λ

hpayHotel, toPayi ∈ Λ

htoPay, toPayi ∈ Ψ

As we will discuss later, this solution will also sim-

plify the process of adding new partners to the agency.

Offering Promotions. WISHYOUWERETHERE

offers a number of promotions to its special clients.

For example, in February the agency offers them

a 20% discount on all purchases. Because of the

partnership, the concept of special client is distributed

among all partners: a client is a special client if it

fulﬁlls one of the partners’ requirements – e.g. having

traveled some number of miles with the airline

partner, or booked a family holiday in one of the

partner’s hotels, or bought one of the agency’s pricey

packages. The partnership protocol requires that

each knowledge base provide a concept identifying

which clients are eligible for promotions, so that the

partners can change these criteria without requiring

WISHYOUWERETHERE to change its program.

This is a situation where the LIFTING design pat-

tern applies. Assuming that L

uses TopClient for its

special clients, L

uses Gold and P deﬁnes special,

these three predicates are given the same semantics

through LIFTING. Intuitively, this means that, in the

Mdl-program’s view, all three concepts equally de-

note all special clients, regardless of where they orig-

inate. The application of the pattern translates to

hTopClient, spe ciali ∈ Λ

hsp ecial, TopClienti ∈ Ψ

h¬TopClient, notSpeciali ∈ Λ

hnotSpecial, ¬TopClienti ∈ Ψ

and four similar observers in Λ

and Ψ

, with Gold

in place of TopClient.

Furthermore, in order to determine whether a par-

ticular client is entitled to promotions, it is useful

to give closed-world semantics to these predicates.

Since they are all equivalent, we can do this very sim-

ply in P by adding the rule

notSpecial(X) ← not s pecial(X).

Note that we did not need to apply the CLOSED-

WORLD pattern because special is a predicate from P ,

where the semantics is closed-world: the application

of LIFTING ensures that Gold and TopClient, being

equivalent, also have closed-world semantics.

In order for one of the partner companies

to make its clients eligible for special promo-

tions, its ontology just needs to contain in-

clusion axioms partially characterizing special

clients. For example, L

might contain the rule

∃ﬂies.10000OrMore ⊑ TopClient, or L

might

specify that ∃hasCompleted.FamilyBooking ⊑ Gold,

or spec ial(X) ← booked(X, Y), expensive(Y) might

be a rule in P .

A subtle issue now appears regarding the consis-

tency problems that may arise from the use of the

LIFTING pattern. Since this pattern identiﬁes con-

cepts from different knowledge bases, it does not a

priori guarantee that the resulting knowledge bases

are consistent. In particular, if one of the partners

grants special status to a client and another denies this

status to the same client, an inconsistency will arise.

More sophisticated variations of the LIFTING pattern

can be developed to detect and avoid this kind of sit-

uation, but such a discussion is beyond the scope of

this presentation.

An example of a promotion offered by WISH-

YOUWERETHERE to special clients would be

20%Discou nt(X) ← special(X).

All special clients will beneﬁt from this discount, re-

gardless of who (the travel agency, the hotel partner

or the aviation company) decided that they should be

special clients. However, in some cases partners may

want to deny their promotions to particular clients.

For example, the aviation company is offering 100

KEOD2013-InternationalConferenceonKnowledgeEngineeringandOntologyDevelopment

bonus miles to special costumers booking a ﬂight on

a Tuesday, but this promotion does not apply to its

workers. In order to allow this kind of situation, part-

ners may deﬁne a dedicated concept identifying the

non-eligible clients. Since all clients external to that

partner are automatically eligible, this concept needs

to have closed-world semantics so that (in our exam-

ple) L

can include the rules

100BonusMilesWinner ⊑ TopClient ⊓ ¬Blocked

Worker ⊑ Blocked

still giving the promotion to all clients from the other

partners. Although each knowledge base can enforce

this semantics in its domain, in order to extend it to

other clients the CLOSED-WORLD pattern must be

applied, so we will have

hBlocked, blockedFi ∈ Λ

hnonBlockedF, ¬Blockedi ∈ Ψ

nonBlockedF(X) ← not blockedF(X) ∈ P

Suppose that airline employee Ann qualiﬁes

for WISHYOUWERETHERE promotions because she

spent three weeks in Jamaica with her husband

and their ﬁve children, hence Gold(Ann) holds in

and therefore Ann is a special client. She

is therefore eligible for WISHYOUWERETHERE’s

promotions, but she will still not earn the bonus

miles because it is L

who decides whether some-

one gets that particular promotion, and even though

TopClient(Ann) holds that knowledge base will not

return 1 00BonusMi lesWinner(Ann). However, she

will earn the 20%Discount, since it is offered directly

by WISHYOUWERETHERE.

Adding New Partnerships. We now discuss brieﬂy

how new partners can be easily added to the system

later on, as this illustrates quite well the advantages of

working both with design patterns and in the context

of Mdl-programs with observers.

Summing up what we have so far relating to the

partnerships, the sets Λ

, Λ

, Ψ

and Ψ

are:

: hFlyer, c lienti Λ

: hGuest, clienti

hpayFlight, toPayi hpayHotel, toPayi

hTopClient, spe ciali hGold, speciali

h¬TopClient, notSpeciali h¬Gold, notSpeciali

hBlocked, blockedFi hBlocked, blockedHi

:hspecial, TopClienti

hnotSpecial, ¬TopClienti

hnonBlockedF, ¬Blo ckedi

:hspecial, Goldi

hnotSpecial, ¬Goldi

hnonBlockedH, ¬Blockedi

Also, the application of the design patterns added

the following rules to P .

nonBlockedF(X) ← not blockedF(X)

nonBlockedH(X) ← not blockedH(X)

notSpecial(X) ← not s pecial(X)

The similarity between Λ

and Λ

, and between Ψ

and Ψ

, is a clear illustration of the changes required

when future partners of WISHYOUWERETHERE are

added to the system. Furthermore, the names they use

for each concept or role are not relevant – they just

need to indicate how they identify their clients, their

clients’ debts, their special clients, and the clients they

wish to exclude from their promotions.

6 BEYOND THESE PATTERNS:

LIMITATIONS AND FUTURE

WORK

We have shown so far how the ideas of design pat-

terns can be applied to Mdl-programs, yielding gen-

eral principles for this programming paradigm. In this

section we explore some limitations and discuss fu-

ture directions for our work.

In many contexts, a component of a system may

not be known or available at the time of implementa-

tion of others, yet it is necessary to query it. A way to

get around this is to use a prototype knowledge base

that will later on be connected to the concrete compo-

nent in a straightforward way. The same problem also

arises if one wishes to be able to replace a knowledge

base with another with a similar purpose, but whose

concept and role names may be different. This can be

achieved by means of the following pattern.

Pattern (Straight) Adapter.

Problem. One wants to work with L

independently

of its particular syntax.

Solution. Add an empty interface knowledge base L

to K B using the desired concept and role names.

Connect each concept and role in L

with its coun-

terpart in L

by means of an application of the

TRANSVERSAL OBSERVER pattern.

There is one important characteristic of this imple-

mentation that distinguishes it from the usual Adapter

PatternsforInterfacingbetweenLogicProgramsandMultipleOntologies

design pattern: the dl-program syntax for local exten-

sions to dl-queries only works in the particular case

where the query is over a concept or role being di-

rectly extended. Because all queries go through the

interface knowledge base, where no axioms exist, any

other extensions are lost.

Consider a simple example where the interface L

speciﬁes two concepts P and Q, which are made con-

crete in L

as A and B. Furthermore, L

also contains

the inclusion axiom A ⊑ B. Finally, P contains the

single fact thisIsTrue(ofMe). In P , the direct query

[A ⊎ thisIsTrue;B](X) would return the answer

X = ofMe, since L

is extended with A(ofMe) in the

context of this query. However, the corresponding in-

direct query (i.e. the same query, but passing through

the adapter)

[P⊎ p

, P∪

−

, Q⊎ q

, Q∪

−

, P⊎ thisIsTrue;Q](X)

after extending P with the rules

(X) ← DL

[;A](X) q

(X) ← DL

[;B](X)

−

(X) ← DL

[;¬A](X) q

−

(X) ← DL

[;¬B](X)

as introduced by the concretization of the observer

sets would still return no answer, since L

only

knows the facts about B that are directly given by L

through q

Note, however, that the dl-atom DL

[A ⊎

thisIsTrue;A](X) is equivalent to

[P⊎ p

, P∪

−

, Q⊎ q

, Q∪

−

, P⊎ thisIsTrue;P](X),

since the query is directly on the concept whose ex-

tent was altered. In practice, this is a common enough

situation that this issue is less restrictive than it may

seem. This is a restriction with respect to the full

power of dl-programs; but the authors see this as a

feature of the STRAIGHT ADAPTER design pattern.

Should a context arise where such ﬂexibility is essen-

tial, then this is not the right design pattern to apply.

A more complex problem arises with the PROXY

design pattern. This pattern is used when one wants

to control or restrict access to a resource, for exam-

ple a database containing sensitive information. In

practice, this is not very different from the ADAPTER

design pattern – but ADAPTER is an algorithm-free

pattern that just deﬁnes interfaces, whereas an entity

implementing PROXY is expected to do some process-

ing before passing on the information it receives.

If we attempt an implementation along the lines

we have followed so far, it would be natural to ex-

plore the possibility of a proxy knowledge base to

serve as a mediator between two components. In the

setting of dl-programs, this is actually not possible to

achieve directly, since all queries must go through the

logical program. The only other option is to encode

the proxy in the logic program itself, forcing every

dl-query to the protected resource to be immediately

preceded by some atoms implementing the proxy –

which from the PROXY design pattern perspective is

not completely satisfactory. There would be ways to

go around this problem, namely by deﬁning appropri-

ate syntactic constructions, which we intend to pursue

in future extensions of this work.

7 CONCLUSIONS

We proposed Mdl-programs as a generalization of dl-

programs to systems that connect several description

logics by means of a logic program. On top of these,

we deﬁned a syntactic construction (observers) that

supports communication between the logic program

and the different knowledge bases in a structured way,

allowing one to externalize several communication

aspects and focus on the development of the algorith-

mic parts of the program.

The original motivation for deﬁning Mdl-

programs with observers was to achieve global

changes to the knowledge bases in the logic pro-

gram’s view of them, by guaranteeing that all

dl-queries were appropriately extended, even the ones

that were written after deciding that a concept or role

should be observing a predicate. As we showed, this

construction is powerful enough to allow for elegant

and straightforward implementations of several well-

known design patterns. By deﬁning other adequate

syntactic constructions, other design patterns may

become easily accessible. In fact, it has been argued

that the study of design patterns can be a key ingre-

dient in deciding what syntactic extensions should be

added to speciﬁc programming languages (Gibbons,

2006). In this spirit, we believe that we have more

than justiﬁed the inclusion of observers as a syntactic

tool in the context of Mdl-programs.

Another aspect that will have to be discussed re-

lates to the practical issues of the usage of design

patterns. Ad hoc solutions to speciﬁc problems may

be more efﬁcient than the application of systematic

methods, but they tend to yield less generalizable and

less extensible software applications. On the other

hand, the use of observers introduces higher complex-

ity, especially when non-stratiﬁed negation (which

occurs in the examples discussed earlier) is involved.

It is important to have a precise understanding of the

compromise between efﬁciency and quality obtained

by a systematic use of design patterns. We are work-

ing on building a prototype implementation of Mdl-

programs within

dlvhex

tool (Eiter et al., 2006b) as a

ﬁrst step towards this study.

KEOD2013-InternationalConferenceonKnowledgeEngineeringandOntologyDevelopment

The purpose of the present study, at this stage, is

to show that design patterns also have a place in the

world of the Semantic Web. One can foresee a future

where there is a widespread usage of systems combin-

ing description logics with rules, and the availability

of systematic design methodologies is a key ingredi-

ent to making this future a reality. This paper is by

necessity limited in its scope, and it is the authors’

intent to explore how more sophisticated design pat-

terns could be applied to Mdl-programs.

It would also be interesting to explore how the

mechanisms herein discussed can be applied to multi-

context systems, in view of the similarities between

these and Mdl-programs. A preliminary study of this

connection has been undertaken in (Cruz-Filipe et al.,

2013).

ACKNOWLEDGEMENTS

This work was partially supported by Fundac¸˜ao para

a Ciˆencia e Tecnologia under contract PEst-OE/EEI/

UI0434/2011.

REFERENCES

Adams, M., Coplien, J., Gamoke, R., Hanmer, R., Keeve,

F., and Nicodemus, K. (1996). Fault-tolerant telecom-

munication system patterns. In Pattern Languages of

Program Design 2, pages 549–562. Addison–Wesley

Longman Publishing Co., Inc., Boston, MA, USA.

Antoy, S. and Hanus, M. (2002). Functional logic design

patterns. In Hu, Z. and Rodr´ıguez-Artalejo, M., ed-

itors, Proceedings of FLOPS 2002, volume 2441 of

LNCS, pages 67–87. Springer.

Brewka, G. and Eiter, T. (2007). Equilibria in heteroge-

neous nonmonotonic multi-context systems. In Pro-

ceedings of AAAI-07, pages 385–390. AAAI Press.

Bruijn, J. d., Ehrig, M., Feier, C., Mart´ıns-Recuerda, F.,

Scharffe, F., and Weiten, M. (2006). Ontology media-

tion, merging, and aligning. In Davies, J., Studer, R.,

and Warren, P., editors, Semantic Web Technologies:

Trends and Research in Ontology-based Systems. John

Wiley & Sons, Ltd, Chichester, UK.

Cruz-Filipe, L., Henriques, R., and Nunes, I. (2013). View-

ing dl-programs as multi-context systems. Technical

Report 2013;05, Faculty of Sciences, University of

Lisbon. http://hdl.handle.net/10455/6895.

Eiter, T., Ianni, G., Lukasiewicz, T., and Schindlauer, R.

(2011). Well-founded semantics for description logic

programs in the semantic Web. ACM Transactions on

Computational Logic, 12(2). Article 11.

Eiter, T., Ianni, G., Lukasiewicz, T., Schindlauer, R., and

Tompits, H. (2008). Combining answer set program-

ming with description logics for the semantic web. Ar-

tiﬁcial Intelligence, 172(12–13):1495–1539.

Eiter, T., Ianni, G., Schindlauer, R., and Tompits, H.

(2006a). Effective integration of declarative rules with

external evaluations for semantic-web reasoning. In

Sure, Y. and Domingue, J., editors, Proceedings of

ESWC 2006, volume 4011 of LNCS, pages 273–287.

Springer.

Eiter, T., Ianni, G., Schindlauer, R., and Tompits, H.

(2006b). Towards efﬁcient evaluation of HEX pro-

grams. In Dix, J. and Hunter, A., editors, Proceed-

ings of NMR-2006, Answer Set Programming Track,

pages 40–46. Institut f¨ur Informatik, TU Clausthal,

Germany.

Erl, T. (2009). SOA Design Patterns. Prentice Hall, New

York.

Fowler, M. (2002). Patterns of Enterprise Application Ar-

chitecture. Addison–Wesley.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J.

(1995). Design Patterns: Elements of Reusable

Object-Oriented Software. Addison–Wesley.

Gangemi, A. and Presutti, V. (2009). Ontology design pat-

terns. In Staab, S. and Studer, R., editors, Handbook

on Ontologies, International Handbooks on Informa-

tion Systems, pages 221–243. Springer. 2nd edition.

Gibbons, J. (2006). Design patterns as higher-order

datatype-generic programs. In Hinze, R., editor, Pro-

ceedings of WGP 2006, pages 1–12. ACM.

Grau, B., Parsia, B., and Sirin, E. (2005). Combining OWL

ontologies using e-connections. Journal of Web Se-

mantics, 4(1):40–59.

Kifer, M. and Boley (eds.), H. (2010). RIF overview. W3C

Working Group Note, http://www.w3.org/TR/2010/

NOTE-rif-overview-20100622/.

Larman, C. (2004). Applying UML and Patterns. Prentice–

Hall. 3rd Edition.

Mattson, T., Sanders, B., and Massingill, B. (2005). Pat-

terns for Parallel Programming. Addison–Wesley.

Meyer, B. (1997). Object-Oriented Software Construction.

Prentice–Hall. 2nd Edition.

Norvig, P. (1996). Design patterns in dynamic pro-

gramming. Tutorial slides presented at Object

World, Boston, MA, May 1996, available at http://

norvig.com/design-patterns/.

Oliveira, B. and Gibbons, J. (2005). TypeCase: a design

pattern for type-indexed functions. In Leijen, D.,

editor, Proceedings of Haskell 2005, pages 98–109.

ACM.

Schmidt, D., Stal, M., Rohnert, H., and Buschmann, F.

(2000). Pattern-Oriented Software Architecture, Vol-

ume 2: Patterns for Concurrent and Networked Ob-

jects. John Wiley & Sons.

Sterling, L. (2002). Patterns for Prolog programming. In

Kakas, A. and Sadri, F., editors, Computational Logic:

Logic Programming and Beyond, Essays in Honour

of Robert A. Kowalski, Part I, volume 2407 of LNCS,

pages 374–401. Springer.

Wang, K., Antoniou, G., Topor, R., and Sattar, A. (2005).

Merging and aligning ontologies in dl-programs. In

Adi, A., Stoutenburg, S., and Tabet, S., editors, Pro-

ceedings of RuleML 2005, volume 3791 of LNCS,

pages 160–171. Springer.

PatternsforInterfacingbetweenLogicProgramsandMultipleOntologies