DCO: A Mid Level Generic Data Collection Ontology

Size: px
Start display at page:

Download "DCO: A Mid Level Generic Data Collection Ontology"

Transcription

1 DCO: A Mid Level Generic Data Collection Ontology by Joel Cummings A Thesis presented to The University of Guelph In partial fulfilment of requirements for the degree of Master of Science in Computer Science c Joel Cummings, November, 2017

2 ABSTRACT DCO: A Mid Level Generic Data Collection Ontology Joel Cummings University of Guelph, 2017 Advisor: Professor Deborah Stacey Ontologies have established themselves as the major framework for knowledge transfer and sharing. They allow consistent understanding of data to both computers and human modellers. This is done through a standard representation of a domains world view which captures the classes and relationships that exist in a particular domain. The interest in capturing a domains world view has led to the creation of many ontologies as ontological developers create ontologies to model their world views. An ontologies world view is a major contributor to reuse and interoperation. The significant number of ontologies produced has created a wealth a knowledge but particular application or domain specific views creates issue for others. The issue is communication and interoperation between ontologies. With so many different designs and terminology it is difficult to make use of existing terms and instances within these ontologies without creating some way to relate or translate terminology. This thesis tackles the problem of data collection among ontologies through answering the question: How does one model the domain of data collection using an ontology while maintaining a level of domain agnosticism such that the ontology can be reused for any domain? We propose that a mid level ontology design can be used to model the domain of data collection while remaining domain generic otherwise. Consequently, we present the Data Collection Ontology (DCO) and evaluate it to show that we enable reusability through

3 its high level class hierarchies that allow domain level terminology to be represented within the DCO. Direct contributions of this work include the Data Collection Ontology (DCO), the DCO Survey Ontology as well the philosophy of Classifiers as a way to introduce reasoning and dynamic ontology support.

4 Contents 1 Introduction Motivation General Motivations Motivations for a Generic Data Collection Ontology Terminology Research Question and Hypotheses Domain Overlap Term Specificity Ontology Coverage Thesis Statement Literature Review and Design Anaylsis Terminology Defined Classification Research Classifying Ontologies Upper Level Ontologies Problem Placement of Generic Data Collection iv

5 2.3.1 Mid Level Ontologies as Placement Conclusion Ontology Design BFO Discussion Design Intentions Classifiers Examined Competency Questions Defined Ontology Components Classes Relations Working Example Design Summary Evaluation Methodology Research Hypotheses Domain Overlap Term Specificity Ontology Coverage Experiment 1: The EPA Fuel Economy Ontology Classes Relations Experiment 2: A Case Study of the Survey Ontology The Survey Ontology Premise v

6 4.3.2 Integrated Survey Ontology DCO Survey Ontology Variant Evaluation using Traditional Techniques The FOCA Methodology Results Data Collection Ontology Evaluation Competency Question Evaluation FOCA Evaluation Comparing the Survey Ontologies FOCA Evaluation Table Notation Defined Evaluating Ontology Hypotheses Survey Ontology Evaluation Conclusions Conclusion Conclusions Contributions Future Work and Limitations A Diagrams 104 A.1 Fuel Economy Ontology Structure A.2 Survey Ontology Structure A.3 Integrated Survey Ontology Class Structure A.4 DCO Survey Ontology Class Structure vi

7 List of Tables 2.1 The evaluated upper level ontology implementations summarized The top level classes of the Basic Formal Ontology (BFO) that divide major elements DCO Competency Questions to define the uses expected for the DCO implementation DCO Object Relations Summarized Object Relations Continued DCO Data Properties Summarized Subjects defined in the EPA Fuel Economy Ontology. These subjects are based on the aspects that the EPA captures on the Vehicles tested EPA Ontology Relations. These relations are defined to match the terminology used by the EPA for the values captured Object Relations for the Vehicle Class DCO Survey Object Relation Locations within the DOC. Each relation is presented with the it s parent in the DCO DCO Survey Data Relation Locations within the DCO. Each relation is presented with the it s parent in the DCO vii

8 4.6 DCO Survey Relations added to DCO along with the DCO parent under which it is defined FOCA Goal 1 [14] defined along with a description used to evaluate each question FOCA Goal 2 [14] defined along with a description used to evaluate each question FOCA Goal 3 [14] defined along with a description used to evaluate each question FOCA Goal 4 [14] defined along with a description used to evaluate each question FOCA Goal 5 [14] defined along with a description used to evaluate each question Competency Question Justifications to assess the if the ontology implementation meets the requirements of each question Competency Question Justifications Continued Question Scores for the DCO Ontology DCO FOCA Goal 1 Justifications DCO FOCA Goal 2 Justifications DCO FOCA Goal 3 Justifications DCO FOCA Goal 4 Justifications DCO FOCA Goal 5 Justifications Goal 1 Questions and Justifications for Survey Ontologies Goal 2 Questions and Justifications for Survey Ontologies Goal 3 Questions and Justifications for Survey Ontologies viii

9 5.12 Goal 4 Questions and Justifications for Survey Ontologies Goal 5 Questions and Justifications for Survey Ontologies Survey Ontology Sizes Compared ix

10 List of Figures 2.1 The Ontology Hierarchy demonstrates how term specificity and structural design affects use case An example of how domain level ontologies can utilize one or more mid level ontologies to extend capability while reusing existing terms The BFO Hierarchy demonstrates the use of different ontological levels (as defined within the Ontology Hierarchy, see Figure 2.1) by BFO developers, making it suitable for mid level construction The Basic Formal Ontologies Class Structure in its OWL implementation. All terms under owl:thing are defined in BFO as an OWL Class An example of classifiers that demonstrates the use of equivalency relations defined on the Classifier classes to reason the type of instances. This type can then be compared to the has expected type on the relation to determine consistency DCO Process Types. State Driven Processes represent those that are blocking and require one process to finish before the next starts. The Independent Process structure allows for parallel tasks DCO Classifier Type. Classifiers utilize the has expected type relation to compare to the type assigned by the OWL reasoner through equivalency relations assigned to a classifier to check consistency x

11 3.5 A partial model of the Vehicle Performance Ontology showing how DCO datums are used and linked to Subjects to specify units on captured instances The top level class structure of the DCO within the BFO. Classifiers exist at the entity to level support reasoning with any type The branch of BFO Continuant decedents defined in the DCO. Continuants represent entities that remain the same throughout time The branch of BFO Occurrent decedents defined in the DCO. Occurrents represent entities that exist within a period of time The list of DCO relations and their structures broken down by type. Relations are used to link DCO classes and instances EPA Ontology Classifiers that are used to group vehicles based on their combined passenger and cargo capacity Vehicle Ontology Structure. This defines the structure of the ontology using DCO Subjects, Measurement Units, and Datums to represent the domain specific EPA Fuel Economy content A Survey Question with Example Answer Formats demonstrating how answer formats can be linked to questions along with responses The total quality estimator of FOCA The total quality estimator of FOCA The FOCA Methodology Steps [14] for evaluating an ontology A.1 Fuel Economy Ontology Base A.2 Fuel Economy Ontology Continuant Tree Structure from BFO A.3 The Fuel Economy Ontology s class Structure starting with the Occurrent Class xi

12 A.4 Fuel Economy Ontology Data Relations A.5 Recreated Survey Ontology Object Relations A.6 The original Survey Ontology Class Structure A.7 The original Survey Ontology Data Relations A.8 The original Survey Ontology Data Relations A.9 Integrated Survey Ontology Base A.10 The Integrated Survey Ontology Class structure starting from the Classifier Class A.11 Integrated Survey Ontology Continuant A.12 Integrated Survey Ontology Occurrent A.13 Integrated Survey Ontology Data Relations A.14 Integrated Survey Ontology Object Relations A.15 DCO Survey Ontology Base A.16 DCO Survey Ontology Classifier Class Structure A.17 DCO Survey Ontology Continuant Class Structure A.18 DCO Survey Ontology Occurrent Class Structure A.19 Recreated Survey Ontology Data Relations A.20 Recreated Survey Ontology Object Relations xii

13 Chapter 1 Introduction Ontologies have established themselves as the major framework for knowledge transfer and sharing. They allow consistent understanding of data to both computers and human modellers. This is done through a standard representation of a domain s world view which captures the terms and relationships that exist in a particular domain. The interest in capturing a domains world view has led to the creation of many ontologies as researchers and industrial workers create ontologies to model their world views. An ontology s world view is what can enable reuse and interoperation, that is the ability for an ontology be integrated with existing systems [45]. One of the major issues with ontological design is the balance of specificity along with the balance of domain related terminology that makes it suitable for particular use cases [45]. Studies have shown that reuse is a major issue across domains with only a small number reusing terms and even fewer reusing ontologies in their entirety [42, 45]. This issue largely centers around hierarchies and generic terms which allow other developers to adapt them to their use case [45, 42]. Many domain level ontologies focus on defining terms that fit their use case or problem but that often doesn t fit other domains or problem areas within that domain [45, 23]. As a result of issues with reuse and the ability to adapt terms there exists many ontologies within the same domain that fail to make any impact in terms of reuse 1

14 to others in the same field [37, 45, 42]. This results in a lot of redefinitions and reduced productivity where developers could leverage the work of others in their own solutions. Solutions for reuse have been researched with generic terminology in the form of upper level ontologies [36, 35] that provide terms common to all ontologies and create a structure that allows ontology developers to organize their terms. However, upper level ontologies still leave a large gap between their high level definitions and the terms that exist in application or domain specific ontologies. The result has been upper level designs that enable reuse and provide structures to those building ontologies in any domain. The issue with utilizing upper level ontologies is that it puts the onus of placing the terms within that structure on users that may only be familiar with their particular domain or use case [45]. To developers not aware of the issue of reuse the additional effort required to develop using a generic base may lead to developing from scratch [45]. This prevents wider use of upper level ontologies by developers and in turn reduces the likelihood of reuse of the resultant ontology by future developers. This thesis tackles the problem of developing a bridge to reduce the gap between high level terms and domain specific terms for ontologies that capture data. We define a data collection ontology as an ontology that focuses on the processes and instances that occur as a result of data collection. To maintain reusability, a data collection ontology defines a world view which is based on data collection and will not include the terms of any particular domain. This will allow developers to extend its design to place their domain specific terms within a common hierarchy that can be shared among all data collection ontologies. 1.1 Motivation Ontologies being central to the semantic web must also play a role in sharing or transferring information across domains and between ontologies. The ability for ontologies to be constructed using the same core for defining and capturing data would allow for much easier interoperation; interoperation being the transfer or sharing of data between systems 2

15 and/or ontologies. We can separate these motivations into a few general motivations that span ontologies as a whole and then specific motivations for what a data collection ontology should provide to domain level developers General Motivations Potential for Reuse Reuse is the overarching goal for ontologies [36, 37]. It is a key concept of several evaluation methods [14, 47] that suggest more general terminology be provided allowing for a greater number ontologies to utilize the same terms. The potential for reuse allows researchers to make use of existing work and designs while tailoring their solutions to meet specific requirements. A domain agnostic data collection ontology more easily allows reuse through a structure that is recognizable across designs that extend it. Potential for Reasoning We are cognizant that ontologies are designed to be reasoned with [16]. The ability to reason enables a more powerful ontology that can answer a greater number of questions while representing more complex data [16]. Reasoning support in terms of data collection can enable the ability for the ontology to determine where instances fit into the overall world view by dynamically assigning type. Assigning type through a reasoner avoids the need for external systems to perform the task outside of the ontology definitions. Additionally reasoning can reduce the need for external systems to perform data validation through the use of range restrictions on instances [24, 16] Motivations for a Generic Data Collection Ontology System Interoperation Ontologies that capture data should support integration with existing or future systems to allow data transfer and for querying of terms and instances. As an example 3

16 the ontology could be used as a backend for a data collection application that stores its data into the ontology and/or can query the ontology about validity or the process used for data collection. Data Collection Domain Ontologies that capture data tend to do so as a secondary purpose to modelling the domain they operate in [45]. This means they are not focused on the process itself and may miss important data collection components. By creating an ontology for generic data collection a focus is placed on the collection itself, providing the basic components and organization for domain ontologies that require data collection. 1.2 Terminology We will briefly define some key terms here to assist the reader with the research questions and hypotheses. More extensive definitions are defined in Chapter 2.1. A URI or a Uniform Resource Identifier is a string, generally in the form of a URL [25] that in terms of an ontology defines the method of identifying classes, relations, datatypes, annotations, and instances. These URI s allow for elements to be linked via relations as well as shared among other ontologies. Namespace Through the use of URIs, namespaces can be defined by taking the base form of a URI. For example, in the URI would be the base form of the URI. Using the base form ontology can define overloaded terms so that two ontologies may define Person but have a different definition. Relations allow ontology elements to be linked providing a human understandable way to describe classes. Classes are used to define high level terms or elements that define the domain the ontology seeks to model, another common term is to call them Concepts. Classes should represent a general description. 4

