Ontopia: The Topic Map Company

The Ontopia FAQ

About the Ontopia Topic Map FAQ

Omnigator Questions

How can I get the Omnigator to display class hierarchies?

See How can I build class hierarchies?

How do I name an axis of scope?

In the Filter plug-in, when you're using scope, you can select themes ... but how do you specify the axis as something different than "axis: [unspecified]"?

This is quite easy: If your theme topic is an instance of a class, then the name of that class will replace "[unspecified]".

STP

Basic Topic Map Concepts

What are facets?

Facets are a part of the HyTM syntax in the original ISO 13250 standard. They were added to the standard so that topic maps could contain metadata about information resources. Things you might say with facets are things like: what languages are this document in, who wrote it, when was it published, etc. (Facets are sort of the opposite of occurrences. Instead of saying that a resource is relevant to a topic, you say that a topic is a value for a facet of the resource.)

Below is an example: 

<facet type="publisher">
  <fvalue type="operaweb"
          href="http://www.opera.it/Operaweb/it/manonlescaut/trama.html"/>
</facet>

The HyTM fragment above creates a facet ("publisher"), for which the resource with the given URI has the value "operaweb". In other words, the given resource is published by OperaWeb.

When XTM was created the concept of subject identity was generalized a little, so that you could create topics that represented information resources. That is, you could say "this topic represents that web page", for example, which meant that facets were no longer needed, since you could now say the same things directly using topics.

So you could now create a topic for the resource, create an association to the autor, add the publication date as an occurrence, and add associations to the languages it is available in. The need for facets has therefore gone away, and so it is not recommended that they be used in new topic maps. XTM does not even support facets.

Below is an example that expresses in XTM exactly the same as the HyTM example above. The example uses only topics and associations, which demonstrates that facets really aren't needed in topic maps any more. 

  <topic id="trama">
    <subjectIdentity>
      <resourceRef xlink:href="http://www.opera.it/Operaweb/it/manonlescaut/trama.html"/>
    </subjectIdentity>
  </topic>

  <association>
    <instanceOf>
      <topicRef xlink:href="#published-by"/>
    </instanceOf>
    <member>
      <roleSpec>
        <topicRef xlink:href="#publisher"/>
      </roleSpec>
      <topicRef xlink:href="#operaweb"/>
    </member>

    <member>
      <roleSpec>
        <topicRef xlink:href="#resource"/>
      </roleSpec>
      <topicRef xlink:href="#trama"/>
    </member>
  </association>

LMG

Topic Maps and Content Management Systems

How are topic maps used/integrated within content management systems?

Topic maps provide a uniquely powerful means of organising and relating content independently of the content itself or its location. By providing a topical organisation of documentation, it is possible to break out of the strait-jacket of the folder hierarchy provided by most CM systems and provide a more flexible categorisation system.

The applications of this use of topic maps within a CM system may be either author-oriented or end-user oriented. For content creators and managers, a topical organisation of content may enable different users to organise content in different ways (for example, an author may organise content by urgency, and editor by project and a translator by language). For content users, topic maps provide multiple routes through documentation enabling a user with a particular interest to follow that interest from one piece of information to another.

For both sets of users, a topic map can also serve as a representation of the content in miniature - the fundamental connections between the subjects covered by the documentation can be encoded in a topic map, enabling a person browsing the topic map to get a feel for the subject area(s) of interest, and perhaps pointers into other areas which they may not have found or searched for by issuing queries.

Another interesting point about topic maps is that because they exist separate from the content they describe, it is possible for a topic map to simply correlate two disparate sources of information. This provides an organisation with the ability to connect a procedure manual on an intranet site to a set of forms in a CM system, or a client record in a database to their details in a contact management system, or even to document the relationships between customers. In other words, a topic map need not limit itself to a single system - a well-designed TM system can actually be used as a knowledge repository for information spread out across an organisation.

Integrating a TM system with a CM system will depend on the interfaces of both. If the TM system is developed to be separate from the CM system, then there are issues of addressing into the CM system to retrieve content (many modern CM systems include a web-based interface which may be used for this purpose) and of keeping the topic map up to date as content changes in the content managment system. How the two systems are synchronised depends primarily upon the way in which the topic map is created and used.

If manually authored, either as a published 'guide' to the documentation or as a personal organisation of content for an individual content creator or manager, then it may be left up to the individual or individuals responsible for the topic map to keep it up to date either as part of the editorial process or as part of their normal work processes. However, by extracting information from document metadata and/or content it may also be possible to populate and update the topic map automatically when a document is checked-in to the CM system - Ontopia is currently working on automatic topic map generation technologies which would include elements of metadata analysis and natural language processing techniques to extract topics and associations from the documents themselves.

Finally, it would also be possible for a CM system vendor to use a topic map as a key part of a content management solution - directly integrating the topic map into the infrastructure of the system. A topic map is perfectly suited to keeping standard CM metadata such as content organisation (as already pointed out, this could be far more flexible than the standard folder hierarchy) and user/group organisation, as well as information regarding document status, check-outs held by a user, comments on a document from editorial or review staff, and so on.

One thing to be very aware of in this context is that a topic map is simply a data structure - just because it *can* be represented as an XML file, does not mean that it has to be - or indeed that it is efficient to do so - so while at first glance a CM system capable of storing XML might seem like a good way to manage a topic map, such a solution would not scale beyond the use in a small department scenario.

Kal

How are topic maps different from what I'd normally do for metatagging?

I suppose it depends on what you would normally do for metatagging ! :-)

Seriously, most metadata is resource-oriented and resource-based. In other words the metadata relates directly to an individual document and it is typically stored either within the document or within some record of the document in a content management solution. Relationships between documents are typically not stored in metadata - they are instead inferred from common metadata values assigned to documents (e.g. all documents authored by Joe Author are found by querying the CM system for all documents where the property 'Author' has the value 'Joe Author').

