Ana səhifə

National Library of Medicine Recommendations on nlm digital Repository Software


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

7.3.1 Data Management - Administer Database

Note 3

P










7.3.2 Data Management - Administer Perform Queries

Note 3

P










7.3.3 Data Management - Generate Report

Note 3

P










7.3.4 Data Management - Receive Database Updates

Note 3

P










7.4 Administration

Note 3

P










P1 - Generate AIP




P










P1-1

Generate AIP - Demonstrate the generation of AIPs from ingested SIPs that do not need normalization.

7.1.3.1,

7.1.3.2,

7.1.3.3,

7.4.1


P

Yes

2




P1-2

Generate AIP with normalization - Demonstrate the generation of AIPs from ingested SIPs that need normalization - Transform an unsupported format to an accepted format (See Appendix B).

7.1.3.1,

7.1.3.2,

7.1.3.3,

7.4.1


P

NO: No normalization and submission auditing (check the title field only).

0




P1-3

Derivative files - Demonstrate the generation of AIPs that consist of master files and derivatives.

7.1.3.6

P

Yes

1




P1-4

Master files - Demonstrate the generation of AIPs that consist of master files only.

7.1.3.6

P

Yes

1




P1-5

Store AIP in archival storage - Demonstrate the ability to transfer AIPs to Archive Storage.

7.1.5.1,

7.2.1.1,

7.2.1.2


P

Yes

2




P1-6

Store metadata in DB - Demonstrate the ability to generate and transfer Descriptive Information (metadata) to Data Management Database.

7.1.5.2,

7.3.4.1


P

Yes

2




P1-7

Link metadata and objects - Demonstrate the ability to store identification information in the Data Management database and link digital objects in the Archive Storage.

7.1.5.4

P

Yes

2




P1-8

Send confirmation - Demonstrate the ability to automatically send confirmation to ingest and/or receiver when AIP and metadata transfers are completed.

7.1.5.1,

7.1.5.3,


7.2.1.3,

7.3.3.3


P

Yes for manual ingest. Batch ingest has only on-screen confirmation and can optionally invoke workflow process. Batch ingest provides on-screen confirmation of item ingest; data shown includes all metadata values and bitstream file names. (Ed verified)

2




P1-9

Send statistical reports - Demonstrate the ability to automatically send statistical reports to ingest and/or receivers when AIP and metadata transfers are completed.

7.1.5.1,

7.1.5.3,


7.2.1.3,

7.3.3.3


P

No for manual ingest. The existing DSpace statistics reports do not include counts for items ingested via batch ingest. (Ed verified.)

0




P1-10

Send error reports - Demonstrate the ability to automatically send error reports to ingest and/or receivers when AIP and/or metadata transfers fail.

7.1.5.1,

7.1.5.3,


7.2.1.3,

7.3.3.3


P

No for manual ingest. Error reports are not sent for batch ingest. (Ed verified.)

0




P2 - Administer Archival Storage & Database




P










P2-1

Monitor transfer integrity - Demonstrate the built-in function to automatically monitor and report if any AIPs and metadata are altered or corrupted during data transfer and media change (refresh or replace).

7.2.2.1,

7.2.3.2,


7.2.4.1

P

Yes. The DSpace Checksum Checker verifies that checksum of every bitstream file in the repository has not changed. The Checker can be configured to run regularly using the Unix cron. The Checker creates a log file that contains the results of the checksum checker run.

2




P2-2

Check data/referential integrity - Demonstrate the built-in function to perform routine and special referential and data integrity checks (CRC or checksums) on files in the Archive Storage and Data Management Database.

7.2.4.2,

7.3.1.1,

7.3.1.2,

7.4.4


P

Data integrity checks (checksum) for data transfer but not for version upgrades and format migration (7.4.4.). Also no referential integrity checks (7.3.1.2).

1




P2-3

Routine configuration for data/referential integrity - Demonstrate the ability to allow for routine configuration.

7.2.4.2,

7.3.1.1,

7.3.1.2,

7.4.4


P

See comments in P2-2.

1




P2-4

Disaster recovery - Demonstrate the ability to allow for disaster recovery including data backup, off-site data storage, and data recovery.

7.2.4.3

P

Yes. Can be recovered from backup or exported data)

2




P2-5

User views - Demonstrate the ability to allow for customized user views of the contents of the storage (create, maintain, and access).

7.3.1.4

P

Yes with external tools.

2




P2-6

