UMBEL - Annex F

From UMBEL Wiki
Jump to: navigation, search
UMBEL Annex F: Mapping with UMBEL

UMBEL Annex Document - 10 May 2016

Latest version
http://techwiki.umbel.org/index.php/UMBEL_-_Annex_F
UMBEL Logo
Last update
$Date: 2016/5/10 9:22:47 $
Version
Version No.: 1.50
Volume
TR 16-5-10-F
Authors
Michael Bergman - Structured Dynamics
Frédérick Giasson - Structured Dynamics

Structured Dynamics Logo

UMBEL: Upper Mapping and Binding Exchange Layer by Structured Dynamics LLC is provided under the
Creative Commons Attribution 3.0 license. See the attribution section for how to cite the effort.

Creative Commons License

Copyright © 2009-2016 by Structured Dynamics LLC.

Beginning with UMBEL version 1.20, statistics regarding numbers of reference concepts (RCs) in the ontology and splits between SuperTypes (STs) and modules have been moved to the statistics Annex Z document. As a result, earlier statistics in this and other annexes are no longer being updated, which means any statistics cited below may be out of date. Please consult Annex Z for the current UMBEL statistics.
As of version 0.80, 'Reference Concept' (RefConcept) has replaced the notion of 'Subject Concept' (SubjectConcept). Historical documentation may still use the older term and some use is kept in current documentation for continuity reasons. Please treat the two terms as synonomous.

INTRODUCTION

UMBEL may be used for mapping to external classes and properties in ontologies or to external instances or individuals (entities or things). This annex provides details on these mapping options.

LINKING EXTERNAL CLASSES (ONTOLOGIES)

In the Annex E, we described the inferential benefits of linking external ontology classes to UMBEL reference concepts. This linkage gives us the possibility to re-use external ontology classes and properties to describe instances of reference concept classes and instances of external ontology classes.

However, to make this happen, we needed to create the linkage between these external ontology and reference concept classes. Additionally, this linkage had to be consistent with the UMBEL structure.

Tools

We have created a series of Web services to help ontology developers and maintainers to link external classes to reference concept classes. These Web services help find possible related reference concepts, view their relationship with other external ontologies, and infer facts to validate the consistency of the UMBEL structure when creating a new linkage.

The series of UMBEL Web services [1] are defined in three main categories:

Finding Reference Concepts

  1. Find Subject
    • This Web service is used to find UMBEL reference concepts that match a search string. This is the primary tool for finding available reference concepts.

Visualizing/Exploring Reference Concepts

  1. Reference Concept Report
    • This Web service is used to get basic information about a specific UMBEL reference concept. The information shown in the report is a definition of the reference concept and its semset related to that concept. This semset is an aggregation of different labels with similar meaning that is used in practice to designate the concept.
  2. Reference Concept Detailed Report
    • This service provides detailed information about a specific UMBEL reference concept. This user interface is a special kind of service. It uses all existing UMBEL Web services to create a detailed report about a UMBEL reference concept and its relations to other UMBEL reference concepts, external ontology classes, and existing named entities from different kinds of data sources.
  3. Reference Concepts Explorer
    • This service is a visualization interface that lets you browse the UMBEL graph of reference concept relationships. You can navigate from one node to another by clicking any of the circles. Each circle is an UMBEL reference concept or an external ontology class.

