DNER Architecture Andy Powell, Liz Lyon MLE Steering Group 4 May 2001 UKOLN, University of Bath [email protected] UKOLN is funded by

DNER Architecture

Andy Powell, Liz Lyon

MLE Steering Group4 May 2001

UKOLN, University of Bath

[email protected]

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.

MLESG - 4 May 20012

Contents

• scope of the DNER• content• functionality

• network systems architecture• discovery• access

• integration of DNER into VLEs

Scope

What is the DNER?

MLESG - 4 May 20014

Primary Content

Secondary Content

Funded

Institutional

External

Web

pag

es

Museum

s

home pages

thes

es

research papers

OPACs

Institutional gateways

GoogleYahoo

Northern

Light

RDN A&I

imagesFull-text

statistics

Map data

COPAC

Amazon

Public libraries

cour

sew

are

DNER scope by content?

MLESG - 4 May 20015

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

MLESG - 4 May 20016

DNER Collections• content typically in the form of ‘collections’

• where collection is one or more items• collections of stuff (text, images, data, ...)• collections of metadata about stuff (e.g subject

gateway’s, library catalogues)• local collections, ‘JISC’ collections, other collections

• network services make digital collections available at digital ‘locations’

• real services make physical collections available at physical ‘locations’

• people access content through services

MLESG - 4 May 20017

Primary DNER entities

Content

Person Service

Host, port,protocol, schema

Collection, item,discovery, description,rights, terms & conditions

Contact details,preferences,subject interests,educational level

MLESG - 4 May 20018

DNER scope by function

• simple underlying functional model• discover, access, use

• characterised in the solution to two problems• ‘portal problem’ - how to provide seamless

discovery across multiple content providers• ‘appropriate-copy problem’ - how to provide

access to the most appropriate copy of a resource (given access rights, preferences, cost, speed of delivery, etc.)

• generic - applicable to finding Web resources, buying books, buying cars, ...

MLESG - 4 May 20019

Functional model• iterative process• move from user-need to resource

on desktop (physical or digital)• three stage ‘discovery process’• ‘buildLandscape’ and ‘survey’ -

collection level• ‘discover’ and ‘detail’ - item level• ‘detail’ phase provides

information about how to request instance of resource

• ‘detail’ may involve resolving identifier or metadata for resource using ‘resolver’

surveydiscover

authenticatebuildLandscape

detail

requestauthoriseaccess

useResource

useRecord

MLESG - 4 May 200110

DNER information flow

• process is iterative at all stages• DNER not just a ‘provider to user’ flow• users are both recipients and creators of

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.


DNER scope summary...• DNER is an information environment (a set of services)

that enables people to discover, 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

• ‘discover, access and use’ includes• discover / locate / access• use / reuse / create• receive / provide / collaborate

Network Systems Architecture

How does the DNER do it?


Web Web Web Web Web

Content(local andremote)

End-user

Current services offer mix of discover, access and use functionality

End-user needs to join services together manually - as well as learning multiple user interfaces

Current DNER architecture


Web Web Web Web

Current shared servicesContent

End-user

Authentication

Authorisation

Authentication and authorisation already provided as shared services through Athens


Joining things together

• DNER architecture provides framework for shared services

• machine to machine interfaces• DNER as coherent whole rather than lots of

stand-alone services• two areas in particular...• discovery

• finding stuff across multiple content providers

• access• streamlining access to appropriate copy

Discover

How does the DNER support content discovery?


Discover

• want to allow end-user to discover across several network services...

• to support this, services need to expose content for machine to machine (m2m) use

• expose metadata about their content for• searching• harvesting• alerting

• develop services that bring stuff together• portals


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)


Web Web Web Web

Thin portalContent

End-user

Portal

Authentication

Authorisation

Collect’n Desc

Service Desc

HTTP


Web Web Web Web

SearchingContent

End-user

Portal

Z39.50Bath Profile

Authentication

Authorisation

Collect’n Desc

Service Desc

HTTP


Z39.50 - Bath Profile

