ISO/IEC JTC 1/SC 34N0548

ISO/IEC JTC 1/SC 34

Information Technology --
Document Description and Processing Languages

Topic Map Constraint Language (TMCL) Requirements and Use Cases

1. Background

The ISO JTC1 SC34 Project for a Topic Map Constraint Language (TMCL) [N0221] was voted and approved on 2001-10-5. The NP vote can be found in ISO/IEC JTC 1/SC34 N0259 [N0259], along with the National Body comments on N0226 Draft Requirements, examples and a "low bar" proposal for Topic Map Constraint Language [N0226]. At the time of the submission of this NP, a data model was proposed and it was decided that since this model would be needed to develop TMCL, work was suspended until development of the model has sufficiently progressed. It was decided in Baltimore 2002 to resume work on TMCL and begin collecting requirements. The changes in this document over N0226 were made based on the comments received from National Bodies on N0226, plus additional comments gathered from tmcl-wg@isotopicmaps.org and discussions on irc.//irc.freenode.net/#topicmaps.

2. Introduction

2.1 Overview

TMCL will provide a means to express constraints on classes of topic maps conforming to the Data Model [DM] for ISO/IEC 13250:2002 Topic Maps [13250]. Its goal will be to provide a language such that a topic map can be said to be conforming to set of constraints. A topic map can be said to conform if it is successfully validated against the set of constraints. It may help optimization both of topic map storage and of TMQL [N0249] queries based on schema information. It may aid applications in providing more intuitive user interfaces for creating and maintaining topic maps.

This document, split into three core sections, outlines the general requirements that the language should meet, provides technical use cases (these are data structure level use cases), and provides use cases that cater to the wider deployment of TMCL (such as illustrating how TMCL could be used in a document management solution to provide metadata authoring rigor).

2.2 Definitions, Acronyms and Abbreviations

The keywords "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMEND," "MAY," and "OPTIONAL will be used in this document as defined in [RFC 2119].

"Topic Map Constructs" are the information items described in [DM].

"TMCL Schema" can be defined as a collection of constraints (defined using TMCL) used together for some purpose.

"Schema Introspection" is the ability to interrogate the data model of a set of constraints.

A "Selector" is an expression that locates or identifies some set of topic map constructs.

A "Restrictor" expresses conditions upon items identified by the selector.

"Typing Constraints" are constraints that only apply to classes of topics or classes of associations.

"Free Ranging Patterns" are constraints that apply to constructs that can be arbitrarily dispersed throughout a topic map.

"Constraint Reification" is ability to represent a constraint as topics in some topic map.

3. TMCL Requirements

3.1 General Requirements

R1. Relation to the data model for Topic Maps

TMCL must be specified in terms of the Topic Map data model [DM].

R2. Constraints ranging over the complete data model for Topic Maps

The language must be able to constrain all topic map structures defined in the data model for Topic Maps [DM].

R3. Data model

TMCL will have a defined data model that will be formalized with the XML Infoset notation [XMLinfoset].

R4. XML syntax

The language should have one and only one standardized XML serialization syntax.

R5. Serialization

TMCL should enable alternative serializations of a TMCL schema besides the one standardized in XML.

R6. Model and syntax

TMCL must define a) a syntax for expressing constraints b) a model for internal representation for these constraints, and c) behavior of TMCL validation.

R7. Validation and Exceptions

TMCL may define a set of validation exceptions. Where these exceptions are defined it must be unambiguous as to what constitutes a violation and what exception occurs. A violation is considered a topic map construct that breaks a TMCL constraint.

R8. Merging of schemas

Given two schemas, it must be possible to compose them. In cases where there are schema contradictions, these must be communicated to the client by the merging application.

R9. Schemas as distinct resources

Schemas should be resources that have their own unique identifiers, such as a Published Subject Indicators (PSIs).

R10. Explicit schema extension

Schemas must be able to explicitly extend other schemas in order to reuse constraints while adding new constraints. Schema extension must be a transitive relation; if schema A extends schema B, and schema B extends schema C, then schema A implicitly extends schema C as well.

