ISO/IEC JTC 1/SC34 N0407

ISO/IEC JTC 1/SC34

Information Technology --
Document Description and Processing Languages

U.K. National Body Comments on JTC1/SC34 N0393 -- Topic Maps Model (TMM)

The following comments were the result of an initial read through of this heavily revised text:

General Comment

The text refers to "this International Standard" and implies that conformance to this text is a requirement of the whole standard. However, TMM is proposed as just one part of a multipart standard, and there is no reason why conformance to parts other than this part should be conditional on conformance to this part. Wherever the term "this International Standard" has been used it should be replaced by "this part of ISO 13250:200n".

Specific Technical Comments

Clause 1 - Scope
Item 1 is misleading in two areas: it is deemed to apply to all topic maps and is defined as the only alternative. In fact TMM is one of a number of perfectly permissible information structures (SAM, HyTM grove, etc), which are applicable to those topic map applications deeming information models to be a requirement. I suggest that wording be changed to:
  "1 An information structure for formally defining the contents of topic maps"

Clause 3.2.3
This clause states that "No topic can have more than one SIDP instance" and that "Each SIDP instance independently specifies the subject of the topic". This means that you cannot make the combination of a name and a scope into a SIDP. Yet the name + scope combination is currently defined as the technique used in ISO 13250 as the criteria for topic merging, and these rules have been retained in the HyTM syntax, which will form another part of the same multipart standard. Therefore the HyTM syntax cannot conform to the rules in TMM. This would seem to be more than unfortunate. If it is intended that a single SIDP can be created by combining multiple properties of a particular syntax (e.g. the contents of one element plus one token from a set of tokens derived from attributes on a number of elements, as is the case with HyTM scope statements) then a note to this effect should be added to the text.
Note: Also affects wording in third paragraph of 6.1.2.

Clause 4
The use of the words "are themselves subjects" in the second sentence is ambiguous. Does it mean "must themselves be subjects" or "may themselves be subjects"? If it is a requirement of the standard that all relationships in any topic must "must be defined as subjects" then this part is unnecessarily constraining topic map applications. If the interpretation is one of optionality this should be clearly spelt out in the text.

Clause 4.1.3
The phrase "each such specific role is itself a subject" is also ambiguous, for the reasons explained for clause 4. If the role "must be a subject" then this must be explicitly stated. If it "may be a subject" this optionality must be made clear.

Note 8
The analogy of SIDPs with costumes is totally inaccurate. There are are many plays where more than one character has the same costume (e.g. the beefeaters in The Yeoman of the Guard). There are even plays where the whole plot is based on the fact that two characters have the same costume. SIDPs are unique, like the names given to the various participants in the script (1st Beefeater, 2nd Beefeater, etc).

Clause 4.2.2.2.1
As is made clear in 4.2.2.7.1, a statement is needed to explain that the value may legitimately be empty, and that this state must be differentiated from that of having been assigned no value.

Clause 6.1.1 - 2nd Paragraph
 The reservation of the letters IS at the start of TM Application names is unnecessarily constraining. It should be replace by something like "ISO13250-1", "IS-TMM-" or "ISRM": i.e. by some series of letters and numbers that does not occur in any natural language. You should be able to use words such as "island",  "Islam" or "isagogic" as the name of the application if you so wish, not to mention the name of a company such as "IS-Thought".

Clause 6.1.4 - 2nd Paragraph
It is stated that "No two assertion types can include the same role." Therefore you cannot create an assertion of the types son-of and daughter-of for children with the same mother and father if you have roles of is-father-of and is-mother-of. This arbitrary rule seems totally unnecessary and far too constricting to be considered valid. (Was it meant to read "No two assertion types can include the same set of roles"?)

Clause 6.1.5
If "a TM Application must define one or more rules" how must these rules be expressed? Must they be computer interpretable? Must they be written in a specific language? What if a developer chooses to write them using predicate calculus, or some notation that is specific to his application?

Clause 6.2
The constraint on the use of periods in names is in direct contradiction to Note 14, which suggests that name conflicts can be minimized by using URIs to identify the TM Application namespace. URIs always contain periods, therefore cannot be used for TM Application names as defined in this clause.

Clause 7
The statement that  "Every instance of an interchangeable topic map must implicitly or explicitly declare the Syntax Deserialization Definition" is illogical. If the definition is not explicitly supplied then how can it be implied? Is the fact that it is not explicitly stated sufficient to infer that the definition can be implied?

Clause 8
The requirement in this late clause that c-topics must be merged is made far too late in the document. It should have been mentioned in 4.1.4 at the very least. The rules for the merging of c-topics have not been clearly identified in the preceding text.

Clause 9.1
The requirement that "The resulting topic map must represent all reified subjects as topics and all relationships between topics as assertions" is an unnecessary constraint on topic maps that do not require to conform to the TMM.

Clause 9.5
Why must castings be merged? Under which circumstances can two castings have the same values for their "other castings" property?

Editorial Comments

Clause 2.3.6
Change the initial "A defined set" to "A set" as there is no syntax for expressing any definitions within the standard.

Clause 6.1.3
The term TM Application Definition used in this clause should be defined in Clause 2.

Clause 6.1.4
In saying that "The names and semantics of all assertion types must be defined" no statement is made as to what "defined" means. Is a list of name used sufficient? What constitutes a valid "semantic"? Does the semantic need to be human readable, machine readable, displayable on a computer screen, etc? If a developer chooses to use Klingon for my semantic definitions of assertion types named using hieroglyphics is he conformant to the standard?

Clause 6.1.7
The use of "can be" in the second sentence implies the ability to look into the future. It should be changed to "have been" to indicate that only those specified by the application need to be defined.

Clause 9.3
The term "Any conflicts with built-in values" should, it is thought, be corrected to read "Any conflicts between built-in values"