---

P-Member	APPROVAL OF THE DRAFT AS PRESENTED	APPROVAL OF THE DRAFT WITH COMMENTS AS GIVEN ON THE ATTACHED	DISAPPROVAL OF THE DRAFT FOR REASONS ON THE ATTACHED	DISAPPROVAL (appropriate changes in the text will change vote to APPROVAL)	ABSTENTION (For Reasons Below)	NO RESPONSE
Canada	X
China						X
Italy	X
Japan				X
Korea	X
Netherlands	X
Norway		X
United Kingdom		X
United States		X

Japan

(1) Technical

(1.1) All part of the specification
"URI" should be changed to "IRI", because an IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646) and allows to use non-Latin scripts in it.

(1.2) Clause 3. Terms and definitions
Term "topic map construct" should be added.

(1.3) Clause 4.1 Introduction, 3rd paragraph
"Conceptual model" should be clarified.

(1.4) Clause 4.1 Introduction, 4th paragraph
It is ambiguous which type "All types" mean, information item type or data type. It should be clearly described.

(1.5) Clause 5.4 Topic name items, [parent] property, Computed value
"the topic name item whose [topic names] property ...." should be
"the topic item whose [topic names] property ....".

(1.6) Clause 6.3 Merging topic name items
The [type] property operation should be added in the procedure for merging.

(2) Editorial

(2.1) Clause 2. Normative references
"IETF RFC 2396, ... " should be changed to
"IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax ... , January 2005, available at <http://www.ietf.org/rfc/rfc3986.txt>".

(2.2) Clause 2. Normative references
"IETF RFC 2732, ... " should be deleted, because of it is included in IETF RFC 3986.

(2.3) Clause 2. Normative references
"IETF RFC 3987, Internationalized Resource Identifiers (IRIs), Internet Standards Track Specification, January 2005, available at <http://www.ietf.org/rfc/rfc3987.txt>" should be added.

(2.4) Clause 2. Normative references
"XML Infoset, XML Information Set, ... " should be
"XML Information Set (Second Edition), World Wide Web Consortium, 4 February 2004, available at <http://www.w3.org/TR/2004/REC-xml-infoset-20040204/>".

(2.5) Clause 2. Normative references
"ISO10646-1, ISO 10646-1:2000: ... " and ISO10646-2, ISO 10646-2:2001:" should be
"ISO/IEC 10646: 2003: ... ".

(2.6) Clause 2. Normative references
"W3C XML, Extensible Markup Language (XML) 1.0 (Second Edition), ... " should be
"W3C XML, Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation, 4th February 2004, available at <http://www.w3.org/TR/2004/REC-xml-20040204/>".

(2.7) Clause 4.5 Constraints
"The model defined in this this part of ..." should be
"The model defined in this part of ...".

(2.8) Bibliography
"ISO 13250-5: ... " should be
"ISO/IEC 13250-5: ... "

Norway

Template for comments and secretariat observations

Date: 2005-05-12

Document:N 588, (FCD 13250-2)

1	2	(3)	4	5	(6)	(7)
MB1	Clause No./ Subclause No./ Annex (e.g. 3.1)	Paragraph/ Figure/Table/Note (e.g. Table 1)	Type of com-ment2	Comment (justification for change) by the MB	Proposed change by the MB	Secretariat observations on each comment submitted

