Stephen, it looks like this message is truncated, at least in the archives. It ends with "We have a implemented a ". Can you resend the full text?
Also, did this get discussed at last Wednesday's meeting? I couldn't make it. -Turadg On Mar 22, 4:01 pm, Stephen Bannasch <[EMAIL PROTECTED]> wrote: > The TELS project would like to be able to support the teacher > feedback functionality Matt F. has story-boarded. > > I'll describe two options below: > > 1) Annotations > > My proposal is to build this on a new SAIL type I'm calling > annotations. Annotations are similar to socks in that every pod-rim > combination instantiated for a Workgroup would have a Annotation into > which annotationEntries can be put or fetched. > > While annotationEntries are held in a type of list similar to > sockEntries to be complete they need an additional aspect: they are > interleaved with the sockEntries. In otherwords an annotationEntry > exists before or after a scokEntry (and if the annotationEntry was > created before any sockEntries then it exists before any sockEntries > that may be created. The rationale for this is that the teacher > feedback represents an artifact that was based on student work at a > specific time and state and as such the state of that work when the > annotation was made should be recoverable. > > This could be implemented with a single list container that held two > types of objects: sockEntries and annotationEntries. > > Here's a simple use scenario: > > After some students have used a PAS project a teacher starts up the > teacher PAS to review and then comment on student work. These > comments and feedback are stored as Annotation Entries for that > workgroup. > > When the student starts up the PAS project a UI is presented that > enables the student to see that their teacher has given them feedback > and what that feedback is. > > What is different is that normally the Pod delegates the the > management of the UI for the annotation to a service which can be > implemented to handle these requests from any Pod in the project. > > 2) RunProperties > > A property could be set for each workgroup whose value was a URL for > accessing the feedback from the teacher. > > A simple version of this exists now in that any portal can add > arbitrary properties by appending them to the jnlp for starting a > workgroup. > > RunProperties are a variation where the property is set when the > portal creates the SDS resource and the property will be added to the > config file sent to the SAIL application when it is started. > > The idea is that these properties could be set on Portal Realms, > Offerings, or Workgroups or by passing in a value by appending it to > the jnlp url. > > The PAS program would have to be extended to interpret the URL and > possibly add on to it with the Pod uuid and rim name in order to > specifically identify resources mapped related at this level. > > We have a implemented a > -- > - Stephen Bannasch > Concord Consortium,http://www.concord.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
