Your SlideShare is downloading. ×
The ‘discovery to delivery’ DLF reference model
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

The ‘discovery to delivery’ DLF reference model


Published on

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

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

Published in: Education

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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 a centre of expertise in digital information management
  • 2. Contents
    • 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
      • history – the IE
      • context - the DLF Abstract Service Framework Working Group
      • terminology – the DLF model and ‘reference model’
      • the d2d reference model
      • issues
  • 3. History - the JISC IE
    • attempt to allow services offered within the JISC community to be joined together more seamlessly
      • JISC-funded, institutional, other
      • allow users to ‘discover’, ‘access’ and ‘use’ resources – d2d
      • not just library resources – wide range of heterogeneous resources
    • a set of standards/interfaces
    • essentially ‘service oriented’ but work pre-dated that use of terminology
  • 4. Context – the DLF
    • Digital Library Federation – consortium of largely US research libraries but growing international membership – e.g. the British Library
    • DLF Abstract Service Framework Working Group - applying a ‘service oriented’ approach to library services
      • see how library services fit into world populated by Google, Amazon, eLearning systems, Grid services and eResearch, Web 2.0, etc.
      • unbundle monolithic library systems into ‘service’ components
    • everything I’m about to tell you may be wrong!
    • this presentation discusses work that is currently in progress
    • the terminology may well change (in fact it is already changing)
    • the use of the DLF model for things like d2d may well change (in fact it is already changing)
    • DLF keen to work with JISC on the eFramework to reach consensus
  • 6. Terminology - the DLF model Business requirement Business process Business function Abstract service Service binding Deployed service Business entity
  • 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. 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. 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. 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. DLF reference model
    • a DLF reference model is…
    • a document that describes all the features of this model as used to meet a particular business requirement
    • not clear how formalised this document can/should be?
      • human text vs.
      • UML (or some other modelling language)
  • 12. Applying the DLF model…
    • …to the discovery to delivery (d2d) ‘business requirement’
      • the requirement for people to be able to discover and access resources in the context of their learning and/or research activities
    • in this case the requirement is met by allowing the end-user to undertake a number of ‘business functions’
      • enter, survey, discover, detail, request, deliver
      • each function is documented using UML use cases
  • 13. Enter
    • entering the ‘system’
    • likely to have to be authenticated before accessing resources
      • e.g. providing an Athens username
    • may result in a personalised view of the landscape being presented
    enter authenticate buildLandscape initiate user provider
  • 14. Survey/discover
    • 'survey‘ is about identifying the collections that are of interest
    • 'discover' drills down into each of the collections identified during the initial survey
    • same ‘discovery’ strategies used in each
    discover initiate user provider survey useSavedRecord search initiate useSavedRecord search browse alert initiate assistQuery assistQuery browse alert initiate
  • 15. Detail
    • builds up knowledge about a particular resource
      • locations, formats, ratings and annotations, terms and conditions, etc.
    • find out enough to be able to request the resource
    detail locate getFormats initiate user provider getRatings getConditions
  • 16. Request/deliver
    • attempt to obtain resource
      • HTTP GET
      • inter-library loan
      • buying book from Amazon
      • etc.
    • some level of authorisation may be required before delivery
    request deliver authorise initiate initiate initiate user provider
  • 17. Abstract services
    • business functions and processes supported by services
    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. Abstract services
    • each abstract service documented in terms of its behaviour, inputs, outputs and intelligence (the business entities it needs to know about)
    • for example:
    • Search (Discover)
      • 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
    • Link server (Detail)
      • 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
  • 19. Service bindings
    • each abstract service instantiated using one or more service bindings
    • for example:
    • Search
      • Z39.50 (Bath Profile) SRW/SRU
      • DC, IEEE LOM
      • METS, IMS-CP, MPEG-21 DIDL
    • Link server
      • OpenURL
  • 20. Deployed services
    • the set of service bindings deployed on the network
    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. Issues - workflow
    • UML use-cases as presented here tend to imply a linear workflow
      • enter, survey, discovery, detail, request, delivery
    • in practice, services likely to be joined together by end-users in arbitrary order as they see fit
    • not possible to pre-determine workflow used in the wild?!
    survey/ discover useRecord detail request deliver useResource
  • 22. Issues – enter function
    • ‘ enter’ function OK if thinking about monolithic resource discovery application, e.g. a ‘portal’
    • but doesn’t sit comfortably in scenario where end-user is joining services together to suit them
    • authentication, authorisation, user-profiling likely to happen at multiple places in workflow
      • e.g. consider user moving from Google to Connotea to OpenURL link server to library OPAC to A&I service to lngenta Journals …
  • 23. Issues – survey vs. discover
    • this work is draft and undergoing inactive change
    • not clear that this is the right breakdown of ‘business functions’
    • ‘survey’ vs. ‘discover’ distinction not clear – particularly since same strategies might be used to find ‘annotations’, ‘terms and conditions’, etc.
  • 24. Issues – use of UML
    • not building monolithic applications
    • rather, we are building loosely-coupled services that will be joined together and choreographed by a variety of applications
    • use of UML in this context is somewhat ‘unusual’
    • might be better to use other approaches instead of/as well as UML
      • e.g. Mindmaps
  • 25. Discussion…