Balisage Paper: Translation between RDF and Topic Maps: Divide and Translate

Terminology

RDF and Topic Maps interoperability: a conceptual viewpoint

As with natural languages, translating RDF constructs into corresponding Topic Maps constructs and structures requires interpretation and may involve some loss or distortion of meaning. The interoperability between RDF and Topic Maps languages has been addressed by various authors[Cian03], [Gars03], [Lach01],[Moore01],[Ogie01], [Ogie01], with a focus primarily of the syntactic and semantic level; less attention has been paid to the pragmatic and practical aspects of the translation. In contrast to the previous works on RDF2TM mapping, vocabulary and structure preservation is not the top priority of our translation. Our basic requirements are guided by pragmatic and semantic considerations.

We distinguish differences between ontology languages from differences between the ontologies themselves. The latter can further be divided into differences among the things that are described and differences in the way things are described. The problems associated with the semantic interoperability between RDF and Topic Maps are mostly due to the differences in their original assumption of how the world is modeled. These differences are passed to the corresponding modeling frameworks, which directly affects the syntax and the descriptive capability of each. It also affects the mapping between the two models. The fact that RDF and Topic Maps differ in representation, structure, and vocabulary leads to a great multiplicity of matching alternatives. In general, an RDF2TM mapping process can not be defined by one-to-one matching relationships between the source and target concepts. Typically it involves one-to-many, many-to-one, and one-to-none relationships. This type of matching ambiguity may turn into semantic inconsistency that is not resolvable without specific domain information. Such inconsistencies occur because the source model: (i) differs in compositional granularity from the target, (ii) has extensible vocabulary along with the target and (iii) contains concepts that are irrelevant according to the target ontological vocabulary.

These observations are critical in the context of RDF — Topic Maps interoperability. We can illustrate the key points in comparison with conventional programming languages. First consider the translation of the FORTRAN loop statements

      DO 10 I = 1, 100
         STATEMENT1
         …..
         STATEMENTn
     10  CONTINUE 

into the following C++ statement.

    for(int i = 1; i < 101; i++)
       {
	  statement1
           …..
           statementn

       }

It is straightforward, because the loop vocabulary (keywords) is predetermined and it does not depend on the intention of the user. The FORTRAN loop statement DO 10 I = 1, 100 doesn’t allow variations, e.g. PERFORM 10 I = 1, 100. Similarly, C++ does not support extensibility with non standard control structures and for loop is defined in the language. Any change in the C++ loop vocabulary for(int i = 1; i < 101; i++) e.g. into trough(int i = 1; i < 101; i++) will violate the syntax rules. This results into one-to-one matching between the two loop statements with fixed semantics.

Now consider a similar task in our original context: translating the following Topic Maps binary association ^[1]:

         based-on(lecture7 : adaptation,  Xpointer : source)

with verbalization: Lecture7 is based on the topic Xpointer, where Lecture7 plays a role of adaptation and Xpointer plays a role of source. Can we translate this association into a single RDF property

         ex:lecture7     ext:based-on      ex:Xpointer

with corresponding verbalization Lecture 7 is based on Xpointer? The answer is not obvious at a syntactic level. Firstly, the naming (vocabulary) in the TM association

         based-on(lecture7:adaptation,  Xpointer : source) 

is left to the user’s choice, as opposed to the first example. For instance, it is possible to assert Topic Map association with different name, e.g.

         derived-from(lecture7:adaptation,  Xpointer : source)

