ISO/IEC JTC 1/SC 34N0548

ISO/IEC JTC 1/SC 34

Information Technology --
Document Description and Processing Languages

TITLE:	Topic Map Constraint Language (TMCL) Requirements and Use Cases
SOURCE:	Mr. Graham Moore; Ms. Mary Nishikawa; Mr. Dmitry Bogachev
PROJECT:	CD 19756: Information Technology - Topic Maps - Constraint Language (TMCL)
PROJECT EDITOR:	Mr. Dmitry Bogachev; Mr. Graham Moore; Ms. Mary Nishikawa
STATUS:	Editors' Draft
ACTION:	For review and comment
DATE:	2004-10-16
DISTRIBUTION:	SC34 and Liaisons
REFER TO:	N0549 - 2004-10-16 - Topic Map Constraint Language
REPLY TO:	Dr. James David Mason (ISO/IEC JTC 1/SC 34 Chairman) Y-12 National Security Complex Bldg. 9113, M.S. 8208 Oak Ridge, TN 37831-8208 U.S.A. Telephone: +1 865 574-6973 Facsimile: +1 865 574-1896 Network: [email protected] http://www.y12.doe.gov/sgml/sc34/ ftp://ftp.y12.doe.gov/pub/sgml/sc34/ Mr. G. Ken Holman (ISO/IEC JTC 1/SC 34 Secretariat - Standards Council of Canada) Crane Softwrights Ltd. Box 266, Kars, ON K0A-2E0 CANADA Telephone: +1 613 489-0999 Facsimile: +1 613 489-0995 Network: [email protected] http://www.jtc1sc34.org

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 [email protected] 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.

U2. TMCL must support selectors that do iterative constraint checking, applying restrictions to submaps.

U3. TMCL must support selectors that select topics by their type, and enforce constraints over the matching topics.

U4. TMCL should allow calculation on data that is number.

Some constraints may be enforced on the value of the particular topic characteristics, e.g., number calculation.

Example: A customer can only order a maximum value of $100. This constraint is explained further in section 4.1 of this document.

4.2 General Use Cases

This section provides use cases that are more high level than the those in the previous sections. It provides use cases that describe the wider application of TMCL to business problems and specific deployment domains. These constraints are intended to keep the big picture in mind when developing the low level building blocks of TMCL in order to support the data structure use cases.

4.2.1 Schema-driven presentation of information and introspection

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.

TMCL should support introspection

to generate storage representations for topic map data conforming to the schema that is less resource-intensive than generic storage representations
to optimize TMQL queries
to generate, or help generate, user interfaces and simplify editing of topic maps
to perform data binding from topic map data to programming language APIs.

4.2.2 Process for allowing applications to improve the topic map merging process

The presence of a TMCL schema may also allow applications to improve the results of merging topics/topic maps by providing enough information to allow implementations to do additional transformations and redundancy removal. See SAM issue merge-use-of-schemas and references to it.

http://www.ontopia.net/omnigator/models/topic_complete.jsp?tm=tm-standards.xtm&id=merge-use-of-schemas

5 Design Goals

5.1 Syntax for expressing constraints

TMCL will have at least one human-friendly syntax, preferably one based on XML. It may be based on XTM.

5.2 Standardized representation in topic map form

TMCL should have a standardized representation in topic map form using published subjects defined in the TMCL standard.

5.3 Use of TMQL to locate topic map constructs

TMCL will make use of TMQL to define both selectors and restrictions. In other words, TMCL will use TMQL to locate the topic map constructs or properties to be constrained and TMQL will use TMCL to identify particular situations with the task of TMQL only being the generation of output.

5.4 Model

The model for TMCL (Section 3, R3) will be useful in helping us to understand how TMCL makes use of TMQL to define selectors and restrictions.

Note: TMCL should support the validation of topic map data authored by humans.

5.5 Results of TM validation

The results of the validation should either be confirmation on that the topic map satisfy the given set of constraints or if any constraint is not satisfied then error messages should be given. This error messages may also include warnings, depending on the validation rules (Section 3 R7). Results of the validation may produce a virtual topic map.

5.6 Dependencies

The language should be based on the next version of ISO 13250 as defined by [N0323] and may also make use of ISO 18048 TMQL [N0249]. It may make use of XML Schema Part 2 Datatypes [xmlschema] and OWL [OWL].

6 Usage Scenarios

6.1 E-Commerce Application

E-Sell Corp. has many local offices, some of them large and others small, that all maintain their own customer and order databases. In order to provide unified access to all of these, E-Sell plans to use Topic Maps. The contents of the various databases, which all have slightly varying schemas, will be mapped into Topic Maps which will then be merged. Some information may also be authored in topic map form. In order to ensure consistency across all these topic maps, they must be constrained to follow certain structural rules.

A typical solution for knowledge management is a relational database. The following ER diagram shows how the information should be represented in a relational database.

This particular ER diagram can be represented as a Topic Map. The mapping will be from a relational database to topic map document (note that this is only a suggested mapping).

