Semantic Design Patterns Using the OWL Domain Profile

Transcription

1 Semantic Design Patterns Using the Profile Rishi Kanth Saripalle, and Steven A Demurjian Department of Computer Science & Engineering, University of Connecticut, Storrs, CT, USA Abstract Design patterns in software engineering are templates garnered from generalizing proven solutions that can then be applied to other applications with similar needs; patterns allows developers to quickly structure their software based on a combination of its information and behavioral characteristics. However, the research, design, development, and usage of design patterns in ontologies is at a novice level. Patterns as applied to ontology design and development have the potential to promote reuse across various domain ontologies. Hence, the creation of reusable semantic design patterns and their inclusion into ontologies should enhance both the semantics and the reusability of ontologies. This paper proposes an approach to represent semantic design patterns using the Web Language Profile feature by integrating patterns into the domain ontology. Keywords - Knowledge Patterns, ODP, Metamodel 1 Introduction A design pattern in software engineering can be defined as a description or template as how to solve a reoccurring problem that can be used in many different situations. [1]. Essentially, design patterns are templates, but not furnished domain models, which can be used for capturing domain data or transformed into executable code. As a result, design patterns are an architectural concept (e.g., the structure and behavior of a system or component) which are realized in programming languages such as Java, C++, etc. The ability of patterns to facilitate modularity, flexibility, and ease of transformation across heterogeneous systems, have gained them wide acceptance in academic research and industry. Design patterns typically show relationships and interactions between classes or objects at a conceptual level, for domain independent structure and behavior. A pattern provides a body of knowledge on a particular structure thereby communicating insight on a portion or component of a solution; the idea is that we can leverage patterns that are generalized from prior solutions and experience to build solutions more effectively. While patterns are dominant in the software engineering community, they have also influenced other research areas like computational algorithm design and application execution behavior [12]; patterns have much to offer beyond their original usage if one generalizes them even more to apply to other research areas. Once such research area is knowledge representation, where there has been work that begins to apply patterns [2, 8, 9]. Knowledge representation primarily focuses on the development of ontologies which captures the semantic agreement a conceptualization of a domain. The question is whether the domain knowledge encapsulated by the ontology can be generalized (patterned) to be reused in multiple settings. For example, in the medical domain, each system (e.g., electronic medical record, prescription system, personal health record, etc.) may all have their own ontologies to manage diseases, symptoms, etc. The results are often incompatibility among ontologies for the same data that is not easily reusable. This is often due to an ontology designer not having a tool such design patterns to assist in structuring these larger and complex ontologies. Semantic design patterns which were previously overlooked while designing and developing ontologies has gained importance in the recent times, as they provide generalized structure, which explicitly modularizes conceptualization from domain concepts and rich axioms giving meaning to the structure [2]. For example, rather than encoding a theory about different electric circuits which can exist/co-exist in an electronic appliance, we can initially design directed graphs and later develop a procedure as how to impose or correlate the circuit to the graphs[2]. In a medical domain, we can leverage patterns to develop ontologies for diseases, symptoms, etc., that are more easily reused to facilitate sharing of medical information In both examples, patterns provide modular structures which are reusable; encourage knowledge modeling rather than encoding; and eases integration issues since rules built at the pattern level have to be followed by lower levels. Further, ontology can be viewed as collection of patterns which are connected with each other instead of behemoth logical structure. In this paper, we propose the development of semantic design patterns by identifying domain specific abstract concepts and leveraging the Profile (ODP) to develop a pattern. The paper is organized as follows: Section 2 provides background information on design patterns, and Profile, and a review of prior and ongoing efforts on utilizing patterns for ontologies; Section 3 proposes and demonstrates a technique of utilizing design patterns with ODP; and Section 4 concludes the paper and discusses ongoing work.

