A topic map describes subjects, their names, their relationships, and the resources associated with them. It is useful for understanding how a knowledge collection connects ideas across documents. Begin with the subjects and the questions readers ask, then inspect the XML interchange representation.
Model meaning before writing XML
| Construct | Example | Purpose |
|---|---|---|
| Topic | Ada; Field Guide | Represents a subject being discussed. |
| Association and roles | Ada is Author; Field Guide is Work in Authorship | Expresses the relationship and each participant’s part. |
| Occurrence | A catalog-entry resource for Field Guide | Connects the subject to information about it. |
| Subject identifier | https://example.org/subjects/ada | Provides a shared identity reference beyond a display name. |
Names are useful labels, but two people can share a name. A topic map needs identity rules that say when records describe the same subject. The Topic Maps Data Model describes topics, associations, occurrences, scope, and merging.
Scope qualifies the context in which a name, occurrence, or association applies. For example, terminology may vary between an organization's departments. Record that context explicitly instead of forcing every audience to use one label.
Inspect the XTM 2.0 example
The XML labs pack includes topics.xtm. It defines Ada, Field Guide, and the types used by an Authorship association. The Field Guide topic also points to a fictional catalog resource. A shortened topic looks like this:
<topic id="ada">
<subjectIdentifier href="https://example.org/subjects/ada"/>
<name><value>Ada</value></name>
</topic>Inside the complete document, topicMap declares version="2.0" and the default namespace http://www.topicmaps.org/xtm/. This fragment inherits that namespace. The id is a document-local identifier; the subject identifier is the intended shared reference for Ada. The example.org addresses are fictional, and no network retrieval is required to read the model.
Find the association, then follow each topicRef. The association has type Authorship; one role has type Author and player Ada, and the other has type Work and player Field Guide. A role identifies how a topic participates, which is more precise than an untyped line between two nodes.
Understand what merging would mean
Imagine importing a second map that calls the same person “Ada L.” and uses the same subject identifier. Subject identity gives a processor grounds to merge those topic representations and combine their characteristics. A second person called “Ada” with a different subject identity should remain distinguishable.
Review the identifier policy before importing data. A copied but incorrect identifier can merge unrelated subjects and contaminate many relationships. Conversely, different identifiers for the same subject may need an explicit reconciliation decision. Keep provenance so that a disputed merge can be traced back to its inputs.
The bundled file passes the published supplementary XTM 2.0 XML Schema. That checks syntax. Full conformance also requires interpreting references, identities, and merge rules; this example does not claim to implement a complete topic-map engine.
Keep versions and formats distinct
The XTM 2.0 syntax specification documents differences from XTM 1.0. Version 1.0 material uses a different namespace and constructs such as baseName. Inspect the root, namespace, and processor support before reusing examples from older books.
XML Topic Maps: Creating and Using Topic Maps for the Web belongs to the early XTM literature. Its conceptual discussions can help explain knowledge organization; verify the syntax and software assumptions against the implementation you use.
Topic maps, RDF, and ordinary XML document trees represent information through different models. A conversion should specify which identities, association roles, scopes, and provenance survive. Start with a tiny case and compare the interpreted model after export and import. Successful XML parsing alone cannot establish that the knowledge relationships survived.