but with an equivalent meaning to the first one. More interestingly, Topic Map associations differ in compositional granularity from the RDF properties. Their expression involves concepts such as association type and role types coupled with role-playing topics. The Role player: Role type constructs of the Topic Maps association do not have a matching counterpart in the RDF properties (i.e. one-to-none matching). In such cases there are three alternatives: to disregard all role players in the translation, to translate them into a predefined RDF construct with a similar meaning or to perform a semantic preserving translation into RDF construct intended to serve as an RDF encoding of the TM role types and role players. Even if we decide to skip the Topic Maps role types translation, we still have to decide how to relate role players to the subject and object of the RDF based-on property. This will transform the directionally neutral Topic Maps association into uni-directional RDF properties. A closer look at Topic Maps association specifications reveals that both role players must be topics (they cannot be strings) while the object of the RDF based-on property can be any resource. For example, in one RDF document the object of the ext:based-on property may refer to a web page describing Xpointer (single resource) while in another RDF document the object of the ext:based-on property may refer to the Xpointer concept with a reference to book chapter divided into sections by relevant RDF properties (structure of resources). Thus significant amount of the information carried by the association

         based-on(lecture7 : adaptation,   Xpointer : source)

will be lost if we choose to translate it directly into the RDF statement

         ex:lecture7     ext:based-on      ex:Xpointer

is In fact such a process will be a transformation of a Topic Maps association into an RDF property, since it is changing the representation as well as the semantics.

One point that was left implicit in the above example is that a complete semantic mapping is not always the best alternative. For example, if the Superclass-Subclass association

         Superclass-Subclass(Person: superclass,
Professor: subclass)

is mapped directly to the RDF(S) subClassOf property:

         ex:Professor   rdfs:subClassOf  ex:Person

where the player of type superclass is mapped to the object and the player of type subclass is mapped to the subject of the subClassOf property, then the role types (viz. superclass and subclass) will be lost. If we choose to ignore such a loss, the compensation will be a direct use of the RDF subClassOf property with predefined semantics that captures the intended meaning of the Topic Maps Superclass-Subclass association. Similar arguments also apply to user defined associations/properties such as based-on. However the Topic Maps and RDF extensibility makes finding a user defined property with equivalent semantics a challenging task.

In contrast, a translation of source content, which includes concepts that do not exist in the target model, may result in a redundant set of data, a set that remains unused by the agents using the target representation. Indeed, we can translate a Topic Maps binary association with role types and role players into RDF by mapping it into a composition of RDF properties that preserve the role concept. Thus, it is possible to define a translation that captures the semantics of a TM association. However, the interpretation of the corresponding RDF composition embodying the role concept is conveyed by an external agreement for RDF. More importantly, semantic consistency does not imply intentional consistency. An agent reading the target may be unable to grasp the role concepts as intended in the source. As a result, the original intention assigned to association roles may be lost despite their faithful translation. To make this example more specific, consider a user-defined Topic Maps association, employment, involving two roles, employer and employee. The two roles can be translated into matching RDF constructs participating in the translated employment association. For example, for each role in the employment association we can include a statement whose property corresponds to the role type (viz. employer and employee); its value is a property with predicate member that references the role player, where referencing is done through an additional (e.g. referencedBy ) property. Obviously, this will increase the complexity of the resulted translation while decreasing its readability. More importantly, despite their presence in the resulting RDF encoding, the constructs corresponding to the employer and employee roles may remain unused because they correspond to concepts defined outside of RDF - the existing RDF applications are designed with no assumptions relating to query, search, display, etc., association roles.

It is even more challenging to pragmatically integrate the TM contextual roles (e.g. when a person playing a role of husband in one context is playing a role of father in another context) in an RDF setting, ensuring their practical utilization. When a topic map user applies a scope to a particular statement, he does that with certain intent. The scope concept with meaning provided by the Topic Maps data model is designated to capture this intention. Since there is no corresponding term (and meaning) in the RDF vocabulary, this intention can not be passed to the target. A possible approach for overcoming such problems is to extend the RDF vocabulary with terms for naming given RDF compositions that correspond to particular Topic Maps concepts (e.g. rdf:scope). However, we believe that we should not target a translation that enforces or assumes that RDF users and applications should “speak Topic Maps”.

