ISO/IEC JTC 1/SC34 N226

ISO/IEC JTC 1/SC34/WG3

Information Technology --
Document Description and Processing Languages
-- Information Association

TITLE:	Draft requirements, examples, and a "low bar" proposal for Topic Map Constraint Language
SOURCE:	SC34/WG3
PROJECT:
PROJECT EDITOR:	Steve Pepper <[email protected]>
STATUS:	Draft
ACTION:
DATE:	2001-05-24
DISTRIBUTION:	SC34 and Liaisons
REFER TO:
REPLY TO:
VERSION:	$Id: tmcl-reqs.html,v 1.2 2001/06/08 11:08:00 pepper Exp $

Draft requirements, examples, and a "low bar" proposal for Topic Map Constraint Language (TMCL)

1. User requirements

TMCL shall permit the definition of classes of topic maps in order to:
- enable the documentation of the structure and semantics of a class of topic maps;
- provide a foundation for defining vertical or domain specific applications of topic maps;
- provide means of validation to ensure consistency within a topic map or across a class of topic maps;
- enable applications to provide easier and more intuitive user interfaces for creating and maintaining topic maps;
- enable the separation of the tasks of modeling and populating topic maps.
TMCL shall be based on the Topic Map Data Model (and therefore support both XTM and ISO 13250 Topic Maps).
TMCL shall not attempt to cover every possible constraint. Instead it should provide a solution for the most commonly required kinds of constraints and, at the same time, an extension mechanism to allow the expression of less common constraints by other means.
TMCL shall provide for modularization, and the ability to extend individual sets of constraints through reference to others.
TMCL shall be expressible as XML, using the topic map interchange syntax where applicable.
TMCL shall build on pre-existing specifications and established best practice for knowledge representation and data modeling where possible. (Candidates for consideration include DAML/OIL, KIF, OKBC, OCL, PAL (Protégé Axiom Language), and XML Schema.)
TMCL shall be as concise and human-readable as possible within the terms of the preceding requirements.

2. Working definitions

This section proposes some definitions of terms and concepts relevant to a topic map constraint language.

ontology

The classes and subclasses of topics, associations, association roles, and occurrences that describe everything in the application domain; and the set of scopes in which topics may have characteristics in that domain.

Note: The status of facet types and facet value types needs to be considered once the data model has been finalized.

constraint

Rule(s) governing classes of objects in an ontology.

template

The expression of the constraints to which instances of a class of topic map object must conform.

schema

The collection of templates that together define a class of topic maps.

3. Catalog of typical constraints

This section lists some typical ways in which designers might want to constrain topic maps. The constraints are grouped according to the types of topic map objects. The catalog is intended to provide a means whereby different proposals might be evaluated. It is not complete and suggestions are invited for other constraints that might be useful.

3.1 By association type

permitted association role types and cardinalities
permitted classes of role playing topics
valid combinations of the above
valid scopes

Example 1.1: Constrain the topic "T" to be used for typing associations and nothing else.

Example: The topic "born in" defines a class of associations.

Example 1.2: Constrain associations of type "T" to consist of N roles, "R1", "R2", ... "Rn".

Example: Associations of type "born in" must have two roles, "person" and "place".

Example 1.3: Constrain the role "R" in an association of a given type to be played by exactly one topic belonging to the class "C".

Example: The roles "person" and "place" in an association of type "born in" must each be played by exactly one topic belonging to the classes "person" and "place", respectively.

Example 1.4: Constrain the role "R" in an association of a given type to be played by one or more topics belonging to the class "C".

Example: The role "project" in an association of type "project membership" must be played by a topic of type "project", and the role "project member" must be played by one or more topics of type "employee".

Example 1.5: Constrain associations of type "T", such that

if role "R1" is played by a topic of type A1, then role "R2" must be played by a topic of type "A2", "A2'", or "A2''";
if role "R1" is played by a topic of type B1, then role "R2" must be played by a topic of type "B2", "B2'", or "B2''";
etc.

