A Software Modeling Approach to Ontology Design via Extensions to ODM and OWL

A Software Modeling Approach to Ontology Design via Extensions to ODM and OWL

Rishi Kanth Saripalle, Steven A. Demurjian, Alberto De la Rosa Algarín, Michael Blechner
Copyright: © 2013 |Pages: 36
DOI: 10.4018/jswis.2013040103
(Individual Articles)
No Current Special Offers


Ontologies are built to establish standard terminologies representing a semantic agreement between humans and knowledge systems via representational frameworks (e.g., KIF, DAML+OIL, OWL, etc.) that have been proposed in the research community, with limited adoption in industry. One possible reason is a lack of a formal model and associated process to more precisely and accurately design and develop ontologies. The authors’ prior work explored UML, entity-relationship diagrams, and XML as compared to RDF and OWL, identifying modeling capabilities lacking in ontologies. In all three approaches, design precedes instantiation which contrasts with ontology developers who build ontologies at the application level targeted to a specific domain. The paper proposes design-level modeling enhancements to ontologies by extending the OMG Ontology Definition Model (ODM) and OWL grammar with capabilities from the three aforementioned approaches, promoting a software engineering-based process. As a result, this work provides a more software engineering-oriented process to ontology design and development.
Article Preview

1. Introduction

Software domain modeling is a process where individuals seek to conceptualize an application in order to arrive at a solution that meets all of the application’s domain needs and requirements. Conceptualization can be defined as a structure {D, R}, where D is the domain (scope of the application) and R is the set of relevant relations (functionality and interactions of the application) in the D (Gruber, 2005). Currently, one popular domain conceptualization approach is ontologies where the representation of knowledge occurs via the definition of concepts that can be related to one another for sharing and reuse of that knowledge. In practice, W3C supports two major ontology development frameworks, the Resource Description Framework (RDF) (Powers, 2003) and the Web Ontology Language (OWL) (Allemang & Hendler, 2011), where the latter is built on top of the former. Additionally, a wide range of knowledge representational frameworks (e.g., KIF (Genesereth, 1991), KL-ONE (Brachman & Schmolze, 1985), DAML+OIL (Horrocks, 2002), etc.) are available. When reviewing the usage of these frameworks in real applications, the overriding theme is realizing a specific instance-level solution for a particular system, rather than designing a solution that can be reused by multiple similar applications within the same general domain. For example, in health information technology (HIT), multiple systems such as AllScripts (AllScripts, 2012), Centricity (GE Centricity, 2012), MS Health Vault (Microsoft Health Vault., 2013), etc., are developed with their own specific (and different) medical ontologies despite the fact that each one is storing and managing patient data. Any attempt to integrate data from across multiple EHRs, referred to as health information exchange (HIE) requires integrating their different medical ontologies which at best is a semi-automated and arduous task. While many of these HIT systems leverage existing standard medical terminologies (e.g., LONIC (LOINC, 2001), UMLS (Bodenreider, 2004), ICD (ICD, 2009), etc.), there is no uniform attempt to design an ontology domain model for medical knowledge that is general purpose and reusable in multiple contexts. For example, one HIT system may organize medical knowledge in an ontology by disease, symptoms (for each disease), diagnoses (for each disease), and treatments (for each disease), while another HIT system might invert and target this information from a symptom to diagnosis to disease to treatment basis. Attempting to reconcile this medical knowledge in two or more different ontologies is an arborous, time-consuming, and at best semi-automated task, making HIE difficult to achieve.

Complete Article List

Search this Journal:
Volume 19: 1 Issue (2023)
Volume 18: 4 Issues (2022): 2 Released, 2 Forthcoming
Volume 17: 4 Issues (2021)
Volume 16: 4 Issues (2020)
Volume 15: 4 Issues (2019)
Volume 14: 4 Issues (2018)
Volume 13: 4 Issues (2017)
Volume 12: 4 Issues (2016)
Volume 11: 4 Issues (2015)
Volume 10: 4 Issues (2014)
Volume 9: 4 Issues (2013)
Volume 8: 4 Issues (2012)
Volume 7: 4 Issues (2011)
Volume 6: 4 Issues (2010)
Volume 5: 4 Issues (2009)
Volume 4: 4 Issues (2008)
Volume 3: 4 Issues (2007)
Volume 2: 4 Issues (2006)
Volume 1: 4 Issues (2005)
View Complete Journal Contents Listing