3.4: Conceptual Modelling

Formally describing some aspects of the physical and social world around us for purposes of understanding and communication

Conceptual modelling is ...

... the activity of formally describing some aspects of the physical and social world around us for purposes of understanding and communication... Conceptual modelling supports structuring and inferential facilities that are psychologically grounded. After all, the descriptions that arise from conceptual modelling activities are intended to be used by humans, not machines... The adequacy of a conceptual modelling notation rests on its contribution to the construction of models of reality that promote a common understanding of that reality among their human users.

John Mylopoulos, Conceptual Modeling and Telos, 1992

Introduction

As we have stated, an ontology is a formal explicit description of concepts in a domain of discourse classes (sometimes called concepts but not here), properties (sometimes called roles or slots but not here) of each concept which describe various features and attributes of the concept, and restrictions (sometimes called facets, or role restrictions but not here) on properties .

In practical terms, by developing the conceptual model you will create structure in the set of concepts you have deemed relevant to speak about (hence, domain of discourse) for your purpose, have listed in an initial set of terms and have addresses in the competency questions. The conceptual modelling activity includes:

  • defining classes in the model and arranging the classes in a taxonomic (subclass–superclass) hierarchy;

  • defining properties of these classes;

  • describing allowed values for these properties, filling in the values for properties for instances.

Some fundamental rules in model design:

  1. There is no one single correct way to model a domain — there are always viable alternatives. The best solution almost always depends on the application that you have in mind (purpose of your model) and the extensions that you anticipate;

  2. Remember that model development is necessarily an iterative process. Your model will be extended and changed based on new insights, requirements or use in practice;

  3. Concepts in the model should be close to objects (physical or logical) and relationships in your domain of application. These are most likely to be nouns (objects) or verbs (relationships) in sentences that describe your domain.

Step 1. Define the classes and the class hierarchy

The purpose of conceptual modelling is to create structure in your set of concepts. As a first step, a basic initial structure that can be defined in your model is a taxonomical structure. A taxonomy allows us to classify things or concepts along a hierarchy,

At this stage, the concepts need to be classified into a taxonomy to define superclass-subclass hierarchy, as some nouns from the Glossary of Terms will seem to be related as types (subclasses) of other (superclasses).

Classes and taxonomy

  • A class is a concept in the domain;

  • A class represents a collection of elements with similar properties, characteristics or pattern of features that can be realized by multiple individuals;

  • Instances (also denoted as individuals, or particulars) must instantiate at least one class.

While developing the taxonomy, it is important to account for different types of taxonomic relations, i.e., how the subclasses are related to the superclasses (Horridge01):

Once you have a comprehensive list of terms, you may try to decide whether a term in the list might be a concept, an attribute/property or an instance: concepts are nouns standing on their own; attributes look more like nouns describing types of things; instances tend to refer to more individual objects (that particular apple). Furthermore, verbs will end up as relations between specific concepts. Though the initial list may not cover up all relations and classes, the model will be refined through several iterations.

  • Subclass: A concept C2 is subclass of concept C1, if and only if every instance of C2 is also instance of C1, and, C1 collects more instances than those of C2;

  • From an ontological perspective, this implies that:

    • A superclass represents a more general concept in the domain. In other words, a superclass addresses less characteristics to enforce distinction and, hence, collects more individuals that collectively show more heterogeneity / less similarity than a subclass would;

    • A subclass represents a more specific concept in the domain. In other words, a subclass adds more characteristics to differentiate along than is provided by its superclass. Consequently, a subclass collects less individuals than its superclass, and collectively those individuals show less heterogeneity / more similarity;

    • The individuals that are collected by the subclass must be collected by its superclass as well.

  • Decomposition of a superclass in its subclasses can be disjoint and/or complete, or not:

    • completeness, i.e., all subclasses together contain all individuals that are also contained by the superclass, no single individual excluded;

    • disjointness, i.e., two subclasses do not share the same individuals.

Approach

How do you decide between a superclass or subclass approach to defining the taxonomy? There are several possible approaches:

Which approach do you take: superclass or subclass? There are several possible approaches:

  • A top-down development process starts with the definition of the most general classes in the domain and a subsequent specialization of the classes.

  • A bottom-up development process starts with the definition of the most specific classes, the leaves of the hierarchy, with subsequent grouping of these classes into more general classes.

  • A combination development process is a combination of the top-down and bottom-up approaches: we define the more salient concepts first and then generalize and specialize them appropriately.

None of these three methods is inherently better than any of the others. The approach to take strongly depends on the personal view of the domain. If a developer has a systematic top-down view of the domain, then it may be easier to use the top-down approach. The combination approach is often the easiest for many ontology developers, since the concepts “in the middle” tend to be the more descriptive concepts in the domain.