The entities, as shown on the ER diagram, are customer, product, and order.

Each customer is represented by a topic that has the topic-type customer. Attributes of the customer can be represented as the topic characteristics. Customer name is represented as the topic's basename, address as topic's occurrence, and the email address as topic's occurrence as well. In addition to that, customer may also have a customer id that may be represented as both occurrence and subject identifier.

Each product is represented by a topic that has the topic-type product. Attributes of the product can be represented as the topic characteristics. The product name may be represented as basename, and the product price can be represented as an internal occurrence. The product id can be represented as both an occurrence and a subject identifier.

Each order is also represented by a topic that has the topic-type order. Attributes of the order can be represented as the topic characteristics. Order ID is represented as both occurrence and subject identifier.

The relationship between the entities, as shown on the ER diagram, are orders and contains.

Each relationship may be represented by an association. The relationship orders may be represented as an association of type is-making-order with two association roles customer and order. The relationship contains can be represented as association with association-type contains with at two association roles order and product.

After designing the topic map structure for this particular application, constraints or rules should be defined to ensure the consistency of data contained within the topic map document. Several possible constraints for this particular topic map document can be defined.

Each customer must have customer id, name, and address, but email address may be optional.
Each product must have the product id, name, and price.
Each order must have order id.
The association is-making-order must have the role customer played by one player and role order played by at least one player.
The association contains must have the role order played by one player and role product played by at least one player.

Many more constraints will be required to limit and ensure the consistency of the data contains in the topic map document.

These constraints for a topic map document should be able to be represented in Topic Map Constraint Language. Therefore, TMCL in this particular application must be able to define the following constraints.

Constraints for the entity customer
- For all topic that has the topic-type customer, it must have a basename (for customer name), occurrence (for address), subject identifier (for customer id), and optionally additional occurrence (for email address).
- Basename (for customer name) must follows the pattern "first-name middle-name last-name" where the middle name is optional. Therefore the basename value must contain at least two words.
- Occurrence (for address) must be of type address and also scope in Australia.
- Subject identifier (for customer ID) must not contain any spaces or any illegal characters (as defined).
- Occurrence (for email) must be of type email and contain the @.symbol.
- Topics that has the topic-type customer can only play a role in one association of type is-making-order.
Constraint for the entity product
- For all topic that has the topic-type product, it must have a basename (for product name), internal occurrence (for product price), and subject identifier (for product id).
- Internal occurrence (for product price) must be of type price where the value is a double (data type constraint).
Constraint for the entity order
- For all topic that has the topic-type order, it must have a subject identifier (for order id).
- Each topic that has the topic-type order must play a role in the association with association type contains.
- Topics that has the topic-type order can only play a role in one association of type contains.
Constraint for the relationship orders
- For all association with association type is-making-order, it must have the association roles customer and order played by the topic that is of type customer and order respectively.
- The role customer can be played by only one player.
- The role order can be played by one or more players.
Constraint for the relationship contains
- For all association with association type contains, it must have the association roles order and product played by the topic that is of type order and product respectively.
- The role order must be played by only one player.
- The role product must be played by one or more players.
Miscellaneous
- The topic is-making-order can only be an association type.
- The topic contains can only be an association type.
- The topic customer can be a topic type or association role.
- The topic order can be a topic type or association role.
- The topic product can be a topic type or association role.

Business rules may also be represented in TMCL, for example, a customer may order up to maximum of $100. The is-making-order association which has all the orders that a customer makes, should help ensure this. Therefore for all the topic playing the role order, should calculate the total order and make sure it does not exceed the $100 limit.

E-Sell Corp.'s local offices may update their database from time to time, and these changes have to be incorporated to the topic map construct. These updates may include price list updates, new customers, new products, etc.

Incoming data need to be added to the current topic map construct. In order to keep the consistency of the current topic map, the new data needs to be validated to check its consistency. The new data can be added manually to the topic map construct via an authoring interface. Another option is to construct a topic map document for the new data and then merge it with the current topic map construct.

If the incoming data is in a topic map construct, then merging should take place. This incoming topic map TM2 may have constraints C2 define for itself, but it has to be validated against the constraints of E-Sell topic map constructs C1 before or during the merging process. The constraints C1 and C2 need to be merged along the merging of the topic maps documents. The merging of constraints is completely independent to the merging of topic maps, it is up to the author to decide whether the constraints merging is required.

Within E-Sell topic map constraints, the constraint language should be able to define the merging rules. During the merging, TMCL is able to filter "bad" data and only add the necessary data to E-Sell topic maps document.

If the incoming data is then added manually to the topic map document, then we need to edit the current document. TMCL should act as a template, and the editor is schema-based. Any changes that is done to the current document is done through a schema-based editor. Any changes that does not satisfy the template will be rejected therefore the topic map document is kept valid even after editing.

E-Sell Corp.'s product database is currently in relational database. These products are grouped in different product categories and currently E-Sell is facing a problem with adding a new product category, since different product categories requires different information to be kept in the database.

