[sc34wg3] TMDM comments

[Lars Heuer]

Hi there,

I've some comments regarding TMDM dtd. 2005-10-28

Best regards,
Lars


Comments against TMDM version 2005-10-28

Foreword
--------
"""
ISO/IEC 13250 consists of the following parts, under the general title
Topic Maps:
    [...]
"""

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 
Topic.
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 
removed.


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
notation.


5.3.3 Scope
-----------
Example 2: 
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 ..."

Example 3: 
IMO it would be nice to find an example that 99% (or more) of the
readers understand instead of that cryptic one.


5.3.5 Properties
----------------
Equality rule

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
addressable.


"""
NOTE:

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 
("http://psi.topicmaps..../subject")?



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.


-- 
http://semagia.com