Translating in the opposite direction, from RDF to Topic Maps, demonstrates slightly different problems [Gars03]. Consider, for example, a general RDF property, relating two resources identified by their URIs. It can be mapped to either a TM binary association or a TM occurrence. The correct mapping of the RDF property to a Topic Maps format depends on the intended meaning of the property (e.g. employment vs. seeAlso). On the other hand, properties such as rdf:type or rdfs:label allow us to map them unambiguously to Topic Maps expressions. The mapping in this particular case is enabled by the existing rdf:type and rdfs:label semantics in the source language. However, non-standard properties, such as rdf:is-described-by, rdf:plays or, rdf:exists, do not carry predefined semantics and thus can not be mapped based on any logical ground. RDF does not make any assumption about their meaning except that they relate two resources - one playing a role of subject and the other a role of object. In this case a semantic mapping to Topic Maps terms would require a significant human involvement. If the property rdf:is-described-by denotes a relationship with an information resource that is pertinent to and enlightens a given subject, then this property should be translated to a TM occurrence, otherwise it should be translated to a TM binary association. Note that a complete and accurate mapping will require additional decisions to be made about the occurrence type and the role types of the association in each of the corresponding decision steps. In a situation like that, human involvement can not be eliminated because a correct property translation will require an understanding of the context of the property, so its intended meaning and the resources it involves can be captured. These distinctive features of the two models and the differences in the compositional granularity result in a mapping ambiguity and the need of an additional vocabulary, such as RTM [Gars03], [Ontop03], for explicitly defining external meaning and intentions.

Design Requirements

Based on the above observations, we focus on a translation that respects the meaning while maximizing the usability of the translation result. To achieve this we exploit the ontological similarities between the models, which also allow natural integration of the translated expressions into the target formalism. As an additional requirement, we chose not to support guided translation [Gars03], [Pepp06b], [Pepp06c]. Thus, we assume that the source model is not annotated with specific information for the purpose of guiding the translation. This kind of annotation presumes familiarity with both models. It is typically done manually and is a costly exercise. A further assumption is that sharing vocabularies across the two models is not required. Our opinion is that the purpose of any translation is to make translated concepts interpretable in terms of the native vocabulary and to allow users not knowing a foreign vocabulary to utilize it. In fact, the primary role of the translation is to make users independent of a foreign vocabulary. The above assumptions served as a starting point for identifying the key requirements of the translation.

Focused (overlapping) translation

Since the separation between overlapping and non-overlapping concepts is based on syntactic distinctions, the differentiation of their translation does not significantly increase the level of complexity. The following strategy for translating RDF properties into Topic Maps associations can be used as an illustration of this approach.

The RDF type property is converted to Class-Instance association, where the subjects of the property aremapped to the instance members of the association and the objects of the type property are mapped to the corresponding typing topics. The RDF(S) subClassOf property is converted to Superclass-Subclass association, where the subjects of the property are mapped to the subclass association members and the objects of the subClassOf property are mapped to the superclass association members. RDFS label properties are converted to Topic names (baseName). The predefined RDF(S) properties seeAlso are converted to Topic Maps occurrences, where the subject of the property is converted to a topic and the object of the property to the topic occurrence. More specifically, the object of the seeAlso property is converted to an external occurrence of type Information Resource. The remaining RDF properties (describing user defined structures) are subject to generic translation. They are converted into a Topic Maps binary association with two role types: subject and object, mirroring the subject and the object of the corresponding RDF property. The type of the association corresponds to the predicate of the property.

Going in the reverse direction is similar. All TM Class-Instance associations are converted to an RDF type property, where the topic instances are mapped to the subjects and the typing topics of the associations are mapped to the objects of the type property. Superclass-Subclass associations are converted to a subClassOf property, where the players of type superclass are mapped to the objects and the players of type subclass are mapped to the subjects of the subClassOf property.

