ISO/IEC JTC 1/SC 34N0645
ISO/IEC JTC 1/SC 34
Information Technology --
Document Description and Processing Languages
TITLE: | Amsterdam 2005 meeting notes for CD 19756: Topic Maps -- Constraint Language |
SOURCE: | Mr. Steve Pepper |
PROJECT: | CD 19756: Information Technology - Topic Maps - Constraint Language (TMCL) |
PROJECT EDITOR: | Mr. Dmitry Bogachev; Mr. Graham Moore; Ms. Mary Nishikawa |
STATUS: | Meeting notes |
ACTION: | For information |
DATE: | 2005-05-26 |
DISTRIBUTION: | SC34 and Liaisons |
REPLY TO: |
Dr. James David Mason (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 |
TMCL Comments
TMCL Schema comments
- TMCL should provide ability to specify exceptions when we use "for every X" construct.
- Schema has "include" property now. Should it be in TMCL model or outside (syntax only)?
- TopicIdentification. Add constraint that only one topic should be returned.
- ScopePattern. Clarify relationship with TMDM implementation
- SchemaID. Clarify what is that. Also clarify how we find parent of a schema item.
- Clarify in schema description what is a selector and what is a constraint. For exaample, type, scope, association template are selectors. Need clear notation for expressing this as well as description in prose.
- BaseNameSchema
- dataType -> delete
- oneOf -> delete
-
VariantSchema
oneOf -> delete
-
InternalOccurrenceSchema
minExclusive -> looks like it is complex -> should be deleted
* . Merge Internal and External Occurrence into one structure
- OneOfSchema -> replace with topicset as property
- PlayRoleSchema -> delete otherPlayers
- Clarify meaning of a scope in schemas: is it selector or constraint?
-
Association
Discussion of SchemaID -> let's have it
AssopciationSignature is too complicated, it promotes bad ontology. delete Association signature
-
RoleSchema
OneOf requires additional investigation
-
ExistsAtLeast
Investigate integration with TMQL, clarify scope matching
-
Introspection
Delete section. TMCL-Schema will have standard Topic Map-based representation. Introspection will be achievable using regular TMQL.
TMCL-Rules comments
-
TopicMapSchema
Notification is useful concept but current approach is too heavy.
Alternatives:
- Topic Map Schema level
- Topic Schema + modes
- pattern + modes
-
Diagnostic Item
It should exists at syntax level only
-
ContextItem
Requires simplification.
Replace ContextItem with expression with free variables. It is a selector.
Consider to look at message section as "return" section in TMQL.
In this case it can return XML, strings and Topic Maps
-
ConflictItem, NotificationItem
Consider to have only one type of ConflictItems with additional attributes, such as mode
Additional constraints
- Add super-type - sub-type constraints (as constraints, not facts)
- Add uniqueness constraints for names, occurrence and associations. Example: capital should be unique
- Add reification constraints
- Ignore idea of external resources constraints.
- Add disjoint constraint.
- Investigate "Same subject" constraint
- Describe schema->model>schema transformation
- Add section "Detecting schema conflicts"
Main tasks for next draft
- Port Schemas to UML and Infoset
- Provide formal schema interpretation based on basic constraints