E-Connections of Web Ontologies

by Bernardo Cuenca Grau bernardo@mindlab.umd.edu

An E-Connection is a knowledge representation language defined as a combination of other logical formalisms. Each of the component logics has to be expressible in the Abstract Description System (ADS) framework, which includes Description Logics (and hence OWL-DL), Modal and Epistemic logics, as well as many logics of time and space. Obviously, different component logics will give rise to different combined languages, with different expressivity and computational properties.

E-Connections were originally introduced as a way to go beyond the expressivity of each of the component logics, while preserving the decidability of the reasoning services. An E-Connection language is a formalism, strictly more expressive than any of its component logics, and which is decidable, provided that each of its components is decidable. Hence, E-Connections provide a trade-off between the expressivity gained and the computational robustness of the combination.

Here, we will use E-Connections as a language for defining and instantiating combinations of OWL-DL ontologies. We will restrict ourselves to OWL-DL, since OWL-Full is beyond the Abstract Description System framework. Whenever we mention OWL , we will implicitly refer to OWL-DL.

An E-Connection is a set of ``connected'' ontologies. An E-Connected ontology typically contains information about classes, properties and their instances, as in OWL, but also about a new kind of properties, called links, which are somewhat similar in spirit to datatype properties. In OWL, the classes defined in terms of datatype properties ``combine'' information from different domains: the actual application domain of the ontology and the domain of datatypes. The coupling between datatypes and the ontology is always achieved through restrictions on datatype properties. For example, a ``retired person'' can be defined in OWL as a person whose age is greater than 65, by using a class (``Person'') in the ontology and a restriction on a datatype property ``age'' with value ``greater than 65''. Both from a logical and from a modeling perspective, the domain of the ontology and the domain of datatypes are disjoint: from a modeling perspective the (application) domain of ``persons'' is disjoint from the (application) domain of ``numbers''; from a logical perspective, in OWL the domain where classes, properties and individuals in the ontology are interpreted is disjoint from the domain of datatypes, and datatype properties are interpreted as binary relations with the first element belonging to the domain of the ontology and the second on the domain of the datatypes.

In the same vein, link properties allow to create classes in a certain ontology based on information from a different ontology, provided that the domains of the ontologies are disjoint, both from a logical and a modeling perspective. For example, a ``Graduate Student'' in an ontology about ``people'' could be defined as a student who is enrolled in at least one graduate course, by using the class ``Student'' in the people ontology and a someValuesFrom restriction on the link property ``enrolledIn'' with value ``GraduateCourse'', which would be a class in a different ontology dealing with the domain of ``academic courses''. Link properties are logically interpreted as binary relations, where the first element belongs to the ``source'' ontology and the second to the ``target ontology'' of the link property. Conceptually, a link property will be defined and used in its ``source'' ontology. For example, the link property ``enrolledIn'' would be defined as a link property in the ``people'' ontology with target ontology ``academic courses''. An E-Connected ontology, in the Semantic Web context, can be roughly described as an OWL-DL ontology, extended with the ability to define link properties and construct new classes in terms of restrictions on them.

In this tutorial, we use ``E-Connection Language'' to denote a formalism, i.e. a logic; we will use ``E-Connection'' to denote a knowledge base written in such a language. These knowledge bases are composed of a set of ``connected'' ontologies, for which we will use the term ``E-Connected ontology'' or ``component ontology''.

From a modeling perspective, each of the component ontologies in an E-Connection is modeling a different application domain, while the E-Connection itself is modelling the union of all these domains. For example, an E-Connection could be used to model all the relevant information referred to a certain university, and each of its component ontologies could model, respectively, the domain of people involved in the university, the domain of schools and departments, the domain of courses, etc.

One advantage of OWL is the availability of tools that can reason on, at least, a large fragment of the language. Since reasoning support was an important requirement in the design of OWL, it also should be a key requirement for any extension of OWL. Reasoning is a strong motivation for introducing E-Connections as a formalism for combining OWL ontologies, since we show that is is possible to define practical reasoning algorithms for such combinations as an extension of existing OWL reasoners.

