SIST EN 16425:2014

SLOVENSKI STANDARD
oSIST prEN 16425:2012
01-julij-2012
Vmesnik za enostavno publiciranje
Simple Publishing Interface
Schnittstelle für einfaches Publizieren
Interface de publication simple
Ta slovenski standard je istoveten z: prEN 16425
ICS:
35.240.30 Uporabniške rešitve IT v IT applications in information,
informatiki, dokumentiranju in documentation and
založništvu publishing
oSIST prEN 16425:2012 en,fr
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
oSIST prEN 16425:2012

---------------------- Page: 2 ----------------------
oSIST prEN 16425:2012


EUROPEAN STANDARD
DRAFT
prEN 16425
NORME EUROPÉENNE

EUROPÄISCHE NORM

April 2012
ICS 35.240.30; 35.240.99
English Version
Simple Publishing Interface
Interface de publication simple Schnittstelle für einfaches Publizieren (Simple Publishing
Interface - SPI)
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee CEN/TC 353.

If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations which
stipulate the conditions for giving this European Standard the status of a national standard without any alteration.

This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other language
made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland,
Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to
provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without notice and
shall not be referred to as a European Standard.


EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2012 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 16425:2012: E
worldwide for CEN national Members.

---------------------- Page: 3 ----------------------
oSIST prEN 16425:2012
prEN 16425:2012 (E)
Contents Page
Foreword .3
1 Introduction .4
2 Notations and conventions .4
3 Requirements and Design Principles .4
3.1 Syntactic versus semantic interoperability .5
3.2 “By reference” and “by value” publishing .6
3.3 Flexible application.6
3.4 Objectives .7
4 SPI Model .7
4.1 Submit a resource.8
4.1.1 Resource submission by value .8
4.1.2 Resource submission by reference . 11
4.2 Delete resource . 13
4.3 Submit metadata . 13
4.4 Delete metadata . 15
4.5 Errors . 15
4.5.1 Method not supported . 15
4.5.2 Invalid authorization token . 15
4.5.3 Package type not supported . 15
4.5.4 Content type not supported . 15
4.5.5 Deletion not allowed . 15
4.5.6 Invalid identifier . 15
4.5.7 Invalid source location . 16
4.5.8 Schema not supported . 16
4.5.9 Metadata validation failure . 16
4.5.10 Resource validation failure . 16
4.5.11 Resource not retrieved . 16
4.5.12 Overwriting not allowed . 16
4.5.13 Method failure . 16
4.6 SPI Target Configurations . 16
4.7 Authentication . 17
5 Conclusion . 18
6 References . 18

2

---------------------- Page: 4 ----------------------
oSIST prEN 16425:2012
prEN 16425:2012 (E)
Foreword
This document (prEN 16425:2012) has been prepared by Technical Committee CEN/TC 353 “Information and
Communication Technologies for Learning, Education and Training”, the secretariat of which is held by UNI.
This document is currently submitted to the CEN Enquiry.
This document contains the requirements for the Simple Publishing Interface (SPI), a protocol for storing
educational materials in a repository.
This protocol facilitates the transfer of metadata and content from tools that produce learning materials to
applications that persistently manage learning objects and metadata, but is also applicable to the publication
of a wider range of digital objects.
3

