---

Extended comments on N596 (Norway)

General comments

Terminology

#1. The term "class" occurs twice in the document, but should perhaps be replaced with "type", since TMDM deliberately avoids "class".

#2. The term "subject address" is used in the document, but TMDM uses "subject locator". This should be updated.

#3. The term "member" is used in the document, but TMDM uses "association role". This should be updated.

Notation

#4. In general the notation used to define the model could do with some explanation or definition before it is used. The notation in general is unclear to many readers, as is the purpose of the '#' character in particular. Maybe it could be changed to something like:

  TopicSchema:
    type : TopicIdentification         # identifies type of topics
    subjectAddressSchema : URISchema*  # constraints subject ...
    etc etc

Alternatively, one could use the infoset formalism in the same way that TMDM does.

#5. The parts of a schema that are used for matching throughout should be indicated typographically, for example with bold or italics.

Conflicts

#6. The document does not define a notion of conflicts between constraints, which may not be required in itself, but if schemas are to be mergeable this will be required. One approach might be to define a notion of conflict inside a single schema, and to make conflicts on merge be detected simply by saying "merge schemas, then detect conflicts within merged schema using usual approach".

Conflicts probably cannot be detected for TMCL-Rule, but they can for TMCL-Schema, and so perhaps they should be?

New features

Subclassing

#7. The interaction of TMCL with supertype/subtype associations in the topic map are not specified. Also, should it be possible to demand that a type be a subtype of another? Or at least make it clear that it is so in the schema? Obviously, this interacts with composability.

#8. Another issue is whether it should be possible to subclass characteristic types (association, association role, and occurrence types). Again the question is how information in the topic map interacts with information in the schema.

Merging rules

#9. TMCL needs some way of indicating which values (or combinations of values) are unique. This has been referred to as "merging rules" in the past, but it is not clear that for a TMCL schema to modify the topic map is necessarily a good idea. It may be better to just have rules for what needs to be unique, with defined ConflictItems (or WhateverItems), so that users/application can decide how to resolve the problem.

Computed properties/relationships

#10. In Amsterdam in May 2004 there was talk of adding features for computed properties (given date of birth for a person, we can compute their age) and computed relationships (effectively inferencing rules, a la tolog). There is no mention of this here. Has it been dropped, or is to come?

Reification

#11. There is no support here for constraining the topics that reify topic characteristics. For example, it cannot be expressed that topics reifying "employment" associations must be of type "employment" and have "contract" and "start date" occurrences.

Schema modularity

#12. Functionality needs to be added that lets a schema from one source be extended/modified by reference from another schema.

Constraints on external resources

#13. The issue of constraints on external information resources (MIME type, size, etc) has been raised. Probably the requirements document should be updated to state specifically that such constraints are out of scope for TMCL.

TMCL-RELAX

#14. In Amsterdam in May 2004 there was discussion of modifying TMCL-Schema to allow users to specify which properties in a partial schema are selectors and which are constrainers, in order to provide greater expressivity. The editors have since expressed concern that this may be providing too much power. Could a compromise be struck by providing this only for TopicSchema and AssociationSchema, but not for other schemas, such that some of the benefit is provided, without incurring all of the complexity.

Syntaxes

#13. Perhaps the time has come to add these? That is, compact syntax, and topic map representation. Do we really want an XML syntax?

#14. TMCL should be used to constrain the topic map representation of TMCL.

Detail comments

General

#15. Perhaps cardMin and cardMax should be optional throughout, with specified defaults? Or perhaps that belongs in the syntax?

TopicMapSchema

#16. What is the SchemaID? That is, is it a string, an integer, a URI, a PSI, or something else? Does it relate to the TMDM in some way? Does it relate to the TMCL syntax in some way? etc

#16. What is the Name? Is it metadata about the schema? Is it a simple string? Can it be scoped?

#17. Is ID and name all the metadata we want to standardize about schemas? Should people be allowed to use topic maps to make arbitrary statements about schemas? Do we want to standardize some of these statements?

#18. Should the Include be in the model? In TMDM we left mergeMap for the syntax. Should TMCL do the same?

TopicIdentification

#19. Are these URIs relative or absolute? If they are relative, what are they relative to? Should it be possible to use source locator URIs here that are relative to the base locator of the topic map? (If the answer is "no" it means that a TMCL schema that uses source locator will be bound to a topic map at a particular location, and that it won't be portable.)

#20. The name srcLocators should perhaps be sourceLocators?

#21. What happens if this matches more than one topic?

#22. Does TMCL assume that different TopicIdentification items always match different topics in the topic map? (In theory it could happen that two different TopicSchemas in the schema wind up matching the same topic type.)

ScopePattern

#23. There are some typos in the comments here.

#24. Is the OrTopicExpression really needed?

#25. What combinations of alternatives is allowed here?

TopicSchema

#26. Is the SchemaID only for the topic schema or for the parent topic map schema? If the former, is it preferrable to have an identifier for the topic schema as distinct from the topic type constrained by the schema?

#27. The subjectAddress property should be called subjectLocator.

#28. The subjectIdentifier property should be called subjectIdentifier.

#29. Is the cardinality on match in SubjectLocatorSchema and SubjectIdentifierSchema right? Wouldn't it be much simpler to keep this as a single match? If multiple matches have the same cardinality that can just be represented using multiple schemas.

#30. What happens if, during matching, no matching topic is found for the type? What happens if it has no instances?

#31. Is it possible to constrain topics which are not instances of any type?

#32. What happens with topics which are instances of a type which is not mentioned in the schema?

SubjectIndicatorSchema

#33. Here the cardinality indicators suddenly moved into the comments...

BaseNameSchema

#34. In TMDM topic names do not have a datatype, so dataType can be removed.

#35. Should this be called TopicNameSchema?

InteralOccurrenceSchema

#36. Now that TMDM has datatypes, maybe this can merge with ExternalOccurrenceSchema?

OneOfSchema

#37. Is this really needed? Surely a property named "one of" of type TopicSet is enough?

RoleSchema

#38. This section, plus the two following, begins: "ConstrainTs the nature of..."

PlaysRoleSchema

#39. Is otherRoleType really needed? What does it do? The same applies to otherPlayersSchema.

AssociationSchema

#40. It is not clear what AssociationSignatureSchema does. More information would help.

Syntax for TMCL-Schema

#41. An example would be very useful here.

TMCL-Schema Introspection

#42. Is this really suitable for standardization? If it is, it's not clear how it does whatever it does. Is there any difference between this and using TMQL on the topic map representation of TMCL-Schema?

Interpretation of TMCL-Schema

#43. This seems less formally grounded than it could be. What syntax is used? Is it meant to be TMQL?

TMCL-Rule

#44. Would it be cleaner to integrate this into TMCL-Schema, but specify how to know whether a schema fits inside the TMCL-Schema subset? This way one could have rules on the topic map as a whole, but also on individual TopicSchemas and AssociationSchemas.

RuleItem

#45. Does this really need to be so complex?