The remaining binary associations are also subject to focused translation. The association assoc(player1:Role1, player2:Role2) is translated to RDF(S) by creating a property assoc with domain Role1 (Role2) and range Role2 (Role1). Note that the choice of which association role types to map to the domain and which one to the range of the property is arbitrary. The lack of predetermined mapping reflects the fact that, the TM role types play a neutral role in the associations and any decision of how to map them to the domain and range will have equal effect on the translation. For example, one possible translation of the association employment(Christo:employee, WSSU:employer) into an RDF property may result in an RDF property employment with domain employee and range employer. This translation generates the property employment that applies to instances of the class employee and the values of the employment property are instances of the class employer. The other alternative will generate an RDF property employment with domain employer and range employee, which means that the property employment now applies to instances of the class employment and the values of the property are instances of the class employee. Since the Topic Maps associations are directionally neutral, there is no danger of reversing the directionality of the origin. Instead, we are fixing it. As Topic Maps do not assume any directionality, the names of the associations are typically articulated by a direction-neutral terms (e.g. employment). Thus, the selection of the directionality does not affect the readability of the translation result.

Topic Maps external occurrences are converted to a seeAlso property with an object of the occurrence URI. Internal occurrences are also converted to a seeAlso property with an object of the internal resource (string). Finally topic names are converted to an RDFS label property.

Translating between RDF and Topic Maps metadata formats

As stated earlier, the goal of this work is to foster the interchange of resources between RDF and Topic Maps. However, resource semantics is a broad term, which includes ontologies, metadata and instance-data. From the perspective of a librarian, cataloger or publisher, the Semantic Web is a metadata initiative. Therefore, successful interoperation requires an efficient strategy of how the standard categories of metadata relate to each other across RDF and Topic Maps formats. The current web includes ontologies and metadata developed by different communities, such as Dublin Core metadata, FOAF etc. FOAF data currently makes the bulk of the Semantic Web information. Another trend is the rise of data that commits to simple ontologies like SKOS. The proposed approach combining translation of overlapping concepts with generic translation also incorporates methods specializing in specific metadata formats and dialect vocabularies. The inclusion of metadata into “overlapping concepts” is a reflection of the existence of both RDF and Topic Maps standards for encoding the included metadata. The standardization is an important component that integrates them in both languages and makes them overlapping concepts. For example DCMI currently has a Recommendation for expressing Dublin Core in RDF/XML [Beck02], [Nils08] and a new work item was recently approved by ISO for a Type 3 Technical Report on Expressing Dublin Core Metadata Using Topic Maps [Pepp07a], [Pepp07b]. Assuming a two-format representation, the translation turns into a simple mapping between two standard encodings of the same metadata concepts.

Table 2 shows the proposed translation between RDF and Topic Maps representation of Dublin Core Metadata. Based on the recommended encoding of the Simple Dublin Core Metadata Element Set [DCMI06] and following Pepper [Pepp07a], elements contributor, coverage, creator, type, format, language, publisher, relation, source and subject are translated into an association of the corresponding type (see Table 2). The resource to which metadata is being assigned is represented as an association role of type resource, while the other role of the association is of type value. The elements date, description, identifier and rights are represented as occurrences, while the element title is represented as a topic name.

The reverse direction is obvious. Topic Map associations of type contributor, coverage, creator format, language, publisher, relation, source, subject, and type are translated to dc:contributor, dc:coverage, dc:creator, dc:format, dc:language, dc:publisher, dc:relation, dc:source, dc:subject, and dc:type, where the players of type resource are translated to the subject and the player of type value to the object of the corresponding property. The occurrences of type date, description, identifier and rights are translated to properties dc:date, dc:description, dc:identifier and dc:rights. Finally, the topic name is translated to dc:title.

As for RDF dialects, such as FOAF and SKOS, there are no corresponding recommendations from the Topic Maps ISO side. As an illustration of a translation between SKOS and Topic Maps, we present sketchy translations between associations from the TM4L Dialect of Topic Maps and SKOS properties. The association Related(player1:Relation, player2:Relation) is translated to RDFS by creating a symmetric property rdfs:related by defining a symmetric property rdfs:related which entails the inverse relation of subject and object.

