Proposal for a "Standardized Topic Map Constraint Language (sTMCL)"

H. Holger Rath, DIN, Germany\
Version 1.01, 2001-05-24

ISO Topic Maps offer flexible and powerful techniques for knowledge
representation. It defines the general concepts and provide -- with
intention -- just the necessary semantics. This document explains why
the semantics standardized in ISO/IEC 13250:2000 should be extended by a
"Topic Map Constraint Language" (TMCL) and how it could be done.

# Introduction

Knowledge representation (KR) is already well understood by Artificial
Intelligence (AI) research. Concepts like Semantic Networks or
Conceptual Graphs were developed to model knowledge. The general
approach of the topic map paradigm defines already the basic constructs
for KR with topic maps. But supporting this particular application
domain was not in the design goal of the topic map standardization.
Therefore the specifically needed semantics have to be defined e.g., as
a kind of application profile.

## A simple KR example

KR will be a key issue in enterprise knowledge management applications.
Thus, the example used throughout this chapter comes from this
application domain.

The scenario is as follows: A company runs a couple of projects which
are ordered by customers. The employees of the company having skills in
some technologies are the project team members of which one is the
project manager. Every projects uses a couple a technologies e.g.,
products or standards.

Just using the standardized concepts the topic map could look like this:

+-----------------------------------------------------------------------+
| -   **Topic classes (all defined as topics):** company, employee,     |
|     customer, project, technology, product, standard                  |
|                                                                       |
| -   **Association classes and their roles (all defined as topics):**  |
|                                                                       |
| -   ownership (owner, company)                                        |
|                                                                       |
| -   employment (company, employee)                                    |
|                                                                       |
| -   personal skill (employee, technology)                             |
|                                                                       |
| -   project membership (project, team member)                         |
|                                                                       |
| -   project leadership (project, project manager)                     |
|                                                                       |
| -   project technology (project, technology)                          |
|                                                                       |
| -   project customer (project, customer)                              |
|                                                                       |
| -   company customer (company, customer)                              |
|                                                                       |
| -   **Occurrence classes (all defined as topics):** business plan,    |
|     contract, CV, project plan, status report, product description,   |
|     standard text                                                     |
|                                                                       |
| -   **Topic instances and their classes:** Bertelsmann Mohn Media     |
|     (company), empolis (company), eCOM (company), Peter (employee),   |
|     Mike (employee), Marisa (employee), WK (customer), LEX (project), |
|     LLM (project), SL (product), SGML (standard)                      |
|                                                                       |
| -   **Association instances, their classes and roles:**               |
|                                                                       |
| -   ownership: Bertelsmann Mohn Media (owner), empolis (company)      |
|                                                                       |
| -   ownership: empolis (owner), eCOM (company)                        |
|                                                                       |
| -   employment: eCOM (company), Peter (employee), Mike (employee),    |
|     Marisa (employee)                                                 |
|                                                                       |
| -   personal skill: Peter (employee), SGML (technology), SL           |
|     (technology)                                                      |
|                                                                       |
| -   personal skill: Mike (employee), SL (technology)                  |
|                                                                       |
| -   personal skill: Marisa (employee), SGML (technology)              |
|                                                                       |
| -   project membership: LEX (project), Peter (team member), Mike      |
|     (team member)                                                     |
|                                                                       |
| -   project leadership: LEX (project), Peter (project manager)        |
|                                                                       |
| -   project technology: LEX (project), SL (technology), SGML          |
|     (technology)                                                      |
|                                                                       |
| -   project customer: LEX (project), WK (customer)                    |
|                                                                       |
| -   project customer: LLM (project), WK (customer)                    |
|                                                                       |
| -   company customer: eCOM (company), WK (customer)                   |
+-----------------------------------------------------------------------+

The next sections will discuss the various drawbacks of this modeling
approach and present solutions for them.

## The missing pieces 

-   *Topic map templates*: the ontology part of a map.

-   *Constraints*: constraining conditions supporting guided editing and
    semantic validation of topic maps.

The sum of the listed concepts results in a *topic map schema*. The
schema itself can be expressed as a topic map. Thus, the "schema" map
controls the "real" map and defines the necessary semantic needed by
topic map tools. This chapter presents a solution and gives examples for
every conceptual part of the schema. All concepts rely on the use of
somehow standardized *Published Subject Indicators* (*PSI*).

# Topic map templates

Most of the "objects" declaring a topic map ontology are topics; namely
scoping topics, classes (topics, occurrence, associations are instances
of), and roles (topics play in an association).

  -----------------------------------------------------------------------
  **The ontology topics of our example:** company, employee, customer,
  project, technology, product, standard, ownership, owner, employment,
  personal skill, project membership, team member, project leadership,
  project manager, project technology, project customer.

  -----------------------------------------------------------------------

