1. DNER Architecture Andy Powell 6 March 2001 UKOLN, University of Bath a.powell@ukoln.ac.uk www.ukoln.ac.uk 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. 2 What is the DNER? 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

3. 3 Functional model 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 authenticate landscape detail request authorise access useResource useRecord

4. 4 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. however, current work on architecture doesn’t really address this.

5. 5 framework for network of 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 Systems architecture

6. 6 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

7. 7 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 - search, share and alert)

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

9. 9 Web Thick portal - searching Content End-user Portal Z39.50 Bath Profile Broker Authentication Authorisation Collect’n Desc Service Desc HTTP

10. 10 Searching and Z39.50 cross-searching based on Z39.50 and Bath Profile pragmatic rather than dogmatic choice Z39.50 only real option at this stage can move to other options (e.g. W3C query language) when appropriate

11. 11 Web Thick portal - sharing Content End-user Portal Open Archives Initiative Aggregator Authentication Authorisation Collect’n Desc Service Desc HTTP

12. 12 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

13. 13 Web Thick portal - alerting Content End-user Portal RSS Aggregator Email Authentication Authorisation Collect’n Desc Service Desc HTTP

14. 14 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/

15. 15 Resource identification ‘discovery’ 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

16. 16 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

17. 17 Resolving identifiers may need to resolve the metadata, identifier or locator into information about how to request a particular instance of the resource need to find appropriate copy resolution 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?

18. 18 OpenURL metadata, identifier or locator effectively 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

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

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

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

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