Generic Translation

Semantics preserving translation is just one of the criteria guiding our translation strategy. As we mentioned earlier, the translation is intended to facilitate interoperability. The interoperability is measured by the ability of the two models to share common concepts. Concepts that have no match in the other model are among the ones that make the translation task difficult. For such concepts it is possible to provide translation generating semantically equivalent results such that even a user familiar with RDF and Topic Maps will hardly recognize and understand. Therefore, for non overlapping concepts we combine our criteria with pragmatic interoperability. Pragmatic interoperability is used to measure the utilization of the translation result for achieving the agent’s goals. It is in line with the intentional consistency as a measure of the occurrences when the intended meaning of the translation is in agreement with its actual interpretation from agents operating on the source. The proposed generic translation is intended to generate syntactically correct encoding in terms of the target model with minimal intentional inconsistency with respect to the original. All Topic Maps and RDF concepts that do not have corresponding counterparts in the other model (i.e. with no matching target concepts) are subject to generic translation. Strictly speaking, the term “generic translation” refers to a combination of translations and transformations. The semantics of particular source concept may change its meaning when translated into the target model in order to make use of existing concepts with similar meaning instead of introducing new ones. Syntactically correct RDF (Topic Maps) output generated by the proposed approach does not always imply a compete translation. It is possible that part of the input changes both the representation and semantics during the translation.

The Topic Maps N-ary associations are dealt with generic translation. The concept of an n-ary relationship can be represented in multiple ways in RDF. We propose a translation where an association n-assoc(player1:Role1, player2:Role2, .., playern:Rolen) is translated to RDF by creating blank nodes as shown in Figure 1.

N-ary-relation

Figure 1. N-ary Relationship

The other Topic Map concept that is a subject to a generic translation is scope. We translate scope by defining an RDF class Scope. The intention is for all scopes to be defined as a subclass of the class Scope. Thus each scoped item (e.g. name or occurrence) becomes a member of a particular “scope” subclass in addition to its preexisting class memberships. Such scope-based classifications allow additional grouping of the corresponding items based on their scopes.

The variant names are translated into a new RDFS property altLabel defined as a sub-property of the property rdfs:label. The use of the term altLabel was motivated by its inclusion in the SKOS vocabulary.

The non-overlapping concepts from the RDF side include containers and collections. The three types of containers: bag, sequence and alternative are intended for a different type of resource grouping. We transform RDF containers into compositions of the predefined Topic Maps InstanceOf and Whole-Part binary associations. For each container, a topic of type Bag, Seq or Alt is generated. This topic container is also a role payer of type whole. The contained items, called members, are translated as role players of type part and linked by the Whole-Part association to the container topic.

For example, the statement “Group1 consists of the students Elva, James and Paul” with the following RDF representation.

   <rdf:Bag>
      <rdf:li rdf:resource="#Elva"/>
      <rdf:li rdf:resource="#James"/>t;
      <rdf:li rdf:resource="#Paul"/>
   </rdf:Bag>

is translated into the following sequence of Topic Maps assertions

    InstanceOf(Group1:instance, Bag:class)
    Whole-Part(Group1: whole, Elva: part)
    Whole-Part(Group1: whole, James: part)
    Whole-Part(Group1: whole, Paul: part)

The remaining type of containers rdf:Seq or rdf:Alt are translated in a similar fashion. The difference is that the container topic is now of type Seq or Alt instead of Bag. Thus each container is composed from multiple Whole-Part associations applied to the container topic of type Bag/Seq/Alt.

The translation of the RDF built-in structure List is similar with some abuse of the Whole-Part association. To avoid defining new non-standard associations we (inaccurately) treat list members as part of a particular container of type List. Thus RDF list members are represented as parts of a topic of type List .