The ‘discovery to delivery’ DLF reference model

2,044 views

Published on

A presentation at the JISC-CETIS Conference, Edinburgh, November 2005

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,044
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

The ‘discovery to delivery’ DLF reference model

  1. 1. UKOLN is supported by: The ‘discovery to delivery’ DLF reference model Andy Powell, UKOLN, University of Bath [email_address] JISC-CETIS Conference, Edinburgh, November 2005 www.bath.ac.uk a centre of expertise in digital information management www.ukoln.ac.uk
  2. 2. Contents <ul><li>this talk summarises some draft work that has been done as part of the DLF Abstract Service Framework Working Group to develop a ‘reference model’ for the ‘discovery to delivery’ space </li></ul><ul><ul><li>history – the IE </li></ul></ul><ul><ul><li>context - the DLF Abstract Service Framework Working Group </li></ul></ul><ul><ul><li>terminology – the DLF model and ‘reference model’ </li></ul></ul><ul><ul><li>the d2d reference model </li></ul></ul><ul><ul><li>issues </li></ul></ul>
  3. 3. History - the JISC IE <ul><li>attempt to allow services offered within the JISC community to be joined together more seamlessly </li></ul><ul><ul><li>JISC-funded, institutional, other </li></ul></ul><ul><ul><li>allow users to ‘discover’, ‘access’ and ‘use’ resources – d2d </li></ul></ul><ul><ul><li>not just library resources – wide range of heterogeneous resources </li></ul></ul><ul><li>a set of standards/interfaces </li></ul><ul><li>essentially ‘service oriented’ but work pre-dated that use of terminology </li></ul>
  4. 4. Context – the DLF <ul><li>Digital Library Federation – consortium of largely US research libraries but growing international membership – e.g. the British Library </li></ul><ul><li>DLF Abstract Service Framework Working Group - applying a ‘service oriented’ approach to library services </li></ul><ul><ul><li>see how library services fit into world populated by Google, Amazon, eLearning systems, Grid services and eResearch, Web 2.0, etc. </li></ul></ul><ul><ul><li>unbundle monolithic library systems into ‘service’ components </li></ul></ul>
  5. 5. BIG DISCLAIMER <ul><li>everything I’m about to tell you may be wrong! </li></ul><ul><li>this presentation discusses work that is currently in progress </li></ul><ul><li>the terminology may well change (in fact it is already changing) </li></ul><ul><li>the use of the DLF model for things like d2d may well change (in fact it is already changing) </li></ul><ul><li>DLF keen to work with JISC on the eFramework to reach consensus </li></ul>
  6. 6. Terminology - the DLF model Business requirement Business process Business function Abstract service Service binding Deployed service Business entity
  7. 7. Terminology - the DLF model Business requirement Business process Business function Abstract service Service binding Deployed service A business requirement is identifiable segment of an organisation’s overall mission. A business process is an identifiable portion of a business requirement. Business processes may be made up of business functions .
  8. 8. Terminology - the DLF model Business requirement Business process Business function Abstract service Service binding Deployed service A bstract services are discrete pieces of networked functionality (supporting a business process/function). A service binding is an instantiation of an abstract service – a concrete data representation, API, Web service description, etc.
  9. 9. Terminology - the DLF model Business requirement Business process Business function Abstract service Service binding Deployed service A deployed service is a service binding available at a specific location on the network. Business entity
  10. 10. Terminology - the DLF model Business requirement Business process Business function Abstract service Service binding Deployed service A business entity is something of interest – typically represented by metadata. The things that services are about. Business entity
  11. 11. DLF reference model <ul><li>a DLF reference model is… </li></ul><ul><li>a document that describes all the features of this model as used to meet a particular business requirement </li></ul><ul><li>not clear how formalised this document can/should be? </li></ul><ul><ul><li>human text vs. </li></ul></ul><ul><ul><li>UML (or some other modelling language) </li></ul></ul>
  12. 12. Applying the DLF model… <ul><li>…to the discovery to delivery (d2d) ‘business requirement’ </li></ul><ul><ul><li>the requirement for people to be able to discover and access resources in the context of their learning and/or research activities </li></ul></ul><ul><li>in this case the requirement is met by allowing the end-user to undertake a number of ‘business functions’ </li></ul><ul><ul><li>enter, survey, discover, detail, request, deliver </li></ul></ul><ul><ul><li>each function is documented using UML use cases </li></ul></ul>
  13. 13. Enter <ul><li>entering the ‘system’ </li></ul><ul><li>likely to have to be authenticated before accessing resources </li></ul><ul><ul><li>e.g. providing an Athens username </li></ul></ul><ul><li>may result in a personalised view of the landscape being presented </li></ul>enter authenticate buildLandscape initiate user provider
  14. 14. Survey/discover <ul><li>'survey‘ is about identifying the collections that are of interest </li></ul><ul><li>'discover' drills down into each of the collections identified during the initial survey </li></ul><ul><li>same ‘discovery’ strategies used in each </li></ul>discover initiate user provider survey useSavedRecord search initiate useSavedRecord search browse alert initiate assistQuery assistQuery browse alert initiate
  15. 15. Detail <ul><li>builds up knowledge about a particular resource </li></ul><ul><ul><li>locations, formats, ratings and annotations, terms and conditions, etc. </li></ul></ul><ul><li>find out enough to be able to request the resource </li></ul>detail locate getFormats initiate user provider getRatings getConditions
  16. 16. Request/deliver <ul><li>attempt to obtain resource </li></ul><ul><ul><li>HTTP GET </li></ul></ul><ul><ul><li>inter-library loan </li></ul></ul><ul><ul><li>buying book from Amazon </li></ul></ul><ul><ul><li>etc. </li></ul></ul><ul><li>some level of authorisation may be required before delivery </li></ul>request deliver authorise initiate initiate initiate user provider
  17. 17. Abstract services <ul><li>business functions and processes supported by services </li></ul>Enter Survey Discover Detail Deliver Request JISC IE D2D Authentic- ation User Preferences Service Registry Search Alert Terminology Metadata Schema Registry Harvest Identifier Resolver Rating/ Annotation Link Server Terms and Conditions Authorisation Authorisation Authorisation Terminology Business Requirement Business Process Abstract Service
  18. 18. Abstract services <ul><li>each abstract service documented in terms of its behaviour, inputs, outputs and intelligence (the business entities it needs to know about) </li></ul><ul><li>for example: </li></ul><ul><li>Search (Discover) </li></ul><ul><ul><li>Behavior: Accepts a structured query and issues a set of metadata records (a result set) in response to the query. Intelligence: Schema Data in: Structured query Data out: Metadata record set </li></ul></ul><ul><li>Link server (Detail) </li></ul><ul><ul><li>Behavior: Provides information and/or links (i.e. URLs) associated with a resource based on a metadata record about that resource. Intelligence: Data in: Metadata record Data out: Information and links </li></ul></ul>
  19. 19. Service bindings <ul><li>each abstract service instantiated using one or more service bindings </li></ul><ul><li>for example: </li></ul><ul><li>Search </li></ul><ul><ul><li>Z39.50 (Bath Profile) SRW/SRU </li></ul></ul><ul><ul><li>DC, IEEE LOM </li></ul></ul><ul><ul><li>METS, IMS-CP, MPEG-21 DIDL </li></ul></ul><ul><li>Link server </li></ul><ul><ul><li>OpenURL </li></ul></ul>
  20. 20. Deployed services <ul><li>the set of service bindings deployed on the network </li></ul>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 link servers shared infrastructure authentication/authorisation (Athens) institutional profiling services terminology services service registries identifier services metadata schema registries © Andy Powell (UKOLN, University of Bath), 2005
  21. 21. Issues - workflow <ul><li>UML use-cases as presented here tend to imply a linear workflow </li></ul><ul><ul><li>enter, survey, discovery, detail, request, delivery </li></ul></ul><ul><li>in practice, services likely to be joined together by end-users in arbitrary order as they see fit </li></ul><ul><li>not possible to pre-determine workflow used in the wild?! </li></ul>survey/ discover useRecord detail request deliver useResource
  22. 22. Issues – enter function <ul><li>‘ enter’ function OK if thinking about monolithic resource discovery application, e.g. a ‘portal’ </li></ul><ul><li>but doesn’t sit comfortably in scenario where end-user is joining services together to suit them </li></ul><ul><li>authentication, authorisation, user-profiling likely to happen at multiple places in workflow </li></ul><ul><ul><li>e.g. consider user moving from Google to Connotea to OpenURL link server to library OPAC to A&I service to lngenta Journals … </li></ul></ul>
  23. 23. Issues – survey vs. discover <ul><li>this work is draft and undergoing inactive change </li></ul><ul><li>not clear that this is the right breakdown of ‘business functions’ </li></ul><ul><li>‘survey’ vs. ‘discover’ distinction not clear – particularly since same strategies might be used to find ‘annotations’, ‘terms and conditions’, etc. </li></ul>
  24. 24. Issues – use of UML <ul><li>not building monolithic applications </li></ul><ul><li>rather, we are building loosely-coupled services that will be joined together and choreographed by a variety of applications </li></ul><ul><li>use of UML in this context is somewhat ‘unusual’ </li></ul><ul><li>might be better to use other approaches instead of/as well as UML </li></ul><ul><ul><li>e.g. Mindmaps </li></ul></ul>
  25. 25. Discussion…

×