BS EN 16425-2014 Simple Publishing Interface《简单的发布接口》.pdf

1、BSI Standards PublicationBS EN 16425:2014Simple Publishing InterfaceBS EN 16425:2014 BRITISH STANDARDNational forewordThis British Standard is the UK implementation of EN 16425:2014.The UK participation in its preparation was entrusted to TechnicalCommittee IST/43, Information technology for learnin

2、g, educationand training.A list of organizations represented on this committee can beobtained on request to its secretary.This publication does not purport to include all the necessaryprovisions of a contract. Users are responsible for its correctapplication. The British Standards Institution 2014.

3、Published by BSI StandardsLimited 2014ISBN 978 0 580 78346 3ICS 35.240.30; 35.240.99Compliance with a British Standard cannot confer immunity fromlegal obligations.This British Standard was published under the authority of theStandards Policy and Strategy Committee on 31 July 2014.Amendments issued

4、since publicationDate Text affectedBS EN 16425:2014EUROPEAN STANDARD NORME EUROPENNE EUROPISCHE NORM EN 16425 July 2014 ICS 35.240.30; 35.240.99 English Version Simple Publishing Interface Interface de publication simple Schnittstelle fr einfaches Publizieren (Simple Publishing Interface - SPI) This

5、 European Standard was approved by CEN on 22 May 2014. 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. Up-to-date lists and bibliographical references

6、concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN member. This European Standard exists in three official versions (English, French, German). A version in any other language made by translation under the responsibility of a CEN membe

7、r 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, Former Yugoslav Republic of Macedonia, Fran

8、ce, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom. EUROPEAN COMMITTEE FOR STANDARDIZATION COMIT EUROPEN DE NORMALISATION EUROPISCHES KO

9、MITEE FR NORMUNG CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels 2014 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. EN 16425:2014 EBS EN 16425:2014EN 16425:2014 (E) 2 Contents Page Foreword 3 1 Scope 4 2 Terms and d

10、efinitions .4 3 Requirements and design principles .5 3.1 General 5 3.2 Syntactic versus semantic interoperability 6 3.3 “By reference” and “by value” publishing 6 3.4 Flexible application6 3.5 Objectives .7 4 SPI Model 7 4.1 General 7 4.2 Submit a resource8 4.2.1 General 8 4.2.2 Resource submission

11、 by value 9 4.2.3 Resource submission by reference 10 4.3 Delete resource . 12 4.4 Submit metadata . 12 4.5 Delete metadata 14 4.6 Errors . 14 4.6.1 General . 14 4.6.1.1 Introduction . 14 4.6.1.2 Method not supported 14 4.6.1.3 Invalid authorization token . 14 4.6.1.4 Package type not supported 14 4

12、.6.1.5 Content type not supported . 14 4.6.1.6 Deletion not allowed . 15 4.6.1.7 Invalid identifier . 15 4.6.1.8 Invalid source location . 15 4.6.1.9 Schema not supported . 15 4.6.1.10 Metadata validation failure . 15 4.6.1.11 Resource validation failure 15 4.6.1.12 Resource not retrieved . 15 4.6.1

13、.13 Overwriting not allowed . 15 4.6.1.14 Method failure 15 4.7 SPI target configurations . 15 4.8 Authentication . 16 5 Conclusion 17 Bibliography . 18 BS EN 16425:2014EN 16425:2014 (E) 3 Foreword This document (EN 16425:2014) has been prepared by Technical Committee CEN/TC 353 “Information and Com

14、munication Technologies for Learning, Education and Training”, the secretariat of which is held by UNI. This European Standard shall be given the status of a national standard, either by publication of an identical text or by endorsement, at the latest by January 2015, and conflicting national stand

15、ards shall be withdrawn at the latest by January 2015. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CEN and/or CENELEC shall not be held responsible for identifying any or all such patent rights. This document contains the requ

16、irements 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 a

17、lso applicable to the publication of a wider range of digital objects. According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmar

18、k, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom. BS EN 16425:2014

19、EN 16425:2014 (E) 4 1 Scope This European Standard specifies the Simple Publishing Interface (SPI), an abstract protocol for publishing digital content and/or the metadata that describes it into repositories in a way that preserves the references between the two. This protocol is designed to facilit