System CM - Demonstrate the ability to allow for configuration management of the system hardware and software.

7.4.2

P

Yes

2




P2-7

Database CM - Demonstrate the ability to allow for configuration management of the Data Management Database such as table, schema definitions, etc.

7.3.1.3

P

Yes

2




P2-8

Delete AIPs - Demonstrate the ability to allow the authorized staff to delete AIPs from the repository including: removing the digital object's files and retaining associated metadata, or removing both the files and metadata.

7.4.3.4

P

Yes

2




P2-9

Coordinate AIP removal - Demonstrate the ability to generate an alert and coordinate the removal of an AIP with maintenance of metadata held in other systems.

7.4.3.5

P

No

0




P2-10

File migrations - Demonstrate the ability to allow the authorized staff to schedule and perform file migrations or migration on request for batched and individual files by authorized staff.

7.4.3.6

P

No

0




P2-11

Request DIPs for update - Demonstrate the ability to allow the authorized staff to request DIPs for file migrations and data updates.

7.3.4.1,

7.3.4.2,

7.3.4.3,

7.4.3.1,

7.4.3.2,

7.4.6.2


P

Yes. DIPs can be requested and exported. However, it provides no tools for file migration and data updates.

1




P2-12

Re-ingest updated DIPs - Demonstrate the ability to allow the authorized staff to reingest updated DIPs as SIPs.

7.4.3.3

P

Yes. Exported data can be re-ingested with a replacing option. Ed will verify whether the re-ingest will also remove a deleted file from an item.

2




P2-13

Support query requests - Demonstrate the ability to receive, retrieve, display, and deliver data for query requests from other functions such as Ingest, Access, and Administration.

7.3.2.1,

7.3.2.3,


7.4.6.1

P

Yes

2




P2-14

Query requests from different storage locations - Demonstrate the ability to handle query requests with required data to be sourced from different storage locations.

7.3.2.2

P

Yes. Files can be optionally stored on a network file system.

2




P2-15

Queries against all metadata - Demonstrate the ability to run data queries against all metadata used to manage the repository.

7.3.2.4

P

Yes

2




P2-16

Audit trial - Demonstrate the creation of an audit trail of all actions including who, when, how, what and where for Archive Storage and Data Management Database.

7.1.3.4, 7.1.5.6, 7.2.1.4, 7.2.2.3, 7.2.5.2, 7.3.2.5, 7.3.3.7, 7.3.4.6, 7.4.3.7, 7.4.6.4

P

No provenance for record update and no email/screen confirmation for delete/withdrawal.

1




P2-17

Generate reports - Demonstrate the ability to receive, generate, display, and deliver management information reports and statistics such as summaries of repository holdings by category, summaries of updates by category, user codes, etc., usage statistics for access to repository holdings, and descriptive information for a specific AIP.

7.3.3.1, 7.3.3.2, 7.3.3.5, 7.3.4.4

P

Perl was installed to enable DSpace's statistics tools to be exercised, and the reports were viewed by the entire working group. // Monthly and total repository lifetime reports can be generated that show the total number of archived items, but the items are not broken down into categories (e.g., collections, submitters). The total number of archived items shown in the report includes all items ingested via the web interface and by batch; the "items ingested" counts only those items ingested via the web interface (does not include items ingest by batch). Counts are shown for creation, update, and deletion of items, bitstreams, bundles, collection, and communities; but these counts are only for "all items," "all collections," etc. Updates to the metadata of items are not counted or otherwise reported. Counts are reported for total user logins, total item views, bitstream views, searches performed. User logins are also reported by userid. Items are identified that were viewed more than a certain number of times. Note: Some actions shown in the "All Actions Taken Report" were unclear.

1




P2-18

Schedule reports - Demonstrate the ability to generate reports in an ad-hoc manner, automatically or to be triggered by a calendar or by a specific system event.

7.3.3.4

P

The Perl-based DSpace statistics report generator can be run manually by an administrator, or scheduled to run at any desired frequency (e.g., daily, weekly, monthly) using the Unix cron task scheduler. However, only two type of reports can be generated: total repository activity up through the current date/time, and monthly activity reports. DSpace can be configured so that reports can be viewed by all users, or only by administrators.

1




P2-19

Time period for reports - Demonstrate the ability to allow the user to specify a time period or set of time periods for reports and statistics.

7.3.3.6

P

DSpace's Perl-based statistics and report generation tools only enable the creation of monthly reports.