Example: Associations of type "located in" consist of two roles, "container" and "containee" such that the "container" may be

a topic of type (or supertype) "country", in which case the "containee" must be of type (or supertype) "state", "county", or "city";

a topic of type (or supertype) "state", in which case the "containee" must be of type (or supertype) "county" or "city";

a topic of type (or supertype) "county", in which case the "containee" must be of type (or supertype) "city";

a topic of type (or supertype) "city", in which case the "containee" must be of type (or supertype) "theatre";

Example 1.6: Constrain associations of type "T" to be in the scope "S".

Example: Associations of type "born in" must be in the scope "biography".

3.2 By topic type

valid topic name spaces (i.e. scopes) in which topics of this type may have names
requirements on subject indicators for topics of this type (e.g. valid URI patterns, prefixes, or PSI registries)
requirements on subject addresses (valid combinations of URI patterns and notations)
requirements on variant names (valid combinations of URI patterns, notations, and scopes)
requirements on occurrences (valid combinations of URI patterns, notations, scopes, and types)
requirements on associations in which topics of this type must participate

Example 2.1: Constrain the topic "T" to be used for typing topics and nothing else.

Example: The topic "city" defines a class of topics.

Example 2.2: Constrain the topic "T" to be used for typing topics and/or association roles, and nothing else.

Example: The topic "person" defines a class of topics and a class of association roles.

Example 2.3: Constrain topics of type "T" to have a name in the scope "S".

Example: Topics of type "country" must have a name in the scope "english".

Example 2.4: Constrain topics of type "T" to have an occurrence of type "O".

Example: Topics of type "country" must have an occurrence of type "map".

Example 2.5: Constrain topics of type "T" to have a subject indicator defined in a certain registery.

Example: Topics of type "country" must have a subject indicator defined in the registery at "http://www.oasis-open.org/psi/country".

Example 2.6: Constrain topics of type "T" such that they must play a role in an association of type "A".

Example: Topics of type "person" must play the role of "person" in an association of type "born in".

3.3 By occurrence type

valid combinations of locator (URI pattern), scope, and parent topic

Example 3.1: Constrain the topic "T" to be used for typing occurrences and nothing else.

Example: The topic "map" defines a class of occurrences.

Example 3.2: Constrain occurrences of type "O" to only be characteristics of topics of type "T".

Example: Occurrences of type "map" may only be characteristics of topics of type "country".

Example 3.3: Constrain occurrences of type "O" to have locators that match a URI pattern "P".

Example: Occurrences of type "map" must have URIs that match the pattern "http://www.maps.com/".

Example 3.4: Constrain occurrences of type "O" to be within scope "S".

Example: Occurrences of type "map" must be in the scope "geography".

3.4 By association role type

Example 4.1: Constrain the topic "T" to be used for typing association roles and nothing else.

Example: The topic "person" defines a class of association role.

3.5 By theme

which topics can be used for scoping
which types of characteristics themes can contribute to the scope of

Example 5.1: Constrain topics of type "T" to be used as themes and nothing else.

Example: The topic "classified" is only used for scoping topic characteristics.

Example 5.2: Constrain topics of type "T" to be used as themes for name characteristics only.

Example: The topic "english" is only used for scoping name characteristics.

3.6 By scope

valid combinations of themes/scoping topics
which types of characteristics can be scoped by which scopes

Example 6.1: Define valid combinations of themes "T1", "T2", "T3", and "T4", to be "T1 T3", "T1 T4", "T2 T3", and "T2 T4".

Example: Valid combinations of the themes "english", "french", "beginner", and "expert", are: "english beginner"; "english expert"; "french beginner"; and "french expert".

Example 6.2: Constrain the scope "T1 T2" defined by the themes "T1" and "T2" to be used to qualify characteristic assignments of type "C".

Example: The scopes "english beginner" and "french beginner" may only qualify occurrences of type "description".

4. Notes on conformance

Once a constraint language has been defined, it would be possible to express three levels of conformance for topic map documents:

