Date & Location
at 15:00 UTC (11:00am EST)
NO MEETING on Tuesday, Sept 24. Please provide updates via Slack on #entities-wg channel.
Join from PC, Mac, Linux, iOS or Android: https://lyrasis.zoom.us/my/dspace (Meeting ID: 502 527 3040)
Actual attendee list will be updated after meeting.
- Tim Donohue - LYRASIS (Out from Sept 23-24 at 2019 DSpace North American User Group Meeting)
- Pascal-Nicolas Becker - The Library Code (unavailable)
- Alexander Sulfrian - Freie Universität Berlin
- Lieven Droogmans - Atmire
- Ben Bosman - Atmire
- Paulo Lopes - FCT|FCCN (unavailable)
- Mark H. Wood - IUPUI (unavailable)
- Paulo Graça- FCT|FCCN
- Jose Carvalho - University of Minho (unavailable)
- Heather Greer Klein - LYRASIS (unavailable)
- Dimitris Pierrakos - ARC/OpenAIRE
- Oliver Goldschmidt - Hamburg University of Technology (TUHH) (unavailable)
Any additional topics to today's agenda?
|2||5min||11. OpenAIRE v4||Update||All|
Discussion about https://github.com/DSpace/Rest7Contract/pull/74:
|4||15mins||DSpace 7 Estimation Process for Entities||Tim|
|4||10mins||Wrap-up and Assigning tasks|
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/issues?jql=project%20%3D%20DS%20AND%20priority%20%3D%20Critical%20AND%20component%20%3D%20%22Configurable%20Entities%22
- Major Tickets: https://jira.duraspace.org/issues?jql=project%20%3D%20DS%20AND%20priority%20%3D%20Major%20AND%20component%20%3D%20%22Configurable%20Entities%22
- (HIGH PRIORITY) Bug with performance of Angular (especially with regards to Entities, e.g. in PR#402): https://github.com/DSpace/dspace-angular/issues/458
PRs Needing Review
- (REST Contract) Entities support for external authority sources https://github.com/DSpace/Rest7Contract/pull/74 UPDATED WITH FEEDBACK (Paulo Graça - feedback provided ,Alexander Sulfrian, Tim Donohue )
- (REST Contract) Configuring whether name variants should be used https://github.com/DSpace/Rest7Contract/pull/77 QUESTIONS EXPLAINED DURING LAST MEETING (Paulo Graça - feedback provided , Alexander Sulfrian, Tim Donohue )
- (REST) Rename properties and support for name variants https://github.com/DSpace/DSpace/pull/2488 UPDATED (Tim Donohue - Needs re-review, Dimitris Pierrakos , Paulo Graça - feedback provided)
- (NEW) (REST) Discovery indexing: Ensuring discovery configuration is used during indexing https://github.com/DSpace/DSpace/pull/2527 (Tim Donohue- asked questions, Paulo Graça)
- (Angular) Rename relationship type properties https://github.com/DSpace/dspace-angular/pull/461 ( Tim Donohue, Paulo Graça) (WAIT TO MERGE UNTIL REST IMPLEMENTATION IS MERGED)
- related to https://github.com/DSpace/DSpace/pull/2488
- (NEW) (Angular) Item page entities changes/refactoring https://github.com/DSpace/dspace-angular/pull/475 (Paulo Graça, Tim Donohue)
PRs Merged this week!
- (REST Contract) Delete item with relationships https://github.com/DSpace/Rest7Contract/pull/78
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. - In implementation
- (Lieven, Ben, Tim, Jose, Oliver, Paulo) Which metadata fields should be used for each Entity type. (DS-4223). - In implementation
- (Lieven, Ben, Tim, Mark) Additional data for relations (essentially "metadata" or labels on relations) - Related to many other features / use cases. - In implementation
- (Oliver, Paulo) Author name variants - In implementation
- (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
- (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)
- (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 on Aug 6
- 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. (NEEDS DISCUSSION)
- 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). (Related to #15)
- 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: Discussed in meetings on Aug 27 and Sept 17 - In implementation
- OpenAIRE v4 updates
- Some PRs coming soon regarding metadata fields and forms that need to be required as part of OpenAIRE v4 compliance
- Discussion about https://github.com/DSpace/Rest7Contract/pull/74
- Paulo and Tim have questions/concerns about current `/externalsources` endpoint. It seems nearly identical to existing `/authorities` endpoint (main difference is sources are external instead of internal).
- Tim doesn't like the POSTs on that endpoint. They seem misplaced as Paulo noted in these two comments:
- Ben notes another difference is that `/authorities` endpoint requires a `metadata` parameter for filtering (whereas that doesn't make sense for most external sources). See contract at https://github.com/DSpace/Rest7Contract/blob/cb86c89bb6918128f4ab3a6d2c5e2ccb835776be/authorities.md#authority-entries
- Tim notes he's having difficulty following all the reasons why this still needs to be a separate endpoint. Ben asks Tim to provide an alternative idea & Tim agrees
- Next Steps: Ben & Tim will work offline on a possible solution to move this forward. Will bring the proposal back to this team for final approval next week.
- Overview of the DSpace 7 Estimation Process (for those who haven't heard about this yet)
- Need more volunteers to help with estimations beyond the Atmire team. Ideally want two developers per task, as it provides balance to the discussion. All, think about volunteering to help with this process...let Tim know.
- Next steps: Our Working Group needs to revisit our "Task List" in our weekly agenda to (1) narrow down which tasks to estimate for 7.0 (vs any to consider out of scope for now), (2) better define/clarify/scope each individual task (and perhaps create subtasks as needed) so that they can be estimated by a developer. We'll start this process next week.