14.3 Ontologies and Knowledge Sharing 14.3.1 Uniform Resource Identifiers 14.3.3 Top-Level Ontologies

The third edition of Artificial Intelligence: foundations of computational agents, Cambridge University Press, 2023 is now available (including full text).

14.3.2 Description Logic

Modern ontology languages such as OWL are based on description logics. A description logic is used to describe classes, properties, and individuals. One of the main ideas behind a description logic is to separate

•

a terminological knowledge base (or TBox) describes the terminology; it defines what the symbols mean
•

an assertional knowledge base (or ABox) specifies what is true at some point in time.

Usually, the terminological knowledge base is defined at the design time of the system and defines the ontology, and it only changes as the meaning of the vocabulary changes, which should be relatively rarely. The assertional knowledge base usually contains the knowledge that is situation specific and is only known at run time.

It is typical to use triples to define the assertional knowledge base and a language such as OWL to define the terminological knowledge base.

The web ontology language (OWL) describes domains in terms of

•

Individuals are things in the world that is being described (e.g., a particular house or a particular booking may be individuals).
•

Classes are sets of individuals. A class is the set of all real or potential things that would be in that class. For example, the class “House” may be the set of all things that would be classified as a house, not just those houses that exist in the domain of interest.
•

Properties are used to describe individuals. A datatype property has values that are primitive data types, such as integers or strings. For example, “streetName” may be a datatype property between a street and string. An object property has values that are other individuals. For example, “nextTo” may be a property between two houses, and “onStreet” may be a property between a house and a street.

OWL comes in a few variants that differ in restrictions imposed on the classes and properties, and how efficiently they can be implemented. For example, in OWL-DL a class cannot be an individual or a property, and a property is not an individual. In OWL-Full, the categories of individuals, properties, and classes are not necessarily disjoint. OWL-DL comes in three profiles that are targeted towards particular applications, and do not allow constructs they do not need that would make inference slower. OWL 2 EL is designed for large biohealth ontologies, allowing rich structural descriptions. OWL 2 QL is designed to be the front end of database query languages. OWL 2 RL is a language that is designed for cases where rules are important.

OWL does not make the unique names assumption; two names do not necessarily denote different individuals or different classes. It also does not make the complete knowledge assumption; it does not assume that all the relevant facts have been stated.

$C_{k}$ are classes, $P_{k}$ are properties, $I_{k}$ are individuals, and $n$ is an integer. $\#S$ is the number of elements in set $S$ .