ISO/IEC 13250:2000 does not provide a mechanism to identify the list of
ontology "objects" of a map before they have been referenced by
instances -- and this can lead to some confusion: Users often mix up
"ontology" topics and "regular" topics during discussions. In addition
to that, the different tasks of topic map design, creation, and
maintenance are hard to distinguish and to separate.

The same is true for the control of user access rights: As long there is
no distinction, different rights cannot be assigned to the different
parts of the map. A separate ontology part could also be used for
defining categories of topic maps that share a common set of classes
with predefined semantics.

A template is a topic map that consists of scoping topics, classes, and
roles. We will see later that it also consists of consistency
constraints and inference rules. We define a set of PSIs for the basic
classes.

1.  PSIs for *basic classes*.

  ------------------- ------------------------------------------------------------------
  **Description**     **PSI**

  topic class         http://www.iso.org/tmpsi/1.0/template.xtm#topic-class

  occurrence class    http://www.iso.org/tmpsi/1.0/template.xtm#occurrence- class

  association class   http://www.iso.org/tmpsi/1.0/template.xtm#association-class

  association role    http://www.iso.org/tmpsi/1.0/template.xtm#association-role-class
  class               

  scoping topic class http://www.iso.org/tmpsi/1.0/template.xtm#scoping-topic-class
  ------------------- ------------------------------------------------------------------

These PSIs are used as subject indicator references for the classes of
the classes of the application domain.

+-----------------------------------------------------------------------+
| **Definition of the ontology topic "company" as topic class and       |
| association role class:**                                             |
|                                                                       |
| \<topic id=\"tc-company\"\>\                                          |
| \<instanceOf\>\                                                       |
| \<subjectIndicatorRef                                                 |
| xli                                                                   |
| nk:href=\"http://www.iso.org/tmpsi/1.0/template.xtm#topic-class\"/\>\ |
| \</instanceOf\>\                                                      |
| \<instanceOf\>\                                                       |
| \<subjectIndicatorRef                                                 |
| xlink:href=\"h                                                        |
| ttp://www.iso.org/tmpsi/1.0/template.xtm#association-role-class\"/\>\ |
| \</instanceOf\>\                                                      |
| \                                                                     |
| <baseName\>\<baseNameString\>company\</baseNameString\>\</baseName\>\ |
| \</topic\>                                                            |
+-----------------------------------------------------------------------+

Explanation of the ontology topic tc-company:

-   The topic tc-company is an instance of a class which is identified
    by the subject indicator references
    http://www.iso.org/tmpsi/1.0/template.xtm#topic-class and
    http://www.iso.org/tmpsi/1.0/template.xtm#association-role-class.

-   Because of this references the topic map software is aware that
    tc-company is a topic class and a association role class -- even
    before the class was referenced by a topic instance or used as an
    association role.

The definition of further ontology topics representing occurrence
classes, association classes, association role classes, and scoping
topic classes is done analogous.

The "real" topic map uses the domain specific classes.

+-----------------------------------------------------------------------+
| **Definition of company "eCOM":**                                     |
|                                                                       |
| \<topic id=\"t-ecom\"\>\                                              |
| \<instanceOf\>\                                                       |
| \<topicRef xlink:href=\"#tc-company\"/\>\                             |
| \</instanceOf\>\                                                      |
| \<baseName\>\<baseNameString\>eCOM\</baseNameString\>\</baseName\>\   |
| \</topic\>                                                            |
+-----------------------------------------------------------------------+

The naming of the ids and the topic names is up to the application
designer. Just the PSIs are predefined.

# Consistency constraints

ISO/IEC 13250:2000 has almost nothing to say on the subject of
validation and consistency. The "Conformance" section of the standard
focuses on the understanding of the defined constructs, the interchange
syntax, and import/export of topic maps.

Both the designer and the editor of topic maps need system support when
designing and creating a map which will consist of millions of topics
and associations. The question of the consistency of the map becomes a
key issue, because it is nearly impossible to check a map of that size
manually. For that reason we need concepts to declare consistency
constraints and to validate that those constraints have been obeyed.
\[Rat00\]\[Gro00\]

Consequently a separate schema is needed which contains all the
information necessary for the validation process. We call this construct
*consistency constraints* or just *constraints*. The validation is the
task of the topic map development environment (e.g. a editor or an
editorial system). It should be performed permanently or on demand --
like structure validation in an SGML/XML editor.