Inferring Reference Concepts

  1. List Sub-Concepts & Sub-Classes
    • This Web service is used to get a list of more specific concepts (UMBEL reference concepts or external ontology classes) for a given UMBEL reference concept URI or an external ontology class URI.
  2. List Super-Concepts & Super-Classes
    • This Web service is used to get a list of more general concepts (UMBEL reference concepts or external ontology classes) for a given UMBEL reference concept URI or an external ontology class URI.
  3. List Equivalent External Classes
    • This Web service is used to get a list of equivalent concepts (UMBEL reference concepts or external ontology classes) for a given UMBEL reference concept URI or an external ontology class URI.
  4. Verify Sub-Class Relationship
    • This Web service is used to get a "true" or "false" answer to the question: is this UMBEL reference concept URI or external ontology class URI a sub-concept of this other UMBEL reference concept URI or external ontology class URI?
  5. Verify Super-Class Relationship
    • This Web service is used to get a "true" or "false" answer to the question: is this UMBEL reference concept URI or external ontology class URI a sub-concept of this other UMBEL reference concept URI or external ontology class URI?
  6. Verify Equivalent Class Relationship
    • This Web service is used to get a "true" or "false" answer to the question: is this UMBEL reference concept URI or external ontology class URI equivalent to this other UMBEL reference concept URI or external ontology class URI?

Method

The method consists of a series of steps to guarantee the consistency of the UMBEL structure once the linkage between an external class and a reference concept class is made. To help users to perform these steps, we will illustrate with the use of the Web services that have been described in the section above.

Step 1: Search for a related reference concept

When you try to link an external ontology class <A> to the UMBEL reference concepts structure, the first thing you have to do is to try to find a related reference concept.

To find a list of potential candidates, we suggest using the Find Subject Web service to find a list of reference concepts that can use the search label to denote the reference concept. Most of the time, we use the name of a class, and some of its synonyms, to find potential reference concept candidates. Additionally, we can use the Reference Concept Detailed Report to check the list of more general and more specific reference concepts related to the reference concepts returned by the Find Subject Web service. Inspecting this list helps refine the search for the right reference concept.

Once we have a list of such potential candidates, we have to find the right one to make the linkage.

Step 2: Find the right reference concept

To find the right reference concept class <B> to link to a class <A>, we have to determine the right relation that exists between class <A> and a given reference concept. There exists three different kind of relations, and not all have the same importance. The relationships, in order of importance, are:

  1. Equivalence relationship; owl:equivalentClass
  2. Sub-class of relationship; rdfs:subClassOf

The reference concept that shares the highest importance relationship with the class <A> will be linked to it.

To determine the relation that applies, we apply this procedure:

  • Do all individuals that belong to the reference concept class <B> also belong to the class <A>?
    • If yes, do all individuals that belong to the class <A> also belong to the reference concept class <B>?
      • If yes, then the two classes are equivalent
      • If no, then the reference concept class <B> is a sub-class of class <A>
    • If no, do all individuals of the class <A> belong to the reference concept class <B>?
      • If yes, then the class <A> is a sub-class of the reference concept class <B>
      • If no, is there a non-empty intersection between the class <A> and the reference concept class <B>?
        • If yes, then the class <A> is-about the reference concept class <B> given a certain confidence percentage value
        • If no, there is no relationship between the class <A> and the reference concept class <B>.

Additionally, we have to read the description of the class <A> and the reference concept class <B> to make sure that both classes share the same semantic meaning. This description is normally written in the documentation of the ontologies.

Once we think we have found the right reference concept class <B> to link to the class <A> (if any candidates do indeed exist), we next have to make sure that the UMBEL data model remains consistent after making the linkage.

Step 3: Analyze the relationship between the two classes

This third step is performed to make sure that the UMBEL reference concept structure remains consistent after asserting that the class <A> is related, in some way, to the reference concept class <B>.

The analysis will differ depending on the kind of relationship that exists between the class <A> and the reference concept class <B>.

This analysis is based on the OWL 2 DL description of the external ontology classes and UMBEL reference concept classes. As we noted in the Inference and Open-World Assumption section above, we can only conclude things according to what is known (so what is defined in these different ontologies).