2 2 Background and Motivation Design patterns [1] captures the structure and semantics of a component level solution that has been generalized from well-proven solutions taken from different domains; as a result, such a pattern can be adopted to work in different applications that have the similar requirements of the pattern. The context, problem, and solution are the primary components of the pattern. Patterns provide reusable experienced solutions rather than reusable program logic. In general, a design pattern has the following essential elements: Name, Problem, Context, Forces, Solution, Examples, Resulting Context, Rationale, Related Patterns, and Known Uses [1]. Patterns have been classified into three broad categories: the Creational Pattern deal with object creation in multiple situations, e.g., Factory Pattern, Builder Pattern, Singleton Pattern, etc.; the Behavioral Pattern handles the communication mechanism between the objects, e.g., Interpreter Pattern, Mediator Pattern, and Observer Pattern; etc.; and, The Structural Pattern eases the design by identifying a simple way to realize relationships between entities, e.g., Adapter Pattern, Bridge Pattern, etc. Schmidt [3] has noted a number of benefits gained from incorporating design patterns into the development process, including: enabling widespread reuse of software architecture designs, improved communication within and across development teams, facilitated training of new programmers, and transcending ways of thinking imposed by individual programming languages. The Web Language ()[4] is a knowledge representation framework built on top of RDF[5] semantics and has three variants: Lite, DL, and Full. The DL (Description Language) variant is the most powerful and popular framework chosen for developing ontologies, maintaining a balance between expressiveness and reasoning complexity. As ontologies are designed for encapsulating domain conceptualization, the knowledge engineers are very much concerned in encapsulating all of the domain vocabulary for implementation purpose and exploiting reasoning algorithm Metamodel Reasoners Model instance extends imposed Profile Profile Parser Figure 1: Architecture of, Profile and Model. by using underlying description logic[6]. In our previous work[7, 13], modeling capabilities of ontologies were compared to standard modeling techniques such as the unified modeling language (UML), entity-relationship design (ERD), and the extensible markup language (XML)[7], with extensions were proposed to leverage modeling capabilities of when compared to standard software modeling paradigms. One of the proposed features was the Profile (ODP) module, which supports with metamodeling entities for capturing abstract domain specific concepts in a domain profile to act as metamodeling entities. The architecture of ODP in support with and the ontology is shown in the Figure 1, where the is extended to develop ODP which is later imposed on the domain ontology. The Profile parser (under development) authenticates and validates the imposing of the profile onto the model. The concept of domain profile is illustrated in Figure 2, owl:class M0: Metamodel M1: Model M2: Data extends ODP odp:profileclass Disease Class Diseases Data Asthma Figure 2: Layered representation of with ODP. where a domain model (M1 Level) provides the abstract view of the real world, while the metamodel (M0 Level) provides the abstract view of the domain model. For instance, in the domain of medicine (see Figure 2), the term Disease may represent all of the known diseases. The domain expert may further classify the concept Disease into various classes such as Diseases, Cardiac Diseases, Circulatory Diseases, etc., which may be further classified forming a classic is-a hierarchical relationship between the classes. Similarly, concepts such as Symptom, Treatments, Procedure, Surgery, Drugs, etc., can be built to form complex medical ontologies. After defining the class model (at M1 Level), viewing from the perspective of collecting real world data (M2 Level), the concept hierarchies and associations between them provide an excellent schema for describing the data. However, from the perspective of the metamodel (M1 Level), concepts such as Disease, Symptom, Treatment, Procedure, Drug, etc. are domain specific generic concepts which can be abstracted and moved to metamodel level. Once these domain specific generic concepts are captured and connected they form a semantic pattern which can be reused in multiple domain

