My answers are interspersed. Anthony Perritano wrote: > > On Apr 1, 2008, at 6:45 AM, Scott Cytacki wrote: > > >> I was hoping the persisted user data for pas would look the same as >> the >> persisted user data for udl, itsi, and capa. This way the reporting >> code could be unified. >> > > Hiroki, Geoff and I talked about this and we are interested in > unifying our user data persistence schemes. We would like to learn > more about them. > > where can we learn more about them? > > if we did this. what would the development effort look like. > Just doing something like what I described in my last response would be all you need to do. And then thinking through how the SDS and Pas portal needs to be updated.
I don't know if there is any single place where you can learn about the data persistence schemes by udl, itsi, and capa. They all basically use the same approach which is to store the learner data in OTObjects just like the Pas authoring tool is doing. And the OTrunk system takes care of keeping this data separate from from authored data. >> So that would mean not using OTSock and OTSockEntry or >> OTPasInterfaceObject. It also means not storing the history of the >> sock entries. That would have to wait until the OTrunk logging is >> activated. >> >> So each Pas Step type that has rims would have properties on its >> OTClass >> to store the values. If the step type has multiple rims based on its >> content, then it would have a list of OTObjects representing that >> content and each would have a property to store the user data. >> >> OTAssessment is an example of that latter case, and QTI complicates >> this. >> >> I don't know if I have this right, so please correct me: Each >> OTAssessment has one qti AssessmentItem which has multiple qti >> BlockInteraction. Those BlockInteractions correspond to the tabs in >> the notes. When these BlockInteractions are created by the converter >> they have identifiers. >> >> Do they also have identifiers when they are created by the authoring >> tool? >> > > The assessmentItem has something called a responseDeclaration linked > to each BlockInteraction. in our pas note the author creates a text > interaction or choice interaction, with that a new > "responseDeclaration" is created and a new rim. these are put into a > map. basically mapping the question to the answer. This map is a > property on the bean and is something that is checked when the note > loads up in the vle. it gets the rim and looks up the sock and > displays the last entry. > > > >> So I would add a OTObjectList property to OTAssessment which stores >> OTBlockInteraction objects. And then each OTBlockInteraction would >> have >> a property to store the identifier of the block interaction and a >> property to store the response. You might need to create sub >> OTClasses >> for the different types of BlockInteraction so you could store the >> responses correctly. >> > > do we really need the OTBlockInteraction structure? all we need is > something similar to responseDeclarationToRim map. something that maps > some and id to some data object. this was the transferObject that > aaron and i discussed. if we unified under tghe data persistence > mechanisms wouldn't we want this to be generic for future steps that > have multiple "sock" like structures. > The list of OTBlockInteraction objects is the map you are describing. Each OTBlockInteration has a id and a value property which is the response. It might make sense to create a generic version of this, but I would guess that each step that needs to store multiple pieces of user data will have different needs. Is there another step type that needs this? If not I'd wait until one shows up before generalizing it. The data persistence mechanism in use by the other projects is for the java code or script to put the user data inside of the authored content objects. This way there is no need for the java code or script to worry about ids. And also a programmer doesn't need to learn two state saving systems to work on the author and learner code. The code just puts the data inside of its own object. If this is done at author time them it is stored as the authored data. If it is done at learner time it is stored as learner data. That authored content object can be split into multiple objects so it can store multiple pieces of user data. The way a programmer decides to split the authored content into multiple objects is flexible so it can be done however it makes most sense. > > >> So with these objects, then the particular PasStep would be loading >> and >> saving stuff directly into its own OTObject. If you want to keep >> PasSteps independent of OTrunk then you could stick an interface in >> between which the PasSteps use and the OTPas controllers implement. >> >> The draw back of this solution is the temporary loss of fine grained >> user data history. When I come back I plan to continue work on the >> logging code so this type of fine grain history is available to all >> OTrunk applications. >> > > when do u come back? > I'll be starting part time the end of this week or early next. > >> I think this draw back is offset by the benefit from unifying the user >> data model for our multiple projects. Which ever approach is used, >> the >> reporting code in the SDS and Pas Portal is going to have to be >> updated >> to handle the new format of the user data. If the user data is >> unified >> then that work (which has to be done no mater what) will benefit more >> projects. And those projects will be working on improvements to the >> reporting, so Pas should benefit from that. >> >> Sticking with the rim, sock, and sockentry model will make updating >> the >> reporting code easier in the SDS and Pas Portal, but that work will >> only >> benefit Pas. >> > > i think we agree with you and unifying makes sense. the question is > how we can initialize this effort? > > -Tony > > >> Scott >> >> Aaron Unger wrote: >> >>> Tony, Geoff and I met today and discussed how to persist data from >>> PasSteps under pas-otrunk. Notes from the meeting can be found here: >>> http://www.telscenter.org/confluence/display/SAIL/Pas+OTrunk+Persistence+Model >>> >>> The page basically outlines a bunch of classes and interfaces that >>> could >>> be used in order to allow pas steps to save into otrunk objects >>> instead >>> of socks/sockentries, and hopefully will work for the situation Tony >>> describes below. >>> >>> Questions, comments, critiques are accepted. >>> -- Aaron >>> >>> Anthony Perritano wrote: >>> >>> >>>> Aaron, geoff, hiroki and i had a good discussion about how to get >>>> PO- >>>> Trunk steps persisting learner data. The method that we want to >>>> explore is passing an OTrunk object into the pasStep and bypassing >>>> the >>>> rim/sock/pod model. After that discussion Hiroki, Geoff and I sat >>>> down >>>> and looked at our main scenario for persistence which is notes. i >>>> think one of the we are confused about is how our sock/rim model >>>> translates to this OTrunkTransferObject that is passed in. >>>> >>>> for instance, in our current model. there is a bean property on >>>> Notes >>>> that is a Map of ResponseDeclarationsToRims. this is created at >>>> author >>>> time. On start up of the step, that map is iterated and the rim is >>>> used to find its sock. once the sock is found or a new one is >>>> created >>>> it is put into a map ResponseDeclarationsToSocks. this is basically >>>> mapping the the question to the answer. >>>> >>>> i think the big question is this OTrunkPasTransferObject. How do we >>>> distinguish which data(a sock or OTrunk equivalent) goes with >>>> question. In our old model a 3 part note has 3 rims and 3 socks. >>>> are >>>> there OTrunk mechanisms that the transferObject can use? we are >>>> still >>>> going to need some mapping similar to ResponseDeclarationsToRims/ >>>> OTObject at author time? are there any examples that we can look at? >>>> >>>> thanks >>>> -Tony >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SAIL-Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/SAIL-Dev?hl=en -~----------~----~----~----~------~----~------~--~---
