ukoln is supported by: put functionality augmenting interoperability across scholarly repositories...
TRANSCRIPT
![Page 1: UKOLN is supported by: Put functionality Augmenting interoperability across scholarly repositories 20/21 April 2006 Rachel Heery, UKOLN, University of](https://reader036.vdocuments.net/reader036/viewer/2022062511/551609d055034694308b5016/html5/thumbnails/1.jpg)
UKOLN is supported by:
Put functionality
Augmenting interoperability across scholarly repositories
20/21 April 2006
Rachel Heery,
UKOLN, University of Bath
www.bath.ac.uk
a centre of expertise in digital information management
www.ukoln.ac.uk
![Page 2: UKOLN is supported by: Put functionality Augmenting interoperability across scholarly repositories 20/21 April 2006 Rachel Heery, UKOLN, University of](https://reader036.vdocuments.net/reader036/viewer/2022062511/551609d055034694308b5016/html5/thumbnails/2.jpg)
Augmenting interoperability across scholarly repositories, April 20/21 2006
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
![Page 3: UKOLN is supported by: Put functionality Augmenting interoperability across scholarly repositories 20/21 April 2006 Rachel Heery, UKOLN, University of](https://reader036.vdocuments.net/reader036/viewer/2022062511/551609d055034694308b5016/html5/thumbnails/3.jpg)
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
![Page 4: UKOLN is supported by: Put functionality Augmenting interoperability across scholarly repositories 20/21 April 2006 Rachel Heery, UKOLN, University of](https://reader036.vdocuments.net/reader036/viewer/2022062511/551609d055034694308b5016/html5/thumbnails/4.jpg)
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/
![Page 5: UKOLN is supported by: Put functionality Augmenting interoperability across scholarly repositories 20/21 April 2006 Rachel Heery, UKOLN, University of](https://reader036.vdocuments.net/reader036/viewer/2022062511/551609d055034694308b5016/html5/thumbnails/5.jpg)
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 of different 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)
![Page 6: UKOLN is supported by: Put functionality Augmenting interoperability across scholarly repositories 20/21 April 2006 Rachel Heery, UKOLN, University of](https://reader036.vdocuments.net/reader036/viewer/2022062511/551609d055034694308b5016/html5/thumbnails/6.jpg)
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?
![Page 7: UKOLN is supported by: Put functionality Augmenting interoperability across scholarly repositories 20/21 April 2006 Rachel Heery, UKOLN, University of](https://reader036.vdocuments.net/reader036/viewer/2022062511/551609d055034694308b5016/html5/thumbnails/7.jpg)
Augmenting interoperability across scholarly repositories, April 20/21 2006
7
Put scenarios
Put
Put
Put
id
id
Create surrogate
Create surrogate
![Page 8: UKOLN is supported by: Put functionality Augmenting interoperability across scholarly repositories 20/21 April 2006 Rachel Heery, UKOLN, University of](https://reader036.vdocuments.net/reader036/viewer/2022062511/551609d055034694308b5016/html5/thumbnails/8.jpg)
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
![Page 9: UKOLN is supported by: Put functionality Augmenting interoperability across scholarly repositories 20/21 April 2006 Rachel Heery, UKOLN, University of](https://reader036.vdocuments.net/reader036/viewer/2022062511/551609d055034694308b5016/html5/thumbnails/9.jpg)
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)
![Page 10: UKOLN is supported by: Put functionality Augmenting interoperability across scholarly repositories 20/21 April 2006 Rachel Heery, UKOLN, University of](https://reader036.vdocuments.net/reader036/viewer/2022062511/551609d055034694308b5016/html5/thumbnails/10.jpg)
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
![Page 11: UKOLN is supported by: Put functionality Augmenting interoperability across scholarly repositories 20/21 April 2006 Rachel Heery, UKOLN, University of](https://reader036.vdocuments.net/reader036/viewer/2022062511/551609d055034694308b5016/html5/thumbnails/11.jpg)
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?
![Page 12: UKOLN is supported by: Put functionality Augmenting interoperability across scholarly repositories 20/21 April 2006 Rachel Heery, UKOLN, University of](https://reader036.vdocuments.net/reader036/viewer/2022062511/551609d055034694308b5016/html5/thumbnails/12.jpg)
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
![Page 13: UKOLN is supported by: Put functionality Augmenting interoperability across scholarly repositories 20/21 April 2006 Rachel Heery, UKOLN, University of](https://reader036.vdocuments.net/reader036/viewer/2022062511/551609d055034694308b5016/html5/thumbnails/13.jpg)
Augmenting interoperability across scholarly repositories, April 20/21 2006
13
Questions and Discussion