3 model settings irrespective of the domain model. The ODP framework used for representing these patterns at the metamodel level has the following entities: odp:profileclass a metamodel entity used to represent a profile class, odp:attribute used to capture the characteristics of a profile class, odp:profiledatatypeproperty a metamodel entity used to capture interactions between the profile classes, and odp:profiledatatypeproperty represent datatype properties of a profile class. These entities are derived by extending primitive entities [7]. In Figure 2, Disease, Symptom, Treatment, Procedure and Drug are of type ProfileClass and their interactions will be of type ProfileObjectProperty. Once defined, the profile entities (Disease) are imposed [2] onto the domain model entity ( Disease - M1) which is read as Diseases isoftype Disease. Later, the domain model classes can be instantiated to collect instance data (M2) such as Asthma. Similarly, the profileclass Disease can be imposed onto multiple domain classes such as Cardiac Diseases, Diseases, Reproductive Diseases, etc., are all of type Disease. Finally, to complete this section, we focus on prior and ongoing work in the area of design patterns as applied to ontologies and knowledge representation. Gangemi[8] has proposed a Conceptual Design Pattern (CODeP) to capture generalized use case scenario acting as a template to solve domain modeling issues. The CODeP are Space-Region Space-Region Time-Interva,l etc., as classes and associations such as Spatial-Location, temporal-part-of, part-of, participant-in, etc., using the objectproperty. Our observation on this work is that the patterns developed by Gangemi(Figure 3) are captured as domain model (M1 in Figure 2), but not at the metamodel level (M0 in Figure 2). Staab[9] defined semantic patterns as a means of representing epistemological level concepts which can be instantiated by any target language. RDF is chosen for pattern development as RDF is basic building block for developing any other knowledge representational frameworks. A Consistency Translation is performed to assure semantics of the implemented language and pattern are the same. Clark [2] introduced the concept of knowledge Patterns which are defined as structure representing reoccurring pattern similar to software patterns, but morphing the knowledge pattern entities onto domain classes instead of instantiating them as show in Figure 4. In our approach to be presented in Section 3, a design pattern is defined as first-order logic which is later incorporated into the domain knowledge with definitive axioms. For example, a simple distribution design pattern as shown in Figure 4 where P is the producer, S is a switch mechanism, and C is the consumer. This pattern can be applied to any domain P S P C Switch Generator Light 1 Spatial-location 1 Spatial-location S C Switch Fan Object 1 temporal-part-of Object 1 * Figure 4: Distribution network pattern by Clark. participant-in Event Constant-participant-in temporal-location 1 * 1 * Time- Interval model, for instance, P can represent a battery, power plant, reactor etc., I can be a common switch and C can be any device which consumes power such as light, heater, computer etc. as shown in Figure 4. Event Part-of temporal-location Time- Interval developed by extracting key backbone knowledge on which the core ontology is built and is encoded in any knowledge representational format. For implementation, the author has defined a number of fundamental core patterns such as the participation pattern in Figure 3 which is extracted from the DOLCE ontology which illustrates participation relation between objects and events; the Role-Task pattern is also extracted from extended version of DOLCE explains the relationship between role, task, object and event. These patterns are implemented using the framework by defining concepts such as Space-Region, Event, Object, 1 * Figure 3: CODeP Participation Pattern. 3 Semantic Patterns using ODP In this section, we propose the inclusion of semantic design patterns using the ODP feature and exemplify its development through the Meta Vocabulary (OMV) [10] model. A Semantic Design Pattern captures reoccurring structure along with it associated semantics at the metamodel level allowing ontology designers to solve similar problems occurring in multiple settings. As discussed in Section 2, the ODP entities capture generic abstract domain concepts which can be class, attribute, or relationship. Our proposal in this section involves, interrelating profile classes (type odp:profileclass) profile objectproperty (odp:profiledatatypeproperty) which will result in a semantic pattern which can be imposed to develop an ontology schema. As the concepts are captured at metamodel