One of the hardest decisions to make at this stage of modeling is when to introduce a new class as opposed to represent a distinction through introduction of property values. It is hard to navigate both an extremely nested hierarchy with too many classes, and a very flat hierarchy that has too few classes with too much information encoded in slots. There are several rules of thumb that help to decide when to introduce new classes in a hierarchy. Subclassing a class may have:

  • additional properties that the superclass does not have, or

  • restrictions different from those of the superclass, or

  • participate in different relationships than the superclasses.

Although you should not model all possible things, you have to define the ones you need for your granularity (level of detail) and scope. Guidance can be found by the competencies that are required to answer the CQ's. Be careful to stick to them to avoid misclassifications and redundancies. While doing so, take notice of variations or even inconsistencies in granularity and scope. The latter two can be added to your Definition of Done: Do all specified concepts express similar granularities? Do all specified concepts remain within the same scope of competency? Breaking the former criterion may indicate disbalance in comprehensiveness of the subject concepts, i.e., concepts that allow detail that is not necessary or, vice versa, concepts that have not been sufficiently elaborated yet. The CQ's are your friends here, since these determine the required level of competency. Breaking the latter criterion may be an indication of incompleteness or overcompleteness, or an indication of overlapping clusters of competency.

Between concepts, there will be relations that are to be described in detail by giving a name, source concept, target concept, cardinality (how many instances of a concept are related with how many of the others), inverse name (you can read from A to B, but also from B to A. Sometimes, the distinction is important).

In practice

(TBD: example)

Step 2. Define the properties of classes

The purpose of this step is to define features of concepts.

Properties describe the features of the concepts. Some of the nouns in the Glossary of Terms could be considered as properties, i.e., the terms used to describe others. Properties in a class definition describe attributes of instances of the class and relations to other instances.

Ontologists distinguish between class attributes (terms describing concepts which take their values in the class they are defined, and not inherited in the hierarchy) and instance attributes (terms describing concepts that take their values in the instance, and may be different for each instance).

For each property in the list, we must determine which class it describes. These properties become slots attached to classes. In general, there are several types of object properties that can become slots in an ontology:

  • “intrinsic” properties such as the color of an object or the flavor of a wine;

  • “extrinsic” properties such as an object’s name or the name of a wine;

  • parts, if the object is structured; these can be both physical and abstract “parts” (e.g., the courses of a meal)

  • relationships to other individuals: these are the relationships between individual members of the class and other items (e.g., the maker of a wine, representing a relationship between a wine and a winery, and the grape the wine is made from).

Tips

There is no unique way to define the properties of a concept, but there are certain tips and general guidelines:

  • Try to attach the attribute/slot to the most general class/concept that can have that property. Caveat: all subclasses of a class inherit the slot of that class.

  • Try to define type attributes (integer, string, float, . . .). If a term can have a well-defined type (integer, string, float) it is an attribute, not a concept.

  • Try to define a range, value, precision, related classes and other data that might be useful

Most importantly, you should remain flexible and open-minded: some classes might end up being attributes to describe the different classes and/or instances.

In practice: determine existence dependency between objects

When the relevant objects (post-its) for the iteration are selected, it is time to define the relations between the objects. The relations identified between objects can be physically drawn on a whiteboard or can be connected using tape. A good way of relating objects is by explicitly stating the existence dependency between objects. E.g. ask the following questions:

  • Can an order exist without a customer?

  • Can a customer exist without an order?

Answering these questions results in a first graph with the most important objects being linked. As an addition, answering these questions can directly be used to specify cardinalities. E.g., an order belongs to exactly one customer, but a customer can have one or more orders.

Step 3. Define the restrictions of the properties

The purpose of this step is to scope (limit) the possible interpretations that are allowed by the ontology.

Properties can have different type of restrictions:

  • Slot cardinality defines how many values a property can have. Some systems distinguish only between single cardinality (allowing at most one value) and multiple cardinality (allowing any number of values).

  • A value-type restriction describes what types of values can fill in the property (e.g. string, Number, Boolean, ..).

  • Allowed values provide a restriction on the values that can fill in the property.

  • Domain (the classes to which a property is attached) and range (allowed classes for properties of type Instance).

A useful understanding on the use of OWL restrictions can be found here.

In practice

(TBD: example)

Step 4. Create instances

Purpose: define the most specific concepts in the model.

An instance is an individual of a class: you can describe in detail relevant instances that may appear by giving them a name, a concept to which they are related, attribute names and values.

Defining an individual instance of a class requires:

  1. choosing a class

  2. creating an individual instance of that class

  3. filling in the property values.

Some guidelines:

  • The class becomes a direct type of the instance.

  • If concepts form a natural hierarchy, then we should represent them as classes.

  • Individual instances are the most specific concepts rep[resented in the knowledge base.

  • Assign property values for the instances.

(TBD: how to differentiate between subclasses and instances)

Last updated