Standards For JISC's Digital Repositories Programme

1
Standards For JISC's Digital Repositories
Programme
http//www.ukoln.ac.uk/web-focus/events/meetings/j
isc-2006-03/

• Brian Kelly
• UKOLN
• University of Bath
• Bath

Acceptable Use Policy Recording/broadcasting of
this talk, taking photographs, discussing the
content using email, instant messaging, Blogs,
SMS, etc. is permitted providing distractions to
others is minimised.
Email B.Kelly_at_ukoln.ac.uk
This work is licensed under a Attribution-NonComme
rcial-ShareAlike 2.5 licence (but note caveat)
Subject to confirmation at end of talk
UKOLN is supported by
2
Contents

• This brief talk will cover
• Background to use of standards in JISC-funded
  activities
• Limitations of previous approaches
• Layered approach developed by QA Focus
• Doing the work
• Supporting the work
• Building on the work

3
Background

• JISC's development programmes
• Traditionally based on use of open standards to
• Support interoperability
• Maximise accessibility
• Avoid vendor lock-in
• Provide architectural integrity
• Help ensure long-term preservation
• History
• eLib Standards document (v1 1996, v2 1998)
• DNER Standards document (2001)
• which influenced
• NOF-digi Technical Standards
• ..

4
Lessons Learnt

• Experiences of the QA Focus (and NOF-digi
  Technical Advisory Service) revealed problems
• Lack of knowledge of standards
• Lack of resources
• Immaturity of standards
• Failure for standards to take off
• Difficulties when building on existing work
• Uncertainty of what to do if standards not
  implemented correctly

5
What To Do?

• QA Focus project asked by JISC to make
  recommendations on how to address such tensions
• Should we suggest
• Mandation of use of defined open standards
  penalty clauses for non-compliance (central
  government way?)
• Leave everything to the marketplace (Thatcherite
  approach)
• Or is there a third way?

6
Need For Flexibility

• There is a need for flexibility in the standards
  infrastructure
• Learning the lessons from OSI networking
  protocols (the great networking standard of the
  1980s!)
• Today
• Conveyor belt of great new Web standards is
  slowing down
• Questions as to whether Web (for example) is
  becoming over-complex
• "Web service considered harmful"
• The lowercase semantic web / Microformats
• Lighter-weight alternatives being developed
• Responses from the commercial world

7
Compliance Issues

• What does must mean?
• You must comply with HTML standards
• What if I don't?
• What if nobody does?
• What if I use PDF?
• You must clear rights on all resources you
  digitise
• You must provide properly audited accounts
• What if I don't?

There is a need to clarify the meaning of must
and for an understandable, realistic and
reasonable compliance regime
8
The Context

• There will be a context to use of standards
• The intended use
• Innovative / research ? Mainstream
• Key middleware component ? Small-scale
  deliverable
• Organisational culture
• HE vs FE ? Teaching vs Research
• Service vs Development ?
• Available Funding Resources
• Significant funding training to make use of
  important new standards
• Minimal funding - current skills should be used

9
The Layered Standards Model
Owner
JISC
3rd Parties
JISC / project
This 3-layered model has been recommended to JISC
10
Scope Of The Standards Work

• The Standards Catalogue
• Covers JISC's development programmes
• Cover other JISC-funded development work
• Is available for others (e.g. institutional work)
• May be extended to cover
• JISC-funded services
• Cover JISC itself
• Content areas will include
• Web ? File formats
• Metadata ? Resource discovery
• E-learning ? Addressing
• Alerting ? Authentication
• E-Research ?

11
Implementation

• How might this approach be used in practice?

12
Collating The Content

• We used a Wiki to collect initial information
  about the standards
• Being used by a small groups of trusted
  individuals
• Avoids bottleneck for uploading and maintaining
  content
• Note the Wiki is used for creation maintenance
  of the data and will not be the final repository

13
Using The Model

• Current status
• Initial work carried out by QA Focus project
  (2002-2004)
• Several peer-reviewed papers described aspects
  of work
• A Contextual Framework For Standards,
  E-Government Workshop, Edinburgh, May 2006
• A Standards Framework For Digital Library
  Programmes, ichim05
• Interoperability Across Digital Library
  Programmes? We Must Have QA!, ECDL 2004
• Deployment Of Quality Assurance Procedures For
  Digital Library Programmes, EUNIS 2003
• Ideology Or Pragmatism? Open Standards And
  Cultural Heritage Web Sites, ichim03
• Following validation of ideas, approaches are now
  being deployed by JISC
• JISC's Digital Repositories Programme will act as
  initial pilot

Co-authors include staff from UKOLN, AHDS,
TechDis CETIS
14
Accessing The Content
http//www.ukoln.ac.uk/repositories/digirep/index
/DigRepStandardsHome

• Content available via the Digital Repositories
  Wiki

15
About The Content

