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
-~----------~----~----~----~------~----~------~--~---

Reply via email to