The JISC IE: shared, global or common services?

UKOLN is supported by: The JISC IE: shared, global or common services? JISC Common Services Integration Meeting – 27 October 2004 Andy Powell, UKOLN, University of Bath [email_address] www.bath.ac.uk A centre of expertise in digital information management www.ukoln.ac.uk

JISC IE diagram JISC-funded content providers institutional content providers external content providers brokers aggregators catalogues indexes institutional portals subject portals learning management systems media-specific portals end-user desktop/browser presentation fusion provision OpenURL resolvers shared infrastructure authentication/authorisation (Athens) institutional profiling services terminology services service registries resolvers metadata schema registries

JISC IE Architecture

presents a view of the world in terms of 'service components‘

fairly significant chunks of functionality offered thru network services (e.g. a portal, a repository, etc.)

loosely-coupled, semi-monolithic applications

structured and unstructured network services – i.e, machine–oriented and human-oriented Web interface

Danger of mismatch between… JISC-funded content providers institutional content providers external content providers brokers aggregators catalogues indexes institutional portals subject portals learning management systems media-specific portals end-user desktop/browser presentation fusion provision OpenURL resolvers shared infrastructure authentication/authorisation (Athens) JISC IE service registry institutional preferences services terminology services user preferences services resolvers metadata schema registries What the architecture says…

…and reality! end-user desktop/browser … what the end-user sees :-(

JISC IE scope (function)

“resource discovery”

D2D (discovery to delivery)

functional model (UML)

discover, access, use

survey, discover, detail, access, use

discover = search, browse and/or alert

in today’s terminology “metasearch” and “context sensitive linking”

cross-searching multiple collections/targets

linking to most appropriate copy

IE Standards Framework

The JISC IE standards framework lays out a set of interfaces (the protocols and standards) that these service components use to talk to each other in m2m ways for the purpose of supporting 'resource discovery'.

JISC IE technologies

cross-searching

Z39.50 (Bath Profile) and SRW/SRU

harvesting

OAI-PMH

link resolution

OpenURL 1.0

alerting (news-feeds and related stuff)

RDF Site Summary (RSS) 1.0

metadata

DC (largely simple DC) and LOM (UK LOM Core)

shared infrastructural services

SOAP (or REST)

E-Learning Framework

provides a set of lower-level, functional components/APIs (the ELF services)

much broader in functional scope than the IE

can think of these as the building blocks that can be used to create larger ‘service components’

and/or that are used to offer interfaces (APIs) between one service component and another

ELF IE

the ELF and the IE meet when the API used to deliver an ELF service is the same as the standard/protocol specified in the IE standards framework

can enumerate the sub-set of ELF services that are used as building blocks for the current set of JISC IE service components

Alert, Authentication, Authorisation, Content Management, DRM, Federated Search, Format Conversion, Harvesting, Identifier, Metadata Management, Metadata Schema Registry, Packaging, Rating / Annotation, Resolver, Search, Service Registry, Terminology, User Preferences

Shared vs. common services

IE “shared” infrastructural service components…

service components that support the functionality of other IE service components

where it makes sense to ‘share’ the delivery of that functionality

shown as single ‘boxes’ on the IE architecture diagram – but may be distributed

ELF “common” services…

the building blocks and/or interfaces that are common to many service components

Shared infrastructural service It doesn’t make much sense for lots of libraries to deliver a Dewey terminology service. Better for OCLC to deliver as a “shared” infrastructural service… JISC-funded content providers institutional content providers external content providers brokers aggregators catalogues indexes institutional portals subject portals learning management systems media-specific portals end-user desktop/browser presentation fusion provision OpenURL resolvers shared infrastructure authentication/authorisation (Athens) institutional profiling services terminology services service registries resolvers metadata schema registries

Common service Many service components will offer a search interface. Therefore, “search” is an example of a “common” service… JISC-funded content providers institutional content providers external content providers brokers aggregators catalogues indexes institutional portals subject portals learning management systems media-specific portals end-user desktop/browser presentation fusion provision OpenURL resolvers shared infrastructure authentication/authorisation (Athens) institutional profiling services terminology services service registries resolvers metadata schema registries

Shared, global or common?

yes!

“shared” as in “shared infrastructure”…

“common” as in making use of common APIs

“global” as in…

services offered from within JISC IE to external parties (e.g. requests to host external service registries within IESR)

services offered from outside JISC IE to IE parties (e.g. OCLC Dewey auto-classification service, purl.org, DCMI metadata registry, handle.net, DOI, …)