IMS Developer Network

IMS Developer Network

Dr. Charles Severance
IMS GLC Developer Network
Coordinator

© Copyright 2008 IMS Global Learning Consortium
All Rights Reserved. 1

Goals of the Developer Network

• Increase adoption of IMS Standards in real,
shipping products
• Increase developer involvement in standards
development – use implementation experiences
• Improve interoperability between different
implementations of IMS Standards on “day 1”


Adding Value to Member Efforts

• IMS does not have developers, nor do we build
products
• Coordination and communication amongst member
developers – increase efficiency
• Build structures for exchanging information
between member developers- like open source


Communication

• IMS Developer Network (members only)
• Work in development – working with draft specs

• Webinars – To the membership and public
• Speaking outreach at developer-oriented meeting
• Developer tutorials – at meetings or on site
• Software artifacts


Open Source IMS Artifacts

• Apache 2 contribution agreements and license
• Reusable code – think jar file
• Sample code – multiple languages
• Test code to help exercise implementations

• Clean Intellectual Property is very important so
these artifacts can be used in shipping products


Resources

• Some of this will be an exercise in “herding cats” –
motivating “volunteers” to help each other
• Increasing IMS Developer Network Membership will
increase resources
• Will engage in some fund raising to retain
resources to do bits and pieces here and there


Value Proposition of DevNet

• Once a member’s developers “are hooked in”
information will come to them
• I will actively work to “pull information” out of
one member to be shared with all members
• Members can adopt/implement more specs with
less time and less travel.


Next Steps

• Work with IMS to develop legal structure for
developer network
• Continue work with LTI 2.0 to help define the
mission and approach – investigate LTI Alliance
• Broaden involvement to other efforts as
opportunities present themselves


IMS Learning Tools
Interoperability 2.0
Building the Standards for Learning
Functionality Mashup


IMS Tool Interoperability

• A standard which is currently under development
by IMS (www.imsglobal.org) for functionality mash
up
• Effectively provides Facebook-like capabilities for
learning management systems
• Read-write access from a tool to the LMS


IMSTools Interoperability 1.0

• Demonstrated at IMS
Alt-I-Lab 2005 in
Sheffield England
• Balckboard, Sakai,
WebCT, Moodle,
Samigo, ConceptTutor


Caveat: This section discusses a
specification still under
development – anything can change
as the specification progresses.


IMS Learning Tool
Interoperability 2.0
• Currently in Development
• Specification Leads
• Bruno van Haetsdaele -Wimba
• Chris Moffatt - Microsoft
• Learning Functionality Mash Up
• Integrated into “Add Resource” in learning
systems


Scenarios

• IMS LTI 2.0 tool installed by the administrator – end-
users don’t even realize the tool is hosted externally
• IMS LTI 2.0 generic tool available to instructors – to be
placed and configured Mash-Up style (like a general-
purpose RSS reader or web-content tool)
• An IMS LTI 2.0 tool is placed when a publisher
cartridge is loaded – often these are partially
provisioned


Virtual Tool - Admin Install

• Administrator installs a proxy tool and makes it
available as a regular tool
• Administrator configures services “sandbox” for
the remote tool – exchange of key material
• Tool may have permission to connect asynchronously
• Tool may have permission to places “resources” –
instances of itself in a course shell

Instructor MashUp – YouTube

• Instructor creates some learning object in an external
service (freelearningsoftware.com)
• The service presents a URL + password
• The instructor pastes
this information into
an LTI Consumer Tool
in the LMS


Instructor MashUp – SandBox

• For instructor mash up – the Instructor configures
the ”sandbox” at the time of mash up
• The admin can set an
inherited “sandbox”
for all instructor-
placed tools.


Common Cartridge

• Scenario 1: Content points to a pre-trusted host
such as content.pearson.com – administrator has a
sandbox pre-configured for tools that point to the
pre-trusted host
• Scenario 2: When there is no pre-arranged
trust/sandbox – a placement from a cartridge
behaves as an instructor-placed IMS LTI proxy tool.

Case Study: UM.SiteMaker
www.gvcsitemaker.com
• SiteMaker is a simple, end-user tool to build web sites
• Database capability called “data tables”
• Combination of power and simplicity
• Written in Apple’s Web Objects by Michgan
• Now has its own open source community and
commercial vendor
• Should we rewrite SiteMaker in Sakai? No.

All Rights Reserved. www.gvcsitemaker.com 21

Sakai / Sitemaker Integration

• Launching via IMS LTI 2.0 (an early draft)
• Experiment in the ease of workflow of mashing a
tool up
• Model: YouTube - “paste this HTML”
• Production: Fall 2008

All Rights Reserved. www.gvcsitemaker.com 22

IMS Learning Tools
Interoperability Demonstration
• IMS Learning Impact
• May 12-16, 2008, Austin, TX, USA
• http://www.imsglobal.org/


Thanks

• Wimba
• Microsoft
• Blackboard
• Icodeon
• Ucompass
• Pearson
• University of Michigan


IMS Developer Network

• My task is to develop the IMS Developer Network
• Improve “in-the-field” availability of standards-
compliant implementations
• Develop reusable bits / sample code / test code
• Work with and go-between developers
implementing IMS Specs in their products


IMS / Sakai
Google Summer of Code


General Idea

• Build many different implementations of IMS Tool
Interoperability
• Variations on a theme - think beyond just learning
management systems
• Try to create an initial body of work to make it worth
while to build tools using IMS Tool Interoperability


Proposed Project Ideas
•Sakai
•Chisimba
• Consumer
•Drupal
• Producer
•Moodle
•Google Android
• Consumer •Rails IMS TI Test Kit
• Producer • Consumer
•Atutor • Producer
•Elgg
•Proxied access

Consumer = LMS Producer = Tool


IMS / Sakai
Google Summer of Code
• An IMS LTI Producer for Sakai – Katherine
Edwards, McGill University
• An IMS LTI Producer for Moodle – Jordi
Piguillem Poch - Universitat Politècnica de
Catalunya
• Improving Sakai’s Presense Capability – Eli
Foley – Georgia Tech


Next Steps

• Work with IMS to develop legal structure for
developer network
• Continue work with LTI 2.0 to help define the
mission and approach – investigate LTI Alliance
• Broaden involvement to other efforts as
opportunities present themselves


IMS Developer Network

More Related Content

Similar to IMS Developer Network (20)

More from Charles Severance (20)

Recently uploaded (20)

IMS Developer Network

Editor's Notes