SPI

Contents 1 Introduction 2 Materials available 3 Requirements Analysis 3.1 By reference versus by value publishing of learning objects 3.2 By reference versus versus by value publishing of metadata 3.3 Synchronisation of metadata versus publishing of metadata 3.4 Publishing complete metadata instances versus issuing partial updates 3.5 Transaction processing 3.6 Abstract versus Concrete model 4 Forthcoming Meetings 5 Past Meetings 6 Bibliography

Introduction

This initiative is an open, collaborative effort, under the auspices of the CEN/ISSS Learning Technologies Workshop, to achieve interoperability between learning object repositories. A Yahoo Group has been set up at http://tech.groups.yahoo.com/group/publishinterop/ to support e-mail-based collaboration (Feel free to join - instructions are available on the site!). This Wiki documents the current status.

Materials available

• An initial version of SPI that has been developed in the prolearn project: Prolearn SPI Deliverable
• The final CWA has been published in March 2010. This document builds on both the prolearn version of SPI and integrates work done in SWORD and the Atom Publishing Protocol (APP).

Requirements Analysis

By reference versus by value publishing of learning objects

When publishing learning objects, a resource is transferred from a source to a target. The following does not apply for referatories as these only manage metadata. Traditionally, two approaches allow for passing data from a source to a target.

1. By value publishing embeds a learning object, after encoding, into the message that is sent to a target. This behaviour can be compared to adding an attachment to an e-mail message.
2. By reference publishing embeds a reference (e.g. a URL) to a learning object into the message that is sent to a target. When a target receives this reference from a source, it must retrieve the resource and store it in the repository to complete the publishing of the resource. Comparing this to e-mail traffic, this scenario is similar to sending a message that contains a URL reference to an external web page, rather than adding the page as an attachment.

By value publishing is useful for a standalone application, which is generally not associated with a web server on which a target can obtain a learning object. In this case, embedding a learning object in a message passed to the target lowers the threshold for pushing a learning object. By reference publishing is particularly suited when larger amounts of data have to be published. As embedding large files into a single message may cause degraded performance, a need exists to use a distinct method (e.g., FTP, HTTP, SCP, etc.) for uploading learning objects. Rather than imposing one of these approaches, the publish protocol will be designed to support both of them.

By reference versus versus by value publishing of metadata

When publishing metadata, a metadata instance can be transferred to the resource in a similar manner. One can embed a reference that points to the metadata instance (by reference) or one can attach the metadata instance as a whole.

To discuss: do we need this functionality or not?

Synchronisation of metadata versus publishing of metadata

Synchronisation enables repositories to maintain and manage copies of their metadata.

1. With a harvesting protocol like OAI-PMH, a repository can synchronise metadata with another repository by pulling metadata from that repository.
2. A repository can also push its metadata to another repository.

With publishing of metadata, we target scenarios where a new metadata instance is submitted by a client (e.g. authoring tool, metadata indexation tool, LMS, etc) to a repository. This also involves altering and updating existing metadata instances.

To discuss: SPI will not overlap with OAI-PMH. That is, SPI will enable not pulling metadata instances from a repository.

Publishing complete metadata instances versus issuing partial updates

Metadata instances usually aggregate multiple metadata fields and associated values. With respect to publishing metadata, one can consider both scenarios where either (single) metadata values or (complete) metadata instances are published.

Publishing a complete metadata instance is illustrated below:

MD1 = "<lom ...><general><title><string>A title<string></title></general>...</lom>"
publishMD(user1, id1, MD1)

When a metadata instance is altered, this happens as follows:

String newInstance = alterOldInstance(mdInstance); rePublish(id1, mdInstance )

The semantics of this operation are that the old instance is overwritten. The target can (but is not obliged) to organise version control and maintain a copy of the old instance.

Publish (or alter) a single metadata field. Altering a single metadata field can be done as follows:

updateMD(user1, id1, lom.general.title.en, "a new title");

To discuss: Do we want to consider both kinds of scenarios?

Transaction processing

Consider the following instance based scenario.

MD1 = retrieveMetadata(user1, id1)
MD2 = retrieveMetadata(user2, id1)
MD1' = alterMetadata(user1, MD1) //e.g. add a title
MD1' ' = alterMetadata(user2, MD1) //e.g. add a geographic location
updatemetadata(user2, id1, MD1' ')
updatemetadata(user1, id1, MD1')

In this scenario, the second update overwrites the first update (adding a geographic location). Do we need to prevent these and similar scenarios?

For instance:

1. Do we allow a user to lock a metadata instance.
2. Or will we enable editing at a lower level. E.g. user changes title, but not the rest of the document. This however let's the problem persist at a lower level.
3. Use transaction ID's.
4. Any other solutions?

Abstract versus Concrete model

Create an abstract metamodel of the specification that allows for bindings using different technologies (e.g. SOAP, REST, JMS, ...). Provide a binding in at least one technology.

Forthcoming Meetings

• 2009-03-02, SPI workshop, Vigo, Spain
• 2009-04-27: CEN/ISSS WS-LT meeting, Berlin, Germany

Past Meetings

• 2008-06-27, CEN/ISSS WSLT meeting, Lyon, France

Bibliography

• Ternier, S., Massart, D., Van Assche, F., Smith, N., Simon, B. & Duval, E. (2008). A Simple Publishing Interface For Learning Object Repositories. In Proceedings of World Conference on Educational Multimedia, Hypermedia and Telecommunications 2008 (pp. 1840-1845). Chesapeake, VA: AACE.