IMS Learning Tools Interoperability
Another blog-summary from the IMS conference. This talk was pretty quick - I'll have a nice slow look tomorrow and may be able to post more.
Chuck Severance
We got a look at Blackboard 9 proxy tool patterns, and built upon that. It talks about how to put tools inspecifications and to launch those tools. It defines how a tool is launched from the LMS, passing roster information.
Along with the sopecification design has been the development of code. The end point is to get it in the marketplace, rather than to have the standard - it is probably even better to finalize the standard after it has been used for a while.
The core thing is identity. We can use iframe, but we want to pass information along. Also, it enables the provision of learning from LMSs across multiple systems. It means you don't need to implement one of everything in an LMS. This allows us to make exciting things without sticking them into Blackboard, Moodle or Sakai.
When combined with Common Cartridge, this becomes very interesting. By having single signon to access services (and maybe make publishers some money) the cartridges can be very small and mobile. We don't need to send the giant flash file all over, even if there's something in it we wan to protect.
Eventually, LTI will allow even tools in one LMS to be used in a different type of LMS. Where we get our content, and even what language it's in, becomes less and less relevant. We don't have to bring everything into the course.
I created a spec, nothing official, called "Simple LTI" - I went out and posted it, no password necessary. So I've been writing code for a year and a half. But writing code helps me understand what the problems are.
Basic LTI is a profile of LTI of LTI 2.0 - we expect it out in July 2009. And LTI 2.0 by the end of the year.
- demo - the user experience - the user clicks on the tool, and poof the tools shows up
The tool is obtained from the LMS, it is signed using OAuth, the producer receives the form, it validates the signatire, the to provisions the user, course and profile as necessary, the tool is sent back, and then it is sent and displayed.
We have some stuff in production - content integration: McGraw Hill sells them directly to students via common cartridge LTIO integration. Another: Moodle - uses LTI to contact Google, which uses SAML to ask who is in the course, and then the lot is transferred into Google Docs. Use Googl app engine to accomplish that. Another example k12.com
Basic LTI - created 48 hours ago - and a version is in production now. Basic LTI for powerlink is going be open sourced tomorrow.
Also -- www.tsugiproject.org
Also - Pearson LTI 2.0 - pre-release. They have ben working about 6 months on full automatic provisioning. You will go to some resource, click the button, "Add to my course" - just like the 'add to Digg' buttons.
Now, basic LTI is being added to Common Cartridge, so we can add these links to it. If you think of Common Cartridge 1.0, only a fraction of it can work in the LMS. Most of it is just some hacking back into the publisher servers. It's ugly, nasty and prone to breakage.
Common Cartridge 1.1 doesn't expand too much, but we standardize the links back to the publishers. No more hacking. So even though publishers will continue to do things the LMS can't do, we can meet in the middle using standards, and pass the data over.
There's kind of a hybrid model where we can imagine some sort of external player that can't be run in the LMS but can be stored in the LMS so the publisher doesn't have to run the player every time. (SD - an example of this would be a widget engine).
Eventually, you see the line move, so more and more of the stuff (learning design, for example) can be rendered by the LMS.
4-minute technical ovrview. LTI is a bunch of course data, roster and user information, etc. If your passing data and you're not using OAuth, you're a fool. It's the practical security for REST. Google uses it. twitter uses it. www.oauth.net
Three-legged OAuth is truth between two servers and a user. We do not do that - Google wants us to do that. Googles very pushy on this. So is Yahoo - to put course information into groups (don't tell anyone I said that).
demo - 8 line common cartridge with LTI
Basic LTI + CC - sample code - all available http://code.google.com/p/ims-dev
(awesome)
demo - a bunch of CC - LTI stuff from the tool.
Tomorrow - detailed walk-thoughs of the spec. Heh heh heh.
Chuck Severance
We got a look at Blackboard 9 proxy tool patterns, and built upon that. It talks about how to put tools inspecifications and to launch those tools. It defines how a tool is launched from the LMS, passing roster information.
Along with the sopecification design has been the development of code. The end point is to get it in the marketplace, rather than to have the standard - it is probably even better to finalize the standard after it has been used for a while.
The core thing is identity. We can use iframe, but we want to pass information along. Also, it enables the provision of learning from LMSs across multiple systems. It means you don't need to implement one of everything in an LMS. This allows us to make exciting things without sticking them into Blackboard, Moodle or Sakai.
When combined with Common Cartridge, this becomes very interesting. By having single signon to access services (and maybe make publishers some money) the cartridges can be very small and mobile. We don't need to send the giant flash file all over, even if there's something in it we wan to protect.
Eventually, LTI will allow even tools in one LMS to be used in a different type of LMS. Where we get our content, and even what language it's in, becomes less and less relevant. We don't have to bring everything into the course.
I created a spec, nothing official, called "Simple LTI" - I went out and posted it, no password necessary. So I've been writing code for a year and a half. But writing code helps me understand what the problems are.
Basic LTI is a profile of LTI of LTI 2.0 - we expect it out in July 2009. And LTI 2.0 by the end of the year.
- demo - the user experience - the user clicks on the tool, and poof the tools shows up
The tool is obtained from the LMS, it is signed using OAuth, the producer receives the form, it validates the signatire, the to provisions the user, course and profile as necessary, the tool is sent back, and then it is sent and displayed.
We have some stuff in production - content integration: McGraw Hill sells them directly to students via common cartridge LTIO integration. Another: Moodle - uses LTI to contact Google, which uses SAML to ask who is in the course, and then the lot is transferred into Google Docs. Use Googl app engine to accomplish that. Another example k12.com
Basic LTI - created 48 hours ago - and a version is in production now. Basic LTI for powerlink is going be open sourced tomorrow.
Also -- www.tsugiproject.org
Also - Pearson LTI 2.0 - pre-release. They have ben working about 6 months on full automatic provisioning. You will go to some resource, click the button, "Add to my course" - just like the 'add to Digg' buttons.
Now, basic LTI is being added to Common Cartridge, so we can add these links to it. If you think of Common Cartridge 1.0, only a fraction of it can work in the LMS. Most of it is just some hacking back into the publisher servers. It's ugly, nasty and prone to breakage.
Common Cartridge 1.1 doesn't expand too much, but we standardize the links back to the publishers. No more hacking. So even though publishers will continue to do things the LMS can't do, we can meet in the middle using standards, and pass the data over.
There's kind of a hybrid model where we can imagine some sort of external player that can't be run in the LMS but can be stored in the LMS so the publisher doesn't have to run the player every time. (SD - an example of this would be a widget engine).
Eventually, you see the line move, so more and more of the stuff (learning design, for example) can be rendered by the LMS.
4-minute technical ovrview. LTI is a bunch of course data, roster and user information, etc. If your passing data and you're not using OAuth, you're a fool. It's the practical security for REST. Google uses it. twitter uses it. www.oauth.net
Three-legged OAuth is truth between two servers and a user. We do not do that - Google wants us to do that. Googles very pushy on this. So is Yahoo - to put course information into groups (don't tell anyone I said that).
demo - 8 line common cartridge with LTI
Basic LTI + CC - sample code - all available http://code.google.com/p/ims-dev
(awesome)
demo - a bunch of CC - LTI stuff from the tool.
Tomorrow - detailed walk-thoughs of the spec. Heh heh heh.
Stephen - have you seen this?
ReplyDeletehttp://getwookie.org/moodle/course/view.php?id=6
(You need a signup, but its just a test server.)
This is how we do what Simple/BasicLTI does, and a whole lot more, just by implementing the W3C Widgets spec and Google Wave Gadgets API - no extra IMS spec needed; the API spec for connecting the widget server to Moodle/Elgg/Wordpress/LAMS is less than a page long - in fact let me summarise it here:
1. getwidget?api_key=somekey&shareddatakey=somecourse&widgetid=somewidget&userid=someuser
2. addparticipant?(as above+)participant_id=someid&participant_display_name=name&participant_thumbnail_url=somepic
LTI does a good thing, but it doesn't need to be done by IMS, and doesn't need to be anywhere near as complicated - BasicLTI (the *simplified profile* of LTI) has 26 launch parameters for instantiating a tool. Wookie has 7 (see above). The LTI 2.0 spec itself consists of 20 spec documents.
It also doesn't need the kind of closed development process that IMS uses. That just makes it easier to make mistakes, especially when you get a spec that ends up being that large.
Hello,
ReplyDeleteI'm beginner about IMS LMD tools and worked in this theme on last year. We made us tools for publisher and run IMS LMD packages in the Sakai project within that in Brazil is Tidia-ae.
You can see these two tools in http://computacaoeeducacao.blogspot.com/
Regards,
Jaguaraci Silva
http://www.jaguaracisilva.blogspot.com