SKOS in Topic Maps

<< 2005-10-24 21:57 >>

I've argued for a long time that the RTM vocabulary for mapping RDF to Topic Maps makes it possible to use RDF vocabularies in Topic Maps. Nobody has really picked this up yet, probably because the presentation in the original paper makes it something of a challenge to see exactly how to do that.

So for a long time (at least a year) I've wanted to write up a mapping from SKOS to Topic Maps in order to show how this might work. A recent article on DITA and SKOS (and the fact that I now have a blog to write this in) finally made me do it, so here goes.

The basic idea is the same as elsewhere in RTM: resources become topics, and their RDF types become their topic types. Other statements about the resources become either names, occurrences, or associations, and the mapping tells us which. The RTM vocabulary gives us a formal way to express this, and one that is supported by the Omnigator, so that given the mapping SKOS data can be loaded in the Omnigator.

An example

An example may serve to make this clearer. The SKOS Core Guide starts out with a nice example from the UK Archival Thesaurus, expressed both in traditional thesaurus form, and in a diagram showing the SKOS expression of it. The SKOS expression, translated to RDF/XML would look like this:

<rdf:RDF xmlns:rdf="" 
    <skos:prefLabel>Economic cooperation</skos:prefLabel>
    <skos:altLabel>Economic co-operation</skos:altLabel>
    <skos:scopeNote>Includes cooperative measures in banking, trade,
    industry etc., between and among countries.</skos:scopeNote>

        <skos:prefLabel>Economic policy</skos:prefLabel>


        <skos:prefLabel>Economic integration</skos:prefLabel>

    <!-- ...more narrower terms omitted ... -->


Declaring the mapping

So what would this become in Topic Maps? With RTM we can answer this very precisely, by mapping each SKOS term to Topic Maps. Let's walk through the example, and do the SKOS terms as we come across them.

The first term we see is skos:Concept, but this just becomes the topic type. (The normal mapping of rdf:type handles this for us.) So we can ignore this one.

Next we find skos:prefLabel, which is quite easy. It's obviously a name for the concept, and by definition the preferred one. This means it should be an unscoped base name on the topic. That's easy to say in RTM:

  <rdf:Description rdf:about="">
    <rtm:maps-to rdf:resource=""/>

The skos:altLabel is similar, being a name, but one that is not preferred. Again this is easy: it becomes a base name, but since it's not preferred it has to be scoped, and skos:altLabel serves as a nice ready-made scope for it. In RTM:

  <rdf:Description rdf:about="">
    <rtm:maps-to rdf:resource=""/>
    <rtm:in-scope rdf:resource=""/>

You may be wondering at this point why we don't use a variant name for the skos:altLabel. The reason is that variant names are assumed to be, well, variants of the base name. That is, there should be some sense in which the variant is another form of the base name. One example might be that the English "Sweden" could be said to be another form of Swedish "Sverige", but the Finnish "Ruotsi" could not. The skos:altLabel may be another form of the same name, but we don't know this, and so we err on the side of caution, and don't assert something we don't know to be true.

The skos:scopeNote becomes an internal occurrence of type skos:scopeNote, which again is trivial to express in RTM:

  <rdf:Description rdf:about="">
    <rtm:maps-to rdf:resource=""/>

The skos:broader statement is also easy: it becomes an association of type skos:broader. The only difficulty is what role types to use, since SKOS doesn't supply any. We could choose to create some, but it doesn't feel quite right to "pollute" the SKOS vocabulary with home-made terms, so instead we use the rtm:subject and rtm:object roles defined as part of RTM. This gives us:

  <rdf:Description rdf:about="">
    <rtm:maps-to rdf:resource=""/>
    <rtm:subject-role rdf:resource=""/>
    <rtm:object-role rdf:resource=""/>

The skos:related statement is slightly more challenging. We could have mapped it the same way, but it is a symmetric property, meaning that if a skos:related b, then b skos:related a. But even this turns out to be easy to handle: we just let the two participants in the association play the same role. This is how symmetric relationships are expressed in Topic Maps. In RTM we can say this quite easily:

  <rdf:Description rdf:about="">
    <rtm:maps-to rdf:resource=""/>
    <rtm:subject-role rdf:resource=""/>
    <rtm:object-role rdf:resource=""/>

This leaves only skos:narrower, which is a little problematic. It's the inverse of the skos:broader property, and it doesn't really make sense to have both association types in Topic Maps if they really mean the same thing. However, once again the solution in RTM is straightforward: we map skos:narrower into skos:broader, but invert the roles. In RTM:

  <rdf:Description rdf:about="">
    <rtm:maps-to rdf:resource=""/>
    <!-- override so 'narrower' becomes an inverted 'broader' association -->
    <rtm:type rdf:resource=""/>
    <rtm:subject-role rdf:resource=""/>
    <rtm:object-role rdf:resource=""/>

That's it! We've now translated the whole example. And not only that: our translation will work for any SKOS data that uses one of these properties.

The resulting topic map

So what would be the result of running the SKOS example through the Omnigator? In LTM syntax the result would look as follows:

#PREFIX skos @""
#PREFIX rtm @""

[coop : skos:Concept = "Economic cooperation"
                     = "Economic co-operation" / skos:altLabel]
{coop, skos:scopeNote, [[Includes cooperative measures in banking,
trade, industry etc., between and among countries.]]}

skos:broader(coop : rtm:subject, policy : rtm:object)
skos:related(coop : rtm:subject, interdependence : rtm:subject)
skos:broader(coop : rtm:object, integration : rtm:subject)

Note how the last skos:broader association has inverted roles.

You can see the result in the Omnigator in the screenshot below.


Well. This actually became quite long. What was it I wanted to say again? Oh, yes. See? You really can use an RDF vocabulary in Topic Maps. And with RTM you can express how, and also convert existing data into Topic Maps.

A complete mapping file for SKOS can be found here. If you want to use it in Omnigator, copy and paste the contents into the webapps/omnigator/WEB-INF/topicmaps/mapping.rdff file already in your Omnigator. (It's best to add it in, since that way you can keep your existing mappings.)

Similar posts

Implementing SPARQL with tolog

I realized quite a while ago (a year ago, maybe) that it's possible to implement SPARQL on top of tolog without too much effort

Read | 2005-12-15 23:03

The web's identity crisis and httpRange-14

URIs are used to refer to both information resources (which are downloadable over the net) and abstract concepts and physical objects (which are not)

Read | 2007-10-08 08:54

A quick introduction to CXTM

I got some questions about how CXTM actually works, so I thought I'd put together a little introduction to it

Read | 2006-08-04 22:27


Markus Ueberall - 2008-08-08 16:56:36

Unfortunately, the link to the mapping file mapping.rdff doesn't seem to work anymore...

Add a comment

Name required
Email optional, not published
URL optional, published
Spam don't check this if you want to be posted
Not spam do check this if you want to be posted