Page History

...

1. (Lieven, Ben, Tim, Fernando, Jose, Mark, Oliver, Paulo) Submission integration (creating Entities & relations using the Item submission process) - Mockups already created by Paulo previously. - In implementation
2. (Lieven, Ben, Tim, Jose, Oliver, Paulo) Which metadata fields should be used for each Entity type. (DS-4223).  - In implementation
3. (Lieven, Ben, Tim, Mark) Additional data for relations (essentially "metadata" or labels on relations) - Related to many other features / use cases.   - In implementation
4. (Oliver, Paulo) Author name variants  - In implementation
5. (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. - In implementation
6. (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. (NEEDS DISCUSSION)
7. (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).  - Discussed Today
   1. Relates to GDPR
8. (Alexander) AIP Backup & Restore (of Entities)*
9. 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. (NEEDS DISCUSSION)
10. SWORD integration (submission of Entities via SWORD) - Uses same format as AIP. Once AIP is implemented, SWORD should be easy.
11. OpenAIRE v4 implementation using Entities* - Brought up in Steering.  Possibly just an OAI-PMH configuration which maps Entity metadata fields to OpenAIRE v4
12. ORCID integration with Entities (for Person Entities). (Related to #15)
13. 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.
14. The ability of pick the proper affiliation of a Person for a specific context. DSpace should address this use case to allow the user to describe something like in this document http://repositorium.sdum.uminho.pt/bitstream/1822/46268/1/1-s2.0-S1877050917302788.pdf regarding the authors and affiliations. You have different persons, each can belong to an institution at the time of that publication. The affiliation shouldn't be changed afterwards. And the user should be able to pick the proper one if an Author has more than one.  (PER discussion on July 16, this is lower priority and may be more likely to be implemented in DSpace 8)

15. (REQUIRED) Deeper dive discussion into how Entities will work with Authority Control, and how ORCID integration will work (as ORCID integrates with Authority Control). Some useful resources:  (NEEDS DISCUSSION - On agenda on Aug 27)

    • Authority Control of Metadata Values
    • ORCID Integration#Importingexistingauthors&keepingtheindexuptodate

Notes

• Discussion of Task #7: 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)
  • Discussion points are available in the documentation : https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.c62y8iqnvlur
  • Some use cases identified
    • Want to delete an Author profile without  removing their name from publications (Implementation would require copying "virtual metadata" from Author  to all the Publications linked to that profile)
    • Want to delete an Author profile AND remove their name from publications (e.g. to align with GDPR or other privacy regulations, or because Author was incorrect).  (Implementation would be simply deleting the Author and the Relationship)
    • Want to simply unlink an Author profile from all Publications (e.g. wrong author was linked)  (Implementation would be simply deleting the Relationship only)
    • Want to delete an entire Journal  (Implementation could use cascading deletions or require multiple steps or a bulk delete option, e.g. find everything related to the journal, bulk select & delete)
  • A few main options exist
    • Do we support cascading deletions? (e.g. delete an entire journal)  - After discussion, we decided NO cascading deletions in DSpace 7.  The primary reason is that this is complex, and it's very difficult to determine when a relationship is hierarchical.  Additionally, you'd need to only cascade in one direction...e.g. a Journal deletion would cascade down the hierarchy, but an article deletion should not cascade up the hierarchy.  Overall, this is a very complex topic which would require complex configuration/code.  We'd recommend not supporting this in DSpace 7....it could always be added in a future release
    • Do we want to always copy "virtual metadata" to other objects during a deletion?
      • No, this needs to be optional for several reasons
        • Some use cases (see above) may not want metadata copied between objects during a deletion.
        • Also, the user deleting the main object may not have permissions to modify ALL of the related objects. This needs to be an "all or nothing" activity
      • This should be an option presented to the user during the deletion process.
      • If this is optional, who can choose to copy "virtual metadata" to the related objects?
        • It'd likely be too complex to figure out dynamically if you have permissions to modify all the related objects.  For example, if you are deleting an Author Profile page, and that Author is the author of 200 articles, you'd need to check permissions on 200 separate items before you can determine if "virtual metadata" can be copied over (as this is an "all or nothing" activity)
        • After discussion, we decided to limit this to Full Administrators only.  Only Full Administrators can choose to delete & copy over virtual metadata.  Other levels of users can be given option to delete without copying over virtual metadata, but will be warned to contact the Administrator if virtual metadata needs to be retained.