ISO/IEC JTC 1/SC34 N0405

ISO/IEC JTC 1/SC34

Information Technology --

Document Description and Processing Languages

Title: Topic Map Constraint Language Requirements
Source: Mary Nishikawa, Graham Moore, JTC1/SC34
Project: JTC 1 NP Number – ISO/IEC 19756 Topic Map Constraint Language
Project editor: Steve Pepper
Status: Draft
Action: For Review and Comment
Date: 2003-Apr-04
Summary:
Distribution: National Bodies and Liaisons of SC34
Refer to:
Supersedes: N226 Draft Requirements, examples and a "low bar" proposal for Topic Map Constraint Language
Version: $Id: requirements.html,v 1.8 2003/04/04 14:47:02 mariyo Exp $

Requirements for a Topic Map Constraint Language JTC 1 NP Number – ISO/IEC 19756

1. Background

The ISO JTC1 SC34 Project for a Topic Map Constraint Language was voted and approved on 2001-10-5. The NP vote can be found in ISO/IEC JTC 1/SC34 N259, along with the National Body comments on N226 Draft Requirements, examples and a "low bar" proposal for Topic Map Constraint Language. 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 N226 were made based on the comments received from National Bodies on N226, plus additional comments gathered from [email protected] and discussions on irc://irc.freenode.net/#topicmaps.

2. Introduction

2.1 Purpose and Scope

Topic Map Constraint Language (TMCL) will provide a means to express constraints on classes of topic maps conforming to ISO/IEC 13250:2000; these will be over and above the constraints currently defined by the Standard Application Model (Data Model for Topic Maps). Its goal will be to provide a language such that a topic map can be said to be conforming within a topic map or within a class of topic maps. It may help optimization both of topic map storage and of TMQL queries based on schema information. It may aid applications in providing more intuitive user interfaces for creating and maintaining topic maps.

This document will define the requirements that we expect the language will provide.

TMCL shall be specified in terms of SAM (Standard Application Model for Topic Maps), a data model, and will not be specified on any serialization format for topic maps. This will automatically allow it to support both XTM and HyTM as well as LTM and AsTMa=, since these all have mappings to SAM.

TMCL is to be developed by ISO/JTC SC34 WG3 and this requirements document is for members of the committee and implementors who have expressed an interest in the development of a Topic Map Constraint Language.

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].

A TMCL constraint is a requirement that information items which match a given criterion (called the selector) must also match a second criterion (called the restriction). A restriction placed on a topic map construct is used to confine or narrow the semantics of the construct or to further define cardinality and data types where they had not been defined within the topic map model. A constraint also enables extensions to the model by specifying explicit typing patterns.

"Topic map constructs" are the topic characteristic assignments described in [SAM].

"TMCL schema" can be defined as a collection of constraints (defined using TMCL) used together for some purpose. It might be the constraints that together define the use of a vocabulary or the constraints that define the input accepted by an application (Lars Marius Garshol).

"System of typing patterns" refers to the set of type definitions that are applied consistently within a topic map or merged sets of topic maps. In some knowledge domains this may be referred to as an ontology. See the definition of ontology in [OWL] for a further explanation of current usage of the term.

"Schema Introspection" is the ability to read in a schema description or create one from scratch, manipulate it, access all useful information and write it back out (Paul Prescod).

"Constraint reification" is ability to represent a constraint as topics in some topic map (it can be a "system" topic map which is different from "main" topic map which we apply constraints to). "Constraint reification" allows the assignment of different characteristics to constraints. It also allows us to define "types" of constraints explicitly (Dmitry Bogachev).

2.3 References

  1. [13250] ISO/IEC 13250:2002 Topic Maps, ISO, Geneva, 2002.
  2. [N221] New Work Item Proposal, Topic Map Constraint Language, with acceptance criteria, 2001-05-23, ISO/IEC JTC1 SC34 N0221.
  3. [N226] Draft Requirements, examples and a "low bar" proposal for Topic Map Constraint Language, Steve Pepper, 2001-05-24, ISO/IEC JTC1 SC34 N0226.
  4. [TMCL] Summary of Voting on SC 34 N 226 - CD Ballot for Topic Map Constraint Language (New JTC 1 NP Number - ISO/IEC 19756), 2002-10-04, ISO/IEC JTC1 SC34 N0259.
  5. [N249] TMQL requirements (1.0.0), Hans Holger Rath, Lars Marius Garshol, 2001-08-29, ISO/IEC JTC1 SC34 N0249
  6. [TMQL] Summary of Voting on SC 34 N 226 - CD Ballot for Topic Map Query Language, 2001-05-07.
  7. [SAM] The Standard Application Model for Topic Maps, Lars Marius Garshol, Graham Moore, 2002-12-04, ISO/IEC JTC1 SC34 N0356
  8. [OWL] Web Ontology Language (OWL) Guide Version 1.0, Michael K. Smith, Chris Welty, Deborah McGuinness, 2003-02-10.
  9. [XML Schema] XML Schema Part 2: Datatypes W3C Recommendation, Paul V. Biron, Ashok Malhotra, 2001-05-10.
  10. [N323] Guide to the topic map standardization process, Lars Marius Garshol, 2002-06-23, ISO/IEC JTC1 SC34 N0323.
  11. [N388] Summary of Voting on SC 34 N 358 – Restatement of Topic Maps, 2003-03-26, ISO/IEC 13250:2002 ISO/IEC JTC1 SC34 N0388.
  12. [RFC 2119] Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, March 1997.
  13. [TMCL Use Cases] Use Cases for TMCL Requirements, Erica Santosaputri, in progress.

