[sc34wg3] Feedback on TMDM

[Jan Algermissen]

Robert Barta wrote:

>- 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 ..."
>  
>
Why not use the term that has been in use for years for this: 
"functional dependency"???

>- 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.
>
>  
>
And: the 'source' is (at least whith 'Topic Maps on the Wev' (and thus 
use of HTTP) just a serialization
(for network transport) of a TMDM graph. It has no significance at all 
beyond that. With HTTP especially,since one
cannot even be sure that a GET on the 'map URL' won't return SVG next time.

>  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).
>  
>
Cool....that is the ancient PMTM4 style of representing  scope.....

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

Jan



>sc34wg3 mailing list
>sc34wg3@isotopicmaps.org
>http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
>
>  
>


-- 
Jan Algermissen
Consultant & Programmer
http://jalgermissen.com