DNER Architecture

1. DNER Architecture Andy Powell UKOLN, University of Bath a.powell@ukoln.ac.uk www.ukoln.ac.uk Web of Science Enhancements Committee, Centre Point 5 March 2001 UKOLN is funded by Resource: The Council for Museums, Archives and Libraries, the Joint Information Systems Committee (JISC) of the Higher and Further Education Funding Councils, as well as by project funding from the JISC and the European Union. UKOLN also receives support from the University of Bath where it is based.

2. Contents • scope • functional model • network systems architecture • discover • request, access

3. Scope What is the DNER?

4. DNER scope by content? External Public libraries Institutional Web pages home pages Funded Museums theses research papers Map data courseware Full-text images Primary Content statistics Northern Light Secondary Content RDN WoS A&I COPAC OPACs Institutional gateways Amazon Yahoo Google

5. but... • … not a user view • … not an institutional view • user view based on personalised landscape... • own information foremost • institutional (intranet or VLE) • DNER and external (general Web stuff) • probably with discipline or subject focus • … difficult to scope DNER by content?

6. Information environment • DNER is an information environment (a set of services) that enables people to access and use a wide variety of resources • ‘resources’ are… • services / content • local / remote • primary / secondary, data / metadata • digital / physical • JISC funded / not JISC funded • policy controlled / non-policy controlled • ‘access and use’ includes • discover / locate / access • use / reuse / create • receive / provide / collaborate

7. Functional Model What does the DNER do?

8. Web Web Web Web Web Currently... Content (local and remote) • end-user has to interact with several different services, each with their own user-interface • what functional model is supported? • what can end-user do? End-user

9. Functional model authenticate landscape • move from user-need to resource on desktop (physical or digital) • three stage ‘discovery process’ • ‘landscape’ and ‘survey’ - collection level • ‘discover’ and ‘detail’ - item level • iterative process • final ‘detail’ phase provides information about how to request instance of resource • ‘detail’ may involve resolving identifier or metadata for resource using ‘resolver’ survey discover useRecord detail request authorise access useResource

10. DNER information flow • process is iterative at all stages • DNER not just a ‘provider to user’ flow • users are both recipients of and creators of both primary content, secondary content and metadata • DNER architecture needs to support • collaboration and • creation • …as well as discovery, etc. • current work on architecture doesn’t really address this.

11. Network Systems Architecture How does the DNER do it?

12. Web Web Web Web Web Currently... Content End-user needs to join services together manually - as well as learning multiple user interfaces Current services offer mix of survey, discover, detail, request, access, useRecord functionality End-user

13. Joining things together • build framework for shared services • DNER as coherent whole rather than lots of stand-alone services • two areas in particular... • discovery • finding stuff from multiple content providers • locate/request/deliver • streamlining access

14. Discover • in order to allow end-user to discover seamlessly across several network services... • services need to expose content for machine use (m2m) • expose metadata for • searching • harvesting • alerting • develop services that bring stuff together • portals

15. Portals • portals provide access to multiple network services • there will be many kinds of portals... • subject portals • data centre portals • institutional portals • personal portals (agents) • virtual learning environments • thin portals (shallow linking) • thick portals (deep linking, richer discovery and use functionality)

16. Thin portal Content Web Web Web Web Authentication Authorisation Collect’n Desc Portal HTTP End-user

17. Searching Content Web Web Web Web Authentication Z39.50 Bath Profile Authorisation Broker Collect’n Desc Portal Service Desc HTTP End-user

18. Sharing Content Open Archives Initiative Web Web Web Web Authentication Authorisation Aggregator Collect’n Desc Portal Service Desc HTTP End-user

19. Open Archives Initiative • OAI Metadata Harvesting Framework • simple mechanism for sharing metadata records • records shared over HTTP... • ... as XML (using XML Schema) • client can ask metadata server for • all records • all records modified in last ‘n’ days • info about sets, formats, etc. • See <http://www.openarchives.org/>

20. Alerting Content Web Web Web Web RSS Authentication Authorisation Aggregator Collect’n Desc Portal Service Desc Email HTTP End-user

21. RSS • Rich/RDF Site Summary • XML application for syndicated news feeds • pointers and simple descriptions of news items (not the items themselves) • has been transitioned to more generic RDF/XML application (RSS 1.0) • no querying - just regular ‘gathering’ of RSS file http://www.ukoln.ac.uk/metadata/rssxpress/

22. request, access How does the DNER help us access content?

23. Resource identification • discover phase results in metadata about a resource that may include its identifier or a locator • for Web resources a URL is common • identifier is persistent • locator also needs to be persistent • enable lecturers to embed it into learning resources • enable students to embed it into multimedia essays • enable people to cite it

24. Identifiers/locators • also need to think about what is identified...? • the resource (e.g. an image) • the resource in context (e.g. image embedded into VADS page) • metadata about the resource (e.g. description of image from VADS or subject gateway) • probably need to identify all of these • need guidelines on good practice for use of URLs • investigate use of DOIs

25. Resolving identifiers • may need to resolve the metadata, identifier or locator into information about how to request a particular instance of the resource • ‘locate’ part of detail phase provides resolution using resolvers • resolvers find appropriate copy • location is context sensitive - need to know who end-user is, where they are and what they have access to • may be best carried out locally to end-user?

26. OpenURL • metadata, identifier or locator forms a ‘citation’ for the resource • OpenURL provides mechanism for encoding citation for a resource as a URL • OpenURL = baseURL + description • baseURL provides location of a ‘resolver’ • description is either a global identifier (e.g. a DOI or ISBN) or a description (a citation) or mixture • http://sfx.bath.ac.uk/sfxmenu?genre=book&isbn=1234-5678

27. Locate and identifiers Web resource Journal issue Book Article Discovery services Discover URI DOI ISBN Citation/metadata Persistent ‘identifiers’ - context independent OpenURL or Z39.50 request Locate Locate services (resolvers) Resource URL Delivery service URL or Resource URL Transient ‘locators’ - context sensitive Request

28. OpenURL resolver Content Delivery service Authentication Authorisation Collect’n Desc Portal OpenURL Service Desc Resolver HTTP End-user

29. DNER shared services • authentication • authorisation/profiling • collection description • service description • resolution • user preferences • thesauri/terminology • metadata registry • (ratings, terms & conditions) key desirable

30. Summary provision content shared services m2m interfaces brokers and aggregators middleware fusion portals presentation