Topic Maps 2008: Tutorial Day

I am currently at the 2nd International Topic Maps Conference, held in Oslo, Norway; Topic Maps 2008. Today was tutorial day.

This is what I got some insight into today (they are all bits and pieces, but I include the notes here for sharing).

Open Source Topic Map Portals

Arnar Lundesgaard, the lead developer of Zope Topic Maps, held a 1/2 day presentation on ZTM3. For me, it was vital to attend this introduction to ZTM3, as I have high hopes for it … and we will def. be building sites on it in the not too distant future.

Status & ZTM2 vs. ZTM3

Arnar told us that ZTM3 is still under development, but very close to being ready for deployment, with a pilot application (for UiB) going live at the end of this month. It is open source and written in Python — on top of Zope3. The core engine is released under LGPL, while the user interface components will be GPL lisensed.

In order to contribute to ZTM3, one doesn’t have to know much about Zope or any of the other technologies used. This is contrary to ZTM2 (Sourceforge project page), which did require comprehensive knowledge about both the application server (Zope2), the content managment framework (CMF), the topic maps standard, and much more. If one is able to do HTML/template coding, program python, design, etc. and have something to contribute to the project, one should be able to contribute.

There were also a lot of other issues with Zope2 and ZTM2 — bad design/architecture, very steep learning curve for developers, difficult to separate between implementation and architecture, etc. — which lead to a rewrite for ZTM3.

ZTM3 uses the new architecture/design of Zope3 and will be module based for flexibility (interfaces, object storage, adapters, utilities, site managers, views, layers, skins, Python eggs).

The ZTM3 modules are:

• ztm.topicmaps - the core engine
• ztm.navigator - an omnigator clone (even the colors were the same :D)
• ztm.editor
• ztm.interfacemanager
• ztm.contenteditor - ontology editor
• ztm.search - support for filters/sorting/relevance hit
• ztm.imagearchive
• ztm.filearchive

Installation

Installation will be done via easy_install.
Arnar is also in the process of making `ztmproject’, something I suspect (and got the impression of) will work in much the same way as `zopeproject‘.

Arnar claimed that it is not going to be as easy to deploy as PHP-style hosting, but is going to support WSGI later on. In any way, it is supposed to be much easier to set up than ZTM2 is/was, and like Arnar I don’t think writing 4-5 commands ought to be a show stopper.

Usability Works!

What is a bit unique about ZTM3 and the development philosophy, is that usability is placed at the center of things. As one of Arnar’s slides said: Usability Works!

The thought is that user should not have to worry about the system or have to know what topic maps are. It must work like any other CMS. This is something I believe is extremely important for this kind of application, and many applications (generally speaking) — I would dare to say often the open source ones — fail.

The ZTM3 development is supported by UiB and Bouvet, and interaction designers as well as graphic designers will be involved in creating a usable system - once the functionality is in place. It’s also good to know that the developers really care about making a system that ordinary people should be able to use.

Development and Performance

The development of ZTM is unit test driven, and uses bazaar for distributed version control.

Performance-wise it is not yet optimized as they are currently focusing on functionality. It is, however, never going to be the fastest thing in the world (hard to do with such a graph-like structure). The team is aiming for ZTM2’s performance and focus on flexibility instead. ZTM3 should be great for small to medium sized sites (for a list of ZTM portals, refer to the ZTM Wiki).

Caching of output (front end) will of course help on performance.

Demo & New Features

Arnar also gave a live demo of some parts of the admin interface. The UI is still kinda buggy, but it looked very promising. There is a lot of jQuery/Ajax going on in the interface, which will benefit the editors. The ontology editor does for example support inline editing as well as drag and drop for e.g. assigning name types to topic types, changing order of topic characteristics (as they will occur for the content editors), etc. Pretty cool.

In ZTM3 they have moved away from the one-topic-per-page paradigm, as they often need to present multiple topics on one page.

