Hello everybody ! my name Is hendrik thomas, I am a phd student of the technical university of ilmenau. In my research I work on the question “how topic maps can be used to enhance the subject indexing in digital libraries” In this context of digital libraries I talk quite often to librarians and it is quite easy to explain the advantages of topic map in representing knowledge to them. However, when it comes to visualization of this knowledge to the enduser, most librarians prefer a simple list or table. In my opinion a graphical visualization of the knowledge network can be a helpful - and now comes the tricky part - I can simple not show any real live example where an existing topic map visualisation can really help the user to solve a retrieval or navigation problem. This Problem haunted me for some time and today I want to explain you, why traditional visualization approach for Topic Map is unsufficiently and and how a creativ design approach can improve the helpfulness . Therefore I want to present tmchartis - a prototypically tool set for designing multiple problem oriented topic map visualisations
In the last years several drafts for a GTM including an ISO/IEE document with requirements for a GTM has been published. However, till today no graphical notation is generally approved and used in the Topic Map community[18, 3, 16, 5]. For example, the conference proceedings of the last two international conferences of Topic Maps and Applications contained overall 51 graphical representations of topic maps, but every single paper used a individual notation. Concluding a standardizes graphical Topic Maps notation is still missing, which is quite odd, given the acknowledged importance of a graphical notation as a communication and modeling devices[16, 17] In the last years several drafts, recommendations and concepts for a GTM have been published, but till today no graphical notation is general accepted and´used in the Topic Map community[3–7]. Recent studies showed that the common trend to reuse and adapt existing graphical notations from the field of data and knowledge modeling [6, 7] is not suitable for this task [8, 9]. Evidences could be identified which indicates that none of these existing notations 1 could be used
Becker, Rosemann, Sch¨utte published in the late 90s a set of Generally Accepted Modeling Principles (GAMP) as a standard framework of guidelines for modeling [9, 10]. GAMP provides general valid design recommendations, which are suitable for our purpose because every GTM models a specific topic map draft [17, 16]. Based on the following five objectives for a GTM can be deduced. The 1. object is completeness, in term that the graphical representation (model) must follow every rule defined in the TMDM (topic has name, have varinat name, has scope …) 2. objectivs is consitency - A GTM is considered as consistent, if the graphical presentation does not allow different interpretations. For example, two elements can be connected with a strait line with arrow heads on both sides. This is from our point of view not a consistent presentation because of the missing reading direction, which makes the interpretation of such a relation ambiguous for a user Relevant – this means every GTM transformalbe without lossing or adding any element or meaning GTM should also provide different views on relevant aspects to simply and support understanding especially if the TM is huge Considering a cost-benefit-ration, the amount of effort which is necessary to create a graphical visualization and using the notation should be as low as possible – strong implication for the amount and complexity of the elements Finally, a GTM must reflect the unique characteristics of the Topic Maps paradigm [2, 13]. Essentially two features must be taken into account. First, we have to consider the fundamental rule of Topic Maps: one topic per subject. As a result in a graphical representation a subject should be modeled by exact on element. If this is not possible the notation must provide suitable indicators, which makes clear, that two elements represent the same subject [13, 2]. Furthermore in Topic Maps all kind of types (e.g. topic types, association types, association role types, name types and occurrence types) are represented by topics. As a result a topic can act as a class but at the same time as an instance. These quite unique feature must also be considered in the notation.
Turning to the actual design of a GTM, two observations can be made regarding to these requirements.
Turning to the actual design of a GTM, two observations can be made regarding to these requirements. RDF literale
annotation for explanation?
The tricky thing with names is, they are the main thing to identify a topic but they can be very complex fast drawing vs. high expressivness as a results we have the first name visualisation option – just write it inside the bubble – this is good for identificant but you can not modell any additional information (type) second modell the name completely = als a value with role symbole = it is more AUFWENDIG but you can add as much additional information as you like = but both type as displayed here are equal = represent the same facts
topic map developing process very often the discussion is limited to a specific topic rather than to the whole complex topic map network. To provide users a detailed view on the modeled knowledge on a relevant subject in GTMalpha the so-called subject-centric view was pre-defined. In this view all topic map elements are drawn according to the presented GTMalpha notation rules, which ensures a cross-model consistent representation and visualization. The layout of the subject-centric view is tree oriented in contrast to the network orientation of the domain view. This enables a well-structured and easy-to-grasp presentation . In the subject centric view the topic of interests is placed at the top and all modeled information are arranged in an explore tree beneath it. We recommend to start with the subject identity, followed by all topic types, topic names, occurrences and at the bottom all association the topic is involved in. Fig. 11 shows the subject-centric view for the central topic Ilmenau of the previous topic map draft. In the end in both views the same information are displayed, only different default layouts are used in order to highlight a specific aspect, e.g. overview or detailed information. Other views are possible.
As the name GTMalpha indicates, the focus was on the design o f a practical usable notation. However, it is still a draft and only the broad usage of GTMalpha in the Topic Maps community can lead to a final answer of the question: is GTMalpha really suitable for representing topic map drafts. Overall a GTM has been missing for so long and with this proposal we hope to start a fruitfully discussion, which will finally lead to a official standardized GTM.
Thanks for your attention – I’m happy to answer any questions you may have.
Beside these criteria, from a pure pragmatic point of view, a GTM is only suitable for the needs of the Topic Maps community, if it allows to draw a Topic Maps draft fast and easy – with a bad handwriting using a half-full pen on a dirty white board – and an foreign ontology expert is still able to grasp the structure and the elements of the topic map draft correctly and consistently. This is what we need to support the modeling process and communication.
GTMalpha a graphical notation for Topic Maps - TMRA08
GTM alpha towards a graphical notation for Topic Maps Hendrik Thomas 1 , Tobias Redmann 2 , Maik Pressler 2 , Bernd Markscheffel 2 1 KDEG Trinity College, Ireland 2 Ilmenau University of Technology, Germany
Outline <ul><li>Introduction </li></ul><ul><li>Requirements for a GTM </li></ul><ul><li>General GTM Design </li></ul><ul><li>Tutorial for GTM alpha </li></ul><ul><li>5. Summary </li></ul>
1. Introduction <ul><li>Graphical Notation for Topic Maps (GTM) </li></ul><ul><ul><li>supports modeling, documentation and discussion </li></ul></ul><ul><ul><li>notation ensures consistent interpretation exchange and reuse </li></ul></ul><ul><ul><li>several drafts and proposals, BUT no standardized or generally accepted GTM </li></ul></ul>Contribution: Design of a new graphic notation for Topic Maps Presentation of the draft GTM alpha Steve Pepper: TAO. 2002
2. Requirements for a GTM <ul><li>General modeling requirements: </li></ul><ul><ul><li>COMPLETNESS according to the TMDM </li></ul></ul><ul><ul><li>CONSISTENCY only one interpretation </li></ul></ul><ul><ul><li>RELEVANT transformation without losing or adding elements </li></ul></ul><ul><ul><li>LAYOUT & VIEWS support and simplify interpretation </li></ul></ul><ul><ul><li>ECONOMIC EFFICIENT easy to learn and use </li></ul></ul><ul><li>Reflect unique characteristics of Topic Maps: </li></ul><ul><ul><li>ONE-TOPIC-PER-SUBJECT same rule for graphical topics </li></ul></ul><ul><ul><li>MULTIPLE TOPIC ROLES instance and type at the same time </li></ul></ul>
3. General GTM Design (1 of 2) 1.) Which basic layout? 2D-graph layout with many different elements (topic, types, occ, etc.) 2.) How to separate the different elements? different colors topic scope type occ different geometric shapes topic scope type topic type topic type BUT: topics can be types AND instances
3. General GTM Design (2 of 2) <ul><li>Solution: </li></ul><ul><ul><li>Topic represented by a unique shape </li></ul></ul><ul><ul><li>Values represented by a unique shape </li></ul></ul><ul><ul><li>Any text outside a shape is a comment </li></ul></ul><ul><ul><li>Add symbols to indicate the role of an element </li></ul></ul>topic value comment Subject Identity Occurrence Scopes Topic Names Instance-Types
4. GTM alpha tutorial – Topics and Types (1 of 2)
4. GTM alpha tutorial – Topics and Types (2 of 2)
4. Summary <ul><li>GTM alpha is a fully documented graphical notation for topic maps </li></ul><ul><li> complete, consistent, relevant, provides 2 views, (easy to learn) </li></ul><ul><li>Open Tasks: </li></ul><ul><ul><li>tool support shape sets for DIA and Visio needed! </li></ul></ul><ul><ul><li>automated transformation of GTM alpha drafts in other notations (XTM, LTM, CTM) </li></ul></ul>Is GTM alpha suitable for the representation of topic maps? ONLY THE COMMUNITY CAN DECIDE BUT ITS DAMN TIME FOR A OFFICAL GTM STANDARD!
2. Requirement for a GTM (2/2) any GTM draft must fulfill these requirements to support modeling & communication <ul><li>Pragmatic point of view: </li></ul><ul><li>A GTM allows to </li></ul><ul><ul><li>draw a topic map fast and easy </li></ul></ul><ul><ul><li>with a bad handwriting </li></ul></ul><ul><ul><li>using a half-full pen </li></ul></ul><ul><ul><li>on a dirty white board </li></ul></ul><ul><li>AND a “young ontology expert” is still able to understand the element & structure </li></ul>