• search and retrieve• support portal and broker cross-searching• Bath Profile based on existing profiles• cross-domain focus (in part)• DC XML records• DTD-based rather than XML Schema


Web Web Web Web

SharingContent

End-user

Portal

OpenArchivesInitiative

Authentication

Authorisation

Collect’n Desc

Service Desc

HTTP


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


Web Web Web Web

AlertingContent

End-user

Portal

RSS

Email

Authentication

Authorisation

Collect’n Desc

Service Desc

HTTP


RSS

• RDF Site Summary• RDF/XML application for syndicated news

feeds (RSS 1.0)• pointers and simple descriptions of news

items (not the items themselves)• makes use of DC elements• previous versions based on XML (RSS 0.9)• no querying - just regular ‘gathering’ of RSS

filehttp://www.ukoln.ac.uk/metadata/rssxpress/

Access

How does the DNER help us access content?


Resource identification

• discovery phase results in metadata about a resource

• metadata will include its identifier or a locator

• for Web resources a URL is common• identifier/locator 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


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 Web page)• metadata about the resource (e.g. description of

image)

• probably need to identify all of these• need guidelines on good practice for use of

URLs• investigate use of DOIs


Resolving identifiers

• may need to resolve the metadata, identifier or locator into information about how to request a particular instance of the resource

• this is done 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?


OpenURL

• metadata, identifier or locator forms a ‘citation’ for the resource

• OpenURL - way to encode citation for a resource

• 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


OpenURL resolver

Content

End-user

Deliveryservice

Authentication

Authorisation

Collect’n Desc

Service Desc

Resolver

Portal OpenURL

HTTPInst’n Profile

Summary


Web Web Web Web

Content

End-user

Portal

Broker/Aggregator

Authentication

Authorisation

Collect’n Desc

Service Desc

Resolver

Shared service model

Inst’n Profile


sharedservices

portals

content

brokersand

aggregators

DNER architectureprovision

fusioninfrastructure

presentation

m2minterfaces

The VLE problem?

How is the DNER integrated with VLEs?


3 points of contact

• DNER as a repository of ‘learning resources’

• DNER as source of building blocks for learning resource creation

• DNER as source of trusted information for student centred activities

• Issues...


DNER as repository

• some DNER resources will be learning resources

• IMS packages, Blackboard cartridges, etc.• described using IMS metadata (or similar)• discovery by lecturers for plugging into their

VLE• IMS doesn’t provide ‘standard’ way for VLE to

talk to a collection of learning resources (repository)

• …but IMS Digital Repositories working group about to address this area


DNER as source

• DNER is trusted source of building blocks for learning resources

• tools for packaging learning resources (IMS package constructors?) need to integrate with with DNER portals or become DNER portals

• portal search results need to be able to populate course reading lists


DNER as resource

• VLEs provide environment for student centred activities

• DNER provides trusted source of rich information for such activities

• need to integrate VLEs closely with DNER portals or make VLEs into DNER portals


Issues - VLEs as portals

• VLEs are already thin portals - provide links to external services

• do we expect VLE software to become think portals - i.e. to support Z39.50, OAI, RSS, etc?

• not necessarily…• use frames to integrate external portals into VLE• use CGI-based technologies such as RDN-

Include• not close integration… but a start


Issues - metadata

• learning packages typically described using IMS (rich metadata)

• DNER discovery based largely on Dublin Core (simple metadata)

• a proposal…• DC (or DC-Education) sufficient for discovery of

packages

• IMS required within packages for integration into VLE

• so… IMS internal to the package but only need to expose DC (or DC-Education) externally


Issues - common sense

• need shared understanding and metadata practice across whole range of services

• need to agree ‘cataloguing guidelines’ and terminology in 4 key areas

• subject classification• audience level (who is this resource aimed

at?)• resource type (what kind of resource is this?)• certification (who has created this resource?)

Documents

DNER Architecture Andy Powell, Liz Lyon MLE Steering Group 4 May 2001 UKOLN, University of Bath [email protected] UKOLN is funded by