Syntax conformance: The topic map conforms to one of the standard interchange syntaxes.
Ontology conformance: The topic map is internally consistent with its own ontology, i.e. the classes to which topics, occurrences, associations, and association roles are declared to belong are themselves declared to be classes of the correct type.
Schema conformance: The topic map conforms to the rules of its schema, i.e. its ontology and all constraints upon that ontology.

5. A simple low bar proposal

In order to provide a starting point for discussions, the following proposal is offered as a strawman with the intention of establishing a "low bar" for what a topic map constraint language should be able to express. It requires the definition of six public subjects, and uses topics and associations as "templates" (in the sense of "cut-out patterns") for expressing constraints.

5.1 Public subjects

The following public subjects are defined. (Note: The URLs used here are for illustration only.)

template: The concept of template.
"http://www.iso.org/iso13250/tmcl.xtm#template"
topic type: The concept of topic type.
"http://www.iso.org/iso13250/tmcl.xtm#topic-type"
occurrence type: The concept of occurrence type.
"http://www.iso.org/iso13250/tmcl.xtm#occurrence-type"
association type: The concept of association type.
"http://www.iso.org/iso13250/tmcl.xtm#association-type"
association role type: The concept of association role type.
"http://www.iso.org/iso13250/tmcl.xtm#association-role-type"
theme: The concept of theme.
"http://www.iso.org/iso13250/tmcl.xtm#theme"

5.2 Topic template

A topic template is a topic that is used as a theme and/or to type other constructs. The classes of objects that it may type depend on the classes to which it itself belongs. For example, a topic that belongs to classes defined by the public subjects topic type and association role type may be used to type topics and association roles.

A topic that is to be used for typing other topics may template the name and occurrence characteristics of its instances. Templated characteristics are recognized by the use of the "template" public subject in their scopes.

Example

The following topic defines a class of topics and provides templates for certain name and occurrence characteristics:

<topic id="country">
	<instanceOf>
		<subjectIndicatorRef
			xlink:href="http://www.iso.org/iso13250/tmcl.xtm#topic-type"/>
	</instanceOf>
	<baseName>
		<baseNameString>country</baseNameString>
	</baseName>
	<baseName>
		<scope>
			<subjectIndicatorRef
				xlink:href="http://www.iso.org/iso13250/tmcl.xtm#template"/>
			<topicRef xlink:href="#en"/>
		</scope>
		<baseNameString>English name</baseNameString>
	</baseName>
	<occurrence>
		<instanceOf>
			<topicRef xlink:href="#map"/>
		</instanceOf>
		<scope>
			<subjectIndicatorRef
				xlink:href="http://www.iso.org/iso13250/tmcl.xtm#template"/>
		</scope>
		<resourceRef xlink:href="http://www.maps.com/"/>
	</occurrence>
</topic>

In order to conform to this template, a topic must be an instance of the class "country"; it must have a base name in the scope "en"; and it must have an occurrence of type "map"[, located via a resource reference whose URI matches the string "http://www.maps.com/"]. The following is an example of such a topic.

<topic id="norway">
	<instanceOf>
		<topicRef xlink:href="#country"/>
	</instanceOf>
	<baseName>
		<scope>
			<topicRef xlink:href="#en"/>
		</scope>
		<baseNameString>Norway</baseNameString>
	</baseName>
	<occurrence>
		<instanceOf>
			<topicRef xlink:href="#map"/>
		</instanceOf>
		<resourceRef xlink:href="http://www.maps.com/norway.jpg"/>
	</occurrence>
</topic>

5.3 Association template

An association template is an association in which the role playing topics are classes or superclasses. It is scoped by the template public subject defined above.

An association conforms to a template if and only if it is identical to the template in every respect except:

The template public subject does not contribute to its scope.
The role playing topics are instances of classes defined by the corresponding role playing topics in the template.

For the purpose of templating, class membership may be determined indirectly through the use of superclass-subclass associations.

There may be multiple templates for the same class of association. An individual association need only conform to one of them.

