[sc34wg3] Feedback on TMDM

[Robert Barta]

Hi,

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
  consistently?

- 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
  different ones.

  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
  map meaningful?

- 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
    construct".

  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
  fail here.

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

- Bibliography

  [4] has to be updated.

\rho