Page History

...

1. Submission integration (creating Entities & relations using the Item submission process) - Mockups already created by Paulo previously. - In implementation
   1. Not started yet: Adding name variants, importing from external sources
2. Which metadata fields should be used for each Entity type. (DS-4223).  - In implementation
   1. Not done yet: A field to store the entity type. This is currently set to relationship.type
3. Additional data for relations (essentially "metadata" or labels on relations) - Related to many other features / use cases.   - In implementation
   1. Not fully complete.
4. Author name variants  - In implementation
   1. Not fully complete. Can estimate.
5. 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
   1. Needs analysis of what is outstanding.
6. 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. 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
   1. Relates to GDPR
8. 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)
    1. Importing from external sources (can estimate)
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:  Discussed in meetings on Aug 27 and Sept 17 - In implementation

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

Notes

• Any open feedback on  Entities support for external authority sources https://github.com/DSpace/Rest7Contract/pull/74?
  • Tim notes this PR should not be changing the "/authorities" endpoint.  It's an Entities-specific PR, so it should just update "/externalsources" endpoint for Entities.
  • That said, if there are necessary refactoring/changes to "/authorities" endpoint those can be in a separate Contract PR, submitted to the DSpace 7 WG
  • Ben notes that makes sense to him too
  • Tim had questions in the PR on whether the "metadata" section coming back from each External Source would display DSpace schemas?  That seems to imply we'd be "pre-mapping" the response of the external source to DSpace metadata?
  • Ben answers Yes, we would need to do this pre-mapping to support the Angular UI anyways.  We don't want the Angular UI to have to "understanding" each different response from each different external source, so we need to map them to an understandable format/structure (DIM metadata in JSON response).  This simplifies things for the client.   Also, this same mapping can make the import process easier once a user selects an external object to import into an Entity (as it's metadata is already mapped)
  • Tim understands now.  This PR looks generally good.  Will add some notes to the approval though that if we hit performance issues or other issues with implementing this generic endpoint, then (as discussed last  week) we may need to revisit this contract.  But, it seems like a good place to start work.

• Proposal on AIP export/import https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.qi8bp6kog7yi

  • Ben walked us through this early proposal.
  • One of the main questions were around adding the "place" field to DIM output (to represent the ordering of metadata fields, especially important for mixed metadata – relationships and string metadata)
    • Tim and Paulo note this DIM output is likely used elsewhere (Paulo thinks the OAI harvesting uses it too).  But, that's not necessary a bad thing – the place field could be helpful there too
    • Generally, no one disapproves of this direction.  Seems like a "place" field would help simplify things, but we may want to make it optional .  If the metadata fields are already ordered, then place can be assumed to be the order they are in.  But, when needed (especially for entity relationships), "place" can be explicitly added to the field.
  • Other discussion notes were added to the Google Doc directly
• Review our Updated Task List
  • Lieven is on holiday, and he wasn't able to pass along his work on this. 
  • We quickly ran through the tasks listed as "in implementation" to determine if any are complete.  None seem to be.  So, we need to better define/determine the remaining subtasks for each in order to add to an estimation spreadsheet
  • Lieven did have some notes on outstanding tasks from the North American User Group meeting talk on Entities.  Tim thinks those may have been higher level, but will review to see if they can be applied to this task list to make estimations easier here.
• Wrapped up meeting with assignment of PRs.  Next meeting is Tues, Oct 22.