---------------------- Page: 5 ----------------------
oSIST prEN 16425:2012
prEN 16425:2012 (E)
1 Introduction
This document presents the Simple Publishing Interface (SPI), a protocol for publishing digital objects or their
metadata to repositories. This protocol is designed to facilitate the transfer of metadata and content from tools
that produce learning materials to applications that manage learning objects and metadata. It is also
applicable to the publication of a wider range of digital objects.
The objective is to develop a practical approach towards interoperability between repositories for learning and
applications that produce or consume educational materials. Examples of repositories for learning are
educational brokers, knowledge pools, institutional repositories, streaming video servers, etc. Applications
that produce these educational materials are for instance query and indexation tools, authoring tools,
presentation programs, content packagers, etc. The work will concentrate on the development of the simple
publishing interface (SPI), an interface for publishing digital materials into a repository. Whilst the
development of the SPI specification draws exclusively on examples from the education sector, it is
recognised that the underlying requirement to publish content and metadata into repositories crosses multiple
application domains.
The following section presents some important requirements for this work. Next, the SPI model enumerates
the different messages that are interchanged when publishing metadata and content. This model has been
designed such that it is interoperable with v1.3 Simple Web-service Offering Repository Deposit (SWORD)
profile [SWORD], Package Exchange Notification Services [PENS] and the publishing specification that was
developed in the ProLearn Network of Excellence [PROLEARN SPI]. The intent of this work is thus not to
create yet another specification but to create a model that can be bound to existing technologies.
2 Notations and conventions
The following terms are used to distinguish the requester from the system that publishes an entity (a metadata
instance or a learning object):
• A ‘source’ is a system that issues a publication request. Alternatively, this system can be labeled as
requester.
• A ‘target’ is a system to which publication requests are sent. This can be a repository component or a
middle layer component. Such a middle layer component can fulfill several tasks. It can generate and
attach metadata to a resource, disaggregate and publish more granular components or act for
instance as an adapter to a third party publishing API.
We refrained from using the terms ‘client’ and ‘server’ as they give a bias towards an interface that is only
applicable in client/server applications. Moreover, the scenarios in which the API is used also envisage a
source running on a server (e.g., publishing from within an LMS). Furthermore, in the remainder of this
document, the terms “resource”, “digital content”, “learning object” and “educational material” will be used
interchangeably.
3 Requirements and Design Principles
In this section, some of the requirements for a publishing application programming interface (API) are
identified. These requirements stem from different repository architectures where learning resources and
metadata instances have to be communicated across system boundaries. SPI enables applications to upload
learning resources or metadata to a repository. For example, Figure 1 illustrates how an authoring tool (e.g.,
OpenOffice) could use SPI to upload a resource directly into a repository. A Learning Management System
(LMS) (e.g., Moodle, Blackboard, etc.) could enable teachers to publish their materials transparently into a
repository. By doing so, materials are simultaneously made available to students and published into a
repository where they can be reused.
4

---------------------- Page: 6 ----------------------
oSIST prEN 16425:2012
prEN 16425:2012 (E)

Figure 1 — Example SPI architectures.
SPI is also meant to enable flexible architectures where a middleware component gathers learning resources
or metadata through an SPI interface (from authoring tools or harvesters), applies value adding operations on
these, and then stores them into a backend repository. Examples of such operations are disaggregation of
material into small reusable components, automatic generation of metadata, validation or translation services.

Figure 2 — AloCom architecture.
Such architecture has been implemented in the context of the AloCom project (Figure 2). [ALOCOM]. This
architecture contains a plugin for MS PowerPoint, a source that can publish to a middle layer application,
which is the target of this publishing operation. Next, the AloCom middleware disaggregates the material into
small reusable components such as diagrams, individual slides, etc. and automatically generates metadata for
each component. Each individual component is then published by the middleware component into a
specialized AloCom repository where individual components are available for reuse. The AloCom middleware
acts as a source and the AloCom repository as target.
Interoperability in both publishing steps is important. First, as several applications (not only MS PowerPoint)
require publishing access to the middle layer application, the publishing process from within end-user
applications needs standardization. Secondly, the middle layer application must be interoperable with other
repositories, to promote interchangeability of components.
3.1 Syntactic versus semantic interoperability
The design of the SPI API is based on the design principles of the simple query interface (SQI) [SQI]. We
have defined a simple set of commands that is extensible and flexible. By analogy with SQI, this protocol
makes a distinction between semantic and syntactic interoperability.
• Syntactic interoperability is the ability of applications to deal with the structure and format of data. For
instance, a language such as XML Schema Description (XSD) ensures the syntactic interoperability of
XML documents as it allows for the parsing and validation of these documents.
• Semantic interoperability refers to the ability of two parties to agree on the meaning of data or methods.
When exchanging data, semantic interoperability is achieved when data is interpreted the same way by
all the applications involved.
5

