DNER ArchitectureAndy Powell

UKOLN, University of Bath

a.powell@ukoln.ac.uk

www.ukoln.ac.uk

JOIN-UP Seminar on Linking Technologies, Edinburgh

6 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

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

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’

surveydiscover

authenticatelandscape

detail

requestauthoriseaccess

useResource

useRecord

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

• 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

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

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

Web Web Web Web

Thin portalContent

End-user

Portal

Authentication

Authorisation

Collect’n Desc

HTTP

9

Web Web Web Web

Thick portal - searchingContent

End-user

Portal

Z39.50Bath Profile

Broker

Authentication

Authorisation

Collect’n Desc

Service Desc

HTTP

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

Web Web Web Web

Thick portal - sharingContent

End-user

Portal

OpenArchivesInitiative

Aggregator

Authentication

Authorisation

Collect’n Desc

Service Desc

HTTP

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 <http://www.openarchives.org/>

13

Web Web Web Web

Thick portal - alertingContent

End-user

Portal

RSS

Aggregator

Email

Authentication

Authorisation

Collect’n Desc

Service Desc

HTTP

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 filehttp://www.ukoln.ac.uk/metadata/rssxpress/

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

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

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

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

Locate and identifiers

Discover

Locate

Request

ISBN

ResourceURL

URI DOI

OpenURL or Z39.50 request

Citation/metadata

Discovery services

Web resource Book

Journal issue Article

Delivery service URLor

Resource URL

Locate services(resolvers)

Persistent ‘identifiers’- context independent

Transient ‘locators’- context sensitive

20

OpenURL resolver

Content

End-user

Deliveryservice

Authentication

Authorisation

Collect’n Desc

Service Desc Portal OpenURL

HTTPResolver

21

DNER shared services

• authentication• authorisation/profiling• collection description• service description• resolution• user preferences• thesauri/terminology• metadata registry• (ratings, terms & conditions)

key

desirable

22

sharedservices

portals

content

brokersand

aggregators

Summaryprovision

fusionmiddleware

presentation

m2minterfaces