Sunday, 21 November 2010
Topic maps provide us with two different and important views into an information space:
- a resource-centric view, one in which we use metadata to describe the resources we reference with topics
- a subject-centric view, in which topic maps provide the tools necessary to represent, to “talk about” subjects.
These views, when coupled with the “topic map attitude” that topic maps, where possible, should be unified through merging, provide us with the opportunity for global knowledge interchange.
If you want to start creating your own topic maps it is recommended to download the Omnigator (Download) and write an XTM or LTM file. Then, the topic map can be browsed in the Omnigator immediately, without any programming or stylesheets.
- Making a topic map
Create a topic map about XML, where it can be founded topics representing 'the XML Recommendation', 'the W3C', and 'Tim Bray'.
The types of the topics should be 'standard', 'standards body', and 'person'.
The relationship between the XML Recommendation and the W3C is called 'publishing', while the relationship between the Recommendation and Tim Bray is one of 'authorship'. So in the 'authorship' association Tim Bray plays the role of 'author' while the XML Recommendation plays the role of 'work'.
For "Tim Bray", occurrences should be his home page.
To create a topic map for the example above we can start by defining topics for the three topic types. This is done as follows:
This gives us three topics suitable for use as topic types in our topic map. The baseName elements give the topics names that can be used to display the topics. The next step is to add one topic to be used as an occurrence type and our three instance topics, complete with names and occurrences. (The fragment below should be inserted inside the topicMap element above. The order of topic elements in topic maps is irrelevant.)
<baseNameString>The XML Recommendation</baseNameString>
<baseNameString>World Wide Web Consortium</baseNameString>
The first two topic elements create topics for the XML Recommendation and Tim Bray, making them instances of the "standard" and "person" topic types we defined earlier. Notice how instanceOf is used to provide the class and topicRef is used to point to the topic that defines the class. Then we define the occurrence type "homepage" and finally a topic for the W3C, which is of type "standards-body" and even has a "homepage" occurrence. The resourceRef element inside the occurrence gives the URI of the resource that is the occurrence.
Finally, we are ready to create topics for the association and role types and create the corresponding associations in order to complete the topic map. The fragment below does just this.
How to Use Topic MapsFor creating a topic map there are three main approaches
- Have humans author the topic maps manually. This usually gives very high-quality and rich topic maps, but at the cost of human labor. This is appropriate for some projects, while prohibitively expensive for others.
- Automatically generate the topic map from existing source data. This can give very good results if the existing data are well-structured (sound familiar?); if not, there are various natural-language processing tools that might help.
- Automatically produce the topic map from structured source data like XML, RDBMSs, LDAP servers, and more specialized applications.
The following is a complete list of element types in the order in which they are documented:
<topicRef>: Reference to a Topic element
<subjectIndicatorRef>: Reference to a Subject Indicator
<scope>: Reference to Topic(s) that comprise the Scope
<instanceOf>: Points to a Topic representing a class
<topicMap>: Topic Map document element
<topic>: Topic element
<subjectIdentity>: Subject reified by Topic
<baseName>: Base Name of a Topic
<baseNameString>: Base Name String container
<variant>: Alternate forms of Base Name
<variantName>: Container for Variant Name
<parameters>: Processing context for Variant
<association>: Topic Association
<member>: Member in Topic Association
<roleSpec>: Points to a Topic serving as an Association Role
<occurrence>: Resources regarded as an Occurrence
<resourceRef>: Reference to a Resource
<resourceData>: Container for Resource data
<mergeMap>: Merge with another Topic Map
The <scope> element
- Define a scope consisting of the subject “English” using a published subject:
- Define a scope consisting of the topics “tragedy” and “theatre” in the current document:
It specifies the name and occurrence characteristics of a single topic. It has a single unique identifier, and the ability to state the class(es) of which it is an instance and the identity of the subject that it reifies.
Every topic is intended to be organized around exactly one subject, even if that subject is only implicitly defined.
A topic map document may contain multiple topic elements that reify the same subject.
The class(es) of which the topic is an instance are indicated via the <instanceOf> child element(s).
Names are declared by means of <baseName> child elements.
( instanceOf*, subjectIdentity?, ( baseName | occurrence )* )
- <instanceOf> Each optional and repeatable <instanceOf> child element specifies a class of which this topic is an instance.
- <subjectIdentity> The optional <subjectIdentity> child element specifies the subject identity of this topic.
- <baseName> Each optional and repeatable <baseName> child element specifies a name characteristic of this topic.
- <occurrence> Each optional and repeatable <occurrence> child element specifies information resources that are relevant to this topic.
It specifies a topic name. A topic name is represented by one string: the content of the <baseNameString> child of <baseName>. Natural language discrimination between base names may be specified by a child <scope> element.
<!ELEMENT baseName ( scope?, baseNameString, variant* ) >
- <scope> The optional <scope> child element specifies the context in which this base name is valid.
- <baseNameString> The single mandatory <baseNameString> child element provides the string that is the base name of the topic.
- <variant> The optional and repeatable <variant> child element provides alternate forms of the base nam
Topic with multiple names in different languages, differentiated by scope
(assumes the existence of topics with the IDs “en” and “da” that reify the subjects
“English” and “Danish” respectively):
<!-- baseName for English -->
<!-- baseName for Danish -->
It is the parent of all <topic>, <association and <mergeMap> elements in the topic map document.
The <topicMap> element is the root element from which topic map syntactical recognition is performed.
( topic | association | mergeMap )*
- <topic> Each optional and repeatable <topic> child element reifies a single subject.
- <association> Each optional and repeatable <association> child element specifies a relationship among topics.
- <mergeMap> Each optional and repeatable <mergeMap> child element causes its parent topic map to be merged with another topic map.
It specifies the class to which its parent belongs, via a <topicRef> or <subjectIndicatorRef> child element.
<!ELEMENT instanceOf ( topicRef | subjectIndicatorRef ) >
- <topicRef> The <topicRef> child element references a <topic> element that reifies a class of subject.
- <subjectIndicatorRef> The <subjectIndicatorRef> child element references a resource that indicates the identity of a class of subject.
Declare that the topic with the ID “hamlet” is an instance of the topic type whose ID is “play”:
Saturday, 20 November 2010
For programmers, many software libraries, called Topic Maps engines are available to use, some of which are part of complete knowledge management solutions.
Students and academics will find the Topic Maps Library useful. It includes many publications, a glossary, information about standards and more.
Many companies offer commercial services and/or consulting around Topic Maps products. The list of sponsors of TMRA is a good place to look for them. The Topic Maps Projects list gives some starting points, too.
The Standards are available through ISO. The latest versions can also be obtained at isotopicmaps.org. The most prominent standard is the Topic Maps Data Model which uses XTM 2 and CTM as serializations.
The purpose of a topic map is to convey knowledge about resources through a superimposed layer, or map, of the resources. A topic map captures the subjects of which resources speak, and the relationships between subjects, in a way that is implementation-independent.
A topic is a resource that acts as a proxy for some subject; it is the topic map system's representation of that subject.
The key concepts in topic maps are topics, associations, and occurrences.
An association is a relationship between one or more topics, each of which plays a role as a member of that association. The roles a topic plays in associations are among the characteristics that can be assigned to it and are therefore governed by scope. Each individual association is an instance of a single class of association (also known as an association type) that may or may not be indicated explicitly.
Topics can have names. They can also have occurrences, that is, information resources that are considered to be relevant in some way to their subject.
Topics can participate in relationships, called associations, in which they play roles as members.
- Community Standards
Besides the ISO standards, there are some community standards.
- Programming APIs:
- Java: TMAPI
- PHP: PHPTMAPI
- .NET: TMAPI.NET
- Serialization Formats
- JSON Topic Maps
- Linear Topic Maps Notation (superseeded by CTM)
- Modeling conventions
- Normalizing Association cardinality: Many binary Associations are easier to handle than one big association with many roles.
- Directed association names: Directed Names for (bidirectional) associations should be defined as names for the association type topic and scoped with the role type topic of the source role.
- shall be straight forwardly usable over the Internet.
- shall support a wide variety of applications.
- shall be compatible with XML, XLink, and ISO 13250.
- It shall be easy to write programs that process XTM documents.
- The number of optional features is to be kept to the absolute minimum, ideally zero.
- The documents should be human-legible and reasonably clear.
- The design should be prepared quickly.
- The design shall be formal and concise.
- The documents shall be easy to create.
- Terseness markup is of minimal importance.