Technical%20overview%20of%20the%20JISC%20Information%20Environment

1
Technical overview of the JISC Information
Environment

• Andy Powell
• a.powell_at_ukoln.ac.uk
• UKOLN, University of Bath
• Presentation to staff at IOPP
• September 2002

2
Contents

• summary of the technical architecture of the UK
  JISC Information Environment (DNER)
• Impact on content providers like IOPP
• Web services
• trends in portal developments
• impact on development of digital library services
• not very in depth

3
Simple scenario

• consider a lecturer searching for materials for a
  course module covering the development of
  business in China
• the aim is to construct a hybrid reading list
  that can be given to students to support their
  coursework
• he or she searches for business china using
• the RDN, to discover Internet resources
• ZETOC, to discover recent journal articles

4
(No Transcript)
5
(No Transcript)
6
(No Transcript)
7
(No Transcript)
8
Issues

• different user interfaces
• look-and-feel
• subject classification, metadata usage
• everything is HTML human-oriented
• difficult to merge results, e.g. combine into
  reading lists
• difficult to build a reading list to pass on to
  students
• difficult to move from discovering journal
  article to having copy in hand (or on desktop)
• users need to manually join services together

9
The problem space

• from perspective of data consumer
• need to interact with multiple collections of
  stuff - bibliographic, full-text, data, image,
  video, etc.
• delivered thru multiple Web sites
• few cross-collection discovery services (with
  exception of big search engines like Google, but
  lots of stuff is not available to Google, i.e. it
  is part of the invisible Web)
• from perspective of data provider
• few agreed mechanisms for disclosing availability
  of content

10
UK JISC IE context

• 206 collections and counting(Hazel Woodward,
  e-ICOLC, Helsinki, Nov 2001)
• Books 10,000
• Journals 5,000
• Images 250,000
• Discovery tools 50
• A I databases, COPAC, RDN,
• National mapping data satellite imagery
• plus institutional content (e-prints, library
  content, learning resources, etc.)
• plus content made available thru projects 5/99,
  FAIR, X4L,
• plus

11
The problem(s)

• portal problem
• how to provide seamless discovery across multiple
  content providers
• appropriate-copy problem
• how to provide access to the most appropriate
  copy of a resource (given access rights,
  preferences, cost, speed of delivery, etc.)

12
A solution

• an information environment
• framework of machine-oriented services allowing
  the end-user to
• discover, access, use, publish resources across a
  range of content providers
• move away from lots of stand-alone Web sites...
• ...towards more coherent whole
• remove need for use to interact with multiple
  content providers

13
JISC Information Env.

• discover
• finding stuff across multiple content providers
• access
• streamlining access to appropriate copy
• content providers expose metadata about their
  content for
• searching
• harvesting
• alerting
• develop services that bring stuff together
• portals (subject portals, media-specific portals,
  geospatial portals, institutional portals, VLEs,
  )

14
Discovery

• technologies that allow providers to disclose
  metadata to portals
• searching - Z39.50 (Bath Profile)
• harvesting - OAI-PMH
• alerting - RDF Site Summary (RSS)
• fusion services may sit between provider and
  portal
• broker (searching)
• aggregator (harvesting and alerting)

15
Access

• in the case of books, journals, journal articles,
  end-user wants access to the most appropriate
  copy
• need to join up discovery services with
  access/delivery services (local library OPAC,
  ingentaJournals, Amazon, etc.)
• need localised view of available services
• discovery service uses the OpenURL to pass
  metadata about the resource to an OpenURL
  resolver
• the OpenURL resolver provides pointers to the
  most appropriate copy of the resource, given
• user and inst preferences, cost, access rights,
  location, etc.

16
Shared services

• collection/service description service
• information about collections (content) and
  services (protocol) that make that content
  available
• authentication and authorisation
• resolver services
• user preferences and institutional profiles
• terminology services
• metadata registries
• ...

17
JISC Information Env.
Content providers
Provisionlayer
Shared services
Authentication
Fusionlayer
Authorisation
Broker/Aggregator
Broker/Aggregator
Collectn Desc
Service Desc
Portal
Portal
Portal
Presentationlayer
Resolver
Instn Profile
End-user
17
18
Summary

