Transcript presentation source

DNER Architecture
Andy Powell, Liz Lyon
MLE Steering Group
4 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.
Contents
• scope of the DNER
• content
• functionality
• network systems architecture
• discovery
• access
• integration of DNER into VLEs
2
MLESG - 4 May 2001
Scope
What is the DNER?
DNER scope by content?
External
Institutional
Secondary Content
RDN
A&I
COPAC
4
MLESG - 4 May 2001
Northern
Light
Primary Content
Map data
Full-text
images
statistics
Funded
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
5
MLESG - 4 May 2001
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
6
MLESG - 4 May 2001
Primary DNER entities
Content
Person
Contact details,
preferences,
subject interests,
educational level
7
Collection, item,
discovery, description,
rights, terms & conditions
Service
Host, port,
protocol, schema
MLESG - 4 May 2001
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, ...
8
MLESG - 4 May 2001
Functional model
9
• 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’
MLESG - 4 May 2001
authenticate
buildLandscape
survey
discover
useRecord
detail
request
authorise
access
useResource
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.
10
MLESG - 4 May 2001
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
11
• discover / locate / access
• use / reuse / create
• receive / provide / collaborate
MLESG - 4 May 2001
Network Systems
Architecture
How does the DNER do it?
Current DNER architecture
Content
(local and
remote)
Web
Current services
offer mix of
discover, access
and use
functionality
13
Web
Web
Web
End-user
MLESG - 4 May 2001
Web
End-user needs
to join services
together
manually - as
well as learning
multiple user
interfaces
Current shared services
Content
Web
Web
Web
Web
Authentication
Authorisation
End-user
14
MLESG - 4 May 2001
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
15
MLESG - 4 May 2001
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
17
MLESG - 4 May 2001
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)
18
MLESG - 4 May 2001
Thin portal
Content
Web
Web
Web
Web
Authentication
Authorisation
Collect’n Desc
Service Desc
Portal
HTTP
End-user
19
MLESG - 4 May 2001
Searching
Content
Web
Web
Web
Web
Authentication
Z39.50
Bath Profile
Authorisation
Collect’n Desc
Service Desc
Portal
HTTP
End-user
20
MLESG - 4 May 2001
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
21
MLESG - 4 May 2001
Sharing
Content
Web
Web
Web
Web
Open
Archives
Initiative
Authentication
Authorisation
Collect’n Desc
Service Desc
Portal
HTTP
End-user
22
MLESG - 4 May 2001
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/>
23
MLESG - 4 May 2001
Alerting
Content
Web
Web
Web
Web
RSS
Authentication
Authorisation
Collect’n Desc
Portal
Service Desc
Email
HTTP
End-user
24
MLESG - 4 May 2001
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 file
http://www.ukoln.ac.uk/metadata/rssxpress/
25
MLESG - 4 May 2001
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
27
MLESG - 4 May 2001
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
28
MLESG - 4 May 2001
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 enduser?
29
MLESG - 4 May 2001
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
30
MLESG - 4 May 2001
OpenURL resolver
Content
Delivery
service
Authentication
Authorisation
Collect’n Desc
Service Desc
OpenURL
Portal
Resolver
HTTP
Inst’n Profile
End-user
31
MLESG - 4 May 2001
Summary
Shared service model
Content
Web
Web
Web
Web
Authentication
Authorisation
Broker/Aggregator
Collect’n Desc
Service Desc
Portal
Resolver
Inst’n Profile
End-user
33
MLESG - 4 May 2001
DNER architecture
provision
content
infrastructure
shared
services
m2m
interfaces
portals
presentation
34
MLESG - 4 May 2001
brokers
and
aggregators
fusion
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...
36
MLESG - 4 May 2001
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
37
MLESG - 4 May 2001
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
38
MLESG - 4 May 2001
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
39
MLESG - 4 May 2001
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 RDNInclude
• not close integration… but a start
40
MLESG - 4 May 2001
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
41
MLESG - 4 May 2001
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?)
42
MLESG - 4 May 2001