0




P3 - Generate DIP




P










P3-1

Generate DIP for access requests - Demonstrate the generation of DIPs by putting AIPs and Descriptive Information back together for access requests.

7.1.5.5,

7.2.5.1,

7.4.6.2


P

Yes

2




P3-2

Generate DIP for object maintenance - Demonstrate the generation of DIPs by putting AIPs and Descriptive Information back together for content/metadata update, versions upgrades and format migration by authorized staff.

7.4.6.2,

7.4.3


P

Yes

2




7.4.1 Administration - Negotiate Submission Agreement




T










7.4.1.1

Manage submission agreements - Demonstrate that the system manages information regarding submission agreements: that it tracks negotiation status and written submission agreements, and that it maintains schedules.

7.4.1.1

T




0




7.4.1.2

Edit submission agreements - Demonstrate that the system allows submission agreements to be edited, based on the access level of the user.

7.4.1.2

T




0




7.4.1.5

Terms of submission agreements - Demonstrate that the system stores the terms of submission agreements, and uses the terms to monitor, review, and process submissions.

7.4.1.5

T




0




7.4.1.6

Audit trail - Demonstrate that the system maintains an audit trail of all actions related to submission agreements.

7.4.1.6

T




0




7.4.2 Administration - Manage System Configuration




T










7.4.2.1

Monitor repository functionality - Demonstrate that the system monitors the functionality of the entire repository.

7.4.2.1

T

Functions are monitored but not entire repository.

0




7.4.2.2

System configuration - By design analysis, confirm that the system maintains the integrity of the system configuration.

7.4.2.2

T




0




7.4.2.3

Audits operations - Demonstrate that the system audits system operations, performance, and usage.

7.4.2.3

T

In log file.

2




7.4.2.4

Data management information - Demonstrate that the system collects and can display system information concerning Data Management.

7.4.2.4

T

Statistics reports show the number of items, communities, collections, bitstreams, and bundles that are created, updated, and deleted in each month, and totaled for all months of operation. Additional detailed information is collected in the log file, but no report is generated containing this detail. No information collected or reported on metadata updates. Reports don't breakdown activity by specific user, community, or collection.

1




7.4.2.5

Operational statistics - Demonstrate that the system collects and can display operational statistics concerning Archival Storage.

7.4.2.5

T

Statistics reports show total number of items in archive, and number of items archived each month. Batch imported items are included in "total in archive", but not included in "items archived". No breakdowns by collection, community, user. No totals for bitstreams. Additional detailed information is recorded in the log file and history files, but no tool is currently available to report on this information.

1




7.4.3 Administration - Archival Information Update
















7.4.5 Administration - Audit Submission




T










7.4.5.1

Audits - Demonstrate that the system can support an audit procedure to verify that submissions (SIP or AIP) meet specified requirements of the repository. The audit method may be based on sampling, periodic review, or peer review. [See NLM DRD Functional Requirements document, section 7.4.5 for description of audit requirements.] (Also partially covered by 7.2.4.2)

7.4.5.1

T




0




7.4.5.2

Metadata audit - Demonstrate that the system can audit metadata as part of the audit procedure.

7.4.5.2

T




0




7.4.5.3

Audit rejection - Demonstrate that the system can reject components of audited information packages, based on specified audit requirements.

7.4.5.3

T




0




7.4.5.4

Audit report - Demonstrate that the system can generate an audit report, based on the results of periodic audits of SIPs and AIPs.

7.4.5.4

T




0




7.4.5.5

Audit trail - Demonstrate that the system maintains an audit trail of all actions regarding the auditing of SIPs and AIPs.

7.4.5.5

T




0




7.4.6 Administration - Activate Requests




P










7.6.1 Access - Coordinate Access Activities - User Access




A










7.6.1.1

Manage user permissions - Demonstrate the access controls for multiple permission levels and user privileges.

7.6.1.1

A

Discrete admin accounts; authenticated users can be limited to specific functions or collections. Collections can be hidden from public (anonymous) view.

2




7.6.1.2

Manage user restrictions - Demonstrate multiple levels of access restrictions for NIH employees and general public based on licensing terms, embargo periods, IP range restrictions, workstation access, and other possible legal restrictions.

7.6.1.2,

7.6.1.3


A

No built-in logic to tie access controls to licensing data. No built-in access controls based on IP ranges. Collections could be hidden from anonymous users via the Authorizations policies.

1




7.6.1.4

