While topic maps have been around for a while, ontologies have now come of age, and are bound to become the backbone of emerging Semantic Web technologies in the years to come. How can ontologies and topic maps live together? Since the new W3C recommendation, the Web Ontology Language OWL [OWL], is built on top of RDF, one could think that achieving semantic and syntactic interoperability between topic maps and RDF will somehow entail automatically interoperability between topic maps and OWL-RDF ontologies. Actually, many debates and publications in the recent years have raised in Semantic Web and topic map communities about comparison and interoperability of the two technologies, and it has been a recurrent subject in XML conferences.

A good reference is Lars Marius Garshol's 2003 paper [GA03] which sums up in great detail similarities and differences between RDF and topic maps families of standards at the data model level. As the title of Garshol's paper says very well, we have to live now with both technologies around, they are neither equivalent nor really competiting, and they should be widely interoperable. If no standard interoperability framework is yet available, it's more out of process issues than technical ones, the main one being the fact that they have been developped by different standard organizations, namely W3C and ISO. There have been recently interesting steps in the good direction. The new W3C Semantic Web Best Practices and Deployment Working Group, set up in March 2004, has considered among many issues to tackle, integration of topic maps legacy in the Semantic Web big picture. At that point, this issue is not on the top priority of the WG and no formal task force has been dedicated to it so far. But it is on the backburner [SWBP].

Without pre-empting whatever conclusion of this process, this paper addresses a very specific aspect of a possible interoperability framework, the capacity to use OWL to express the ontology layer in a knowledge organization system using topic maps. The purpose is not again mapping RDF and Topic Map data models, but to show :

We'll discover in the process some interesting insights on what data types are or can be, and how they fit in this framework.

Topic maps have been designed to be deliberately 'ontology-agnostic', in the sense that they are intended to be able to represent and manage any kind of subjects and relationships between them, in any kind of ontological context. Better, topic maps would be able to represent any kind of ontological framework.

Although it reflects the unbounded expressivity that is a major quality acknowledged by topic maps users and designers, this very claim has attracted criticism from experts in semantics, formal logic and ontologies, and among the Semantic Web community, sometimes interpreting it as a puff of smoke hiding poor formal foundation ... although this capacity to 'say anything about anything' is also claimed by RDF. But it's true that the formal foundation and conceptual model of topic maps remain a subject of debate - not to say a bone of contention - inside the topic map community itself.

But when one looks closely at any topic map used in a real-world enterprise application, one will find an organization showing all the symptoms of the presence of some underlying, implicit if not explicit, ontology. Classes of topics, association types, role types, occurrence types, seem carefully chosen, and one will find out some sensible and recurrent patterns linking association types to specific role types, occurrence types to topic types, role types in association types to topic classes, implicit rules of cardinality, etc.

So one naturally wonders if those implicit ontologies should not be better off explicited and formalized, and for such a formalization to be used in a Semantic Web context, using OWL should of course be considered.

Indeed, requirements for future TMCL [TMCL] include capacity to express 'ontological constraints' such as those quoted above, and so do existing TM schema languages such as OSL [OSL] and AsTMa! [ASTMA]. Why not use those, then? An obvious point is that none of those languages has achieved so far the status of standard recommendation as OWL has, the standard TMCL being yet in early stages of development, and with a long requirements list. Another point is that TMCL will be dedicated for exclusive use against the Topic Map Data Model, and will be able to control a lot of specific topic map features that are not addressed in this paper. All the point of using OWL is to leverage the considerable work made to develop this language, and the strength of the formal model underlying it. It does not preclude any further fine-grained constraining that TMCL could bring about. Moreover, as we'll see now, we address here the use of topic maps in a specific context of layered knowledge organization systems, where topic maps are integrated at the level where they fit best and have their best potential : the representation of knowledge bases.

A real-world topic map of the kind mentioned above, on which we will focus now, will be considered hereafter as part of a Knowledge Organisation System. We will use this acronym KOS to refer to systems using an explicit representation of 'individual entities' (real-world objects and/or abstract concepts), a formal or implicit organization of those entities through classes and relationships, used to index or classify data, documents, information pieces, attached to the entities in a meaningful way.

