Page History

...

• 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.)?
    • Batch Metadata Editing#AddingMetadata-OnlyItems
  • 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.

...