17 Instances are concrete examples of one or more classes. Instances must have all relations defined at the class level to be a considered an instance of that class. Datatypes are a way of assigning type to the value that is captured within an instance. Annotations are the method used for documenting ontology components, they allow for textual descriptions for designers, users, and maintainers of an ontology to understand the purpose and use of each component. OWL/RDF is an example of a language that an ontology can be expressed in [24]. XML is the typical format that is used to define OWL/RDF, which is a language that defines standard relations, classes, and the triple format of subject, predicate, object (i.e. class, relation, (instance/data)). All OWL class definitions are a derivation of owl:thing meaning owl:thing is the base level class. OWL/RDF is a standard language and is the language used by DCO and its derivatives. Foundational or upper level ontologies can be defined as: an ontology that seeks to provide definitions and terms that are general to all domains. [35] [19]. A mid level ontology seeks to provide a bridge between an upper ontology and a domain level ontology by providing terms that will be common to several domain level ontologies or areas of a domain level ontology [22]. Domain level ontologies are ontologies that seek to capture a shared conceptualization of a particular domain. These ontologies contain domain specific terms and may only be linked to a specific application [43]. 1.3 Research Question and Hypotheses The main research question of this thesis is: How does one model the domain of data collection using an ontology while maintaining a level of domain agnosticism such that the ontology can be reused for any domain or stated another way Is it possible for one to construct an ontology that models the data collection domain such that it can be reused in 5

18 other domains. Based on our research questions we develop hypotheses for ontologies that are created using the proposed solution. Specific terminology is fully defined in Section 2.1. Each of our hypotheses has a null hypothesis in the case our hypothesis is not satisfied Domain Overlap Hypothesis (H 1 ): There exists overlap with domain specific data collection terms and data collection terms within the DCO. Null Hypothesis: There is no overlap between domain specific data collection terms and the terms in the DCO Term Specificity Hypothesis (H 2 ): If and where overlap exists the DCO includes higher level terms than that of the domain specific data collection ontology (i.e. terms introduced are subclassing the DCO terms). Null Hypothesis: The overlapping terms are less generic or at the same level as in the DCO (i.e. terms introduced are parents to the DCO terms) Ontology Coverage Hypothesis (H 3 ): There are no terms defined outside of the DCO hierarchy (i.e. there are no terms defined at the owl:thing level). Null Hypothesis: There are terms that are outside of the DCO hierarchy (i.e there are terms defined at the owl:thing level). 6

19 1.4 Thesis Statement Based on our research question we define a thesis statement that is: A mid level ontology design can be used to model the domain of data collection in a domain agnostic manner. This is based on the notion that mid level designs are to be extended by design and that through using an existing upper level design we enable developers with a familiar starting point. This statement will be proven or disproven (i) by outlining our design, (ii) by establishing an evaluation methodology, and (iii) through experimentation, and evaluating our hypotheses. 7

20 Chapter 2 Literature Review and Design Anaylsis Capturing data is a common ontological purpose where ontologies, terms, descriptions, and relations capture the universal aspects of a particular dataset and the instances serve as specific examples of those universals. The result is an ontology that categorizes instances through its understanding of universals. However, with ontologies focused on capturing a specific domain they define terms only applicable to their domain, ignoring hierarchies and higher level terms that are reusable amongst other domains. This is true for the data collection aspects as well [45]. The commonality of such designs in relation to our problem directed research toward generic designs. In creating a generic design domain ontologies are able to reuse existing work in the design of their ontology with the lower level components being the domain terms. These lower level terms will describe data collection in language that coincides with that particular domain while reusing higher level terms to provide an overall hierarchy. Based on this definition we can reword our problem to be the construction of a generic data collection ontology that defines terms and hierarchies at a high level to enable reuse among other ontologies that collect data. This definition will help direct the rest of the information in this chapter to examine existing work in the field. 8

21 Our definition of ontology further alludes to a preference towards generic design. Ontology is defined as a shared conceptualization that should seek to define terms in their most formal regard and should not use terms that are specific to particular areas wherever possible [31]. In other words, ontology developers should strive to produce solutions that enable reuse among other ontologies. To do this, high level terms and sub-classing to create hierarchies is preferred over single more specific terms [17] [31]. Therefore, our definition of ontology and the goal of a data collection ontology are the components that guided research into existing designs. Research in the area of a generic ontology for data collection cannot be found in published work at the time of this writing. For this reason the problem has been broken down into subproblems that are general to ontology construction. The first issue is that of reuse; if we think of the problem in a global context, reuse is one of the most significant problems involved in developing a solution. This is evident since our solution is based around other ontologies reusing the terms and relations in the data collection ontology. Additionally, from a second perspective, we may be interested in reusing other ontology components. The second major area is how ontologies are defined in terms of a hierarchy, and what characteristics define that category. Categorization is important because it will determine the ontological research area our problem fits in. It is expected that users will be able to reuse or extend the solution s components in some aspect. In terms of definition we consider the categories to be based on the generality of the ontology s world view. In this chapter we open by defining important terms for ontologies for those not familiar with the field as well as defining terms that may be known but have overloaded definitions. We then move on to discuss different types of ontologies and the level of concern they have for reuse to determine if and where existing designs or ontologies can be reused by a generic data collection ontology. We then focus on ontology categorization in the context of where our problem is best tackled keeping in mind our definition of ontology and our high level view of data collection. Finally, we summarize by drawing conclusions on existing designs and what needs to be done in terms of defining generic and reusable ontologies. 9

22 2.1 Terminology Defined In this section we will define major terminology we will use in this chapter as well as future chapters so readers have an understanding of ontology terms as well as how we will refer to overloaded terms. A URI or a Uniform Resource Identifier is a string, generally in the form of a URL [25] that in terms of an ontology defines the method of identifying classes, relations, datatypes, annotations, and instances. These URI s then allow for elements to be linked via relations as well as shared among other ontologies. Finally, URIs can also be used external to ontologies to identify other resources such as a class in a programming language that can then be linked into an ontology using its URI. Namespace Through the use of URIs, namespaces can be defined by taking the base form of a URI. For example, in the URI would be the base form of the URI. Using the base form ontology can define overloaded terms so that two ontologies may define Person but have a different definition. This provides the ability to include an alternate definition from another ontology. An example would be dco:person and schema:person, where dco and schema define specific URIs that end with the term after the colon. Relations in terms of an ontology will be described as either an Object relation or a Data relation. Relations allow ontology elements to be linked providing a human understandable way to describe classes. Additionally, relations are used to impose restrictions and requirements for classes that allow the reasoner to determine consistency. In terms of language, relations tend to be in the form of a verb (i.e. has part, branches to) where classes are nouns. An example usage of a relation would be Vehicle has part Engine. An Object relation is used to link instances to classes or instances to instances. Data relations link data elements such as strings, numbers, and boolean values to instances. An example of an object relation was seen in the Vehicle example above while an example of a data relation would be Engine displaces 5.7, where 5.7 is the float value that is captured. All relations 10

23 will be italicized in this document for easy reference. Classes are used to define high level terms or elements that define the domain the ontology seeks to model; another common term is to call them Concepts. Classes should represent a general description. Classes should not contain any data that is specific to an example of that term or object. As an example we would not include that a Person has blue eyes since that is not representative of all people. Additionally, classes typically have relations between them to link data or instances and this allows the term or object to be placed within the world the ontology is modelling (i.e what it is related to), and the other classes that are a part of or contain that class. Classes are typically expressed as nouns such as Vehicle, Person, Word, etc. Instances are concrete examples of one or more class. Instances must have all relations defined at the class level to be a considered a instance of that class. Establishing class type is reasoned though the use of restrictions. For example, we may define a class of Person which defines the attributes common to all persons (such as having eyes) whereas an instance would define a person with green eyes which is not something common to all Persons. Datatypes are a way of assigning type to the value that is contained within a string. The reason for this is that ontologies are stored in text form and all data relations are captured as strings with datatypes that are appended to the end. Datatype definitions allow types such as float, int, string, date, etc. to be interpreted though a program. An example of a datatype would be 12 :ˆˆ xsd:int, where the xsd:int tells an application that the string preceding it is to be interpreted as an integer type. RDF, OWL, and XSD are XML schemas that allow users to import and use default types commonly used across ontologies and understood by applications such as Protege [46]. These default types allow for interoperation between ontologies and other software programs that can interpret the types and constraints imposed by these schemas. Annotations are the method used for documenting ontology components. Annotations allow for textual descriptions of ontology components for the consumption of designers, 11

24 users, and maintainers of an ontology to understand the purpose and use of each component and why a component exists. Annotations are in the form of a relation type which links a string of some format. OWL/RDF is an example of a language that an ontology can be expressed in [24]. XML is the typical format that is used to define OWL/RDF, which is a language that defines standard relations, classes, and the triple format of subject, predicate, object (i.e. class, relation, (instance/data)). RDF defines base relations and data types while OWL imposes base classes and relations that enable reasoning capability. For example, all OWL class definitions are a derivation of owl:thing meaning owl:thing is the base level class. OWL/RDF is a standard language and is the language used by DCO and its derivatives. Competency Questions are commonly used [15, 26, 29] to define the scope and goals an ontology sets out to accomplish. Competency questions can change over time as ontology purpose is realized and iterated upon. Competency questions do not define a single ontology but rather impose constraints on what the ontology can be; however, anyone could develop their own ontology against a set of competency questions. Competency questions allow both users and developers to establish an ontology s functionality and ideals about how to accomplish a particular task. Competency questions are typically written in an informal fashion but they must be able to represented or answered using the ontology s axioms and definitions [26]. An example competency question comes from a project that seeks to design an ontology that models the Brazilian Family Health Program [28] that is: What is the epidemiological profile of patients in a given region, i.e. age range, gender and ICD (International Classification of Diseases)? [28]. This question seeks to establish that the ontology can answer a high level question that is pertinent to the domain it models. In this case since we are tracking people s health, the ontology must contain information regarding its patients which the competency question above seeks to establish. 12

25 2.2 Classification Research Ontological research has become widespread in the design of information systems. Recently the desire for ontologies to span and integrate different views of a domain and even across domains has come to fruition [36]. The development of these ontologies provides the opportunity for systems to integrate and become interoperable allowing for information sharing [32] [36]. In this case an ontology acts as a bridge between systems unifying information [32] and allowing systems to communicate through the ontology using their standard language and message passing techniques. Unifying data allows the key components of one or more domains to be captured and shared among ontologies that further define a particular domain. The ability for an ontology to capture a particular domain is related to its viewpoint of the world. Each ontology imposes a particular view that defines its ability to share information; this viewpoint is therefore what we are concerned with. Furthermore, each ontology exhibits its own degree of formality through how it views the world and its domain [32]. These views can allow us to classify ontologies by the generality of their view. This world view becomes important when we look at defining an ontology as generic where we would say its definition allows it to span across a wide variety of domains and thus integrate systems with different domains and views of the world. Ontologies can be broadly classified based on their formalism and world view allowing us to narrow down suitable designs for our purposes Classifying Ontologies In this section we seek the broad classifications that are given to ontologies based on their perspective of defining the world. These categories may be further broken down but for our purposes of searching for generality at a high level it will be suitable. Domain level ontologies are ontologies that seek to capture a shared conceptualization of a particular domain. These ontologies contain domain specific terms and may only be linked to a specific application [43]. Domain ontologies are important in that they describe 13

26 the type of data to capture but they assume a particular domain to capture data from. A domain level ontology, however, could represent the end product for a system reusing an ontology. A local or application ontology is a specialization of the domain ontology and represents data from the viewpoint of one user or developer [43]. This differs from a domain ontology that seeks to capture the shared view of a particular domain that may vary depending on particular users [43]. An application ontology can therefore have very specific term definitions within the ontology; in other words, the ontology s correctness is based upon application features or requirements. That requirement differs from a domain ontology where the correctness is based on whether it captures all views and ideas within a particular domain. Again, an application ontology may be the result of using a generic data collection ontology in a larger system but does not provide reusable terms for the base of an ontology. A core ontology is linked to a particular domain but has the advantage of providing several viewpoints relating to different user groups [43]. Core ontologies are often the result of several domain level ontologies mapped together [43]. Core level ontologies represent a higher level of term generality as they seek to span and provide definitions for a wider domain or domains. From the problem perspective core level ontologies are certainly closer but still maintain the requirement of domain specific content within them thus, they cannot generically be applied to any domain. Foundational or upper level ontologies can be defined as: a foundational ontology seeks to provide definitions and terms that are general to all domains. [35] [19]. The first point is that they serve as a building block for future ontologies by enabling reuse since they define common terms that will be contained by domain level ontologies [40]. The goal of an upper level ontology is to avoid the redefinition of common terms to allow for easier and consistent reuse of defined terms. In other words, they provide a single agreed upon definition of terms [36] [43]. More importantly however is the fact that they are designed to support all domains which differs from core or domain ontologies that only define terms 14

27 for their particular domain, likely choosing specific (overloaded) definitions over general definitions [43]. Upper level ontologies are also commonly used for other tasks including merging domain level ontologies [36] where their global terminology can be used to match differing terms between source ontologies. By doing so it allows the translation and merging of two or more domain ontologies to create a core ontology, or to link separate but related domains [36]. This is common to work in systems that are built to interoperate with others and is one of the key usages for upper level ontologies [36]. A mid level ontology seeks to provide a bridge between an upper ontology and a domain level ontology by providing terms that will be common to several domain level ontologies or areas of a domain level ontology [22]. Mid level ontologies serve a similar purpose to the upper level ontology by preventing term redefinition and providing consistent relationships but at a more specific level. This has several advantages in addition to avoiding redefinition. Firstly, it provides a common understanding between derived ontologies through similar terms, structures and relations. Secondly, it provides a more streamlined starting place for those new to the construction of ontologies by providing terms more closely related to their domain than that of upper level ontologies. In terms of an ontology category hierarchy the mid level ontology falls in the middle with domain level ontologies extending mid level ontologies and mid level ontologies extending upper level ontologies. To summarize the classifications we can order the view point of ontology classification as in Figure 2.1 which allows one to see that upper level ontologies are a general source of reuse for all ontologies. They contain terms at such a high level that every ontology could start by subclassing those terms to create their ontology. However, at the other end of the spectrum, domain and application level ontologies create a world view that only extends to whatever domain or view of a domain is necessary for an application. These are the ontologies that we expect to derive from a generic data collection ontology with the benefit being that the ontology will implicitly have a higher level view because it will subclass terms within an existing reused hierarchy. 15

