Versions Compared

Key

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

...

  1. (tick) Metadata schemas for Entity types (DS-4223). 
    1. REST: https://github.com/DSpace/DSpace/pull/2443 , Angular: https://github.com/DSpace/dspace-angular/pull/420
    2. Early Docs / Notes: https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.wjaqg235p53r
  2. (warning) (Minor refactor) Decide which metadata field should be used to store Entity Type (DS-4184).  Currently, it is stored in "relationship.type". (DEEMED LOWER PRIORITY, but "nice to have" for 7.0 if possible?)
  3. (tick) Creating Relations (between Entities) with CSV Batch Import 
    1. REST: https://github.com/DSpace/DSpace/pull/2269 and https://github.com/DSpace/DSpace/pull/2471 and https://github.com/DSpace/DSpace/pull/2522
    2. Early Docs / Notes: https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.df1z7jh9mcc
  4. (tick) Permissions on Relations (between Entities)
    1. Discussed on Aug 6 
    2. Early Docs / Notes: https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.y6qarjnylexl
  5. Deleting Entities that have existing relations
    1. (tick) Deletion action itself:
      1. REST Contract: https://github.com/DSpace/Rest7Contract/blob/master/relationships.md#deleting-a-relationship , REST: https://github.com/DSpace/DSpace/pull/2332 , Angular: https://github.com/DSpace/dspace-angular/pull/402
      2. Early Docs / Notes: https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.c62y8iqnvlur
    2. (warning) Copy virtual metadata from deleted entity to related entity
      1. (tick) REST Contract: https://github.com/DSpace/Rest7Contract/pull/78
      2. (tick) REST impl: https://github.com/DSpace/DSpace/pull/2577
      3. (warning) Angular Impl (in progress / under review): https://github.com/DSpace/dspace-angular/pull/530
  6. (tick) Dynamic display of Relations
    1. Early Docs / Notes: https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.pm34t6u1djdf
    2. (warning) Completed, but may require usability improvements (NEEDS DISCUSSION - may be delayed for v7.1)
  7. Submission Integration Tasks
    1. (tick) Creating new Entities using Submission Forms
      1. REST: https://github.com/DSpace/DSpace/pull/2443
      2. Early Docs / Notes: https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.9aixusqzgcnp
    2. (warning) Creating relations between two Entities during Submission process
      1. (tick) REST Contract: https://github.com/DSpace/Rest7Contract/pull/64 ,
      2. (tick) REST Impl: https://github.com/DSpace/DSpace/pull/2472
      3. (warning) Angular Impl (in progress / under review): https://github.com/DSpace/dspace-angular/pull/531
      4. Early Docs / Notes: https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.9aixusqzgcnp
    3. (warning) Search External Sources (includes ORCID integration with Entities)
      1. (tick) REST Contract: https://github.com/DSpace/Rest7Contract/pull/74 
      2. (tick) REST Impl: https://github.com/DSpace/DSpace/pull/2560
      3. Angular is in implementation (no PR yet)
    4. (warning) Convert External Sources to an Entity
      1. If an Admin:
        1. (tick) REST Contract: https://github.com/DSpace/Rest7Contract/pull/82
        2. (warning) REST Impl (under review): https://github.com/DSpace/DSpace/pull/2590
      2. If a Submitter (Feature is NOT specific to Entities, as this is simply porting the "Live Import" framework of DSpace 6.x)
        1. (warning) REST Contract under review: https://github.com/DSpace/Rest7Contract/pull/83
  8. Name Variants
    1. (warning) Create name variants in submission
      1. (tick) REST Impl: https://github.com/DSpace/DSpace/pull/2561
      2. (warning) Angular Impl (in progress / under review) - this is included as part of https://github.com/DSpace/dspace-angular/pull/531
    2. (tick) Display name variants on Item pages (Angular)
  9. (warning) OpenAIRE v4 support (using Entities)
    1. (tick) Configuration of Entities needed for OpenAIRE v4: https://github.com/DSpace/DSpace/pull/2575
    2. (warning) Configuration of Metadata fields/schemas needed for OpenAIRE v4 (under review): https://github.com/DSpace/DSpace/pull/2576
    3. (warning) Configuration of Submission Input Forms for OpenAIRE v4 (in implementation, no PR yet)
    4. (warning) Configuration of OAI-PMH for OpenAIRE v4 (in implementation, no PR yet)
  10. (warning) How to display related items on an Item page if that related item is still in workflow approval
    1. Early idea is to simply display the related item as plain text metadata (until workflow approval completes).
  11. (warning) Edit Item page integration
    1. How to display relationships on "edit metadata" tab in UI.  How to add relationships on "relationships" tab in UI.
    2. Angular UI Mockups discussed/approved on Nov 5 and Nov 12.
  12. (question) Relations in AIP Backup & Restore
    1. Discussed on Oct 15
    2. Proposal: https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.qi8bp6kog7yi
  13. (question) Creating Relations in SAF Import (might be postponed for a future release)
    1. Requires AIP Backup & Restore
    2. Proposal: https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.n8ktliibe7kj
  14. (question) SWORD integration (might be postponed for a future release)
    1. Requires AIP Backup & Restore, as SWORD uses the same crosswalks / format as AIP.
    2. Proposal: https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.xufwyy1ep8h2
  15. (question) Best Practices around Entities in Collections (NOT: this may just be early documentation).  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. 
    1. Should we eventually consider hiding these Collections which only serve to store Entity Types?

Notes

  • Question from last week (Nov 26):  How do we handle "relatedIdentifiers" vs "alternateIdentifiers" in our DSpace metadata?

    • The new Schema.org identifier fields in PR#2576 seem to correspond to "alternateIdentifiers" (e.g. person.identifier.gsid is an alternative Google Scholar identifier for the Person Entity). 
      • These fields represent (externally created) Identifiers that correspond to the Entity in DSpace. For example, if a publisher has its own DOI, then the publisher's DOI would be stored in these fields....while the DSpace-generated DOI would be stored in "dc.identifier.uri" as normal.
    • "relatedIdentifiers" concept could be represented as new "oaire.relatedIdentifier.*" fields perhaps?  (Jose Carvalhoand Paulo Graçawill discuss and get back to us)
    • DECISION: was to remove the identifier fields from publication and rely on `dc.identifier.*` for that entity type (for now).  Some identifiers were added to other Entities however.  See PR#2576 for updates
  • Discussion about entities on XOAI layer (https://github.com/DSpace/DSpace/pull/2592) The way XOAI uses Solr, we foresee that Solr will get some weight and also the "/dspace/bin/dspace oai import" method will be a little bit slower using this approach (this was negligible with our experience with DS5, but we just processed Publications, now we may also process Persons). At the moment the only possible solution that occurs is to have a configuration (perhaps on oai.cfg) to enable/disable entities. Other suggestions includes filtering by the relationship label, like: isAuthorOfPublication.
    • Some possible OAI-PMH performance issues noted, if we are loading large numbers of objects (e.g. all related Entities) in order to fill out the response of one Entity.
    • Possible solution: Do not  load up all related Entities...instead, just load the info available on the relationship object (i.e. a Label and the Entity ID).  This may speed up OAI-PMH requests as we'll be loading less objects.  However, it may not be exactly what the OAI harvesters expect (uncertain).
    • Could also consider precaching these responses for speed, but that may add a lot of complexity to DSpace itself.  The primary limitation here is within OAI-PMH, and this isn't a DSpace-specific issue.