R11. Commitment to a schema

A Topic Map must be able to explicitly commit to a specific schema.

R12. Schema metadata

It must be possible to provide metadata for each schema. This meta data should take the form of a topic map.

R13. Versioning information

The language must provide features for relating different versions of the same schema. This should include features for relating revisions to prior versions, explicit statements of backwards-compatibility, and the ability to deprecate identifiers (i.e., to state they are available for backwards-compatibility only, and should not be used in new applications/documents.)

R14. Type hierarchy constraints

The language must be able to constrain topic class hierarchies. This includes, but is not limited to, sub classing and transitivity.

R15. Topic property constraints

The language must be able to express constraints on topic properties. These include, names, occurrences, identifiers and roles in associations.

R16. Data types

TMCL will not specify its own set of basic data types. However, it will be enabled to utilize data typing as defined by standards such as XML Schema Part 2 Datatypes [xmlschema], RELAX-NG [relax-ng] or Document Schema Definition Languages [dsdl].

R17. Sets of Individuals

The language must be able to express that a set topic map information items and/or literals constitute the allowed value of a property, be it in relation to topic types, scope or allowed role players.

R18. Cardinality constraints

The language must support the specification of cardinality restrictions on topic map structures.

R19. Support for a character set

The character set for TMCL shall be Unicode.

R20. Topic structure selection

Anything retrievable by TMQL can be constrained.

R21. Free-ranging Topic Map constraints

The language must allow for topic map constraints to apply to several disjoint topic map structures, i.e., TMCL will not just restrict the properties of a topic of a given class, or the role types of a given association type.

R22. Schema introspection

The language must be constructed in such a way that it is possible to introspect any given schema for the purpose of user interface creation or automated semantic processing.

R23. TMCL levels

TMCL should have two levels of constraining. Fully qualified TMCL will allow for the constraint of any topic map construct, whereas, TMCL- Lite will only enable the constraint of commonly used topic map constructs such as topic type and association type.

3.3 Specific Requirements

SR1. Constraints by association type

Some examples include constraints that

• restrict association role types and define cardinality
  
• restrict types of role-playing topics
• allow valid combinations of the above
• restrict valid scopes.
  

SR2. Constraints by topic type

Some examples include

• scope constituents in which topics of this type may have names
• subject indicators for topics of this type (e.g. valid URI patterns, prefixes, or PSIs)
• subject addresses (valid combinations of URI patterns and notations)
• variant names (valid combinations of URI patterns, notations, and scopes)
• occurrences (valid combinations of URI patterns, notations, scopes, and types)
• associations in which topics of this type must participate.

SR3. Constraints by occurrence type

These may include but are not limited to valid combinations of locator (URI pattern), scope, and parent topic.

Internal occurrence data types and values should be constrained and used when constraining other aspects of the topic map.

SR4. Constraints by association role type

These are selectors that

• restrict topics that can only be used for typing association roles
• restrict topics that may not be used for typing association roles

SR5. Constraints by scoping-topic characteristics

A selector may restrict a topic to be used for scoping topic characteristic(s): base names, occurrences and association roles.

A selector may restrict which topics can be used as scoping topics.

SR6. Cardinality constraints

Cardinality will be defined, for example, for

• characteristics of topics (by type and scope)
• other properties of topics (e.g. subject indicators)
• roles in associations
• role players in roles
  
• Topic Map wide properties

SR7. Representation of complex validation rules

TMCL should allow different combinations of logical connectives and quantifiers such as exists, forall, and, or, not, implies and equivalent.

TMCL should represent information about equality (= and /=).

TMCL should include basic constructs for making statements about

• numeric data such as <, >, <=, >=, = and /=
• string-based data such as =, /= and contains (string,substring).

TMCL may include basic constructs for making statements about string-based data using regular expressions.

TMCL may allow the introduction of "virtual" (extended) constructs which can be reused in defining new validation rules (a kind of "virtual" relations/associations).

TMCL may create named complex conditions.

SR8. Prescriptive validation

