Technical look at Sled Player

1
Technical look at Sled Player

• Alex Little
• a.little_at_open.ac.uk
• Institute of Educational Technology
• Open University (UK)

2
Introduction

• 2 JISC funded projects running April 05 Nov 05
• Toolkit new developments to Sled Player
• Demonstrator demonstrating (!) Learning Design
  using the Sled Player
• Collaboration between the Open University (OUUK)
  and Open University Netherlands (OUNL)
• Im focusing on the Toolkit project

3
What were trying to do

• 2 main objectives
• Integrate other services into LD (e.g. QTI,
  forums, search, ePortfolio) and create generic
  way this could be extended for any other service
• Make it as easy as possible to switch between
  service providers

4
LD/QTI integration

• We have finished the LD QTI integration, so can
  now incorporate QTI xml into LD units of
  learning.
• We are currently using the APIS QTI engine, but
  different QTI engines could be used.

5
LD/QTI integration How does it work?
6
Changing service providers

• Were assuming the each type of service has a
  generic set of functions (so create a generic
  java class for each service which the player and
  LD engine can interact with)
• Each specific instance of a service provider has
  a sub class which implement the required methods
• A configuration file for the LD player then
  specifies which implementation of the generic
  class is used
• Slightly different angle to Sakai approach they
  are adapting the applications themselves to fit
  the OSID whereas we are leaving applications
  as-is and coding the connection only.

7
Pros of this approach

• Very easy to switch service providers (single
  value change in xml file)
• No programming involved to switch and different
  instances of CopperCore and Sled player can
  connect to different combinations of service
  providers
• Non generic functions can be accommodated - but
  by doing this you would be creating a customised
  installation, which may be harder to maintain in
  the long run.

8
Cons of this approach

• Only very easy to switch if the specific class
  for the service provider has already been created
  (by someone) otherwise youd need to write the
  class yourself
• Very difficult to get agreement on what the
  generic functions should/would be at the moment
  were making a best guess
• Even having a formal spec for the service may not
  give the agreement for the generic functions (as
  Ill now explain..!)

9
Connecting to ePortfolio

• Were just starting the process of applying the
  same method to LD ePortfolio integration as we
  have done with LD QTI
• Come up against 2 problems
• Havent yet got an ePortfolio tool with
  webservice, java or other API (not a big
  problem!)
• ePortfolio is a different type of IMS spec

10
How is ePortfolio different to QTI spec?

• Can take a QTI XML and put it in LD package as
  its not specific to a particular person
• Cant do this with ePortfolio, as the ePortfolio
  XML is specific to an individual
• ePortfolio specifies how individuals data is
  stored, not how it gets there
• Therefore need a language so the LD author can
  add an activity in LD that says at this point do
  x with your ePortfolio (could be upload a file
  or add reflection etc)
• So for us to integrate ePortfolio we need to
  create this language

11
Where next?

• The problem we encountered with integrating
  ePortfolio is likely to be replicated when
  integrating other services (with or without
  specs!)
• In terms of this project were not expecting to
  create the whole language just a small
  subsection to demonstrate one way it could be done

12
The end!

• Useful links
• Sled project http//sled.open.ac.uk/
• CopperCore http//www.coppercore.org
• Development blog http//iet.open.ac.uk/pp/a.littl
  e/index.cfm?pageLDdiary