KMR > E-learning frameworks > Specification development > IMS content packaging
RDF binding of IMS content packaging
This page considers a RDF binding of the
IMS content packaging standard effort.
There are some considerations a binding
has to take a stand on. We have already had some
discussions which form a basic FAQ on example 2.
A similiar discussion on example 1 will be put up shortly.
Constructed by: Hadhami Dhraeif, Matthias Palmer and
This example comes very close too the IMS content packaging data model.
Constructed by: Hadhami Dhraeif and Matthias Palmer
There is a shorthand for linking in CP-resources, just point to them directly
from an organization via dc:hasPart or dc:hasPart to a rdf:sequence which
contains them. This is translated just as pointing to intermedient organizations,
one for each CP-resource which in turn points to the CP-resources via rdf:value.
This shortcut is only possible when no information should be added on the
Manifests are a resource of type Manifest with submanifests pointed
to via imscp:hasManifest wich is a subproperty of dc:hasPart.
- Organization is a class that have subclasses to distinguish
between hierarchical and flat structures. An Organization is a merge between
the Item and Orgnaization entries in the data model.
- An organization has-sub organizations listed via repeating hasPart
properties or a single hasPart property pointing to a rdf:sequence containing
- Each organization can point to a rdf:resource via rdf:value,
this represents the CP-resource in the data-model. This resource may point
to other resources via dc:hasPart, this is interpreted as the file entry in
the data model.
- Metadata may be expressed on the manifest, organization or on
the resources pointed to via rdf:value and then on the succesive resources
pointed to via hasPart.
- (Sub)manifests, organizations or resources may be expressed
in other models and should be refferred to via their URI's (as RDF always
does). No duplication should occure in the RDF representation unless needed
for transport or export to other formats.
- Metadata (dc, lom etc) may be expressed in other models. As
in this case there is no explicit referrence to theese models a dc:hasPart
property on the manifest indicates where to look.
- CP-resources need not be explicitly listed. However they may
be listed in a top level flat organization which is what will be generated
on export (to other bindings) if noone already exists.
Also, note that the distinction between the shortcut, i.e. pointing directly
to an CP-resource or to a organization lies in the fact that a resource is
of the type organization or not. Hence if the structure of a CP-resource should
be visible as a part of the organization struture you only need to type the
CP-resource to be a organization and point to it like any other resource,
there is no way to tell the cases apart. Here is a picture that illustrates
how the shorthand (pointing to a resource that isn't of the type organization)
should be interpreted.
Mail any comments to Matthias Palmer <email@example.com>.