KMR > E-learning frameworks > Specification development > IMS content packaging
Relevant considerations (currently rather mixed)
Se separate page for a discussion.
As resources in CP info model is a construct that is different
from what is meant in the RDF community with a resource I will
hereafter differentiate them via calling the first a CP-resource
and the other just resource.
- IMS-CP means being able to easily collect the
CP-resources and structure talked about.
Focus is packaging.
- As SCORM
reuses IMS-CP for it's CSF (Content Structure Format)
more flexibel uses of a manifest is foreseen.
Focus is here structure.
- What are the relations between models and manifests.
- There are already an rdf-binding for IMS-metadata, it will be used.
- Can properties from IMS-MD be used when constructing other parts
(than thoose that already are IMS-MD) of this binding?
E.g. reuse of dc:hasPart as a way to relate items with subitems
is semantially correct even if it gives rise to some subtle problems.
- Should CP-resources be explicitly stated as in the XML binding or
only indirectly via the transitive closure of the organizations?
- If an item points to a CP-resource should the items metadata
autmoatically apply to the CP-resource?
Does it make a difference wheter the items has subitems or not?
- It would be nice to use the inherent structure of the CP-resources
(i.e. the dc:hasPart property in the metadata of the CP-resources)
as an organization without forcing you to reflect the same structure
as a tree of items pointing to the CP-resources.
This implicitly means that you have no clue whether this
organization is hierarchical or similiarly, i.e. it's up to the
metadata of the resources collectively to decide.
- It's elegant to use inheritance from items to specify different
organizations but it could result in a lot of unneccessary
type checkings. Especially if the next consideration is true.
- Shouldn't really the type of an organization be possible to specify
on each item allowing a more finegrained view of the organizations
structure. This information will be lost if you export to other
bindings.
- The two suggestions above forces you to do type checks
as otherwise you will treat CP-resources as items as both use
dc:hasPart to point to respectively subitems and parts of the
DC-resources.