The OASIS interoperability standards body have recently released the Content Management Interoperability Services specification (CMIS) 1.0. Why are we interested? Well, though it is aimed at content management services, the distinction between an enterprise content management service, a repository and a virtual learning environment is somewhat superficial: a quick look at CMIS will show that the services involved are applicable to both repositories of educational content and VLEs.
From the specification abstract:
The Content Management Interoperability Services (CMIS) standard defines a domain model and Web Services and Restful AtomPub bindings that can be used by applications to work with one or more Content Management repositories/systems.
The domain model conceptualizes CMIS as providing “an interface for an application to access a Repository. To do so, CMIS specifies a core data model that defines the persistent information entities that are managed by the repository”. Transient state information, event information, workflows, user administration are not modelled where these are considered internal to the working of a specific CMS. The data model does define the following entities: repositories (which manage objects), document objects (stand-alone information assets), folder objects (hierarchical collections of objects), relationship objects, policy objects, access control, versioning, query (based on a subset of SQL) and a change log.
A large number of services are defined relating to these objects, but these are pretty much what one would expect: getRepositories returns a list of repositories in the system, getRepositoryInfo returns information about a specified repository; getObject and getProperties do similar for objects; navigation is facilitated by a range of services such as getFolderTree, getObjectParents, getChildren which relate to folders and relationships. There are also services for creating, moving and deleting objects or adding them to folders. Core content management is catered for by services for checking objects in and out, retrieving versions of an object and applying policies.
There is a RESTful binding for these services using ATOM feeds, AtomPub, and the underlying HTTP GET, PUT and DELETE methods. There is also a Web Services / WSDL binding, which references WS-I, WS-SECURITY and SOAP. To conform to CMIS, clients must implement either the REST or the Web Service binding, repositories however must implement both.
It will be interesting to see what influence CMIS has on the education sector, e.g. whether there is any uptake of parts of it by VLE vendors or repositories used by the sector. I say “parts of it” because the core spec is a 200+ page document, which in turn references several others, especially for the binding. One can imagine the reaction when it lands on the desk of a developer for one of our niche repositories or VLEs, commercial or open source, especially when they learn that they have to do both REST and WS bindings. Aside from full-on or partial implementations it does give us a further point of comparison for interoperability specs in the education domain to check that we remain in line with the wider world; for example how does CMIS’s use of ATOMPub compare with SWORD and SPI, and how the use of SQL for query contrasts with those standards which come more from the library domain (e.g. CQL in SRU).