GTM Minutes from WG 3 Meeting in Oslo, 2007
For ease of reference, these minutes contain the presentation made
by the GTM editors, Lars Marius Garshol and Professor Jaeho Lee,
as well as the comments and decisions made during the
meeting. Comments and decisions from the meeting are shown
in italic text.
1. Purpose
- GTM should be usable for communicating the contents of a topic map to students and readers of technical papers. This means that GTM should effectively be able to express the same information as the TMDM, but in a visual form. This is the purpose served by GTM level 0.
- example: Tosca was composed by Puccini
- GTM should be usable to communicate the constraints on a Topic Maps ontology to customers, developers, students, and readers of technical papers. This means that GTM should effectively be able to express the same information as TMCL Schema, but in a visual form. This is the purpose served by GTM level 1.
- example: every opera must have at least one composer
2. General Requirements
- GTM must support both of the purposes described above.
- ie. both instances and constraints
- GTM should be easy for humans to read.
- GTM should be easy for humans to write, using either
- a modelling tool with GTM support,
- a general vector drawing tool, or
- simply manually on a whiteboard or blackboard.
- GTM models should be compact, and conserve visual real
estate.
- The two parts of GTM should be visually consistent; that is, they should use a common set of shapes.
- The GTM standard should not rely on colour for communicating model information. That is, if a GTM model is printed in black and white, no standardized information should be lost.
- A GTM model is not required to display every aspect of the represented TMDM/TMCL instance. If essential information is omitted, GTM must specify the shapes to be used as a "shorthand" for the omitted information. (Note that this applies only to simplifications such as omitting the type and role types of an association, and is not a general templating mechanism or support for clustering of topics.)
- The visual structure of a GTM model should correspond as closely
as possible to the structure of the topic maps being either
represented directly (in level 0) or constrained by the model (in
level 1).
- The shapes used by GTM must be fit for purpose (e.g, something with multiple connection points should be designed in such a way as to aesthetically facilitate this).
- All GTM models must be required to use a consistent set of shapes to represent the various underlying TMCL and TMDM constructs. (That is, the shape used to represent, e.g, topic types should be consistent across all GTM models.)
- Requirements on shapes must be specified as minimal requirements only, to allow users to make extensions to GTM (such as use of colour and fill patterns) without being incompatible with the standard.
- GTM must define precisely what is considered to be consistent with the standard, and what is not. (For example, is rotation of the shape allowed; is using a fill colour inside the shape allowed, etc etc)
- GTM should aim to not constrain visual representations of GTM models any more than what is necessary for consistency. That is, the constraints on visual representations should be minimal.
- GTM must provide some way of visually representing both information from level 0 and level 1, and the connections between the two levels.
Comments on Requirements
- GTM needs to support breaking models up into several diagrams. It must be possible to see how these diagrams are connected into a single model.
- The editors need to make requirements 2:8 and 2:9 more precise so people know what it means.
- 2:9: something about using shapes that allow many connection points
- 2:11 and 2:13
- merge
- make extensibility the main point
- how is secondary
- There should be some way to annotate the diagrams with textual extra information.
- The visual vocabulary used in GTM should be systematically designed.
- The standard needs to make the systematic approach taken explicit.
- Although we are going to have a consistent visual vocabulary, visual or textual variation within that visual vocabulary is not necessarily forbidden
- should such variation come to not be forbidden, it must be
clear what the limits for legitimate variation are
2. General non-requirements
- The standard will not define an interchange format for GTM diagrams and models similar to XMI for UML. (Except in so far as this is supported by CTM and XTM.)
- Features such as filtering, zooming, and layering will not be defined by GTM, although tools may well provide these functions, so long as the resulting models conform to GTM.
- No data model for the visual shapes will be defined.
3. GTM level 0
- GTM level 0 must be able to represent all item types and properties in the TMDM.
- GTM level 0 may also define shapes for representing the type-instance and supertype-subtype association types defined by TMDM.
- There must be a precise definition of how the shapes in GTM level 0 map to constructs in the TMDM.
3. GTM level 0 non-requirements
- GTM level 0 only represents TMDM, and no attempt will be made to represent any aspects of CTM and XTM beyond those present in TMDM.
3. GTM level 0
- Note that since TMCL constraints have a TMDM representation it is possible to represent these constraints in GTM level 0. This is considered to be useful for communicating the TMDM representation of TMCL constraints, but not to be suitable for communicating an actual set of constraints to customers etc as described under "Purpose" above. This is why a level 1 is proposed in addition to level 0.
4. GTM level 1
- GTM level 1 must be able to express everything that TMCL Schema can express. That is, it must be possible to generate a TMCL Schema from a GTM level 1 model.
- GTM level 1 must be conceptually similar to existing modelling formalisms such as UML, ORM, and ER.
- GTM level 1 must allow a representation of TMCL constraints that is more compact than the representation of the TMDM form of these constraints in GTM level 0.
- There must be a precise definition of how the shapes in GTM level 1 map to constraints in TMCL.
Now What?
- Editors to produce new version of requirements document
- Editors to
- collect existing proposals
- make sure they are all available online
- maintain a list of links to the proposals
- Editors to propose GTM draft by July 2 (in time for Extreme)