Example

The following example provides a template for the association type "born-in":

<!-- born-in, person, and place topics omitted for brevity-->

<association>
	<instanceOf>
		<topicRef xlink:href="#born-in"/>
	</instanceOf>
	<scope>
		<subjectIndicatorRef
			xlink:href="http://www.iso.org/iso13250/tmcl.xtm#template"/>
	</scope>
	<member>
		<roleSpec>
			<topicRef xlink:href="#person"/>
		</roleSpec>
		<topicRef xlink:href="#person"/>
	</member>
	<member>
		<roleSpec>
			<topicRef xlink:href="#place"/>
		</roleSpec>
		<topicRef xlink:href="#place"/>
	</member>
</association>

An association conforms to the foregoing template if it is identical in every respect except for:

The association is not scoped by the public subject template, and
The topics playing the roles person and place are instances of the classes (or superclasses) person and place respectively.

The following example shows an association which conforms to the foregoing template.

<!-- born-in, person, and place topics omitted for brevity-->

<topic id="puccini">
	<instanceOf>
		<topicRef xlink:href="#person"/>
	</instanceOf>
</topic>

<topic id="lucca">
	<instanceOf>
		<topicRef xlink:href="#place"/>
	</instanceOf>
</topic>

<association>
	<instanceOf>
		<topicRef xlink:href="#born-in"/>
	</instanceOf>
	<member>
		<roleSpec>
			<topicRef xlink:href="#person"/>
		</roleSpec>
		<topicRef xlink:href="#puccini"/>
	</member>
	<member>
		<roleSpec>
			<topicRef xlink:href="#place"/>
		</roleSpec>
		<topicRef xlink:href="#lucca"/>
	</member>
</association>

The classes defined in the template for role playing topics may be superclasses of the classes to which the role playing topics in the conforming association belong. Thus, if "lucca" were a topic of type "city", and there existed a superclass-subclass relationship between "place" and "city", then the association shown above would still conform to the template. Similarly, if "puccini" were a topic of type "composer", and there existed a superclass-subclass relationship between "person" and "composer", then the association shown above would also conform to the template.

5.4 Evaluation of the low-bar proposal

This proposal seems to satisfy most of the user requirements defined above, except that no extension or modularization mechanisms have yet been defined.

It can handle association type constraints 1.1, 1.2, 1.3, 1.5, and 1.6, above. It cannot handle constraint 1.4 since it has no way to express cardinality.

It can handle topic type constraints 2.1, 2.2, 2.3, and 2.4. In its current form it cannot constrain the use of subject indicators (2.5), or constrain topics of a certain type to always participate in associations of certain types (2.6).

The proposal can only constrain occurrence types and association role types in terms of stating which topics define classes of such objects (3.1 and 4.1).

The proposal cannot constrain the use of themes and scopes from their own perspective except for stating which topics may be used as themes (5.1).

A further shortcoming of the proposal is that it does not allow the specification of constructs which may appear, as opposed to constructs which must appear.

In spite of its shortcomings, this proposal addresses many, if not all, of the most common constraints required by developers of topic map applications. At the very least it would seem to constitute a 60/40 solution, if not even an 80/20 solution, and it does so within the terms of the topic map paradigm, without introducing new constructs (except for six public subjects).

ISO/IEC JTC 1/SC34 N226

ISO/IEC JTC 1/SC34/WG3

Information Technology --Document Description and Processing Languages-- Information Association

Draft requirements, examples, and a "low bar" proposal for Topic Map Constraint Language (TMCL)

1. User requirements

2. Working definitions

3. Catalog of typical constraints

3.1 By association type

3.2 By topic type

3.3 By occurrence type

3.4 By association role type

3.5 By theme

3.6 By scope

4. Notes on conformance

5. A simple low bar proposal

5.1 Public subjects

5.2 Topic template

Example

5.3 Association template

Example

5.4 Evaluation of the low-bar proposal

Information Technology --
Document Description and Processing Languages
-- Information Association