[sc34wg3] TMCL-WG Summary of Contributions

[Mary Nishikawa]

Hi,

Thank you very much in providing initial feedback on the TMCL. I am very 
encouraged to work with such an enthusiastic and knowledgeable group of 
people.  If I missed your comments, or misrepressented anything please 
forgive me and correct it immediately!

I have compiled most if not all of the points discussed on and agreed to on 
the TMCL-WG list so far and placed some additional information into a 
Requirements Specification Template based on IEEE Standard 830-1993. 
Various ideas on specific functional requirments had already been proposed, 
but they are not included here.

What is also not included here are various TMCL ideas and discussions that 
have taken place on the SC34WG3 or topicmapmail lists.

If you want to contribute to TMCL, please do so through the TMCL-WG list. 
Thanks.

I will send out a separate request for functional requirements and how to 
submit these.

This is in a pre draft state. After receiving your contributions of 
functional requirements, and other necessary additions this will become a 
working draft. Please comment and suggest content for missing parts or 
categories that are not needed. Thank you.

Cheers,
Mary

---------------------------------
Requirements for a
Topic Map Constraint Language (TMCL)

Source: TMCL-WG
Rrequirement Editors: Graham Moore, Mary Nishikawa
Project Editor: Steve Pepper

1. Introduction

1.1 Purpose of the document

What is the goal of the project?
What is the purpose of having a TMCL?
Who Should read this document?


The Topic Map Constraint Language (TMCL) will  provide a means of 
validation over and above the constraints currently defined by the Standard 
Application Model. It's goal will be to ensure consistency within a topic 
map or within a class of topic maps.

It may provide more intuitive user interfaces for creating and maintaining 
topic maps.


1.2 Scope of the Language

Exactly what are you specifying?
What will not be specified?
Are there any limitations?

WHAT IT MUST SPECIFY

The TMCL must define a standard way to explicitly indicate how information 
item types and properties as defined in the Standard Application Model for 
Topic Maps are to be constrained.

TMCL shall be specified in terms of the SAM.  This will automatically allow 
it to support both XTM & HyTM s well as LTM and AsTMa=, since these all 
have mappings to the SAM.

WHAT IT MAY SPECIFY

TMCL  may be  based on an XML syntax using XSDL/DTD/DSDL, or
in the very least one informative syntax would be provided.

This may include

   - a fully-fledged expression language
  a) TMCL shall support detailed constraints through the use of an
     expression language.

   - a more down-to-earth 'lite' version for those who live more on the
     template level
  b) TMCL shall support simple declarative constraints that do not
     require the use of an expression language.

  c) The expression language used in TMCL shall be TMQL, or a suitable
     subset thereof.

It may also  include but is not limited to the following.

Definitions of Classes and relationships of Classes and Instances:
Explicily indicate topics as classes
Describe relationships as classes
Describe kinds of classes
Represent regularities about class instances
Represent partially known information about instances

Cardinality:
Cardinality of infomation item types and properties

Data Typing:
Provide data typing not currently defined in the SAM.

Validation and Exceptions:
Define which topic map information  item types and properties are allowed 
(Validity constainst beyond what has already been defined by the SAM.)
Allow any topic map instance element to be constrained, ie, not just topics 
and associations, but names resource references, variants, etc.

1. Must define set of validation exceptions and should be unambiguous as to 
what validation exceptions are possible
2. Define the operational semantics of validation and set of validation 
exceptions.

Application of the constraint language without a validation requirement
The schema may imply templating  or prototyping but does not necessarily 
require validation.

Application of the constraint language with validation.

(May or may not be a validation requirement?)

Issue: Seems to be a need to define a validating (strict) versus loose 
validation or non validating.
We need to define these if we think that they are important.

Some definitions from posts:

Strict validating topic map application MUST ensure that only instances of 
schema constructs exist in the map, ie only topics of types defined inthe 
schema can exist and that all constraints defined arre conformed to in the 
topic map.

A validating topic map application MUST ensure that any structure tht can 
be constrained conform to the constraints of the schema.

ISSUE:  Why should we have two different conformance levels?

If we had two levels of validation, what would they be?


Use of TMQL
The TMCL should make use of the TMQL. The TMCL may use the TMQL to locate 
the information item or property to be constrained or the TMQL may use the 
TMCL to identity particular situations and the task of TMQL is only to 
generate output.

The TMCL may use schema information to create a UI or "template."

Use of Topic Map Published Subjects indicators


WHAT IT WILL NOT SPECIFY

TMCL shall not be specified in terms of  any serialisation format for topic
maps.

It will not state when these constraints are applied.

It will not define domain or vertical market ontologies however these may 
be used for illustrative purposes in usage scenarios.

Any information item types or properties that are not defined as part of 
the Standard Application Model will not be specified by the Topic Map 
Constraint language.


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

Definition:  Validity constraints defined by TMCL versus XTM.dtd

Definitions of ontology and metamodel

From: Pidcock, Woody
Sent: 13 January 2003 22:42
Subject: DRAFT Ontology FAQ