NO	3		ed	"Topic name type" is not defined.	Add "Topic name type" to the Terms and definitions.
NO	3.6		te	Definition of base name should be reviewed. By the current definition some variant names could be regarded as base names.
NO	4.4		te	It should be stated explicitly that the datatype URIs are considered to be PSIs for the respective datatypes, not just "identifiers".
NO	4.4		te	It is unclear from the definition of XML datatype whether the datatype also includes complete XML documents in addition to document fragments.
NO	5.2		te	The semantics of the base locator property need to be defined more precisely.
NO	5.4		te	The [type] property should be required to have a value.	Define PSIs for use when deserializing untyped topic names from XTM.
NO	5.6		te	See comment on 5.4
NO	5.7		te	See comment on 5.4
NO	5.8		te	See comment on 5.4
NO	6.1		te	State explicitly that merging is a process in a single topic map and not across multiple topic maps. Clarify that changes that trigger merging are not defined by TMDM itself, but by other specifications which use TMDM.
NO	7		ge	The domain topicmaps.org should not be used for PSIs since it is not controlled by SC34.	Use PSIs whose form is http://psi.topicmaps.com/iso13250/foo.
NO	7.3		ed	The example at the end requires more explanation
NO	7.4		te	The display name PSI should be removed. It no longer serves any purpose now that the topic naming constraint has been removed.
NO	7.5		te	The unique-characteristic PSI should be removed from TMDM since it belongs more appropriately in TMCL.
NO	7.6		te	The purpose served by the PSIs defined in this section should be made clear, or else they should be removed from the standard. If retained, they should be defined more carefully.
NO	7.6		te	Each term in the glossary should have a PSI.
NO	7.6		te	PSIs should be defined for each item type that has the [type] property. These PSIs can be used as the value of the [type] property when representing constructs that are untyped in XTM.

United Kingdom

2005-05-05Template for comments and secretariat observations

Date: 2005-05-05

Document:FCD 13250-2 – SC34N0588

1	2	(3)	4	5	(6)	(7)
MB1	Clause No./ Subclause No./ Annex (e.g. 3.1)	Paragraph/ Figure/Table/Note (e.g. Table 1)	Type of com-ment2	Comment (justification for change) by the MB	Proposed change by the MB	Secretariat observations on each comment submitted

GB	Clause 3.9		Ed	Is this proper English? Does a subject "belong" to a type? Surely it can belong to a set or to a class, but not to a type. It could be "of" a type. Definition of type (3.31) indicates that it is an abstraction that gives rise to a set of subjects, so a subject belongs to that set, not to the type.
GB	Clause 3.11		Ed	"Reduce or eliminate": this makes it sound like a process such whereby merge(merge(A)) != merge(A) Suggest change to just "Eliminate".
GB	Clause 3.14-3.16		Ed	Why are these defined? Surely 13250-2 only needs to be concerned with subject identifiers and subject indicators, published or not. Remove 3.14 - 3.16 and remove all reference to "published" identifier and indicators.
GB	Clause 3.21		Ed	Remove second sentence.
GB	Clause 3.28		Ed	"statement" is already defined as the assignment of a topic characteristic to a topic. Remove this definition and rework the text to remove references to "topic characteristic assignment"
GB	Clause 4.1		Ed	Para 4: Should read "All information item types..." - otherwise clashes with "type" defined in clause 3
GB	Clause 4.3	Note	Ed	Replace "As the it " with "As it"
GB	Clause 4.4		Ed	Why use the XML Schema anyType for XML data type? Is that really valid? Editors could usefully rework text relating to the identification of data types.
GB	Clause 5		Ed	Editors must ensure that definitions repeated from the glossary remain consistent with the definitions contained in this clause.
GB	Clause 5.1		Ge	The UK would like the editors to review whether clause 5.1, Source locators, should be an integral part of the data model.
GB	Clause 5.1	Note	Ed	Replace "source locators are created that" with "source locators may be created that"
GB	Clause 5.1	1st para	Ed	Surely a topic map *is* itself, not a representation of itself. The topic map information item represents the topic map, but it does not have "no meaning or significance" as it serves as an anchor for reification (or non-reification) of the topic map. Therefore strike the last sentence.
GB	Clause 5.3.4	Note	Ed	Seems a bit strange for a standard to be saying. Strike last sentence of para 1.
GB	Clause 5.3.5		Ed	Remove definition of reification and replace with definitions of "reifier" and "reified".
GB	Clause 5.4	Note	Ed	Remove the last sentence as it does not add anything.
GB	Clause 5.7	Figure 7	Ed	UML shows 0..* roles on an association. Text says 1..*. Fix diagram.
GB	Clause 6.2	Point 2	Ed	Replace "some information items" with "all information items"
GB	Clause 7.1		Ed	Clarify whether last sentence refers to the identifiers or the subjects identified. Clarify the meaning of "distint" - should this actually read "disjoint"? If this standard is to define new subject identifiers for concepts which already have subject identifiers under the http://www.topicmaps.org/ namespace, the editors should specify the mapping between the http://psi.topicmaps.org/ namespace and the http://psi.topicmaps.org/ namespace.
GB	Clause 7.4		Ed	What does it mean for a variant with XML or locator data type to be in the "sort" scope? Still use Unicode string comparison? Sort order should be on the *string representation of the value property*
GB	Clause 7.6		Ed	Explain why the identified for topic map constructs are there, or else remove them. Additional comments: With the addition of data typing on variants and occurrences there now appears to be a commonality between variants, occurrences and to some extent topic names. The editors should seek to re-examine the way that these constructs are explained. (i.e. if the data type for the topic name value is the string data type, this should be made clear). [datatype] property. Value should be described as a string identifier.

