Forum .LRN Q&A: Re: Request for advice from the OCT

Collapse
35: Re: Request for advice from the OCT (response to 1)
Posted by Ola Hansson on 06/16/04 11:12 AM
Simple Sequencing (the reason this whole thread started) is not out at the moment and might not be for some time. Once an API is out, it sounds like a good idea to evaluate this and then implement (parts) of it in assessment (if someone is willing to put money in this).
I agree it would be worth evaluating that day, and let's be optimistic, Malte - I suspect that the .LRN funders are beginning to see that there is a huge need for this missing link.
Question: Why does everyone say assessment has to follow the SS model, but noone talks the other way round: The SS package could as well make use of the functionality written within assessment and add other SS related things on top of it. After all, the sequencing specs (technical) for assessment are already out in the open, so anyone who has an interest in SS and wants to see standards supported and prevent a lot of money invested in sequencing twice, PLEASE take a look at the specs and give feedback. Or, even better, write up a specification for SS that is more readable than IMS specifications and tailored to the OpenACS realities.
I don't say so 😊. SS can't use code in Assessmet for its sequencing for the simple reason that Assessment is not specified/coded to cater for the same needs. To the extent they *will* eventually share parts of the code or certain sub-processes, it makes a lot of sense (easier, quicker, less expensive) to first make sure the SS package gets funded and implemented, and then we can think about refactoring and breaking out some parts of it if we find that it makes sense at that time. I would honestly find it quite difficult to predict, at this early stage when there even is no SS package, whether a reuse of functionality such as what we are talking about now makes sense or not. It makes sense to keep that kind of reuse in mind, though. (Malte, the SS spec is pretty clear as it is with its pseudo code, only it doesn't say what programming language to use. If that is too long to follow, the Carnegie Mellon paper is a nice summary of the SS spec. If I specify it any more OpenACS-centric than that, well then it is practically already implemented.)
Collapse
39: Re: Request for advice from the OCT (response to 35)
Posted by Malte Sussdorff on 06/16/04 03:35 PM
I just read through the Carnegie Mellon paper *again* and tried to understand how an implementation like this would help us with our internal branching needs and solve at the same time our generic "condition results in action" problem. I asked Timo to read through it as well. We did not come up with a solution at  the moment, especially taking into account that our generic condition results in action approach hits two flies with one stroke and there is not much sense to use SS for branching if it already works smoothly with an internal approach, unless I'm given a use case which mandates this (all use cases given so far can be solved by the way described a couple days back).

Therefore I will drop the issue of how the assessment should handle the use of SS and LORS internally from my part, as I need to follow up on other things as well. If people are interested in putting SS into assessment I'm open for detailed suggestions that provide an enhancement over the currently taken approach. If people are interested in storing items, sections and assessments in LORS, then I suggest to take a look on how assessment at the moment defines the items, sections and assessments itself and come up with an OpenACS solution on how to solve this with LORS.