Products may have categories, and each category relates to a set of product characteristics. These categories are

television, with characteristics such as type, brand, size (in inch), channel options, etc.
microwave, with characteristics such as type, brand, size (in liter), heat options, etc.
refrigerator, with characteristics such as type, brand, size (in liter), freezer, meat keeper, vegetable keeper, etc.

Each E-Sell's product has different characteristics that are related only to a particular category. Modelling this in a relational database can be very ugly, therefore native topic map storage may provide a proper solution. Adding new category in topic map can be strictly easy and a different product category may have specific constraints imposed on it.

A new product category is just another topic with required characteristics. The constraint language can help us define which characteristics this particular product category must have and it can also define the merging rules.

7 Non-Requirements

7.1 TMCL WILL NOT specify

7.1.1 When these constraints are applied

7.1.2 Constraint of Topic IDs

7.1.3 Ordering of topic map constructs or the application of other similar syntactic constraints

7.1.4 Explicit typing of vocabulary for domain or vertical markets

However; these may be used for illustrative purposes in usage scenarios.

7.1.5 Vertical market vocabularies as published subjects

[Issue 2] If a vocabulary is not within the scope of TMCL then how is the vocabulary merged with the schema? An ontology is the vocabulary plus its structure. TMCL would not include these in the specification but could possibly recommend other standards bodies to create these published subjects for public use.

7.1.6 Formalized mechanism to 'register' typing of domain vocabularies

The TMCL will not require the use of any any registry or repository.

7.1.7 Test Suite

It is recommended that a test suite be developed, but it will not be within the scope of this ISO project of work. However, we encourage other standards bodies such as OASIS to consider it.

If a suite were developed, it could possibly consist of a set of topic maps and schema and a superstructure that tells you

which combinations of topic maps and schema should validate,
which ones should not,
which schema constrain syntax errors, and
which schema contain semantic errors.

8 Risks

The progress of TMCL development rests on dependencies on the topic map family of standards [N0323] [N0388] and may be also be dependent on the Web Ontology Language [OWL] and XML Schema Part 2: Datatypes [W3C Schema]. As these standards progress so does TMCL development. With changes in dependent models such as the data model for Topic Maps, XTM Syntax specification,and TMQL, backwards compatibility must always be kept in mind to ensure integration with all standards TMCL is dependent on.

9 Contributors

We are indebted to Lars Marius Garshol, Steve Pepper, Robert Barta, Erica Santosaputri, Kal Ahmed, Bernard Vatant, Eric Freese, Anthony B. Coates, and members of [email protected] and irc.//irc.freenode.net/#topicmaps for the source of requirements and Use Cases, and discussions of this draft. Special thanks goes to Erica Santosaputri for providing the use case examples and usage scenario.

10 References

[13250] ISO/IEC 13250:2002 Topic Maps, ISO, Geneva, 2002.
[N0221] New Work Item Proposal, Topic Map Constraint Language, with acceptance criteria, ISO/IEC JTC1 SC34 N0221. 23 May 2001.
[N0226] Draft Requirements, examples and a "low bar" proposal for Topic Map Constraint Language, ISO/IEC JTC1 SC34 N0226
Steve Pepper, 24 May 2001.
[N0259] Summary of Voting on SC 34 N 226 - CD Ballot for Topic Map Constraint Language (ISO/IEC JTC1 Project 19756 - TMCL), ISO/IEC JTC1 SC34 N0259. 4 October 2002
[N0249] TMQL requirements (1.0.0), ISO/IEC JTC1 SC34 N0249. Hans Holger Rath and Lars Marius Garshol, 29 August 2001 .
[DM] Topic Maps -- Data Model, ISO/IEC JTC1 SC34 N0443. Lars Marius Garshol and Graham Moore, 22 October 2003.
[OWL] Web Ontology Language (OWL) Guide, W3C Candidate Recommendation. Michael K. Smith, Chris Welty, and Deborah McGuinness, World Wide Web Consortium. 18 August 2003.
[W3C Schema] XML Schema Part 2: Datatypes W3C Recommendation, Paul V. Biron and Ashok Malhotra. World Wide Web Consortium. 10 May 2001.
[RFC 2119] Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. Network Working Group, Internet Engineering Task Force. March 1997.
[N0323] Guide to the topic map standardization process, ISO/IEC JTC1 SC34 N0323. Lars Marius Garshol, 23 June 2002.
[N0388] Summary of Voting on SC 34 N0358 Restatement of Topic Maps, ISO/IEC 13250:2002 ISO/IEC JTC1 SC34 N0388. 26 March 2003.
[XMLinfoset] XML Information Set, W3C Recommendation. J. Cowan and R. Tobin, Editors. World Wide Web Consortium. 24 October 2001.
[relax-ng] RELAX-NG Specification , OASIS Committee Specification. James Clark and Makoto Murata, Editors. Organization for the Advancement of Structured Information Standards. 3 December 2001.
[dsdl] Document Schema Definition Languages, ISO/IEC JTC1 Project 19757 - DSDL. 4 December 2002.