Eventually, ZTM3 will support inline editing of content, meaning that it will be much easier for content editors to use the system as they actually edit what they see (on the front end). Inline editing removes inconsistency between what you see on the front end and what you see in the editor (in ZTM2, editors had to move between topics even though the front might’ve presented multiple topics).

ZTM3 does also support scoping of content, which means that it is possible to quite easily support multiple languages or e.g. user group tailored content.

There will be `widgets’ like datetime, wysiwyg, etc. that ontology editors might specify as datatypes for occurrences.

Arnar did also “promise” that there will be wizards for content creation and that ZTM3 will include workflows, integration framework (RESTful).

ZTM3 can import topic maps that are encoded in XTM 2.0.

There should also be a standard user interface, while the UI might be customized using any kind of Python templating system.

Constraining Topic Maps with TMCL

After lunch, Graham Moore of Networked Planet held a tutorial on the upcoming ISO standard TMCL.

Status & Influences

TMCL has been under development for approx. 5 years now, so it’s definitively about time it is reaching the final draft stage (I guess it would have moved much quicker through the system had it been a product of Microsoft :p).

The delay is partly caused by a lack of resources (=> people and time), and partly due to it being dependent on TMQL and CTM. Both of which are also under development.

Graham hoped to see many of the remaining standards from the topic map stack going into a fixed (final draft) state after an ISO meeting which is being held this weekend. So do I; having a constraining languages such as TMCL is very important for the community and the standard stack.

TMCL is influenced by UML, Schematron, OWL, OSL (Ontopia’s), K42 Schema Language (?), NPCL (Networked Planet’s).

What it’s all about

TMCL lets users define constraints on topic map constructs and enables schema validation of topic maps & topic maps content (ontology and instance layer). It is inference free — there are no kind of inference rules, etc.The use cases that have driven the TMCL group’s work are about

• Topic Maps Validation.
  Topic maps fragment(s) from topic map A needs to be checked before being imported into topic map B, consistency check for resulting topic map, etc.
• User Interface Generation — for ontology editors.
  E.g. “What kind of associations can a Person be involved in, and what are the role types in such an associations? UIs for guiding users / avoiding unnecessary errors.
• Meta Programming.
  Annotation at the type level. Expressing things about types.

People like me, who have used the OKS‘ ontology editor Ontopoly, will probably have seen such a (kind of) language in use — for example through OKS’ ontology annotation capability, which allows you to express things about e.g. topic types or association types.

The goal is to being able to express what is implied

Metamodel Topics

TMCL defines metamodel topics with PSIs. These are:

• TopicType
• AssociationType
• OccurrenceType
• NameType
• AssociationRoleType

TMCL Terminology

A contraint type is a class of constraint.
A constraint is a single constraint type instance.
A schema is a set of constraints

Constraint Templates++

There is no error reporting defined by the standard. It does just indicate whether a constraint/schema is valid. Error handling should be done on the implementation level.

TMCL is written in CTM or XTM.

TMCL defines some specialized association types; for example applies-to(x: constraint-role, y: topictype-role).

TMCL does also define constraint templates (template = CTM construct), such as isAbstract($topictype). Example of use:

vehicle isa tmcl:topictype
isAbstract(vehicle) # defined in imported TMCL

There are other such templates, such as NotDisjointConstraint (disjointness of classes is the default, which seems like a reasonable pick), SubjectIdentifierConstraint (min/max cardinality) and cardinality constraints on occurrences, association types, association role types, name types, scope types, etc.

TMCL will also allow you to define regular expressions for matching of patterns (e.g. names or occurrence values).

TMCL is extendable; people may define their own constraints and people or organizations may publish constraints for others to use. If topic maps are to be used across different applications and domains, the latter is definitely of importance. Being able to enforce constraints, like being able to explicitly state which topics are types or how many occurrences of a given type might exist on a given topic, is also very important. Being able to do so in a standardized manner is also a very nice thing.

TMCL will be published on http://psi.topicmaps.org/tmcl/.

Good to see this getting closer to a standard!

This entry was posted on Wednesday, April 2nd, 2008 at 22:29 and is filed under Topic Maps. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.