| 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 $ |
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 tmcl-wg@isotopicmaps.org and discussions on irc://irc.freenode.net/#topicmaps.
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.
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).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.
TMCL must support selectors that
These may include but are not limited to selectors that
Some examples include
These may include but are not limited to valid combinations of locator (URI pattern), scope, and parent topic.
These are most likely selectors that
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?
Cardinality will be defined for
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?]
The TMCL will have at least one human-friendly syntax, preferably one based on XML. It may be based on XTM.
This includes the merging of schemas, but also the possibility for one schema to build on or extend another.
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
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).
It will check that the topic map is internally consistent with its own
defined pattern of typing according to a controlled vocabulary.
The TMCL should support introspection (Source: Lars Marius Garshol)
TMCL should have a standardized representation in topic map form using published subjects defined in the TMCL standard.
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
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
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.
However; these may be used for illustrative purposes in usage scenarios.
[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.
The TMCL will not require the use of any any registry or repository.
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
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.
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.
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 tmcl-wg@isotopicmaps.org and irc://irc.freenode.net/#topicmaps for the source of requirements and discussions of this draft.