Class	Class Contains
owl:Thing	all individuals
owl:Nothing	no individuals (empty set)
owl:ObjectIntersectionOf $(C_{1},\dots,C_{k})$	individuals in $C_{1}\cap\dots\cap C_{k}$
owl:ObjectUnionOf $(C_{1},\dots,C_{k})$	individuals in $C_{1}\cup\dots\cup C_{k}$
owl:ObjectComplementOf $(C)$	the individuals not in $C$
owl:ObjectOneOf $(I_{1},\dots,I_{k})$	$I_{1},\dots,I_{k}$
owl:ObjectHasValue $(P,I)$	individuals with value $I$ on property $P$ , i.e., $\{x:x~{}P~{}I\}$
owl:ObjectAllValuesFrom $(P,C)$	individuals with all values in $C$ on property $P$ ; i.e., $\{x:x~{}P~{}y\rightarrow y\in C\}$
owl:ObjectSomeValuesFrom $(P,C)$	individuals with some values in $C$ on property $P$ ; i.e., $\{x:\exists y\in C\mbox{ such that }x~{}P~{}y\}$
owl:ObjectMinCardinality $(n,P,C)$	individuals $x$ with at least $n$ individuals of class $C$ related to $x$ by $P$ , i.e., $\{x:\#\{y:xPy\mbox{ and }y\in C\}\geq n\}$
owl:ObjectMaxCardinality $(n,P,C)$	individuals $x$ with at most $n$ individuals of class $C$ related to $x$ by $P$ , i.e., $\{x:\#\{y:xPy\mbox{ and }y\in C\}\leq n\}$
owl:ObjectHasSelf $(P)$	individuals $x$ such that $x P x$ .

Figure 14.4: Some OWL built-in classes and class constructors

OWL has the following predicates with a fixed interpretation, where $C_{k}$ are classes, $P_{k}$ are properties, and $I_{k}$ are individuals; $x$ and $y$ are universally quantified variables.

Statement	Meaning
rdf:type $(I,C)$	$I\in C$
owl:ClassAssertion $(C,I)$	$I\in C$
rdfs:subClassOf $(C_{1},C_{2})$	$C_{1}\subseteq C_{2}$
owl:SubClassOf $(C_{1},C_{2})$	$C_{1}\subseteq C_{2}$
rdfs:domain $(P,C)$	if $x P y$ then $x\in C$
owl:ObjectPropertyDomain $(P,C)$	if $x P y$ then $x\in C$
rdfs:range $(P,C)$	if $x P y$ then $y\in C$
owl:ObjectPropertyRange $(P,C)$	if $x P y$ then $y\in C$
owl:EquivalentClasses $(C_{1},C_{2},\dots,C_{k})$	$C_{i}\equiv C_{j}$ for all $i, j$
owl:DisjointClasses $(C_{1},C_{2},\dots,C_{k})$	$C_{i}\cap C_{j}=\{\}$ for all $i\neq j$
rdfs:subPropertyOf $(P_{1},P_{2})$	$xP_{1}y$ implies $xP_{2}y$
owl:EquivalentObjectProperties $(P_{1},P_{2})$	$xP_{1}y$ if and only if $xP_{2}y$
owl:DisjointObjectProperties $(P_{1},P_{2})$	$xP_{1}y$ implies not $xP_{2}y$
owl:InverseObjectProperties $(P_{1},P_{2})$	$xP_{1}y$ if and only if $yP_{2}x$
owl:SameIndividual $(I_{1},\dots,I_{n})$	$\forall j\forall k~{}I_{j}=I_{k}$
owl:DifferentIndividuals $(I_{1},\dots,I_{n})$	$\forall j\forall k~{}j\neq k$ implies $I_{j}\neq I_{k}$
owl:FunctionalObjectProperty $(P)$	$\mbox{ if }xPy_{1}\mbox{ and }xPy_{2}\mbox{ then }y_{1}=y_{2}$
owl:InverseFunctionalObjectProperty $(P)$	$\mbox{ if }x_{1}Py\mbox{ and }x_{2}Py\mbox{ then }x_{1}=x_{2}$
owl:TransitiveObjectProperty $(P)$	$\mbox{ if }xPy\mbox{ and }yPz\mbox{ then }xPz$
owl:SymmetricObjectProperty	$\mbox{ if }xPy\mbox{ then }yPx$
owl:AsymmetricObjectProperty $(P)$	$x P y$ implies not $y P x$
owl:ReflectiveObjectProperty $(P)$	$x P x$ for all $x$
owl:IrreflectiveObjectProperty $(P)$	not $x P x$ for all $x$

Figure 14.5: Some RDF, RDF-S, and OWL built-in predicates

Figure 14.4 gives some primitive classes and some class constructors. This figure uses set notation to define the set of individuals in a class. Figure 14.5 gives primitive predicates of OWL. The owl: prefixes are from OWL.

In these figures, $x P y$ is a triple. Note that this is meant to define the meaning of the predicates, rather than any syntax. The predicates can be used with different syntaxes, such as XML, Turtle (a simple language of triples), or functional notation. Here we use the OWL functional-style syntax where the arguments of the constructors are written in parentheses, separated with spaces.

Example 14.13.

As an example of a class constructor in OWL functional syntax:

ObjectHasValue(lc:has_logo lc:lemon_icon)

is the class of objects for which the individual lc:lemon_icon is a value for the property lc:has_logo.

ObjectSomeValuesFrom(lc:has_color lc:green)

is the class of all objects that have some green. That is the objects for which some of the colors of the object are green. Here lc:green is assumed to be a class of more specific colors such as emerald or forest-green.

MinCardinality(2 :owns :building)

is the class of all individuals who own two or more buildings. That is, the set $\{x:\exists i_{1}\exists i_{2}~{}building(i_{1})\land building(i_{2})\land~{}x% ~{}\mbox{{:owns}}~{}i_{1}\land x~{}\mbox{{:owns}}~{}i_{2}\land i_{1}\neq i_{2}\}$ .

The class constructors must be used in a statement, for example, to say that some individual is a member of this class or to say that one class is equivalent to some other class.

OWL does not have definite clauses. To say that all of the elements of a set $S$ have value $v$ for a predicate $p$ , we say that $S$ is a subset of the set of all things with value $v$ for predicate $p$ .

Prefix(lc:=<http://artint.info/ontologies/lemon_computers.owl#>)
Ontology(<http://artint.info/ontologies/lemon_computers.owl>

Declaration(Class(lc:computer))
Declaration(Class(lc:logo))
ClassAssertion(lc:logo lc:lemon_icon)
Declaration(ObjectProperty(lc:has_logo))
ObjectPropertyDomain(lc:has_logo lc:computer)
ObjectPropertyRange(lc:has_logo lc:logo)

Declaration(Class(lc:lemon_computer))
SubClassOf(lc:lemon_computer lc:computer)
SubClassOf(lc:lemon_computer
           ObjectHasValue(lc:has_logo lc:lemon_icon))

Declaration(Class(lc:color))
Declaration(Class(lc:green))
Declaration(Class(lc:yellow))
SubClassOf(lc:green lc:color)
SubClassOf(lc:yellow lc:color)
Declaration(Class(lc:material_entity))
SubClassOf(lc:computer lc:material_entity)
ObjectPropertyDomain(lc:has_color lc:material_entity)
ObjectPropertyRange(lc:has_color lc:color)
SubClassOf(lc:lemon_computer
           ObjectSomeValuesFrom(lc:has_color lc:green))
SubClassOf(lc:lemon_computer
           ObjectSomeValuesFrom(lc:has_color lc:yellow))
)

Figure 14.6: OWL functional syntax representation of Example 14.14

Example 14.14.

Figure 14.6 shows a representation of (part of) Figure 14.2.

The first line defines “lc:” to be an abbreviation. Thus lc:computer is an abbreviation for the URI

\left<\mbox{{http://artint.info/ontologies/lemon\_computers.owl\#computer}}\right>

The second line defines which ontology this is (the parenthesis ends at the last line).

lc:computer and lc:logo are both classes. lc:lemon_icon is a member of the class lc:logo. lc:has_logo is a property, with domain lc:computer and range lc:logo.

To state that all Lemon computers have a lemon icon as a logo, you say that the set of Lemon computers is a subset of the set of all things for which the property $has\_logo$ has value $lemon\_icon$ . The ontology specifies lc:lemon_computer is a subclass of lc:computer and a subclass of the set of individuals that have value lc:lemon_icon for the property lc:has_logo. That is, all Lemon computers have a lemon icon as a logo.

Green and yellow are subclasses of color. The property $has\_color$ applies to material entities, which are physical objects. Some of the colors of a Lemon computer are yellow and some are green.

Some of OWL and RDF or RDFS statementshave the same meaning. For example, rdf:type $(I,C)$ means the same as owl:ClassAssertion $(C,I)$ , and rdfs:domain means the same as owl:ObjectPropertyDomain for object properties. Some ontologies use both definitions, because the ontologies were developed over long periods of time, with contributors who adopted different conventions.

There is one property constructor in OWL, owl:ObjectInverseOf $(P)$ , which is the inverse property of $P$ ; that is, it is the property $P^{-1}$ such that $yP^{-1}x$ if and only if $x P y$ . Note that it is only applicable to object properties; datatype properties do not have inverses, because data types cannot be the subject of a triple.

The list of classes and statements in these figures is not complete. There are corresponding datatype classes for datatype properties, where appropriate. For example, owl:DataSomeValuesFrom and owl:EquivalentDataProperties have the same definitions as the corresponding object symbols, but are for datatype properties. There are also other constructs in OWL to define properties, comments, annotations, versioning, and importing other ontologies.

Example 14.15.

Consider an Aristotelian definition of an apartment building. We can say that an apartment building is a residential building with multiple units and the units are rented. (This is in contrast to a condominium building, where the units are individually sold, or a house, where there is only one unit.) Suppose we have the class $R e s i d e n t i a l B u i l d i n g$ that is a subclass of $B u i l d i n g$ .

The following defines the functional object property $n u m b e r O f U n i t s$ , with domain $R e s i d e n t i a l B u i l d i n g$ and range $\{one,two,moreThanTwo\}$ .

Declaration(ObjectProperty(:numberOfunits))
FunctionalObjectProperty(:numberOfunits)
ObjectPropertyDomain(:numberOfunits :ResidentialBuilding)
ObjectPropertyRange(:numberOfunits
                    ObjectOneOf(:two :one :moreThanTwo))

The functional object property $o w n e r s h i p$ with domain $R e s i d e n t i a l B u i l d i n g$ , and range $\{rental,ownerOccupied,coop\}$ can be defined similarly.

An apartment building is a $R e s i d e n t i a l B u i l d i n g$ where the $n u m b e r O f U n i t s$ property has the value $m o r e T h a n T w o$ and the $o w n e r s h i p$ property has the value $r e n t a l$ . To specify this in OWL, we define the class of things that have value $m o r e T h a n T w o$ for the property $n u m b e r O f U n i t s$ , the class of things that have value $r e n t a l$ for the property $o w n e r s h i p$ , and say that $A p a r t m e n t B u i l d i n g$ is equivalent to the intersection of these classes. In OWL functional syntax, this is

Declaration(Class(:ApartmentBuilding))
EquivalentClasses(:ApartmentBuilding
    ObjectIntersectionOf(
        :ResidentialBuilding
        ObjectHasValue(:numberOfunits :moreThanTwo)
        ObjectHasValue(:ownership :rental)))

This definition can be used to answer questions about apartment buildings, such as the ownership and the number of units. Apartment buildings inherit all of the properties of residential buildings.

The previous example did not really define $o w n e r s h i p$ . The system has no idea what ownership actually means. Hopefully, a user will know what it means. Everyone who wants to adopt an ontology should ensure that their use of a property and a class is consistent with other users of the ontology.

A domain ontology is an ontology about a particular domain of interest. Most existing ontologies are in a narrow domain that people write for specific applications. There are some guidelines that have evolved for writing domain ontologies to enable knowledge sharing:

•

If possible, use an existing ontology. This means that your knowledge base will be able to interact with others who use the same ontology.
•

If an existing ontology does not exactly match your needs, import it and add to it. Do not start from scratch, because people who have used the existing ontology will have a difficult time also using yours, and others who want to select an ontology will have to choose one or the other. If your ontology includes and improves the other, others who want to adopt an ontology will choose yours, because their application will be able to interact with adopters of either ontology.
•

Make sure that your ontology integrates with neighboring ontologies. For example, an ontology about resorts will have to interact with ontologies about food, beaches, recreation activities, and so on. Try to make sure that it uses the same terminology for the same things.
•

Try to fit in with higher-level ontologies (see below). This will make it much easier for others to integrate their knowledge with yours.
•

If you must design a new ontology, consult widely with other potential users. This will make it most useful and most likely to be adopted.
•

Follow naming conventions. For example, call a class by the singular name of its members. For example, call a class “Resort” not “Resorts”. Resist the temptation to call it “ResortConcept” (thinking it is only the concept of a resort, not a resort; see the box). When naming classes and properties, think about how they will be used. It sounds better to say that “ $r1$ is of type Resort” than “ $r1$ is of type Resorts”, which is better than “ $r1$ is of type ResortConcept”.
•

As a last option, specify the matching between ontologies. Sometimes ontology matching has to be done when ontologies are developed independently. It is best if matching can be avoided; it makes knowledge using the ontologies much more complicated because there are multiple ways to say the same thing.

Classes and Concepts

When defining an ontology, it is tempting to name the classes concepts, because symbols represent concepts: mappings from the internal representation into the object or relations that the symbols represent.

For example, it may be tempting to call the class of unicorns “unicornConcept” because there are no unicorns, only the concept of a unicorn. However, unicorns and the concept of unicorns are very different; one is an animal and one is a subclass of knowledge. A unicorn has four legs and a horn coming out of its head. The concept of a unicorn does not have legs or horns. You would be very surprised if a unicorn appeared in a university lecture about ontologies, but you should not be surprised if the concept of a unicorn appeared. There are no instances of unicorns, but there are many instances of the concept of a unicorn. If you mean a unicorn, you should use the term “unicorn”. If you mean the concept of a unicorn, you should use “concept of a unicorn”. You should not say that a unicorn concept has four legs, because instances of knowledge do not have legs; animals, furniture and some robots have legs.

As another example, consider a tectonic plate, which is part of the Earth’s crust. The plates are millions of years old. The concept of a plate is less than a hundred years old. Someone can have the concept of a tectonic plate in their head, but they cannot have a tectonic plate in their head. It should be clear that a tectonic plate and the concept of a tectonic plate are very different things, with very different properties. You should not use “concept of a tectonic plate” when you mean “tectonic plate” and vice versa.

Calling objects concepts is a common error in building ontologies. Although you are free to call things by whatever name you want, it is only useful for knowledge sharing if other people adopt your ontology. They will not adopt it if it does not make sense to them.

OWL, when written in the OWL functional syntax, is much easier to read than when using XML. However, OWL is at a lower level than most people will want to specify or read. It is designed to be a machine-readable specification. There are many editors that let you edit OWL representation. One example is Protégé (http://protege.stanford.edu/). An ontology editor should support the following:

•

It should provide a way for people to input ontologies at the level of abstraction that makes the most sense.
•

Given a concept a user wants to use, an ontology editor should facilitate finding the terminology for that concept or determining that there is no corresponding term.
•

It should be straightforward for someone to determine the meaning of a term.
•

It should be as easy as possible to check that the ontology is correct (i.e., matches the user’s intended interpretation for the terms).
•

It should create an ontology that others can use. This means that it should use a standardized language as much as possible.

Artificial Intelligence 2E

14.3.2 Description Logic

Example 14.13.

Example 14.14.

Example 14.15.

Artificial
Intelligence 2E