The constraints are either a set of topic, occurrence, and association
"patterns" declared in the template or implemented with a programming
language using an API of the topic map editor/engine. Latter one gives
more freedom, but for the price of rather big effort. The first one
fulfills the 80/20 rule and might be sufficient for most applications.

+-----------------------------------------------------------------------+
| **Example for a topic constraint:**                                   |
|                                                                       |
| A topic of class "project" has to have at least one English name, one |
| project plan, between one and ten status reports, and has to be       |
| associated with a project manager.                                    |
|                                                                       |
| **Example for an association constraint:**                            |
|                                                                       |
| An association of class "project membership" has to have exactly one  |
| project that has one or more project team members.                    |
+-----------------------------------------------------------------------+

## Constraint patterns

The constraints are defined rule-based as patterns for topics and
associations. These patterns "declare" the possible parameters and their
combinations. The patterns are defined as topics and associations. A
predefined scoping topic "schema" which is used as the scope signals
that these topics and associations have a special meaning -- they are
constraints for topics/associations of the given class.

The already introduced any topic will be used if the pattern needs a
wildcard for topics. A predefined scoping topic is assigned to the
association as scope if some topics must participate (playing the
specified role) in the association.

The declaration of minimum and maximum numbers of "objects" in a pattern
(like names, occurrences, and association roles) is done indirectly
through resourceData occurrences assigned to a topic reifying the
appropriate "object".[^1]

These PSIs define the "constraint schema" scoping topic, the "required
association role" scoping topic, and both the "minimum" and "maximum"
occurrence classes.

2.  PSIs for *constraints*.

  ------------------- ------------------------------------------------------------------
  **Description**     **PSD**

  topic map "object"  http://www.iso.org/tmpsi/1.0/template.xtm#constraint-schema
  is part of          
  constraint schema   
  which is identified 
  by a scoping topic  

  topic has to be     http://www.iso.org/tmpsi/1.0/template.xtm#topic-role-requirement
  used in association 
  which is identified 
  by a scoping topic  

  occurrence class    http://www.iso.org/tmpsi/1.0/template.xtm#min-number
  "minimum number of  
  reified 'object'"   

  occurrence class    http://www.iso.org/tmpsi/1.0/template.xtm#max-number
  "maximum number of  
  reified 'object'"   
  ------------------- ------------------------------------------------------------------

## Topic class example

