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?