Former analysis of use of topic maps in KOS can be found in various chapters of 'XML Topic Maps' book. [PA03]Whether one uses topic maps or not, it is a common and sensible (not to say 'best') practice to structure a KOS in three clearly distinct layers : the ontology layer, the knowledge base layer, and the data layer. The proposed architecture is making the following choice of languages, using each one where it seems to fit the best.

We'll now go in more details, based on an example of a KOS representing a community of practice : people, organizations they work in, domains of expertise and interest, projects they are involved in, technologies used by those projects, indexing relevant on-line information resources documenting all the above. We'll address in this section only the ontology and knowledge base layers.

The ontology layer contains and defines types, or classes, used to organize the two other layers. In a topic map KOS, the ontology layer will contain topic types, association types, role types, and occurrence types. In our example, topic types would be e.g. 'Person', 'Technology', 'Organization', 'Project', association types would be 'Employment', 'Project Team', 'Expertise', role types 'employer', 'employee', 'manager', 'participant', 'expert', and occurrence types 'cv', 'e-mail', 'homePage', 'beginDate' ...

Actually, the topic map standard does not require us to declare topics as types before using them as such, and actually gives no provision for such a declaration. A topic is considered a type (or class) as soon as some other topic, association, role or occurrence, is declared to be an instance of it, through 'instanceOf' declaration. Therefore, by parsing an XTM file and gathering all the 'instanceOf' tags, or by any other way based on implementations conformant to the TM Data Model [TMDM], it's quite easy to gather which topics are used as topic, association, role and occurrence types, and constitute the topic map 'implicit ontology'. This kind of description is for example what Ontopia's Omnigator does, e.g. for the famous opera topic map [OPTM]. But it is difficult this way to capture more subtle ontological features, like patterns of implicit constraints, such as association templates linking association type, role types and classes of role players, that are certainly present implicitly in the intention of the topic map author.

So, it is certainly abusive to claim that the ontology layer of a topic map (or RDF) file could be defined 'a posteriori'. Certainly, resources used as classes can be found and represented in an useful structured way, like the above example shows. But calling such a representation an 'ontology' could be confusing for the casual user, since classes and types have not been explicitly declared or represented anywhere before creation of the file, and neither control nor constrain this creation. To appreciate the difference between 'a posteriori' description and 'a priori' declaration, think about DTD or schemas created on the fly by some XML tools out of any random XML file with no schema declaration, against XML files created and validated against pre-defined, and hopefully well-thought, schemas.

If one now compares the situation in RDF, it's quite the same. Any RDF resource can be considered an implicit class as soon as some other resource uses it as such through an 'rdf:type' property. But RDFS and OWL provide the means for declaring that a resource is a class before populating it with instances, and OWL-DL demands that this declaration be explicit before declaring instances. The same kind of approach can be applied to topic maps, as we will see later on : what OWL brings to RDF, it can also bring to topic maps.

The knowledge base layer contains instances of the types defined in the ontology layer. In a topic maps KOS, they are topics, roles, associations and occurrences, linked to the ontology layer topics by 'instanceOf' relationships. For example 'Bernard Vatant', 'Mondeca', 'ITM' are instances of topics, and 'Employment (employer: Mondeca, employee: Bernard Vatant)' an instance of association. The notation used might be understood in RDF as well as in XTM, with the same semantics, the XTM association being equivalent to two RDF triples 'Employment, employer, Mondeca' and 'Employment, employee, Bernard Vatant'.

A layered KOS requires that the ontology layer and knowledge base layer are totally disjoint, and in particular that classes and instances to be different types of objects (like in OWL-DL). Topic maps, like RDF (or OWL-Full), have no such requirement : the same TM topic, or RDF resource, can be used both as class in the ontology and instance in the knowledge base (or, in TM, as association type and class, or class and role type ...)

In ontologies for topic maps, a sensible additional requirement would be to have distinct topics defining topic types, association types, role types and occurrence types. Those could seem too strong requirements leading to a loose of expressive power of topic maps. It might be, but the same kind of trade-off between expressivity and formal power has led to the distinction between OWL-DL and OWL-Full (or RDF). What we propose hereafter is along the same lines, and in fact will naturally lead to propose to use OWL-DL to declare ontology layers in layered topic maps. The parallel with OWL and RDF should make it clear that we don't propose here that any topic map should be structured that way. Having RDFS and OWL to constrain RDF does not prevent anyone to use RDF "freely" without OWL.

