Ana səhifə

National Library of Medicine Recommendations on nlm digital Repository Software


Yüklə 1.4 Mb.
səhifə7/15
tarix10.06.2016
ölçüsü1.4 Mb.
1   2   3   4   5   6   7   8   9   10   ...   15

Appendix C – DSpace Testing Results


Consolidated Digital Repository Test Plan

Last updated: March 4, 2008

Source Require-ments

Sub-

group

See Note 1

DSpace 1.4.2 Tests




Test ID

Test Plan Element







Test Procedure and Results

Score

(0-3)

Note 2

Notes

7.1.1 Ingest - Receive Submission




T










7.1.1.7

File types - Demonstrate that the system can ingest content in all the file formats listed as "supported" in Appendix B of the NLM DR Functional Requirements document (plus MP3 and JPEG2000), specifically: MARC, PDF, Postscript, AIFF, MPEG audio, WAV, MP3, GIF, JPEG, JPEG2000, PNG, TIFF, HTML, text, RTF, XML, MPEG.

Demonstrate that the system can ingest the following types of content: articles, journals, images, monographs, audio files, video files, websites, numeric data, text files, and databases.

Conduct this test element by ingesting the set of files listed in the Test File spreadsheet. (The files listed in this spreadsheet contain examples of all the file formats, and all the content types identified above.)


7.1.1.7

7.1.1.9


T

All files can be ingested. It is an implementation decision as to how the files/content are structured.
Testing of "primary bit stream" for HTML files (KK):

Shows primary bit stream file but hides all other files regardless of how related to HTML doc. Does not change original links in HTML doc.



3




7.1.1.1

Manual review - Demonstrate that the system has the capability to require that submitted content be manually reviewed before it is accepted into the repository.

Demonstrate that the system maintains submitted content in a staging area before it is accepted.

Demonstrate that the system notifies a reviewer when new content is ready for review.

(Also see tests for 7.1.4.1, 7.1.4.2, and 8.1.2.)



7.1.1.1

T

Workflow limited to 3 steps, although this will be generalized in next release, 1.5.

3




7.1.1.2

Review and acceptance workflow - Demonstrate that the system supports a workflow for the review and acceptance of submitted content. Demonstrate that the workflow includes the following functions:

- Receive and track content from producers; YES

- Validate content based on submitter, expected format, file quality, duplication, and completeness; NO

- Normalize content by converting content into a supported format for final ingestion into the repository; NO

- Human review of content; YES

- Acceptance or rejection of content or file format. YES




7.1.1.2,

7.1.1.10


T

JHOVE or similar needed for file validation.

Tools/scripts available to parse log files.



2




7.1.1.3

Reason for rejection - Demonstrate that the system records a set of identifying information or metadata that describes the reason for the rejection of submitted content. Demonstrate two cases: (1) automatic rejection, and (2) rejection by a human reviewer.

7.1.1.3

T

DSpace doesn't record the reason for rejection anywhere. The text of the reason that is manually entered by a reviewer is sent in an email back to the submitter, but the reason is not recorded in the DSpace database or the log file. The rejected item is kept as an "Unfinished Submission" in the submitter's My DSpace area, but the reason for rejection is not included with the item.

0




7.1.1.4

Rejection filter - Demonstrate that the system allows the creation of a filter that can be used to automatically reject submitted content. (This capability will eliminate the need for manual review of some submissions and resubmissions.)

7.1.1.4

T




0




7.1.1.5

Rejection notification - Demonstrate that the system can notify the producer or donor when submitted content is rejected. Demonstrate two cases: (1) notification after immediate rejection by an automated process, and (2) notification after rejection by manual review.

7.1.1.5,

7.1.1.11


T

1 - No

2 - Yes by email



1




(7.1.1.8)

Metadata types - Demonstrate that the system can ingest content with associated metadata in the following formats: all NLM DTDs, Dublin Core, MARC21, MARCXML, ONIX, MODS, EAD, TEI, PREMIS, METS. (NOTE: This test is covered by tests 8.1.1, 8.1.8, and 8.1.9)

7.1.1.8,

8.1.1,


8.1.8,

8.1.9


M/T

Dublin Core only

1 (M & T)




7.1.1.10

Format conversion - Demonstrate that the system has the capability to convert the format of a file being ingested to a desired supported format. As a test case, demonstrate that a WAV file can be converted to MP3 format when it is ingested. (An external tool may be needed to perform the conversion. If this is the case, demonstrate that the system can invoke the required external tool.)

7.1.1.10,

7.1.1.2


T

Definitely not a showstopper. External tool could possibly be used.

0




7.1.1.12

Resubmission - Demonstrate that the system can ingest a SIP that is resubmitted after an error in the SIP was detected and corrected. Demonstrate two cases: the resubmission can occur after an error was detected in (1) the content of the SIP, and (2) the metadata of the SIP.

7.1.1.12

T

If an item is rejected by a reviewer, an email containing the reason for rejection is sent to the submitter. The rejected item is kept in the submitter's My DSpace area as an "Unfinished Submission." The submitter can edit the item, correct any errors, and resubmit it. When format errors are detected during batch submission, the error is reported in the command window where the batch submission command is run. The administrator can manually correct the format errors, and resubmit the item in another batch submission. There is no duplication checking.

2




7.1.1.14

Versions - Demonstrate that the system can store, track, and link multiple versions of a file.

7.1.1.14

T

Planned for version 1.6 or 2.0

0




7.1.1.15a

