Product requirements
Product Requirements Matrix
Core Requirement | Summary | Who must execute it? | Priority level: Must have/Should have/Could have/Won't have | Back end or front end feature | Metadata or Services group? | Systems possible | Already available in DSpace? | Relationship to DSpace; Notes/Decisions | Tickets | Reference links |
---|---|---|---|---|---|---|---|---|---|---|
Standard repository features- front end | Searching, Facets, thumbnails, search results interface, item interface, customizable header footer and landing page | Devs or Gabe/Chin | Must Have | Front | S | Blacklight DSpace custom DSpace standard | Yes | |||
Primary Search- full text indexing | search full text via PDF OCR | Devs | Should have | Front | S | Yes | - DSPAC-86Getting issue details... STATUS | How to set up full text indexing in DSpace: https://wiki.duraspace.org/display/DSPACE/Configure+full+text+indexing | ||
Primary Search- metadata indexing | Search item metadata | Devs | Must have | Front | S | Yes | ||||
Advanced search- functionally identical to DSpace | --Applied facets also function as filters --DSpace lets you select which fields are searchable via advanced search. | Devs | Must have | Front | S | Yes | Advanced search with facets applied: http://155.247.166.104:8080/xmlui/discover?filtertype_0=subject&filtertype_1=title&filter_relational_operator_1=equals&filter_relational_operator_0=equals&filter_1=&filter_0=%7CTemple+University&filtertype=subject&filter_relational_operator=equals&filter=explicit Instructions for customizing which DSpace fields https://wiki.duraspace.org/display/DSPACE/Modify+search+fields | |||
Advanced search- collating fields | Combining two fields separated on the back end for practical reasons into a single field in the advanced search UI | Devs | S: Should have M: Should have | Back | M S | DSpace back end | No | Definitely a developer task | See: http://kim-shepherd.blogspot.com/2010/11/discovering-discovery-dspace-solr-tips.html | |
Customizable header and footer- configurable by devs | One time configuration. It should remain relatively static, but might need to be updated occasional | Devs | Must have | Front | S | Sort of: requires lightweight code changes | ||||
Customizable header and footer- configurable by site admin | Would be configurable by site admins via a CMS | Devs | Could have | Front | S | No | ||||
Item display page- image viewer- other formats | When appropriate, all visual items would display at full size in an image viewer. | Devs | Could have | Front | S | No | This would exceed DSpace's current capabilities | |||
Item display page- image viewer- PDF specific | When appropriate, PDFs would display at full size in an image viewer. | Should have | S | No | This would exceed DSpace's current capabilities | |||||
Item display page- just thumbnails + downloads | A thumbnail leading to a download link would appear on each item page | Devs | Must have | Front | S | Yes | This would equal DSpace's out-of-the-box functionality | |||
Responsive site design | Devs | Should have | S | Yes, via Mirage2 theme | ||||||
DOIs- autogeneration | DOI generated automatically when an item is created. Each record will be assigned a DOI, while individual files and collections/communities will not. | Gabe/Chin | S: Must have M: Must have | Back | S M | DSpace back end | Yes | We'd be using the Datacite procedure described on this page. Versioning would not be used, so I believe the metadata would not be sent back to Datacite if updated. | Out of the box DOI integration: https://wiki.duraspace.org/display/DSDOC6x/DOI+Digital+Object+Identifier | |
Customize Facets for display | Decide which fields are faceted, control facet order. This doesn't have to be doable by non-devs, and the fields used as facets would be decided prior to any development work. This list of fields would not change. | Gabe/Chin | Must have | Front | S | Blacklight DSpace custom | Yes | - DSPAC-71Getting issue details... STATUS | Procedure: https://wiki.duraspace.org/pages/viewpage.action?pageId=30218817 | |
Citation generation | Automatic Citation generation, either via DSpace's native features or some sort of external plugin that functions through the interface | Devs | Should have | Unclear | S | Blacklight DSpace custom DSpace standard | No | What the services group has requested is the sort of functionality offered by EBSCO or most equivalent systems. Click on 'cite' on this page to see an example. DSpace doesn't offer out-of-the-box citation generation. They suggest several ways to implement a java-based solution on this page. | - DSPAC-73Getting issue details... STATUS | https://wiki.duraspace.org/display/DSPACE/Citation+Generation |
Direct Submission form- form | A direct submission form for use by faculty | Gabe/Chin | Must have | Back | S | DSpace back end | Yes | - DSPAC-68Getting issue details... STATUS | Documentation: https://wiki.duraspace.org/display/DSDOC6x/Submission+User+Interface Input forms customized via: https://github.com/DSpace/dspace-release/blob/master/config/input-forms.xml (The form-map maps collection handles to forms.) Item submission process customized via this: https://github.com/DSpace/DSpace/blob/master/dspace/config/item-submission.xml (The process-map maps collection handles to a particular Item Submission Process.) slide deck: https://www.slideshare.net/bramluyten/secrets-of-the-dspace-submission-form | |
Direct Submission form- Public access via web | A way to authenticate users submitting through the form, probably via Shibboleth | Gabe/Chin | Must have | Back | S | DSpace back end | No | The plan is to use Shibboleth to restrict access to the direct submission form (as in the Shibboleth Authentication section of this page). This submission form + Elements would be the two ways external users could submit on their own to the IR. In either case the items would enter an approval queue that would be vetted by the repo manager. External to DSpace in some regard. The plan is to embargo some items via DSpace's out-of-the-box embargo functionality. The URLs of embargoed items end with ' isAllowed=n' rather than ' isAllowed=y' | - DSPAC-82Getting issue details... STATUS | https://wiki.duraspace.org/display/DSDOC6x/Authentication+Plugins Tim Donohue's description of how to execute our use case: |
Homepage- customizable by devs | Customizable display layer, including homepage, subpage, configurable interface, customizable facets, etc. This does not have to be configurable by the site admins, just by devs, and such pages should remain mostly static. | Devs Gabe/Chin | Must have | Front | S | Blacklight DSpace front end custom DSpace front end standard | Yes, lightweight code changes | - DSPAC-76Getting issue details... STATUS | 'Making DSpace your own' webinar https://www.slideshare.net/DuraSpace/42418-making-dspace-your-own-webinar-recording Here's the custom code from the webinar | |
Homepage- customizable by repo manager | updatable on the fly through a CMS | Devs | Could have | Front | S | |||||
Homepage, with community landing pages. | with links to search results corresponding to DSpace communities and collections. just search results. | Should have | S | Homepage: Landing page: https://ecommons.cornell.edu/handle/1813/52201 Homepage: Landing Page: https://atmire.com/preview/handle/123456789/5286 | ||||||
Homepage, no landing pages, just links to canned search results, no explanatory text | No landing pages for Data, ETDs, etc. | Must Have | S | Homepage: Home page (mirage2): | ||||||
Theming- consistent throughout site | The skin would cover all aspects of site | Should have... However, this depends on how seamlessly the two systems can be interlaced so it's hard to give a firm ranking. | S | |||||||
Theming- blacklight themeing for homepage and search, but other site areas are raw DSpace pages | Must have (Tentative) | S | Fully shielding DSpace would be preferable, but if visual consistency can be maintained it could be fine to switch between skinned pages and raw DSpace pages. There are also structural concerns, for example how would the breadcrumb trail on a page like this be handled. | |||||||
Documentation portal- external to site | A place to contain our policies and advisory text | Devs Gabe/Chin | Must have | Front | S | Blacklight DSpace front end custom | External to DSpace, as well as a part of the custom homepage | - DSPAC-77Getting issue details... STATUS | ||
Customize item display page- structural | Ability to customize the features of each page. For example, adjusting thumbnail size. This would be a one time thing, done by devs. The repo manager does not need to be able to do this on the fly through a CMS. | Devs Gabe/Chin | Could have | Front | S | Blacklight DSpace front end custom DSpace front end standard | Doable out-of-the box in DSpace up until a point. Would require dev support for more sophisticated integrations. Each item page would be structurally identical, and the template for these pages would only need to be implemented once, by devs. The desired features are: --Thumbnail --View/download option. View would open the item for viewing in a new tab as in DSpace --Facets | - DSPAC-79Getting issue details... STATUS | Thread: https://groups.google.com/forum/#!searchin/dspace-tech/orcid|sort:date/dspace-tech/f_BZETZYXiM/mavRYst_AwAJ | |
Item display page- Introductory page | Selected fields would be highlighted and enlarged for readability | Must have | Front | S | DSpace example | |||||
Item display page- full list of metadata fields | All metadata values listed next to their dc.fieldname | Must have | Front | S | DSpace example | |||||
Visual improvements/aesthetic upgrades to the interface, including search results, item view, homepage, etc. | Customizing colors, fonts, etc. This doesn't have to be done through a CMS; it could be a one-time thing implemented by a dev that would remain static after that. | Devs | Must have | Front | S | Blacklight DSpace front end custom DSpace front end standard | ||||
Search results interface- structural | For example, the structure of this page | Devs | Could have | Front | S | Blacklight DSpace front end custom DSpace front end standard | It could look and function similarly to the blacklight search interface. Once configured by a dev it wouldn't have to be changed. | |||
Search results interface- Metadata preview | For example, the preview fields featured on this page | Devs | Must have | Front | S | Once configured by a dev it wouldn't have to be changed. | ||||
Search results interface- Thumbnails | For example, the thumbnails featured on this page | Devs | Must have | Front | S | Once configured by a dev it wouldn't have to be changed. | ||||
Search results interface- results sorting | Comparable to, but not necessarily identical to, DSpace's | Devs | Must have | Front | S | |||||
View and download counts | Analytics integrated into front end | Devs Gabe/Chin | Must have | Front | S | Blacklight DSpace front end custom | Configurable through Mirage2 | - DSPAC-78Getting issue details... STATUS | Documentation: https://wiki.duraspace.org/display/DSDOC6x/DSpace+Google+Analytics+Statistics RAMP: | |
Analytics (back end) | Site admins can retrieve and run reports on analytics | Gabe/Chin | Must have | Back | S | DSpace back end | ||||
Social media/Sharing buttons | Social media sharing buttons | Devs | Should have | Front | S | Blacklight DSpace front end custom | Links/buttons for sharing work via social media (Twitter, Facebook/LinkedIn) | |||
Share via email button or function | Devs | Should have | Front | S | Blacklight DSpace front end custom | |||||
New human-readable URL | Customizable URL | Gabe/Chin | Must have | Back | S | DSpace back end | Yes it's implementable. The Services group must decide on the URL | - DSPAC-81Getting issue details... STATUS | ||
Thumbnails next to recently added | Devs | Could have | Front | S | Blacklight DSpace front end custom DSpace front end standard | Done through DSpace this requires customization of the DSpace theme. It's unclear how thumbnails would be generated in a blacklight skin | ||||
ADA note integrated into interface | Devs | Must have | Front | S | Blacklight DSpace front end custom DSpace front end standard | Text in footer | ||||
ORCID integration- front end | Green ORCID button linking back to author's ORCID profile, as in DukeSpace | Devs | Must have/should have | Front | S | Blacklight DSpace front end custom | DSPAC-65- ORCID strategyIN PROGRESS | Cambridge: https://www.repository.cam.ac.uk/handle/1810/266430 Duke: https://dukespace.lib.duke.edu/dspace/handle/10161/8875 DSpace orcid documentation: https://wiki.duraspace.org/display/DSDOC6x/ORCID+Integration Thread on v6.2 compatibility and 6.3 errors https://groups.google.com/forum/#!topic/dspace-tech/N_azMfWalD8 GG's orcid doc: https://docs.google.com/document/d/1ump6tlTrd62nvDoXo4I9GBsSdLs5SeY7k1flP2InYTs/edit 6.3 errors doc: | ||
Transform language codes (or any metadata value) into full words via display layer | the field contains the value 'en' but the interface displays the word 'English' | Devs | Must have | Front | M | Blacklight DSpace front end custom DSpace front end standard | This is doable through the tweaking of the native theme or another theme like Mirage2. I was unable to find a way to do this other than through the theme Note that this could be done easily by adding another language field specifically for display, however the metadata group would prefer to avoid this | DSPAC-66- Transform language codes for display TO DO | Thread on the topic: | |
Auto-Generate MIME types | Automatically populate a field with MIME type values based on file extension | Devs | Should have | Back | M | DSpace back end | Last option- contact Texas Uni | DSPAC-75- Auto-generate MIME types TO DO | See convo with Andrea SchweerNotes from Services Metadata meeting: This will impact how cumbersome the workflow is for the IR manager. How cumbersome will depend on the volume of submissions, which is currently unknown. | |
SWORD mapping from ProQuest | Automatic ingests of ETDs and associated metadata from ProQuest, plus mapping | Gabe/Chin/Holly Possibly Devs | Should have | Back | M | DSpace back end | Ongoing | DSPAC-60- SWORD Mapping; PQ->DSpaceIN PROGRESS | DSpace METS SIP Profile: https://wiki.duraspace.org/display/DSPACE/DSpaceMETSSIPProfile | |
Extend embargo functionality | Items embargoed through the DSpace administrative layer would be either invisible, or would display metadata-only | Gabe/Chin | Must have | Back | M | DSpace back end | It can easily be enabled in the submission form. To auto-apply embargos via imported ProQuest metadata we need to provide an exact lift date. Two additional back-end fields must be implemented, embargo.field.terms and embargo.field.lift. Note that there may be an exact date in the regular metadata from proquest ETD admin | DSPAC-63- Extending embargo functionality- feasibility IN PROGRESS | Embargo documentation https://wiki.duraspace.org/display/DSDOC6x/DSpace+6.x+Documentation Implement a variation on this for 'six month', '1 year', etc.: http://wiki.lib.sun.ac.za/index.php?title=SUNScholar/Embargo_Systems/1.8.X Embargo setter javascript: https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/embargo/DefaultEmbargoSetter.java | |
CVs- internal list | Gabe/Chin | Must have | Back | M | DSpace back end | DSPAC-80- Controlled VocabsTO DO | https://wiki.duraspace.org/display/DSPACE/Authority+Control+of+Metadata+Values | |||
CVs- external lookup (via something like LCSH) | This would happen exclusively through DSpace, via out-of-the-box functionality | Gabe/Chin | Could have | Back | M | DSpace back end | ||||
CVs- ORCID | Integrate ORCID into back end | Gabe/Chin | Could have | Back | M | DSpace back end | Should be straightforward Note: The Services group's ORCID enhancement depends on this. | https://wiki.duraspace.org/display/DSDOC6x/ORCID+Integration | ||
Mirage2 theme-implement | Customizable display layer, including homepage, subpage, configurable interface, customizable facets, etc. | Gabe/Chin | NA | Front | S | NA | - DSPAC-67Getting issue details... STATUS | Meeting Example: https://atmire.com/preview/browse?type=title See note on this page, specifically 'Enabling and building the DSpace 5 Mirage 2 theme' for troubleshooting ideas Thread on error encountered by Chin, with Fix by Tim Donohue | ||
DOI patch | Fix for 6.x DOI prob | Gabe/Chin Maybe devs | NA | Back | S M | NA | Thread on the issue: https://groups.google.com/forum/#!topic/dspace-tech/EQUlVrif-u8 The old DIM2DataCite.xsl crosswalk: https://github.com/DSpace/DSpace/blob/master/dspace/config/crosswalks/DIM2DataCite.xsl Patched DIM2DataCite.xsl crosswalk: https://github.com/DSpace/DSpace/pull/2321/commits | |||
Upgrade to 6.3 | Gabe/Chin | NA | Back | M S | NA | Make a backup plan and implement first. Use Meld to find versions of our file | DSPAC-72- Upgrade to 6.3IN PROGRESS | Note: DSpace 7.0 will be released mid 2019 https://www.youtube.com/watch?v=JBH0A3QwBUk . (see 18:36 for directories to back up... back up a) sql and solr databases. see 20:30, section on using meld to discover differences. 23:50 for folders to check for changes) | ||
More Issues | See Jira Board |
High level requirements
Other considerations
DOI functionality
Core Functionality | Requirements | Complications and question: | Notes/Decisions | Jira Tickets | Reference Links |
---|---|---|---|---|---|
DOI generation | DOI agency integrated with DSpace | DSpace, when configured so that DOI generation is integrated, automatically generates a DOI for each item added to the repository.
| - DSPAC-3Getting issue details... STATUS | ||
DOI generation | Manual retrieval and entry of DOIs | How would manual generation of DOIs through a new Libraries CrossRef membership work? This would be the simplest solution, however would require more manual intervention per-item.
| |||
Subscribing to a DOI Registration agency | We'll need to join a DOI registration service |
| - DSPAC-37Getting issue details... STATUS - DSPAC-41Getting issue details... STATUS | ||
DOIs for data | Decide if we want DOIs for data |
|
ETD functionality
Core Functionality | Requirements | Complications and question: | Notes/Decisions | Jira Tickets | Reference Links |
---|---|---|---|---|---|
ETD Migration | Migrate ETDs from CONTENTdm to DSpace |
| |||
ETD workflow | Create a ProQuest→DSpace ingest workflow | It's a complicated process! Do we know of any institutions that have successfully completed a ProQuest→DSpace direct deposit workflow using SWORDv2? | Gabe is currently working on this- Determining this workflow's feasibility will take a bit more time |
DSpace structure/configuration
Core Functionality | Requirements | Complications and question: | Notes/Decisions | Jira Tickets | Reference Links |
---|---|---|---|---|---|
DSpace's Community/Collection structure- High Level | Two options:
|
| Discussed at 9/18 project team meeting. This group favored the 'flat' approach. What does the IR Services group think? | ||
DSpace's Community/Collection structure- Granular | Assuming we want to go with a 'flat' structure which communities and collections should be included | One possible structure- one collection each for
| |||
DSpace's Community/Collection structure- Granular | Assuming we want to go with a communities/collections-based structure, which communities and collections should be included? |
| |||
Direct submission form | A form for direct submission of faculty publications will be create | This involves both
| https://wiki.duraspace.org/display/DSDOC6x/Submission+User+Interface See the 'Assigning a custom Submission Process to a Collection' section | ||
DSpace Embargo functionality | DSpace's embargo functionality is enabled Through the ProQuest→DSpace ingest workflow ProQuest's embargo codes can efficiently be translated into DSpace embargoes. | We'll have to decide if we want to implement DSpace's simple embargo settings or advanced embargo settings. The Simple settings can be easily enabled globally. We'll need to determine whether we can use the DSpace's 'Creating Embargoes via Metadata' as a part of our Elements→DSpace or ProQuest→DSpace work Q: Are there any items imported from Elements that will need to be embargoed? | - DSPAC-47Getting issue details... STATUS | https://wiki.duraspace.org/display/DSDOC6x/Embargo |
Policy Decisions
Core Functionality | Requirements | Complications and question: | Notes/Decisions | Jira Tickets | Reference Links |
---|---|---|---|---|---|
Elements Deposit interface- customize statements | Guidance text- we'll need to provide a statement Institutional Advice- we'll need to provide a statement | - DSPAC-32Getting issue details... STATUS | https://docs.google.com/document/d/1p57lEx70eWyYMhd_EIAias7f9-H-U7Ecb8pKpLnsJ-E/edit | ||
DSpace- licenses | Customize license for Elements→DSpace submission workflow | We may not have to use this... the interface a faculty submitter will have to use is the Elements interface | |||
DSpace- licenses | Customize license/advisory text for Direct Submission→DSpace workflow | ||||
ADA policies | Determine what they are and how they affect our configuration | A text readable layer is required on all digital objects. This means that the ETD PDFs will have to be OCRed, as well as PDFs ingested via Elements. |
Workflow considerations
Core Functionality | Requirements | Complications and question: | Notes/Decisions | Jira Tickets | Reference Links |
---|---|---|---|---|---|
Implementation of 'deposit' button in Elements | a deposit embedded in the Elements interface, usable by both library staff and faculty users of our RIMS | It must be enabled universally. Is this a problem? This functionality cannot be limited only to certain classes of user. The crosswalk allows us to move items deposited from Elements→DSpace to specific dspace collections based on their 'publication type' status in elements. This could be one solution. | |||
Library mediated deposits from Elements→DSpace | We've discussed having the library deposit from Elements to DSpace on faculty member's behalf. | One complication is that Elements indexes articles hosted in other systems, but does not ingest copies of articles. What are the workflow and legal implications of downloading these articles directly from the publication. Another complication is that many journals allow the deposit of the preprint or accepted version, but not the publisher's version. How would we obtain one of the permissible versions, which would be unpublished. | |||
Dark archive? | We could set up a DSpace collection shielded from the public that would facilitate the long term preservation of faculty research, while keeping it in accessible due to legal complications | Is this worth it? Is this too far in the wrong direction re: open access? |
Metadata Configuration
Core Functionality | Requirements | Complications and question: | Notes/Decisions | Jira Tickets | Reference Links |
---|---|---|---|---|---|
Elements mapping | Define master Elements→DSpace mapping | Mapping brainstorming doc (Holly/Gabe) | |||
Elements mapping | Define master DSpace→Elements mapping | Holly: These are not necessary, | Mapping brainstorming doc (Holly/Gabe) | ||
Elements mapping | Configure per-publication type mappings | These may not be necessary. | Mapping brainstorming doc (Holly/Gabe) | ||
ETD migration | Decide which metadata to maintain when migrating from CDM Create migration crosswalk | ||||
ETD workflow | Define Proquest→ETD crosswalk | ||||
Direct Submission form | Define which fields will be included Determine how this will fit into workflow | https://wiki.duraspace.org/display/DSDOC6x/Submission+User+Interface See the 'Assigning a custom Submission Process to a Collection' section | |||
Web endpoint for direct submission form | A way for Temple affiliated users to submit items through the submission form, without having to interact with the repository. Registering for an account through DSpace. The endpoint providing this should be linkable from anywhere. | ||||
Embargo | If needed, incorporate 'creating embargoes via metadata' procedures into Elements→DSpace and/or ProQuest→DSpace crosswalks | https://wiki.duraspace.org/display/DSDOC6x/Embargo#Embargo-Creating%20Embargoes%20via%20Metadata | |||
OAI-PMH | OAI-PMH- configure it | Blacklight WorldCat And more! | |||
Controlled Vocab | Implement DSpace controlled vocabs | Decide- do we need them? If so, how should they be implemented | Newer, incomplete: https://wiki.duraspace.org/display/DSPACE/Authority+Control+of+Metadata+Values Older, more complete: https://wiki.duraspace.org/display/DSPACE/Authority+Control+of+Metadata+Values#AuthorityControlofMetadataValues-XMLUI | ||
Standardized rights statements | Account for them in the schema Insert them via the load process | ||||
Functionality: Display underlying metadata as a different text string for display | Use case: Translate language codes to plain text for display | ||||
Autogenerated MIME types | [UTexas generates them automatically] | ||||
CVs- Internal | |||||
CVs- External vocabs | |||||
Citations | Is it possible to include the DOI in the citation? | ||||
Departmental Data | Format: |Temple University|College of Science and Technology|Department of Physics Parse by separator | ||||
Auto Filling a file size field | |||||
DSpace- standardized rights statements | Look into CC and rs.org in DSpace see [link] | Findings: CC is supported but rs.org isn't. |
Back-end configuration- Services group
Core Functionality | Notes | Status | Jira Tickets | ||
---|---|---|---|---|---|
Storage issues | Find out: 1. How much DSpace storage space is currently available? | In progress | - DSPAC-56Getting issue details... STATUS | ||
ADA concerns- System | Scope out and resolve ADA-related systems issues | - DSPAC-57Getting issue details... STATUS | |||
ADA concerns- Materials | Scope out and resolve ADA-related materials issues | - DSPAC-58Getting issue details... STATUS | |||
Storage Budget | Determine what the budget will be for the IR's storage | - DSPAC-59Getting issue details... STATUS | |||
More issues | See Jira Board |