This section describes on an example how to declare in OWL topic types (classes), association types and role types, and constraints linking them. We'll assume the existence of a namespace tm: at http://www.ex.org/, defining the needed generic topic maps classes and properties.

 <owl:Class rdf:about="http://www.example.org/ontology#Organization">
    <rdfs:subClassOf rdf:about="http://www.ex.org/Topic"/>
 </owl:Class>
 <owl:Class rdf:about="http://www.example.org/ontology#AffiliatedPerson>
    <rdfs:subClassOf rdf:about="http://www.ex.org/Topic"/>
 </owl:Class>
     

 <owl:Class rdf:about="http://www.example.org/ontology#Employment">
    <rdfs:subClassOf rdf:about="http://www.ex.org/Association"/>
 </owl:Class>

 <owl:ObjectProperty rdf:about="http://www.example.org/ontology#employer">
    <rdfs:subPropertyOf rdf:about="http://www.ex.org/associationRole"/>
    <rdfs:domain rdf:about="http://www.example.org/ontology#Employment"/>
    <rdfs:range rdf:about="http://www.example.org/ontology#Organization"/>
 </owl:ObjectProperty>
 <owl:ObjectProperty rdf:about="http://www.example.org/ontology#employee">
    <rdfs:subPropertyOf rdf:about="http://www.ex.org/associationRole"/>
    <rdfs:domain rdf:about="http://www.example.org/ontology#Employment"/>
    <rdfs:range rdf:about="http://www.example.org/ontology#AffiliatedPerson"/>
 </owl:ObjectProperty>
    

   <owl:Class rdf:about="http://www.example.org/ontology#PublicEmployment">
    <rdfs:subClassOf>
      <owl:Class rdf:about="http://www.example.org/ontology#Employment"/>
    </rdfs:subClassOf>
    <rdfs:subClassOf>
      <owl:Restriction>
        <owl:onProperty>
          <owl:ObjectProperty rdf:about="http://www.example.org/ontology#employer"/>
        </owl:onProperty>
        <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int">1</owl:cardinality>
      </owl:Restriction>
    </rdfs:subClassOf>
    <rdfs:subClassOf>
      <owl:Restriction>
        <owl:allValuesFrom>
          <owl:Class rdf:about="http://www.example.org/ontology#PublicOrganization"/>
        </owl:allValuesFrom>
        <owl:onProperty>
          <owl:ObjectProperty rdf:about="http://www.example.org/ontology#employer"/>
        </owl:onProperty>
      </owl:Restriction>
    </rdfs:subClassOf>
  </owl:Class> 
 

  <ex:Employment>
    <ex:employee>
      <ex:AffiliatedPerson rdf:about="http://www.example.org/kb#dupont"/>
    </ex:employee>
    <ex:employer>
      <ex:Organization rdf:about="http://www.example.org/kb#my-company"/>
    </ex:employer>
  </ex:Employment>   

<topicMap>
 <topic id="dupont">
   <instanceOf>
     <subjectIndicatorRef xlink:href="http://www.example.org/ontology#AffiliatedPerson"/>
   </instanceOf>
   <subjectIdentity>
     <subjectIndicatorRef xlink:href="http://www.example.org/kb#dupont"/>
   </subjectIdentity>
 </topic>
 <topic id="my-company">
   <instanceOf>
     <subjectIndicator xlink:href="http://www.example.org/ontology#Organization"/>
   </instanceOf>
   <subjectIdentity>
     <subjectIndicatorRef xlink:href="http://www.example.org/kb#my-company"/>
   </subjectIdentity>
 </topic>
 <association>
   <instanceOf>
      <subjectIndicatorRef xlink:href="http://www.example.org/ontology#Employment"/>
   </instanceOf>
   <member>
      <roleSpec>
         <subjectIndicatorRef xlink:href="http://www.example.org/ontology#employer"/>
      </roleSpec>
      <topicRef xlink:href="#my-company"/>
   </member>
   <member>
      <roleSpec>
         <subjectIndicatorRef xlink:href="http://www.example.org/ontology#employee"/>
      </roleSpec>
      <topicRef xlink:href="#dupont"/>
   </member>
 </association>
