Page tree
Skip to end of metadata
Go to start of metadata


Discussion (combined Angular UI & REST meeting)



  • General updates:
    • Tim and Andrea attended the DSpace 7 Marketing Working Group meeting (yesterday).
      • Tim will be attending these (they are every other week)
      • Outreach group seems excited to help review mockups and give feedback.
        • At the next meeting, Andrea will present/walkthrough the mockups for the Submission wizard with this group
  • Angular UI Team updates (from Art)
  • REST API Updates (from Andrea)
  • Discussion of updated Submission Wizard & Deduplication mockups
    • Submission wizard
      • Questions about "File Access policies" (Files and access condition (editable mockups)). How are these configured?
        • Andrea Answer: Access policies should be configurable per Collection. However, how to configure it is still not decided
        • Tim: As this is newer functionality, we may want to scope this back (to something more similar to DSpace 6) if we find this too complex to configure.
        • Also a question about whether these policies should be editable to submitters, or just to reviewers of submissions?  Could this be configurable?
          • Can be considered here, but as that is also new functionality, it may need to be delayed until post-DSpace 7.
    • Duplicate detection and merge tool
      • Andrea overviews how this will work on backend (and added more description to this new wiki page at the top)
        • Based on deduplication functionality recommended by Solr ( 
        • The idea is to essentially generate signatures (md5 hashes) that represent specific comparison "algorithms" (e.g. a hash to represent title+author)
        • If the signatures between two items are identical, then they are flagged as possible duplicates.
        • Signatures would be stored in Solr, and would be (re)generated each time an Item is indexed
        • We could configure multiple deduplication algorithms in DSpace
          • e.g. If there are 2 algorithms in use, then each Item would have two signatures (one per algorithm). This is what is shown as an example in "Title" and "Identifier" tabbed mockup, as those are two algorithms
          • Items would then be a possible duplicate if they have one matching signature.
      • Submitter will have the opportunity to determine whether a possible duplicate is in fact a duplicate
        • They may still wish to submit a duplicate if the original's metadata is incorrect. Submitter can add a comment to ask the two entries be merged.
      • Andrea agrees with feedback from last week that the "Possible duplicate" Popup is not ideal in the Submission UI
      • The Tabbed duplicate merger screens are Administrative screens. May need more feedback.
      • Is this work "in scope" or are we starting to expand the scope too much with this work?
        • Andrea feels this feature is a good example of extendability of the Submission UI, i.e. creating a custom "step" (as well as of Admin UI functions)
      • We should consider treating this as an "add-on" for now. Still give feedback on the work, and help with the designs, etc.  However, based on how other work progresses, we may need to determine whether this will be "in scope" for DSpace 7, or whether this is initially shipped as an "addon" and brought into DSpace later
  • Next Meeting is Thurs, Oct 5 at 15UTC via Google Hangouts