[sc34wg3] TMDM comments
Wed, 7 Dec 2005 13:23:08 +0100
I've some comments regarding TMDM dtd. 2005-10-28
Comments against TMDM version 2005-10-28
ISO/IEC 13250 consists of the following parts, under the general title
IMO these references add no value to TMDM. There are already
proposals for Part 6 and Part 7 and possibly more parts will follow
in the future
References to all parts of ISO/IEC 13250 should be moved to an
additional, informal document.
4.1 The metamodel - Introduction
Figure 1 - The class hierarchy
According to the UML diagramm a Topic may be reified by another
That is simply not true.
Additionally the note states "[...] and because the value of the
[reifier] property of topic items can be any topic map construct."
This is also not true.
I know, the UML diagramms are not normative and there is a note that
says "prose rules" but I wonder why the UML diagramm and its
note is intentional wrong.
5.3.4. 2nd note says: "One topic cannot reify another." since they
have to merged because they represent the same subject. That is the
truth and the misleading information mentioned above should be
5.3.2 Identifying subjects
The note for subject locators states "[...] This of course raises the
question of when two information resources can be considered to be the
same. This part of ISO/IEC13250 makes no attempt to clarify this and
leaves it for individual locator notations to define."
Do the "locator notations" define in which cases the information
resource should be considered the same? What about
"http://beatles.com/" and "http://www.beatles.com/"? Both refer to the
same information resource and that has nothing to do with the locator
Not a failure but I'd like to suggest to find a more pleasant example
than Word War II.
Additionally this example seems to suggest that dates should be
modelled with occurrences ("This corresponds to creating [...]").
It is also possible to create a topic that represents that date and
connect it via a 'true' association with the WWII topic. ('true' since
occurrence is a special kind of association).
I suggest to change it to something like "This may be modelled ..."
IMO it would be nice to find an example that 99% (or more) of the
readers understand instead of that cryptic one.
Wouldn't a ", or" behind each list item make it more clear that only
one of these items has to be fulfilled to state that particular
topics are equal?
BTW: The equality rules are not addressable (they do not occurr in the
TOC). I suggest to make the equality rule of each topic map construct
Topics may in addition to the properties defined above also have
types, instances, supertypes, and subtypes, represented by means of
associations using the subject identifiers defined in 7.2 and 7.3.
Why "may have types"? Hasn't each topic at least one type
6.2 Merging topic items
"The procedure for merging two topic items A and B (whose [parent]
properties shall contain the same topic map item) [...]"
Why is the [parent] property mentioned here? The merging procedure
describes merging of topic items in the _same_ topic map instance. The
[parent] propety _is_ the same.
The merging procedures 6.3 - 6.7 do not state that the [parent]
property shall contain the the same value.
I suggest to remove the "(whose [parent] ...)" or to add this hint to
every merging procedure (topic names, occurrences, associations ...)
with the appropriate [parent] property name.