=Paper=
{{Paper
|id=Vol-273/paper-2
|storemode=property
|title=C-ODO: an OWL meta-model for collaborative ontology design
|pdfUrl=https://ceur-ws.org/Vol-273/paper_38.pdf
|volume=Vol-273
|dblpUrl=https://dblp.org/rec/conf/www/GangemiLPNC07
}}
==C-ODO: an OWL meta-model for collaborative ontology design==
https://ceur-ws.org/Vol-273/paper_38.pdf
C-ODO: an OWL meta-model
for collaborative ontology design
Aldo Gangemi Valentina Presutti Carola Catenacci
Laboratory for Applied Ontology Laboratory for Applied Ontology Laboratory for Applied Ontology
National Research Council National Research Council National Research Council
(ISTC-CNR) (ISTC-CNR) (ISTC-CNR)
Roma, Italy Roma, Italy Roma, Italy
aldo.gangemi@istc.cnr.it valentina.presutti@istc.cnr.it carola.catenacci@istc.cnr.it
Jos Lehmann Malvina Nissim
Laboratory for Applied Ontology Laboratory for Applied Ontology
National Research Council National Research Council
(ISTC-CNR) (ISTC-CNR)
Roma, Italy Roma, Italy
jos.lehmann@istc.cnr.it nissim@loa-cnr.it
ABSTRACT gies in heterogeneous social contexts is a major issue. The
The design and maintenance of ontologies is a complex so- work presented in this paper is the result of a preliminary
cial collaborative activity, and this is true especially for requirements analysis for collaborative design that has been
semantic-web ontologies. On the one hand, such activity conducted in NeOn, and is extensively reported in [3].
calls for the availability of tools providing support to typical The main focus of the paper is a formal framework to be
operations such as the reuse of existing ontologies and de- used as a requirement language for the ‘social level’ aspects
sign patterns, the re-engineering of thesauri, lexicons, folk- of ontology design. We assume that the specification at the
sonomies, database schemas, and knowledge from corpora, computational level should mirror the social requirements
or to the appropriate evaluation and selection processes which of ontology design, and that this can be done in one of two
are needed in order to make an ontology functional to a given ways: i) by substituting social-level tasks with computa-
task. On the other hand, tools able to support the collab- tional tasks, or ii) by assisting social-level tasks specified as
orative performance of all these operations, aiding e.g. the proxies within a workflow of computational tasks. For exam-
discussion and consensus-reaching processes on an ontology ple, a method for ontology evaluation can be described for-
element and its rationale, should be provided too. Current mally at the social level, and, when the evaluation is limited
tools substantially fail to address both types of need. In our to the structural aspects of an ontology, most tasks can be
opinion, this is partly due to the lack of both an adequate re- accomplished by an implemented algorithm. On the other
quirement analysis, which describes the actual processes and hand, if evaluation at some point requires an active decision
data that are usually managed during ontology-design activ- role from a human agent, that role is proxied by the tool.
ities, and a unifying conceptual framework, which puts to- Being clear about which (and how) social-level methods or
gether the several interrelated aspects of (collaborative) on- tasks are substituted, and which methods, roles or tasks are
tology design. In this paper we present a formal framework proxied may improve the semantic interoperability between
that represents the notions needed to express requirements tools and social practices.
for the development of collaborative ontology engineering In the remainder of section 1, we introduce the basic or-
tools. The framework is formalized as an OWL(DL) ontol- ganization of the framework and the notions treated. A
ogy named C-ODO (Collaborative Ontology-Design Ontol- unifying framework for describing ontology design should
ogy), and is being used within the EU NeOn project. be general enough to express all the possible approaches to
this activity, and should also be practical enough to be im-
plemented without creating unnecessary complexity in local
1. INTRODUCTION solutions, models, and tools. Moreover, it should not con-
Collaborative ontology design cannot be specified unequiv- sist of a single particular methodology, but rather it should
ocally, e.g. as an OWL class, because the entities that provide expressivity enough to describe different methods
are typically referred to by the term ‘design’ can be mul- or aggregations of methods. We consider ontology design in
tifaceted. Usually, the talk about ontology design addresses terms of its objective, scope, components, and supporting
several aspects that are highly interrelated: how the ontol- functionalities.
ogy does look like; its conceptualization; which principles
have been used to build it; the process model that has been The objective of ontology design is to help solving the
used to create it; and so on. In the context of the EU NeOn problem of making choices from the (potentially infi-
integrated project, collaborative design of networked ontolo- nite) choice space offered by the used logical language
and available vocabulary. Formulating an objective
Copyright is held by the author/owner(s).
WWW2007, May 8–12, 2007, Banff, Canada. helps getting started with the design of an ontology.
. In analogy with the blank page effect experienced by
writers, there exists a blank model effect, which needs • Argumentation: a structure for discussing possible de-
to be dealt with in terms of the objective of the model. sign solutions, based on rationales and dialectic rules
The scope of (networked) ontology design is related to • Ontology design rationale: the motivations according
establishing what we want to describe the design of. to which an ontology is designed the way it is
In principle, we could describe the design of any kind
of data, process, or resource which is used or gener- • Functionality description: a description of a task to
ated during the lifecycle of ontologies over the seman- be accomplished by a design operation according to a
tic web: classes, individuals, annotations, email dis- method
cussions, handbooks, etc. Although our proposal is in
principle general and robust enough to support the de- • Design Pattern: a configuration of ontology elements
sign of all these kinds of data, the focus of this paper is that is relevant from the logical, architectural, or con-
on ontology design proper 1 . Please note that because ceptual viewpoint.
of the networked perspective we take here, design is
not to be intended as limited to creation time, i.e. to As mentioned above, a choice is also required on how to
an initial phase of an ontology lifecycle, but rather as represent these components. To this end, we distinguish
an aspect of the entire ontology lifecycle. between two levels of representation:
The components of ontology design are supposed to • Social level: a social view on an ontology development
characterize the objective and the scope of ontology project. At this level, components are characterized in
design. Such components need to be considered from terms of what happens in the real world when a person,
two perspectives. On the one hand, we should be able a group of people, or a community decide to build
to determine what entities should such components be. an ontology or an ontology network in a collaborative
On the other hand, we should be able to determine how fashion. The social level allows to describe the domain
to represent such entities. Listed below are the main of research through the components, and to provide
types of entities selected so far, which are depicted in platform developers with a requirement analysis.
figure 1:
• System level: a system view on an ontology devel-
opment project. At this level components are rep-
resented in terms of the methods and the techniques
that provide (possible) solutions for supporting what
is described at the social level. Such methods and
techniques are the base models for the design and im-
plementation of a platform.
Finally, we consider the functionalities that (are needed
to) support collaborative ontology design. The list of func-
tionalities from the NeOn project includes evaluation, selec-
tion, re-engineering, learning, upgrading database content,
mapping, collaborative workflow, argumentation, provenance,
data annotation, social network analysis, lexical domains,
ontology localization, and multilingual ontology integration.
Each of these functionalities is represented in two ways in
C-ODO. On the one hand, these are all ‘rich’ functionality
descriptions, in which roles, goals, parameters and complex
Figure 1: Ontology Design Components
tasks are put together to compose a ’method’: e.g., a method
to execute ontology selection, argumentation, or concept se-
lection by means of lexical domain filtering and linking to
• Ontology project: a project having the goal of influ- other ontologies. On the other hand, these functionalities
encing the lifecycle of a networked ontology are also (complex) tasks, defined in the related function-
ality descriptions, to be be performed within an ontology
• Collaborative workflow: a special case of epistemic project.
workflow, i.e. a relationship between rational agents The rest of the paper is organized as follows: section 2
that influences the knowledge of one or more agents provides a brief overview of the existing work on require-
in the relationship, according to a workflow shared by ments and tools for collaboration in cooperative knowledge
one, more or even all the agents. A collaborative epis- communities. Section 3 describes the foundations of our
temic workflow is characterized by the ultimate goal conceptual framework, which is the main contribution of
of designing networked ontologies and by specific rela- this paper and is encoded in the Collaborative Ontology-
tions among designers, ontology elements, and collab- Design Ontology (C-ODO). Section 4 presents C-ODO with
orative tasks the help of a simple example. In section 5, a further example
1
The design of e.g. a workflow or a project can be treated illustrates the way C-ODO can be used to model a collab-
similarly, but goes beyond the scope of this paper, which orative ontology-design methodology. Finally, in section 6
is to characterize the choices made about ontologies and some conclusions are drawn and lines for future work are
ontology elements. sketched.
2. RELATED WORK form of reification adopted in our framework makes it
A huge amount of work has been conducted on require- possible to talk in the same language of both a generic
ments and tools for collaboration in cooperative knowledge method and the elementary or complex entities that
communities. For an extended discussion of the state-of-art, allow to perform that method, since both the method
the reader can refer to [3]. For space reasons, here we only and its component entities are in the same domain of
cite some of the most relevant contributions. interpretation This allows, for instance, to design a set
Some works address social aspects to be considered when of operations like the composition of: {elicit knowledge
building tools [1], [15]. [1] clearly states the problems com- from a colleague or an expert, find and specialize de-
ing from the social-technical divide. [13] is a brief survey of sign patterns for that knowledge, validate the adapted
the main studies on principles that seem to underline suc- patterns against competence questions}. This makes
cessful cooperative communities. The DILIGENT method- the language more expressive without making it com-
ology provides several requirements for supporting collab- putationally more complex as usual with reification.
orative workflows [31], [26], and deals with argumentation The form of reification adopted in C-ODO is based on
[25]. In [18], further requirements for collaborative ontology the distinction between descriptions (e.g. a method)
development are identified. Available tools include: On- and the situations that satisfy a description (e.g. the
tology Builder and Ontology Server (OBOS) [6], Hypertext- configuration of operations that allow to perform that
Augmented Collaborative Modelling (HACM) [24], Claimspot- method). This architectural pattern is called DnS [10].
ter [22], ClaiMaker [15], which is based on [16], and Co-OPR Descriptions ‘use’ concepts, e.g. the role of ‘being an
[23], which presents the integration of two existing tools (i.e., expert during elicitation’, while situations are ‘setting
Compendium, and I-X). Furthermore, [14] is a source of in- for’ entities, e.g. an individual expert or an operation.
teresting points with respect to requirements and tool sup- Concepts are used to ‘classify’ entities within a situa-
port, while [21], and [4] analyze aspects of human-computer tion.
interaction (HCI). Finally, as far as coordination in collabo- For the purpose of intuition, the distinction between
rative environments is concerned, interesting suggestions are descriptions and situations can be understood as a
provided by the coordination models and workflow patterns generalization of the UPML (Unified Problem-solving
presented, resp., in [19] and [28]. Method Development Language) paradigm [17], in which
“classification can be seen as the problem of finding
3. THE COLLABORATIVE ONTOLOGY DE- the solution (class) which best explains a certain set
of known facts (observables) according to some crite-
SIGN ONTOLOGY (C-ODO) rion”. Descriptions (as ontological entities) are the
As pointed out in Section 1, the notions of collaboration counterpart of a set of criteria in UPML, while situa-
and ontology design are not univocal. Moreover, none of tions are the counterpart of a solution in UPML. Fur-
the existing treatments of these notions provides a suffi- thermore, situations are settings for a set of entities
ciently general definition for them. This makes it impos- and their relations, which satisfy the concepts devised
sible to adopt any of the existing proposals on either col- in the description. Therefore, related entities in the
laboration or ontology design as a basis for the definition setting of a situation may be considered the counter-
of a language to talk about collaborative ontology design. part of UPML observables.
In order to fill this gap in the literature, we introduce here
the Collaborative Ontology-Design Ontology (C-ODO). C-
Plans, tasks and goals Extensions of DnS have been used
ODO formally specifies the components of collaborative on-
to model several types of conceptualizations, such as:
tology design. It allows formal expression of either social or
social agents like organizations, communities of agents
computational requirements for tools that support ontology
[2], the information objects by which a description is
design. C-ODOs main components - as already informally
expressed [7], the time-spans characterizing the situa-
presented in Section 1 - capture the epistemological nature
tions, etc.
of designing knowledge in general and, in particular, of de-
An important extension to DnS is the Plan ontology
signing ontologies, i.e. reusable knowledge. C-ODO is based
[7], which models plans as descriptions that represent
on a relatively large number of assumptions and ontological
sequences of tasks that lead from a given situation to
commitments, which are briefly summarized in the following
a new, expected one. These descriptions are abstract
subsection.
and independent from computational system design:
3.1 Assumptions and reused ontologies in they are reusable and easy-to-customize representa-
C-ODO tions of the objects and activities involved in multiple
action domains. The main components of plans are:
C-ODO’s design has pivoted on three rationales: i) basing
task, goal and agent-driven role. Tasks and agent-
the whole framework on a reification mechanism, which is
driven roles are types of concepts, while goals are de-
founded on the distinction between descriptions and situa-
scriptions, proper parts of plans. Control constructs
tions; ii) breaking down the conceptualization modeled in
(e.g. choose between the following alternatives) from
the framework into six main layers (ontology project, col-
traditional planning and workflows are represented as
laborative workflow, argumentation, design rationale, func-
control tasks, also defined within plans. Tasks may be
tionality description, ontology design pattern); iii) reusing
connected to roles by a ‘target’ relation. Plans may
as many as possible existing ontologies as foundations for
also have situations as pre- or post-conditions. Plans
C-ODO.
as descriptions are different from plan executions: the
Reification through Descriptions and Situations We latter are situations. Goal situations are situations
have based C-ODO on a reification mechanism. The that satisfy a goal.
Other reused ontologies Other reused ontologies include 4. DESCRIBING ONTOLOGY DESIGN WITH
the Open Systems Ontology [7], which includes the C-ODO
object transformation pattern, involving roles for per-
formers, resources, working items, and products; the As an example, consider a team of designers that are col-
oQual ontology [9, 8], which models ontology evalu- laboratively designing an ontology from a flat list of ten
ation and selection as a diagnostic tasks over ontol- classes, including {Dog, Canine, ...}, and that are willing to
ogy elements, processes, and attributes; the Ontology apply the subsumption logical pattern to Dog. The implicit
Metadata Vocabulary (OMV) [12], which captures sev- choice space is made of ten choices (nine possible super-
eral notions conveying key-information on an ontol- classes, or being a top class). How to decide what class
ogy (ontology task, ontology engineering tool, loca- subsumes Dog? Reusing existing artifacts is a practice that
tion, party, ontology engineering methodology, ontol- advantages designers of any field (e.g., software, business,
ogy language, person, etc.); the notions of Network of etc.) in undertaking their tasks. The same applies to on-
Ontologies and Networked Ontology [12], i.e.: “a Net- tology designers that can reuse previously produced ontolo-
work of Ontologies is a collection of ontologies related gies, parts of them, or best practices in ontology represen-
together via a variety of different relationships such tation. In our example, the decision on subsumption should
as mapping, modularization, version, and dependency be based on an explicit rationale suitable to subsumption.
relationships. We call the elements of this collection For example, the most typical one is ‘extensional seman-
Networked Ontologies.” tics’. In practice, it consists in assuming that choosing e.g.
Canine subsumes Dog, depends on the fact that Dog’s in-
stances are all Canine’s instances. Of course, the very same
design solution can be motivated by a different rationale, for
3.2 Six layers of ontology-design representa- example, assuming dictionaries like WordNet (where Canine
tion is a hypernym of Dog) to be a good motivation for making
As shown in Fig. 1 we have distinguished six layers that subsumption relations. In other words, the design pattern
fraction the scope of design into ordered components, or (in the example, the subsumption logical pattern) represents
modules: ontology project, collaborative workflow, argu- the ‘quality’ of a certain solution, whose rationale is ‘exten-
mentation, design rationale, functionality description, and sional semantics’, which leads to the design solution Ca-
ontology design pattern. The six layers are a componential nine subsumes Dog, on the basis that all Dog’s instances are
structure, and do not imply a given direction in ontology de- also Canine’s instances. One aim of our work is to provide
sign, i.e. they do not tattempt to prescribe a methodology people involved in the design of ontologies with a way to
that starts from project planning and ends with practical represent the rationales that characterize their design deci-
implementation, or the other way around. The six-layering sions (e.g., design patterns chosen for a certain version of
is simply agnostic with respect to sequence of execution. an ontology), and how these rationales are discussed within
Each of these six layers are modeled in terms of the distinc- an argumentation session. We distinguish between solutions
tion between descriptions and situations. For instance, if we adopted and reasons behind such choices, and assume that
take ontology design pattern as a starting point, we have to design rationales represent reasons while design patterns are
distinguish between its descriptions and situations. Design- the solutions adopted. In C-ODO, the subsumption pat-
pattern descriptions, or schemas, include roles, tasks, and tern can be represented by instantiating the class design-
parameters for encoding part of an ontology in a certain pattern schema. Design-pattern schemas are special cases
logical language. The situational counterpart of ontology of ‘qoods’, i.e. quality-oriented ontology descriptions which
design patterns are design solutions, i.e. the states of part describe what is needed in an ontology and its use case(s)
of an ontology at some versioning point. to be appropriate to some criterion. An ontology design-
On their turn, design-pattern schemas and choices are mo- pattern schema is satisfied only by a situation that is the
tivated by a design rationale, and are applied by perform- setting for some ontology element and their axioms (e.g.,
ing some functionality. Design rationales and functionality stating the axiom Dog subClassOf Canine using the OWL
methods are descriptions, whose counterpart are actual de- language). The design-pattern schema formalization and its
sign making situations. situation counterpart are expressed by axioms 1, and 2.
Rationales and functionalities are made explicit during an
argumentation situation, the latter being the situational coun- DesignP atternSchema v oqual : qood u
terpart of an argumentation structure. Argumentation situ- ∀ edns : satisf iedBy(edns :: Situation u
ations typically occur during collaborative workflow enact- ∃ edns : settingF or OntologyElement) (1)
ments (situations) that follow some collaborative workflow
(description).
DesignSolution v edns : Situation u
Such workflows are part of an ontology project (description),
whose counterpart is an ontology project execution (situa- ∃ edns : satisf ies DesignP atternSchema u
tion). ∃ edns : settingF or F ormalExpression u
C-ODO ontology is an OWL(DL) ontology, way too large ∃ edns : settingF or OntologyElement (2)
(127 classes and 58 properties) to be completely presented
in a conference paper. From [5] C-ODO can be downloaded In general, design patterns [11] can be of several kinds:
for extensive browsing. Here we use a guiding example to macro of logical languages, in the sense of [30]; architec-
provide an intuition of what C-ODO is and how it can be tural design patterns, which are formal expressions for solv-
used. We also provide some sample formal definition for the ing structural issues (macros are simple examples of ar-
main C-ODO’s components. For a full textual presentation chitectural patterns); content design patterns, which are
of C-ODO, the reader can refer to [3]. typed (i.e., they refer to a non-logical vocabulary), and al-
low designers to solve domain specific issues; ontology anti- as quantitative measures e.g., the number of terms in the
patterns, which identify wrong solutions to recurrent design questions that match the vocabulary of the two ontologies,
issues. Design pattern schemas are used in order to guide or qualitative evaluations (see [9] for a comprehensive frame-
designers in using ontology design patterns. As a matter work on ontology evaluation types), etc. Both approaches
of fact, the choice can be motivated by different rationales, can be represented as functionality descriptions that define a
e.g. the axiom Canine subsumes Dog can be supported by method to accomplish the evaluation functionality. Axioms
a ‘lexical semantics’ rationale, which could take WordNet 5 and 6 formalize the notion of functionality.
hyponymy relation as evidence. Another rationale is the .
‘expertise semantics’ rationale, which could use a poll sys- F unctionalityDescription = edns : P lan u
tem against a sample of domain experts voting on the best ∃ edns : def ines F unctionality (5)
candidate as Dog’s superclass. Still another rationale is ‘best
approximation semantics’ to a repository of content design
patterns, so that the best candidate as a superclass may be f unctionality v plan : T ask u
chosen from an existing content pattern that includes Dog ∃ edns : def inedIn (F unctionalityDescription u
and Canine, with a best similarity match. One of C-ODO’s
main layers is design rationale, which contains the classes: i) ∀ accomplishedT hrough DesignOperation) (6)
ontology design rationale, and ii) design making. According
Going back to our simple example, let us now consider the
to [20], design rationales should include all the background
case when a team of designers actually agrees on how to
knowledge of a creation process, such as deliberating, rea-
apply the subsumption pattern between Dog and Canine.
soning, trade-off and decision-making in the design process
This agreement must be the result of a discussion between
of an artifact i.e., all the information that can be crucially
the designers from the team, based on argumentation ac-
valuable to various people who have to deal with the ar-
tivities. There are several ways of implementing an argu-
tifact. Design rationales are then explicit statements (or
mentation workflow. A scenario using argumentation the-
sets of statements) which represent the reasons why an ob-
ory for ontological support might follow the characteriza-
ject (product) has been (or is being) designed the way it
tion proposed e.g. in [29]. In the framework proposed by
is. When a rationale is applied to one or more ontology ele-
these authors, an argumentation session (which is a kind
ments, a configuration of possible design solutions emerges.
of collaborative workflow in C-ODO) is a compound of: i) a
Hence, an ontology design rationale can be seen both as a
confrontation, where the problem is presented (expression of
description of the motivations behind specific ontology de-
design-solution divergences); ii) an opening, where argumen-
sign solutions, and as the principle according to which those
tation rules are established, including the closing conditions
choices have been made available. Axioms 3 and 4 formalize
of the session (the decision of acceptable ontology design
the concepts of ontology design rationale and design making,
rationales coming from a community best principles); iii)
respectively.
the argumentation itself, where the dialectical rules (from a
OntologyDesignRationale v DesignRationale u given argumentation structure) are applied; iv) a conclusion,
∀ edns : satisf iedBy DesignM aking u where the closing conditions are met. C-ODO represents
these notions by introducing the following classes: i) argu-
∃ edns : usesConcept sys : P erf ormerRole u mentation structure (made up of dialectical rules: claiming,
∃ edns : usesConcept edns : AgentDrivenRole u agreeing, disagreeing, refusing, etc.); ii) argumentation situ-
∃ edns : usesConcept sys : KnowledgeRole u ation (any situation including designers arguing on ontology
design solutions); iii) argumentation role (any role played by
∃ edns : usesConcept F unctionality (3)
knowledge resources and ontology elements involved in the
argumentation, e.g. preferred choice, debated choice, re-
DesignM aking v edns : Situation u fused rationale, etc.); and iv) argumentation task (any task
∃ edns : satisf ies DesignRationale u to be accomplished within an argumentation situation). As
∃ edns : satisf ies F unctionalityDescription u an example, the generic framework in [29] is represented in
the class: argumentation session schema, which is a kind of
∃ edns : component DesignSolution u
collaborative workflow, and can be enacted as an argumen-
∃ edns : settingF or edns : RationalAgent u tation session within an argumentation situation. Argument
∃ edns : settingF or DesignOperation u sessions include four tasks corresponding to the components
∃ edns : settingF or inf : Inf ormationObject (4) of the framework: i) choice confrontation; ii) rationale decla-
ration; iii) dialectic rule (application); and iv) argument res-
Design makings are realized by means of the implementa- olution. Axioms 7 and 8 formalize the notions of argumen-
tion of some functionality. C-ODO defines the notion of tation structure and argumentation situation, respectively.
functionality as a description which can either be a generic Regardless to the method applied for achieving an agree-
description of a goal, or an actual plan describing a cog- ment on a design solution, and what rationales have been
nitive or computational method to achieve that goal. A provided to argument such choice, all the tasks described
functionality, however, is also a (complex) desired task to above are performed by means of some functionality in the
be performed (e.g., ontology evaluation). Such task is ac- context of some collaborative workflow, e.g. an ontology de-
complished through a design operation (i.e., an action in sign methodology. Consider an example in which the team
the context of a design making). Consider as an example we are talking about is organized as a set of peers, working
the task of evaluating the goodness of two given ontologies in a collaborative fashion with a non-hierarchical policy. All
against a set of competency questions. Such functionality decisions have to be taken together by means of a given set
can be performed by following different approaches, such of rules (e.g., the argumentation structure described above),
upon which peers must agree. Finally, the collaborative design of an ontology, say that
of canine kinds, is the goal of a dedicated ontology project
ArgumentationStructure v edns : Description u composed of a collaborative workflow supported by certain
∃ edns : component DesignRationale u functionalities that allows designers to argument their de-
∃ edns : usesConcept sys : P erf ormerRole u sign decisions by means of design rationales. The ontol-
ogy project can be executed one or more time according to
∃ edns : usesConcept ArgumentationRole (7)
its description. C-ODO represents the notion of ontology
project by defining the classes: ontology project, and on-
ArgumentationSituation v edns : Situation u tology project execution. Axioms 11 and 12 formalize this
∀ edns : satisf ies ArgumentationStructure u notions.
∃ edns : component DesignM aking u OntologyP roject v edns : P lan u
∃ edns : settingF or (∃ isArguedBy) (8) ∃ edns : component EpistemicW orkf low u
This behavior can be described as, and corresponds to, a ∃ edns : usesConcept P erf ormerRole u
kind of collaborative workflow. C-ODO does not prescribe ∃ edns : usesConcept KnowledgeP roductRole u
a specific methodology, since it aims to provide the prim-
∃ edns : usesConcept W orkingKnowledgeItemRole u
itives needed in order to express any methodology for col-
laborative ontology design, and the requirements for devel- ∃ edns : usesConcept KnowledgeResourceRole u
oping supporting tools. To this end, C-ODO defines the ∃ edns : usesConcept F unctionality (11)
classes: epistemic workflow and epistemic workflow enact-
ment. Bear in mind that a collaborative workflow and a col-
OntologyP rojectExecution v edns : Situation u
laboration situation are special cases of epistemic workflow
and epistemic workflow enactment, respectively. Any epis- ∃ edns : satisf ies OntologyP roject u
temic workflow includes at least one argumentation struc- ∃ edns : component EpistemicW orkf lowEnactment u
ture, and is conceived in order to achieving the goal of pro- ∃ edns : settingF or edns : RationalAgent u
ducing some knowledge (i.e., a knowledge production goal).
At least two rational agents (which can be also collectives ∃ edns : settingF or DesignOperation u
e.g., teams) have to participate as accountable perform- ∃ edns : settingF or KnowledgeCollective u
ers (i.e., being classified by an accountable performer role). ∃ edns : settingF or edns : Inf ormationObject (12)
Furthermore, at least two knowledge resources are involved
which are respectively, the knowledge resource which the According to this axiomatization and the definitions given
two agents start working on, and the artifact resulting from above, we define an ontology project as a plan that is com-
their collaboration. posed of some epistemic workflow and uses some working
Epistemic workflow enactment is the situation counter- knowledge object, functionality, performer role, knowledge
part of epistemic workflow. Axioms 9 and 10 formally define resource role, and knowledge product role. These concepts
them. are meant to convey the epistemic nature of an ontology
project, i.e. the idea that an ontology project enables the
EpistemicW orkf low v edns : P lan u production of knowledge from knowledge. Figure 2 summa-
∃ edns : component ArgumentationStructure u
∃ plan : hasM ainGoal KnowledgeP roductionGoal u
∃ edns : usesConcept AccountableP erf ormerRole u
∃ edns : usesConcept KnowledgeP roductRole u
∃ edns : usesConcept KnowledgeResourceRole u
∃ edns : usesConcept W orkingKnowledgeItemRole (9)
EpistemicW orkf lowEnactment v
edns : P lanExecution u
∃ edns : satisf ies EpistemicW orkf low u
∃ edns : component
edns : AgentCoP articipationSituation u
∃ edns : component ArgumentationSituation u Figure 2: Maximal functionalities in collaborative
ontology design
∃ edns : settingF or (edns : RationalAgent u
∃ edns : classif iedBy accountableP erf ormerRole) u
∃ edns : settingF or dol : T imeInterval u rizes the maximal functionalities (use cases) of collaborative
∃ edns : settingF or (edns : Inf ormationObject u ontology design, and how they relate to C-ODO layers.
∃ edns : classif iedBy {ontologyLif ecycleP roduct}) u
∃ plan : directSuccessor 5. AN EXAMPLE OF C-ODO-BASED MOD-
KnowledgeP roductionGoalSituation (10) ELING
In this section we show an example of C-ODO-based mod-
eling. We model the DILIGENT [27] argumentation method.
The model we show is represented by OWL-DL triples that
instantiate classes and relations of C-ODO, and it formalizes
the implicit ontology of the mentioned approach. However,
we do not intend to provide here a complete modeling of its
algebraic features.
The DILIGENT methodology is conceived for supporting
distributed teams of domain experts that are involved in the
process of creation and evolution of ontologies. DILIGENT
also contains primitives for performing argumentation ses-
sions. DILIGENT argumentation model has already been
defined in a simple OWL ontology. Here we model it in
terms of C-ODO. The DILIGENT argumentation model in-
cludes two actors, i.e. argumentation roles in C-ODO: par-
ticipant and moderator. It also includes some C-ODO ra-
tionales, called arguments, that can be expressed on either
issues or ideas. Arguments can be of two types: justifica-
tions, which in turn can be either evaluations or examples,
and challenges, which in turn can be either alternatives or Figure 3: C-ODO-based model of DILIGENT argu-
counter-examples. mentation (focus on tasks)
Figures 3 and 4 depict the DILIGENT argumentation
model in terms of C-ODO. The former focuses on argumen-
tation tasks, while the latter on ontology design rationale
aspects. Both tasks and rationales are modeled as instances ment analysis, and to the social-technical gap between social
of C-ODO classes, because C-ODO is based on DnS theory requirements and technical feasibility. In particular, none
(see section 3.1), which provides a unique domain of dis- of existing approaches attempts at providing a conceptual
corse for projects, methodologies, argumentation protocols, framework of the collaborative use of existing or forthcoming
design rationales, design patterns, and functionalities. technology. The gap is even sharper when collaborative de-
Figure 3 shows the definition of diligent-argumentation, sign is applied to ontologies. In order to fill that gap, we have
which is an instance of argumentation-session-schema (i.e., introduced C-ODO (Collaborative Ontology-Design Ontol-
a plan). In the context of diligent-argumentation, two ogy), the presentation of which is the main contribution of
performerRoles are used, which are participant and this paper. C-ODO is a framework that represents the no-
moderator. Furthermore, two complex argumentation-task tions needed to express requirements for the development
are defined: decision, which includes the voting task as of collaborative ontology engineering tools. The framework
a component, and position, composed of the agree and is formally described as an OWL(DL) ontology. Through
disagree tasks. Diligent-argumentation uses also the con- a simple example, we have shown C-ODO’s main compo-
cepts idea and issue, which are argumentationRoles played nents, their usage and relations, and some of the axioms
by either a design-solution or an information-object. which formalize the notions it contains. C-ODO can be fac-
Decision and position roles are targeted to solutions or torized into six main layers: ontology projects, collaborative
information. workflows, argumentation schemas, design rationales, func-
Figure 4 shows another view of the diligent-argumentation tionality descriptions, and design patterns. Each layer is
session. Here, the focus is on the design rationales that represented by assuming a distinction between descriptions
can be provided during a diligent-argumentation session. (or schemas), and situations, and then adding roles and en-
In DILIGENT terminology, Argument is synonym to the tity types that describe the world of ontology design. The
C-ODO concept of ontology-design-rationale, hence we context of C-ODO is the NeOn project, where a novel ap-
have defined Argument as a subclass of it. Arguments can be proach to ontology design is being defined, with reference to
of two kinds, justification and challenge: example and the networked and contextualized dimension of ontologies.
evaluation specialize (through the specializes relation) The future NeOn platform for ontology design will include
justification, while alternative and counter-example tools that allow a rich and highly customizable configura-
specialize challenge. An ontology-design-rationale is tion of components, on the basis of the specific needs of a
a component of some argumentation-structure. Notice designer, a team of designers, or distributed teams that work
that a diligent-argumentation can be composed only by together in an ontology project or in a part of it. In that
ontology-design-rationales of type Argument. In order generic perspective, ontology lifecycles can be much more
to express this constraint, an OWL hasValue restriction complex and open-ended than it is usually perceived, and a
is introduced on the component-of relation for the class precise modeling of requirements, at development time or at
Argument, where the value is diligent-argumentation. run time, will be a must. The early application of C-ODO
has been realized for the modeling of NeOn functionalities
6. CONCLUSIONS and requirements.
We have briefly discussed the state of art for collaborative
work within cooperative knowledge communities and have 7. ACKNOWLEDGEMENTS
shown that there is a lack of generality in this literature. We are grateful to the members of the NeOn consortium
This is due both to the lack of an adequate social require- who contributed to the NeOn vision being funded by the Eu-
Ontology ISTC CNR, 2005.
http://www.loa-cnr.it/Papers/D07 v21a.pdf.
[8] A. Gangemi, C. Catenacci, M. Ciaramita, and
J. Lehmann. Modelling Ontology Evaluation and
Validation. In Proceedings of the Third European
Semantic Web Conference. Springer, 2006.
[9] A. Gangemi, C. Catenacci, M. Ciaramita, and
J. Lehmann. Qood grid. A metaontology-based
framework for ontology evaluation and selection. In
Proceedings of the EON’2006 Workshop, 2006.
http://km.aifb.uni-karlsruhe.de/-
ws/eon2006/eon2006gangemietal.pdf.
[10] A. Gangemi and P. Mika. Understanding the semantic
web through descriptions and situations. In
CoopIS/DOA/ODBASE, pages 689–706, 2003.
[11] Aldo Gangemi. Ontology Design Patterns for
Semantic Web Content. In M. Musen et al. (eds.):
Proceedings of the Fourth International Semantic Web
Conference, Galway, Ireland, 2005. Springer.
[12] P. Haase, S. Rudolph, Y. Wang, and S. Brockmans.
Networked ontology model. Technical report,
Universität Karlsruhe, 2006.
[13] P. Kollock. . In Proceedings of the Harvard Conference
on Internet and Society, 1996.
Figure 4: C-ODO-based model of DILIGENT argu- [14] Y. Lu. Roadmap for tool support for collaborative
mentation (focus on ontology design rationale) ontology engineering. Master thesis, XiAn
Transportation University, Department of Computer
Science, 1994 (2003).
http://www.cs.uvic.ca/ chisel/thesis/YilingLu.pdf.
ropean Commission 6th IST Framework Programme. Fur- [15] C. Mancini and S.B. Shum. Modelling discourse in
ther information on NeOn is available on http://www.neon- contested domains: A semiotic and cognitive
project.org. framework. technical report kmi-06-14. Technical
report, Open University, 2006. Final version submitted
to International Journal of Human-Computer Studies.
8. REFERENCES [16] W.C. Mann and S.A. Thompson. Rhetorical structure
[1] M.S. Ackerman. . In John Carroll, editor, HCI in the theory: Toward a functional theory of text
New Millennium, 2001. organisation. Text, 8(3):243–281, 1988.
[2] E. Bottazzi, C. Catenacci, A. Gangemi, and [17] E. Motta and W. Lu. A library of components for
J. Lehmann. From collective intentionality to classification problem solving. Ibrow project
intentional collectives: an ontological perspective. ist-1999-19005: An intelligent brokering service for
Cognitive System Research - Special Issue on knowledge-component reuse on the world-wide web,
Cognition and Collective Intentionality, 7(2-3), 2006. deliverable 1, KMi, The Open University, UK, 2000.
[3] Carola Catenacci, Aldo Gangemi, Jos Lehmann, [18] N.F. Noy, A. Chugh, W. Liu, and M.A. Musen. A
Malvina Nissim, and Valentina Presutti. Design Framework for Ontology Evolution in Collaborative
rationales for collaborative development of networked Environments. In Proceedings of The Semantic Web -
ontologies state of the art and the collaborative ISWC 2006, volume 4273, pages 544–558.
ontology design ontology. Deliverable d2.1.1 of the Springer-LNCS, 2006.
neon project, NeOn project, 2006. [19] D.E. Perry and G.E. Kaiser. Models of software
[4] H.E. Chandler. The complexity of online groups: a development environments. IEEE Transactions On
case study of asynchronous collaboration. ACM Software Engineering, 17(3):283–295, 1991.
Journal of Computer Documentation, 25(1):17–24, [20] W.C. Regli, X. Hu, M. Atwood, and W. Sun. A survey
2001. of design rationale systems: Approaches,
[5] The collaborative ontology design ontology. representation, capture and retrieval. Engineering with
http://www.loa- Computers, 16:209–235, 2000.
cnr.it/ontologies/OD/OntologyDesign.owl. [21] T.J.M. Sanders, W.P.M. Spooren, and L.G.M.
[6] A. Das, W. Wand, and D.L. McGuinness. Industrial Noordman. Coherence relations in a cognitive theory
Strength Ontology Management. In Proceedings of the of discourse representation. Cognitive Linguistics,
International Semantic Web Working Symposium, 4(2):93–133, 1993.
2001. [22] B. Sereno, S.B. Shum, and E. Motta. Claimspotter:
[7] A. Gangemi, S. Borgo, C. Catenacci, and J. Lehmann. An Environment to support Sensemaking with
Task taxonomies for knowledge content. Deliverable Knowledge Triples. In Proceedings of the Intelligent
D07 of the Metokis Project, Laboratory for Applied User Interfaces Conference, IUI2005, San Diego, CA,
USA, 2004.
[23] S.B. Shum and et al. Co-opr: Design and evaluation
collaborative sensemaking and planning tools for
personnel recovery. Technical report kmi-06-07, Open
University, UK, 2006.
[24] S.B. Shum, E. Motta, and J. Domingue. Augmenting
Design Deliberation with Compendium: The Case of
Collaborative Ontology Design. In Proceedings of the
Workshop on Facilitating Hypertext Collaborative
Modelling in conjunction with ACM Hypertext
Conference, Maryland, 2002.
[25] Y. Sure, C. Tempich, D. Vrandecic, S. Pinto,
E. Paslaru Bontas, and M. Hefke. Sekt methodology:
Initial framework and evaluation of guidelines. Sekt
deliverable d7.1.2, Institut AIFB, Universitaet
Karlsruhe (TH), Germany, 2006.
http://www.sekt-project.org.
[26] C. Tempich. Ontology Engineering and Routing in
Distributed Knowledge Management Applications.
PhD thesis, University of Karlsruhe, 2006.
[27] C. Tempich, S. Pinto, Y. Sure, and S. Staab.
Argumentation Ontology for DIstributed,
Loosely-controlled and evolvIng Engineering processes
of oNTologies (DILIGENT). In Proc. of ESWC-2005 -
European Semantic Web Conference, Heraklion, Crete,
2005. Springer.
[28] W.M.P. van der Aalst, A.H.M. ter Hofstede,
B. Kiepuszewski, and A.P. Barros. Workflow patterns.
Distributed and Parallel Databases, 14:5–51, 2003.
[29] F.H. van Eemeren and R. Grootendorst. A Systematic
Theory of Argumentation: The Pragma-Dialectical
Approach. Cambridge University Press, Cambridge,
2003.
[30] D. Vrandecic. Explicit knowledge engineering patterns
with macros. In C. Welty and A. Gangemi, editors,
Proceedings of the Ontology Patterns for the Semantic
Web Workshop at the ISWC 2005, Galway, Ireland,
2005.
[31] D. Vrandecic and et al. Sekt methodology: Initial
lessons learned and tool design. Deliverable d7.2.1 of
the sekt project, Institut AIFB, Universitaet
Karlsruhe (TH), Germany, 2006.