Output – SAFIR: Images content model – overview

Title: Digital Library Project (SAFIR): Content model for images

Pages: all
Date Released: 29-01-2009

URI for Output: https://vle.york.ac.uk/bbcswebdav/xid-316149_3

Summary of contents:

The output provides a Fedora content model for images.

Although the content model is developed in the specific context of York, it provides a useful reasoned overview of the metadata requirements and model (for images, technical information, preservation metadata), conventions for datastreams, creating alternate versions, recording relationships, indentifiers, access control requirements, workflow, and rights.

Comments:

For organisations using the Fedora repository platform, the content model provides an example of a content model for images. More importantly it also provides a template for the development of other content models.

Output – SAFIR: Requirements Specification – OAIS

Title: Digital Library Project (SAFIR): Requirements Specification

Pages: 5-13
Date Released: 07 March 2008

URI for Output: https://vle.york.ac.uk/bbcswebdav/xid-89716_3

Summary of contents:

This section of the specification uses the Reference model for Open Archival Information Systems (OAIS) as a basis for analysing the repositories context and creating a specific reference model on which to base the requirements specification.

The following the OAIS model the analysis considers:

• the designated communities of the repository
• how it aproaches different functional areas (ingest, archival storage, data management, administration, preservation planning, and access)
• the information model and information lifecycle that has to be supported
• issues of interoperablity and integration

Comments:

This provides an example of a lightweight use of OAIS as a method of describing and analysing the context of a repository. As such it considers the whole information lifecycle as part of the planning process.

Output – SAFIR: Requirements Specification – Scenarios

Title: Digital Library Project (SAFIR): Requirements Specification

Pages: 14-15
Date Released: 07 March 2008

URI for Output: https://vle.york.ac.uk/bbcswebdav/xid-89716_3

Summary of contents:
Five scenarios are presented for the use of a mulitmedia repository.
Each is focused around a key type of use; they are:

• finding image materials
• sharing resources, advice and guidance
• streaming
• archival collections
• video materials

Comments:

The five scenarios are relevant to the growing knowledge/ innovation  base connected to the e-Framework.

Output – SAFIR: Requirements specifcation – overview

Title: Digital Library Project (SAFIR): Requirements Specification

Pages: all
Date Released: 07 March 2008

URI for Output: https://vle.york.ac.uk/bbcswebdav/xid-89716_3

Summary of contents:
The document presents a requirements specification for a digital library / multimedia repository and includes an overview of the methodology used to formulate it.

Comments:
This requirements specification as a whole provides a useful point of reference for any institution considering the management of these types of materials.

Output – OARS – OARS Functional Specification Document

Output Name: Output – OARS – OARS Functional Specification

Title: OARS Functional Specificationn
Number of pages or page numbers:30 pages
Section:

Date Released: 18 January 2008

URI for Output: http://oars.forcedmigration.org/wp-content/uploads/2008/01/oars-functional-specification.pdf

Also of interest might be:

http://oars.forcedmigration.org/wp-content/uploads/2008/01/oars-specification-migration.pdf

Depicting the current system in place for managing content.

Summary of contents:

Useful fucntional specification document for the OARs project.  Could be useful for instituions who need to look at exemplars of funtional specifications for their own needs, with useful fucntionality check list on page 27 (appendix 1) and for metadata requirements – appendix 2 – pages 28-30

Output – CAIRO: Content Model overview

Title:  Graphical Overview of a Cairo Content Model

Pages: all
Date Released: unknown

Summary of contents:

Graphical overview of a collection content model for archives – displays PREMIS and METS links.

URI for Output: http://cairo.paradigm.ac.uk/projectdocs/cairo_contentmodel_overview-2.png

Comments:

It is difficult to navigage and display this image as it is currently available.

Output – Nectar: Software Functional requirements

Title: Software for NECTAR: Functional requirement

Pages: all
Date Released: 2008

Summary of contents:
3 page specification of the functional requirements for NECTAR’s repository.
It covers key points including:

• Visibility / accessibility
• User interface
• File handling
• Support
• Management
• Demonstration
• Hardware [recommendations]