28 Going back to our definition of Ontology (See Section 2) we can see that upper level ontologies satisfy the condition of avoiding the definition of specific terms where general terms can be used. Additionally, they fit well with the ability to reuse and bridge other ontologies making upper level ontologies the only type that satisfies the requirement for reuse and therefore will work well as a base for generic data collection. Figure 2.1: The Ontology Hierarchy demonstrates how term specificity and structural design affects use case. Term Generality Upper Level Ontologies Mid Level Ontologies Core Ontologies Domain Level Ontologies Application Ontologies General terms meant for all ontologies to be based on. Enforces structure at a high level. Mid Level ontologies bridge the gap between highly generic upper level terms to the terms of a particular domain. Core ontologies define multiple view points or multiple domains. Ontologies that define the view a particular domain has of the world. Local or Application ontologies define a view specific to a particular application. A substantial amount of work has been done in the area of upper level ontologies to produce a solution to become the basis for all ontologies. These developments have prompted authors such as Mascardi et al. to perform a comparison of 7 upper level ontologies [35] in an effort analyze the characteristics amongst them. This number is substantial when you consider one of the goals of upper level ontologies is to unify all ontologies with a common core [32], [18]. This demonstrates that despite the work that has been put into developing upper level ontologies we have not reached an agreed upon design that satisfies the needs of everyone and that their development is ongoing research [32]. One might then wonder why the work put into the development of upper level ontologies has not resulted in a common ontology that is shared among all domain level ontologies. One particular reason for this is the result of language implementation. Languages implemented 16

29 by computer scientists are based on set theory that captures abstract content well but does not capture the concrete objects and their relationships well enough to be completely generic [27]. More recently the author of the General Formal Ontology (GFO) stated that we may not be able to meet such a lofty goal at all [32]. However for the problem s purposes this is still acceptable since one must work with what is available. With that in mind we will focus on available upper level ontologies to seek a design that best meets the requirements of our problem. All of the ontologies are sourced from Mascardi et al. [35] due to it capturing recent and active implementations. To describe such needs we will define criteria that will help us to draw conclusions based on upper level ontology design, purpose, and applications. When developing such a criteria we are seeking to choose the ontology that has the smallest delta from what is considered the ideal upper level ontology based on how we have defined an upper level ontology, our definition of ontology, and our problem. The first criteria we want to define is based on the number of terms and relations in the ontology, where we prefer to have little of each for two main reasons. Firstly, upper level ontologies are meant to be derived into a domain level ontology and thus will have more terms and relations added over time and, large ontologies introduce performance penalties potentially resulting in an ontology that is intractable for a reasoner [34]. Secondly, in terms of understandability, the fewer terms a person must know to use an ontology the easier it is to get started. Also, it will reduce reliance on documentation and expert knowledge making it easier to design and organize derived ontologies. Furthermore large ontologies may deter usage of the ontology altogether. The second criteria we care about is usage and popularity. Popularity of an upper level ontology is important when considering its purpose of unifying ontologies [32]. We want to look at what people are using to see what is working and how many domains are being captured by the upper level ontology. If only one domain is using a particular ontology it is possible that it has not met the needs of others. Additionally greater popularity increases the likelihood that ontology developers will have experience with the ontology. Finally, we move on to a more formal definition for upper level ontologies which is used 17

30 for the purpose of ensuring that the base is kept generic, again to satisfy our definition. Thus we say an upper level ontology must be free from any domain specific terms or relations. We are not interested in ontologies that take the role of defining thousands of terms to satisfy a large number of domains since it is unlikely such an ontology could satisfy each domain realistically Upper Level Ontologies Based on our criteria we will examine several upper level ontologies to see how they suit our desired characteristics defined above. When choosing ontologies we sought only ontologies in active development and only open source ontologies. We left out other major ones that appear to be no longer active. This is because the development of upper level ontologies is considered a long term research effort that requires continued progress [35]. The selected ontologies include the Basic Formal Ontology (BFO), the General Formal Ontology (GFO), a Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE), and the Suggested Merged Upper Ontology (SUMO). We will start by introducing each ontology, its purpose, design decisions and use cases. We will then move on to a comparison and the application of our defined criteria. BFO is an upper level ontology with development starting in 1998 [35]. It currently consists of 35 classes in version 2 [7]. BFO is commonly applied in the biology domain but does exist in a number of other domains and is used in over 150 ontologies as of this writing [12]. BFO itself contains no domain specific content and focuses on describing objects through time and space which is common to all physical objects. It considers both abstract and concrete terms and seeks to define terms based on their lifespan as either occurrent or continuant, with occurrent defining objects that exist during a period of time while continuants exist throughout time [12]. GFO started development during the definition of the GOL language [27, 35] and continued with a more recent paper by Herre [32]. GFO separates its entities based on whether they will be instantiable or non-instantiable. In addition GFO focuses on class axioms that 18

31 dictate where in the ontology derived entities will go with GFO supporting 212 [5] logical axioms to BFOs 52 [7]. GFO contains 45 classes in version 1.0 [5]. Like BFO, GFO defines both time and space and allows objects to have different relationships depending on being abstract or concrete [5]. SUMO started development prior to 2001 with a paper by Niles and Pearse [39]. SUMO in its base ontological form currently consists of 4558 classes and is based around the use of modules. With all of its domain extensions SUMO currently consists of approximately classes [11]. SUMO takes the principle of combining a number of domain specific ontologies to provide an upper level ontology capable of supporting any domain [39] [40]. Unlike GFO and BFO, SUMO defines its terms using concrete terms and does not make use of abstract definitions of time and space to group terms as abstract or concrete. DOLCE started development in 2002 as part of the Wonder Web project but has since separated from the project [35]. DOLCE divides terms into abstract and entities [9] while defining time and space for terms. DOLCE lite consists of 37 classes and 349 logical axioms [9]. Like SUMO, DOLCE is divided into sub modules that allows for additional terms [35]. Comparison of Upper Level Ontologies Each of the discussed upper level ontologies has its own merits which will be examined in this section. Once the merits are discussed we will look at how the ontologies fit with our definition of an upper level ontology. BFO and GFO are generally very similar to each other in their size and definition type. They both focus on defining abstract and concrete (instance) type objects as well as the world they live in. The GFO s concept of Abstract roughly matches that of the BFO s generically dependant continuant but without the restriction of time [5, 7]. BFO takes the approach of dividing based on time whereas GFO defines on instantiation. It appears that due to similar high level content both ontologies could serve as high level designs. SUMO and DOLCE are similar in that they focus on more common sense type terms 19

32 Name Table 2.1: The evaluated upper level ontology implementations summarized. Year Created Classes Axioms Purpose BFO Designed to provide needed definitions for all ontologies. BFO works based on the idea of dividing elements into their existence in timespace. BFO does not contain domain specific content but is most often implemented in the biology domain. GFO Designed to provide needed definitions for all ontologies. GFO works based on dividing elements into whether are instantiated or not. GFO does not contain domain specific content but is currently lacking implementations using it. SUMO N/A Designed around the idea of separation into modules based on ontology purpose and therefore does contain domain specific content. SUMO is a merged ontology and the result of merging non-commercial freely available terms to form an upper level ontology. DOLCE Designed for linguistics, DOLCE organizes by Lite dividing terms into abstract items and entities while also defining time and space. Similar to SUMO, DOCLE also provides several sub modules and based on its design for linguistics; does contain domain specific content. 20

33 without the abstract terms of GFO and BFO. Additionally they both use the concept of modules that enables them to be expanded with greater domain content. This provides the benefit of quickly pulling in several domain modules. These domain modules can serve the purpose of defining a core level ontology. The disadvantage of both SUMO and DOLCE is that they require significant size to include domain level content since they take a less abstract approach to the grouping of terms [35]. Moving on to our specified criteria we will the ontologies examine to see which ones best suit our purposes. One of the first requirements we determined was that the size of the ontology was significant since it would be built upon. In this case both DOLCE and SUMO present the issue of not using abstract terms for their definitions. The base size of DOLCE is only 37 classes but modules quickly add up to over 100 terms [35]. SUMO starts out significantly larger at 4558 [11] and then rises to with all modules added [11]. When that is compared to GFOs 45 and BFOs 35 it is easy to see that they are at least a magnitude larger. The next criteria requires no domain specific content. DOLCE includes a mathematical set definition in the ontology [9] which creates ties to the math domain. A Mathematical set is unlikely to be used in an ontology that describes business practices or that describes the parts of a body, so in these cases such a term provides no benefit and is out of place in such an ontology. SUMO has many domain specific terms and is based around domain specific modules to build up its capabilities as a upper level ontology [40]. We start to see a trend while looking at SUMO and DOLCE and that is because they are more interested in concrete rather than abstract categories and thus they accumulate a lot of terms and begin to rely on domain specific definitions to develop their ontologies. For our purposes, this is undesirable since we are seeking to build an ontology that is agnostic to any domain. DOLCE and SUMO violate this constraint in their design. BFO and GFO do not define any domain specific content by focusing on time and space which are required by all domains and all concrete entities we might want to define in the real world [7] [5]. For our purposes these ontologies work well since they are compact, 21

34 provide only abstract, domain independent definitions which ensures that we start with only the essentials. The last measure to look at is popularity and usage and for this we move to resources on the web to see how many ontologies cite themselves as using each example here. BioPortal cites no known projects using GFO based on their database [5], while they cite 22 usages for BFO [2]. On the BFO web page they cite well over 150 ontologies or projects using BFO [12]. The importance is the projects stem from more than just the biological field. From the GFO site they only present GFO-BIO and biology ontologies as users of GFO [6]. Therefore based on what has been located on the published websites it appears BFO is more popular and diverse in its implementations. In terms of SUMO they note there are 7 projects using SUMO on their website [10]. The number of users of DOLCE could not be found as a direct number but based on papers and project it appears to be relatively popular based on a web search. Based on the criteria above BFO fares best which is why we will focus on discussing BFO and why it best fits our needs. The Basic Formal Ontology is in its second major version therefore we will focus on that version in discussion of terms and structure although the first version is quite similar [1]. 2.3 Problem Placement of Generic Data Collection Upper level ontologies a starting point for the creation of an ontology but do not give direction about the specificity of ontological terms (see Section 2.2.1). We propose a mid level ontology as the design target for the problem and in this section discuss why that choice best reflects the problem, our definition of ontology, and works with the chosen upper level ontology. We will start at examining how the problem fits with this design as well as discussing downsides to the design. 22

35 2.3.1 Mid Level Ontologies as Placement When looking for the class of ontology that best represents our problem we must assume that it handles the following restrictions: support BFO as a base ontology; enable reuse to develop further ontologies; and cannot impose highly specific domain dependent terms. This allows the re-examination of the classification hierarchy Figure 2.1 to determine that mid level ontologies best serve our purpose. In this section we will examine how and why a mid level ontology will best serve our purposes. Mid level ontologies seek to define a domain that is at a very high level and span multiple ontologies. They therefore are generally independent and define terms at a high level to avoid conflict with ontologies that will extend them. This fits well with our problem since it is expected that the solution will form the basis of a domain ontology but not be exhaustive in term definition. Second, in terms of our definition we seek to define terms as generically as possible but while also avoiding the redesigning of existing ontologies and the redefining of terms. Mid level ontologies allow reuse through having the upper level ontology define its basic structure. Another important part of mid level ontology compatibility is exposed when looking at the source ontology. It was noted that SUMO and DOLCE already have modules that are used for domain specific ontologies. In a way these modules are somewhat like mid level ontologies in that they fill a gap but differ in that they are at the domain level in many cases. BFO however, does support domain ontologies through its existing ontological framework and repositories that are built around it. The OBO foundry provides the framework and existing ontologies that have been developed using BFO and demonstrates existing mid level ontologies that are active, see Figure 2.3. This demonstrates merit to the proposed pattern as it provides concrete examples functioning with the Basic Formal Ontology [48]. Furthermore, the Basic Formal Ontology does not have a derived ontology that exists for our particular problem (data collection) demonstrating a gap in existing mid level ontologies where our proposed solution could fit. The design of BFO has taken into consideration mid level ontologies with working examples of mid level ontologies and domain level ontologies 23

36 Figure 2.2: An example of how domain level ontologies can utilize one or more mid level ontologies to extend capability while reusing existing terms. Ontological Level Upper Level Basic Formal Ontology (BFO) Mid Level Data Collection Ontology (DCO) Other Mid Level Ontologies Domain Level Domain Ontology Based on DCO Domain Ontology Based on DCO and other Mid Level Ontology(s) Domain Ontology Not Based on DCO utilizing those mid level ontologies [48]. 2.4 Conclusion In this chapter we have examined ontology classifications and determined that upper level ontologies provide domain independent designs and focus on describing the world at the highest level and based on our definition of ontology they are valuable in terms of reuse. We therefore began looking for particular designs since it was noted that there are several implementations. It was determined that due to the simplicity, popularity, flexibility, and focus on high level terms, the BFO was the best choice of examined upper level ontologies for our problem. Finally we looked at BFO in terms of a mid level extension and found that several implementations currently exist demonstrating that the pattern has merit and domain level ontologies already exist that make use of these designs. It should be noted that there are implications of these designs starting with the fact 24

