The IMAP-DTD

Paul Hermans
Pro Text
Interleuvenlaan 62
Leuven
3001

Abstract

In this paper we outline how the use of design principles had a benificial impact on the modelling of the hierarchy of information, object information, meta-information and shape-information in electronic documents.


Starting point : two frustrations

Lack of a methodology for document analysis and DTD-design

In contrast to the design of relational database systems, there is no such thing as "normalization" or other, generally accepted design principles in the field of document databases.

Yes, there is the CADE-course of Microstar. CADE stands for Computer Aided Document Engineering. The summary of this so-called methodology is: gather all information-elements, throw them in Microstar's Near & Far DTD design software tool and then make 101 reports for your supervisor.

Yes, there is an upcoming book of Jeanne El Andaloussi from Bull and Eve Maler from Digital, who worked together on the development of the Open Software Foundation DTD. But it is still not available.

So, what is left for the (aspirant) information architect? Looking at and studying other people's DTDs such as the TEI-, IBMIDDOC-, OSF-, DOCBOOK-, and other public domain DTDs, and be prepared for a lot of learning by trial and error.

The essence of our own experiences will be covered in the next sections.

Describing spaghetti

Although you are sure you have the best tool to describe structure and content in documents (i.e. SGML of course), the raw data you have to work with at a customer's site is sometimes so badly and inconsistently structured that you end up with very loose DTDs.

It is our opinion that SGML-ing doesn't make sense if the legacy data are themselves too badly structured.

But how to ameliorate the raw material?

I remembered from my cognitive science background the term "Information Mapping". We tried to find some books on the subject, ... and we ended up following an IMAP-course. Besides learning a framework to structure information, the IMAP-methodology itself just asked to be SGMLed.

Developing the IMAP-DTD

Functional demands

The SGML application had to facilitate :

Therefore our guiding design principle was : "Name everything by name".

Framework

In a DTD you describe the structure and content of your information.

This can be divided in four classes:

hierarchy

You have to define the high-level organizing containers within which the other elements are contained. In other words you describe the organizational structure of your information. Typical containers are : book, part, chapter, section, etc.

objects

You describe the structures and properties of real-world objects. e.g. a motor has different parts. Each part has a number, a name, a description, a functionetc.

It is clear that the more you can describe the information in objectterms, the better your chances for supporting efficient information retrieval will become.

meta-information

Besides the information itself, most of the time you also want to describe information about this information. E.g. who wrote it, which version is it, what security level does it have, for which operating system was it created, etc.

shape of the information

You can describe the presentation form or appearance of information, e.g. paragraph, list, table, emphasis, etc.

Our experiences and opinions

hierarchy

Stage 1

The hierarchy was first described as follows :

a book starts with a booktitle, followed by more than one parta part starts with a parttitle, followed by more than one chaptera chapter starts with a chaptertitle, followed by more than one sectiona section ....

Is it necessary to name each title explicitly ?

No, because you are working in a hierarchy, you and all SGML-aware software know what the context of a title is; you know the containing element. It is obvious that the first element with identifier "title" inside a chapter is a chaptertitle.

Neither does this explicit naming enhance retrieval value. A user doesn't know and care if, what he is searching for, is in a sectiontitle or in a subsectiontitle.

Stage 2

The hierarchy second version :

a book starts with a title, followed by more than one parta part starts with a title, followed by more than one chaptera chapter starts with a title, followed by more than one sectiona section ....

But one of our design goals was the reuse of information. What happens if I want to use a chapter of my first book as a section in another one ? It doesn't fit hierarchically.

The best solution

The hierarchy made flexible :

a book starts with a title, followed by more than one divisiona division starts with a title, followed by more than one division OR "divisioncontent" (ESCAPE from the recursive definition of a division).

Leave it to the processing afterwards to give the division a name.

In this same context of reusing containers of information, be careful in using the "#current" keyword as attribute default.

Conclusion

Name it by name, but not the hierarchical containers.

objectinformation

This is what Information Mapping is all about. A map describes and/or the concept, the structure, the facts, etc. of an object.

More, for every information type the method gives you all the elements needed. E.g. for the description of a structure you can textually describe what it looks like, you must have a diagram of the object and you can have a table with an enumeration of all the parts with as subelements partnumber, partname, partdescription, partfunction, etc.

meta-information

Elements or attributes ?

What you see in some recent DTDs is that the higher level container elements start with an optional subdivision in which meta-information can be stored. E.g. The OSF-DTD starts with a meta-element for describing documentinformation, productinformation and a variety of notices.


Figure 1.
a meta-element instance

On a lower level an element's meta-information is stored in attributes. E.g. the IBMIDDOC DTD.


Figure 2.
attributes on an element of the IBMIDDOC DTD

Some considerations in this context :

The IMAP-DTD

Meta-information is only implemented on a limited scale, because it is our belief that meta-information must be customized to the needs/wishes and most of all the budget of the client.

So, on the highest level we have only an optional element to store independent hypertextlinks (HyTime).

And on the element-level we use only a few attributes mainly for the purpose of hypertextlinking.

Shape of the information

Principles

Since information shape elements do not add any information retrieval value, their use must be postponed until no other way of describing the element is available.

Use only the paragraphelement if you have more than one visual block inside the containerelement. In several DTDs the para-element is used redundantly, which only frustrates the editor.


Figure 3.
the DTD used for SGML BeLux

IMAP-DTD

Elements which can't be described any further as object, can have as content :

No tables

Although the IMAP-methodology is full of the use of tables, we didn't use a generic tableshape-element.

Since one of our design principles was to guide the writer/editor completely according to the principles and terms of the IMAP-methodology, we always used the IMAP- names.

E.g. A decisiontable consist of a list of "rules". Each rule has an if-part and a then-part. The writer will be using this terms while editing the information. It is by the use of architectural forms that the if-part and the then-part are mapped to a cell-element and the rules are mapped to a row-element.

This advantage on the editing and retrieval side can have a drawback on the formatting side when the processing software doesn't have facilities to do some formatting on the basis of architectural forms. Then you have to format all those named elements with a table/row/cell-shape instead of one generic shape element.

Other remarks

Inclusions

We never felt the need to use inclusions. Furthermore, recent postings on comp.text.sgml have highlighted some severe drawbacks of the use of inclusions.

Elements used for processing purposes

Normally one uses the processing software to autonumber elements. So you don't need to tag e.g. a separate stepnumber per step in a procedure.

We did, because in the IMAP-methodology a procedure is explained in a proceduretable. So we used for each step (row) an empty step.number element for mapping it to the architectural form cell-element and of course to do the autonumbering inside this cell.

Two DTDs for IMAP : presentation in Near & Far

1990

The first IMAP-DTD was developed in 1990. It reflects the timespirit, using SGML more as a system independent format description tool.

This DTD explicitly names structurecontainers and uses solely shape elements.

1994

Pay attention to:


We would like to acknowledge :

for most of the good ideas we didn't have to learn the hard way.