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.