Page History
...
- Metadata schemas for Entity types (DS-4223).
- (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?)
- Creating Relations (between Entities) with CSV Batch Import
- Permissions on Relations (between Entities)
- Discussed on Aug 6
- Early Docs / Notes: https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.y6qarjnylexl
- Deleting Entities that have existing relations
- Deletion action itself:
- 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
- Early Docs / Notes: https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.c62y8iqnvlur
- Copy virtual metadata from deleted entity to related entity
- REST Contract: https://github.com/DSpace/Rest7Contract/pull/78
- REST impl: https://github.com/DSpace/DSpace/pull/2577
- Angular Impl (in progress / under review): https://github.com/DSpace/dspace-angular/pull/530
- Deletion action itself:
- Dynamic display of Relations
- Early Docs / Notes: https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.pm34t6u1djdf
- Completed, but may require usability improvements (NEEDS DISCUSSION - may be delayed for v7.1)
- Submission Integration Tasks
- Creating new Entities using Submission Forms
- Creating relations between two Entities during Submission process
- REST Contract: https://github.com/DSpace/Rest7Contract/pull/64 ,
- REST Impl: https://github.com/DSpace/DSpace/pull/2472
- Angular Impl (in progress / under review): https://github.com/DSpace/dspace-angular/pull/531
- Early Docs / Notes: https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.9aixusqzgcnp
- Search External Sources (includes ORCID integration with Entities)
- REST Contract: https://github.com/DSpace/Rest7Contract/pull/74
- REST Impl: https://github.com/DSpace/DSpace/pull/2560
- Angular is in implementation (no PR yet)
- Convert External Sources to an Entity
- If an Admin:
- REST Contract: https://github.com/DSpace/Rest7Contract/pull/82
- REST Impl (under review): https://github.com/DSpace/DSpace/pull/2590
- If a Submitter (Feature is NOT specific to Entities, as this is simply porting the "Live Import" framework of DSpace 6.x)
- REST Contract under review: https://github.com/DSpace/Rest7Contract/pull/83
- If an Admin:
- Name Variants
- Create name variants in submission
- REST Impl: https://github.com/DSpace/DSpace/pull/2561
- Angular Impl (in progress / under review) - this is included as part of https://github.com/DSpace/dspace-angular/pull/531
- Display name variants on Item pages (Angular)
- Create name variants in submission
- OpenAIRE v4 support (using Entities)
- Configuration of Entities needed for OpenAIRE v4: https://github.com/DSpace/DSpace/pull/2575
- Configuration of Metadata fields/schemas needed for OpenAIRE v4 (under review): https://github.com/DSpace/DSpace/pull/2576
- Configuration of Submission Input Forms for OpenAIRE v4 (in implementation, no PR yet)
- Configuration of OAI-PMH for OpenAIRE v4 (in implementation, no PR yet)
- How to display related items on an Item page if that related item is still in workflow approval
- Early idea is to simply display the related item as plain text metadata (until workflow approval completes).
- Edit Item page integration
- Relations in AIP Backup & Restore
- Creating Relations in SAF Import (might be postponed for a future release)
- Requires AIP Backup & Restore
- Proposal: https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.n8ktliibe7kj
- SWORD integration (might be postponed for a future release)
- Requires AIP Backup & Restore, as SWORD uses the same crosswalks / format as AIP.
- Proposal: https://docs.google.com/document/d/1X0XsppZYOtPtbmq7yXwmu7FbMAfLxxOCONbw0_rl7jY/edit#heading=h.xufwyy1ep8h2
- 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.
- 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
- 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).
- 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.
Overview
Content Tools