It is important to acknowledge a couple of things before addressing some of this questions. We tent to think way to much on the tech aspects of the implementation and that's cool. But it is also as important to understand the problem that these specs are trying to tackle.
I'd strongly suggest to have a good thorough read of the specs a bit as it would clarify some of the questions you ask here and also will make you go "ahhh, that's what it is..." sort of feeling.
I know, they are an absolute bi#ch to to follow and they are as dry as a pommie's towel. But nevertheless, they are the best we got. The best practices and implementation guides are probably the best start.
> - How does an IMS CP repository differ from the Content Repository
> used by OpenACS ?
This is a big and open question. But let me see if we can summarize it a bit:
OACS CR = stores content
IMS CP = organize and structure content
So, LORSm basically uses the OACS CR to store all the content, and the IMS CP implementation maps all the organization and structure of the content to the actual content.
For instance, an IMS CP item (an entity that could describe a learning unit/object/chapter/etc) is basically an aggregation of content put together to fulfil a specific learning objective (of course without getting very heavily into technicalities and details).
So manifest/organizations/organization/items and to some extent resources, are entities defined for IMS CP that hold structure and organize content in a particular way.
I hope this answers/clarifies the question a bit.
> - Would it make sense to extend the OpenACS content repository by the
> functionality in which IMS CP differs from CR.
No. The CR is pretty cool the way it is and that all it needs to do (for storing content).
The IMS CP implementation sits on top, mapping
> - Looking at ims_cp_items (from the LORS package), a couple of other
> questions come into my mind (in the background of evaluating if
> assessment should extend ims_cp_items instead of cr_items, which would
> be implied by using the IMS CP repository and not the OpenACS Content
> Repository (pure version)).
> - How are additional attributes to ims_cp_items handled? I assume
> through the metadata definition.
Metadata is a different set altogether. If for instance an item contains a node of metadata ala:
... when I parse the item, I grab the metadata node and pass it to the IMS MD implementation that parses the node and extracts the whole 100+ fields of metadata and maps them into the DB (yeah, it was hell of a mapping).
And this might be *just* the same way as it might work with IMS SS extensions.
> - Should this approach taken there be generalized to allow handling
> metadata of items in general (of the content_repository), thereby
> making the extensions to cr_items and useage of your own package
> tables obsolete?
Although I think that IMS MD has waaay more metadata than any normal human can think of, I wouldn't try to map out all sort of metadata into this schema. Why? well, because you might not need so much. In the implemetnation of IMS MD in LORS, you can specify metadata for any acs_object. So in theory yes, it is possible. However, practically, it might not make a lot of sense.
> - If the answer to above is no, under which circumstances should a
> package store it's content in the LORS CP and what is the benefit
> compared to using it's own tables / plain content repository ?
The simple answer is: it's done, you don't have to generate 50+ tables in metadata and content packaging entities. It has integration with OACS CR, all IMS CP are acs_objects, exposes the metadata to the search packages (tsearch/tsearch2) and it uses the file-storage for storage and delivery (taking advantage of versioning, permissioning, webdav, etc).
The other best bet you might have would be to manually put your content in the file-storage, creating the folders and then putting all your files in them and liking them together. But then you will miss out on the main purpose of putting this content into packages (the idea of having learning objects)
> - What is the parameter attribute for?
It is for passing parameters to the LMS on runtime. So for instance, if your item points to a resource and this resource has href ="/index", then you can specify parameters to pass to this page when it's requested. For instance if the parameter is "msg=hello", then the LMS should render '/index?msg=hello' as URL.
> - How do you store prerequsites? Wouldn't it make sense to use
> relationships for this ?
> - Some varchars suggest you would store XML content in these, is this
> true (e.g. maxtimeallowed, timelimitaction)
No, I parse XML, get the value for the attribute and put it in the DB. It's all XML, but you just need to extract what you need.
> - Is there a specific reason for storing isvisible, as this could be
> handled through the permission system.
Yes it is, as it doesn't mean that you are display the item, but also how it's position is in the sequence (have a look at the best practices doc)
> - You seem hesitant to use acs_rels in your system. Is there a reason?
> (I see a couple of mapping tables).
It's not that I've been hesitant, I haven't used them at all. As I mentioned in my previous posting, I still need to play with permissions.
I hope this helps, again, I strongly suggest to have a look at the best practices and implementation guidelines as they might help a lot