- Revisiting Contract for Relationship lookups (PR: https://github.com/DSpace/Rest7Contract/pull/64)
- Decision: no strong opinion here on one being "more correct" than the other
- We will move forward with PR#64 as-is (except Ben will remove the "relationship: true" flag noted as not necessary)
- As we move to implement REST API and/or Angular UI interface, if we find this approach is complicating implementation then we will look towards alternative PR#65: https://github.com/DSpace/Rest7Contract/pull/65.
- Task #14 above
- All agree this is a real need & use case. However, it's not currently met by the existing implementation
- We can only provide a one-to-one link. So publication can be linked to an Org and a Person. Or we can provide a date range for a Person to Org relationship. However, we cannot yet say "This Person was affiliated with this Org when they wrote this Publication"
- While this is a real use case, it might be difficult to achieve in DSpace 7 without a much larger change to implementation (which we don't have time for).
- We will keep this task on the list, but will note that it's more likely to be achieved in DSpace 8 (i.e. post DSpace 7)
- Overview of Task #5 (didn't get to Task #7 today)
- Atmire proposed a way to define "temporary" identifiers in CSV spreadsheets, in order to allow one CSV to create two new Entities & link them together (i.e. the UUID for those new entities will be unknown in the spreadsheet)
- Tim noted this overlaps some with the idea of the "+" placeholder for creating new Items. Should we use "+" as part of that temporary identifier? (e.g. "+1", "+2", etc.)?
- It's important that these identifiers only exist in the CSV spreadsheet. They should NOT be stored in metadata in system as they are not guaranteed unique.