4 level (M0 in Figure 1) a single semantic design pattern can be leveraged to develop multiple domain models. In order to demonstrate the development of semantic design pattern using ODP, we utilize the OMV model. OMV is a domain model for capturing metadata about ontology; Figure 4 shows the core entities of OMV. As given in Figure 5, in a typical ontology engineering process, a Person(s) or Organization(s) is responsible for developing an ontology represented using entity. Task describes the primary task of the ontology and LicenceModel describes the usage boundaries of the ontology. The entities Syntax/Language capture the implementation details of the ontology schema. A further classification of the ontology relies on their level of formality (in ontology, it can be defined as the depth of knowledge captured and its purpose [14]) captured using FormalityLevel and details on ontology languages are representable with the help of the classes Syntax, Language and KnowledgeRepresentationParadigm. The domain the ontology describes is represented by the entity, while OnotologyType describes the nature of the content of the ontology. LicenseModel FormalityLevel Task specifiedby KnowledgeRepres entationparadigm 0:1 conformstokrparadigm 0:1 hasformalit ylevel useimports 0:1 haspriorversion isincompatiablewith 0:1 isbackwardcompatiablewith desginedf orontolog ytask URI version resourcelocator keywords creationdate modificationdate naturallanguage numberofclasses numberofproperties numberofindividuals numberofaxioms has usedontolog yengineerin gmethodolo gy Enginee ringmethodology Type 0:1 isoftype usedenginee ringtool 1:n hascreator hascontributor endrosedby Organization 1:1 has Language Enginee ringtool 0:1 has Syntax 0:1 isdefinedby Party hascontactperson land state city state Location Person firstname lastname phonenumber faxnumber Language Syntax islocatedat Figure 5: Overview of OMV Core concepts Since OMV is a generic model to capture metadata of the ontology irrespective of the domain, we can transform OMV model entities into ODP metamodeling entities which can be connected to form OMV semantic design patterns. The ontology designer can impose the metamodel entities according to his/her usage and the perspective. The first step is to convert the OMV model classes, attributes, and associations into respective ODP entities forming the basic building block of the pattern. In the first part of our proposal is to create and include semantic design patterns, the OMV classes (rectangles in Figure 4) are converted into ODP Profile class entities as shown in Table 1. In the Table 1, the left column represents the OMV classes and the right column represents equivalent ODP profile classes. For example, Party (second row in Table 1) is an OMV domain model class, while rdf:id=party is its ODP Profile class representation. Table 1: OMV Classes to ODP ProfileClass. OMV Model Class Party Task Engineering Methodology Syntax LicenseModel Location FormalityLevel EngineeringTool Language Organization Knowledge Representation Paradigm ODP Profile Class = Party /> /> = Task /> = EngineeringMethodology /> = Syntax /> = LicenseModel /> = Location /> = FormalityLevel /> = EngineeringTool /> = Language /> = Organization /> = KnowledgeRepresentationParadigm / > Second, the OMV attributes in Figure 4 are mapped to the ODP profile datatypeproperty, if the range of the attribute is a datatype (e.g., integer, double, URL, string, etc.) as shown in Table 2. The values on the left column in Table 2 represents attributes of OMV domain classes and the right column represents the respective ODP representation. For example, name (second row in Table 2) is an attribute of OMV class while its representation in ODP is of type ProfileDatatypeProperty (i.e., type of the attribute is String). Table 2: OMV Attributes to ProfileDatatypeProperty. OMV Attributes name acronym description documentation land ODP Profile DatatypeProperty <odp: ProfileDatatypeProperty rdf:id = name /> <odp: ProfileDatatypeProperty rdf:id = acronym /> rdf:id = description /> rdf:id = documentation /> rdf:id