• Z39.50 (Bath Profile), OAI, RSS are key
  discovery technologies...
• and by implication, XML and simple/unqualified
  Dublin Core
• portals provide discovery services across
  multiple content providers
• access to resources via OpenURL and resolvers
  where appropriate
• Z39.50 and OAI not mutually exclusive
• general need for all services to know what other
  services are available to them

19
A note about portals

• portal word possibly slightly misleasding
• Presentation layer will contain lost of
  user-focused services
• subject portal
• reading list and other tools in VLE
• commercial portals (ISI Web of Knowledge,
  ingenta, etc.)
• library portal (e.g. Zportal or MetaLib)
• SFX service component
• personal desktop reference manager (e.g. Endnote)

20
What do you need to do?

• support machine oriented (m2m) interfaces to your
  content/services
• not contentious...
• in line with Web services approach
• 5 steps
• expose your metadata
• share news and alerts
• become an OpenURL source
• become an OpenURL target
• use persistent URLs

21
Allow searching

• support distributed searching of your content by
  remote services
• offer Bath Profile compliant Z39.50 target
• use Z39.50 to expose simple Dublin Core metadata
  about your content
• note possible use of SOAP (Simple Object Access
  Protocol) in the future

22
Allow harvesting

• enable remote services to gather your metadata
  records
• offer Open Archives Initiative repository using
  the OAI Protocol for Metadata Harvesting
• use OAI-PMH to expose simple DC metadata about
  your content
• as well as OR instead of offering Z39.50
  target

23
Share news/alerts using RSS

• offer machine-readable news and alerting
  channel(s)
• news/alerts might include
• service announcements
• list(s) of new resources
• RSS RDF Site Summary
• simple XML application
• use RSS in addition to existing email alerting

24
Become an OpenURL source

• adopt open, context-sensitive linking in the
  form of OpenURLs
• add OpenURLs into search results
• e.g. SFX buttons next to each result
• support mechanism to associate preferred OpenURL
  resolver with each user
• e.g. cookies or user-preferences database

25
Become an OpenURL target

• allow links back into your services from OpenURL
  resolvers
• publicise your link-to syntax, e.g.
• ISSN-based URLs
• DOI-based URLs
• support deep-linking direct to resources
• direct to resource, OR
• indirect via abstract page

26
Use persistent IDs

• Z39.50, OAI-PMH and RSS expose your metadata to
  other services
• allow deep-linking from metadata (e.g. search
  results) to resource
• deep-linking URLs should be unique and persistent
• possibly based on DOIs
• why? allows long-term use of URLs, e.g. in
  course reading list

27
Authentication issues

• how do I control access?
• same as currently - using Athens (or your own
  system)
• user challenged on entry to portal
• portal can determine some search access rights
  from Athens, but you may need to trust portal
• ZBLSA portal/pub query mechanism
• you retain final control at point of access

28
Branding vs. visibility

• will exposing metadata to external service lead
  to loss of branding?
• not really - expect external services to carry
  your branding as quality stamp
• e.g. RSS channel carries your name, URL and logo
• following URL in search results leads direct to
  your site
• so more visibility rather than less

29
Information flow...

• not just about a one-way low of information -
  from you to us
• also exposes content within the academic
  community
• for example...
• RDN offers Z39.50 access to 50,000 resource
  descriptions (soon to offer SOAP interface)
• you can integrate this into your portals

30
Common sense

• Z, OAI and RSS based on metadata fusion -
  merging metadata records from multiple content
  providers
• need shared understanding and metadata practice
  across DNER
• need to agree cataloguing guidelines and
  terminology
• 4 key areas
• subject classification - what is this resource
  about?
• audience level - who is this resource aimed at?
• resource type - what kind of resource is this?
• certification - who has created this resource?

31
A shared problem space

• problems faced by end-users are shared across
  sectors and communities
• student looking for information from variety of
  bibliographic sources
• lecturer searching for e-learning resources from
  multiple repositories
• researcher working across multiple data-sets and
  associated research publications
• a.n.other looking to buy or sell a second-hand car