+-----------------------------------------------------------------------+
| **Example of a pattern that constraints the topic class tc-project:** |
|                                                                       |
| \<topic id=\"X\"\>\                                                   |
| \<instanceOf\>\                                                       |
| \<topicRef xlink:href=\"#tc-project\"/\>\                             |
| \</instanceOf\>\                                                      |
| \<baseName id=\"bn-project-english\"\>\                               |
| \<scope\>\                                                            |
| \<subjectIndicatorRef                                                 |
| xlink:hre                                                             |
| f=\"http://www.iso.org/tmpsi/1.0/template.xtm#constraint-schema\"/\>\ |
| \<topicRef xlink:href=\"                                              |
| http://www.topicmaps.org/xtm/1.0/language.xtm#en\"/\>\                |
| \</scope\>\                                                           |
| \<baseNameString\>X\</baseNameString\>\                               |
| \</baseName\>\                                                        |
| \<occurrence id=\"o-project-plan\"\>\                                 |
| \<instanceOf\>\                                                       |
| \<topicRef xlink:href=\"#oc-project-plan\"/\>\                        |
| \</instanceOf\>\                                                      |
| \<scope\>\                                                            |
| \<subjectIndicatorRef                                                 |
| xlink:hre                                                             |
| f=\"http://www.iso.org/tmpsi/1.0/template.xtm#constraint-schema\"/\>\ |
| \</scope\>\                                                           |
| \<resourceData\>X\</resourceData\>\                                   |
| \</occurrence\>\                                                      |
| \<occurrence id=\"o-status-report\"\>\                                |
| \<instanceOf\>\                                                       |
| \<topicRef xlink:href=\"#oc-status-report\"/\>\                       |
| \</instanceOf\>\                                                      |
| \<scope\>\                                                            |
| \<subjectIndicatorRef                                                 |
| xlink:hre                                                             |
| f=\"http://www.iso.org/tmpsi/1.0/template.xtm#constraint-schema\"/\>\ |
| \</scope\>\                                                           |
| \<resourceData\>X\</resourceData\>\                                   |
| \</occurrence\>\                                                      |
| \</topic\>                                                            |
|                                                                       |
| \<topic id=\"t-reified-bn-project-english\"\>\                        |
| \<subjectIdentity\>\                                                  |
| \<resourceRef xlink:href=\"#bn-project-english\"/\>\                  |
| \</subjectIdentity\>\                                                 |
| \<occurrence\>\                                                       |
| \<instanceOf\>\                                                       |
| \<subjectIndicatorRef                                                 |
| xl                                                                    |
| ink:href=\"http://www.iso.org/tmpsi/1.0/template.xtm#min-number\"/\>\ |
| \</instanceOf\>\                                                      |
| \<scope\>\                                                            |
| \<subjectIndicatorRef                                                 |
| xlink:hre                                                             |
| f=\"http://www.iso.org/tmpsi/1.0/template.xtm#constraint-schema\"/\>\ |
| \</scope\>\                                                           |
| \<resourceData\>1\</resourceData\>\                                   |
| \</occurrence\>\                                                      |
| \</topic\>                                                            |
|                                                                       |
| \<topic id=\"t-reified-o-status-report\"\>\                           |
| \<subjectIdentity\>\                                                  |
| \<resourceRef xlink:href=\"#o-status-report\"/\>\                     |
| \</subjectIdentity\>\                                                 |
| \<occurrence\>\                                                       |
| \<instanceOf\>\                                                       |
| \<subjectIndicatorRef                                                 |
| xl                                                                    |
| ink:href=\"http://www.iso.org/tmpsi/1.0/template.xtm#min-number\"/\>\ |
| \</instanceOf\>\                                                      |
| \<scope\>\                                                            |
| \<subjectIndicatorRef                                                 |
| xlink:hre                                                             |
| f=\"http://www.iso.org/tmpsi/1.0/template.xtm#constraint-schema\"/\>\ |
| \</scope\>\                                                           |
| \<resourceData\>1\</resourceData\>\                                   |
| \</occurrence\>\                                                      |
| \<occurrence\>\                                                       |
| \<instanceOf\>\                                                       |
| \<subjectIndicatorRef                                                 |
| xl                                                                    |
| ink:href=\"http://www.iso.org/tmpsi/1.0/template.xtm#max-number\"/\>\ |
| \</instanceOf\>\                                                      |
| \<scope\>\                                                            |
| \<subjectIndicatorRef                                                 |
| xlink:hre                                                             |
| f=\"http://www.iso.org/tmpsi/1.0/template.xtm#constraint-schema\"/\>\ |
| \</scope\>\                                                           |
| \<resourceData\>10\</resourceData\>\                                  |
| \</occurrence\>\                                                      |
| \</topic\>                                                            |
+-----------------------------------------------------------------------+

Explanation of the constraint for topics of class tc-project:

-   A capital *X* means *any value*.

> Any value for attribute --id-, element \<baseNameString\>, and
> occurrences.

-   The topics which are instances of the subject indicator
    \...#min-number mean that there has to be a minimum number of
    instances of the reified element in the topic map -- but more than
    that number are allowed.

1--*n* elements \<baseName\> with scope English (XTM PSI for English
language is used here).

-   The topics which are instances of the subject indicator
    \...#max-number mean that there could be a maximum number of
    instances of the reified element in the topic map -- but less than
    that number are allowed.

1--10 occurrence of class oc-status-report.

-   If no "min-number/max-number" topic reifies an element the same
    number of that element in the pattern has to be in the topic map.

One occurrence of role class oc-project-plan.

## Association class examples

There is also a pattern for association classes which controls the
scope, the combination of valid association roles using
"min-number/max-number" topics, and the valid topic classes for every
role.

