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.