3. Overview of TMCL Requirements

3.1 Dependencies

Pre-existing specifications and established best practice for knowledge representation and data modeling will contribute to the functional requirements. It will be based on the next version of ISO 13250 as defined by [N323] and may also make use of ISO 18048 TMQL [N249]. It may make use of [XML Schema] Part 2 and OWL.

3.2 TMCL MUST specify

3.2.1 Typing constraints

TMCL must support selectors that

3.2.1.1 Constraints by association type

These may include but are not limited to selectors that

3.2.1.2 Constraints by topic type

Some examples include

3.2.1.3 Constraints by occurrence type

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

3.2.1.4 Constraints by association role type

These are most likely selectors that

3.2.1.5 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.

Editor's note: the categories By Theme and By Scope were reduced to this one category. Is it sufficient? Comment from UK national body was, Change "which topics can be used for scoping" to "which topics can be used as added themes" Since the term "theme is no longer in use, how should this be described?

3.2.2 Cardinality constraints

Cardinality will be defined for

3.2.3 Data typing constraints

The ability to data type occurrence values will be provided. A subset of data types Part 2 of W3C XML Schema shall be used. The language may also provide for the use of an extensible type system.

[ISSUE 1: Use W3C XML Schema Part 2 datatypes, a subset, or allow extensions?]

3.2.4 Syntax for expressing constraints

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

3.2.5 Some form of controlled combination of schemas or merging of schemas

This includes the merging of schemas, but also the possibility for one schema to build on or extend another.

3.3 TMCL SHOULD specify

3.3.1 Validation and exceptions

TMCL should define set of validation exceptions and should be unambiguous as to what validation exceptions are possible. It should define the semantics of validation and related set of validation exceptions. Two levels of validation for topic map constructs should be defined: strict and loose. The levels of validation shall be directly expressed on the topic or association type.

3.3.1.1 Strict (closed) validation: Strict 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.

3.3.1.2 Loose (open) validation: Allow relaxation for some of the rules specified for the strict validation.

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

3.3.1.3 Representation of complex validation rules (Source: Dmitry Bogachev)

TMCL should allow

TMCL should include basic constructs for making statements about

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

TMCL should allow us to specifying that topic, name or occurrence is a "one of" element of a specific set of topics (values).

TMCL should allow us to represent constraints which can target and describe domain dependencies between multiple topics, names, occurrences and associations at the same time.

TMCL constraints should allow validation on an existing known set of topic map items (topics, names, occurrences, associations) using not more than "isa" and "type-subtype" - based inference.

Comment: Topic Map authors do not need to explicitly specify "all types" of which the topic is an instance of. A constraint engine can "infer" other (super)types for specific instances. All other assertions have to be represented explicitly in a topic map. There is no additional "inferencing" during validation and there are no modifications to the basic topic map.

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 allow the assignment of different attributes to constraints which can be used for managing constraints and also for optimization of the constraint engine.

Example: Attribute "average validation time" can help an engine to optimize validation when resources (time) are limited.

TMCL may allow constraint reification as topics (see definition in section 2.2).

3.3.2 Internal consistency checking

It will check that the topic map is internally consistent with its own defined pattern of typing according to a controlled vocabulary.

3.3.3 Schema-driven presentation of information (Source: Dmitry Bogachev) and introspection (Lars Marius Garshol)

The TMCL should support introspection (Source: Lars Marius Garshol)

 

3.3.4 Standardized representation in topic map form

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

3.4 TMCL MAY specify

3.4.1 Use of TMQL to locate information items (Source: Lars Marius Garshol)

TMCL may make use of TMQL to define both selectors and restrictions. In other words, TMCL may use TMQL to locate the information items or properties to be constrained or TMQL may use TMCL to identity particular situations with the task of TMQL only being the generation of output

3.4.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 result 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

3.4.3 Model

A model may be created. It may be usful in to help us understand how TMCL makes use of the TMQL to define selectors and restrictions.

4 Non-Requirements

4.1 TMCL WILL NOT specify

4.1.1 When these constraints are applied

4.1.2 Constraint of Topic IDs

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

4.1.4 Explicit typing of vocabulary usage for domain or vertical markets

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

4.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? A set of typing patterns (ontology) is the vocabulary plus the structure.

4.1.6 Formalized mechanism to 'register' typing of domain vocabularies

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

4.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

5 Use Cases

Examples for the requirements in Section 3.2 can be found in [TMCL Use Cases]. The requirements and use cases will be amended as the language develops.

 

6 Risks

The progress of TMCL development rests on dependencies on the topic map family of standards 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 Standard Application Model, XTM Syntax specification,and TMQL, backwards compatibility must always be kept in mind to ensure integration with all standards TMCL is dependent on.

7 Contributors

We are indebted to Lars Marius Garshol, Steve Pepper, Robert Barta, Erica Santosaputri, Dmitry Bogachev, 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 discussions of this draft.