If we state that <A> is equivalent to <B>, then the following assertions have to be true:

  1. All individuals that belong to <A> also belong to <B>
  2. All individuals that belong to <B> also belong to <A>
  3. All sub-classes of <A> have to be sub-classes of <B>
  4. All sub-classes of <B> have to be sub-classes of <A>
  5. All super-classes of <A> have to be super-classes of <B>
  6. All super-classes of <B> have to be super-classes of <A>
  7. All equivalent classes of <A> have to be equivalent classes of <B>
  8. All equivalent classes of <B> have to be equivalent classes of <A>.

If any of these assertions is false , then <A> is not equivalent to <B> and the linkage is dropped.

If we state that <A> is a sub-class of <B>, then the following assertions have to be true:

  1. All individuals that belong to <A> also belong to <B>
  2. All super-classes of <B> have to be super-classes of <A>

If any of these assertions is false, then <A> is not a sub-class of <B> and the linkage is dropped.

If we state that <A> is-aligned with <B>, then the following assertion has to be true:

  1. Individuals that belong to the intersection of <A> and <B> should not belong to any set of disjoint set of individuals with neither <A> nor <B>.

If this assertion is false, then <A> is not aligned with <B> and the linkage is dropped.

The analysis of the OWL 2 DL class definition, and the current linkage between UMBEL reference concepts and other external ontology classes, will tell us if one of these assertion is true, or false.

The critical analysis task thus determines, according to what is defined within the UMBEL reference concept structure, if these relationships are true or false.

Step 4: Make the Linkage

Once we determine which relation holds with which reference concept class, we can assert this fact in RDF, such that:

  • <A> owl:equivalentClass <B>
  • <A> rdfs:subClassOf <B>

Then the linkage is published via the UMBEL Linkage Ontology Extension, or via an external ontology definition.

See Appendix A: Listing of Linked External Ontologies for the listing of the current 12 external ontologies linked to UMBEL.

LINKING EXTERNAL ENTITIES

You may also link instances to UMBEL or the UMBEL-based domain ontologies. As used herein, instances may also refer to individuals or (named) entities.

The section Using UMBEL to Describe Things below talks about how one can use UMBEL reference concepts to describe things on the semantic Web. In this section we are interested in how UMBEL defines dictionaries of named entities and how these dictionaries can be used.

Structured Dynamics uses publicly available data sources such as Wikipedia and others to create and publish UMBEL named entities dictionaries. These dictionaries are composed of UMBEL named entities (individuals belonging to UMBEL reference concept classes) and their links to numerous identities for a given named entities. This linkage is created and published by Structured Dynamics. However the same principles described in this section can be used by other organizations or individuals to create other named entities dictionaries that use their own linkage methodologies and procedures.

The Goal

The goal is to link external named entities together. The result of this linkage is to aggregate identities of a same thing together. For example, this named entity would link all the Muhammad Ali identities, described in a myriad of external data sources, together:

  <http://umbel.org/umbel/ne/example/> a rc:Boxer ;
      owl:sameAs <http://www.ali.com/me/> ;
      owl:sameAs <http://dbpedia.org/resource/Muhammad_Ali> ;
      owl:sameAs <http://www.mpii.de/yago/resource/Muhammad_Ali > ;
      umbel:isLike <http://yet-another-ne.com/resource/Muhammad_Ali_junior>.
Table 1. Muhammad Ali - Linkage of Identities

The Method

Such UMBEL named entities have three main characteristics:

  1. They are individuals belonging to one or more UMBEL reference concept class(es).
  2. They are linked to individuals of external ontologies classes with the properties owl:sameAs or umbel:isLike .

Named entities created with such a procedure are published in the namespace:

http://umbel.org/umbel/ne/

Normally one named entities dictionary is created for each data source. For example, named entities that come from Wikipedia are published under this namespace:

http://umbel.org/umbel/ne/wikipedia

Also note that each named entity is mapped to a governing reference concept for ontology purposes. As noted, named entities may also have semset aliases.

ENDNOTES

  1. http://umbel.org/web-services/
Copyright © 2009-2016 by Structured Dynamics LLC.