Forum OpenACS Development: Re: Res: error raised when activity appears in several role-parts

Michael, thanks a lot for the feedback. Your are helping us a lot.

We were dealing with that bug now. We think its' better to mark the activity finished in all the role parts that references it. What do you think?

About the other question, we haven't plan about multiple runs of the same UoL, but that could be possible, as you say. All we need (the info in the db) is there, so it would be just to add the API to do it. We will take it into account for our future developments/goals.

Regards

I am wondering if you do not need the concept of a "run" if you deal with multi-user learning_designs where you "enroll" users to a unit of learning, assign them to roles, before you start delivering it, and have to keep track of them as the community of users participating in the same "run", as suggested in the "Implementation guide" of the specification.

Regards,

Currently, we are working on the support of roles into the application. When finishing this task, the information about completed resources will be: user_id, role_id, role_instance_id, resource_id.
With this, before delivering a unit of learning, you must assing roles. Moreover, to reply an IMS-LD you will only have to re-instance a role, and the resources will appear as not-completed, and the imsld will be replied.

All this features are on development. We can call for test before commiting on CVS.

Michael,

We are right now working on supporting multiple runs for the same UoL. So the first thing the professor will have to do after uploading an UoL is to assign users to the run. Then the roles instances, properties instances, etc. will refer to the run (instance of the UoL).

More specifically, I was thinking about adding a "imsld_runs" table, which will map the run with the ims_ld_id. Then the instance of the roles will be made with the users which are assigned to the run, and the "status" table will also store the run_id. Also, the properties instances will refer This way there may be multiple runs for the same UoL.

Do you have any comments?

Jose,

sorry for the late reply. What you describe seems reasonable to me. If you already have something up ready for testing, I would be glad to try it and give you detailed feedback.

Sorry, I forgot to react to the first point. I am not sure if marking the activity finished for all role parts where it is referenced, is what is intended by the specification.
If you think of a learning design with two plays, which both reference the same activity, but in two different contexts. If a user first executes play 1, and passes the activity, and later he executes play 2. When it comes to the activity he already has passed in play 1, it could possibly make a different sense in the new context, and if it had been already marked as finished, the flow of play 2 could become disturbed, or in the first case no longer make sense.
Does this make sense?
Sure, we have also thougth about this fact. The problem appears when the same activity is referenced from two different places, no matter if we are talking about role-part, environmente or plays, the fact is that you have to do the activity twice.

On one hand, the activity has different meaning into different contexts. Another point of view is that the activity is the same, and you can do again this activity, no matter if it have been finished or not. That means: if you have already done an activity and it's time to do it again from another place (role-part, play, etc.) the activity is shown and you can do it again.

Copper-Core behave like .LRN IMS-LD in this sense.