Based on the work done for Mockups for the Submission process with support for the Author (Person Entity) first version: https://drive.google.com/open?id=1wRIsDJr3A7AHrrLqNHlSGGBphPryhd-l we propose to visually enhance the process to allow the user to pick the author name from the name variants.
RCAAP and All
4
5mins
Support for defining relationship lookups in the submission forms
Based on the feedback on https://github.com/DSpace/Rest7Contract/pull/64, it should be determined whether any of the suggestions should be changed, and how all the details can be included in that case
All
5
10mins
Metadata fields for each Entity type
The discussion started at "DS-4223 Metadata Schemas for configurable entities" - https://github.com/DSpace/DSpace/pull/2443, regarding the missing Orcid ID. We need to decide what which strategy to follow, not only for Orcid IDs, but also to other Entity IDs fields, like Organization ISNI or Ringgold which none of them is supported by Schema.org or Dublin Core. The proposed strategies are:
Rely on the DC specification for identifiers - dc.identifier, the values will be stored in the type of a URI - dc.identifier.uri = http://orcid.org/0000-0001-2492-3701
It will be created a set of non standard dc.identifier qualifiers (we already have some), like dc.identifier.orcid, dc.identifier.isni, ... and each installer will decide the best way to manage their qualifiers
Rely on the Schema.org to add new specific fields, for example it supports the DUNS number in the Organization schema
This list was voted on in the meeting on May 23, 2019 (just before OR2019). The prioritization below may change, but it gives a high level overview of what still needs to be done.
(Lieven, Ben, Tim, Fernando, Jose, Mark, Oliver, Paulo) Submission integration (creating Entities & relations using the Item submission process) - Mockups already created by Paulo previously.
(Lieven, Ben, Tim, Jose, Oliver, Paulo) Which metadata fields should be used for each Entity type. (DS-4223).
(Lieven, Ben, Tim, Mark) Additional data for relations (essentially "metadata" or labels on relations) - Related to many other features / use cases.
(Oliver, Paulo) Author name variants - Not currently implemented
(Jose) Configuration of batch import (via CSV) for Entities - Already a CSV import available, but can only link entities in CSV to existing entities (in the system). Need to decide how to represent relations in CSV.
(Mark) Permissions on Relations (who has permissions to add/modify/delete relations) - Currently, if you have Edit permissions on the Entity, then you can edit/delete any relationships to/from that Entity.
(Fernando) Deleting objects with Relations (How or should deletion propagate between closely related objects, e.g. delete entire Journal) - Currently, deleting a relation just decouples the two Entities. E.g. If you delete a Person entity, that Person may no longer be listed on any Publications it is linked to (may want to copy info over after deletion).
Relates to GDPR
(Alexander) AIP Backup & Restore (of Entities)*
Dynamic display of Relations - determine automatically how a list of entities displayed on an Item page (list vs search). Currently hardcoded based on entity type (in item page template). Want to make it configurable/dynamic.
SWORD integration (submission of Entities via SWORD) - Uses same format as AIP. Once AIP is implemented, SWORD should be easy.
OpenAIRE v4 implementation using Entities* - Brought up in Steering. Possibly just an OAI-PMH configuration which maps Entity metadata fields to OpenAIRE v4
ORCID integration with Entities (for Person Entities).
Best Practices around Entities in Collections. We've suggested in the Preview Release to structure Collections based on Entity Type (Person Collection, Projects Collection, etc). We should better document and formalize these best practices. Can we hide these Collections which only serve to store Entity Type.
Notes
Action Items
Any assigned actions will appear here, along with details of who they are assigned to.