• The information provided aims to be simple and
  succinct (but document will still be large when
  printed!)

• Standard Dublin Core
• About the Standard Dublin Core is a metadata
  standard made up
• Version New terms are regularly added to
• Maturity Dublin Core has its origins in
  workshops held
• Risk Assessment Dublin Core plays a key role .
  It is an important standard within the context of
  JISC development programmes.
• Further Information
• DCMI, lthttp//dublincore.org/gt
• Author Pete Johnston, UKOLN
• Contributor
• Date Created 04 Oct 2005
• Update History Initial version.

Example
Note that as the standards catalogue is intended
for wide use the contents will need to be fairly
general
16
Providing Feedback

• As the JISC Digital Repositories programme is the
  pilot for this approach to standards, your
  feedback is important
• The Discussion tab can be used by registered
  users to provide
• Specific feedback on the standards entries
• Suggestions for further information (e.g. case
  studies you've written)

More generic feedback on the model, its
applications, etc. may be provided using other
mechanisms? Opportunity for discussion on best
options.
17
Quality Assurance Infrastructure

• Will projects and services implement standards as
  required? How will we know?
• Compliance checking
• External checkers Approach used in NOF-digi.
  But
• Concerns over big brother
• Does big brother have expertise?
• Alien to HE culture
• Standards not embedded into working practices
  (done because funders want it)
• Self-assessment
• Approach recommended by QA Focus (and should be
  done even if external checking)
• Need for projects/services to define their QA
  processes

18
QA Framework

• QA Focus project
• Developed lightweight quality assurance framework
  designed for JISC's development programmes
• Methodology validated by Duke/Jordan review of
  JISC's standards
• QA methodology
• Project should provided document policies
• Projects should implement systematic procedures
  for ensuring their policies are being implemented
• JISC perspective
• JISC may define the QA procedures
• And/or JISC may ask projects to define their own
  QA policies and procedures

19
Standards Catalogue Process

• There's a need for developing and enhancing the
  standards catalogue in order to
• Update with new standards
• Learn from feedback and experiences

Review
Standards
The Standards Catalogue can be integrated with
the JISC's 'Framework'
20
Sustainability

• How do we
• Sustain, maintain and grow the standards
  catalogue?
• Develop a sustainable support infrastructure?
• Ensure that JISC supports learning organisations
  (and that JISC is a learning organisation)
• Options
• More funding for support infrastructure
• Exploit learning gained by projects, reuse
  experiences, encourage sharing, etc.

21
Support Infrastructure (1)

• Experiences of QA Focus
• 90 briefing documents 30 case studies
• Licensed (where possible) under Creative Commons
• UKOLN are continuing to publish new documents
  (documents on Folksonomies, AJAX, Podcasting,
  Wikis, etc. published recently)

• Case Study Template
• About the Project
• Area covered
• Approach taken
• Lessons Learnt / Things We'd Do Differently

• Case studies
• Opportunity to describe experiences in specific
  areas
• Standard template to ensure consistency provide
  focus
• Allows UKOLN to promote projects' work ?
• Project get better Google rating ?

22
Support Infrastructure (2)

• What you can do
• Case Studies
• On train home use template to summarise one
  aspect of your project work
• Upload to Wiki
• Briefing Documents
• Write a (brief!) briefing paper on area not
  currently covered and send to Brian Kelly

• Why?
• Others (e.g. me) can cite your work
• Use of a CC licence enables you, your work, your
  organisation, to become known in other sectors
  you can benefit from this
• You will be seen to be good JISC citizens
• You may get the 'feel good' factor it's not
  just open source software developers who can
  share their work

23
Support Infrastructure (3)

• How do we maintain the information about the
  standards?
• Your feedback
• Linking to related information in Wikipedia (the
  world can help the updating)
• Uploading information to Wikipedia the wider
  community can help to update and maintain it
• Making information available with CC licences
  so others can use it, update it and hopefully
  give feedback on enhancements

Note that this approach of collaboration, sharing
and trust reflects the Web 2.0 culture which is
currently informing various aspects of Web
development
24
Extending The Model

• Joint UKOLN / TechDis / OSS Watch work has
  extended the layered model to other related areas

Context Policies
Sector
Funding
Culture
Resources

Annotated Catalogues

Standards
Software
Accessibility
Context Compliance
External
Self assessment
Learning

• This model (described in paper accepted for
  E-Government Workshop in Edinburgh in May 2006)
  aims to provide a consistent and understandable
  model
• For use by the funders
• For use by projects
• Applicable to the diversity to be found in the
  sector
• Applicable to the technical complexity and
  diversity

25
Conclusions

• To conclude
• Approach to developing standards catalogue based
  on QA Focus's experiences, and its review by Jon
  Duke/Andy Jordan
• Acknowledges importance of context
• Allows for hard-line implementation (which is
  needed in some areas)
• Projects need to be actively involved in process