+-----------------------------------------------------------------------+
| **An example of a pattern that constraints the association class      |
| ac-project-membership:**                                              |
|                                                                       |
| \<association id=\"X\"\>\                                             |
| \<instanceOf\>\                                                       |
| \<topicRef xlink:href=\"#ac-project-membership\"/\>\                  |
| \</instanceOf\>\                                                      |
| \<scope\>\                                                            |
| \<subjectIndicatorRef                                                 |
| xlink:hre                                                             |
| f=\"http://www.iso.org/tmpsi/1.0/template.xtm#constraint-schema\"/\>\ |
| \</scope\>\                                                           |
| \<member\>\                                                           |
| \<roleSpec\>\                                                         |
| \<topicRef xlink:href=\"#tc-project\"/\>\                             |
| \</roleSpec\>\                                                        |
| \<topicRef xlink:href=\"#tc-project\"/\>\                             |
| \</member\>\                                                          |
| \<member id=\"m-team-member\"\>\                                      |
| \<roleSpec\>\                                                         |
| \<topicRef xlink:href=\"#tc-team-member\"/\>\                         |
| \</roleSpec\>\                                                        |
| \<topicRef xlink:href=\"#tc-employee\"/\>\                            |
| \</member\>\                                                          |
| \</association\>                                                      |
|                                                                       |
| \<association id=\"X\"\>\                                             |
| \<instanceOf\>\                                                       |
| \<topicRef xlink:href=\"#ac-project-membership\"/\>\                  |
| \</instanceOf\>\                                                      |
| \<scope\>\                                                            |
| \<subjectIndicatorRef                                                 |
| xlink:hre                                                             |
| f=\"http://www.iso.org/tmpsi/1.0/template.xtm#constraint-schema\"/\>\ |
| \<subjectIndicatorRef                                                 |
| xlink:href=\"                                                         |
| http://www.iso.org/tmpsi/1.0/template.xtm#topic-role-requirement\"\>\ |
| \</scope\>\                                                           |
| \<member\>\                                                           |
| \<roleSpec\>\                                                         |
| \<subjectIndicatorRef                                                 |
| x                                                                     |
| link:href=\"http://www.iso.org/tmpsi/1.0/template.xtm#any-topic\"/\>\ |
| \</roleSpec\>\                                                        |
| \<subjectIndicatorRef                                                 |
| x                                                                     |
| link:href=\"http://www.iso.org/tmpsi/1.0/template.xtm#any-topic\"/\>\ |
| \</member\>\                                                          |
| \<member\>\                                                           |
| \<roleSpec\>\                                                         |
| \<topicRef xlink:href=\"#tc-project\"/\>\                             |
| \</roleSpec\>\                                                        |
| \<topicRef xlink:href=\"#tc-project\"/\>\                             |
| \</member\>\                                                          |
| \</association\>                                                      |
|                                                                       |
| \<topic id=\"t-reified-m-team-member\"\>\                             |
| \<subjectIdentity\>\                                                  |
| \<resourceRef xlink:href=\"#m-team-member\"/\>\                       |
| \</subjectIdentity\>\                                                 |
| \<occurrence\>\                                                       |
| \<instanceOf\>\                                                       |
| \<subjectIndicatorRef                                                 |
| xl                                                                    |
| ink:href=\"http://www.iso.org/tmpsi/1.0/template.xtm#min-number\"/\>\ |
| \</instanceOf\>\                                                      |
| \<scope\>\                                                            |
| \<subjectIndicatorRef                                                 |
| xlink:hre                                                             |
| f=\"http://www.iso.org/tmpsi/1.0/template.xtm#constraint-schema\"/\>\ |
| \</scope\>\                                                           |
| \<resourceData\>1\</resourceData\>\                                   |
| \</occurrence\>\                                                      |
| \</topic\>                                                            |
+-----------------------------------------------------------------------+

Explanation of the constraint for associations of class
ac-project-membership:

-   The listed association roles are mandatory -- because the \<member\>
    elements are not reified by a "min-number" topic.

All ac-project-membership associations have to have the one association
roles tc-project.

-   The schema \...#topic-role-requirement signals that every topic of
    explicitly given class has to play the listed role in at least one
    association of the given class.

Every topic of class tc-project has to play the role tc-project in at
least one association of class ac-project-membership.

-   The "min-number" topic means that there has to be a minimum number
    of the reified association members in the topic map -- but more than
    that number are allowed. The "max-number" topic would mean that
    there could be a maximum number of the reified association members
    in the topic map -- but less than that number are allowed.

An association of class ac-project-membership consists of at least 1
team member.

## Constraints and class hierarchies

The defined constraints are automatically valid for all subclasses of
the topic class or the association class. Subclasses of the defined
association roles and topic classes playing that role are automatically
valid as well.

The declaration of class hierarchies (e.g. class tc-product is subclass
of tc-technology) will simplify the declaration of constraints.
Declaring the constraint for a general superclass automatically declares
the same constraint for all its subclasses.

An example is "SGML" which is a topic of class tc-standard but is
allowed to play the role tc-technology in an ac-project-technology
association.

# Conclusions

Topic maps are a powerful concepts to define intelligent link networks
over continuously growing information pools. Real-world topic maps will
consist of a large number of objects which require validation to assure
the quality of the map. A couple of concepts help with the QA or make
implicitly coded knowledge explicit: topic map templates define the
ontology of the application domain and constraints are the validation
rules. The sum of the concepts describe the *Topic Map Constraint
Language* (*TMCL*).

Published subject indicators (PSIs) distinguish the schema objects from
the objects of a "regular" topic map. It is the task of ISO JTC1 SC34
WG3 to standardize the PSIs.

[^1]: Because reification is not yet specified by XTM the proposed
    solution might change in the future.