While topic maps are perfectly capable of storing this resource- centric metadata, topic maps really excel at enabling a record of the *connections* between documents to be made; this kind of information is not directly representable as resource-centric metadata.

For example a single document may relate to a number of different subject areas; by creating a topic for each subject, the document can become an occurrence of each of those subjects and under each 'subject topic' you would have a set of documents which are in some way related to that subject area. Furthermore, the nature of the relationship, or the nature of the document itself, can be recorded within the topic map, enabling a topic map user to determine what kind of content they might be going to get by following a particular link without having to have access to the metadata associated with that document.

In a resource-centric system, the other documents connected to the same subject area as this document could only be found with a query (if they could be found at all!). A topic map system, on the other hand, enables those subject areas to be inter-related, pointing users to other areas which may be interesting or which may be more closely related to what they are actually looking for.

Kal

Querying Topic Maps

Where can I get information on querying topic maps?

At the moment topic maps are so new that there is no standard method for querying them. Work has started within ISO to define a standard topic map query language called TMQL, based on a number of existing query languages..

While we are waiting for the TMQL standard, Ontopia has developed its own topic map query language called tolog, which has also been used as input to the TMQL process. See the following question for more information about tolog, and also the section on query languages on our learn more page.

LMG

Is there a way to query on indirect relationships?

You mean, assuming a and b are associated, and b and c are associated, can you get the indirect relationships to a, in this case c?

Yes, Ontopia has developed a query language that does just this, called tolog. This query language was demoed at XML 2000 in Washington, and a paper on it was presented at XML Europe 2001 in Berlin:

tolog - A topic map query lanugage, Lars Marius Garshol

tolog is now implemented as part of the OKS, and included in the Professional and Enterprise Editions. For more information see the tolog language tutorial.

LMG

Modelling Topic Maps

How can I build class hierarchies?

I am interested in the link "Class Hierarchy" in the Omnigator. What do I have to write in the topic map to get such a browsing capability?

You have to create superclass-subclass associations using the XTM PSIs, as follows:

  <!-- superclass/subclass relationship between person and musician -->
  <association>
    <instanceOf>
      <subjectIndicatorRef
        xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#superclass-subclass"/>
    </instanceOf>
    <member>
      <roleSpec>
      <subjectIndicatorRef
        xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#superclass"/>
      </roleSpec>
      <topicRef xlink:href="#person"/>
    </member>
    <member>
      <roleSpec>
      <subjectIndicatorRef
        xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#subclass"/>
      </roleSpec>
      <topicRef xlink:href="#musician"/>
    </member>
  </association>

This example works fine (assuming you have topics with the IDs "person" and "musician"), but it will result in three [no name] topics in the Omnigator unless you include three named topics for the association type (superclass-subclass) and the two association role types (superclass and subclass), respectively. The example below shows how to fix this.

(Note that the association in this case uses <topicRef> instead of <subjectIndicatorRef> - you could use either. Note also that we have given *three* names to the superclass-subclass topic, in three different scopes, in order to get intuitive labelling of theses relationships, no matter which vantage point you regard it from. This technique is described in the Omnigator User Guide.)

  <topic id="superclass-subclass">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#superclass-subclass"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>superclass-subclass</baseNameString>
    </baseName>
    <baseName>
      <scope><topicRef xlink:href="#superclass"/></scope>
      <baseNameString>superclass of</baseNameString>
    </baseName>
    <baseName>
      <scope><topicRef xlink:href="#subclass"/></scope>
      <baseNameString>subclass of</baseNameString>
    </baseName>
  </topic>

  <topic id="superclass">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#superclass"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>superclass</baseNameString>
    </baseName>
  </topic>

  <topic id="subclass">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#subclass"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>subclass</baseNameString>
    </baseName>
  </topic>

  <association>
    <instanceOf>
      <topicRef xlink:href="#superclass-subclass"/>
    </instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#superclass"/></roleSpec>
      <topicRef xlink:href="#person"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#subclass"/></roleSpec>
      <topicRef xlink:href="#musician"/>
    </member>
  </association>

STP

Topic Maps and Ontologies

What's the difference between topic maps and ontologies?

The term "ontology" has been used to mean a large number of different things, from the philosophical study of being to specific kinds of mathematical models, so we can't really answer this question without knowing what the person asking the question meant by "ontology".

Philosophical meaning: in this case, the difference is obviously very big. Topic maps are a technology and a data model, with a certain amount of philosophical underpinning, but by no means a full "ontology" in the philosophical sense.

Computer science meaning #1: in this view, an ontology is a model of the universe in terms of entity types, property types, and relationship types where each type really is expected to exist in the modelled domain. In this sense of the term, topic maps really are ontologies, and there isn't really much of a difference between topic maps and ontologies.

Computer science meaning #2: in this view, an ontology is a model of the kind described above together with a formal logical description of the model. The formal logical description is often rather like a schema (this entity type may have these relationships and properties, it's not allowed to be an instance of both of these entities), but usually focuses on logical inferencing on the data set rather than on constraints. Things not found in schema languages are also often found in this kind of ontology (this relationship is the opposite of this one, this relationship is symmetric, etc).

In this view, topic maps are something one could create an ontology language for, but for which no ontology language exists at present. In other words, published subjects that would let the examples above be expressed could be defined, together with a logical interpretation for these, but no such language has been defined yet. It is possible that TMCL will contain such a language.

Other Questions

Can you suggest any thesis topics related to Topic Maps?

We get this question quite often, so we made a whole page of thesis topic suggestions.