TopicMaps

Authoring a Map < AsTMa* Topic Map Engineering (Part I) < < Home

Authoring a Map

Most people will be familiar with literature references, either by managing their own small databases or having used a library. Having such a rich history and librarians as challenging users, real-life reference database tend to be quite complex in terms what meta data they store and how they represent it for efficient retrieval.

In this article we concentrate more on principles of this application domain and ignore in many aspects the complication of the real world. In any case we assume that for every piece of literature (book, article, ...) there exists at least one URI (URL or URN) to address the object. One specific URI will be used as unique identification; this cite code can then be used by other parties to address a publication. All of the publications have potentially any number of authors.

The basic information we have to cover are the publications themselves, mainly their title and other basic information. Furthermore we have to allow documents to have any number of authors, authors themselves having affiliations and other contact information.

Publications

The first trivial design decision we take is to represent every publication of our literature database in a separate topic:

definitive-xml-app-development (book)
bn: Definitive XML Application Development

In this case the publication is an instance of book; we anticipate that there are more such classes as articles, standard documents, etc.

It also does not seem to be controversial to store the title of a publication as a basename. One complication comes in if we want to use this string within a LaTeX[latex-kopka] document, say using BibTeX: To achieve a uniform look, frameworks like these will do their own capitalisation. While this is not problematic per se, some words must remain in capitals, such as 'XML' above. As this cannot be automated we want to give the author the option to add another name, say in scope latex to be explicit about the capitalization:

definitive-xml-app-development (book)
bn:         Definitive XML Application Development
bn @ latex: Definitive {XML} Application Development

Comments

Another addition we can easily make is to allow text to be added as inline occurrence. Typical applications are comments, abstracts or other information pertaining this particular publication:

definitive-xml-app-development (book)
bn:         Definitive XML Application Development
bn @ latex: Definitive {XML} Application Development
in (comment): too little Perl, too much Java ;-)

Cite Codes

If we would like to add a unique code which authors can use to refer to a particular publication. For this code we can use a URN where we control the namespace, say, via the prefix urn:x-bibtex. Just to be on the safe side and avoid collisions with other codes which might be added later we restrict this code only to exist in our latex scope:

definitive-xml-app-development (book)
bn:         Definitive XML Application Development
bn @ latex: Definitive {XML} Application Development
in (comment): too little Perl, too much Java ;-)
oc (cite-code) @ latex: urn:x-bibtex:lmg02

For authors using LaTeX literature references it is mandatated that they should use this code; other applications might have their own codes.

In any case our intention is to hold this code unique within our literature database.

Online References

In case of online publications we certainly want to capture the URL referencing the document. One option is to use an occurrence. Another one is to use direct reification of the external resource and use the URL as subject address as in the following example:

ltm-spec (specification) reifies http://www.ontopia.net/download/ltm.html
bn:         LTM, The Linear Topic Map Notation
bn @ latex: {LTM}, The Linear Topic Map Notation
oc (cite-code) @ latex: urn:x-bibtex:lmg01
in (abstract): This technical report defines ...
oc (proposal): http://www.ontopia.net/topicmaps/materials/ltm-1.3-prop.html
oc (homepage): http://www.ontopia.net/topicmaps/ltm.html

In creating this topic we also have added pertaining information in and about the concept LTM. In that we are actually rather sloppy: We do not distinguish strictly between the document LTM Specification, the abstract concept of the specification itself and the technology LTM. Reifying a document obviously means that the topic is a proxy for the document. Adding typed occurrences would, in turn, more speak for the abstract concept of that specification.

A more thorough approach would be to separate these and link them with associations:

ltm-spec-doc (online-document) reifies http://www.ontopia.net/download/ltm.html
bn:         LTM, The Linear Topic Map Notation
bn @ latex: {LTM}, The Linear Topic Map Notation
oc (cite-code) @ latex: urn:x-bibtex:lmg01

(is-covered-by)
cover : ltm-spec-doc
theme : ltm-spec

ltm-spec (specification)
bn:         LTM, The Linear Topic Map Notation
bn @ latex: {LTM}, The Linear Topic Map Notation
in (abstract): This technical report defines ...
oc (proposal): http://www.ontopia.net/topicmaps/materials/ltm-1.3-prop.html
oc (homepage): http://www.ontopia.net/topicmaps/ltm.html

(is-defined-by)
definition : ltm-spec
object     : ltm-technology

ltm-technology (topicmap-notation)
bn: LTM, a Topic Map notation

As expected, only the document itself carries the cite code. Relative to the literature database it is only the document which we are interested in; all other information might only be relevant in a broader context.

Where and how to stop will depend on the overall objectives. For the following discussion we decide to compromise a clean modeling and pull everything into one topic.

Authors

To represent authors we simply can create one topic per author:

p-lars-marius-garshol (person)
bn:  Lars Marius Garshol
bn @ latex : Garshol, Lars Marius
sin: http://www.garshol.priv.no/

Again, we should take care of the use in a specialized context such as using the name within a BibTeX environment. As Lars Marius is not an addressable subject per se, we have to use a subject indicator to link the topic with the subject; in this case we decide to use Lars' homepage.

Using one topic per author is then convenient if the author has written several publications. As expected we model this via associations:

(is-author-of)
opus   : ltm-spec
author : p-lars-marius-garshol

(is-author-of)
opus   : definitive-xml-app-development
author : p-lars-marius-garshol

Using associations like this takes care of cases where there is none, or any number of authors for a particular document.

Along these lines we may also code affiliations for the authors

(is-affiliated-with)
person      : p-lars-marius-garshol
affiliation : ontopia

ontopia (company)
bn: Ontopia

Any processor which will be interested in Lars' affiliation will follow the known association is-affiliated-with and will extract the basename of the topic playing the role organisation. For our purposes it is actually irrelevant which class this topic belongs to.

While a clean and orthogonal solution in practical situations such an approach may be heavy-handed and cumbersome. In many cases only one author will be involved, or several, but without any affiliation information. To create dedicated topics which are not likely to be reused will burden the maintainer of the map.

As alternative one might consider a shortcut, albeit not overly elegant solution and to add author information directly as resource data into the document topic:

bn:         LTM, The Linear Topic Map Notation
bn @ latex: {LTM}, The Linear Topic Map Notation
oc (cite-code) @ latex: urn:x-bibtex:lmg01
in (authors) : Lars Marius Garshol
in (authors) @ latex  : Garshol, Lars Marius

While fairly practicable, we ignore this option as it involves complications further down: In any case we will have to allow the one-topic-per-author approach in parallel.

Other meta information

Other meta information like the publication year, the publisher or even library specific codes can also be added using dedicated topics connected via associations.

For publishers this make sense as these topics are likely to be reused:

prentice-hall (company)
bn: Prentice Hall, PTR
oc (homepage): http://www.phptr.com/

(is-published-by)
year      : year-2002
publisher : prentice-hall
document  : definitive-xml-app-development

In some cases we also would want to drop the year, or add the country information, if available:

(is-published-by)
publisher : prentice-hall
document  : definitive-xml-app-development
country   : united-states

Other information may be more specific to the document, so that creating dedicated topics for it triggers the same argument of high overhead applies here as well. An example here would be the ISBN number of a book. This would rather be modeled as an occurrence with a URN in an appropriate namespace.