---------------------- Page: 7 ----------------------
oSIST prEN 16425:2012
prEN 16425:2012 (E)
This document tackles semantic interoperability for SPI. Without a binding (e.g., a REST binding) this
specification cannot be implemented. A binding for SPI will realise syntactic interoperability.
3.2 “By reference” and “by value” publishing
Traditionally, two approaches allow for passing data from a source to a target.
• “By value” publishing embeds a learning object, after encoding, into the message that is sent to a
target.
• “By reference” publishing embeds a reference (e.g., a URL) to a learning object to publish into the
message that is sent to a target. Note that this is different from publishing metadata in a referatory.
Publishing in a referatory involves publishing metadata that contains a reference to the learning
object. When publishing a learning object “by reference”, a reference to the learning object is used to
fetch the learning object. This reference is not added to the metadata instance that describes the
learning object but is used to retrieve the learning object before storing it internally.
“By value” publishing is useful for a standalone, desktop application that cannot be approached by a target in
“by reference” mode. 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 transferring learning
objects. Rather than imposing one of these approaches, the publish protocol will be designed to support both
of them.
3.3 Flexible application
Some of SPI design decisions were inspired by existing applications and practices within the e-learning
domain.
• A learning object referatory manages metadata that refer to learning objects stored on separate
systems. Repositories that do not manage learning objects should thus be able to support SPI.
• Some applications manage publishing learning objects without the metadata. For instance, PENS
enabled applications submit packages to a server without metadata. [PENS]
• Finally, SPI must allow for publishing to repositories that manage both learning objects and metadata.
The MACE architecture for metadata enrichment [MACE] features different content providers that offer their
metadata through an OAI-PMH target [OAI-PMH]. A general purpose harvester like the ARIADNE harvester
is an example of a component that feeds metadata to a metadata referatory. Standardising the publishing
between the harvester and the metadata repository makes these components interchangeable.
6

---------------------- Page: 8 ----------------------
oSIST prEN 16425:2012
prEN 16425:2012 (E)

Figure 3 — The MACE harvesting architecture.
3.4 Objectives
This publishing protocol meets the following objectives:
• SPI enables integrating publishing into authoring environments. This is beneficial for the author
workflow, as they do not need to manually upload their learning objects using external publishing
applications.
• SPI provides interoperability between applications that publish and applications that manage learning
objects and metadata. Doing so, the effort of integrating publishing access into an authoring
application can be reused on other learning object repositories, provided that they support SPI.
4 SPI Model
The model for SPI that is introduced in this section builds on a separation between data and metadata. The
SPI model defines several classes of messages and functional units in a publishing architecture. When
binding the specification to a given technology, these concepts are mapped into a concrete specification that
can be implemented in a repository and for which conformance can be tested. All messages that are defined
by the SPI model contain mandatory (M) and optional (O) elements. Mandatory means that a binding cannot
relax this condition. A binding MUST implement a mandatory attribute and MUST make it mandatory as well.
A binding can deal with optional elements in three ways. It can opt not to include the element, it can include
the element and make it optional, or it can include the element and make it mandatory. A binding might for
instance choose to not support transporting the filename attribute, or an SPI binding can offer support for the
filename attribute while still allowing the source to provide a null value for this element. Depending on the
choices made when implementing an SPI target, the latter can be configured in different ways and sources
must know the exact configuration of a target in order to be able to use it. As a consequence, the
configuration of an SPI target must be exposed to sources using at least one of the strategies presented in
Section 4.6.
As shown by the class diagram of Figure 4, with SPI, a resource MUST have an identifier (that can either be
generated by a target or a source). In addition, the resource MAY have a filename associated. Every
resource can be described by zero, one, or more metadata instances. A metadata instance MUST have a
metadata identifier that identifies the metadata instance itself and MUST have a resource identifier that is
equal to the identifier of the resource. The metadata identifier (that can be either generated by the source or
the target) enables distinguishing between multiple metadata instances referring to the same resource.
7

---------------------- Page: 9 ----------------------
oSIST prEN 16425:2012
prEN 16425:2012 (E)

Figure 4 — Resource and metadata instance.
In this model, a metadata instance MUST be connected to a resource. However the resource MAY be hosted
externally. In such a case, ingesting the resource is not part of the publishing scenario. For instance, when
applying SPI to a referatory, only the messages described in section “Submit metadata” are implemented.
Alternatively, resources can be published without metadata. In this scenario, only the messages described in
section “Submit a resource” are used. As an example, a single resource can be published to a repository.
This scenario also includes the example of a file that consists of both data and metadata packaged in one
content package.
Furthermore, this model also deals with a situation where multiple metadata instances describe the same
resource.
The SPI model does not include explicit methods for updating resources or metadata instances. However,
both metadata and resources can be deleted. Submitting an entity with an identifier that already exists in the
target SHOULD be treated in one of the following ways by the target:
• The target overwrites the entity.
• The target creates a new version of the entity if it supports versioning.
• The target refuses to upda
...