Basic Elements

In order to illustrate the basic elements of an E-Connection, let us consider the following application domains, that we want to formalize: let D₁ be the domain of ``travel accomodations", D₂ the domain of ``leisure activities'', D₃ the domain of ``travel destinations'', and D ₄ the domain of ``people''. We want to use an E-Connection to model the union of these domains, i.e., the domain of ``tourism''.

We want to model each application domain in a different component of the E-Connection and then use link properties to talk about their relationships. As in OWL, each (component) ontology is written in a different file, and the vocabularies being used in each of them can be specified by a set of namespace declarations and entity definitions.

Each component ontology defines its own ontology header, and may include a collection of assertions about the ontology under an owl:Ontology tag. As in OWL, these tags may contain meta-data about the component ontologies, such as comments information about version control, and also owl:import statements. The rdf:about attribute provides a name (a URI) for each ontology. A given component ontology can import another ontology. Note that, although E-Connections can replace import statements in many situations, sometimes it makes more sense to import than to E-connect.

For our domains, we create the following root classes

(accomodations) 
<owl:Class rdf:ID="Accomodation">


(activities) 
<owl:Class rdf:ID="Activity"> 

(destinations)
<owl:Class rdf:ID="Destination"> 

(people)
<owl:Class rdf:ID="Person">

Where, in brackets, we specify the ontology each class has been defined in; we use this informal notation along this section for clarity and brevity, in order to avoid including the namespace and ontology headers of each ontology in the combination.

In SWOOP, we can create a new ontology with URI http://www.mindswap.org/dav/ontologies/destinations, by clicking on the ``New'' button. The following pop-up window will show up:

Add ontology

Then, click the Add Class button and create the class ``Destination''. The result is shown in the next image:

In order to create the remaining component ontologies and their corresponding ``top'' atomic classes, repeat the process for each of them. As a result, all the ontologies (each containing a single atomic class), should be loaded in the SWOOP workspace

Creating Link Properties

We would like to define classes like BudgetDestination (a travel destination which provides a choice of budget accomodations), a CaribbeanHotel (a hotel accomodation offered at a caribbean destination), and a SportsDestination (a destination that offers a variety of activities related to sport). In order to attain this goal, we define a set of link properties, i.e. properties that relate elements of the different application domains. For example, the links providesAccomodation and offersActivity relate the domain of ``destinations'' to the domain of ``accomodations'' and ``activities'' respectively.

(destinations)

<owl:LinkProperty rdf:ID="providesAccomodation"> 
  <owl:foreignOntology rdf:resource="&accomodations;">
  <rdfs:domain rdf:resource="#Destination"/>
  <rdfs:range>
   <owl:ForeignClass rdf:about="&accomodations;#Accomodation">
    <owl:foreignOntology rdf:resource="&accomodations;"/>
   </owl:ForeignClass>
  </rdfs:range>
</owl:LinkProperty>

(destinations)

<owl:LinkProperty rdf:ID="offersActivity"> 
  <owl:foreignOntology rdf:resource="&activities;">
  <rdfs:domain rdf:resource="#Destination"/>
  <rdfs:range>
   <owl:ForeignClass rdf:about="&activities;#Activity">
    <owl:foreignOntology rdf:resource="&activities;"/>
   </owl:ForeignClass>
  </rdfs:range>
</owl:LinkProperty>

A link property is a binary relation between instances of classes, which belong to different E-Connected ontologies. The source of a link property is the ontology in which it has been declared; the target is the ontology specified in the owl:foreignOntology tag in the declaration. The first element of the relation always belongs to an instance of a class in the source ontology. In the example, both ``providesAccomodation'' and ``offersActivity'' have been defined in the ``destinations'' ontology. The second element of the relation corresponds to an individual in the target ontology, i.e. the ``accomodations'' ontology in the case of ``providesAccomodation'' and the ``activities'' ontology in the case of ``offersActivity''.

