1. Versioning of Learning Objects Christopher Brooks, John Cooke, Julita Vassileva Advanced Research in Intelligent Educational Systems (ARIES) Laboratory Computer Science Department University of Saskatchewan Saskatoon, SK, Canada

2. 2 Motivation: Nature of Learning Objects Free to use and modify –“open source” (creative commons license, writings of Stephen Downes) Distributed both in use and storage –POOL, POND, SPLASH, Edutella, etc Customized for a particular audience, with common backgrounds and goals –Localized versions of learning objects (CanCore, Le@rning Federation Profile, etc) David Wiley’s reusability paradox –“the more reusable a learning object is, the harder its use is to automate [combination and delivery]”

3. 3 Motivation: Lecture Learning Objects Consider anecdotal evidence about lecture notes: –Shared between lecturers for no cost –Modified to fit the presentation style of the new lecturer –Modified to contain different content based on course goals e.g. examples in Java instead of C for an introductory computer science course

4. 4 Approach: Authoring Learning Objects These observations suggest that it is important to support the authoring and editing of learning objects –Automated reusability is highly complex for both a content management system and for learning object authors

5. 5 Approach: Versioning the act of recording the evolution of software artifacts –Well studied: Software Configuration Management, Hypermedia, Knowledge Representation Some important aspects of versioning for LOs: –Learning objects are considered immutable, changes just create new versions –Older learning objects can be retrieved and versioned again, creating revision trees –Versions are often meant to coexist with one another (variants)

6. 6 Approach: What to capture Two kinds of versioning need to be captured: –Semantics: How has the meaning of this learning object changed with respect to the one it was derived from? –Syntax: How can I retrieve and display a previous version of this learning object? Three pieces of a learning object need to be versioned: –The content –The display style –The metadata

7. 7 Approach: Problems with Current MD Current metadata specifications tend to focus on human readable values instead of machine readable values Further, they don’t capture how the learning object has changed LOM –Relation: Identifies whether the version is a variant or revision –Version: Identifies a human readable tag –Status: One of draft, final, revised, unavailable

8. 8 Approach: Metadata Model at a Glance IEEE LOM compliant –Does not duplicate or redefine elements that already exist Content changes (deltas) are stored as a tuple –The kind of change, which identifies (programmatically) how a value can be applied to reproduce the change E.g. XML:NodeAdded or ASCII:CharactersInserted –The value of the change E.g. Object databases are also known…

9. 9 Approach: Metadata Model at a Glance Semantics related to the change are also captured –The perspective of the change, which identifies which metadata key is effected by the change Encoded as a path through a metadata tree E.g. “LOMv1.0:General:Coverage” E.g. “DC:Coverage” –The nature of the change, from a predefined vocabulary (machine understandable) Subset, superset, equivalent, etc.

10. 10 Approach: Implementation Very little work has been done on syntactic interoperability of a learning object –authoring environments extremely diverse –E.g. Word, PowerPoint, Photoshop, Notepad, etc. We define a subset of XHTML to be used to mark up content –Allows for easily refactoring most existing learning objects We provide a vocabulary for content change based around the DOM The history of a LO can be viewed by applying XSLT

11. 11 Conclusions The LOM is insufficient for capturing version changes in learning objects We have proposed a model that can capture both the syntax of a change as well as the semantics associated with that change While this model is LO format neutral, it is being applied to lecture based learning objects using a subset of XHTML

12. 12 Questions? Contact information: http://www.cs.usask.ca/research/research_groups/aries/ Christopher Brooks: cab938@mail.usask.ca www.cs.usask.ca/~cab938 John Cooke cooke@cs.usask.ca www.cs.usask.ca/~cooke Julita Vasseliva jiv@cs.usask.ca www.cs.usask.ca/~jiv

13. 13 Why not use CVS? CVS, and most other software versioning environments are: –Centralized Source code is usually shared amongst a small community Learning objects are meant to be distributed to a large community –Agent unfriendly Semantics are not stored in a machine readable format Workflow (searching) of learning objects not supported by CVS Decentralized CVS variants? –tend to decentralize artifact storage only, and still have centralized metadata catalogues