Unique identifiers - Demonstrate that the system assigns a unique identifier to each object ingested. Demonstrate two cases: (1) a unique identifier assigned to a digital object, which may be comprised of a set of component files, and (2) a unique identifier assigned to each of the component files of a digital object.

7.1.1.15a,

7.1.1.15b



T

A handle is associated with each item. Each bitstream is uniquely identified.
The original Handle ID is retained during re-ingest and a new Handle ID is added when exported data are re-ingested. However, if the “replace” option is used, the re-ingest will only replace the files without adding a new Handle ID.

3




7.1.1.15b

Relationships - Demonstrate that the system can represent a parent-child relationship between content items. Demonstrate two cases: (1) an object having multiple components (e.g., a document having multiple pages, each in a separate file), and (2) an object having multiple manifestations (e.g., an image having both TIFF and JPEG files).

7.1.1.15b

T

Item=parent; bitstreams=children

Bitstreams can be "bundled," though this is not apparent to users.



HTML page can be designated as "primary"

1.5




7.1.1.16

Audit trail - Demonstrate that the system maintains an audit trail of all actions regarding receiving submissions (SIPs).

7.1.1.16

T

Info contained in log file but not easily usable.

1




7.1.2 Ingest - Quality Assurance




T










7.1.2.1

Virus checking - By design analysis, confirm that the system performs automatic virus checking on submitted content files.

7.1.2.1

T

Could be handled by external tool as part of pre-ingest process

0




7.1.2.2

Transmission errors - Demonstrate that the system uses MD5, CRC, checksums, or some other bit error detection technique to validate that each data file submitted is received into the repository staging area without transmission errors.

7.1.2.2

T

MD5 computed and stored with each bitstream. SPER project added code to compute own MD5, which is part of SIP.

1




7.1.2.3

Submission validation - Demonstrate that the system verifies the validity of submitted content based on the following criteria: submitter; expected file format; file quality (e.g., actual format of file matches the filename extension, and content of file is well-formed); duplication (e.g., existence of object in the repository); completeness of metadata; completeness of file set (e.g., all expected files are included in the submission).

7.1.2.3

T




0




7.1.2.4

QA UI - Demonstrate that the system allows NLM staff to perform manual/visual quality assurance on staged SIPs via a user-friendly interface.

7.1.2.4

T




2




7.1.2.5

Reaction to QA errors - Demonstrate that the system can react to specified QA errors in two ways: (1) request that the producer correct and resubmit the content, or (2) automatically modify the submission (e.g., converting to a supported format).

7.1.2.5

T

1 - Rejection email sent back to submitter.

2 - No automated way



1




7.1.2.6

File/batch accept/reject - Demonstrate that the system enables NLM staff to accept or reject submitted content (SIPs) at the file or batch level.

7.1.2.6

T

File review is manual (one x one). Batch review is not automated.

1.5




7.1.2.7b

Error reports - Demonstrate that the system generates error reports for ingest quality assurance problems.

7.1.2.7b

T

The DSpace statistics reports show a count of the number of item rejections and rejection notifications. The reports do not classify reasons for rejection, and do not include the text reason entered by the rejecting reviewer. Successful and unsuccessful batch ingests are not included in the statistics reports.

1




7.1.2.8

Adjustable level of manual QC - By design analysis, confirm that the system has the ability to adjust the level of manual ingest quality control needed, based on the origin of the file.

7.1.2.8

T




0




7.1.2.9

Audit trail - Demonstrate that the system maintains an audit trail of all actions regarding ingest quality assurance.

7.1.2.9

T

The DSpace log records when items are submitted, approved, and rejected. Reasons for rejection are not recorded. Successful and unsuccessful batch ingests are logged.

1




7.1.4 Ingest - Generate Descriptive Information / Metadata




M










7.1.4.1

Additional metadata - Demonstrate the entry of additional metadata (e.g. subject headings, names, dates, “curatorial” descriptive metadata - evaluative information that explains why an object is important, whether it was part of a larger collection (e.g., an exhibit), etc.).

7.1.4.1

M

Rather clunky

2




7.1.4.2

Validate metadata - Demonstrate ability to validate specified metadata elements.

7.1.4.2

M




0




7.1.4.4

Metadata storage - Demonstrate that metadata is stored in the database in a manner that conforms to repository reformatting and linked to their corresponding objects via an identifier.

o Demonstrates that basic descriptive metadata is also stored with the objects (e.g., unique identifier, title and date stored in the TIFF header) so that the objects can still be identified in the event that information in the database is corrupted.

o See Appendix D for examples of TIFF header metadata requirements.

(Use of external tool probable)



7.1.4.4

M

First bullet - 2; second bullet - 2

2




7.1.4.5

Required descriptive elements - Demonstrate the ability to recognize required descriptive elements.

7.1.4.5

M

would need an external tool; could write a program to do this

1




7.1.4.7

Audit trail - Demonstrate the creation of an audit trail of all actions.

7.1.4.7

M




1




7.1.3 Ingest - Generate AIP

Note 3

P










7.1.5 Ingest - Coordinate Updates

Note 3

P










7.2.1 Archival Storage - Receive Data

Note 3

P










7.2.2 Archival Storage - Manage Storage Hierarchy

Note 3

P










7.2.3 Archival Storage - Replace Media

Note 3

P










7.2.4 Archival Storage - Error Checking and Disaster Recovery

Note 3

P










7.2.5 Archival Storage - Provide Data

Note 3

P









1   2   3   4   5   6   7   8   9   10   ...   15


Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©kagiz.org 2016
rəhbərliyinə müraciət