37 Figure 2.3: The BFO Hierarchy demonstrates the use of different ontological levels (as defined within the Ontology Hierarchy, see Figure 2.1) by BFO developers, making it suitable for mid level construction. Upper Level Ontologies Basic Formal Ontology (BFO) Mid-level Ontologies Information Artifact Ontology (IAO) Ontology for Biomedical Investigation (OBI) Spatial Ontology (BSPO) Anatomy Ontology Environmental Ontology Infectious Disease Ontology (IDO) Domain Ontologies Cell Ontology Cellular Component Ontology Phenotypic Quality Ontology (PQO) Biological Process Ontology Subcellular Anatomy Ontology Sequence Ontology Molecular Function Protein Ontology that upper level ontologies are incomplete at best and inaccurate at worst with current implementations requiring versioning [1] that alter the design. This means that any mid level ontology could also be invalidated by a major design change. The second major issue with the design is the size of the ontology. While size was one of our comparison criteria when choosing an upper level ontology, these additional levels still introduce greater numbers of terms than ontologies that focus exclusively on domain level terms. We feel these issues are worthwhile trade offs for reasons of reusability, more standardized design among ontologies, and easier to understand terminology with domain specific terms which are sub-classed by more generic parent terms. 25

38 Chapter 3 Ontology Design This chapter is dedicated to an overview of the Data Collection Ontology (DCO), its components, relations, and design choices that make it suitable for data collection. The DCO is designed as a mid level ontology that extends the Basic Formal Ontology (BFO) to organize and provide placement for data collection terms. The DCO provides domain independent definitions as a starting place for domain data collection developers. Due to the fact that the DCO is a mid level ontology and is in its early design it is by no means finished and is expected to change over time. Like an upper level ontology it may be found to be incorrect or lacking and will need to be updated. We start by examining the BFO more in depth and then establish how the DCO is expected to be used by domain ontology developers. We then move on to discussing the components and relations of the ontology to understand why particular components exist and how they contribute to the intended use of the ontology. 3.1 BFO Discussion The Basic Formal Ontology provides several key advantages that serve us well starting with its focus on organization of terms into their existence in the world. BFO bases its concepts 26

39 around objects that exist in time space and those that do not, see Figure 3.1. BFO defines Occurents as terms that exist within time space in that they occur in a particular time period and/or take up space in the world. The second type is Continuant that do not exist in time space. This applies to any domain as it focuses on the world at a very high level and takes into consideration ideas and objects allowing separation of these in the designer s mind. Term Occurrent Continuant Description Entities that exist in some form of time space, i.e. they are an object that lives and dies and consumes some physical space Entities that exist outside of time space, i.e. a concept or idea in someone s mind. Table 3.1: The top level classes of the Basic Formal Ontology (BFO) that divide major elements BFO also provides a relatively small number of terms which is important from the developer s perspective as a large number of terms requires a greater understanding to know where derived terms should go or if they already exist. Furthermore, considering that the ontology will also be further derived to create a domain ontology, a smaller starting size helps developers to maintain a small size relative to other domain level ontologies. Another and perhaps more important benefit to small size is with the performance of reasoning. It becomes a greater factor as ontology size grows due to the fact that high term and instance counts prove intractable for current reasoners [34] which would remove capability from the proposed system and for derived ontologies. 3.2 Design Intentions The design has a philosophy about how data collection should be performed and does so at a high level allowing for more specific work flows to be integrated through defining data 27

40 Figure 3.1: The Basic Formal Ontologies Class Structure in its OWL implementation. All terms under owl:thing are defined in BFO as an OWL Class. 28

41 collection processes. This view is based on first describing what you are collecting; these are Subjects that represent a timeless view of your object. The DCO uses the BFO s independent continuants to define Subjects that describe objects as they are in concept but not as an instance that exists in time and space. Within DCO captured data are represented as instances and have the type of the Subject they are a data point of. DCO also includes processes to capture how data is collected and what stages it goes though. This is to support uses such as surveys or cyclic forms of collection. Additionally DCO places stress on types and units through the definitions of Datums that capture both measures and unit of measure ensuring all values are labelled appropriately. The final portion of the ontology is Classifiers which are defined as entities in the BFO structure since they are time and space irrelevant and may be used to classify any type. In this case it was felt that Classifiers should not be restricted to time or space due to their function of classifying any type. Classifiers are hierarchies of terms on which one defines equivalence relations to define what constitutes this particular class. Classifiers are designed around the suspicions or anecdotal estimates of what range one expects data to fall into. Classifiers are designed to be populated with instances which exist as individuals of any type in the ontology. These instances are then grouped based on the reasoner and can be queried to determine if they are of the expected type when entered in the ontology. In other words, it allows validation of the estimates or anecdotal data that one has. Classifiers provide an additional advantage when concerning data validity in that they are non-destructive whereas traditional approaches may place strict boundaries on collected data, removing instances that don t fit. Classifiers allow invalid data to be filtered but not permanently removed if an error in classification is detected but the datum is valid. This supposes that there is a dynamic aspect of the ontology that overtime it will shaped by the instances that it collects and therefore definitions will be challenged. 29