The definition of a link property must include a single owl:foreignOntology tag. As in the case of object properties, link properties can be assigned a domain and a range. For example, the link ``offersActivity'' relates instances of the class ``Destination'' to instances of the class ``Activity''. The class specified as a range of a link property must be declared as a class in the target ontology. In the source ontology, such a class can be declared as ``foreign'' using the owl:ForeignClass tag.

In SWOOP, we can define the link properties of the example above as follows:

Select the ``destinations'' ontology in the Workspace
Click on the Add Property button
A pop up window will show up. Then, select OWLLinkProperty in the Property Type combo box
Fill the value ``providesAccomodation'' in the ID field
Add any comments you consider
Click on ``Apply''
A new PopUp will show up that allows to select the target ontology of the link property. The user can either specify the URI or select the target ontology among the ones loaded in the workspace. Since the ``accomodations'' ontology is in the workspace, select it in the combo box and click on ``Add Foreign Ontology''.

The result of these steps is shown in the following image:

Adding a link property

Defining the domain and range of link properties

Note that, in the example, the ``providesAccomodation'' property has a domain and a range, that we need to add. In order to do that, return to the ``destinations'' ontology and click again on ``providesAccomodation''. Then:

Click on ``Editable'' on top of the right pane
The possible characteristics that a link property can have will show up on the right pane. Click on ``Add'' in the ``Has Domain'' option.
A new pop up window will show up. Select the ``Destination'' class and click on ``Add&Close''
The Destinations class will now show up in the Domain position.

The result of the process is shown in the next image:

Adding domain

In order to add the range, click on Has Range: Add and select the ``Accomodation'' class in the accomodations ontology. The result, after applying all the changes, is shown in the following image

Adding a range

The blue icon shows that the ``Accomodation'' class is a foreign class in the destinations ontology. If you click on its URI, SWOOP will show the accomodations ontology. You will notice that there the ``Accomodation'' class is represented by a yellow icon, since the class is local to that ontology.

You can now repeat the whole process for the ``offersActivity'' link.

Note that a link property can be defined as functional or inverseFunctional, with the obvious meaning.

However, as opposed to object properties in OWL, a link property cannot be tagged as transitive or symmetric.

Before continuing, it is worth mentioning that any entity in SWOOP, including link properties, can be displayed and edited using a renderer other than the Concise Format renderer. For example, if after completing the above steps you click on the ``abstract syntax'' and ``RDF/XML'' tags, you will see the abstract syntax and the RDF/XML definition of the entity respectively.

Restrictions on Link Properties

Restrictions on link properties can be used to generate new classes in each of the component ontologies, in the same way as OWL provides the ability to define restrictions on datatype properties. For example, we can define a ``budget destination'' as a travel destination that offers at least one kind of budget accomodation:

(destinations) 
<owl:Class rdf:ID="BudgetDestination"> 
 <owl:intersectionOf rdf:parseType="Collection"> 
  <owl:Class rdf:about="#Destination"> 
   <owl:Restriction >
   <owl:onProperty rdf:resource="#providesAccomodation"/>
    <owl:someValuesFrom >
      <owl:ForeignClass rdf:about="&accomodation;BudgetAccomodation" > <
        <owl:foreignOntology rdf:resource="&accomodation;"/>
      </owl:ForeignClass >
    </owl:someValuesFrom >
   </owl:Restriction >
 </owl:intersectionOf>
</owl:Class>

In SWOOP the class ``budget destination'' is created as follows:

Select the accomodations ontology
Create the atomic class ``BudgetAccomodation'' as a subClass of ``Accomodation''
Select the destinations ontology.
Create the atomic class ``BudgetDestination'' as a subClass of ``Destination'' (or as a subClass of owl:Thing)
Click on ``intersection Of, Add'' on the right pane
Select the class ``Destination''
Click again on ``intersectionOf, Add''
Select ``Restriction'' in the pop up window
Select the providesAccomodation link property, the someValuesFrom restriction type and the class ``BudgetAccomodation''
Add and apply the changes

The result is shown in the following image:

Adding restriction on link

Usign an ``allValuesFrom'' restriction we can define a ``fanatic cinema lover'' as a person that only enjoys leisure activities related to cinema:

(people)
<owl:Class rdf:ID="FanaticCinemaLover">
 <rdfs:subClassOf>
   <owl:Class rdf:about="#Person"/>
 </rdfs:subClassOf> 
 <rdfs:subClassOf>
   <owl:Restriction>
     <owl:onProperty rdf:resource="#likesActivity"/>
     <owl:allValuesFrom>
       <owl:ForeignClass rdf:about="&activities;CinemaActivity">             
         <owl:foreignOntology rdf:resource="&activities;"/>         
       </owl:ForeignClass>
      </owl:allValuesFrom>
   </owl:Restriction>
 </rdfs:subclassOf>
 </owl:Class>d

Where in the ``activities'' ontology we would define the class ``CinemaActivity'' as a subclass of activity:

(activities) 

  <owl:Class rdf:ID="CinemaActivity">
    <rdfs:subClassOf>
      <owl:Class rdf:about="#Activity"/>
     </rdfs:subClassOf> 
  </owl:Class>

In SWOOP theses classes can be created using a similar sequence of steps as in the case of the class ``BudgetDestination'':

Select the activities ontology and create the class ``CinemaActivity'' as a subclass of ``Activity''
Select the people ontology
Create the link property ``likesActivity'' with target ontology activities
Create the atomic class ``FanaticCinemaLover''
Define it as the intersection of ``Person'' and the allValues restriction on the ``likesActivity'' link property.

The result is shown in the following image:
Adding a forall restriction

Cardinality restrictions on links allow to constrain the number of objects linked by the connecting relations. For instance, we can define a ``SportsDestination'' as a travel destination that offers more than 10 different sports activities:

(destinations)

 <owl:Class rdf:ID = "SportsDestination">
   <rdfs:subClassOf>
      <owl:Class rdf:about="#Destination"/>
   </rdfs:subClassOf> 
   <rdfs:subClassOf>
      <owl:Restriction>
        <owl:onProperty rdf:resource = "offersSportActivity"/>
        <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">10       
        </owl:minCardinality>  
      </owl:Restriction> 
   </rdfs:subClassOf>
 </owl:Class>

In order to create this class in SWOOP:

Select the destinations ontology in the Workspace
Create a new link property ``offersSportActivity'', with target the activities ontology
Create the atomic class ``SportsDestination'' as a subclass of ``Destination''
Click on Subclass Of: Add
Select ``Restriction'', select the ``offersSportActivity'' link property and the ``minCardinality'' restriction type.
Type 10 in the ``Specify integer'' field, and click on ``Add&Close''

Adding a number restriction

The ``hasValue'' restriction on link allows to specify classes in an E-Connected ontology based on the existence of a particular individual in a different ontology. For example, we can define the class ``Surfing destination'' as a travel destination that offers ``surfing'' as one of their activities, where ``surfing'' is an instance of the class ``SportsActivity''

(destinations)
 <owl:Class rdf:ID = "SurfingDestination">
   <rdfs:subClassOf>
      <owl:Class rdf:about="#Destination"/>
   </rdfs:subClassOf> 
   <rdfs:subClassOf>
      <owl:Restriction>
        <owl:onProperty rdf:resource = "offersSportActivity"/>
        <owl:hasValue>          
           <owl:ForeignIndividual rdf:about="&activities;surfing">             
             <owl:foreignOntology rdf:resource="&activities;"/>
           </owl:ForeignIndividual>
        </owl:hasValue>  
      </owl:Restriction>  
   </rdfs:subClassOf> 
 </owl:Class>

Where in the ``activities'' ontology ``surfing'' is defined to be an individual

(activities)

 <owl:Thing rdf:ID="surfing"/>

In order to create the ``SurfingDestination'' class in SWOOP:

Select the activities ontology
Click on Add individual and add ``surfing''
Select the destinations ontology and create the atomic class ``Surfing Destination'' as a subclass of ``Destination''
Click on SubClass Of Add
Select ``Restriction'' in the popup window, and then select the property ``offersSportActivity'' and the restriction type ``hasValue''
Select ``surfing''

Adding a hasValue rest

Link Property Characteristics

