This is a binding guide for representing IMS Learning Resource Meta-data v1.2 in RDF. For each element in the IMS Meta-data Information Model v1.2 this Appendix provides the preferred representation in RDF, with examples. This appendix is a working draft that is subject to change, and should not be considered final. There are sample RDF instances that use the constructs described below, as well as other documents containing the language definitions, the local vocabulary and taxonomy, and the set of RDF schemas, available for download on the IMS Meta-data website: http://www.imsproject.org/metadata.
The information presented here is not completely self-contained, but rather depends on understanding several separate specifications. In particular, this RDF binding depends on:
The IMS Meta-data Information Model v1.2 (which is essentially equivalent with IEEE LOM Draft 6.1).
The IMS Meta-data 1.2 Dublin Core mapping found as an Appendix to the IMS Meta-data Information Model.
The RDF and RDF Schema Specifications from the W3C. This document does not contain tutorials on RDF or RDF Schema, but heavily relies on them (http://www.w3c.org/RDF/).
The Dublin Core element set 1.1 (http://dublincore.org/documents/1999/07/02/dces/).
The recent Dublin Core Qualifers in RDF draft, found at (http://www.mathematik.uni-osnabrueck.de/projects/dcqual/qual21.3.1/). Note that this document is also a work in progress and is not final.
Each of these should be regarded as a prerequisite for using and implementing this binding.
It is important to realize that an RDF binding can be done in a number of fundamentally different ways. This has to do with the semantic richness of RDF. In addition, in a pure XML approach such as the IMS Meta-data XML Binding of LOM, the structure of the XML instance is the result of choosing the most convenient syntax, creating the element hierarchy that best matches the structure of the data.
By contrast, in RDF the precise data model is not simply syntactic, but has semantic consequences. RDF is a highly object-oriented approach where objects have properties that relate them to other objects. The type of an object or property defines its interpretation, and is thus not simply a syntactic placeholder. In addition, while in the pure XML version of the IMS Binding, each structure is represented by an element. In RDF there are several different possibilities, where you can use properties, resources, or even namespaces to get the structure you want. And the choice matters, as those constructs have fundamentally different semantics.
Thus, a considerable amount of effort is needed to extract the desired semantic quality of each element in order to be able to represent it appropriately. If this reinterpretation is not done, you risk losing not only clarity for the human consumer, but you risk more serious damage to the usefulness of the model. Much of the effort that has gone into this binding has focused on creating such a well-formed semantics of the model.
Creating an RDF binding is very different from creating an IMS Meta-data XML binding, so formulating a more precise design criteria is necessary.
As a consequence of the nature of RDF, we cannot expect the RDF binding to fulfill the same purpose as the XML binding. The XML Binding defines an exchange format for meta-data. The meta-data might be contained in a database and an XML representation generated on demand, for export to other tools and environments. Thus, an XML meta-data record is a self-contained entity with a well-defined structure.
In contrast, an RDF representation is more often than not the definite representation of the meta-data. In addition, the meta-data is not all self-contained, but rather part of a global network of information, where anyone has the capability of adding meta-data to any resource. It is also not the case that meta-data for one resource need be contained in a single RDF document. Translations might be administrated separately, and different categories of meta-data might be separated. This dramatically strengthens the incentive both to reuse identical structures that are used repeatedly, as well as to create decentralized descriptions of resources. Both of these phenomena naturally lead to a fundamentally different approach to meta-data modelling than that found in the XML binding.
Thus, we expect to see much richer structures on many levels in an RDF representation than in the corresponding XML binding instance. In this perspective, we should expect to find that meta-data expressed in RDF using this binding probably can be exported to XML format without many problems; however, an XML meta-data record cannot be effortlessly translated to RDF.
Another aspect is that of compatibility. In XML, there is seldom a natural way to reuse other meta-data standards. By contrast, RDF is designed in a way that leads to naturally reuseable constructs. So, as can be seen in more detail below, this binding is directly compatible with Dublin Core and with vCard. However, this compatibly comes at the price of modeling freedom - some modeling restrictions are imposed on us. Fortunately, much of this compatibility comes for free when taking the approach that the data should be modeled to maximally exploit the expressivity of RDF.
Finally, as RDF is intended to be processed by software, and in many cases software with no explicit knowledge of LOM, it is important to use explicit data typing. This will be seen below in the representation of languages and dates. We have tried to avoid using string literals with only implicit typing. Thus, the purpose of this binding is to define a set of RDF constructs that facilitates introduction of LOM meta-data into the semantic web in the most convenient way.
The RDF representation given here relies heavily on the Dublin Core meta-data element set, and its representation in RDF. We try to model IMS elements similarly to how the Dublin Core qualifiers are represented. The Dublin Core RDF usage model is taken from the latest DC-Architecture RDF draft. Understanding that work is helpful when trying to understand what is being described in this document.
This appendix is aligned with the efforts to improve interoperability between Dublin Core and LOM. The RDF representation presented here is almost fully Dublin Core RDF compatible, in the sense that meta-data constructed according to this guide can be directly understood by Dublin Core-aware software. All the elements of the LOM Dublin Core mapping (in Appendix B of LOM WD 6.1) are compatibly represented, thus allowing the use of all the Dublin Core constructs in a compatible way. It is, however, at this time not possible to map any Dublin Core construct (made without reference to this guide) to a LOM element without some effort, as the LOM requires a more detailed structure in many elements. In short, this guide describes some restrictions to Dublin Core meta-data that are needed to be LOM compatible. The guiding principle has been that using the "dumb-down" algorithm described in Dublin Core Qualifiers draft (http://www.mathematik.uni-osnabrueck.de/projects/dcqual/qual21.3.1/) should result in correct Dublin Core meta-data.
Please note that the Dublin Core Qualifiers work referred to above has not yet reached its final version, so some constructs described here might change.
The Dublin Core compatibility is reached at the cost of full IMS XML binding compatibility, which is doomed to be lost anyway when using RDF. Close attention has been paid to LOM, and no structure representable in LOM should be problematic to represent in the RDF binding. But there are some differences from the IMS XML binding in structure, naming, and representation.
This binding also makes use of the vCard RDF binding by the W3C (http://www.w3.org/TR/vcard-rdf).
Five external namespaces are used below.
rdf: which is the RDF namespace "http://www.w3.org/1999/02/22-rdf-syntax-ns#".
rdfs: which is the RDF Schema namespace "http://www.w3.org/2000/01/rdf-schema#".
dc: which is the Dublin Core Element Set namespace "http://purl.org/dc/elements/1.1/".
dcq: which is the Dublin Core Qualifiers namespace "http://dublincore.org/2000/03/13/dcq#".
vCard: which is the VCard namespace, "http://www.w3.org/2001/vcard-rdf/3.0#".
In addition, this binding is separated into a number of namespaces. Each LOM category has its own namespace, and in addition there is a root namespace containing common constructs. The following abbreviations are used:
lom: which is the IMS base meta-data namespace "http://www.imsproject.org/rdf/imsmd_rootv1p2#".
lom_gen: which is the IMS general meta-data namespace "http://www.imsproject.org/rdf/imsmd_generalv1p2#".
lom_life: which is the IMS life cycle meta-data namespace "http://www.imsproject.org/rdf/imsmd_lifecyclev1p2#".
lom_meta: which is the IMS meta-meta-data namespace "http://www.imsproject.org/rdf/imsmd_metametadatav1p2#".
lom_tech: which is the IMS technical meta-data namespace "http://www.imsproject.org/rdf/imsmd_technicalv1p2#".
lom_edu: which is the IMS educational meta-data namespace "http://www.imsproject.org/rdf/imsmd_educationalv1p2#".
lom_rights: which is the IMS rights meta-data namespace "http://www.imsproject.org/rdf/imsmd_rightsv1p2#".
lom_rel: which is the IMS relation meta-data namespace "http://www.imsproject.org/rdf/imsmd_relationv1p2#".
lom_ann: which is the IMS annotation meta-data namespace "http://www.imsproject.org/rdf/imsmd_annotationv1p2#".
lom_cls: which is the IMS classification meta-data namespace "http://www.imsproject.org/rdf/imsmd_classificationv1p2#".
In addition, the namespace myVoc is used when referring to any resource that can be defined by users and implementers. It uses the URI "http://www.myVocabulary.com/someVocab#".
In this binding, we make heavy use of the rdf:value construct. This construct is a standard way to add qualifying information to RDF statements. Its use is compatible with Dublin Core Qualifiers draft, where it is also described in some detail. In short, this construct is used when a value of a property needs additional information. The property can then be pointed to a new resource, having an rdf:value property pointing to the original value, and any number of new properties qualifying this value. Thus, the string value of the dc:title property in this example:
<dc:title>Sniffy the virtual rat</dc:title>
This can be qualified with a language in this way (see next section for details on language qualifiers):
<dc:title rdf:parseType="Resource">
<rdf:value>Sniffy the virtual rat</rdf:value>
<dc:language rdf:resource="#en"/>
</dc:title>
The title would be found to be the same in both cases, but in the second case, the language (English) of the string would also be known.
Dublin Core Qualifiers draft specifies a "dumb-down" algorithm that essentially removes all qualifying properties, leaving only the final string value. This binding has been designed with this algorithm in mind. This way, software can produce unqualified Dublin Core meta-data from LOM RDF meta-data in a straightforward and stnadardized way, by using the "dumb-down" algorithm.
In the absence of qualifying properties, it is legal to collapse the construct completely as in the following example (see next section for explanation on LangString):
<dc:title>
<lom:LangString rdf:ID="title">
<rdf:value rdf:parseType="Resource">
<rdf:value>Sniffy the virtual rat</rdf:value>
</rdf:value>
</lom:LangString>
</dc:title>
<dc:title>Sniffy the virtual rat</dc:title>
This form of collapse is completely legal, and applications should support it for any element where it may occur. However, collapsing in this way is not always desirable. In the above case, collapsing the statement necessitates a restructuring when a translation of the title is to be made. So in many cases, keeping the full construct is the safest way to go, as it simplifies extensions.
Similarly, collapsing an rdf:Bag or other container in the case of only one element is allowed, but not always a good idea, as this may prevent adding additional resources from the outside. In short, care must be taken when using shortcuts such as these. However, they are syntactically and semantically legal constructs and thus must be supported.
When encoding a string in a specific language, we do not use the xml:lang attribute (this is discussed in the W3C document located at http://www.w3.org/DesignIssues/InterpretationProperties.html). Instead, we follow the guidelines in Dublin Core Qualifiers draft (esp. section 4), using an explicit dc:language qualifier. An example of a language-tagged string follows:
<dc:title>
<rdf:value>Sniffy the virtual rat</rdf:value>
<dc:language rdf:resource="#en"/>
</dc:title>
Here "#en" is a separate language resource. This should be an instance of dcq:RCF1766, for example:
<dcq:RCF1766 rdf:ID="en">
<rdf:value>en</rdf:value>
<rdf:label>English</rdf:label>
<rdf:isDefinedBy rdf:resource="http://www.ietf.org/rfc/rcf1766.txt"/>
</rdf:Description>
It is recommended to put definitions of languages in a separate RDF document, so that they can be reused.
When encoding strings in several languages, always use the following construct (for a more formal description on LangString, see the section of the same title):
<dc:title>
<lom:LangString rdf:ID="title">
<rdf:value rdf:parseType="Resource">
<rdf:value>Sniffy the virtual rat</rdf:value>
<dc:language rdf:resource="#en"/>
</rdf:value>
<lom:translation rdf:parseType="Resource">
<rdf:value>Sniffy le rat virtuel</rdf:value>
<dc:language rdf:resource="#fr"/>
</lom:translation>
</lom:LangString>
</dc:title>
This technique allows us to separate the original title from translations. It also allows Dublin Core-only RDF parsers to understand what the title is, via the "dumb-down" algorithm described in the previous section. Finally, it allows us to add translations in separate RDF documents. A necessary prerequisite for this is that all LangString instances are given an explicit ID as in the example above. For this reason, giving such an ID to each LangString is strongly recommended, even if it is generated automatically by the editing software.
It should be noted that, though allowed, the use of rdfs:label and rdfs:comment is discouraged. The reason is that there is no good way to add language qualifiers, as they point to string literals. Use dc:title and dc:description instead.
In the IMS XML binding, lists are constructed using repetitions of the containing element. In RDF, there are four different possibilities, and all of them can be used when they express the desired semantics. The four ways are: repeated properties, rdf:Bag, rdf:Alt, and rdf:Seq. We provide guidelines below on which to choose to be maximally LOM compatible. Implementers are free to use any of these constructs if they feel that it better represents the semantics of their meta-data; however, keep in mind that such information might get lost when translating to the XML binding.
In some cases Dublin Core has pre-defined classes for use as types of the values. Use of this construct is strongly encouraged, and the classes available for use are given in the table below. In some cases, there is a corresponding qualifier in LOM. For example, the class http://dublincore.org/2000/03/13/dcq#W3CDTF is used to represent dates and times in ISO8601 format, which is used in LOM. We strongly favor this kind of explicit datatyping using RDF classes (see the dc:language example above).
Vocabularies are represented in several different ways in this binding. The fundamental idea is that the (source, value) construct in LOM is best represented in RDF using the (namespace, value) construct that is naturally contained in a resource URI in RDF. Thus, vocabulary values are resources, and the source of a vocabulary is implicit in the URI of a resource.
This binding will provide resources for the restricted vocabularies defined in LOM. These resources can be used directly as values of the corresponding property, for example:
<lom_life:status rdf:resource="http://www.imsproject.org/rdf/imsmd_lifecyclev1p2#Draft"/>
Additionally, implementers are free to define their own RDF resources for use as values in vocabularies, for example:
<lom_life:status rdf:resource="http://www.myVocabulary.com/someVocab#FinalBeta"/>
The resource pointed to will most probably be an RDF resource that is part of an RDF Schema defining the vocabulary. Thus, vocabularies will need to be explicitly translated to RDF. This convention leads to some difficulties when interfacing with the XML binding. Further development in this area is necessary.
Note: In several cases, the vocabulary resource is not an RDFS Class, but rather a Property. This is the case with element 7.1. Relation.Kind, for example:
<dcq:hasPart rdf:resource="http://www.someContentProvider.com/someContent.html"/>
Here the relation is of kind "hasPart". Defining new vocabularies here is as simple as for the above case. The only difference is that, in the example, one would need to define a subPropertyOf dc:relation. This new property is again an RDF resource, and thus the same remarks are valid: explicit translation to RDF is necessary, and care must be taken when interfacing with the XML binding.
A definition of a private (not necessarily useful) vocabulary for Relation.Kind could look like:
<rdf:Property rdf:ID="hasPrerequisite">
<rdfs:subPropertyOf rdf:resource="http://purl.org/dc/elements/1.1/relation"/>
<dc:title>Has prerequisite</dc:title>
<dc:description>This property point to a resource that is a necessary
prerequisite for the learning object.</dc:description>
</rdf:Property>
This would then be used (with the appropriate namespace definition in place) as:
<myVoc:hasPrerequisite rdf:resource="http://www.someContentProvider.com/someContent.html"/>
Generally, the metameta-data category is obsoleted in RDF. There is no real way in which one can talk about "meta-data instances", as the information is connected globally in a semantic web. Thus, the elements in this category must be represented in other ways. Two ways are provided by RDF, and both rely on reusing the normal (non-metameta-data) meta-data properties. But they are not applied to the learning resource, but to either of the following:
Both of these are perfectly valid approaches. Some additional guidance on the representation of LOM metameta-data elements is given in the table below. All of them should apply not to the learning resource being described, but to one of the above resources.
This is the most complex category of all. We have decided to represent taxonomies separately from each meta-data instance. The idea is to represent a hierarchical taxonomy separately, and pointing into this hierarchy when classifying resources. In addition, we try to reuse the subject classifications from Dublin Core Qualifiers, for example:
<lom_cls:Taxonomy rdf:ID="MeSH">
<rdfs:label>Medical Subject Headings</rdfs:label>
<lom_cls:taxon>
<dcq:MeSH ID="A">
<rdf:value>A</rdf:value>
<rdfs:label>Anatomy</rdfs:label>
<lom_cls:taxon>
<dcq:MeSH ID="A01">
<rdf:value>A01</rdf:value>
<rdfs:label>Body Regions</rdfs:label>
<lom_cls:taxon>
<dcq:MeSH ID="A01.047">
<rdf:value>A01.047</rdf:value>
<rdfs:label>Abdomen</rdfs:label>
<lom_cls:taxon>
...
Using this will then look like:
<dc:subject>
<rdf:value rdf:resource="http://www.myVocabulary.com/taxonomy#A01.047"/>
<dc:description>...</dc:description>
</dc:subject>
This binding has been developed by Mikael Nilsson at the Center for user-oriented IT-design at the Royal Institute of Technology in Stockholm, Sweden, with cooperation from the Uppsala Learning Lab. Matthias Palmér from CID has contributed substantial critique of this document. Large parts of the binding come from previous work on LOM RDF schemas by researchers from Learning Lab Lower Saxony at KBS in Hannover, from the UNIVERSAL project. Significant contributions to the schema details have come from: Wolfgang Nejdl, Boris Wolf, Hadhami Dhraief, and Jan Brase from KBS, and Gustaf Neumann, Susanne Guth, Bernd Simon, and Thomas Enzi from Wirtschaftsuniversität Wien, part of the UNIVERSAL project.
This table defines, for each element in the IMS Meta-data Information Model v1.2, the corresponding RDF property to use. It specifies how to repeat the element in conformance with the Information Model and gives usage examples. Note that the RDF Schema definition files in some cases provide more precise definitions, especially for vocabulary creators.
Note: Elements 1.1 and 3.1 are special cases that are not represented as properties, but instead use the RDF rdf:about attribute.
Note that all elements below apply not to the learning resource, but to the metadata about the resource. Please see the example document for examples.
In this category, we disagree with LOM in that the Dublin Core property dc:rights maps to this whole category. We think it only maps to element 6.3, Rights.Description (as was the case in IMS Meta-data v1.1). This is reflected below.
This is strictly no category, but an element. Due to the nature of RDF in the semantic web environment, the elements 7.2.2 Description and 7.2.3 Catalog Entry are not used directly. Instead, the intention is that they can be attached to the resource pointed to. In the example below, the related resource is defined by an ISBN number.
This is strictly speaking no category, but an element in itself.
This is strictly speaking no category, but an element in itself.
This table defines how to construct reusable taxonomies.