Argumentation Technology Argumentation-Based Ontology Engineering Christoph Tempich and Rudi Studer, University of Karlsruhe Elena Simperl and Markus Luczak, Free University of Berlin H. Sofia Pinto, Technical University of Lisbon he Semantic Web envisions an infrastructure in which humans and machines seam- T lessly exchange information on the Web. For this to succeed, we need shared ontolo- gies that enable information exchange between different parties. Engineering a shared ontology in this kind of scenario is a social, evolving process, involving a geographically The DILIGENT dispersed community with different knowledge and The DILIGENT (distributed, loosely controlled, and argumentation expertise—ontology engineers, domain experts, and evolving engineering of ontologies) argumentation ontology users. framework consists of an argumentation process and framework helps Depending on the methodology used, the ontol- a formal model, and is supported technologically by ogy’s life cycle might consist of a series of stages, in a wiki-based support tool, coefficientMakna (col- capture design which the engineering team decides how to model a laborative, ontology-engineering-efficient Makna). domain to best suit the ontology users’needs and the Here, we sketch out DILIGENT’s theoretical back- deliberations in application requirements.1 Such engineering method- ground and an application scenario (typical to dis- ologies typically cover the major aspects of general tributed ontology engineering) we envisioned when ontology-engineering ontology engineering, describing related support specifying the framework’s functional requirements. methods, decisions to consider, and expected results. We also describe coefficientMakna’s design, archi- discussions. It makes However, these methodologies only marginally tecture, and implementation. We employed several address the collaborative interaction among commu- case studies to provide empirical data on the frame- consensus-building nity members who are creating an ontology. For work. We paid particular attention to lessons learned example, consider this two-phase methodology: first, from a study in which a team of eight individuals tasks more efficient a selected team of ontology developers creates an ini- with minimal experience in ontology engineering tial ontology; second, the development team contin- successfully developed a cooking ontology using and provides detailed uously extends and refines the ontology on the basis coefficientMakna. of feedback from a panel of domain experts.2 The guidance for interaction between the participants occurs indirectly, Application scenario and use cases with the core development team acting as a mediator We aim to use the DILIGENT argumentation frame- nonexperts. between the different parties suggesting changes to work in collaborative ontology engineering. The tool the ontological content. Most ontology-engineering primarily supports conceptualizing and formalizing environments also employ this indirect style. shared ontologies, complementing native ontology In contrast, our argumentation framework pro- editors that focus on implementation tasks. (We point vides detailed ontology-engineering guidance explic- readers elsewhere to learn more about the distinc- itly supporting direct interaction between ontology tion between conceptualization, formalization, and engineers and domain experts. This occurs through implementation in ontology engineering.1) arguments, which fosters consensus building and the In a distributed-ontology-engineering scenario, a creation of a truly shared ontology. geographically dispersed community incrementally 52 1541-1672/07/$25.00 © 2007 IEEE IEEE INTELLIGENT SYSTEMS Published by the IEEE Computer Society Authorized licensed use limited to: UNIVERSITY OF ALBERTA. Downloaded on October 1, 2009 at 14:32 from IEEE Xplore. Restrictions apply. develops an ontology—or multiple versions of it—reflecting the community members’ shared view with respect to the modeled domain (see figure 1). The participants, in- cluding domain experts and observers, don’t necessarily have an ontology-engineering background. Building on changes in the tar- get domain, evolving application require- Argue Argue ments, and discussions on whether and how Issues to model specific domain aspects, the engi- Ontology engineers #1 Optional: acquired users from neering team continuously revises and ex- s P nt o e cision s the target group De s it tends the ontology and releases new ver- m io u n Argue g s sions. To effectively participate, new parties r Persistent joining the community must understand the A ontology rationale behind modeling decisions and fol- versions low the ontology’s release history. E Argue Ontology engineering usually starts by ana- laborations lyzing the domain and application require- Board Argue Ideas ments. The developers agree on these require- Argues ments and their importance, and propose and discuss different ways to build a model Optional: that complies with them. They must discuss ontology engineers #2 Customer whether to model specific domain information as classes, instances, attributes, or properties, Figure 1. A collaborative ontology-engineering scenario. to decide on an adequate granularity level for the model and on conventions for labeling and documentation. Finally, they implement the stated that nutrition values were not available for argumentation support and formalization, conceptualization in a formal knowledge rep- for the ingredients, without providing an alter- which are unique to ontology engineering: resentation language such as the Semantic Web native to resolve the issue. ontology language OWL DL (Web Ontology The participants informally state a common • You can apply general argumentation Language Description Logic). They can revise goal for the ontology and introduce ideas for models across various disciplines, which the ontology according to user needs once new its resolution on a conceptual level. While cover many argument types. However, our domain knowledge is available. Later, differ- all agree on the common goal, a participant studies highly recommend (and even re- ent parties might maintain and use different disagrees with the proposed conceptualiza- quire) limiting the set of arguments to versions of the same ontology, while a shared tion. We developed methods that support improve such general models’usability for version has changes integrated into it. To facil- capturing such deliberations and help detect ontology engineering.6 itate the shared ontology’s systematic evolu- conflicts. • You can’t easily detect inconsistencies in tion and to operationalize consensus building, informal argumentation models’ discus- the developing team should discuss such issues Requirements sions because arguers don’t formalize in a controlled manner and trace the engineer- From an argumentation point of view, we their arguments. This might be a secon- ing process and results achieved to date. They can categorize ontology-engineering discus- dary consideration for general topic dis- should ensure a seamless development of the sions as deliberation dialogues in which the cussions such as requirements analysis, shared ontology, using instruments to resolve participants “collaborate to decide what ac- but it becomes crucial for knowledge for- conflicts that arise when several parties hold tion or course of action should be adopted in malization tasks. Ontologies are formal irreconcilable views. some situation.”3 The IBIS (Issues-Based models that must be semantically consis- We exemplify the scenario and its require- Information System) methodology provides tent to be of value to the applications ments using a discussion from a case study, an argumentation theory for deliberation dia- using them. Inconsistencies in discussions in which the participants built a cooking on- logues. Developers have used IBIS in soft- on how to ontologically represent domain tology. A short passage from the study illus- ware and requirements engineering to cap- knowledge lead to inconsistent models of trates the main issues in collaborative ontol- ture design deliberations.4,5 Researchers have lower usability. ogy engineering: developed formal models to allow for struc- • You can build ontologies in various ways, One of the participants stated the requirement tured queries on the collected arguments. with manual building and automatic learn- that the developed ontology should include Such approaches show that formal argu- ing as prominent examples. The latter helps guidelines for a low-fat diet. All members mentation models ease design-decision trace- produce large amounts of data but is less agreed with this requirement. As an idea to ability, help in conflict resolution, enhance suited for structuring this data into man- resolve this requirement, one participant stated reusability, and facilitate integrating new par- ageable pieces. Argumentation models can that this would require the inclusion of nutri- tion values into the ontology. At this point ticipants. Although these are general mod- help provide structure, offering an inte- another participant challenged this idea and els, they let us identify several requirements grated view on manually and automatically NOVEMBER/DECEMBER 2007 www.computer.org/intelligent 53 Authorized licensed use limited to: UNIVERSITY OF ALBERTA. Downloaded on October 1, 2009 at 14:32 from IEEE Xplore. Restrictions apply. Argumentation Technology created ontologies (or interrelated ontol- empirical findings,