Analogously to Object and Datatype properties in OWL, it is possible to add special features to the definition of link properties.

Link Inversion

A link can be defined as the inverse of another link. For example, link inversion would allow us to define a WaterSport activity a Sports Activity that is offered at a beach destination:

(activities)
 <owl:Class rdf:ID="WaterSport">
    <rdfs:subClassOf>
      <owl:Class rdf:about="#Sport"/>
     </rdfs:subClassOf> 
     <rdfs:subClassOf>
        <owl:Restriction>         
          <owl:onProperty rdf:resource="#isOfferedAt"/>               
             <owl:someValuesFrom>             
               <owl:ForeignClass rdf:about="&destinations;BeachDestination">             
                 <owl:foreignOntology rdf:resource="&destinations;"/>          
               </owl:ForeignClass>   
             </owl:someValuesFrom>
        </owl:Restriction>
    </rdfs:subclassOf>
  </owl:Class>


(activities)
   <owl:LinkProperty rdf:ID="isOfferedAt">
     <owl:foreignOntology rdf:resource="&destinations;"/>
     <owl:inverseOf rdf:resource="&destinations;offersActivity"/> 
    </owl:LinkProperty>

Where ``isofferedAt'' is a link property is defined as the inverse of ``offersActivity'' .

In SWOOP:

Select the activities ontology
Create a new link property ``isOfferedAt'' with target ontology destinations
Click on inverse Of Add
Select the ``offersActivity'' link property in destinations, click on ``Add&Close'' and delete the changes
Select the destinations ontology
Create an atomic class ``BeachDestination'' as a subClass of ``Destination''
Select again the activities ontology
Create the atomic class `Sport'' as a subClass of ``Activity'' and ``WaterSport'' as a subClass of ``Sport''
Select SubClass Of Add and add a someValuesFrom restriction on ``isOfferedAt'' on the class ``BeachDestination''.

After adding definining ``isOfferedAt'' as the inverse of ``offersActivity'', we obtain the following in SWOOP:

Adding an inverse

After defining the class ``WaterSportActivity'' we obtain the following in SWOOP:

restrictions on inverses

Functional Link Properties

Inverse Functional Link Properties

Defining Link Hierarchies

A link may be defined as a sub-property of another link. For example, we can define the link ``offersSportActivity'' as a sub-property of ``offersActivity'':

(destinations)
   <owl:LinkProperty rdf:ID="offersSportActivity">
    <owl:foreignOntology rdf:resource="&activities;"/>
    <rdfs:subPropertyOf rdf:about="#offersActivity"/> 
   </owl:LinkProperty>

In SWOOP:

Select the destinations ontology
Select ``offersSportActivity''
Click on Subproperty Of: Add
Select the link ``offersActivity''

link hierarhies

Obviously, a link cannot be declared as a sub-property of an object or datatype property; on the other hand, if a link is declared as a sub-property of a link with a different foreign ontology, the E-Connected knowledge base would be unsatisfiable, due to the semantics of the links and the disjointness of domains.

Axioms and Facts in E-Connected Ontologies

An E-Connected ontology is a sequence of axioms and facts: logical sentences that allow to make assertions about the domain. For example, as in OWL, we can use an axiom to assert that ``Graduate Student'' is a subclass of ``Student'' and a fact to state that ``john'' is ``enrolled in'' the ``Web technologies'' course. In E-Connected ontologies it is also possible to use a fact to instantiate a link property. For example, we can assert that ``SaintThomasIsland'' is an instance of ``CaribbeanDestination'' and that it offers the ``surfing'' activity:

(destinations)
 <rdf:Description rdf:about="#SaintThomasIsland">
  <rdf:type>
    <owl:Class rdf:about="#CaribbeanDestination"/>
  </rdf:type>
 <offersActivity>
    <owl:ForeignIndividual rdf:about="&activities;#surfing">
      <owl:foreignOntology rdf:resource="&activities;"/>
    </owl:ForeignIndividual>
</offersActivity>
</rdf:Description>

In SWOOP:

Select the destinations ontology
Create the atomic class ``Caribbean Destination" as a subClass of ``BeachDestination''
Create a new individual ``saintThomasIsland'' as an instance of ``Caribbean Destination''
In the Uninitialized Properties section on the right pane and click of ``Add Value'' for ``offersSportActivity''
Select the individual ``surfing'' in the PopUp. Click on ``Add&Close''
Apply the changes

instantiating a link

The E-Connections framework imposes some restrictions to axioms and facts. For example, a class shouldn't be declared in an ontology as a subclass of a class declared in a foreign ontology in the combination. An ontology containing such an axiom would be unsatisfiable, since the domains in which those classes are interpreted are disjoint, and hence the classes wouldn't share any instance.

For similar reasons, a property (object, datatype or link) shouldn't be declared as sub-relation of a property in a foreign ontology; an individual cannot be declared as an instance of a foreign class, and a pair of individuals cannot instantiate a foreign property.

The E-Connections framework imposes some restrictions in the use of URIs. In OWL-DL, a URI cannot be used, for example, both as a class and a datatype, or as an object property and a datatype property. In an E-Connected ontology, a set of additional restrictions must be imposed, namely a URI cannot be used ``locally'' in two different component ontologies

What is an E-Connection in a Semantic Web context?

An E-Connection is a set of E-Connected ontologies. However, this definition can be ambiguous, since it may not be apparent at first sight to which set we are referring to.

For example, let us consider again the ``tourism'' domain. At first sight, one would say that we have a single E-Connection, namely, the one composed by the ontologies: destinations, activities, accomodations, people. However, this is not strictly correct.

Suppose that the ``people'' ontology contains an explicit contradiction. Assume we load the ``accomodations'' ontology in a reasoner and try to check its consistency; what should the reasoner do? The ``accomodations'' ontology contains no link property declarations, i.e., it is an ``ordinary'' OWL ontology. In this case, an E-Connections aware reasoner should only check the consistency of that ontology, and ignore the rest, i.e., it shouldn't report the inconsistency in the ``people'' ontology.

Given an E-Connected ontology, a reasoner should consider only all the E-Connected ontologies in its transitive closureunder link references. For example, the ``destinations'' ontology defines a link property providesAccomodation to the ``accomodations'' ontology and a link offersActivity to the ``activities'' ontology. Since ``accomodations'' does not contain any link property (it is an ordinary OWL ontology) and ``activities'' only includes the link isOfferedAt to ``destinations'' again, the reasoner would consider the following set of E-Connected ontologies:

K _destinations = {destinations, accomodations, activities}

We say that K Destinations is the E-Connection induced by the destinations ontology. Also:

K _{accomodations} = { accomodations}

K _activities = {activities, destinations, accomodations}

K _people = {people, destinations, accomodations, activities}

An OWL ontology O can be seen as an E-Connected ontology which induces an E-Connection with O as its only component. In our example, if you select the
accomodation ontology in the SWOOP workspace you will notice that the right pane now displays information about the ontology:

<>
You will notice that the accomodations ontology is an ordinary OWL ontology; in other words, there remains no ``trace'' of the E-Connection. If you now change the combo box on the class tree from ``RDFS'' to ``Pellet'', disable the ``Editable'' mode and click on the ``Species Validation'', SWOOP shows on the right pane the OWL species in which the ontology has bee written (OWL-Lite in our case) as well as the underlying Description Logic. In this case, the ontology is very simple and its corresponding logic is just AL.

Now, click on the activities ontology, click on the ``Species Validation'' tab and turn Pellet on. On the right pane, the expressivity of the Econnection is shown:

Expressivity of an Econnection

In brackets the expressivity of each of the component ontologies is shown. In this case, the E-Connection is composed of the following ontologies:

K _activities = {activities, destinations, accomodations}

All of them are written in the Description Logic ALC. After the closing bracket, SWOOP displays the expressivity used in the links. In this case, inverses, number restrictions on link properties and link hierarchies are defined.

If you click on the people ontology, then the following is displayed:

A larger Econnection

Now, the Econnection is composed of four ontologies, instead of 3.