5 state city firstname lastname phonenumber faxnumber URI version resourcelocator keywords creationdate modificationdate naturallangauge numberofclasses numberof Properties numberof Individuals numberofaxioms = land /> rdf:id = state /> rdf:id = city /> rdf:id = firstname /> rdf:id = lastname /> rdf:id = /> rdf:id = phonenumber /> rdf:id = faxnumber /> rdf:id = URI /> rdf:id = version /> rdf:id = resourcelocator /> rdf:id = keywords /> rdf:id = creationdate /> rdf:id = modificationdate /> rdf:id = naturallangauge /> rdf:id = numberofclasses /> rdf:id = numberofproperties /> rdf:id = numberofindividuals /> rdf:id = numberofaxioms /> Engineering Methodology usedengineeringtool has Syntax has Language hascontactperson islocatedat hascreator hascontributed endrosedby isoftype conformstokr paradigm hasformality Level useimports haspriorversion isincompatiablewith isbackward CompatiableWith desginedfor Task rdf:id = usedengineering Methodology /> rdf:id = usedengineering Tool /> rdf:id = hassynatx /> rdf:id = haslanguage /> rdf:id = hascontactperson /> rdf:id = islocatedat /> rdf:id = hascreator /> rdf:id = hascontributed /> rdf:id = endrosedby /> rdf:id = isoftype /> rdf:id = conformstokrparadigm /> rdf:id = hasformalitylevel /> rdf:id = useimports /> rdf:id = haspriorversion /> rdf:id = isincompatiablewith /> rdf:id = isbackwardcompatiable With /> rdf:id = desginedfortask /> has relatedtask createdby Third, the OMV associations (interactions between classes in Figure 4) are mapped to ODP ProfileObjectProperty as shown in Table 3. The left column represents associations in the OMV domain model while the right column represents the respective ODP conversions are of type ProfileObjectProperty. In Table 3, has is association between classes and (Figure 4) and rdf:id=has is its representation ODP. Table 3: OMV Associations to ODP ProfileObjectProperty. OMV Associations has used ODP ProfileObjectProperty rdf:id = has /> Task Person Party subclassof Organization Figure 6: A Part of OMV Semantic Design Pattern Once the OMV ODP entities have been defined, the next step in our proposed approach for semantic design patterns defines: ODP profile ObjectProperty entities which represent associations that can be used for interconnecting various ODP profile classes; and, ODP profile DatatypeProperty entities that can be associated as attributes to ODP profile classes. The ODP entities defined in Table 1-3 can be

6 Acute nasopharyngitis (common cold) Acute sinusitis Acute pharyngitis o Streptococcal pharyngitis o Acute pharyngitis due to other specified organisms o Acute pharyngitis, unspecified Acute tonsillitis Acute laryngitis and tracheitis o Acute laryngitis o Acute tracheitis o Acute laryngotracheitis Acute obstructive laryngitis (croup) and epiglottitis o Acute obstructive laryngitis (croup) o Acute epiglottitis Acute upper respiratory infections of multiple and unspecified sites Figure 7: ICD classification of Acute upper respiratory infections. interconnected to form a semantic design pattern. To illustrate, Figure 6 shows a portion of an OMV semantic design pattern and essentially denotes that an ontology (represented by the entity ) represents a domain (represented by the entity ), is developed to accomplish a task (represented by the entity Task), and is created by an company (represented by the entity Organization) or person (represented by the entity Person). M0 - MetaModel M1- Model M2 - Instance Data ODP OMV Semantic Pattern Diseases Acute Diseases <odp:profileclass rdfid= Organization /> <omv:organization rdfid= WHO /> <WHO rdf:id=" World Health Orgnization- ICD 10"> <odp:profileclass rdfid= Location /> <omv: Location rdfid= Switzerland /> < Switzerland rdf:id=" Geneva"> <owl:profileclass rdfid= /> <omv: rdfid = Diseases /> < Diseases rdfid = Acute Diseases /> Figure 8: Capturing domain related information of the sample ontology shown in Figure 7. Figure 9: Syntax for capturing ontology information. M0: Metamodel M1: Model M2: Data extends Disease Diseases ODP OMV Semantic Pattern Figure 10: Applying OMV semantic Pattern on multiple ontologies. The pattern entities,, Task, Party, Person and Organization are of type ProfileClass; association s has, relatedtask, createdby and subclassof are of type ProfileObjectProperty. In order to apply the semantic design pattern, consider the ontology in Figure 7, a snapshot taken from the ICD[11] taxonomy which classifies various Acute Upper Diseases. For capturing the domain related information for the sample ontology, the is instantiated as profileclass. This entity at the M0 Level is imposed to capture domain information ( Diseases type ) of the ontology model at the M1 level. Then, the ontology model entity Repository Diseases at M1 level can be instantiated to capture the instance data about the ontology (Acute Upper Diseases in Figure 8) at the M2 level. Other metadata on the ontology (Figure 9) such as organization, location etc. can be captured using the OMV semantic pattern design entities Organization, and Location respectively using the syntax given in Figure 9. As the semantic design pattern and its entities are defined at the metamodel level, they can be reused to describe multiple ontology models. Shown in Figure 10, the OMV semantic design pattern is defined using ODP module at the M0 Level. The same pattern is reused to capture information about multiple ontology models such as Disease, Symptom, and Medication at the M1 level. The ontology models at the M1 level are later instantiated to capture instance data such as Diseases, Symptoms etc. 4 Conclusion and Ongoing Work Symptom Symptoms Design patterns in software engineering are templates that represent the repetitive structure occurring problem solutions that are similar across multiple domains. In this paper, we have proposed the use of semantic design patterns to leverage these capabilities for ontology design and development. We believe we have demonstrated that these reusable structures and their semantics in the form of design patterns can provide a benefit that enhances both the

