Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

This page is a "work in progress" output from both the Technology Planning Group and Strategy Planning Group.  Other DSpace-CRIS or DSpace community members are also welcome to contribute or suggest enhancements.

This page documents the known differences between DSpace-CRIS and DSpace as of April 2025 (DSpace 8.x and DSpace-CRIS 2024.02.00).  It is not meant as formal documentation, but rather just a brief description of where differences exist between these two platforms.

Architectural Differences

The architecture of DSpace and DSpace-CRIS is very similar overall.  All code within DSpace also exists within DSpace-CRIS.  However, areas of DSpace architecture or default configurations have been modified in DSpace-CRIS to support some of the DSpace-CRIS specific features listed below.

Known architectural differences include:  (NOTE: This list may not yet be complete)

  1. Entities are enabled by default: DSpace-CRIS uses the same Entities system as DSpace (except where described below). However, in DSpace-CRIS, Configurable Entities are enabled by default.
  2. Additional, out-of-the-box Entities exist. DSpace-CRIS includes some additional entities:  Funding, Product, Patent, Event, Equipment (see https://github.com/4Science/DSpace/blob/main-cris/dspace/config/modules/cris.cfg#L7) .  These are in addition to the default, optional Entities that are included with DSpace out-of-the-box: Person, Publication, Project, OrgUnit, Journal, Journal Volume, Journal Issue.
  3. Relationships (between Entities) are changed: While DSpace-CRIS uses the same Entities concept as DSpace, it changes the “Relationships” between these Entities.
    1. DSpace uses a database table (relations) to define all Relationships strictly.
    2. DSpace-CRIS instead uses the (existing) DSpace Authority Framework to define relationships between Entities, therefore storing relationships in metadata fields. (This is not the same as the Solr "authority" core) - see page 81-96 of the technical documentation pdf
  4. Virtual Metadata (sharing metadata between Entities) is changed: DSpace-CRIS stores “virtual metadata” (metadata displayed via related entities) in the database alongside regular metadata. So virtual metadata is not dynamic, but it is auto-updated anytime an Entity is edited. As in standard DSpace it allows to go deeper in the graph following relations on related items (and so on).  In DSpace, virtual metadata is dynamically obtained via the relationship.

Feature Differences

While the overall feature-set is similar, DSpace-CRIS has some additional features which are not included in DSpace by default.  There also are a few features which are slightly different.

DSpace-CRIS technical documentation: https://github.com/4Science/dspace-angular/releases/download/dspace-cris-2024.02.01/dspace-cris-2024.02.01.pdf

Known feature differences include: (NOTE: This list may not yet be complete)

  1. Nested / Basic Hierarchical Metadata: DSpace-CRIS can manage basic (2-level deep) hierarchical metadata on its relationships.  The approach relies on how DSpace-CRIS manages relationships.  This is based on the ordering of metadata fields (place column).  Angular currently enforces the ordering (to avoid user mistakes).  4Science notes this is an area they would like to see improvements.
    1. Example use case is storing date ranges on an affiliation for a Person entity.
    2. Store affiliation for contributor in a publication / patent / product entity
    3. Store funder, received amount in funding
    4. Dependent on Authorities & DSpace-CRIS Relationships
  2. Customize Entity/Item display pages via an Excel Spreadsheet (CRIS Layout) uploaded in Admin UI: (Documented in the pdf pages 102-116,  200-204, see also pages 81-96) DSpace-CRIS allows Admins to change the metadata displayed for each Entity type (e.g. Person, Publication) from the Admin UI. 
    1. This is achieved via a structured Excel file which can be exported, edited, then reimported (similar to Batch Metadata Editing). Once imported & validated, the display (splash page) of those Entities is changed without needing to modify Angular code.
    2. Page is laid out using Bootstrap grid system.  Tabs can be created (horizontally or vertically). Tabs can contain any number of "boxes" arranged via Bootstrap grid system.  Boxes then contain metadata, bitstreams, metrics or relationships.  Can also manage Bootstrap CSS (optional).
    3. Can be used to add additional metadata fields to an Item/Entity page.
    4. If you don't load a configuration layout, then the default behavior is the current DSpace Angular component.  But, you also could disable this by using the default DSpace "theme" vs a default DSpace-CRIS "theme".
    5. Dependent on Entities existing.  Might be possible to use without DSpace-CRIS Relationships.
  3. Granular Edit/Security Privileges: (documentation 114, 207 - 211 of the pdf) DSpace-CRIS allows sites to configure more granular edit privileges or security on a metadata field by metadata field basis. Each entity type can have a custom “edit configuration” (defining who can edit individual fields, including non-admins).  Individual metadata field values may also be marked “restricted” (which hides those values from public view) in an additional metadata table column.
    1. These tools also allow Researchers more control over their Researcher Profile (e.g. what fields are displayed publicly vs private, etc)
    2. Managed via a Spring configuration file.
    3. Depends on Custom Entity/Item display pages. Dependent on Entities existing.  Might be possible to use without DSpace-CRIS Relationships.
  4. Control when linked Items/Entities are created: (Documentation in the pdf 96-102, 116-117) DSpace-CRIS lets you decide whether to import linked items, or keep them as a string/identifier.
    1. For instance, when referencing a person via ORCID, you can decide whether to import that Person Entity from ORCID or just keep the ORCID string for future disambiguation
    2. There is a general configuration, but you can override it for specific metadata (ORCID, ROR, OpenAire, etc)
    3. Uses two DSpace Authority placeholders ("Will be generated" or "Will be referenced") to store the string ID representation initially.  With the "Will be referenced" placeholder, if you create an object at a later time which matches that ID, then it will be automatically linked up.
      1. E.g. Suppose you create a Publication and reference an Author via an ORCID string. If you later create a Person Entity with that same ORCID, then that Person Entity will be automatically linked to any Publications with the "Will be referenced" placeholder for that ORCID.  If the Person Entity is later deleted, then the ORCID string will be restored to all linked Publications.
      2. There is a CRISConsumer which handles the processing of these placeholders.
    4. Dependent on Authorities & DSpace-CRIS Relationships
  5. Enhanced Statistics (and exporting statistical reports): (documentation 292 of the pdf) DSpace-CRIS provides more ways to view and export statistics.  See DSpace-CRIS demo site for some examples:
    1. Homepage (shows summary stats, most viewed and counts of views/downloads per object)
    2. Site-wide statistics (includes date-based reporting & export)
    3. Search results have visualization tools based on results. (These are not really statistical tools, but “reporting” style tools.) These are visible only on search results via a “Show/Hide charts” button.
    4. Item-based statistics: Each Item page has statistical details at the bottom along with a “Statistics” button which lets you view the item’s statistics in greater detail.
    5. “Login statistics” give administrators the ability to see basic statistics of how many times users have logged into the system
    6. “Workflow statistics” give administrators the ability to see the number of workflow steps performed, current workflows, etc.
    7. These statistics use the same DSpace "statistics" Solr core.  Also use aggregation using Solr feature called Solr JOIN.
    8. Can also subscribe for statistics updates. Uses the DSpace subscription feature, but offers an additional subscribe type ("statistics") which will send you emails with an excel export of those statistics.
    9. Should be mostly independent of other features
  6. Multilingual support for content:  Display translated titles in search results & Item pages if you switch to a different language display in the User Interface.  For example, if you switch to French display, then Items that have a French version of the title will display that version instead of English.
    1. Uses the existing DSpace "lang" field on a metadata value.  The change is on the backend. The backend will use the locale to filter on the proper metadata.
    2. Also extension of the search system. Can configure a facet to be multi-lingual, so that you can build facets based on a specific language.  So, the facet values would appear in your selected language.
    3. Should be mostly independent of other features
  7. [Researcher Profile] Create a sorted list of "Selected Publications" (or other related content) for display on a user's Researcher Profile (Person Entity).  This can be done for other Entities as well.
    1. Has a user interface to allow you to change the order of your related content presented on your Researcher Profile
    2.  Dependent on Authorities & DSpace-CRIS Relationships & Entities.
  8. [Researcher Profile] Create a custom URL for your Researcher Profile (or other entities):  This URL can include your name or similar, and any UUID URLs will redirect to the custom URL. This can be done for other Entities as well.
    1. Keeps track of the history of your custom URL.  If you change your custom URL, then the system will remember your old URLs.  All old URLs will redirect to the current custom URL (with proper HTTP status code).
    2. Achieved via a custom Submission Step.
    3. Depends on Entities being enabled.
  9. [Item page] "Edit Item" page provides a submission-like display for easier editing: (documented at pages 31-135 of the pdf) When editing an Item, you see the same forms used in the Submission process.  This allows for better validation of fields, etc.  You still have the option to "Administer" which brings you to the DSpace "Edit Item" display.
    1. Can configure additional edit modes / options, which link to different submission form configurations.  You can then define who has permissions to each edit mode, to give different users the ability to edit different parts of the Item/Entity
    2. Depends on Granular Security Privileges feature?
  10. [Item page] “Export” Item pages to Citation format (Chicago style, APA) or bibliographic format (BibTeX, Endnote): An “Export” button lets you export the current item to a format of your choice.
    1. Should be mostly independent of other features
  11. [Item page] Popup details about related entities.  If you hover over a related entity, you get a more detailed popup summary of that entity.
    1. Should be mostly independent of other features
  12. [Item page] “Download” button instead of file link. (see page 126 of the pdf technical documentation).  This is just an alternative option available. Can choose whether to show file links (like DSpace) or a download button.
    1. Should be mostly independent of other features
  13. Authors can download restricted bitstreams: Regardless of permissions set on Bitstream, the author can always download it.
    1. If your Researcher Page is linked as a "dc.contributor.author" on the publication, then you can download any restricted files.  This is a similar concept to the ORCID feature already in DSpace.  
    2. This is a general DSpace-CRIS feature that allows you to define permissions based on a "business rule".  These "business rules" are based on the metadata on the object.  This allows you to say, if you are an author on this object, you have extra permissions on that object.  These business rules are configurable, and this "Author can download restricted bitstreams" rule is a default configuration provided in DSpace-CRIS
    3. Depends on Entities being enabled. Other dependencies need to be determined.
  14. [Submission] Shared workspaces:  Can be enabled at the Collection level.  It allows you to share a WorkspaceItem with all other Collection Submitters to work on it collaboratively.  Or you can define a custom rule to share the WorkspaceItem just with other authors of the publication.
    1. Based on the same functionality as Supervisor Orders in DSpace, but it's not the same as the Supervisor Order.  WorkspaceItem is shared between all the users (via Resource Policies), but is also indexed into Solr.
    2. Does not manage concurrent editing of an Item.  But, this problem also exists in DSpace with Supervisor Orders, etc.
    3. Should be mostly independent of other features
  15. [Submission] Advanced Duplicate Detection:  DSpace has basic duplicate detection available as of version 8.  DSpace-CRIS has a more advanced duplicate detection feature.
    1. In DSpace-CRIS you can compare identifiers (DOI, etc) and additional fields.  By default, DSpace just checks the "dc.title", but can support additional fields.  DSpace does fuzzy matching, while DSpace-CRIS does a string comparison (of item signatures, see below).
    2. In DSpace-CRIS there's an additional Solr core where all the details about duplicate detection is stored.  This include details about the duplicate, and decisions about what to do with the duplicate.
    3. In DSpace-CRIS, each item has several "item signatures" which is a normalization of the Item's metadata.  Two items are potential duplicates if they have one signature that matches (e.g. DOI, title, etc). This is based on a deduplication feature in Solr. See https://sujitpal.blogspot.com/2014/11/near-duplicate-detection-using.html
    4. The DSpace and DSpace-CRIS REST APIs are different for this feature.  The DSpace user interface implementation is more simplistic and is presented to them in the submission & workflow.
    5. This feature is enabled in the DSpace-CRIS demo server.  Submit two items that are very similar or have the same DOI or title and you should see it.
    6. Should be mostly independent of other features
  16. [Submission] Metadata extraction from PDF files using GROBID
    1. Standalone feature, based on DSpace feature to enrich metadata when you add a DOI or identifier.
    2. When you upload a new PDF file to a submission, it can be sent to GROBID.  GROBID will return an XML of the extracted metadata from this PDF.  DSpace-CRIS can then parse that XML and map it to DSpace metadata fields in order to prepopulate metadata on the Submission form.
    3. Use Case: If you drag & drop a PDF, then the submission form will start with prepopulated metadata extracted by GROBID.
    4. Discussed during DSpace 7 development in the context of the move from BTE to the Live Import Framework.  But, this was not completed at the time as Grobid was based heavily on the older BTE framework.
    5. Should be mostly independent of other features
  17. Correction Requests: Users can request a correction to an existing Item, to be reviewed/approved by an administrator. (May need refactoring / reconsideration after the merger to address overlap with DSpace Quality Assurance Framework and/or Item Versioning, etc.)
    1. This is an older feature of DSpace-CRIS which pre-dates the "Quality Assurance" Notification framework that exists now in DSpace 8+.  This was also created before the advanced edit item functionality in DSpace-CRIS. This is still used in DSpace-CRIS, but is less relevant than it initially was. Some users just use the enhanced Edit Item functionality in DSpace-CRIS instead of this. But, others still use this feature for specific use cases.
    2. This feature is only enabled if a Collection has an enabled Workflow.  When a workflow is enabled, authorized users (based on business rules - default is just the author or original submitter) can start a new submission related to an existing published Item.  They can then change the metadata to suggest changes.  When this new submission goes into Workflow, it's flagged as a "correction request", which is displayed differently to reviewers.  Reviewers can see the differences between the items.  If the reviewer accepts the item, then those changes will overwrite the existing Item.
    3. This process creates a separate WorkspaceItem which is discarded when the metadata is copied to the existing Item.  The flow is similar to Versioning, but you modify the original Item instead of a new version. 
      1. Versioning itself is not necessarily a suitable replacement for Correction Requests because you don't want to force a new version to be created for correcting typos or obviously incorrect metadata mistakes.
    4. Depends on Entities being enabled.
  18. Edit Homepage News, Header and Footer (“Edit CMS Metadata”): From the admin sidebar menu, administrators can choose to edit the Homepage header, footer or news section, and translate it into other major languages.
    1. Stores metadata on the "Site" object in DSpace.  This metadata is used to store the Header, Footer, and Homepage News (and the User Agreement below).  Multilingual support in the metadata allows you to save the News in different languages.
      1. Content can include fragments of HTML or Markdown or similar.  Not every HTML tag is accepted – HTML is sanitized.
    2. Discussed during DSpace 7 development, this topic came up as this feature used to exist in the DSpace 6 JSPUI.  But, at that time, there was disagreement around where to store this CMS-like data.  The DSpace-CRIS approach is to store it as metadata on the Site object.  During DSpace 7 early development, an alternative approach was suggested to store it in one or more Bitstreams (see https://github.com/DSpace/RestContract/pull/45).  Agreement was never reached, and the feature fell off the priority list.
    3. This concept continues to be of interest to DSpace users, see https://github.com/DSpace/dspace-angular/issues/3200
      1. Several related Pull Requests also use a similar idea of storing layout / CMS-like content in metadata fields, e.g. https://github.com/DSpace/dspace-angular/pull/3250, https://github.com/DSpace/dspace-angular/pull/3256
    4. Should be mostly independent of other features
  19. Edit User Agreement: From the admin sidebar menu, administrators can edit the “User Agreement” text (using Markdown), and translate it into other major languages. 
    1. This uses the same infrastructure as the prior feature (Edit Homepage News, Header and Footer). It's managed by using metadata on the Site object.
    2. If user agreement is modified after agreed on, is there are record which agreement was signed or agreed to? Similar to regular DSpace, with difference to be able to edit agreement from UI; this refers to the first login agreement, not the deposit license
      1. This behavior is enforced at API level
    3. Should be mostly independent of other features
  20. “My Processes” menu for Users: After login, users have a “My Processes” menu under their account which allows them to see their processes (and the processes of others if they are an Admin)
    1. Intended to allow more users to access the process; anonymous users can trigger specific processes; automatization mechanism which controls which users can make modifications
      1. For anonymous users, the result of the process is public/anonymous. Can define processes to create an output that is public/anonymous (e.g. a public export).
      2. The script configuration is the same as in DSpace but has been extended to allow configuration for anonymous user.  The new export script can be configured to be open to everyone (anonymous), specific group or admin.  Can also configure a limit (maximum export size) based on different type of users (anonymous, group, admin).
      3. Concerns mentioned about a bot triggering anonymous exports.  But, 4Science has not encountered that problem as a crawler cannot navigate to this page (would need to use the REST API directly to trigger).  They had discussed using Captcha but has not been needed yet. Concerns this could be an area that an attacker could send many requests.
    2. Example: A user (non admin) can export data – want to make sure that the user that has triggered the process can look into that
    3. User Interface is a bit different. Instead of redirecting to the Processes page, there's a notification dialog/popup which gives the status/progress of the process.
    4. For the future, it might be good to use a token similar to the Request a Copy in 9.0 (this doesn't exist yet in DSpace-CRIS though)
    5. Should be mostly independent of other features
  21. Metric Framework & Integration with external metrics tools: Where applicable, links to PlumX and Dimensions metrics can be found in the “Most Viewed Items” (on homepage) and on individual item pages at the bottom of the Item page.
    1. Most Viewed Items on Homepage:  On the homepage, you can see a list of “Most Viewed” items/entities, with snapshots of their views and downloads.
      1. Based on DSpace CRIS Metrics.  This is stored in an additional database table (cris_metrics), managed by a script (which queries the Solr core on a regular basis).
    2. Two types of Metrics:  Stored metrics (in cris_metrics database table) and Dynamic metrics
    3. Metrics tracked: Views & downloads for specific object over a specific time period. 
    4. Stored Metrics
      1. For Publication, can import number of citations from Scopus & Web of Science using DOI/IDs.  For Person, can import H-Index, total citations/papers from Scopus & Web of Science.  This is all stored in "cris_metrics" table.  Can define a query which defines the timeperiod which needs to be retained (defaults to 40 days of data is retained). Can configure which metrics you want to collect (and turn off/on Scopus or WoS).
      2. Information in cris_metrics is copied to Solr via automic update. The indexed Solr data is what is used by the user interface.  The Most Viewed Item report is a Solr query sorted by most viewed.
    5. Dynamic metrics are not  stored in the database. Examples of this are PlumX, Dimensions, Altmetrics badge which are embedded as Javascript in the user interface.  Can configure which Entity Types have this data embedded.
      1. All the embedded Javascript is also integrated with the Cookie Consent popup.  It is opt-out by default (to comply with GDPR).  They need to opt-in in order to use it.
    6. Configured via the CRIS Layout. Can decide where these badges are shown, and who can see the badges.  Stored metrics and Dynamic metrics can both be displayed in badges.
    7. Depends on Entities being enabled. Other dependencies need to be determined.
  22. Audit Framework: Can track changes to a DSpace object in an additional Solr core.  You can then view this history of all events at the Item/Entity level.
    1. Receives Events for auditing purposes
    2. Additional "audit" Solr core.  There's a consumer which logs a DSpace event to that Solr core. Any update/change that triggers an event can be stored in Solr.  These event details can be accessed by any Administrator of the object.
      1. This can track which metadata fields where changed, but does not know what the previous value was.
      2. This data is only stored in Solr, which means you'd want to backup your Solr core in order to backup this audit trail.
      3. Can track timestamp, object, and some details about the change (the same details that the current DSpace event system tracks).  This includes the user who made the change and when.
      4. You can only see this data at the object level (for any DSpaceObject).  It's not possible to see the entire audit log or search it at this time, you must view object by object.
    3. New Audit Trail extension is in the work for DSpace being built by 4Science (See https://github.com/DSpace/DSpace/issues/8824).  Can be disabled completely if you don't want this.
      1. This will allow for tracking of previous value and new value of events.
    4. Should be mostly independent of other features
  23. Share links via social networks/email (Facebook, X, LinkedIn, email, etc): A social networking menu hovers over the bottom of each page. Clicking on it lets you share the link to the current page in your network/email of choice.
    1. This is an Open Source library on the Angular side which is GDPR compliant.  Can configure which providers you want included.  Can be turned on in the YML configuration of Angular (it is disabled by default).
    2. Depends on Entities being enabled.
  24. Subscriptions to items: These subscriptions allow you to get a notification, when a new item is set as related to a subscribed item. For example you can get a notification, when a new publication has been approved for a specific author.
    1. Same subscription feature as in DSpace. 
    2. A new type of subscription exists for statistics.  You can be notified about the statistics of a specific Item based on the frequency of the subscription.  Includes total view/download and growth over the period you subscribed.
      1. This button to subscribe appears on the Item page. But there are more options in the subscription popup 
    3. If you subscribe to a Person object, then you will be notified about new publications linked to that Person.  Can be used on all Entities.  Can subscribe to Organization Unit for relationship updates, etc.
    4. This feature relies heavily on the way relationships are managed in DSpace-CRIS.
    5. Depends on the DSpace-CRIS relationship model
  25. Bulk import from Excel File: In the administrative processes section you can upload a particularly structured Excel file to create new items or modify/update existing ones.
    1. Very similar to Bulk Edit via CSV, but using an Excel file.
    2. Excel file has multiple sheets. One is for collection metadata (like in DSpace's bulk edit).  One is for hierarchical metadata (e.g. authors and affiliation).  One is for the files - includes details about the bitstreams, and adding/removing/modifying bitstreams.  Bitstreams are added via a remote URL (HTTP, FTP, SFTP) or a path on the server (starting from a configured folder - for security reasons).
      1. If the bitstream download fails, then it's logged in the output of the process.
    3. Structure of Excel file is checked against the submission forms. If metadata is mandatory, that is enforced on the excel file.  If metadata is repeatable, it can also be repeatable in excel.
    4. Can cross reference records in the excel file.  Can relate to records using the row id in Excel (like in DSpace CSV), or by using a business identifier (e.g. using ORCID, ROR, etc).  This can be configured.
    5. Excel is used here because it allows for multiple sheets.  But, you can use LibrOffice or other tools to edit the Excel
    6. Can be used by submitters, but the import occurs in a specific collection
    7. Should be mostly independent of other features
  26. Configuration options for Homepage: 
    1. Explore sections: Define special navbar to provide special Explore pages without having to modify Angular Code
      1. Explore pages are at the top menu of the demo site of DSpace-CRIS.  This has various components which can be laid out on the explore page on various rows.  These components/widgets can be configured using a discovery configuration and sort/number displayed settings.
      2. The homepage has widgets which can be configured, including HTML fragments (on the homepage announce section)
      3. These "Explore" sections are used to create sub-homepages for a section of the repository.  It's a place to highlight content.
      4. These Explore pages are managed via Spring Configuration XML files.  But, the HTML fragment can pull in metadata values from the Site object (or other objects) in order to change the content of the fragment. The HTML text or Markdown can be edited manually and is checked for security.
      5. Changes to the Spring Configuration XML require a Tomcat reboot.
      6. The Spring XML configuration also does have Bootstrap classes listed in order to define the layout.  This is similar to the approach in the submission form for DSpace where Bootstrap classes can be used.
      7. Can this be disabled?  Not exactly, as there's a default configuration which overrides the DSpace default homepage Angular component. But, you can use the DSpace-CRIS default configuration to create a homepage that looks very similar to the DSpace home page.
        1. You are not forced to use this mechanism, but you'd have to override it.  We might be able to add an Angular configuration to allow you to switch between these options.  Or this could be achieved via using different themes for "DSpace" or "DSpace-CRIS".
      8. This does not use the same configuration as "Customize Entity/Item display pages via an Excel Spreadsheet" (#2 above) because they've found these configurations are changed less frequently.
      9. Should be mostly independent of other features
    2. Configure boxes and elements on the start page: Configuration options to show specific boxes and elements on the home page without having to modify Angular Code
      1. These are the widgets that are used in the Explore sections described above.
      2. Should be mostly independent of other features
    3. Show navbar option for communities and collections by configuration: Configuration option to show the navbar option to get a hierarchical list of communities and collections without having to modify Angular Code
      1. Can hide the "Communities & Collections" link in the header if you don't want it to display.
      2. Should be mostly independent of other features
  27. eMails to fixed recipients: DSpace-CRIS allows you to set an option in dspace.cfg/local.cfg to send any email not to the original recipient, but rather to a fixed recipient. This is useful for test systems, if you are using a database with real email addresses, but do not want to send emails to these addresses (but still want to see, which emails DSpace would be sending).
    1. Small change in configuration. Can configure a list of email addresses to send all emails to that fixed list.  That way during testing you can get all notifications to a single email.
    2. Should be mostly independent of other features
  28. Set relations reciprocally: DSpace-CRIS allows you to set relations reciprocally, i.e. you can define metadata fields, which will set the counterrelation to the referenced item. This will certainly only work for local references. It can be configured in authority.cfg/local.cfg in the configuration setting ItemAuthority.reciprocalMetadata.ENTITYTYPE.METADATAFIELD = METADATAFIELD. This feature is undocumented. Example: ItemAuthority.reciprocalMetadata.Publication.dc.relation.product = dc.relation.publication. This will set the field dc.relation.publication in the item, which is referenced, whenever dc.relation.product is set for a product entity.
    1. In DSpace-CRIS you manage relationships via metadata. You can add opposite direction links to point back to related items.  You can use this mechanism to add a link between two Entities on one side  and the opposite link is added automatically.  If you remove one link, then they both are removed.
    2. The use case for this is to display the links on both Entity pages, because the link is stored on both sides as metadata.
    3. These bi-directional links are kept in sync via a Consumer to watch for changes to one Entity and updates the other Entity.
    4. This is not used widely by DSpace-CRIS users, and is not used by default.  Most standard use case is to link Publication to DataSet. 4Science doesn't see much usage, and this could possibly even be dropped if it's controversial in any way.
    5. Depends on DSpace-CRIS relationships.
  29. submission forms and workflow linked to collection via UI: DSpace-CRIS has additional fields in the edit-collection screen that allow to select which submission-form and workflow apply to the collection overriding what is defined in the corresponding xml files


  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.