1 / 13

UKOLN is supported by:

Put functionality Augmenting interoperability across scholarly repositories 20/21 April 2006 Rachel Heery, UKOLN, University of Bath. UKOLN is supported by:. www.bath.ac.uk. www.ukoln.ac.uk. a centre of expertise in digital information management. My perspective.

adolfo
Download Presentation

UKOLN is supported by:

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Put functionality Augmenting interoperability across scholarly repositories 20/21 April 2006 Rachel Heery, UKOLN, University of Bath UKOLN is supported by: www.bath.ac.uk www.ukoln.ac.uk a centre of expertise in digital information management

  2. My perspective • JISC Digital Repositories Programme • 20+ repository projects • JISC Framework • Defining reference models and services • Deposit API meeting and ongoing • Intention to find light-weight solution to assist populating repositories within timescales of JISC programme • NB submit, deposit, post, put…similarities but subtle differences Augmenting interoperability across scholarly repositories, April 20/21 2006

  3. Put – User requirements • To enable users to populate repositories effectively • To capture content from desktop applications, experimental equipment (smart labs), learning content development tools etc • To enable repositories to exchange data in predictable manner • To hide complexity from end-user • To be compatible with follow-on added value services layered on repository content Augmenting interoperability across scholarly repositories, April 20/21 2006

  4. Put - Scenarios • Author ‘saves’ a report from a desktop authoring system to the institutional repository • An institutional repository submits a learning object to a national learning materials repository • Experimental data output from spectrometer is 'saved as' a file and a file containing metadata on operational parameters is also generated. A data capture service is invoked and the files pertaining to the experiment are deposited, along with the necessary metadata, in the laboratory repository. See http://www.ukoln.ac.uk/repositories/digirep/ Augmenting interoperability across scholarly repositories, April 20/21 2006

  5. Functional requirements • Must be generic enough to be offered by wide range of heterogeneous repositories • scholarly publications, data, learning objects, images, etc. • Must accept submission ofdifferent digital object types in consistent way: • data and/or metadata possibly in the form of complex objects • Data may be of different types and metadata may be of different formats • Data may be large scale (scientific datasets) • Repositories may have different policy rules • Successful deposit should initiate ingest process for local storage in repository: • may be automated and/or involve manual intervention (metadata extraction, quality assurance, identity and provenance processing etc) Augmenting interoperability across scholarly repositories, April 20/21 2006

  6. Put – abstract service definition Put interface: a Repository interface that supports submission of one or more Surrogates into the Repository, thereby facilitating the addition of Digital Objects to the collection of the Repository. Questions: • How are Digital Objects submitted in first instance? • As ‘attachments’ to surrogate? As separate ‘deposit’ service? Embedded in surrogate? • Are some digital objects sufficiently different to warrant a separate interface e.g. large scale datasets? Augmenting interoperability across scholarly repositories, April 20/21 2006

  7. id id Put Put Put Put scenarios Create surrogate Create surrogate Augmenting interoperability across scholarly repositories, April 20/21 2006

  8. Put – abstract interface definition • data in • introspection request (“explain”) • put request with optional parameters (e.g.digital object ‘semantics’, metadata formats..) • data out • introspection response (“repository policy info”) • receipt confirmation and digital object identifier Augmenting interoperability across scholarly repositories, April 20/21 2006

  9. Next steps • Specify abstract service • Information models and APIs must be developed in manner neutral to implementation binding • Examine existing protocols and packaging formats to see how far they could implement the abstract service • Evaluate and decide whether something new required (protocols and/or packaging formats) Augmenting interoperability across scholarly repositories, April 20/21 2006

  10. Potential bindings for abstract service Simple approach? • HTTP with attachment?? • Use XOP to deal with transporting data efficiently?? Examine existing Protocols? • SRW Update • OKI OSID • JSR 170 &123 • Fedora Deposit API • XOP • Atom Examine existing packaging formats? • METS, MPEG DIDL, IMS Content Packaging Augmenting interoperability across scholarly repositories, April 20/21 2006

  11. Issues • How are Digital Objects submitted in first instance? • As ‘attachments’ to surrogate? Embedded in surrogate? • As separate ‘deposit’ or ‘obtain’ service? • Is there requirement for packaging service associated with ‘put’? • At what stage is surrogate created/packaged’? • Is there requirement for a separate packaging service? • Boundaries between put and ingest • What has already happened at point of ingest? regarding metadata and identifiers • Data integrity • Is there requirement to get back (export) exact object that was deposited? • Can look up of policy rules be done as a request to service registry? • How far is look up of policy rules automated? Augmenting interoperability across scholarly repositories, April 20/21 2006

  12. Issues (2) Can levels of interoperability be defined for deposit? • Level 0: lowest common denominator e.g. no authentication, local identifiers assigned • Level 1: added layer of constraint e.g. some authorisation, recognised identifier scheme • Level 2: more complex authorisation process, single default identifier scheme, semantic typing of data etc Augmenting interoperability across scholarly repositories, April 20/21 2006

  13. Questions and Discussion Augmenting interoperability across scholarly repositories, April 20/21 2006

More Related