Manage user settings - Demonstrate access settings allow staff to add or edit descriptive metadata

7.6.1.4

A




3




7.6.1.7

Audit users - Demonstrate access mechanisms can identify individual users and maintain audit log of user actions.

7.6.1.7

A

Metadata edit actions are not logged in a useable way.

0




7.6.1.5

Perform maintenance tasks - Demonstrate maintenance access including adding new files, manipulating images, editing metadata, performing format conversions/migrations, and troubleshooting system problems.

7.6.1.5

A

Maintenance actions demonstrated by Ed. Some can be through the UI, some are command-line only.

1




7.6.1.6

Manage system rights - Demonstrate ultimate system rights access for NLM system administrators and programmers.

7.6.1.6

A

OCCS staff testing has demonstrated system-level access for both the system files and the Oracle schema.

1




7.6.1 Access - Coordinate Access Activities - Rights/Data Control of Objects




A










7.6.1.8

Manage access rights - Demonstrate access rights and conditions to materials and storage directories provide for a combinational of create/write; edit; read; delete privileges.

7.6.1.8

A

via Authorizations section

3




7.6.1.9

Manage metadata rights - Demonstrate access rights may be associated with the metadata relating to an individual object

7.6.1.9

A

Authorizations do not apply to metadata, only to Communities, Collections, Items, Bundles and Bitstreams. Item metadata is always viewable.

0




7.6.1.13

Manage relationships - Demonstrate access rights and conditions can be inherited from a parent object to any child object.

7.6.1.13

A

via Authorizations section

3




7.6.1.14

Manage relationships - Demonstrate access rights and conditions can be assigned to an object on an individual or group basis at same time.

7.6.1.14

A

via Authorizations section

3




7.6.1.16

Automated retrieval - Demonstrate objects in the repository are accessible for data mining or automated retrieval.

7.6.1.16

A

DSpace does not internally facilitate automated retrieval of its objects, only the metatdata via OAI-PMH. Full-text indexing by external source may be facilitated through a Java API in the future (JSR-170).

0




7.6.1.17

Metadata access - Demonstrate access to deleted and retracted metadata is retained.

7.6.1.17

A

Minimal audit history in a cumulative log file accessible via scripts, but history of metadata actions is sparse.

0




7.6.1.18

Metadata harvesting - Demonstrate metadata harvesting following the OAI-PMH guidelines.

7.6.1.18

A

DSpace will allow external hosts to harvest its metadata via OAI-PMH. It does not do harvesting (bring in metatdata).

2




7.6.1.10

Access rights - Demonstrate access rights and conditions of use are applied to each digital object and its related metadata and are machine readable and actionable.

7.6.1.10,

7.6.1.11


A

License can be associated with a Collection or a specific item. There is no logic triggered by the license, which is just an unstructured text file.

1




7.6.1.12

Access conditions - Demonstrate access conditions are specific to a digital object.

7.6.1.12

A

Only collection-level restriction - denial of read access to anonymous.

0




7.6.1.15

Free/Restricted access - Demonstrate free (items available via internal/external delivery mechanisms) and restricted access (access permission must be satisfy various criteria) status for objects, files, metadata, etc.

7.6.1.15

A

Verified collection-level restriction via Authorizations (read access denied to anonymous users). No file-level restriction is available.

1




7.6.1 Access - Coordinate Access Activities - Search and Retrieval




A










7.6.1.19

508 compliance - Demonstrate the search interface is web-accessible and Section 508 compliant.

7.6.1.19

A

User interface is entirely web-based. Tested with Fangs and Accessibility Add-on in Firefox. Tables are used for layout, but alt tags may be input for images. Content scaled logically when CSS is disabled. Unable to validate HTML code.

2




7.6.1.20

Search features - Demonstrate search includes: metadata, full-text, standard boolean, proximity, "more like" this"

7.6.1.20,

7.6.1.21,

7.6.1.22,

7.6.1.23,



7.6.1.24

A

Among the features listed, only metadata and, probably, full-text, are supported. Searching across DSpace needs additional investigation and it isn’t clear how much configuration of Lucene (the underlying search engine) can be done.

1




7.6.1.25

Search results display - Demonstrate search results display includes date sort; relevancy ranking; alpha by author or source.

7.6.1.25

A

Help mentions category search - how?

0




7.6.1.26

Relevancy ranking - Demonstrate whether relevancy ranking can be manipulated via system as well as user defined settings.

