At 9:13 PM -0700 5/24/07, Matt Fishbach wrote: >Another scenario which is even more likely to occur in classroom settings. > >Suppose I run a week long project. It has six activities. My sample class >has 27 students. >All students pair up and one students works by herself. Students A & B are >paired. Student C is the solo. >On day three of the project, student A gets strep throat and will be out of >school for two weeks (you'd be amazed how often this sort of thing happens). >Students B & C ask if they can work together for the remainder of the project. > They've both already completed Activities 1 and 2, and want to do Activities >3-6 together. >If I move student B into student C's team, do I replace all of her Activity 1 >and 2 work with the existing work done by student C? If I move Student C into >Student B's team, do we override Student C's established data.? If we keep >track of their individual data, how is this melded once they're in a group?
Hi Matt, It's great to have somebody else thinking about these issues from the classroom side. See my previous email about how this is implemented now. Last August when I implemented the SDS we discussed these issues. At the time we decided to keep all the data associated with a workgroup even if the membership changes. If two workgroups startup: Oranges and Apples Oranges: students A, B, and C Apples: students C, D, and E Each workgroup completes three sessions and then A is removed from the Orange membership and added to the Apples membership. Right now there is no way to distinguish the data contributed to the Oranges workgroup from student A from students B and C. So we decided that we certainly didn't want the SDS moving any data around. Basically it should handle all the use cases and speak 'truthfully' about what happened. By 'truthfully' I mean accurately describing what the data mean and only accepting valid queries. In this case you describe below this means that there is no way to precisely ask the SDS to give me all of Student A's work. Instead a portal would need to ask: "Dear SDS, In Offering 123 please give me all the learner artifacts for all workgroups student A has been a member of. Please also include the times these artifacts were collected and list the other members of the workgroup or workgroups student A was a member of when these artifacts were collected." The Portal could then use these data to present functionality similar to that you describe below. If your Portal needs the concept of "Student A's data file" then it would have to process he data returned from the above query to the SDS to construct his new artifact. The SDS has no concept of "Student A's data file" it only understands artfacts saved for workgroups Student A has been a member of. >My suggested compromise: >- if student A is moved into a new group X and that student has any stored >data, then the system warns the teacher that the Student A's existing data >file will be updated to match the work already completed by the Group X, and >all previous work completed by the student will be appended as "Archived >Work." So now student A is unified with the other student(s) in team X, >except that Student A's also include their old work (marked with a header tag >along the lines of "ARCHIVED WORK before transfer to new group on [date]. " >This should be fairly easy to due for the text in Notes, but we'd have to >decide how to handle the many other types of assessment steps. I think the SDS should support the portal in presenting this kind of UI and data policies to the teachers and students. It is very important for however for folks like you to have a good understanding of the underlying relationships that the SDS implements -- not the actual mechanisms necessarily but to have clear model of what are the SAIL models of persistence (in the SAIL documentation what I call workgroups are often referred to as Agents). This understanding will help you more effectively specify functionality a Portal can perform and composite data models a Portal can create from SAIL artifacts delivered from the SDS. These conversations and work based on them can also guide and provoke improvements in SAIL and the related SDS. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
