-
Foreward: Should list: Part 5: Reference Model
-
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.
-
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"?
-
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.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?
-
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"
-
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.
-
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.
-
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.
-
3.13 occurrence type: cf. comments on use of subject
under 3.12.
-
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.
-
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.
-
3.18 scope: see comments under 5.3.4 Scope
-
3.19 source locator:
"topic map construct"?
-
3.20 statement:
Is this necessary? Not objectionable but is such a statement
required for the statement of the standard?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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)
-
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.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).
-
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.
-
The first sentence, "well-defined" should be "defined".
-
Not certain about the reference in the second sentence to "This
equality test...."? What equality test? Has not be defined,
yet.
-
And, on second sentence, a string equality test is defined for
properties that are not of type set.
-
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.
-
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."
-
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.
-
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.
-
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?
-
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."
-
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.
-
5.3.1 Subjects and topics:
cf. comments made under 3.21 subject
-
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.
-
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."
-
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."
-
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.
-
Shouldn't we lose the examples? Odd to disclaim any notion about
how to create a context and then to proceed to illustrate it.
-
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.
-
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?
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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...?"
-
Merging:
General comment: Listing the operations in the same order as the
property lists for the various items would make referencing between
them easier.
-
6.2 Merging topic items:
Question: Shouldn't there be an operation for merging the [roles
played] properties of the respective topic items?
-
6.3 Merging topic name items:
Question: Shouldn't there be an operation for merging the [type]
properties of the respective topic name items?
-
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.
-
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.
-
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.
