KMR > E-learning frameworks > Specification development > IMS content packaging
Questions regarding example 2 before example 1 existed separately.
Q1
While in CP the item list of an organisation is ordered, dcq:hasPart doesn't
include ordering information.
How is ordering handled in the proposal?
A1
You're quite right, there is no ordering when repeating properties in RDF.
However when I read the information binding the last time, I couldn't find
the information that the items should be ordered. Reading it again I see a
note that maybe should be interpreted this way:
2.2.4 Item ..... Can be used in
a hierarchical organizational
scheme by ordering and nesting.
However it's rather unclear, so if you have found this clearly stated somewhere I would really like to hear about it.
The reason for using dcq:hasPart is to make the organization structure
and the CP-resource file tag to have a common syntax. My thought is that
the CP-resource construct is unneccessary and it should be replaced with
a notion of when to stop digging out structure from resources via the dcq:hasPart
which may exist in several steps. I.e. when should the resources structure
be visible as a part of the organization and when viewed as a black box
(a CP-resource).
Q2
What ist the reason for introduction of organization type markers (Graph,
Hierarchy, Flat)? I didn't find these types in the CP spec.
Also IIRC only tree-like structures are allowed as organizations.
A2
In the information model there is an entry 2.2.2 that says structure which
is a string that currently has only one defined value, i.e. 'hierarchical'.
However they say that in the future there may be several other acceptable
values. I thought that the correct way of modeling this is via inheritance
rather than adding an extra property.
Then I've taken the liberty to add some extra classes.
It's up to applications to support other strucutures and export them correctly
to XML.
Comment
In the current example 2, the graph class is removed.
Q3
Wouldn't it be good to use rdf:Seq to express the item structure
for organizations?
A3
Well, we would have the order. But we would loose the convergence
between items and CP-resources.
Comment
In example2 we allow hasPart to point to a rdf:sequence.
In example1, another construction simliar to linked list is used.
Q4
While the proposed Schema is able to represent a CP,
there isn't much resemblance left to the original CP spec.
A4
I disagree, the spirit is still there, i.e. the semantics from a
manifest is expressable. However the syntax is a bit different, but I think
this is due to the fact that they specified the information model thinking
to much about how they would do it in XML.
There is very clear signs of this, e.g. duplication of title and some entries
that have no other purpose than being containing tags in XML.
Doing an RDF-binding is very much about capturing the essence of what we
want to express and do this in a way that allows maximall reuse and flexibility.
Actually the current suggestion may be used to express much richer content
packages than the current XML binding, I see this as a feature not as a bug.
Very simplified:
A similiar decision between syntax and semantics of the binding had to be
made for the ims-metadata binding. Semantics was choosen, see here for details.
Q5 (partly obsolete)
I think the binding should use the same terms as the spec (item),
and try to avoid additional terms (Graph/Hierarchy/Flat, Builtin/EntryPoint
).
A5
The difference between organization and item in the cp-spec is just that
organization is the item on top. And since we already mapped the structure
information as a subclass it felt like Item could be modeled as a subclass
as well. When trying to do this we realized that the name item is actually
misleading, item seems more like a leaf in a list as a catalog, hence we
decided on using organization and possible subclasses of organization everywhere
instead.
So we could equally well call the superclass Item instead of Organization if that rings better.
As we have specific inherited classes for expressig the structure it seems
uneccessary to have both Organization and Item.
I'm not that happy with Builtin and EntryPoint though, I will investigate
further if there is some acceptable way to do without them and still retain
all functionallity.
Comment
In the current example2 they are removed.