A prescriptive validating topic map application MUST ensure that only instances of schema constructs exist in the map, i.e., only topics of types defined in the schema can exist and that all constraints defined are conformed to, in the topic map.

• A validating topic map application MUST ensure that any structure that can be constrained, conforms to the constraints of the schema.
• TMCL will allow any topic map construct to be constrained, i.e., not just topics and associations, but also names, resource references, and variants, etc.

SR9. Permissive validation

With permissive validation, any constraints defined must be met, but any structures not governed by the constraints are deemed to be in violation of the schema.

4. TMCL Use Cases

This section provides use cases that are based on topicmap constructs. These low level constraints help to define the scope and shape of the building blocks of TMCL. The examples in this section will provide use cases of how people would constrain constructs such as names and identities.

4.1 Use Cases based on TMCL requirements

General rules for all constraints:

• Every "must" is replaceable with "must not"
• Every "can" is replaceable with "can not"
• Every "should" is replaceable with "should not"

4.1.1 Constraint by association

Elements of association definition in Topic Maps:

• Association type
• Association scope
• Association role
• Association player

U1. Permitted association type topics

This particular constraint defines what topics can be used as association type topics. For example, the topic "student" is not the right topic to be used as an association type topic, while the topic "is-studying-at" is.

a. Topic T can be used as an association type topic.

Example: Association of type born-in defines a class of associations.

Restriction: Further restrictions may be enforced on this particular constraint such as limiting the use of a particular topic as an association type topic and nothing else.

U2. Valid association scopes

This particular constraint defines the scope a particular association should have. This may also restrict which topics may be used to scope an association.

a. Association with association type A must be in scope S.

Example: Association of type born-in must be in scope biography.

b.Topic T can be used to scope the association (used as an association scope).

Example: Topic biography can be used to scope association.

Restriction: Further restriction may be enforced to this particular constraint. In regards to the second usage, limit the use of a particular topic to scope association and nothing else.

U3. Permitted association role types in an association

This particular constraint defines which association roles an association should have, and it also enforces cardinalities of the association roles. An association must have association roles, and this constraint defines which roles should be included with the association.

a. Association with association type A has only roles R1 and R2.

Example: Association of type born-in must have roles person and place.

b. Association with association type A has at least the roles R1 and R2.

Example: Association of type employed-by must have at least the roles employee and employer.

U4. Permitted association role topics

This particular constraint defines which topics can be used as association role topics. The topic born-in is not an appropriate choice as an association role topic, but the topic employee is.

a. Topic T can be used as an association role topic.

Example: Topic container can be used as association role topic.

b. Topic T can be used as an association role topic in association with association type A.

Example: Topic killer can be used as an association role topic within association of type murder.

Restriction: Further restrictions may be enforced on this particular constraint such as limiting the use of a particular topic as association role topics only and nothing else, whether or not within a specific association only.

U5. Permitted association player topics

This particular constraint defines which topics can be used as association player topics. The topic born-in is not an appropriate choice as an association player topic, but the topic Erica is .

a. Topic of type T can be used as an association player topic, i.e., can participate in an association.

Example: Topic of type student can participate in an association.

b. Topic of type T can be used as association player topic or participate in an association with association type A.

Example: Topic of type student can participate in association with association type studying-at.

Restriction: Further restrictions may be enforced on this particular constraint. As in the first usage, limit the use of a particular topic as association player topics only and nothing else, whether or not within a specific association only.

U6. Permitted association structure

This particular constraint defines what an association should look like.

a. Association of type A must have (only/at least) two participating topics where one is of type T1 and the other is of type T2.

Example: Association of type employed-by must have at least two participating topics where one is of type employee and the other is of type employer.

b. Association of type A must have the role R being played by a topic of type T.

Example: An association of type studying-in must have the role student being played by a topic of type student.

U7. Combinations of the above (allow cardinality)

a. Association of type A has role R played by exactly two topics of type T.

Example: Association of type project-partnership must have the role partner being played by two topics of type businessman.

b. Association of type A has role R1 played by topic of type T1 and role R2 played by topic of type T1 or T2.

