| Create from Template | ||||||||
|---|---|---|---|---|---|---|---|---|
|
...
Product Requirements Matrix
...
Priority level: Must have/Should have/Could have/Won't have
...
Standard repository features- front end
| 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 |
| 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 |
| 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. |
| 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 |
| 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' |
| https://wiki.duraspace.org/display/DSDOC6x/Authentication+Plugins | Homepage- customizable by devs | Customizable display layer, including homepage, subpage, configurable interface, customizable facets, etc. 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 |
| '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 | 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 |
| |||||||||
| Customize item display page- structural | Ability to customize the features of each page. For example, adjusting thumbnail size. | 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 |
| Thread: https://groups.google.com/forum/#!searchin/dspace-tech/orcid|sort:date/dspace-tech/f_BZETZYXiM/mavRYst_AwAJ | ||||||||||||||
| Item display page- embedded image viewer | When appropriate, items would display at full size in an image viewer. | Devs | NA | Front | S | This would exceed DSpace's current capabilities | Item display page- Thumbnails + View/download option. | 'View'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 |
| |||||||||||||||
| 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 . 'download' would initiate a download. | Devs | NA | Front | S | This would equal DSpace's current capabilities --Facets |
| 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 |
| 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 |
| |||||||||||||||
| 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 | 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 | 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 | 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 | 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 | 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 | 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 |
| 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 | 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 |
...
| 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.
|
| ||||||||||||||||||
| 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 |
|
| ||||||||||||||||||
| DOIs for data | Decide if we want DOIs for data |
|
...
| 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 |
| 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? |
...