This article proposes a design pattern for ontologies and the Semantic Web based on the concept of formally defined Roles as a means to richly express the semantics of relationships among entities in ontologies. Roles are special types of n-ary relations, and thus the use of Roles is a subset of the Semantic Web best-practices recommendation for N-Ary Relations.
The Semantic Web relies on ontologies - formal definitions of the meaning of various concepts. For example, an ontology could define the formal meaning of the term "Person" -- specifically, that a "Person" is a "Human" that has a "First Name" and a "Last Name" and has "Legal Status," "Friends" and a "Gender" and many other attributes. Each of these attributes could be further defined specifically -- for example, "a Friend" is a different Person who is "Socially-related" to the former Person and "Has Met" that Person at least once, and "is Liked by" and "Trusted by" that Person. Each of these predicates, such as "Socially-related," "Trusted by," and "Has Met" may or may not be further defined, depending on the structure of particular ontologies.
Most simple ontologies use binary relations to express predicates that connect things together. More complex and sophisticated ontologies, such as the ones I have developed for the Radar Platform and my work with SRI and DARPA and the University of Texas Clib ontology project, instead only cast the most basic building-block predicates with object and data type relations (in OWL). Instead, most relations (including even those that could be expressed with simple object properties) are defined using special classes called Roles. This moves much of the weight of expressing how classes interconnect from properties to Role classes.
While using Roles instead of simple object properties introduces certain minor complexities -- such as the requirement to model N-ary relations, and thus Roles, such that they can be used in place of object properties to connect instances of classes -- it results in even more important benefits. In particular, a major benefit is that the use of classes to represent Role relations enables far more expressive ontologies to be developed. This method is even more expressive than the potential use of additional facets on properties. While adding special additional facets to properties is certainly one way to augment the semantics of predicates, it still is not as richly expressive as simply using Role classes instead of properties for most relations. The use of Role classes enables ontolology designers to create rich ontologies of relations, such that every relation that is modeled by a Role can be formally defined as a concept with respect to other entities and relations in the ontology. In other words, it enables a much richer semantics to be defined for the domain.
I propose that the use of Role classes to define the semantics of various types of relations among entities (including among relations themselves) should be a Semantic Web Best Practice and should be adopted in all but the most simplistic ontologies. The rest of this article explains why I believe this in more detail.
By using a formal representation of Roles and their semantics, we can create ontologies of Roles, each of which can have unique properties, such as relations to other Roles. This in turn will in the future make it easier to map between different ontologies -- unless the meaning of relations is semantically defined in as formal a manner as the meaning of classes, mapping will be quite difficult and ad-hoc.
For example, if we represent the predicate "hasFriend" using a mere object property in OWL, it is simply a string with a meaning that could be constrained somewhat by various OWL restrictions on its domain and range, cardinality, and so forth. But if instead, a Role such as "Friend of" was expressed as a class, then it could have various properties of its own, such as "distance of relationship" (in social degrees), "length of relationship" (in days), "Affinity level " - (a real number representing a measure of how much the other party is liked by the Person occupying the Role), "trust level" (a real number), "Context of first meeting" (an instance of a Person, Group, Organization, Place, Project, Meeting or other Event), etc.
Furthermore, since
"Friend of" is a Class rather than a simple property, it can be
connected to other Classes in the ontology -- for example, classes defining other related Roles. For instance,
the class "Friend of" can be made a subclass of a more general class
called "Socially Related To" which itself can be a subclass of a more
general class, "Social Role" that encompasses all roles that social
agents can inhabit. "Social Role" can itself be a subclass of the most
general "Role" class that holds the basic properties of all Roles.
So for example, we might have a portion of our ontology that looks something like this class schematic:
Thing
Agent
Living Thing
Human
Software Agent
Group
Social Group
Family Group
Group of Friends
Community
Organization
Corporation
Team
Living Thing
Human
Information Object
Document
Event
Meeting
Project
Relation
Action
Hyperlink
Role
Information Role (may only be played by Information Objects)
Publication
Deliverable
Draft
Version
Event Role (may only be played by Events)
Starting Event
Cause
Effect
Concluding Event
...
Agent Role (may only be played by Agents)
Living Thing Role (may only be played by a Living Thing)
Human Social Role (may only be played by a Human)
Friend of/has Friend
Professional Role
Manager of/Managed by
Colleague of/Colleague of
Team-mate of/Team-mate of
Familial Role
Parent of/Child of
Sibling of
Group Agent Role
....
Note: The properties of the class, Role should specify the basic semantics for binding instances of other classes to and from Roles so that they can "occupy" those Roles such that all Things have particular Role-properties so that they may be either the "Source of" or "Target of" appropriate Role instances. It should also specify additional properties that apply only to Roles and for connecting them to possible "Inverse Role," "Equivalent Roles," "Non-Equivalent Roles," "Pre-Requisite Roles," "Compatible Roles," "Incompatible Roles," etc. Thus for example we might have:
<>(Class Thing
....
isRolePlayerOf (Role)
isRoleTargetOf (Role)
...)(Class Role
...
hasRolePlayer (Thing)
hasRoleTarget (Thing)
hasInverseRole (Role)
hasEquivalentRole (Role)
hasNonEquivalentRole (Role)
isRolePlayerOf (Role)
isRoleTargetOf (Role)
hasPreRequisiteRole (Role)
hasCompatibleRole (Role)
hasIncompatibleRole (Role)
...)
Note: In the above class and properties pseudocode, Roles can in fact play other Roles and be targets of other Roles. This is an additional benefit of using Roles that enables even more expressive power in our ontology. For example, it enables us to precisely model a statement such as, "Sue is the Manager-Of the Manager-Of Joe" by making an instance, A, of the Manager Role that hasRolePlayer = Sue and hasRoleTarget = another Manager Role instance, B, that hasRolePlayer = A, and hasRoleTarget = Joe. This kind of indirection cannot be easily modeled if we simply use properties, rather than Role classes, to represent relations. While this benefit may not be important to many applications, it is useful to have from the perspective of designing a fully expressive ontology, and in particular for text-mining and reasoning applications.
The use of Roles as a design pattern is a much richer approach to modeling the world than we see in simple ontologies such as FOAF ("Friend of a Friend") in which the meaning of most predicates is not defined ontologically using classes. By adopting the above suggested design pattern ontologies can become richer, easier to develop and extend, and easier to reason on and integrate in the future. It would be easy to add a Role class to FOAF, and would make the ontology far richer.
For more detailed examples of how to model Roles, as well as a terrific Upper Ontology to build on, I would suggest looking at the latest versions of the University of Texas Clib ontology, which, by the way, is open-source and based on the principles in this article. You can view all the current builds here. In particular, I would suggest looking at the OWL version, which is a scaled-down subset of the full ontology (which is in KM, a more expressive axiomatic language). I have contributed a large number of classes and relations to this version of the CLIB so feel free to ask me questions if you would like to discuss this further. Please note that this ontology is still evolving, so if you build on it, you might want to let us know and keep up with changes by checking the builds frequently.
Comments