32
IMS Digital Repositories
33
Web Services - IBM
Web Services are self-contained,
self-describing, modular applications that can be
published, located and invoked across the
Web. IBM Web Services architecture
overview http//www-106.ibm.com/developerworks/web
/library/w-ovr/?dwzoneibm
34
Web Services - Microsoft
A Web service is programmable application logic,
accessible using standard Internet protocols. A
Platform for Web Services http//msdn.microsoft.co
m/library/techart/websvcs_platform.htm
35
Web Services - principles

• small units of functionality
• informational
• transactional
• b2b (m2m)
• key technologies
• XML, HTTP, SOAP, WSDL, UDDI
• supporting organisations
• World Wide Web Consortium (W3C) Web Services
  Activity 3 working groups http//www.w3.org/2002
  /ws/
• Web Services Interoperability Working Group
  (WS-I) http//www.ws-i.org/

36
IBM Web services model
serviceprovider
WSDLUDDI
Publish
serviceregistry
WSDLSOAP
Bind
servicerequestor
Find
WSDLUDDI
37
WSDL, UDDI and SOAP

• Web Service Description Language
• XML descriptions of Web services
• note limited scope for describing content of
  collections
• Universal Discovery, Description and Integration
• technology for building distributed registry of
  Web services
• Simple Object Access Protocol
• remote procedure calls based on XML and HTTP

38
JISC IE - Web services
serviceprovider
Contentproviders, aggregators, brokers, shared
services
Publish
Collection and Service description service JISC
Inf. Env.Service registry
serviceregistry
Bind
servicerequestor
Find
Portals, aggregators, brokers
38
39
JISC Information Env.
Content providers
Provisionlayer
Service provider
Shared services
Authentication
Service requestor
Fusionlayer
Authorisation
Broker/Aggregator
Broker/Aggregator
Service provider
Serviceregistry
Portal
Portal
Portal
Service requestor
Presentationlayer
Resolver
Instn Profile
End-user
39
40
P3P

• Portal Proliferation Problem
• if intention of portals is to reduce the need to
  interact with multiple Web sites
• proliferation may mean that portals are part of
  the problem not part of the solution
• typical campus may have 3 portals
• library (external focus)
• admin/computing (MIS, finance, room booking,... )
• virtual learning environment (lt)
• plus external subject, media and commercial
  portals, ...

41
From portals to portlets

• Portlets provide the building blocks for portals
• re-usable, display-oriented functional chunks
• Apache Jetspeed, IBM WebSphere Portal Server,
  Oracle Application Server Portal, ...
• but ongoing standardisation currently
• portlet approach being adopted by the RDN Subject
  Portal Project
• portlets underpinned by Web services -
  cross-search, display news feed, ...
• portlets can be embedded into institutional
  portals
• portlets will need registering in
  serviceregistry

42
4 layer model?
Content providers
Provisionlayer
Shared services
Authentication
Fusionlayer
Authorisation
Broker/Aggregator
Broker/Aggregator
ServiceRegistry
Portlet
Portlet
Portlet
Portletlayer
Portlet
Resolver
Portal
Portal
Portal
Portallayer
Instn Profile
End-user
42
43
Architectural summary
provision
content
shared services
brokers and aggregators
m2m
fusion
infrastructure
publishing tools
portals
registries terminology indexing resolution authent
ication authorisation citation linking
presentation
44
Conclusions

• current - digital library technologies
• fairly well understood
• fairly slow moving
• Z39.50, OAI, OpenURL, ...
• future - Web service technologies
• largely driven by commercial portal sector and
  b2b requirements
• fast moving, new set of acronyms and terms
• UDDI, WSDL, SOAP, portlet, ...
• semantic Web and RDF
• how do these fit in?

45
Impact

• increased use of XML and SOAP as carrier
  technologies
• OAI - experimental implementation using SOAP
• ZiNG - SRW (Search/Retrieve Web service) (Z39.50
  using SOAP)
• use of WSDL to describe services
• probably supplemented by other standards to
  describe content of collections
• use of portlet technologies
• demise of monolithic portal applications
• small, reusable functional building blocks
• sharing of portlets between portals

46
Links to further information

• JISC Information Environment technical
  architecture
• www.ukoln.ac.uk/distributed-systems/dner/arch/
• JISC Information Environment and Web services
• www.ariadne.ac.uk/issue31/information-environments
  /

47
Questions
48
(No Transcript)