Example: Association of type born-in must have the role mortal being played by one topic of type person and role birthplace played by one topic of type location.

U8. Dependencies within association

Description: Constraint association of type A 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''

a. An association of type A must have dependencies between player types.

Example: Association of type located-in must have the roles container and containee, such that the container may be

• a topic of type country, in which case the containee must be of type state, county, or city
• a topic of type state, in which case the containee must be of type county or city
• a topic of type county, in which case the containee must be of type city
• a topic of type city, in which case the containee must be of type theatre.

4.1.2 Constraint by topic

Elements of topic

• Topic type
• Topic properties (names, occurrences, subject identifiers)
• Scope, type

U1. Valid topic names

Topics can have name(s) whether it is an explicit or implicit name. This constraint is to limit the existence and/or value of the explicit names of a topic.

a. Topic of type T must have a specified number of explicit names (cardinality).

Example: Topic of type person must have two explicit names, i. e., one is a nickname and the other is the full name.

b. Topic of type T must have at least one explicit name.

Example: Topic of type student must have at least one registered name.

c. Topic of type T must have a name where the value matches the particular pattern.

Example: Topic of type tutorial must have a name containing the word tutorial.

d. Topic of type T must not have a name.

Example: Topic of type time must not have any explicit name.

e. Topic of type T must have a name with scope S.

Example: Topic of type Englishman must have a name with scope en (meaning English).

U2. Valid topic occurrences

This constraint is to ensure that a particular topic has the occurrences as required.

a. Topic of type T must have a specified number of occurrences (cardinality).

Example: Topic of type tutorial must have at least two occurrences, one is the main reference and the other is backup reference.

b. Topic of type T must have at least one occurrence following a particular pattern.

Example: Topic of type tutorial must have at least one occurrence which has the pattern http:// (denotes it is a web page).

c. Topic of type T must have an occurrence that is of type O.

Example: Topic of type tutorial must have an occurrence that is of type homepage.

d. Topic of type T must have an occurrence in scope S.

Example: Topic of type country must have occurrence of type map in the scope geography.

e. Topic of type T must not have any occurrence.

Example: Topic of type is-doing-project must not have any occurrences.

U3. Valid subject indicator

This constraint is to ensure that a particular topic has the subject indicator as required.

a. Topic of type T must have a specified number of subject indicators (cardinality).

Example: Topic of type tutorial must have at least one subject indicator.

b. Topic of type T must have at least one subject indicator.

Example: Topic of type project must have at least one subject indicator no matter what the value is.

c. Topic of type T must have a subject indicator with a particular value or match a pattern P.

Example: topic of type country must have have the subject indicator: http://www.oasis.org/psi/country/.

d. Topic of type T must have a subject indicator defined in a certain registry.

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

e. Topic of type T must not have any subject indicator.

Example: Topic of type undefined must not have any subject indicator.

U4. Valid topic type

This constraint defines which topics can be used for topic typing.

a. Topic T can be used for typing other topics and nothing else.

Example: Topic person can be used for typing other topics, while the topic Erica is not appropriate to use for typing other topics.

b. Topic T can be used for typing occurrences.

Example: Topic map can be used for typing occurrence, and nothing else.

c. Topic T can be used for typing subject indicator.

Example: Topic locator can only be used for typing subject indicator and must not occur anywhere else.

U5. Topics only used for scoping

This constraint defines which topics can be used for scoping, and what it should scope.

a. Topic of type T can only be used for scoping basenames and nothing else.

Example: topic of type English can only be used for scoping names and nothing else.

b. Topic of type T can only be used for scoping occurrences and nothing else.

Example: Topic of type map can only be used for scoping occurrences and nothing else.

c. Topic of type T can only be used for scoping associations and nothing else.

Example: Topic of type doing-something can only be used for scoping associations and nothing else.

U6. Instances of a topic (enumeration)

This constraints defines the allowed instances of a type and may include cardinality.

a. A List of topics are instances of topic type T.

Example: Instances of topic type primary-color can only be red, blue, yellow.

b. There are at least 3 topics that are instances of topic type T.

Example: There have to be at least 5 topic instances of topic type student.