7.6.1.26

A




0




7.6.1.29

Federated search - Demonstrate federated searching of different repository sites.

7.6.1.29

A




0




7.6.1.30

Advanced search - Demonstrate advanced search includes search history; saved searches; saved citation lists/bibliographies; alerts; various functions and formats; dynamic selection of delivery media without recreating search query.

7.6.1.30

A




0




7.6.1.31

Display formats - Demonstrate a variety of standard display formats are provided and whether they are customizable by user

7.6.1.31

A




0




7.6.1.32

Alternate search interfaces - Demonstrate availability of alternate search interfaces for mechanisms such as handhelds and PDAs.

7.6.1.32

A




0




7.6.1.33

Object access - Demonstrate access to the appropriate copy of the identified item (text, image, video, etc.)

7.6.1.33

A

The record does describe the bitstream formats, but doesn't suggest the "appropriate" one

1




7.6.1.34

Library holdings - Demonstrate integration of search results with library holdings.

7.6.1.34

A




0




7.6.1.35

Response time - Demonstrate acceptable response time.

7.6.1.35

A

Good so far, but with very limited content. SPER testing suggests response time may suffer with large data sets.

1




7.6.1.36

External search engines - Demonstrate searching by outside search engines such as usa.gov, Google, and Yahoo.

7.6.1.36

A

Several DSpace installations have been indexed by search engines.

2




7.6.1.37

External system access - Demonstrate external access to other repositories or systems performing web harvesting functions.

7.6.1.37

A




2




7.6.1.38

Language support - Demonstrate how multiple languages and non-Roman scripts are supported in search, retrieval and display.

7.6.1.38

A

demonstrated display of Chinese characters. Verified search & retrieval using Feng Chia University DSpace instance.

2




7.6.1.39

Versioning - Demonstrate access to all versions of digital objects in the repository is provided.

7.6.1.39

A

No versioning functionality present. Any and all parts of an item will be accessible, but no relationships between parts can be conveyed.

0




7.6.1.40

Search settings - Demonstrate system settings and user-defined settings in the search functions are provided.

7.6.1.40

A

Only default system-provided search settings are offered, through regular and advanced search interface.

0




7.6.2 Access - Generate DIP




A










7.6.2.1

Integrate holdings - Demonstrate integration of search results with library holdings.

7.6.2.1

A

Open-URLs can be utilized on item pages for possibly OPAC querying against the DC metadata associated with the item.

1




7.6.2.2

Retrieval and notification - Demonstrate the generation function accepts a dissemination request, retrieves AIP from archival storage and moves a copy of the data to a staging area for further processing, and creates and sends a report request to data management to obtain appropriate metadata.


7.6.2.2,

7.6.2.3,


7.6.2.4

A




3




7.6.2.7

Audit trail - Demonstrate an audit trail of all actions is created and stored.

7.6.2.7

A

Info contained in log file but not easily usable.

0




7.6.2.5

Response and delivery - Demonstrate that the prepared DIP response is placed in the staging area and a message is generated and sent to Coordinate Access Activities that the DIP is ready for delivery.

7.6.2.5

A

This aspect of OAIS is not currently modeled by DSpace. DSpace does not appear to use a staging area but serves requested content directly from the Asset Store.

0




7.6.2.6

Storage retrieval - Demonstrate that Generate function accesses data objects in staging storage and applies the requested processes if special processing is required.

7.6.2.6

A

See above.

0




7.6.3 Access - Deliver Response




A










7.6.3.1

Web-accessibility - Demonstrate the display interface is web-accessible.

7.6.3.1

A

Checked using Fangs and the Accessibility Checker Add-on. It uses tables for layout purposes, but was unable to validate the HTML output.

1




7.6.3.2

Downloading - Demonstrate export function that provides XML output for batch downloads

7.6.3.2

A

Must be done through externally scripting

0




7.6.3.3

Saving content - Demonstrate users are allowed to save digital content to a hard-drive, e-mail, and/or save search results.

7.6.3.3

A

Documents may be downloaded. There does not appear to be a function for emailing or saving search results.

1




7.6.3.5

System notification - Demonstrate a confirmation message is returned to the Coordinate Access Activities section after response has been sent.

7.6.3.5

A

This aspect of OAIS is not currently modeled by DSpace.

0




7.6.3.6

Audit trail - Demonstrate an audit trail of all actions is created and stored.

7.6.3.6

A

Info contained in log file but not easily usable.

0