7 semantic and the reusability of ontologies. Overall, this paper proposed an approach to model semantic design patterns using the Web Language Profile feature that integrated the design pattern concept directly into the domain ontology. Towards this objective, in Section 2 we provided background and motivation on design patterns, an ODP extension, and research efforts that apply design patterns to ontologies and knowledge engineering. Using this as a basis, Section 3 proposed the semantic design patterns using the OMV model and demonstrated that capturing the pattern entities at the metamodel level reuses these components in multiple setting. Our ongoing work has utilized the UML metamodel process [7] to provide a more software engineering like process to ontology design, development, and deployment; the inclusion of semantic design patterns is an extension of this work to enhance the modeling process. For implementing the ODP, we are considering open source ontology editors such as Protégé, JOE, Hozo etc. which support /RDF frameworks. Visualization, Proc. Of 4th Conf. on Object-Oriented Technologies and Systems, [13] S. Demurjian, R. Saripalle and S. Berhe, An Integrated Framework for Health Information Exchange, Intl. Conf. on Software Engineering and Knowledge Engineering, August, [14] N. Guarino, Formal in Information Systems, Proc. of FOIS, Vol. 1, pp. 3-15, June References [1] E. Gamma, R. Helm, R. Johnson and J. Vlissides, Design Patterns: Elements of Reusable Object- Oriented Software, Addison-Wesley Professional, 1st ed., [2] P. Clark, J. Thompson, and B. Porter, Knowledge Patterns, Handbook of Ontologies, pp , Springer, [3] D. C. Schmidt, Experience Using Design Patterns to Develop Reusable Object-Oriented Communication Software, Special Issue on Object-Oriented Experiences, Vol.38, [4] L. Lacy, Owl: Representing Information Using the Web Language, Trafford Publishing, [5] S. Powers, Practical RDF, 1st ed., O'Reilly Media, [6] W. Kuhn, Modeling vs. Encoding for semantic web, Semantic Web Journal, Vol. 1, [7] R. Saripalle, S. Demurjian, and S. Berhe, Towards Software Design Process for Ontologies, Intl. Conf. on Software and Intelligent Information, October, [8] A. Gangemi, Patterns for Semantic Web Content, Proc. Of 4th Intl. Semantic Web Conf., pp , [9] S. Staab, M. Erdmann, and A. Maedche, Engineering Ontologies using Semantic Patterns, Proc. Of Intl. Joint Conf. on Artifical Intelligence, [10] J. Hartmann, R. Palma, Y. Sue, P. Hasse, and M. Suarez-Figueroa, OMV- Metadata Vocabulary, Proc. of Intl. workshop on Patterns for the Semantic Web, November, [11] International Classification of Diseases, [12] Wim De Pauw, David Lorenz, John Vlissides, and Mark Wegman, Execution Patterns in Object-Oriented