U7. Association in which topics must participate

This constraint defines which association a particular topic should participate in.

a. Topic of type T must participate in association type A.

Example 1: A topic of type person must be the only member in association born-in who plays the role mortal.

Example 2: A topic of type student must participate in an association studying-at.

4.1.3 Constraint by occurrence type

U1. Valid combination of scopes, locators, and parent topics

This constraint defines valid combination uses of scopes, locators, and parent topics.

a. Valid combinations of the use of scopes S1, S2, S3 is S1, S2 and S2, S3 only.

Example: Valid combination of topic scopes English, French, and beginner are English - beginner and French - beginner.

b. Scope T1-T2 defined by the topics T1 and T2 to be used to qualify characteristic assignments of type C.

Example: Scope English beginner and French beginner may only qualify occurrence of type description.

U2. Valid place where occurrences may appear

This constraint defines where occurrences may appear.

a. Occurrence of type O can only be a characteristic of topics of type T.

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

U3. Valid occurrence type and scope

This constraint defines the valid occurrence types and scopes.

a. Occurrence of type O can only be used within scope S.

Example: Occurrence of type download can only be used within the scope of internet.

U4. Valid locators

This constraint defines the valid occurrence value.

a. Occurrence of type O must have locators that match a URI pattern P.

Example: Occurrences of type map must have a URI that matches the pattern http://www.maps.com/.

4.1.4 Constraint Transitivity

U1. Sub type - super type relationship

By default, it is defined that if topic T is a subtype topic A, and topic A is a subtype of topic S, then topic T is a subtype of type S. This constraint allows other ways to define the supertype-subtype relationship.

a. Topic A is subtype of topic T, and topic T is subtype of topic B¸ but topic A is not a subtype of B.

U2. Roles transitivity in association

This constraint defines the transitivity rule for association roles within an association.

a. Topic T1 and T2 plays role R1 and R2 in association A, topic T2 and T3 plays role R1 and R2 in association A, topic T1 and T3 are transitively related.

Example: Queensland plays role containee and Australia plays role container in association with association type contained-in; Brisbane plays role containee and Queensland plays role container in association with association type contained-in. Transitivity rule therefore defines Brisbane plays role containee and Australia plays role container in association with association type contained-in.

4.1.5 Data Typing Constraints

This constraint defines data type for particular topic characteristic, or even for any value contained within a topic map.

a. Topic of type T must have a characteristic and the value has to be a particular datatype.

Example 1: Topic that is of type product must have an internal occurrence, which is price, and the value should be of data type currency.

b. Topic of type T must have an occurrence, and the value has to be a particular data type.

Example 2: Topic must have an occurrence that can be either isURL, isURN, isURI, or isNumber.

4.1.6 Miscellaneous

U1. TMCL must allow merging between constraints

Topic Maps allow merging between topic map documents, therefore TMCL should also allow merging between a constraint schema for one Topic Map with a constraint schema for another map, when the two Topic Maps are merged.

Example: Topic map A is created following the constraint OA, while topic map B is created following the constraint OB. When topic map A is merged with topic map B then the two constraints OA and OB need to be merged as well.

TMCL shall be able to aid applications in providing more intuitive user interfaces.

TMCL should support schema-driven presentation of information.

Comment: Without TMCL, software viewers only can show topic map constructs presented explicitly in a topic map. TMCL schema allows to present "what is expected," "what is entered already," and "what is still missing" in a topic map.

TMCL should support schema-driven information editing.

Comment: Schema-based software editors can automatically generate visual forms to support editing existing topic map constructs and entering new "missing" or "possible" topic map constructs.

TMCL should support context sensitive, schema-optimized entering of information by users.

Comment: When users try to enter new information, software editors can suggest a list of all entered-before topics as candidates for "new" items. In real life scenarios, it can include thousands of topics. TMCL Schema-based editors can optimize the list of "candidates" based on context. Example: Topic is instance of Type(s) and constraints.

TMCL may provide support for generating topic map user interfaces with such technologies as XSLT, XForms or other equivalent technologies.