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.
  1. IMS-CP means being able to easily collect the CP-resources and structure talked about. Focus is packaging.
  2. As SCORM reuses IMS-CP for it's CSF (Content Structure Format) more flexibel uses of a manifest is foreseen. Focus is here structure.
  3. What are the relations between models and manifests.
  4. There are already an rdf-binding for IMS-metadata, it will be used.
  5. 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.
  6. Should CP-resources be explicitly stated as in the XML binding or only indirectly via the transitive closure of the organizations?
  7. 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?
  8. 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.
  9. 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.
  10. 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.
  11. 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.