Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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.

...