7.6.3.4

Response request - Demonstrate a response request is received from Coordinate Access Activities


7.6.3.4

A

Demonstrated retrieval of objects via the UI without issue.

2




8.1 Metadata Requirements




M










8.1.1

Metadata formats - Demonstrate that the system can accept metadata associated with objects in at least the following formats: All NLM DTDs, Dublin Core, MARC21, MARCXML, ONIX, MODS, EAD, TEI.

8.1.1

M/T

Does accept it but minimally

1 (M & T)




8.1.2

Metadata checks - Demonstrate the built-in checks on the incoming metadata. Records not containing the minimally defined set of fields should be flagged as problems, either to be returned to the submitter, or sent locally for metadata enhancement.

8.1.2

M

Batch - 0; manual - 1

0-1




8.1.5

Metadata updates - Demonstrate the ability to allow for metadata updates.

8.1.5

M

Rather clunky

2




8.1.6a

Metadata search and display - Demonstrate the ability to search and display metadata (use of external tool possible).

8.1.6a

M




2




8.1.8

PREMIS - Demonstrate standards compliance for PREMIS (use of external tool possible).

8.1.8

M/T




0 (M & T)




8.1.9

METS - Demonstrate standards compliance for METS (use of external tool possible).

8.1.9

M/T

Only exports collections/files in METS (via command line, not the web interface) and is working on METS import capability.

1 (M & T)




App A

Descriptive metadata - Demonstrate that the minimum descriptive metadata requirements described in Appendix A are accepted.

App A

M




2




9.1 Additional Technical Infrastructure Requirements




T










9.1.1

OAI-PMH - Demonstrate that the system can respond to OAI-PMH requests as a data provider.

9.1.1

T

DSpace can be a provider but does not itself harvest and incorporate other data. Key functions: identify (handshake), listsets (list of collections), listidentifiers (list of IDs), listmetadataformat (list of metadata formats), listrecords (metadata only, no bit stream), etc.

2




9.1.2

Z39.50 - By design analysis, confirm that the system can respond to data requests using the Z39.50 standard.

9.1.2

T




0




9.1.3

SRU/SRW - By design analysis, confirm that the system can respond to data requests using the SRU and SRW data access standards.

9.1.3

T




0




9.1.4

SOAP - Demonstrate that the system can respond to web service requests using SOAP.

9.1.4

T




0




9.1.5

UNICODE - Demonstrate that the system supports UNICODE.

9.1.5

T




3




9.1.6

OpenURL - By design analysis, confirm that the system is compliant with OpenURL.

9.1.6

T




0




9.1.7

Z39.87 - By design analysis, confirm that the system supports the Z39.87 image metadata standard.

9.1.7

T




0














































Notes:

1. Subgroups: A=Access, M=Metadata, P=Preservation, T=Technical Infrastructure
















2. Score indicates the extent to which the test element could be demonstrated: 0=None, 1=Low, 2=Moderate, 3=High










3. Preservation tests - These sections of the functional requirements are covered by Test Plan sections P1, P2, and P3, which were defined by the Preservation subgroup to facilitate testing.




4. Test elements having blue background are the subject of outstanding questions from the Access subgroup.




























10. Additional Observations
















10.1

Back button on browser cannot function as a navigation tool all the time, and there is no other navigation tool. (KK)







10.2

Files are just listed in the order they were ingested and cannot be sorted by item (KK).













10.3

Sub-community hierarchies get lost in the collection selection window during submission (FK).







10.4

Batch ingest does allow customized licenses to be included for different items (EL).













10.5

Internal errors were generated in the following instances:
1. When more than one user to edit a record simultaneously. The record does not appear to be locked and DSpace generates internal system errors (JM, DB).
2. While trying to edit policies for a collection (FK)


10.6

DSpace creates two XML files for item(s) containing both DC and NLM/DC metadata (such as permanence) during the export process. The dublincore.xml for all DC elements and metadata_nlm.xml for all NLM/DC elements. (EL)

10.7

DSpace tracks every action as an entry in a text-based log file but the log file doesn’t reveal the specific action taken. The History file, on the other hand, records more specific details than the log file but some of the entries don’t seem related to the actual action. For example, adding a subject and modifying an item type are recorded as updated bit streams and updated bundles in the history file. No tools are provided to access the history file. We should check with the DSpace community to see if there are any available tools already. (EL)



1   ...   4   5   6   7   8   9   10   11   ...   15


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