[sc34wg3] Feedback on TMDM
Thu, 21 Apr 2005 21:47:04 +1000
In mapping TMDM onto \Tau+, I had the pleasure (yes, I am a master of
euphemism) to look more into the spec. In the following some
remarks/questions/abuses. Some might have been raised before, so the
editors may well refer me to the threads. My apologies, that I do not
keep track of this.
- Suggestion: To distinguish between the technology 'Topic Maps' and
particular instances of topic maps, maybe use this capitalization
- General: computed values
I found nowhere a place which says, that 'computed values'
are simply constraints and that it does not make a difference
where the information is in the first place.
The way it is now, sounds very much like a programming thing to me.
Can we rename it to 'Redundancy' or 'Constraint' or something?
So leave the property, but add a constraint, that "and this
value must be the same as ..."
- General: Default Values
In a couple of places the TMDM allows to have NULL as value,
even if there were a choice for a reasonable default. So,
for instance, if an occurrence does not have a type, it is
an 'OCCURRENCE' or if a topic is not an instance of something,
then lets make it a 'THING' or 'TOPIC'.
Everyone who defines a mapping from TMDM into something else
needs a base ontology for the TMDMish things (Lars needs it for his
Q, I need it for \Tau). It is probably not good if we all use
If that is done clever, we could reuse it for TMQL as well.
- 5.1: Source Locators
"...source locators are created that point back to the syntactical
constructs that gave rise to the information item..."
And then these source locators are used when a construct is reified.
What I probably will never understand is the relevance of
the "syntactical constructs". How is this supposed to work if
the map is only in my brain (which is valid according to the
introduction) before I make a braindump into computer memory?
Or less futuristic, if the map is built up in memory from
scratch (no deserializable syntax in sight). In this case
you would not have any source, so no source locator.
Isn't it the agenda to "address the item" itself regardless
where it may have come from (which may not exist anymore)?
[ This must have been discussed often, plz forgive my "Occamisation
by ignorance". ]
- 5.1: typo
... to have string that are equal....
- 5.1: Constraint
They cannot be the same unless items are topics. In that case, these
have to be merged. So there is only one topic afterall. So the source locators
are different afterall for _EVERYHTING_! Or not?
- 5.2: Base Locator
I would assume - from the name - that it is an absolute URI which allows all
relative URIs in the map to be made absolute.
Why is it there in the model and what reason could there be that
this is NOT done at deserialisation (or construction) time?
The only reason can be that the base locator is modified in a TM
instance changing all relative URIs in there. I cannot see any use
case for this.
It can be NULL. So what does that mean for relative URIs? Is such a
- 5.2. TM item
< critique withheld >
- 5.3.4 Scope
I see now that scope sets have AND semantics. Good.
Then why have actually a set there? If it is always the
ANDed set, then the model can be minimalized by everything
having EXACTLY ONE scope and that one scope object then
is a set of individual scopes (just another association with
predefined type and roles).
Needless to say, that this has impacts on TM[CQ]L.
- 5.3.4 Scope
The empty set is the encoding for the unconstrained scope.
I would rather have preferred to have one predefined concept
'unconstrained-scope' and put it as scope if required.
In TMQL one might explicitely say 'unconstrained scope' here. So
we need a name anyway.
- 5.3.5 Reification
"...making a topic represent the subject of another topic map
Is it only within the same map? Or can it be in another map?
- 5.5 Variant Names
Suggestion: "Section 7.4 defines....."
- 5.5 Variant Names
The scoping of variant names is a bit ... baroque.
First it has its own scope, so acts as if it were a separate
characteristic, but it belongs actually to a name which also
has a scope, but these scopes must be in some relationship.
Needless to say, that any mapping into something elegant will
- 5.6 Occurrence
The datatype is a string. And then it is a locator one sentence later.
I guess it is not a topic for a good reason?
- Annex A
is obsolete, I assume.
 has to be updated.