An ontology is a controlled vocabulary and a grammar for using that
vocabulary to express something meaningful within a specified domain of
interest.  The grammar contains formal constraints (e.g., specifies what it
means to be a well-formed statement, assertion, query, etc.) on how terms in
the ontology's controlled vocabulary can be used together. People make
commitments to use a specific ontology for a specific domain of interest.
Enforcement of an ontology's grammar may be rigorous or lax.  Frequently,
the grammar for an ontology is not completely specified, i.e., it has
implicit rules that are not explicitly documented.

A meta-model is an explicit model of the constructs and rules needed to
build specific models within a domain of interest.  A valid meta-model is an
ontology, but not all ontologies are modeled explicitly as meta-models.  A
meta-model can be viewed from three different perspectives:
(1) as a set of building blocks and rules used to build models
(2) as a model of a domain of interest, and
(3) as an instance of another model.


Editor note: need to collect definitions as required.

1.4 References

Editor note: need to collect references as required.


2. Overview of the TMCL Requirements

2.1 TMCL Perspective

Describe the relation to other Topic map standards, the XML infoset and any 
other standards or recommendations.

  Pre-existing specifications and established best practice for knowledge 
representation and data modeling will contribute to the function requirements.
These include OWL, DAML/OIL, KIF, OKBC,OCL, PAL (Protege Axiom Language), 
and XML Schema. Some aspects of TMCL my depend heavily on one or more of these.


2.2 TMCL Functions

Describe the Main functions that the TMCL must perform

2.3 User Characteristics

Who will use the language?  ---
Implementers writing interfaces (expression language) data modelers, 
designers of system ontologies

2.4 General Constraints

Describe limitations and Constraints

2.5 Assumptions and Dependencies

List factors that can  affect the requirements. What if changed, will 
change the requirements.

3. Specific Requirements

3.1 Business Requirements (there was a reques to separate out business 
requirements from Functional requirements -- I don't have any business 
requirements now- unless I missed them.)

Business Requirement #1


3.2 Functional Requirements (These should be very specific and relate to 
the information items in the SAM.)

Functional Requirement #1
Source: Name person submitting the requirement.
Criticality: "MUST,"  "MUST NOT,"  "REQUIRED,"  "SHALL,"  "SHALL NOT," 
"SHOULD,"  "SHOULD NOT,"  "RECOMMEND," "MAY," and "OPTIONAL
Definition:
Information flow (how is the information flowing between parts?)
Process description (usage scenario)
Define Data constructs if any (data types, arrays, class fields, etc.)
data dictionary (A list of all data items in the function. Should at least 
have name and data type -- short explanation, life span acuracy, which 
functions or processes the data is used in.)

Functional Requirement #2
Source: Name person submitting the requirement.
Criticality: "MUST,"  "MUST NOT,"  "REQUIRED,"  "SHALL,"  "SHALL NOT," 
"SHOULD,"  "SHOULD NOT,"  "RECOMMEND," "MAY," and "OPTIONAL
Definition:
Information flow (how is the information flowing between parts?)
Process description (usage scenario)
Define Data constructs if any (data types, arrays, class fields, etc.)
data dictionary (A list of all data items in the function. Should at least 
have name and data type -- short explanation, life span acuracy, which 
functions or processes the data is used in.)


3.3 Classes (object-oriented)
NOTE:These are here to illustrate the usage scenarios described in 3.2 
Include syntax examples here too?

Can use some class examples that would refer to functional requirements 
described above.
We can use this section to clarify the context of the usage scenarios 
above. We may want to describe that  the constraint may be described at the 
schema level or application level and use pseudo code for the application 
level descriptions.

Source (Dymtry)
1. I see here something like that:
isa(instance:server,class:metaClass)

2. superclass-subclass is just basic relationship here. There are some
others:
isDefinedByInstances(
     class:Continent,
     instance:Eurasia,
     instance: Africa,
     instance:North_America,
     instance:South_America,
     instance:Australia,
     instance: Antarctica),
for example.

3. Personally, I see value in separating classes as basic, abstract  and
specializations. So I see here something like that:
isa(instance:server,class:metaClass),
isa(instance:server,class:basicClass),
subclass(subclass:basicClass,superclass:metaClass),
isa(instance:sqlServer,class:spesializationClass),
subclass(subclass:sqlServer,superclass:server)

4. Something like that:
eachHasToHaveResourceOccurrence(
     subjectClass:server,
     resourceClass:serverDescription),

eachHasToHaveDataOccurrence(
     subjectClass:server,
     resourceClass:installationDate,
     resourceDataClass:date),

eachDefinesClassRestrictionOnInstancePlayingRole(
     objectClass:server,
     objectAssociationRole: objectOfOwnership,
     associationClass:ownership,
     otherObjectAssociationRole:owner,
     otherObjectClassRestriction:itSpecialist)

5. Something like that:

hasCardinalityRestrictionOnNumberOfInstancesPlayingRole (
     instance:john3000,
     instanceRole:who,
     associationClass:hasSisters,
     restrictedRole:sisters,
     cardinalityRestriction:2)


3.4 Design Constraints
standards compliance,  limitations

3.5 Quality Attributes or Non Functional attributes

reliability
availability
security
maintability
portability
binary compatibility
usability
versioning
data updating
Resource utilization
serviceability
internationalization

3.7 Requirements for testing

Need to be described in a canonical syntax?

3.7 Non Requirements

Describe in detail what will not be addressed.

3.8 Risks