Date & Location
at 15:00 UTC (11:00am EST)
Join from PC, Mac, Linux, iOS or Android: https://duraspace.zoom.us/my/dspace (Meeting ID: 502 527 3040)
Actual attendee list will be updated after meeting.
- Tim Donohue - DuraSpace
- Pascal-Nicolas Becker - The Library Code
- Alexander Sulfrian - Freie Universität Berlin
- Lieven Droogmans - Atmire
- Ben Bosman - Atmire
- Paulo Lopes - FCT|FCCN
- Mark H. Wood - IUPUI
- Paulo Graça- FCT|FCCN (sorry I but won't be available)
- Jose Carvalho - University of Minho
- Heather Greer Klein - DuraSpace
- Dimitris Pierrakos - ARC/OpenAIRE
- Oliver Goldschmidt - Hamburg University of Technology (TUHH)
Any additional topics to today's agenda
OpenAIRE v4 Data Model & Submission Forms proposal
NOTE: Please read the OpenAIRE4 DSpace 7 specification documentation: https://docs.google.com/document/d/1mUrtxbVMhCmp18doZ2kavZAAJ2LMemmeiYPPC6O13LU/edit#heading=h.z88cm4fcy2rm
This discussion will concentrate on "R1" and "R2" in the DSpace 7 Requisites section. Please add comments/questions to the Google Doc directly, or bring to this meeting.
|Jose & All|
|3||15mins||Updated "Name Variants" Proposal Discussion|
Initial thoughts on configuration of:
Discussion points added to documentation at: https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.9pbj0sv7dtex
|Atmire & All|
|4||15mins||Discussion of Task #7|
Dig a bit deeper on this task. What is possible for DSpace 7?
|Atmire & All|
|5||5mins||Wrap-up and Assigning tasks||Tim|
Tickets to Resolve
- All JIRA tickets tagged with "Configurable Entities": https://jira.duraspace.org/issues/?jql=project%20%3D%20DS%20AND%20component%20%3D%20%22Configurable%20Entities%22
- Critical Tickets: https://jira.duraspace.org/browse/DS-4244?jql=project%20%3D%20DS%20AND%20priority%20%3D%20Critical%20AND%20component%20%3D%20%22Configurable%20Entities%22
- Major Tickets: https://jira.duraspace.org/browse/DS-4241?jql=project%20%3D%20DS%20AND%20priority%20%3D%20Major%20AND%20component%20%3D%20%22Configurable%20Entities%22
PRs Needing Review
- (Rest Contract) (Entities) Rename properties and support for name variants: https://github.com/DSpace/Rest7Contract/pull/67 ( Tim Donohue, Paulo Graça)
- (NEW) (REST) support for defining relationship lookups in the submission forms https://github.com/DSpace/DSpace/pull/2472 (Tim Donohue - gave feedback, Alexander Sulfrian)
- (Angular) (Entities) Deleting relationships: https://github.com/DSpace/dspace-angular/pull/402 (Paulo Graça - reported issues, Tim Donohue )
- (Angular) (Entities) Grid templates for entity types https://github.com/DSpace/dspace-angular/pull/433 (Paulo Graça, Alexander Sulfrian )
PRs Merged this week!
- (Entities) One-sided relationship filtering and refactoring https://github.com/DSpace/dspace-angular/pull/430
This list was roughly prioritized 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. NOTE: Keep in mind, just because an item is listed here does NOT guarantee it will be completed for DSpace 7. Some of these tasks may need to be delayed for a future release.
- (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.
- 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)
(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:
- OpenAIRE v4 discussion
- Jose led us through R1 and R2 concepts in documentation at https://docs.google.com/document/d/1mUrtxbVMhCmp18doZ2kavZAAJ2LMemmeiYPPC6O13LU/edit#heading=h.z88cm4fcy2rm
- Including the metadata mapping spreadsheet here: https://docs.google.com/spreadsheets/d/1qD7gmeSVtgEhMzOGs-2a0CM4STIri0m_K5MUnZz6aZc/edit#gid=2105340432
- Some feedback added inline in Google doc (first link above)
- Tim's notes
- We should minimize the number of new metadata fields we are adding. As part of this we need to understand which OpenAIRE fields are required or optional
- The metadata spreadsheet is a good start, but would like to better understand the exact proposals for:
- What metadata fields the OpenAIRE team feels should be added to DSpace
- What input form changes are deemed necessary to provide "out of the box" basic support
- "Name Variants" Proposal Discussion
- Lieven's Slides: Entities-meeting-20190730.pdf
- These overview 3 options for handling Name Variants
- Proposal is to go with Option #3 the "Hybrid Approach"
- Tim likes this approach
- it adds the ability for any submitter to create links/relationships to Author Entities and note a new name variant as needed. Also keeps "approved" name variants on the Person Entity itself...provides a possible future where people could manage their own profiles (entities) and decide which name variants to list on their profile versus keep unlisted (e.g. if variant is a misspelling or similar)
- others said they'd like to think a little more on it.
- Discussion of Configuration needs section
- Went through a bit more quickly
- Seems reasonable enough, though Tim wants to review docs in more detail
- ACTION: everyone should review these materials in more detail. Ask questions or make observations on Slack. If necessary can discuss further next week.
- Meeting wrapped up. Next meeting on Aug 6.
Any assigned actions will appear here, along with details of who they are assigned to.