</topicMap>

Let's take an example again. We've mentioned above 'CV' as an usual piece of information attached to a person. In topic maps, one will use an occurrence to attach to a 'Person' topic a link to an external resource, hopefully yielding actually some kind of CV document for the Person. Let's take again the topic '#dupont' defined above, and let's add such a 'cv' occurrence.

 <topic id="dupont">
   <instanceOf>
     <subjectIndicatorRef xlink:href="http://www.example.org/ontology#AffiliatedPerson"/>
   </instanceOf>
   <subjectIdentity>
     <subjectIndicatorRef xlink:href="http://www.example.org/kb#dupont"/>
   </subjectIdentity>
   <occurrence>
    <instanceOf>
      <topicRef xlink:href="http://www.example.org/ontology#cv"/>
    </instanceOf>
    <resourceRef xlink:href="http://www.example.org/dupont/cv.xml"/>
   </occurrence>
 </topic>

To cope with those difficulties, the mechanism proposed here is to defer the declaration details of CV data types (the physical data type) to existing external schema that applications integrated with the KOS can make sense of, by re-using available schemas in a modular way. Neither RDF nor topic maps make actual provision for that kind of mechanism, but workarounds can be found that make it possible to express it using the two languages. It goes through reification of complex data, that allows to explicitly make distinct the logical and physical data types, and as necessary bind the former to the latter.

In the CV example, the mechanism is to create a 'CurriculumVitae' subclass of some generic 'ComplexData' class, having the generic ObjectProperty 'schemaRef'. We assume again that those generic Class and ObjectProperty are defined in the tm: namespace, with non-ambiguous semantics. In the example, the schemaRef resource is a DTD, actually defining about 50 common fields of a CV. The ObjectProperty 'cv' defined on domain 'Person' and range 'CurriculumVitae', is declared as subproperty of tm:occurrence, and will be used as an occurrence type in XTM files referring to this ontology.

  <owl:Class rdf:about="http://www.example.org/ontology#CurriculumVitae">
    <rdfs:subClassOf rdf:resource="http://www.ex.org/ComplexData"/>
    <rdfs:subClassOf>
      <owl:Restriction>
        <owl:onProperty>
          <owl:DatatypeProperty rdf:about="http://www.ex.org/schemaRef"/>
        </owl:onProperty>
        <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI">
        http://www.xml.org/xml/schema/f0eee0ed/CVML-1_0.dtd.xml
        </owl:hasValue>
      </owl:Restriction>
    </rdfs:subClassOf>
  </owl:Class>
  <owl:ObjectProperty rdf:about="http://www.example.org/ontology#cv">
    <rdfs:subPropertyOf rdf:about="http://www.ex.org/occurrence"/>
    <rdfs:range rdf:about="http://www.example.org/ontology#CurriculumVitae"/>
    <rdfs:domain rdf:about="http://www.example.org/ontology#AffiliatedPerson"/>
  </owl:ObjectProperty>

Validation of topic 'dupont' and its 'cv' occurrence of the previous example is now a two-step process.

In an integrated environment, this validation process can actually be made by two different applications. The ontology-driven topic map engine could make the logical step, and any XML application the physical validation and subsequent relevant processing such as publication, transformation, knowledge extraction ...

The notion of physical type can of course be understood in a very broad sense. It goes from the ideal case mentioned above, of an XML schema or DTD, to a human-readable standard form of administrative document, through a format of image in terms of file extension, dimensions in pixels, rights of diffusion.

Such a mechanism makes the whole KOS more modular and therefore improves usability from the OWL-RDF viewpoint, by making the actual data schema an external resource, that can be managed and modified without any impact on the ontology itself. The other way round, switching to another schema, or adding another allowed schema is made as simple as possible. Moreover, it would be much more easy to re-use the ontology in another enterprise, simply changing the schema(s) of CV allowed to fit the local practices.

Last but not least, this approach make it easier to leverage the legacy of existing data schemas, without the overhead of re-writing and maintaining their content inside an OWL file. In an integrated environments, dedicated applications know what to do with specific complex data already well organized. There is no point to mess up this with the ontology and knowledge base.