Do we need a "basic" outcomes service?

[Scott Wilson]

I've just taken a look at the IMS Outcomes Service. Its very SOAPy and very XMLy and very complicated [1]

I can see it being used with something like QM Perception, however, for basic learning apps something much simpler ought to work fine. We mostly need to POST outcomes rather than read/delete/update them, and the outcome data itself should be pretty basic for most apps.

So I was wondering if something like this would work instead:

Outcomes API

POST /{api endpoint}

(oauth params)

context_id= identifier for the context, e.g. id of course
context_type= {handle of context type, e.g. course, section etc}

lis_person_name_full
lis_person_contact_email_primary={email add?}

result_type={interim | final | midterm} <- optional, default is "final"
result_label= label for result, e.g "passed!"
result_score= score value, e.g. "85"
result_date= date score recorded
result_list= optional comma-delimited list of possible results (e.g. "A,B,C,D,E", "pass,fail")
result_range= optional scale of values (min-max) e.g "0-100"
result_status={unmoderated | tobemoderated | interim | final} <- optional, default is "unmoderated"

Returns:
201 Success
400 Bad Request
500 Internal server error

[1] http://www.imsglobal.org/lis/lisv2p0pd/OMSinfoModelv1p0pd.html

[csev]

Scott,

We have been working on an internal doc called SimpleOutcomes aimed mostly at some demo experiments that might lead into a Bacic spec if we like it.

I attach the draft materials for the spec and also for an important part of the result_sourcedid design used so far in Sakai and Moodle.

/Chuck

[Scott Wilson]

Thanks Chuck - it would be great to have the "80/20" case of posting simple outcomes covered using REST. Carlos (GLUE!) and I were discussing this earlier in the week.

So the basic idea is to generate an opaque ID to pass to widgets/apps/tools to associate any outcomes plus outcomes API URL as part of the launch params? That would certainly make the API nice and easy to implement.

I'm happy to have a go at implementing it in the BasicLTI adapter for Wookie if there is a Moodle or Sakai build to work to.

It would also be pretty easy to spec a complimentary simple JavaScript API for injection as a Feature in Wookie and Shindig, e.g. "simpleOutcomes.reportPercentage(85);"

> <sakai-outcomes-02.rtf><simpleoutcomes-04.rtf>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "IMS Developer Mailing List" group.
> To post to this group, send email to ims...@googlegroups.com.
> To unsubscribe from this group, send email to ims-dev+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/ims-dev?hl=en.
>

[csev]

On Aug 27, 2010, at 11:21 AM, Scott Wilson wrote:

Thanks Chuck - it would be great to have the "80/20" case of posting simple outcomes covered using REST. Carlos (GLUE!) and I were discussing this earlier in the week.

So the basic idea is to generate an opaque ID to pass to widgets/apps/tools to associate any outcomes plus outcomes API URL as part of the launch params? That would certainly make the API nice and easy to implement. 

The Opaque id notion is already in Basic LTI - we put it in knowing that LIS was coming and that the opaque ID was the way LIS would do Outcomes.

I'm happy to have a go at implementing it in the BasicLTI adapter for Wookie if there is a Moodle or Sakai build to work to. 

There is a Sakai implementation - it is in trunk and scheduled for release in Sakai 2.8.

There is a Moodle 1.9 implementation - I have it in a Mercurial clone

http://code.google.com/r/drchuck-simpleoutcomes/

It would also be pretty easy to spec a complimentary simple JavaScript API for injection as a Feature in Wookie and Shindig, e.g. "simpleOutcomes.reportPercentage(85);"

I also implicitly proposed such a creature for Shindig in this:

https://cwiki.apache.org/confluence/display/SHINDIG/Adding+a+New+Feature+to+Shindig

/Chuck