42 Figure 3.2: An example of classifiers that demonstrates the use of equivalency relations defined on the Classifier classes to reason the type of instances. This type can then be compared to the has expected type on the relation to determine consistency. Classifiers Compact Vehicle Midsize Vehicle Large Vehicle Reasoned Relationships Incoming Data w/ Attributes Ford Edge Ford F-150 Lexus ES350 Chevrolet Camaro Chevrolet Impala Classifiers Examined Classifiers are an important concept so we will examine them in further detail so one can understand their purpose and use cases. Classifiers in conjunction with the has expected type relation allow two types of inconsistencies to be detected in the ontology. Classifiers are defined as classes using OWL equivalence relations to restrict instances (Illustrated in Figure 3.2. The first we consider to be a datum inconsistency which occurs when the ontology has not classified your datum into a category you expected and this is because it does not belong in that category and the ontology has marked it as such. In other words, something about that datum is invalid. The second type is a world view inconsistency which occurs when there is a mismatch but you know your datum is accurate and in this case the ontology must be updated since its world view is inconsistent with actual collected data. In both cases the error is caught through finding instances that have has expected type relations that do not match the reasoner assigned type or the rdf:type. We will now go over an example of where this can be integrated into an external system. 30

43 Suppose we are creating an ontology to classify cats based on their age, weight, and breed. We have some estimates of what these ranges are for each breed and create Classifiers based on this. However, since they are estimates they may not be accurate. In this case the ontology may be used as a front end for vet clinic software and is able to present an error if a cats weight falls outside of a range based on its age and breed using the Classifiers. Since we know the Classifiers may not be accurate users can override and have the system alter the ontology to adjust ranges. With such a system Classifiers allow for both error detection (with mismatched classified values) and a dynamic ontology that re-captures Classifier ranges to be consistent with its domain. A second case using the same example would be creating a dataset of only valid data and have an external system adjust the ontology s classifications each time an inconsistency arises. In other words, you have the ontology learn the correct boundaries for given classifications. Classifiers are designed to be used as a part of a larger system to gain understanding of the data that is being captured. If we consider our examples above it can act like an error detection system as well as having the system automatically update the ontology when its world view is inconsistent. Furthermore one could determine the distribution of a Classifier category by importing its instances and using the has expected type to link to a data type in the external system and running a statistics package on the datums. Therefore, Classifiers used along with has expected type provide the means to link ontology instances to an external system making them a key component of the ontology. 3.3 Competency Questions Defined Here we will define the competency questions (see Section 2.1) used when designing the ontology, whose creation was based on the design principles and goals. Each question belongs to one of 4 categories based the type of question. These categories are defined as: Capability, a goal the ontology must accomplish or support in its design; Reasoning: 31

44 a goal that centres around the ontologies ability to reason in some aspect; Counting: a query that can return the result of some aggregation of instances; Selection: a query that returns instances based on some condition. The competency questions are defined in Table 3.2. Table 3.2: DCO Competency Questions to define the uses expected for the DCO implementation. ID Category Question 1 Capability Can construct a process based on blocked and unblocked flows allowing support for concurrency in processes? 2 Capability Has the ability to link complex classes to a similar type in an external system? 3 Capability Has the ability to apply universal time of any format across the ontology? 4 Capability Has the ability to assign qualities to data type? 5 Capability Has the ability to assign units of measure to data captured? 6 Reasoning Has the ability to re-classify existing data? 7 Reasoning Has the ability to assign expected types to individuals allowing automatic classification using the reasoner? 8 Counting What is the amount of captured aggregates? 9 Selection Has the ability to query based on data type and by data structure? 10 Selection Has the ability to query based on time? 3.4 Ontology Components With the high level view of DCO established we can further break down its components into main components: Subjects, Processes, Data Qualities, Classifiers, and Meta Data. In this section each of these terms is defined with examples and use cases. We can then move on to using the components with the defined object and data properties to form a working example of the DCO. The working example seeks to establish what a result of the DCO will will look like as its components are declared at a high level, like other mid level ontologies. 32

45 3.4.1 Classes Here we will cover all the major classes in the ontology however we will not be exhaustive with all subclassed types, for a visual representation of the classes in DCO, see Figure 3.6. Subjects represent what data is being collected from or about. Subjects can be either physical objects or concepts, meaning types can be either material or immaterial. Subjects are designated as Continuant meaning they represent subjects at a universal level leaving out anomalies of particular individuals. For example, if we are surveying people then the Subject may be Person and would define a person at a universal level. When instances are entered into the ontology they may have a relationship with the Person Subject i.e. part to Person but are themselves Occurrent and do exist in space and time. The person is instance is where specific attributes are captured such as height and weight or their name. Processes fall under the BFO s process definition with some extensions provided by DCO for convenience. DCO s processes allow one to support both state driven and independent processes. State driven processes require one process block to finish before another can continue while independent processes can have any number of process blocks running concurrently. An example of the process types can be seen in Figure 3.3. Classifiers are where equivalence relations are defined to classify instances in your ontology. Classifiers are where one defines the range data is expected to fall into to form a particular category or type. One may think of a Classifier as having the ontology assign type to an individual based on its understanding of the world. Classifiers can be thought of as the dynamic component of the ontology as they are designed to change if data proves them to be invalid. Alternatively individuals may change if they are proven invalid based on the ontology s view of the world. For an example of how classifiers are represented see Figure 3.4. Meta Data are descriptors that exist to define a data point or complex structure that one expects an individual to contain. Meta data describes the types and units allowing for data in multiple formats and multiple units while having it link to the same individual type. 33

46 Figure 3.3: DCO Process Types. State Driven Processes represent those that are blocking and require one process to finish before the next starts. The Independent Process structure allows for parallel tasks. Basic State Driven Process Independent Process Process Block Process Block Process Block Process Block 1 Process Block 2 Process Block 3 Process Block Process Block Process Block Process Block Process Block Sequential processes require one process block to end before another starts. This is the most common form of a process where block N depends on block N-1. Parallel processes act like several sequential processes allowing process blocks to overlap. Any number can overlap as there are no direct restrictions within the DCO. An example case of this would be if a study were conducted across North America where in Canada the metric system dominates while Americans use the Imperial system. Data could be captured for the same study just using different Meta Data classes to describe the units while declaring Classifiers to capture both formats. Data Qualities exist to define restrictions and set theory properties on instances that can be used as part of classifiers to group instances or as a part of a larger system. Examples of Data Qualities include boundedness, cardinality, and equality Relations In this section we will examine the relations defined in the DCO, and go over how they are used and the reason for their existence. The DCO defines several object and data type relations that are meant to be extended and added to, therefore these relations are by no means exhaustive but should provide good coverage for most ontologies. All data relations can be seen in Figure

47 Figure 3.4: DCO Classifier Type. Classifiers utilize the has expected type relation to compare to the type assigned by the OWL reasoner through equivalency relations assigned to a classifier to check consistency. Classifiers group instances based on equivalency relations using a reasoner where the has_expected_type serves to store the classifier you expect an instance to be grouped under Classifier ClassiferEX1 Equivalency Relations ClassifierEX2 InstanceEX1 InstanceEX1 InstanceEX2 Has_expected_type ClassifierEX2" Has_expected_type Based on the has_expected_type one can see where there is a discrepancy between the reasoned type or the ontology view of the world and the expected view highlighting an error on either side ClassifierEX1" Has_expected_type 35

48 Object Relations In this section top level object relations are discussed that are relations that act to link individuals to other individuals (see table 3.3) and are expected to be extended when deriving the DCO in a domain specific implementation. When viewing the tables a dash (-) reflects a relation that is at the top level. 36

49 Table 3.3: DCO Object Relations Summarized. Relation Purpose Inverse has part Allows individuals to be composed of other individuals. This is important where data is captured on different parts of a larger item or data is aggregated into a larger sum. Composition should not be thought of only in terms of physical objects having parts. has measure Measurements are considered any numerical value one captures and links to an individual. Note that this is a object property so it forces one to link to some descriptor for the value. Subclass of has measure has measurement datum properties as it links measurement datums This will be one of the most common to individuals so data is annotated with units. has measurement unit This provides a link for unit definitions to measurement datums. has time stamp Links a time value to some measurement datum that contains some time unit allowing a universal way to save time in an ontology. part to measure to measurement datum to measurement unit to time stamp to 37

50 Table 3.4: Object Relations Continued Relation Childof Purpose Inverse contains process has part Links a process to an object; for example, some subject may go through some process that captures data. The data collection may itself be a process and have a relation to a process. has quality - Allows individuals to possess particular qualities or require particular qualities on data being classified. has object - Used for objects that act as a control, for control example, in a process something may be a terminator. branches to has object Supposes that an object in a process will control branch to another object when it has completed allowing for order to captured. process to quality of object control to branch of Data Relations In this section key data relations are defined and discussed in table 3.5. These data properties are designed to cover most basic relations necessary to interact with the defined objects. It is expected most derivations of DCO will extend these properties for domain specific terms to establish the language used in that particular domain. When viewing the tables a dash (-) reflects a relation that is at the top level. 38

51 Relation has expected property Table 3.5: DCO Data Properties Summarized. Purpose Denotes what property this value is intended to represent. This is designed primarily for external use where a value may link with a variable. has expected type Denotes what type we expect an instance to be. This is has control Subclass of has control intended to be used in conjunction with Classifiers allowing ontology verification based on expected types. It is additionally intended to be used to link to external systems where we want an instance to link to a particular type. Represents data values that act as controls such as booleans that alter the flow of a process can repeat has sequence has value Denotes whether a particular entity can repeat such as a process block. Some processes may be cyclical Denotes a sequence value that may be used to order process blocks or other entities. The base compositor for values, allows an instance to be composed of particular values. Subclass of has value has coordinate value has maximum has minimum has time value has percentage has measurement value Used for denoting the location of instances. Represents a maximum expected value for an instance to have; good for creating ranges. Represents a minimum expected value for an instance to have; good for creating ranges. Links time values to instances. Note that format is independent and can be any type based on the ontology design. Commonly values are captured as percentages, reflected here. Used to link measurement values to measurement datums. 39

52 3.5 Working Example As an example of how the design works we will construct a very basic ontology around collecting vehicle performance data with a goal of comparing consistency of output figures against other instances of the same type (see Figure 3.5). We will refer to this as the Vehicle Output Ontology. The first Subject of our collection will be Vehicle which is the most generic object. The Vehicle Subject will describe what a vehicle is composed of from the performance perspective as this is the view our ontology has of the world. For example, every Vehicle has an Engine and a Transmission so we will define those as other Subjects since we are interested in these components as they alter a vehicle s performance substantially. Our last Subjects will be the Make and Model since we need to compare like for like vehicles and therefore need to know who manufactured them. Now we define the relations between our Subjects. Vehicles are made up of an Engine and a Transmission so we can use composition to define a Vehicle having those parts. DCO defines the part of relation which allows us to produce a composite relationship. Additionally Models are produced by some Make, and we can consider them part of what the company produces. For our example we can use the has part for Vehicle to the Engine and Transmission and we can subclass part to to include example of for Vehicle to Model while adding produces to has part to state that a manufacturer produces Vehicles and Models. Moving on to the data we would like to capture we will define measurement datums that will capture key performance points for a Vehicle. In this simple example we would like to capture the power and torque that the vehicle produces so we will define some common units. Power is measured commonly using horsepower and kilowatts while torque is measured commonly using foot pounds and newton meters. These are defined as instances under Power Unit and Torque Unit measurement units respectively. Finally we create datums for Power that require a numerical value and some Power Unit as well as a Torque Datum that requires a numerical value and some Torque Unit. With these measures defined we will say a subclassof Vehicle requires at least one of each measure using the has measurement datum 40

53 relation. The design can be partially illustrated as seen in Figure 3.5 where datums and units are defined as well as Subjects linking to their respective datums. This is the general structure expected for data that is to be collected on subjects. Figure 3.5: A partial model of the Vehicle Performance Ontology showing how DCO datums are used and linked to Subjects to specify units on captured instances. Measurement types are divided into broad categories: power units for engines and consumption for vehicle fuel economy Measurement Unit Subjects Two Subjects are defined for fuel economy in this case, the engine and a vehicle that data will be captured from. Vehicle Subject Has_part some Engine Engine Has Measurement Datum exactly 3 Fuel Economy Datum Has Measurement Datum exactly 2 power datums Power Unit Consumption Unit Has unit some Consumption Unit Fuel Economy Datum Power Datum Has Unit exactly 1 Power Unit Horsepower LB/FT l/100km Measurement Units Defined as Instances Measurement datums are defined for the measures that expected to be captured from subjects. They serve to link values with some unit type. Measurement Datum Now since we are capturing data on vehicle performance we may define Classifiers that are based on estimations of what we expect. For this example, let us say we are verifying that Vehicles are within their rated power measurements so we will define Classifiers based around manufacturer provided power and torque ratings for a particular vehicle and apply some expected variance to create boundaries. These Classifiers will use range values around 41

54 the Power and Torque measurement Datums we just defined. This allows us to create Classifiers around a particular Model using values for the Make and Model as well as ranges for Power and Torque for a particular Engine to group our Vehicles. The greatest importance here is when populating the ontology we must use the has expected type relation and link to the corresponding Make and Model Classifier to allow the data and the ontology to be validated. This is done by using the reasoner to add type to our added instances and then querying the reasoner for the intersection of instances that are not the same type as the has expected type URI value stated. In other words, this presents that there is an error with the Vehicle that data was captured on or that the ontology has an inaccurate view of what values are valid for that Vehicle. In creating classifiers it is useful to assign a name that relates to what you are capturing so has expected type values can be application generated or human generated very easily. For example, in our case we might name a classifier DodgeRam57Auto to denote that we expect this classifier to group all Dodge Ram pickups with the 5.7 litre engine and automatic transmission making it easy to to generate the URI with the data we use to populate an instance. 3.6 Design Summary The design of the DCO is based around an ontology validating and being validated by its own instances through the use of classifiers. It does this by using the has expected type relation to link to the URI of the Classifier class the subject is expected to align with and then using a reasoner to find all instances whose type does not match that of the has expected type relation. Another key point to the design of the DCO is its basis around generality of Subjects that are described based on attributes and measurements that define them within the view of the ontology. Instances can then be examples of Subjects using the relation has subject type. This is done to keep definitions at a high level for the purpose of re-usability where well described Subjects may be linked into other ontologies. 42

55 Figure 3.6: The top level class structure of the DCO within the BFO. Classifiers exist at the entity to level support reasoning with any type. owl:thing bfo:entity dco:classifier bfo:continuant bfo:occurrent 43

56 Figure 3.7: The branch of BFO Continuant decedents defined in the DCO. Continuants represent entities that remain the same throughout time. bfo:continuant bfo:generically dependent continuant dco:meta data dco:measurement datum dco:complex measurement datum dco:scalar measurement datum dco:length measurement datum dco:time measurement datum dco:measurement unit label dco:length unit dco:time unit bfo:independent continuant dco:subject bfo:immaterial entity bfo:continuant fiat boundary bfo:one-dimensional continuant fiat boundary bfo:two-dimensional continuant fiat boundary bfo:zero-dimensional continuant fiat boundary bfo:site bfo:spatial region bfo:one-dimensional spatial region bfo:two-dimensional spatial region bfo:three-dimensional spatial region bfo:zero-dimensional spatial region bfo:material entity bfo:fiat object part bfo:object bfo:object aggregate bfo:pecifically dependent continuant bfo:quality dco:relational quality dco:datatype property dco:boundedness dco:bounded dco:numerically bounded dco:unbounded dco:cardinality dco:countable dco:finite dco:uncountable dco:equality dco:equal dco:inequal dco:exactness dco:exact dco:approximate dco:numericalness dco:non numerical dco:numerical dco:realizable entity dco:disposition dco:function bfo:role dco:data role 44

57 Figure 3.8: The branch of BFO Occurrent decedents defined in the DCO. Occurrents represent entities that exist within a period of time. bfo:occurrent bfo:process bfo:process profile bfo:history dco:independent process dco:dependent process dco:exclusive state driven process dco:basic state dco:probabalistic state bfo:process boundary dco:process part bfo:spatiotemporal region bfo:temporal region bfo:one-dimensional temporal region bfo:zero-dimensional temporal region 45

58 Figure 3.9: The list of DCO relations and their structures broken down by type. Relations are used to link DCO classes and instances. (a) DCO Object Relations owl:topobjectproperty dco:has data entity dco:has measure dco:has measurement datum dco:has measurement unit dco:has time stamp dco:has object control dco:branches to dco:has part dco:contains process dco:has subject type dco:has quality dco:location of dco:realizes (b) DCO Data Relations owltopdataproperty dco:has expected property dco:has expected type dco:has control dco:can repeat dco:has sequence dco:has value dco:has coordinate value dco:has measurement value dco:has time value dco:has maximum dco:has minimum dco:has percentage 46

59 Chapter 4 Evaluation Methodology Evaluating the Data Collection Ontology requires the examination of our problem to establish the criteria and methods that are appropriate. The goal of the DCO is to facilitate domain level ontologies with providing terms and hierarchies that they can extend and reuse in their data collection components. In Chapter 2 we established this would be done through developing a mid level ontology that extends the Basic Formal Ontology, and will be extended directly through domain level ontologies. Based on the design of the DCO there are several areas we can use to evaluate the ontology. Firstly, we are concerned with general design of the DCO in terms of the components it provides. A data collection ontology must contain terms relevant to data collection while avoiding the declaration of terms that are too specific. Secondly, there is concern with documentation, and general usability. This is important because users are expected to interact directly with the ontology components. Finally, we are concerned with the criteria we used in Chapter 2 as that was the criteria we used when looking at reuse of source ontologies and therefore we must hold the same standard for our solution. With our criteria in mind we begin the chapter by outlining our hypotheses for a derived ontology constructed with the DCO. This sets up our experiments for the ontology of which there are two. These experiments serve to produce derived ontologies using the DCO, the 47

60 first of which is based on the Vehicle Ontology described in Chapter 3 but using data collected by United States Environmental Protection Agency for new vehicle fuel economy. The second ontology is based on the comparison of an existing ontology, the Survey Ontology [30], to a version derived using DCO. Each of these designs are outlined in this chapter to describe components, areas of reuse and the philosophy behind their design as well as the evaluation techniques used. The creation of ontologies using the Data Collection Ontology is important because it evaluates both usability and ensures that our ontology criteria is met and allows us to use additional ontology evaluation techniques. The last topic of this chapter is the discussion of the traditional evaluation methods of which we will use two. We will use the FOCA method [14] which is a framework for evaluation and additionally we will use our criteria defined in Chapter 2 to examine the derived ontologies ensuring they still reasonably meet the criteria we outlined in our search for upper level ontologies. 4.1 Research Hypotheses In this section we further discuss the hypotheses we defined in Chapter 1 that will be used to evaluate the merit of the Data Collection Ontology. Specifically, the hypotheses will be tested against ontologies constructed using the Data Collection Ontology as a base. For convenience the hypotheses are reiterated below Domain Overlap Hypothesis (H 1 ): There exists overlap with domain specific data collections terms and data collection terms within the DCO. Null Hypothesis: There is no overlap between domain specific data collection terms and the terms in the DCO. 48

61 4.1.2 Term Specificity Hypothesis (H 2 ): If and where overlap exists the DCO includes higher level terms than that of the domain specific data collection ontology (i.e. terms introduced are subclassing the DCO terms). Null Hypothesis:The overlapping terms are less generic or at the same level as in the DCO (i.e. terms introduced are parents to the DCO terms) Ontology Coverage Hypothesis (H 3 ): There are no terms defined outside of the DCO hierarchy (i.e. there are no terms defined at the owl:thing level). Null Hypothesis: There are terms that subclass owl:thing and are therefore outside of the DCO hierarchy. Each of these hypotheses seeks to evaluate a part of our problem. The first hypothesis is about problem coverage since the goal of the DCO is to enable data collection ontologies to reuse its components therefore the terms defined must cover data collection regardless of domain. The second hypothesis ensures that if and when the terms are being reused they are being subclassed and are not becoming the subclass of a defined term because they are too specific. Lastly, the third hypothesis is based around coverage, it is important that when using the BFO as a base and defining terms in the DCO we are not forcing developers to start declaring items outside of the DCO terms or the BFO terms. In other words nothing should be defined at the entity level or above. 4.2 Experiment 1: The EPA Fuel Economy Ontology The first experiment takes the idea of the Vehicle Output Ontology and uses available data from the Environmental Protection Agency (EPA) to create the EPA Fuel Economy 49

62 Ontology. Instead of modelling vehicle output however, we use similar components to capture vehicle fuel consumption. The EPA releases the fuel consumption ratings for new vehicles from 1984 to present. In addition to fuel economy, it includes engine information, transmission information, and vehicle size classifications. These size classifications are based on rules of interior and cargo capacity. These rules work as an example of how classifiers should work in the DCO ontology. The EPA labels each vehicle with a size classification of: Minicompact, Subcompact, Compact, Midsize, or Large. These values are used as a has expected type URI and the classifiers contain the rules for each size class. It is unlikely the EPA has made an error with their data but it does provide a nice example of where classifiers could be used. The structure of the Fuel Economy Ontology can be seen in Appendix A.1. The dataset can be found in [13]. The dataset starts from 1984 and goes until present day with updates occuring often as the EPA tests vehicles. The ratings of historic vehicles are also updated periodically. The CSV format was used with each row representing a test or data point and was parsed into the OWL format using Python 3 and the Owlready2 API to generate OWL out of Python Objects [8]. From the data set the following fields were used city08, highway08, comb08, displ, engid, make, model, year, and VClass [4]. We define the fields below: city08 - The city Miles per Gallon (MPG) a vehicle achieves highway08 - The highway MPG a vehicle achieves comb08 - The combined MPG, calculated based on 55% city driving displ - The Vehicle s engine displacement engid - The ID that identifies a particular engine make - The make of the vehicle model - The model of the vehicle year - The vehicle s model year 50

63 VClass - The vehicle s size class (Minicompact, Subcompact, Compact, Midsize, Large) Vehicles were selected from a reduced number of years and we chose long standing models, such as the Honda Accord, Toyota Camry, and Chevrolet Malibu to allow trends to be seen and to reduce the ontology size. This reduction in size was primarily to reduce reasoning time of the classifiers to allow for greater experimentation. In the next sections the design and components of the ontology will be described along with relations used and how the DCO allows for reuse of terms and relations as well as how it provided the overall structure for the design of the EPA Fuel Economy Ontology Classes The ontology defines Vehicle as the main subject since that a particular vehicle is what data is collected from. The Vehicle is defined in a universal type with the EPA test providing specific examples of a Vehicle. In addition the ontology also will model some of the data captured by the EPA such as information about the engine which is one of the biggest contributors to fuel consumption and what the EPA has the user select before presenting ratings. Finally, we will define Make and Model as subjects. We defined Make since makes must maintain fuel economy averages and model because the data spans from 1984 to present so while models have the same name, they can vary significantly between generations making it important to separate. For the meta data components, fuel economy datums are defined as well as volume and fuel consumption units that allow us to capture consumption, engine displacement, interior volume (for size classification), and fuel tank volume in the relevant units. Volume is particularly important since engine displacement is measured in litres today but was previously measured in cubic inches which is still the case with older EPA data, while interior volume is measured in cubic feet. 51

64 Figure 4.1: EPA Ontology Classifiers that are used to group vehicles based on their combined passenger and cargo capacity. Vehicle Size Minicompact Subcompact Compact Midsize Large This ontology does not involve processes since we are using already captured data, although one can imagine there is some process that the EPA uses to capture this data and while it may be worth modelling it is out of scope for our purposes but still supported by the DCO through the process hierarchy. Classifiers were defined in the EPA ontology to group vehicles based on their size, in this case the EPA has them labelled so we will use that as the has expected type URI to create groups for each vehicle size as defined by the EPA. The classifiers are based around the criteria for each size class allowing the ontology to validate the data. Additional classifiers around fuel economy based around an estimate of what one may expect a vehicle to achieve were created for further examples. All classes in the Fuel Economy Ontology can be seen in Figure A.1. 52

65 Table 4.1: Subjects defined in the EPA Fuel Economy Ontology. These subjects are based on the aspects that the EPA captures on the Vehicles tested. Term Vehicle Manufacturer Model Engine Purpose Captures a particular vehicle and its relevant attributes Links vehicles and models to the manufacturer that produced them Links vehicles to the particular model they describe Links an engine to a particular vehicle as many vehicles offer choice of engine Table 4.2: EPA Ontology Relations. These relations are defined to match the terminology used by the EPA for the values captured. Term achieves fuel economy has displacement has engine code Purpose Captures a fuel economy value Captures engine displacement Captures the unique code for a particular engine Relations Several domain specific relations were added so the ontology makes sense from a vehicle s perspective and the terms used for composition are human readable. Each of these relations is placed under one of the existing DCO relation hieararchies meaning there are no new top level relations. These relations were largely for the purpose of composition and therefore many of the relations are sub classing the part of relation. When linking meta data attributes many of the original relations were used since no more specific terms were needed. We found that the has meta property was fine since the meta data types were labeled with domain specific names. However, more specific data relations were created to label the values being collected such as fuel economy and various volumes. 53

66 Vehicle Object Relations Relation Purpose Subclass of has engine Links an engine individual to a vehicle part of manufactured by Links a vehicle to a manufacturer part to model of Links a vehicle to a model part to Table 4.3: Object Relations for the Vehicle Class 54

67 Figure 4.2: Vehicle Ontology Structure. This defines the structure of the ontology using DCO Subjects, Measurement Units, and Datums to represent the domain specific EPA Fuel Economy content. Measurement types are divided into broad categories, length for the vehicle dimensions, power units for engines and consumption for vehicle fuel economy Measurement Unit Subjects Two Subjects are defined for fuel economy in this case, the engine and a vehicle that data will be captured from. Engine Subject has part some Engine Vehicle Measurement Datum Measurement datums are defined for the measures that expected to be captured from subjects. They serve to link values with some unit type. has measurement datum exactly 2 Power Datum 55 Power Unit Length Unit Consumption Unit has unit some Consumption Unit has measurement datum some VehicleLengthDatum has Measurement Datum some Power Unit has unit some Length Unit Horsepower LB/FT Inches l/100km Vehicle Length Datum Power Datum Fuel Economy Datum has measurement exactly 3 Fuel Economy Datum Measurement Units Defined as Instances Subject Measurement Datums

An Ontology-Based Methodology for Integrating i* Variants

An Ontology-Based Methodology for Integrating i* Variants An Ontology-Based Methodology for Integrating i* Variants Karen Najera 1,2, Alicia Martinez 2, Anna Perini 3, and Hugo Estrada 1,2 1 Fund of Information and Documentation for the Industry, Mexico D.F,

More information

0.1 Upper ontologies and ontology matching

0.1 Upper ontologies and ontology matching 0.1 Upper ontologies and ontology matching 0.1.1 Upper ontologies Basics What are upper ontologies? 0.1 Upper ontologies and ontology matching Upper ontologies (sometimes also called top-level or foundational

More information

Conceptual Data Modeling for the Functional Decomposition of Mission Capabilities

Conceptual Data Modeling for the Functional Decomposition of Mission Capabilities Conceptual Data Modeling for the Functional Decomposition of Mission Capabilities February 27, 2018 Andrew Battigaglia Andrew.Battigaglia@gtri.gatech.edu 1 Motivation Describing Data The purpose of a functional

More information

Knowledge Representations. How else can we represent knowledge in addition to formal logic?

Knowledge Representations. How else can we represent knowledge in addition to formal logic? Knowledge Representations How else can we represent knowledge in addition to formal logic? 1 Common Knowledge Representations Formal Logic Production Rules Semantic Nets Schemata and Frames 2 Production

More information

Automation of Semantic Web based Digital Library using Unified Modeling Language Minal Bhise 1 1

Automation of Semantic Web based Digital Library using Unified Modeling Language Minal Bhise 1 1 Automation of Semantic Web based Digital Library using Unified Modeling Language Minal Bhise 1 1 Dhirubhai Ambani Institute for Information and Communication Technology, Gandhinagar, Gujarat, India Email:

More information

New Approach to Graph Databases

New Approach to Graph Databases Paper PP05 New Approach to Graph Databases Anna Berg, Capish, Malmö, Sweden Henrik Drews, Capish, Malmö, Sweden Catharina Dahlbo, Capish, Malmö, Sweden ABSTRACT Graph databases have, during the past few

More information

Data Models: The Center of the Business Information Systems Universe

Data Models: The Center of the Business Information Systems Universe Data s: The Center of the Business Information Systems Universe Whitemarsh Information Systems Corporation 2008 Althea Lane Bowie, Maryland 20716 Tele: 301-249-1142 Email: Whitemarsh@wiscorp.com Web: www.wiscorp.com

More information

A Developer s Guide to the Semantic Web

A Developer s Guide to the Semantic Web A Developer s Guide to the Semantic Web von Liyang Yu 1. Auflage Springer 2011 Verlag C.H. Beck im Internet: www.beck.de ISBN 978 3 642 15969 5 schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG

More information

Ontology Creation and Development Model

Ontology Creation and Development Model Ontology Creation and Development Model Pallavi Grover, Sonal Chawla Research Scholar, Department of Computer Science & Applications, Panjab University, Chandigarh, India Associate. Professor, Department

More information

Modeling Systems Using Design Patterns

Modeling Systems Using Design Patterns Modeling Systems Using Design Patterns Jaroslav JAKUBÍK Slovak University of Technology Faculty of Informatics and Information Technologies Ilkovičova 3, 842 16 Bratislava, Slovakia jakubik@fiit.stuba.sk

More information

Health Information Exchange Content Model Architecture Building Block HISO

Health Information Exchange Content Model Architecture Building Block HISO Health Information Exchange Content Model Architecture Building Block HISO 10040.2 To be used in conjunction with HISO 10040.0 Health Information Exchange Overview and Glossary HISO 10040.1 Health Information

More information

An Architecture for Semantic Enterprise Application Integration Standards

An Architecture for Semantic Enterprise Application Integration Standards An Architecture for Semantic Enterprise Application Integration Standards Nenad Anicic 1, 2, Nenad Ivezic 1, Albert Jones 1 1 National Institute of Standards and Technology, 100 Bureau Drive Gaithersburg,

More information

Semantic Annotations for BPMN models: Extending SeMFIS for supporting ontology reasoning and query functionalities. Dimitraki Katerina

Semantic Annotations for BPMN models: Extending SeMFIS for supporting ontology reasoning and query functionalities. Dimitraki Katerina Semantic Annotations for BPMN models: Extending SeMFIS for supporting ontology reasoning and query functionalities Dimitraki Katerina Thesis submitted in partial fulfillment of the requirements for the

More information

Teiid Designer User Guide 7.5.0

Teiid Designer User Guide 7.5.0 Teiid Designer User Guide 1 7.5.0 1. Introduction... 1 1.1. What is Teiid Designer?... 1 1.2. Why Use Teiid Designer?... 2 1.3. Metadata Overview... 2 1.3.1. What is Metadata... 2 1.3.2. Editing Metadata

More information

Integration With the Business Modeler

Integration With the Business Modeler Decision Framework, J. Duggan Research Note 11 September 2003 Evaluating OOA&D Functionality Criteria Looking at nine criteria will help you evaluate the functionality of object-oriented analysis and design

More information

KARL HAMMAR & VALENTINA PRESUTTI TEMPLATE-BASED CONTENT ODP INSTANTIATION

KARL HAMMAR & VALENTINA PRESUTTI TEMPLATE-BASED CONTENT ODP INSTANTIATION KARL HAMMAR & VALENTINA PRESUTTI TEMPLATE-BASED CONTENT ODP INSTANTIATION OVERVIEW Established methods of CODP instantiation. Our experiences of using CODPs in projects. The alternative: template-based

More information

A Knowledge-Based System for the Specification of Variables in Clinical Trials

A Knowledge-Based System for the Specification of Variables in Clinical Trials A Knowledge-Based System for the Specification of Variables in Clinical Trials Matthias Löbe, Barbara Strotmann, Kai-Uwe Hoop, Roland Mücke Institute for Medical Informatics, Statistics and Epidemiology

More information

VISO: A Shared, Formal Knowledge Base as a Foundation for Semi-automatic InfoVis Systems

VISO: A Shared, Formal Knowledge Base as a Foundation for Semi-automatic InfoVis Systems VISO: A Shared, Formal Knowledge Base as a Foundation for Semi-automatic InfoVis Systems Jan Polowinski Martin Voigt Technische Universität DresdenTechnische Universität Dresden 01062 Dresden, Germany

More information

SKOS. COMP62342 Sean Bechhofer

SKOS. COMP62342 Sean Bechhofer SKOS COMP62342 Sean Bechhofer sean.bechhofer@manchester.ac.uk Ontologies Metadata Resources marked-up with descriptions of their content. No good unless everyone speaks the same language; Terminologies

More information

Proposal for Implementing Linked Open Data on Libraries Catalogue

Proposal for Implementing Linked Open Data on Libraries Catalogue Submitted on: 16.07.2018 Proposal for Implementing Linked Open Data on Libraries Catalogue Esraa Elsayed Abdelaziz Computer Science, Arab Academy for Science and Technology, Alexandria, Egypt. E-mail address:

More information

Ontologies SKOS. COMP62342 Sean Bechhofer

Ontologies SKOS. COMP62342 Sean Bechhofer Ontologies SKOS COMP62342 Sean Bechhofer sean.bechhofer@manchester.ac.uk Metadata Resources marked-up with descriptions of their content. No good unless everyone speaks the same language; Terminologies

More information

Smart Open Services for European Patients. Work Package 3.5 Semantic Services Definition Appendix E - Ontology Specifications

Smart Open Services for European Patients. Work Package 3.5 Semantic Services Definition Appendix E - Ontology Specifications 24Am Smart Open Services for European Patients Open ehealth initiative for a European large scale pilot of Patient Summary and Electronic Prescription Work Package 3.5 Semantic Services Definition Appendix

More information

Helmi Ben Hmida Hannover University, Germany

Helmi Ben Hmida Hannover University, Germany Helmi Ben Hmida Hannover University, Germany 1 Summarizing the Problem: Computers don t understand Meaning My mouse is broken. I need a new one 2 The Semantic Web Vision the idea of having data on the

More information

UNIT II Requirements Analysis and Specification & Software Design

UNIT II Requirements Analysis and Specification & Software Design UNIT II Requirements Analysis and Specification & Software Design Requirements Analysis and Specification Many projects fail: because they start implementing the system: without determining whether they

More information

Using Dublin Core to Build a Common Data Architecture

Using Dublin Core to Build a Common Data Architecture Proc. Int. Conf. on Dublin Core and Metadata for e-communities 2002: 139-146 Firenze University Press Using Dublin Core to Build a Common Data Architecture Sandra Fricker Hostetter Rohm and Haas Company,

More information

Languages and tools for building and using ontologies. Simon Jupp, James Malone

Languages and tools for building and using ontologies. Simon Jupp, James Malone An overview of ontology technology Languages and tools for building and using ontologies Simon Jupp, James Malone jupp@ebi.ac.uk, malone@ebi.ac.uk Outline Languages OWL and OBO classes, individuals, relations,

More information

CHAPTER 7. Observations, Conclusions and Future Directions Observations 7.2. Limitations of the Model 7.3. Conclusions 7.4.

CHAPTER 7. Observations, Conclusions and Future Directions Observations 7.2. Limitations of the Model 7.3. Conclusions 7.4. CHAPTER 7 Observations, Conclusions and Future Directions 7.1. Observations 7.2. Limitations of the Model 7.3. Conclusions 7.4. Future work Domain-specific Ontology for Student s Information in Academic

More information

DCMI Abstract Model - DRAFT Update

DCMI Abstract Model - DRAFT Update 1 of 7 9/19/2006 7:02 PM Architecture Working Group > AMDraftUpdate User UserPreferences Site Page Actions Search Title: Text: AttachFile DeletePage LikePages LocalSiteMap SpellCheck DCMI Abstract Model

More information

Semantic Information Modeling for Federation (SIMF)

Semantic Information Modeling for Federation (SIMF) Purpose Semantic Information Modeling for Federation (SIMF) Overview V0.2-04/21/2011 The Architecture Ecosystem SIG of the Object Management Group (OMG) is in the process of drafting an RFP focused on

More information

A Collaborative User-centered Approach to Fine-tune Geospatial

A Collaborative User-centered Approach to Fine-tune Geospatial A Collaborative User-centered Approach to Fine-tune Geospatial Database Design Grira Joel Bédard Yvan Sboui Tarek 16 octobre 2012 6th International Workshop on Semantic and Conceptual Issues in GIS - SeCoGIS

More information

D WSMO Data Grounding Component

D WSMO Data Grounding Component Project Number: 215219 Project Acronym: SOA4All Project Title: Instrument: Thematic Priority: Service Oriented Architectures for All Integrated Project Information and Communication Technologies Activity

More information

The Design Patterns Matrix From Analysis to Implementation

The Design Patterns Matrix From Analysis to Implementation The Design Patterns Matrix From Analysis to Implementation This is an excerpt from Shalloway, Alan and James R. Trott. Design Patterns Explained: A New Perspective for Object-Oriented Design. Addison-Wesley

More information

Module 16. Software Reuse. Version 2 CSE IIT, Kharagpur

Module 16. Software Reuse. Version 2 CSE IIT, Kharagpur Module 16 Software Reuse Lesson 40 Reuse Approach Specific Instructional Objectives At the end of this lesson the student would be able to: Explain a scheme by which software reusable components can be

More information

Building the NNEW Weather Ontology

Building the NNEW Weather Ontology Building the NNEW Weather Ontology Kelly Moran Kajal Claypool 5 May 2010 1 Outline Introduction Ontology Development Methods & Tools NNEW Weather Ontology Design Application: Semantic Search Summary 2

More information

Object- Oriented Design with UML and Java Part I: Fundamentals

Object- Oriented Design with UML and Java Part I: Fundamentals Object- Oriented Design with UML and Java Part I: Fundamentals University of Colorado 1999-2002 CSCI-4448 - Object-Oriented Programming and Design These notes as free PDF files: http://www.softwarefederation.com/cs4448.html

More information

An Ontological Approach to Domain Engineering

An Ontological Approach to Domain Engineering An Ontological Approach to Domain Engineering Richard de Almeida Falbo, Giancarlo Guizzardi, Katia Cristina Duarte International Conference on Software Engineering and Knowledge Engineering, SEKE 02 Taehoon

More information

Symbolic Execution and Proof of Properties

Symbolic Execution and Proof of Properties Chapter 7 Symbolic Execution and Proof of Properties Symbolic execution builds predicates that characterize the conditions under which execution paths can be taken and the effect of the execution on program

More information

SOME TYPES AND USES OF DATA MODELS

SOME TYPES AND USES OF DATA MODELS 3 SOME TYPES AND USES OF DATA MODELS CHAPTER OUTLINE 3.1 Different Types of Data Models 23 3.1.1 Physical Data Model 24 3.1.2 Logical Data Model 24 3.1.3 Conceptual Data Model 25 3.1.4 Canonical Data Model

More information

Solution Architecture Template (SAT) Design Guidelines

Solution Architecture Template (SAT) Design Guidelines Solution Architecture Template (SAT) Design Guidelines Change control Modification Details Version 2.0.0 Alignment with EIRA v2.0.0 Version 1.0.0 Initial version ISA² Action - European Interoperability

More information

Available online at ScienceDirect. Procedia Computer Science 52 (2015 )

Available online at  ScienceDirect. Procedia Computer Science 52 (2015 ) Available online at www.sciencedirect.com ScienceDirect Procedia Computer Science 52 (2015 ) 1071 1076 The 5 th International Symposium on Frontiers in Ambient and Mobile Systems (FAMS-2015) Health, Food

More information

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich CSCD01 Engineering Large Software Systems Design Patterns Joe Bettridge Winter 2018 With thanks to Anya Tafliovich Design Patterns Design patterns take the problems consistently found in software, and

More information

Goals of the BPEL4WS Specification

Goals of the BPEL4WS Specification Goals of the BPEL4WS Specification Frank Leymann, Dieter Roller, and Satish Thatte This note aims to set forward the goals and principals that formed the basis for the work of the original authors of the

More information

Expose Existing z Systems Assets as APIs to extend your Customer Reach

Expose Existing z Systems Assets as APIs to extend your Customer Reach Expose Existing z Systems Assets as APIs to extend your Customer Reach Unlocking mainframe assets for mobile and cloud applications Asit Dan z Services API Management, Chief Architect asit@us.ibm.com Insert

More information

RDF /RDF-S Providing Framework Support to OWL Ontologies

RDF /RDF-S Providing Framework Support to OWL Ontologies RDF /RDF-S Providing Framework Support to OWL Ontologies Rajiv Pandey #, Dr.Sanjay Dwivedi * # Amity Institute of information Technology, Amity University Lucknow,India * Dept.Of Computer Science,BBA University

More information

The Semantic Web DEFINITIONS & APPLICATIONS

The Semantic Web DEFINITIONS & APPLICATIONS The Semantic Web DEFINITIONS & APPLICATIONS Data on the Web There are more an more data on the Web Government data, health related data, general knowledge, company information, flight information, restaurants,

More information

Annotation Science From Theory to Practice and Use Introduction A bit of history

Annotation Science From Theory to Practice and Use Introduction A bit of history Annotation Science From Theory to Practice and Use Nancy Ide Department of Computer Science Vassar College Poughkeepsie, New York 12604 USA ide@cs.vassar.edu Introduction Linguistically-annotated corpora

More information

Category Theory in Ontology Research: Concrete Gain from an Abstract Approach

Category Theory in Ontology Research: Concrete Gain from an Abstract Approach Category Theory in Ontology Research: Concrete Gain from an Abstract Approach Markus Krötzsch Pascal Hitzler Marc Ehrig York Sure Institute AIFB, University of Karlsruhe, Germany; {mak,hitzler,ehrig,sure}@aifb.uni-karlsruhe.de

More information

Ontological Modeling: Part 2

Ontological Modeling: Part 2 Ontological Modeling: Part 2 Terry Halpin LogicBlox This is the second in a series of articles on ontology-based approaches to modeling. The main focus is on popular ontology languages proposed for the

More information

ISO CTS2 and Value Set Binding. Harold Solbrig Mayo Clinic

ISO CTS2 and Value Set Binding. Harold Solbrig Mayo Clinic ISO 79 CTS2 and Value Set Binding Harold Solbrig Mayo Clinic ISO 79 Information technology - Metadata registries (MDR) Owning group is ISO/IEC JTC /SC 32 Organization responsible for SQL standard Six part

More information

Extension and integration of i* models with ontologies

Extension and integration of i* models with ontologies Extension and integration of i* models with ontologies Blanca Vazquez 1,2, Hugo Estrada 1, Alicia Martinez 2, Mirko Morandini 3, and Anna Perini 3 1 Fund Information and Documentation for the industry

More information

Extracting knowledge from Ontology using Jena for Semantic Web

Extracting knowledge from Ontology using Jena for Semantic Web Extracting knowledge from Ontology using Jena for Semantic Web Ayesha Ameen I.T Department Deccan College of Engineering and Technology Hyderabad A.P, India ameenayesha@gmail.com Khaleel Ur Rahman Khan

More information

ArchiMate 2.0. Structural Concepts Behavioral Concepts Informational Concepts. Business. Application. Technology

ArchiMate 2.0. Structural Concepts Behavioral Concepts Informational Concepts. Business. Application. Technology ArchiMate Core Structural Concepts Behavioral Concepts Informational Concepts interaction Technology Application Layer Concept Description Notation Concept Description Notation Actor An organizational

More information

Standard Glossary of Terms used in Software Testing. Version 3.2. Foundation Extension - Usability Terms

Standard Glossary of Terms used in Software Testing. Version 3.2. Foundation Extension - Usability Terms Standard Glossary of Terms used in Software Testing Version 3.2 Foundation Extension - Usability Terms International Software Testing Qualifications Board Copyright Notice This document may be copied in

More information

Copyright is owned by the Author of the thesis. Permission is given for a copy to be downloaded by an individual for the purpose of research and

Copyright is owned by the Author of the thesis. Permission is given for a copy to be downloaded by an individual for the purpose of research and Copyright is owned by the Author of the thesis. Permission is given for a copy to be downloaded by an individual for the purpose of research and private study only. The thesis may not be reproduced elsewhere

More information

H1 Spring C. A service-oriented architecture is frequently deployed in practice without a service registry

H1 Spring C. A service-oriented architecture is frequently deployed in practice without a service registry 1. (12 points) Identify all of the following statements that are true about the basics of services. A. Screen scraping may not be effective for large desktops but works perfectly on mobile phones, because

More information

Metadata in the Driver's Seat: The Nokia Metia Framework

Metadata in the Driver's Seat: The Nokia Metia Framework Metadata in the Driver's Seat: The Nokia Metia Framework Abstract Patrick Stickler The Metia Framework defines a set of standard, open and portable models, interfaces, and

More information

WHY WE NEED AN XML STANDARD FOR REPRESENTING BUSINESS RULES. Introduction. Production rules. Christian de Sainte Marie ILOG

WHY WE NEED AN XML STANDARD FOR REPRESENTING BUSINESS RULES. Introduction. Production rules. Christian de Sainte Marie ILOG WHY WE NEED AN XML STANDARD FOR REPRESENTING BUSINESS RULES Christian de Sainte Marie ILOG Introduction We are interested in the topic of communicating policy decisions to other parties, and, more generally,

More information

University of Huddersfield Repository

University of Huddersfield Repository University of Huddersfield Repository Olszewska, Joanna Isabelle, Simpson, Ron and McCluskey, T.L. Appendix A: epronto: OWL Based Ontology for Research Information Management Original Citation Olszewska,

More information

JULIA ENABLED COMPUTATION OF MOLECULAR LIBRARY COMPLEXITY IN DNA SEQUENCING

JULIA ENABLED COMPUTATION OF MOLECULAR LIBRARY COMPLEXITY IN DNA SEQUENCING JULIA ENABLED COMPUTATION OF MOLECULAR LIBRARY COMPLEXITY IN DNA SEQUENCING Larson Hogstrom, Mukarram Tahir, Andres Hasfura Massachusetts Institute of Technology, Cambridge, Massachusetts, USA 18.337/6.338

More information

code pattern analysis of object-oriented programming languages

code pattern analysis of object-oriented programming languages code pattern analysis of object-oriented programming languages by Xubo Miao A thesis submitted to the School of Computing in conformity with the requirements for the degree of Master of Science Queen s

More information

Organizing Information. Organizing information is at the heart of information science and is important in many other

Organizing Information. Organizing information is at the heart of information science and is important in many other Dagobert Soergel College of Library and Information Services University of Maryland College Park, MD 20742 Organizing Information Organizing information is at the heart of information science and is important

More information

Chapter 8: Enhanced ER Model

Chapter 8: Enhanced ER Model Chapter 8: Enhanced ER Model Subclasses, Superclasses, and Inheritance Specialization and Generalization Constraints and Characteristics of Specialization and Generalization Hierarchies Modeling of UNION

More information

is easing the creation of new ontologies by promoting the reuse of existing ones and automating, as much as possible, the entire ontology

is easing the creation of new ontologies by promoting the reuse of existing ones and automating, as much as possible, the entire ontology Preface The idea of improving software quality through reuse is not new. After all, if software works and is needed, just reuse it. What is new and evolving is the idea of relative validation through testing

More information

The Unified Modelling Language. Example Diagrams. Notation vs. Methodology. UML and Meta Modelling

The Unified Modelling Language. Example Diagrams. Notation vs. Methodology. UML and Meta Modelling UML and Meta ling Topics: UML as an example visual notation The UML meta model and the concept of meta modelling Driven Architecture and model engineering The AndroMDA open source project Applying cognitive

More information

Semantic Web. Ontology Pattern. Gerd Gröner, Matthias Thimm. Institute for Web Science and Technologies (WeST) University of Koblenz-Landau

Semantic Web. Ontology Pattern. Gerd Gröner, Matthias Thimm. Institute for Web Science and Technologies (WeST) University of Koblenz-Landau Semantic Web Ontology Pattern Gerd Gröner, Matthias Thimm {groener,thimm}@uni-koblenz.de Institute for Web Science and Technologies (WeST) University of Koblenz-Landau July 18, 2013 Gerd Gröner, Matthias

More information

Opus: University of Bath Online Publication Store

Opus: University of Bath Online Publication Store Patel, M. (2004) Semantic Interoperability in Digital Library Systems. In: WP5 Forum Workshop: Semantic Interoperability in Digital Library Systems, DELOS Network of Excellence in Digital Libraries, 2004-09-16-2004-09-16,

More information

Unit 1 : Principles of object oriented programming

Unit 1 : Principles of object oriented programming Unit 1 : Principles of object oriented programming Difference Between Procedure Oriented Programming (POP) & Object Oriented Programming (OOP) Divided Into Importance Procedure Oriented Programming In

More information

NeOn Methodology for Building Ontology Networks: a Scenario-based Methodology

NeOn Methodology for Building Ontology Networks: a Scenario-based Methodology NeOn Methodology for Building Ontology Networks: a Scenario-based Methodology Asunción Gómez-Pérez and Mari Carmen Suárez-Figueroa Ontology Engineering Group. Departamento de Inteligencia Artificial. Facultad

More information

The MUSING Approach for Combining XBRL and Semantic Web Data. ~ Position Paper ~

The MUSING Approach for Combining XBRL and Semantic Web Data. ~ Position Paper ~ The MUSING Approach for Combining XBRL and Semantic Web Data ~ Position Paper ~ Christian F. Leibold 1, Dumitru Roman 1, Marcus Spies 2 1 STI Innsbruck, Technikerstr. 21a, 6020 Innsbruck, Austria {Christian.Leibold,

More information

Chapter No. 2 Class modeling CO:-Sketch Class,object models using fundamental relationships Contents 2.1 Object and Class Concepts (12M) Objects,

Chapter No. 2 Class modeling CO:-Sketch Class,object models using fundamental relationships Contents 2.1 Object and Class Concepts (12M) Objects, Chapter No. 2 Class modeling CO:-Sketch Class,object models using fundamental relationships Contents 2.1 Object and Class Concepts (12M) Objects, Classes, Class Diagrams Values and Attributes Operations

More information

Six Sigma in the datacenter drives a zero-defects culture

Six Sigma in the datacenter drives a zero-defects culture Six Sigma in the datacenter drives a zero-defects culture Situation Like many IT organizations, Microsoft IT wants to keep its global infrastructure available at all times. Scope, scale, and an environment

More information

Knowledge Representation for the Semantic Web

Knowledge Representation for the Semantic Web Knowledge Representation for the Semantic Web Winter Quarter 2012 Pascal Hitzler Slides 2 01/05/2011 Kno.e.sis Center Wright State University, Dayton, OH http://www.knoesis.org/pascal/ KR4SW Winter 2012

More information

LEVERAGING PARAMETER AND RESOURCE NAMING CONVENTIONS TO IMPROVE TEST SUITE ADHERENCE TO PERSISTENT STATE CONDITIONS.

LEVERAGING PARAMETER AND RESOURCE NAMING CONVENTIONS TO IMPROVE TEST SUITE ADHERENCE TO PERSISTENT STATE CONDITIONS. LEVERAGING PARAMETER AND RESOURCE NAMING CONVENTIONS TO IMPROVE TEST SUITE ADHERENCE TO PERSISTENT STATE CONDITIONS by Johanna Goergen 2016 c 2016 Johanna Goergen All Rights Reserved TABLE OF CONTENTS

More information

X-KIF New Knowledge Modeling Language

X-KIF New Knowledge Modeling Language Proceedings of I-MEDIA 07 and I-SEMANTICS 07 Graz, Austria, September 5-7, 2007 X-KIF New Knowledge Modeling Language Michal Ševčenko (Czech Technical University in Prague sevcenko@vc.cvut.cz) Abstract:

More information

Semantic Web. Ontology Engineering and Evaluation. Morteza Amini. Sharif University of Technology Fall 95-96

Semantic Web. Ontology Engineering and Evaluation. Morteza Amini. Sharif University of Technology Fall 95-96 ه عا ی Semantic Web Ontology Engineering and Evaluation Morteza Amini Sharif University of Technology Fall 95-96 Outline Ontology Engineering Class and Class Hierarchy Ontology Evaluation 2 Outline Ontology

More information

Semantic Web. Lecture XIII Tools Dieter Fensel and Katharina Siorpaes. Copyright 2008 STI INNSBRUCK

Semantic Web. Lecture XIII Tools Dieter Fensel and Katharina Siorpaes. Copyright 2008 STI INNSBRUCK Semantic Web Lecture XIII 25.01.2010 Tools Dieter Fensel and Katharina Siorpaes Copyright 2008 STI INNSBRUCK Today s lecture # Date Title 1 12.10,2009 Introduction 2 12.10,2009 Semantic Web Architecture

More information

Ontology driven voice-based interaction in mobile environment

Ontology driven voice-based interaction in mobile environment Ontology driven voice-based interaction in mobile environment Jiri Kopsa 1, Zdenek Mikovec 1, Pavel Slavik 1 1 Czech Technical University in Prague Karlovo namesti 13, Prague 2, Czech Republic j.kopsa@fee.ctup.cz,

More information

1 Executive Overview The Benefits and Objectives of BPDM

1 Executive Overview The Benefits and Objectives of BPDM 1 Executive Overview The Benefits and Objectives of BPDM This is an excerpt from the Final Submission BPDM document posted to OMG members on November 13 th 2006. The full version of the specification will

More information

The Semantic Planetary Data System

The Semantic Planetary Data System The Semantic Planetary Data System J. Steven Hughes 1, Daniel J. Crichton 1, Sean Kelly 1, and Chris Mattmann 1 1 Jet Propulsion Laboratory 4800 Oak Grove Drive Pasadena, CA 91109 USA {steve.hughes, dan.crichton,

More information

Chapter IV. Introduction

Chapter IV. Introduction 54 Chapter IV ULTRAMAN ARCHITECTURE Introduction In previous chapters, we have introduced and motivated the ideas of a transformational approach to generating user interfaces. Throughout this dissertation

More information

Standards Readiness Criteria. Tier 2

Standards Readiness Criteria. Tier 2 Document Number: HITSP 06 N 85 Date: June 1, 2006 Standards Readiness Criteria Tier 2 Version 1.0 May 12, 2006 HITSP Standards Harmonization Committee V 1.0 (5/12/2006) 1 Introduction...3 Background Information...3

More information

Chapter 2 Overview of the Design Methodology

Chapter 2 Overview of the Design Methodology Chapter 2 Overview of the Design Methodology This chapter presents an overview of the design methodology which is developed in this thesis, by identifying global abstraction levels at which a distributed

More information

Ontology Refinement and Evaluation based on is-a Hierarchy Similarity

Ontology Refinement and Evaluation based on is-a Hierarchy Similarity Ontology Refinement and Evaluation based on is-a Hierarchy Similarity Takeshi Masuda The Institute of Scientific and Industrial Research, Osaka University Abstract. Ontologies are constructed in fields

More information

10 Steps to Building an Architecture for Space Surveillance Projects. Eric A. Barnhart, M.S.

10 Steps to Building an Architecture for Space Surveillance Projects. Eric A. Barnhart, M.S. 10 Steps to Building an Architecture for Space Surveillance Projects Eric A. Barnhart, M.S. Eric.Barnhart@harris.com Howard D. Gans, Ph.D. Howard.Gans@harris.com Harris Corporation, Space and Intelligence

More information

Chapter 1 Introduction

Chapter 1 Introduction Chapter 1 Introduction We hardly need to point out the importance of business process modelling and of respective automation in this place (see, e.g. [39, 45, 58, 110, 141]). Also the advantages and shortcomings

More information

DATA STRUCTURES CHAPTER 1

DATA STRUCTURES CHAPTER 1 DATA STRUCTURES CHAPTER 1 FOUNDATIONAL OF DATA STRUCTURES This unit introduces some basic concepts that the student needs to be familiar with before attempting to develop any software. It describes data

More information

It Is What It Does: The Pragmatics of Ontology for Knowledge Sharing

It Is What It Does: The Pragmatics of Ontology for Knowledge Sharing It Is What It Does: The Pragmatics of Ontology for Knowledge Sharing Tom Gruber Founder and CTO, Intraspect Software Formerly at Stanford University tomgruber.org What is this talk about? What are ontologies?

More information

WYSIWON T The XML Authoring Myths

WYSIWON T The XML Authoring Myths WYSIWON T The XML Authoring Myths Tony Stevens Turn-Key Systems Abstract The advantages of XML for increasing the value of content and lowering production costs are well understood. However, many projects

More information

STAR Naming and Design Rules. Version 1.0

STAR Naming and Design Rules. Version 1.0 Version 1.0 March 2007 Revision History Revision Date Version Initial Version March 13, 2007 1.0 Table of Contents 1. Introduction...1 1.1 Purpose...1 1.2 Objective... 1 1.3 Scope...1 1.4 Prerequisites...1

More information

Semantic Concept Modeling UML Profile

Semantic Concept Modeling UML Profile Semantic Concept Modeling UML Profile 1 Semantic Concept Modeling UML Profile... 4 1.1 Semantic Concept Modeling Introduction... 4 1.1.1 What is a semantic concept model?... 4 1.1.2 Semantic Domain Models

More information

Describing the architecture: Creating and Using Architectural Description Languages (ADLs): What are the attributes and R-forms?

Describing the architecture: Creating and Using Architectural Description Languages (ADLs): What are the attributes and R-forms? Describing the architecture: Creating and Using Architectural Description Languages (ADLs): What are the attributes and R-forms? CIS 8690 Enterprise Architectures Duane Truex, 2013 Cognitive Map of 8090

More information

"Charting the Course... ITIL 2011 Operations Support Analysis (OSA) Certification Program. Course Summary

Charting the Course... ITIL 2011 Operations Support Analysis (OSA) Certification Program. Course Summary Description Course Summary ITIL is a set of best practices guidance that has become a worldwide-adopted framework for IT Service Management by many Public & Private Organizations. Since early 1990, ITIL

More information

Whole Platform Foundation. The Long Way Toward Language Oriented Programming

Whole Platform Foundation. The Long Way Toward Language Oriented Programming Whole Platform Foundation The Long Way Toward Language Oriented Programming 2008 by Riccardo Solmi made available under the Creative Commons License last updated 22 October 2008 Outline Aim: Engineering

More information

Metadata Common Vocabulary: a journey from a glossary to an ontology of statistical metadata, and back

Metadata Common Vocabulary: a journey from a glossary to an ontology of statistical metadata, and back Joint UNECE/Eurostat/OECD Work Session on Statistical Metadata (METIS) Lisbon, 11 13 March, 2009 Metadata Common Vocabulary: a journey from a glossary to an ontology of statistical metadata, and back Sérgio

More information

Corso di Biblioteche Digitali

Corso di Biblioteche Digitali Corso di Biblioteche Digitali Vittore Casarosa casarosa@isti.cnr.it tel. 050-315 3115 cell. 348-397 2168 Ricevimento dopo la lezione o per appuntamento Valutazione finale 70-75% esame orale 25-30% progetto

More information

Learning Ontology-Based User Profiles: A Semantic Approach to Personalized Web Search

Learning Ontology-Based User Profiles: A Semantic Approach to Personalized Web Search 1 / 33 Learning Ontology-Based User Profiles: A Semantic Approach to Personalized Web Search Bernd Wittefeld Supervisor Markus Löckelt 20. July 2012 2 / 33 Teaser - Google Web History http://www.google.com/history

More information

Database Optimization

Database Optimization Database Optimization June 9 2009 A brief overview of database optimization techniques for the database developer. Database optimization techniques include RDBMS query execution strategies, cost estimation,

More information

Graphical Notation for Topic Maps (GTM)

Graphical Notation for Topic Maps (GTM) Graphical Notation for Topic Maps (GTM) 2005.11.12 Jaeho Lee University of Seoul jaeho@uos.ac.kr 1 Outline 2 Motivation Requirements for GTM Goals, Scope, Constraints, and Issues Survey on existing approaches

More information

Modeling XML Vocabularies with UML: Part I

Modeling XML Vocabularies with UML: Part I Modeling XML Vocabularies with UML: Part I David Carlson, CTO Ontogenics Corp. dcarlson@ontogenics.com http://xmlmodeling.com The arrival of the W3C s XML Schema specification has evoked a variety of responses

More information

Development of an Ontology-Based Portal for Digital Archive Services

Development of an Ontology-Based Portal for Digital Archive Services Development of an Ontology-Based Portal for Digital Archive Services Ching-Long Yeh Department of Computer Science and Engineering Tatung University 40 Chungshan N. Rd. 3rd Sec. Taipei, 104, Taiwan chingyeh@cse.ttu.edu.tw

More information