ISO/IEC JTC 1/SC34 N0407
ISO/IEC JTC 1/SC34
Information Technology --
Document Description and Processing Languages
| TITLE: | U.K. National Body Comments on JTC1/SC34 N0393 -- Topic Maps Model (TMM) |
| SOURCE: | M. Bryan |
| PROJECT: | Topic Maps |
| PROJECT EDITORS: | M. Biezunski, M. Bryan, S. Newcomb |
| STATUS: | |
| ACTION: | For information |
| DATE: | 2003-04-15 |
| DISTRIBUTION: | SC34, SC34/WG2 and Liaisons |
| REFER TO: | |
| REPLY TO: | Dr. James David Mason (ISO/IEC JTC1/SC34 Chairman) Y-12 National Security Complex Bldg. 9113, M.S. 8208 Oak Ridge, TN 37831-8208 U.S.A. Telephone: +1 865 574-6973 Facsimile: +1 865 574-1896 Network: [email protected] http://www.y12.doe.gov/sgml/sc34/ ftp://ftp.y12.doe.gov/pub/sgml/sc34/ Mrs. Sara Desautels, ISO/IEC JTC 1/SC 34 Secretariat American National Standards Institute 25 West 43rd Street New York, NY 10036 Tel: +1 212 642 4937 Fax: +1 212 840 2298 Email: [email protected] |
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"