United States

1. Foreward: Should list: Part 5: Reference Model

2. 3. Terms and Definitions:

   General comment: Shouldn't the definitions be phrased in complete sentences? Contrast 3.9 Instance (which is a complete sentence) with any of the other definitions. Normal punctuation should be followed as well, assuming complete sentences that implies the use of periods to end sentences.

   1. 3.1 association: Reads: "a representation of a relationship between two or more subjects"

      But, cf. 3.2, which defines association role player as: "a topic participating in an association"

      Shouldn't 3.1 read: "a representation of a relationship between two or more subjects represented by topics"?

   2. 3.3 association role: Reads: "a representation of the involvement of a subject in a relationship represented by an association"

      But, cf. 3.4, which defines association role type as: "a topic defining the nature of the participation of an association role player in an association", and note that association role player is defined at 3.2 as a topic.

      The definitions seem to move between use of subject and topic, which given the more general definition of a subject, is confusing.

      Noting that "topic" is clearly delimited to "symbol[s] used within a topic map to represent some subject...." which is taken to limit the more general definition of subject.

      That is to say that there may be any number of potential subjects depending upon the viewer that could be in an instance of a topic map, but the only ones of which a topic map processor is aware of are those that have been declared by symbols.

   3. 3.6 base name: Reads: "a name or label for a subject, expressed as a string

      Question: Does "string" here as defined later as in 4.2?

      Question: Shouldn't string as a datatype and the other data types as well, be defined here and simply used by reference later on?

      Comment: note the shift back to subject. "base name" is a characteristic of a topic that represents a subject. Yes?

   4. 3.7 information item: Reads: "abstract representations of topic map constructs"

      Note disagreement in case: information item (singular), abstract representations (plural).

      cf. comments elsewhere on what is a "topic map construct"

   5. 3.9 instance:Reads: "Any subject that belongs to a particular type."

      Note shift from topic.

      Shouldn't this be type-instance?

      The term "instance" occurs 36 times (excluding the table of contents) and only 7 of those are type-instance. The other uses, some 29 of them, are clearly not following this definition.

   6. 3.11 merging: Reads: "a process applied to topic maps in order to reduce the number of redundant topic map constructs"

      Accurate but rather prosaic.

      Also note that "topic map constructs" is undefined.

   7. 3.12 occurrence: Reads: "a representation relationship between a subject and an information resource"

      Grammar: "a representation relationship..." -> a representation of a relationship..."

      Question: shouldn't the TMDM consistently use topic or topic iten in place of subject?

      Reasoning that it is the topic + information resource that represents the relationship.

   8. 3.13 occurrence type: cf. comments on use of subject under 3.12.

   9. 3.14 published subject - 3.16 published subject indicator

      Comment: Not sure it is possible but note there is no definition of published.

      Reasoning that 3.23 defines subject indicator as "an information resource" and 3.8 defines information resource as "a resource that can be represented as a sequence of bytes" so does published include printed books? Certainly "can" be represented as a "sequence of bytes" but is is not clear if that was intended to be covered by 3.14-3.16.

   10. 3.17 reification: Reads: "making a topic represent the subject of another topic map construct"

       Wouldn't it be simpler to say that subjects are represented by topics (or topic items). (full stop)

       That is to say if there is no topic that has as a value in its [subject identifiers] property that is equal to the [source locator] property of an information item (note, does information item include a topic item?), whatever may or may not be represented by the information item, is not being represented by a topic.

       Gets away from the notion that association information items represent subjects in "some" sense and to a purely mechanistic test, is there a topic that meets the [subject identifiers] = [source locator] test? If yes, that subject is represented by a topic/topic item in the topic map. If no, then the subject is not represented by a topic/topic item in the topic map.

       Suspect that cleans up the struggle with reification found in 5.3.5 Reification.

   11. 3.18 scope: see comments under 5.3.4 Scope

   12. 3.19 source locator:

       "topic map construct"?

   13. 3.20 statement:

       Is this necessary? Not objectionable but is such a statement required for the statement of the standard?

   14. 3.21 subject:

       A difficult definition to even attempt. Not certain about the "creator of a topic map chooses to discourse."

       What about auto-generated topic maps?

       Suggest: "Whatever is represented by a topic/topic item in a topic map."

       As Barta has noted in off-list discussion, we are really presuming subjects since they are beyond the ken of any computer system.

   15. 3.23 subject indicator: Reads: "an information resource that is referred to from a topic map in an attempt to unambiguously identify the subject of a topic to a human being. Any information resource can become a subject indicator by being referred to as such from within some topic map, whether or not it was intended by its publisher to be a subject indicator."

       Note the abmiguity of what qualifies as an information resources noted under 3.14 publshed subject.

       Note the last part of the last sentence: "...whether or not it was intended by its publisher to be a subject indicator."

       Suggest avoiding the "intent" issue.

       Suggested wording: "...whether it was published as a subject indicator or not."

       That puts the onus on the originator of the topic map.

       Note the the suggested change highlights an ambiguity in the original text. The term being defined is "subject indicator." But surely "subject indicators" are not limited to "published" subject indicators? The reference to the "publisher" in the last sentence makes this unclear.

   16. 3.24 subject locator: Reads: "a locator that refers to the information resource that is the subject of a topic. The topic thus represents that particular information resource; i.e. the information resource is the subject of the topic."

       Question: Is there a difference between "representing" an information resource and the information resource being the "subject" of a topic?

       Since all topics represent particular subjects, suggest losing the second sentence. There is no reason to privilege topics whose subjects are information resources with further explanation.

   17. 3.26 topic: Reads: "a symbol used within a topic map to represent some subject, about which the creator of the topic map wishes to make statements"

       Comment: Ambiguous reference "about which"? Does this refer to the topic (cf. the following 3.28 topic characteristic assignment" or the subject of the topic?

       Note that 3.27 and 3.28 refer to topics.

   18. 3.31 type: Reads: "an abstraction that captures characteristics common to a set of subjects"

       Shouldn't this have "topics" instead of "subjects"?

       Reasoning that only "topics/topic items" have characteristics as defined. At least in the sense that they are accessible to processing following this data model.

   19. 3.32 unconstrained scope: Reads: "the scope used to indicate that a topic characteristic assignment is considered to have unlimited validity"

       Comment: When read in conjunction with 3.18 scope, wouldn't it be clearer to say: "a topic characteristic assignment without a context."

       Reasoning that it is the absence of a specified context that is the sine qua non of being in unconstrained scope.

   20. 3.33 variant name: Reads: "an alternative form of a topic name that may be more suitable in certain contexts than the base name of the topic map"

       Typo: "base name of the topic map" -> "base name of the topic/topic item"

       Comment: Is is necessary to speculate about usage?

       Suggest: "an alternative form of a topic name." (full stop)

3. 4.1 Introduction, forth paragraph reads: All types defined in this part of ISO/IEC 13250 have a well-defined test of equality. This equality test is used to avoid duplicate values in properties whose values are of type set. Information items have identity, independent of their values, so items can be compared both by identity and by value. Equality throughout this part of ISO/IEC 13250 should be taken to mean equality according to the rules defined for the types of the values being compared.

   The last sentence, "Equality throughout this part of ISO/IEC 13250 should be taken to mean equality according to the rules defined for the types of the values being compared." seems to be inconsistent with the sentence that immediately precedes it.

   I take it that "value" is meant to refer to either the identity value of an information item, or its value, but I don't think that is very clear. I suspect it is the "idenpendent of their values" that is throwing me off.

4. 4.1 Third paragraph reads: Certain properties in the model are specified as computed properties, which means that they are specified in terms of how their values may be produced from other properties in the model. These properties are specified for reasons of convenience or to better reflect the conceptual model but are strictly speaking redundant.

   Suggest losing the second sentence: "These properties are specified for reasons of convenience or to better reflect the conceptual model but are strictly speaking redundant."

   Not redundant if required by the data model. Explaining the nature of the property is correct, no further explanation required. The calculated properties are not optional (I don't think).

5. 4.1 Forth paragraph reads: All types defined in this part of ISO/IEC 13250 have a well-defined test of equality. This equality test is used to avoid duplicate values in properties whose values are of type set. Information items have identity, independent of their values, so items can be compared both by identity and by value. Equality throughout this part of ISO/IEC 13250 should be taken to mean equality according to the rules defined for the types of the values being compared.

   1. The first sentence, "well-defined" should be "defined".

   2. Not certain about the reference in the second sentence to "This equality test...."? What equality test? Has not be defined, yet.

   3. And, on second sentence, a string equality test is defined for properties that are not of type set.

   4. Third sentence: "Information items have identity, independent of their values," ?

      How so? How would that be determined other than by examination of values of the information item?

      I was assuming this was the role (non-TM sense) of the source locator. But that is a property of an information item.

6. 4.1 Note following the UML diagram, second sentence reads:

   "It is used here to simplify the UML diagrams using inheritance, and because the value of the [reifier] property of topic items can be any *topic map construct*."

   The material I marked with the "*" seems problematic to me.

   First, it is not a defined term.

   Second, because it is not a defined term, I don't know what qualifies as the value of a reifier property.

   The topic map item says for the reifier property: "A topic item, or null. If present, the topic that reifies this topic map construct."

   The topic item says for the reifier property: "[reified]: An information item, or null. If given, the topic map construct that is the subject of this topic." (Yes, note shift from "reifier" in topic map iten to "reified" in topic item. Not sure of its significance.)

   The topic name item says for the reifier property: "[reifier]: A topic item, or null. If present, the topic that reifies this topic map construct."

   The variant name items says for the reifier property: "[reifier]: A topic item, or null. If present, the topic that reifies this topic map construct."

   Occurrence, Association, and Association Role, items all follow the reifier definition of topic and topic name.

   So, I am not sure if topic name, variant name, occurrence, association and association role are all topic map constructs or not.

   Also note the shift between "topic item" and "information item" (on topic item). Assuming that is to disallow topic item as reifying a topic item but it is still unclear waht is a "topic item."

7. 4.2 The Fundamental types:

   The first sentence reads: "The values of information item properties may be either other information items, or values of one of the types defined below:"

   What does it mean to have an information item as a property value?

   I have assumed it meant source locator but now can't find support in the text for that reading.

8. 4.2 The definition of string:

   Strings are sequences of Unicode scalar values.

   Strings are equal if they consist of the exact same sequence of Unicode scalar values. This implies that all comparisons are case-sensitive.

   ---

   The "exact same sequence of Unicode scalar values" also implies that they are in the same normalization form, the same encoding, etc.

   Suggest striking the second sentence: "This implies that all comparisons are case-sensitive."

   What it implies is that string comparisons are bound by all the Unicode rules for string processing. But I don't see even that as really relevant.

9. 4.2 The definition of set:

   Sets are collections of zero or more unordered elements that contain no elements that are equal to each other. In this data model, the elements of a set are always information items.

   Two sets are equal unless there exists an element in one set for which no equal element can be found in the other.

   ---

   The first sentence seems confusing. If element = information item, why not say: Sets are collections of zero or more unordered information items.

   (Relying on the inherent notion of set comprehension for the "no elements that are equal to each other" part of the sentence.)

   Is it necessary to define equality of sets? (second sentence) That is the definition of sets that are not equal but is it necessary?

10. 4.2 The definition of null:

    Null is used to indicate that properties have no value; it does not necessarily indicate that the value of the property is unknown. In this model null can never be contained in a set.

    ---

    Not sure of the advisory comment: "it does not necessarily indicate that the value of the property is unknown."

    Shouldn't the first sentence read: "Null is used to indicate that properties have no value."

11. 4.4 Datatypes:

    Note shift in language from the first paragraph, "only atomic fundamental types" to first sentence of next paragraph says, "defines only the following three datatypes..."

    Doesn't defining string and using the W3C definition give us two definitions of string?

    BTW, the XML infoset defines "null" (http://www.w3.org/TR/2004/REC-xml-infoset-20040204/) so wouldn't it be cleaner to simply add 'null' to the list and avoid defining string/null, etc.?

    Would leave set to be defined, unless the editors want to refer to the Z specification for a definition of set.

12. 5.3.1 Subjects and topics:

    cf. comments made under 3.21 subject

13. 5.3.2 Identifying subjects:

    Note the definitions from 3 Terms and Definitions are repeated here. Suggest that definitions be made once and only once.

    Offering the definition again, sometimes with more commentary, invites conflicting interpretation.

    Suggest that the example should be changed to: http://www.iso.ch.

    That has the added advantage of allowing an example that suggests that http://www.iso.org is also a subject locator for the same subject (the information resource) but that cannot be determined on the basis of comparing the source locators.

14. 5.3.4 Scope, Third paragraph:

    Reads: "Precisely how a subject, or a set of subjects, defines a context is not defined by this part of ISO/IEC 13250, but left for those creating topic maps to define as part of the definition of their subjects."

    1. Shouldn't ...how a subject, or set of subjects, defines..." read: "...how a topic or set of topics, define..."?

       Reasoning that it is topics in a topic map that define scope. BTW, "define" and not "defines" because topic and "set of topics" are both singular. Taking the referent to be "set."

    2. Shouldn't "...to define as part of the definition of their subjects" read: "...to define as part of the definition of their topics"?

       That is that the "scope" of a subject has to be represented and that is done as part of the topic that represents the subject.

    3. Shouldn't we lose the examples? Odd to disclaim any notion about how to create a context and then to proceed to illustrate it.

15. 5.3.5 Reification:

    CF. the suggestion under 3.17 reification that subjects are represented by topics?

    Doesn't really matter whether the subject is an association (or other) item or some other subject.

16. 5.3.6 Properties:

    Topic characteristics (5.3.3) indicates that only [topic names], [occurrences], and [roles played] are statements about the subject represented by the topic.

    That is clear but the reasoning to exclude [subject identifiers], which are locators for subject indicators is not. Isn't the use of particular locators that indicate a subject a statement about the subject of the topic? That is to say that the locator(s) are a statement about the subject?

17. 5.3.6 Properties, Property # 6 [reified] Computed value:

    Appears to say that if a string in the [source locator] property (a set of strings) is equal to a string in the [subject identifiers] property (also a set of strings), this is the value of the reified property.

    If so, does that mean that a topic could have its [source locator] (a locator assigned to a topic map construct (assuming here that includes a topic, and in this question the topic under discussion) in order for it to be referred to) equal to a [subject identifier] (a locator that refers to a subject indicator), creating a situation where the topic reifies itself?

18. 5.3.6 Properties, Note:

    The only note in 5.3.6 begins: "Locators which refer directly to subjects which are not information resources must be used with caution."

    First, isn't this already covered in the definition of subject locator via its reference to locator? (Modulo the caveat earlier about it not being clear whether potential to be a "sequence of bytes" really limits resources to being network resourdes.)

    Second, why the cautionary note? Either topic maps conform to this data model or they don't. Isn't a matter of caution, simply following the rules as defined.

    The second paragraph of the note reads: "The isbn URN scheme used to identify books ( [IETF RFC 2288][3]), for example, does not reference information resources, and so should not be put in the [subject locators] property, but instead in the [subject identifiers] property."

    This implies a condition on "information resource" that is not stated in its definition. The objects of IETF RFC 2288 URN references can "potentially be represented as a sequence of bytes..." and so at least in one view, could be considered information resources as defined.

19. 5.4 Topic name items:

    Second paragraph, second sentence reads: "They always have a scope, which defines in what contexts the topic name is an appropriate label for the subject."

    Does this mean that the [scope] property is never null?

    Or does it mean that either the [scope] property is not null or if null, has the unconstrained scope?

    In other words, either way, names always have some scope, may be specified or may be the default unconstrained scope.

    Third paragraphs reads: "A base name is a name or label for a subject, expressed as a string. That is, it is something that identifies the subject (though not necessarily uniquely) and can be used as a label for the subject in user interfaces. The notion of a base name corresponds closely to the common sense notion of a name."

    Suggest on second sentence, losing "...and can be used as a label for the subject in user interfaces."

    More generally, is there some reason to re-define base name? It is already covered in 3. Terms and Definitions.

    The following Note concludes: "Essentially, a base name is a specialized kind of occurrence."

    While of interest to topic map theorists, not sure this qualifies for inclusion here. There are a lot of things that could be said, interesting things, helpful things, but not really germane to the exposition of the data model.

20. 5.5 Variant items:

    First paragraph, second sentence reads: "The scope of the variant name is the only basis for establishing what variant name is most suitable in any given situation."

    Why prohibit the unconstrained scope? It is, as noted earlier, scope as well.

    Granted that as the properties of variant name are written, scope is required but other than to support this implementation choice, why is unclear.

    Other plausible senarios include, deciding to display (or not) the variant name on the basis of its being some particular "other kind of information resource." Or in a training situation on a particular topic map, could suppress all variant names of all scopes.

    The point being that if the standard drifts into too far into implementation choices and advice, there is no end to the advice that could be offered.

    Along that same line of reasoning, the Note in 5.5 following the first paragraph should be striken in its entirety.

    If accepted, this comment requires changing the [scope] property on variant name as well as the text discussed.

21. 5.5 Variant Items - Properties:

    Datatype (these comments also apply to [datatype] under occurrence in section 5.6) is defined as follows:

    "[datatype]: A string. A locator identifying the datatype of the variant name value."

    It is unclear if the value may be a string or a locator.

    Note that the two are defined differently and that a locator is a subclass of string.

    Does this mean, a string, that is a locator? (Reading the second sentence as modifying the first.)

    Or, does it mean a string, OR, a locator?

    If it is the first case, then all datatypes will have to be expressed as locators.

    If it is the second case, then I may have "integer" or I may have "http://www.w3.org/TR/xmlschema-2/#integer", which leave me with no way to resolve "integer."

    Of course if it is presumed that no resolution takes place, then string to string comparison would work, except that in the second case there would be false negatives in terms of matching.

22. 5.5 Variant Names - Constraint Variant scope:

    The Constraint: Variant scope section reads: "The value of the [scope] property of each variant item must be a true superset of the value of the [scope] property of the topic name item in its [parent] property."

    Question: How to express a superset?

    Does this mean the [scope} property of the variant item would be the value of its [scope] property plus the value of the [scope] property of its topic name parent?

    That sounds inconsistent with the discussion in 5.3.4, where it is stated: "That is, the topic characteristic is known to be valid only in the contexts where all the subjects in the scope apply."

    A superset in the sense of creating a set of the values of the [scope] property of variant item and the [scope] property of its topic name parent seems to deprive variant item of a limited [scope] property.

    If the intent is to say the [scope] property of the variant item must be a subset of the [scope] property of the topic name parent, the question becomes how to evaluate the subset relationship?

    For example, Akkadian as a language is known to include the following dialects over time and location: Old Akkadian, Old Assyrian, Middle Assyrian, Neo-Assyrian, Old Babylonian, Middle Babylonian, Neo-Babylonian, and Late Babylonian. Collectively, they all fall within the scope of Akkadian, but it is not the case that a name written in any of them also applies in all contexts where Akkadian is the proper scope.

    Nor is it immediately obvious that Neo-Babylonian should be considered a subset of Akkadian. Relying upon the type of writing doesn't help either since Sumerian was also written in cuneiform and it has at best a tangential relationship to Akkadian, which is a Semitic language.

23. 5.6 Occurrence items: (first paragraph)

    The first two lines of the first paragraph read: "An occurrence is a representation of relationship between a subject and an information resource. The subject in question is that represented by the topic which contains the occurrence."

    Suggest that "representation" language be excised except when making references to topics.

    Otherwise, there are "subjects" in the common sense being represented by several items in the data model and not just topics.

    Suggest: "An occurrence is a relationship between a subject and an information resource. The subject in question is that represented by the topic which contains the occurrence."

    If that relationship is to be treated as a "subject" (topic man sense) then it must have a topic. (the "reification" mechanism of the TMDM)

    The third sentence reads: "Occurrences are essentially a specialized kind of association, where one participant in the association must be an information resource."

    Correct, interesting, but topic map theory point. Not really relevant to stating the data model.

24. 5.6 Occurrence items: (second paragraph)

    Second paragraph reads:

    "All occurrences have a scope, which defines the contexts in which the occurrence relationship between the information resource and the subject is valid."

    The definition of the [scope] property does not expressly prohibit the value being null. Was that intentional?

    That is to say, can an occurrence be valid in the unconstrained scope?

    Note the same issue with [datatype] here as was noted under variant name.

25. 5.7 Association items:

    First paragraph reads: "An association is a representation of a relationship between one or more subjects. Associations have an association type, a topic representing a subject which describes the nature of the relationship represented by the association."

    Note the representation language. Work in the following paragraph because a association role is by definition a topic.

    Suggest: "An association is a relationship between one or more subjects. Associations have an association type, a topic representing a subject which describes the nature of the association relationship."

    Forth paragraph reads: "All associations have a scope, which defines the context in which the relationship represented by the association can be considered valid. The scope applies to the assignment of the roles to the topics playing them in the same way as it does to the association as a whole."

    First, same questions as for scope under occurrence. Can it be null?, etc.

    Second, what does "The scope applies to the assignment of the roles to the topics playing them in the same way as it does to the association as a whole." mean?

    Topics have a [roles played] property, which consists of association role items, but association role items have no [scope] property.

    So, if a association role item lacks a [scope] property, how is the scope going to be applied to "the assignment of roles to the topics playing them...?"

26. Merging:

    General comment: Listing the operations in the same order as the property lists for the various items would make referencing between them easier.

27. 6.2 Merging topic items:

    Question: Shouldn't there be an operation for merging the [roles played] properties of the respective topic items?

28. 6.3 Merging topic name items:

    Question: Shouldn't there be an operation for merging the [type] properties of the respective topic name items?

29. 7 Published Subjects, 7.1 General:

    The last paragraph reads: "All published subjects defined by this part of ISO/IEC 13250 are distinct."

    It is not clear what is being added by this statement.

30. 7.2 - 7.6, type-instance relationship, etc.:

    While the presentation by example was clear, it was unexpected following the statement that: "This clause defines a number of published subjects..."

    Suggest simply defining the published subjects with a minimal amount of explanation for each one.

    That is not to say that the fuller examples would not be extremely helpful and appropriate for an annex, but they seem out of place in the normative text.

31. Annex A:

    The latest verion of the Topic Maps Reference Model is now proceeding to CD vote and has been simplied with the assistance of Robert Barta. Those simplifications will require slightly different terminology in the Annex.