20、ate the transfer of learning materials 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 objectives behind SPI are to develop practical approaches towards interoperab

21、ility between repositories for learning and applications that produce or consume educational materials. Examples of repositories for learning include educational brokers, knowledge pools, institutional repositories, streaming video servers, etc. Examples of applications that produce these educationa

22、l materials are query and indexation tools, authoring tools, presentation programs, content packagers, etc. 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 r

23、epositories crosses multiple application domains. This abstract model has been designed to be implemented using existing specifications such as v1.3 Simple Web-service Offering Repository Deposit (SWORD) profile SWORD, Package Exchange Notification Services PENS and the publishing specification that

24、 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 in order to make sure that these technologies are used in a way that takes into account requirem

25、ents specific to the learning domain, where it is necessary to publish both content and metadata that references it in a way that preserves these references. The SPI model enumerates the different messages that are interchanged when publishing metadata and content. 2 Terms and definitions For the pu

26、rposes of this document, the following terms and definitions apply and are used to distinguish the requester from the system that publishes an entity (a metadata instance or a learning object): 2.1 source system that issues a publication request. Alternatively, this system can be labelled as request

27、er 2.2 target system to which publication requests are sent. This can be a repository component or a middle layer component. Such a middle layer component can fulfil several tasks. It can generate and attach metadata to a resource, disaggregate and publish more granular components or act for instanc

28、e as an adapter to a third party publishing API (application programming interface) NOTE The terms “client” and “server” have not been used in order to avoid any bias towards an interface that is only applicable in client/server applications. Moreover, the scenarios in which the API is used also env

29、isage a source running on a server (e.g., publishing from within an LMS). In the remainder of this document, the terms “resource”, “digital content”, “learning object” and “educational material” are used interchangeably. BS EN 16425:2014EN 16425:2014 (E) 5 3 Requirements and design principles 3.1 Ge

30、neral In this clause, some of the requirements for a publishing API are identified. These requirements stem from different repository architectures where learning resources and metadata instances need to be communicated across system boundaries. SPI enables applications to upload learning resources

31、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) could enable teachers to publish their materials transparently into a r

32、epository. By doing so, materials are simultaneously made available to students and published into a repository where they can be reused. Figure 1 Example SPI architectures SPI also enables flexible architectures where a middleware component gathers learning resources or metadata through an SPI inte

33、rface (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 and validation or translation services. Fi

34、gure 2 AloCom architecture Such architecture has been implemented in the context of the AloCom project (Figure 2). ALOCOM. This architecture contains a plug-in for MS PowerPoint, a source that can publish to a middle layer application, which is the target of this publishing operation. Next, the AloC

35、om 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 specialised AloCom repository where individual com

36、ponents 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 proce

37、ss from within end-user BS EN 16425:2014EN 16425:2014 (E) 6 applications needs standardization. Secondly, the middle layer application shall be interoperable with other repositories, to promote interchangeability of components. 3.2 Syntactic versus semantic interoperability The design of the SPI API

38、 is based on the design principles of the simple query interface (SQI) SQI. As such a simple set of commands that is extensible and flexible have been defined. By analogy with SQI, this protocol makes the following distinction between semantic and syntactic interoperability: syntactic interoperabili

39、ty 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 t

40、he ability of two parties to agree on the meaning of data or methods. When exchanging data, semantic interoperability is achieved when data are interpreted the same way by all the applications involved. This European Standard tackles semantic interoperability for SPI. Without a binding (e.g., a REST

41、 binding) this specification cannot be implemented. A binding for SPI will realise syntactic interoperability. 3.3 “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,

42、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. This is different from publishing metadata in a referatory. Publishing in a referatory involves publishing metadata that co

43、ntains 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 be

44、fore 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 referenc

45、e” publishing is particularly suited when larger amounts of data need 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 the

46、se approaches, the publish protocol will be designed to support both of them. 3.4 Flexible application Some aspects of the SPI design follow existing applications and practices within the e-learning domain: a learning object referatory manages metadata that refer to learning objects stored on separa

47、te 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; SPI allows for publishing to reposito

48、ries 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 met

49、adata to a metadata referatory. Standardizing the publishing between the harvester and the metadata repository makes these components interchangeable. BS EN 16425:2014EN 16425:2014 (E) 7 Figure 3 The MACE harvesting architecture 3.5 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