The TM4L Editor is an ontology editor allowing the user to build ontology-driven learning repositories using Topic Maps. It provides ontology and metadata engineering capabilities coupled with basic document management facilities. The TM4L Editor benefits from the Topic Maps’ fundamental feature to support easy and effective merge of existing information resources while maintaining their meaningful structure. This allows for flexibility and expediency in re-using and extending existing repositories. The learning content created by the Editor is fully compliant with the XML Topic Maps (XTM) standard and thus interchangeable and interoperable with any standard XTM tools. The TM4L Editor is Topic Maps-based, thus the main objects that it manipulates are topics (representing domain ontology concepts), relationships between them, resources, and contexts (represented by themes). It includes four different sections (views): Topic Map, Topics, Relationships, and Themes. The user interface uses the Tab metaphor; each tab is associated with a different view on the Topic Map: Topics, Relationships and Themes view. Screenshots from the TM4L Editor interface (the Topics and Relationship sections) is shown on Fig. 1.
Figure 1. Screenshots from the TM4L Editor interface: Topics and Relationship sections.
Topic Map. In the Topic Map section the author defines metadata (Dublin Core and LOM compliant) for the newly created Topic Map. This includes: TM Title, Creator, Subject / Main Topic (keywords), Description, Publisher, Contributor, Creation Date, Last Modification Date, Language, Location, Source, Relation, Coverage, IPR / Copyright. Additionally, a Topic Map Subject Indicator is specified. Some LOM tags are automatically included in the TM metadata with pre-specified values, e.g. LOM 4.1 Resource Format (“text/html”), LOM: 5.1 Interactivity Type (“expositive document”), LOM: 5.3 Interactivity Level (“high”), etc.
Topics. In the Topics section the author defines, edits, and deletes topics. Each topic definition includes the following information: subject indicator, names, types, and related resources. For each new topic an ID is automatically generated.
Topic Categories. Our major concern in designing the Topic Maps Editor was related to the fact that in the TM standard every subject is a topic, which is a powerful idea but will not make much sense to the uninitiated authors. Three different kinds of topics are expected to be used in an educational Topic Map: ‘concept’ topics needed to build the ontological representation of the specific subject domain, ‘utility’ topics needed as meta-data fillers in the Topic Map, for example, to specify the different types of educational resources, and ‘system’ topics needed to represent association types, roles in associations, and other entities required by the TM model. In TM4L we combine the utility and system topics and support two distinct categories of topics: domain ontology topics and utility topics. The former are defined by the user and listed in the Topics section; the latter are automatically defined by the editor, e.g., when a specific authoring activity (such as defining a new relationship type) takes place and are not normally listed in the Topics section. We use the following utility topics categories: association types, association role types, occurrence types, name use types, and themes (for scoping). The category of a topic depends on where it was created by the user, for example, if it was created as a result of user input in the ‘Create Relationship Type’ dialog, it is an association type.>
Topic Names. TM4L allows multiple topic names: one primary and possibly some alternative names. Each name can have alternate names (TM name variants) to be used for special purposes. In this application we have constrained the number of alternate names to four, corresponding to four different purposes of usage of the name: sort, search, display, and draw.
Topic Types. In compliance with the XTM standard, multiple topic types are allowed. The user is given two ways to declare a topic type (or parent topic): either automatically by selecting an existing topic prior to the creation of the new topic, or manually by adding a parent in the ‘Parent Topic Panel’.
Resources. Resources can be internal and external. Internal resources are short pieces of information about a concept, such as definition, short description, some characterizations, etc., stored locally in the Topic Map. External resources can be any addressable learning objects on the Web referenced by their URI. For authors’ convenience, some resource types are pre-defined however the author is allowed to define their own types. We have predefined the LOM 5.2. Learning Resource Types: exercise, simulation, questionnaire, diagram, figure, graph, index, slide, table, narrative text, exam, experiment, problem statement, self assessment, and lecture. In addition, we have predefined types of learning resources relevant to characterizing subject domain concepts: definition, description, example, and graphical representation.
Relationships. Relationships in our model are represented by Topic Map associations. Each relationship has a type (e.g., ‘is-component-of’) and one or more members (concrete topics) along with the roles they play in the relationship. There is a pool of pre-defined relationship types (such as ‘class-subclass’) that the authors can use. In the Relationships section of the Editor the author can define relationship types and roles, create relationships by specifying their types, roles, and role players, and edit and delete relationships. When defining relationships the author selects all involved entities – relationship type, members, and roles, from presented lists, so that input errors are minimized. The scope (context) within which the assertion made by a relationship is valid can be defined in the Theme section. If none such is present, the scope is unconstrained and the relation is always valid. Instead of adopting a single “perspective” on classes of concepts, our model includes three basic concept hierarchies. In this way we are able to create more expressive conceptual structures that include various classifications of certain concepts. For example, operators can be classified by arity (unary, binary, and so on) or by type (arithmetic operator, Boolean operator, String operator, and so on); Java threads can be classified as “part-of” the JavaVM or as “sub-class” of the user–level threads. By enabling different perspectives, we can model different classifications of topics at the same time
Contexts (Views). We conceive the notion of context as derived from two principles: the principle of grouping and the principle of locality. According to the first principle the context is a notion, capturing a fragment of related entities. Grouping can be based on different criteria and different assumptions. We perceive context as a generalization of “putting together”, clustering and categorization: it combines all types and patterns of grouping. That’s why the notion of context is so elusive, despite of the various models proposed and developed. According to the second principle the notion of context is an abstraction, capturing the localization principle in various aspects. For example the principle of locality applied to a given topic in terms of the topics directly or indirectly related to it, determines the set of topics that are somehow related to the selected topic, that is, determines the context of relevant topics. If we apply the localization strategy towards selected relation type, then we arrive to a new type of context (perspective). For example if we select the “whole-part” dimension we can see the topics from a particular hierarchical perspective. Thus the proposed approach to contexts captures also the notion of perspectives (or viewpoints). TM4L allows authors to define contexts through the use of relations and scope (theme). The notion of theme makes it possible to express multiple viewpoints on a single set of learning resources and provide personalized views for different groups of learners. The theme mechanism of TM4L enables any information provided about a topic to be qualified by defining a context within which the information is valid. Theme may be used to define several different perspectives on the same set of information. For example, theme may be used to separate "beginner" resources from "intermediate" or "advanced" resources, thus enabling different sets of information to be presented to learners on different levels. The TM4L Editor is implemented in Java and uses the TM4J Topic Map Engine, which is an open source providing a comprehensive API that allows creating and modifying Topic Map structures stored either in-memory or persistently in a database. The Editor has open modular architecture that allows an easy extension of its functionality./p>