Use of Role Classes to Define Predicate Semantics: Proposal for Semantic Web Best-Practice

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.