URI for Output: http://nectar.northampton.ac.uk/IR_Final_functional_spec.doc

Comments:
This requirement specifcation informs other institutions considering their requirements of a repository system.

Output -RIOJA -Costs and sustainability: overlay journal model

Title: Repository Interface for Overlaid Journal Archives:costs estimates and sustainability issues

Pages: 4-6
Summary of contents:

dftn: “Overlay journal – For the purposes of this report an overlay journal is defined as a quality-assured journal whose content is deposited to and resides in one or more open access repositories.”

p5-6 review the literature on the idea of an open access overlay or deconstructed journal.

Functions of journal publishing are delineated – any emerging model needs to address these:
“Journals are traditionally held to perform four “first order” functions (Meadows, 1974;
Rowland [2002], Roosendaal and Geurts (1997) as cited by Prosser (2005)):

• Registration: an author wishes to be acknowledged as the person who carried out a specific piece of research and made a specific discovery
• Certification: the author’s claims are tested through independent peer review, and it is determined that they are reasonable
• Awareness: the research is communicated to the author’s peer group
• Archiving: the research is retained for posterity

To those mentioned above Prosser adds the function of ‘Reward’ to the author.”
“Prosser, David C. (2005) Fulfilling the promise of scholarly communication – a
comparison between old and new access models, in Nielsen, Erland Kolding and Saur,
Klaus G. and Ceynowa, Klaus, Eds. Die innovative Bibliothek : Elmar Mittler zum
65.Geburtstag, pp. 95-106. K G Saur. (Also available at
http://eprints.rclis.org/archive/00003918) (Last accessed 31/07/2008)”

Comments:
note: The type of overlay journal proposed is one involving original submission to the overlay journal (simultaneous to or concurrent with submission to repository). The issue of overlay journals drawing on work submitted to other journals is not addressed/ in scope.

relevancy to categories
Any component of an emergent infrastructure wanting to be journal-like needs to consider these issues – as such they provide a baseline that RIOJA (and others) are going to address. As the survey results (noted elsewhere) indicate motivating academic researchers to use other forms of publication needs to interact with these issues.

Date Released: July 2008

URI for Output: http://eprints.ucl.ac.uk/12562/1/12562.pdf

Output – RIOJA – Journal Repository APIs

Title: RIOJA Journal-Repository APIs

Page: web page with related files

Summary of contents:
The page contains an introduction to and details about the xml APIs developed by RIOJA.
The APIs cover:
” Repository APIs

• getRepositoryInfo: Get information about the repository
• validateAuthor: Author validation
• getMetadata: Metadata exchange
• setStatus: Journal status change notification
• getStatus: Get journal status from repository
• getTrackbacks: Get repository trackbacks
• getStatistics: Get repository statistics
• getCurrentPaperInfo: Get current state of paper

Journal APIs

• getJournalInfo: Get information about the journal
• getStatus: Get submission status within the journal
• submit: Submit to journal from repository “

The final section is of note:

• Author managed papers are assumed by these APIs.

• ‘Why not just use OAI?

1. OAI is designed for metadata harvesting not as an immediate-reponse API to be used interactively. For RIOJA journals need to be able to get metadata dynamically during the submission process; OAI allows “wait” responses which require re-querying at a later time.
2. RIOJA allows for extraction of information before a paper is public on a repository (e.g. for integrated submission) before it would be available by OAI
3. RIOJA needs to track paper versions carefully. OAI does not include detailed paper version information.
   There should be a well-defined format for titles and abstracts with text formatting and equations so that they can display the same way on the journal and repository without further editing; OAI is very flexible but very vague.
4. RIOJA requires several other functions apart from extracting Metadata ‘

This rationale is also laid out in the final report page 9.http://eprints.ucl.ac.uk/12562/1/12562.pdf
This section also details similarities between some of RIOJA’s desired functionality and that subsequently developed in SWORD.

Comments:

As commented on the software – the API’s currently require custom versions – if this functionality doesn’t make it into a core release using/ supporting these API’s is unlikely to be sustainable.

The case to replace an accepted api has to be very strong.

Looking at these reasons OAI-PMH is deemed unsuitable:

1. no1 – In can see the case for this but given the model of overlay journal that the project has chosen (simlutaneous deposit to repository and for overlay publication). Although I’m not convinced this is the only possible workflow – this reason in itself is probably sufficient to examine alternative apis.
2. no.2  – this seems to be more to do with repository configuration than OAI-PMH as such. There is no reason that a repository can’t be configured for secure OAI-PMH metadata harvesting. Again a lot is predicated on a particular workflow.
3. no.3 – this is just plain wrong – versioning information is a question that relates to bibliographic metadata, OAI-PMH is a harvesting protocol. You can put whatever information you want into OAI-PMH. The observation is true for the simple dublin core metadata (oai_dc) that you must include with  a oai-pmh compliant repository – but this does not prevent you adding any other sets of information. It’s like saying you need an alternative to roads because your car needs lpg not petrol. It is certainly true that the information you get from most existing repositories (via OAI-PMH) does not support the needs of the an overlay journal but this, in itself, is not a reason to replace OAI-PMH.
4. no4 – impossible to comment.

I’m not suggesting that there isn’t a need to use something other than OAI-PMH for an overlay journal, but, aside from the first point (which could be significant enough in itself, but is predicated on a particular workflow) the summary arguments for implementing an entirely new api interface are are weak. In the Final Report possible overlap with SWORD (which developed independently while the project was running) is noted. It doesn’t examine SRW/SRU interfaces.

I’d suggest this is a good example of an infrastructure encountering the limits of accepted protocols but also of a development setting itself up for long term problems by effectively requiring 3rd party support for custom api’s [though, please note: this is not a comment on the effectiveness of these APIs for their purpose as a pilot/ proof of concept service]

Date Released: 2008

URI for Output: http://cosmologist.info/xml/APIs.html

Output – Lirolem – SUM: service arrangement

Title: LIROLEM – Service Usage Model

Section: Structure & Arrangement

Page: 6

Summary of contents:

(section reproduced)

“Services: Security, user management, submission, object store, metadata management, search, transcoding, rights management, dissemination and reporting.

Data Sources: User profile information; data object & object representation information (SIP); provenance, context, reference and fixity information (AIP); METS, IMS Packages, IEEE LOM, PBCore, Dublin Core/OAI-PMH (DIP). For SIP, AIP & DIP, see OAIS Reference Model.

Co-ordination:

The Security service authenticates and authorises the user to use the upload, metadata management, search, transcode and download services.

The User Management service creates, modifies and removes users and their permissions.

The Submission service permits the ingest of data objects and and object representation information (SIP) to the repository.

The Object Store service tracks data objects being submitted and disseminated from the repository.

The Metadata Management service, creates, modifies, verifies and removes all content metadata (descriptive, administrative and technical) in the repository, as well as private user metadata (notes, bookmarks) and shared user metadata (tags, comments). Metadata is linked to objects (items, sets, resources), Licences and users. Provenance, context, reference and fixity information (AIP) is comnpleted for the data object and validated.

The Search service allows a user to search data managed by the metadata management service, according to permissions granted by the user management service. The search service returns and displays search results drawing from the object store service and metadata management service.

The Transcoding service converts data objects from the source format to another format. This occurs at submission time to create preview thumbnails of images and clips of video and audio and also as requested by the user prior to dissemination. Transcoding is performed according to rights applied to the data object.

The Rights Management service requires the application of terms and conditions (a ‘Licence’) to the data object.

The Dissemination service permits the download of transcoded data objects and selected metadata (DIP) according to the Licence applied to the data object.

The Reporting service permits the audit and reporting of transactions by each of the above services.”

Comments:

this section presents the key service arrangement part of the SUM. this outlines the arrangement of software services and standards LIROLEM used to support the management and use of multimedia resources. As such it provides a point of reference for other software development and delineates what standards the development/ implementation used.

it would have been helpful if the SUM had explicitly linked standards with specific service arrangements – however the connections will, in general, be deducible.

Date Released: 2007 -11- 07 (Note: although this SUM is complete it is currently still on the eFramework development wiki – it may move)

URI for Output: https://e-framework.usq.edu.au/users/wiki/DevelopmentSUMLiroLem