IMS Digital Repositories Interoperability

1. IMS Digital Repositories Interoperability Andy Powell a.powell@ukoln.ac.uk UKOLN, University of Bath COLIS Meeting, London February 2003

2. IMS DRI Specifications • IMS Digital Repositories Interoperability • define protocols for interoperability between systems • machine2machine (i.e. how software components talk to each other over the network) • how data (and metadata) is transferred • (note that other IMS spec’s tend to focus on data formats rather than data transfer)

3. IMS DRI service components • IMS DRI splits services into three broad classes… • access services (resource utilizers) • services with which the end-user interacts • LMS/VLE, portal, … • provision services (repositories) • services that make content available • intermediaries (brokers, aggregators) • services that sit between the other two note that IMS uses Learning Management System (LMS) rather than VLE (and I think we should too!)

4. IMS DRI repositories • splits repositories into two broad classes… • learning object repositories (LOR) • e.g. JORUM+ • resources described using IMS metadata • resources packages using IMS CP • ‘information’ repositories • library OPACs, museum databases, image archives, RDN subject gateways, … • resources typically described using non-IMS metadata (DC, MARC, …)

5. Summary… • interoperability between VLE and repositories • repositories of information objects • learning object repositories (LOR) • ‘metadata only’ and ‘metadata and full-content’ repositories • integration of VLE with backend LOR • seamless access to information resources from within VLE

6. IMS DRI on paper • three-part specification (version 1.0)… • IMS Digital Repositories Interoperability - Core Functions Information Model • IMS Digital Repositories Interoperability - Core Functions XML Binding • IMS Digital Repositories Interoperability - Core Functions Best Practice Guide • http://www.imsproject.org/

7. AUDIT RESOLVE Creator Infoseeker Agent Learner Resource Utilizers NEGOTIATE TRADE DISCOVER USE ACCESS MANAGE RIGHTS OBLIGATIONS Presentation (Query, Browse, Follow Path) SEARCH GATHER REQUEST Access Management Procurement Mediation PUBLISH ALERT Repositories STORE STORE MANAGE MANAGE EXPOSE EXPOSE CONTROL ACCESS Provision STORE MANAGE EXPOSE DELIVER Metadata Assets MAKE PAYMENT AUTHENTICATE AUTHORISE Directories Registries People Repositories Metadata Vocabulary Organizations Traders Competency IMS Digital Repositories

8. End-user functionality • end-user is learner, creator, info seeker or agent • users need to • ‘discover’, • ‘access’ • and ‘use’ resources • ‘discover’ achieved by • ‘query’ (initiating a search) across one or more repositories • ‘browse’ across one or more repositories • ‘follow path’ (e.g. via Learning Design spec)

9. System functionality • access services need to support • search, gather, alert (for discover) • request (for access) • publish (for use) • provision services need to support • expose (for discover) • deliver (for access) • store (for use) • manage

10. Search/Expose • 2 protocols supported… • XQuery over SOAP (for learning object repositories) • Z39.50 (for information repositories) • both return IMS metadata records • ‘IMS’ Z39.50 profile under development • set of ‘search’ attributes based on IMS metadata • IMS metadata record syntax (XML)

11. Gather/Expose • OAI Protocol for Metadata Harvesting (OAI-PMH) • supports regular gathering of some or all metadata records from a repository • carries simple DC records (mandated by OAI) and IMS metadata • or any metadata format encoded in XML/XML Schema • need to agree details for how to carry IMS records in OAI-PMH

12. Alert/Expose • no recommendations currently • considering use of RSS… • Rich Site Summary • RDF Site Summary • …but concerns about conflicts between versions 0.9, 1.0 and 2.0

13. Request/Deliver • HTTP (and FTP) • use of DOIs and PURLs for persistent naming • use of OpenURLs to resolve to ‘appropriate copy’ of information (bibliographic) resources

14. Publish/Store • FTP • to upload IMS content packages to Learning Object Repositories

15. Why is IMS DRI important? • VLE (in some shape or form) likely to become one of key ‘presentation’ services in institutional context • IMS DRI spec’s fill space between ‘information providers’ and VLEs • information providers need to think about exposing stuff in the context of ‘e-learning’ systems • VLE-vendors relatively mainstream • pushes digital library technologies to new and wider audience

16. JISC Information Env. Content providers Provisionlayer Shared services Authentication Fusionlayer Authorisation Broker/Aggregator Broker/Aggregator Service Registry Portal Portal Portal Presentationlayer Resolver Inst’n Profile End-user 16

17. JISC IE tech summary • discover, access, use • content providers, brokers/aggregators, presentation services (portals) • searching, harvesting, alerting • Z39.50 (Bath Profile), OAI, RSS are key ‘discovery’ technologies... • … and by implication, XML and simple/unqualified Dublin Core • recognition that SOAP will become more important (e.g. SRW) • access to resources via OpenURL and resolvers where appropriate

18. IMS DRI XQuery/SOAP Z39.50 (IMS) OAI-PMH OpenURL IMS metadata DOI/PURL FTP (publishing) UDDI? JISC IE (SRW/SOAP) Z39.50 (Bath Profile) OAI-PMH RSS OpenURL simple DC UDDI? IMS DRI vs. JISC IE UKCMF

19. Questions…