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

Date & Location

 at 15:00 UTC (11:00am EST)


Join from PC, Mac, Linux, iOS or Android:  (Meeting ID: 502 527 3040)


Actual attendee list will be updated after meeting.




Any additional topics to today's agenda?

220minsEntities + Authority Control

Deeper dive discussion into how Entities will work with Authority Control, and how ORCID integration will work (as ORCID integrates with Authority Control). Some useful resources: 

Atmire + All
Topic #2Any other topics??
55minsWrap-up and Assigning tasks
  • Assign tasks / PRs to review (as needed)
  • Next Meeting is Tues, Sept 3

Current Work

Tickets to Resolve

PRs Needing Review

  1. (HIGHEST PRIORITY) (REST) support for defining relationship lookups in the submission forms UPDATED ( (tick) Tim Donohue - Will Review Alexander's commentsAlexander Sulfrian - re-review)
  2. (NEW) (REST) Rename properties and support for name variants (Tim Donohue , Dimitris Pierrakos )
    1. related to
  3. (Angular) (Entities) Deleting relationships: UPDATED (Paulo Graça - (warning) reported issues, Tim Donohue - REVIEW)
    1. Has been updated by Kristof => (Video of Ben using this PR)
  4. (Angular) (Entities) Grid templates for entity types ((tick)Paulo Graça, Alexander Sulfrian , Tim Donohue  - REVIEW)
  5. (NEW) (Angular) Rename relationship type properties ((tick) Tim Donohue, HAS A SECOND REVIEW)
  6. (Backend) (Entities) DS-4316: Indirect entity refs during csv import UPDATED (Tim Donohue - re-review, Ben Bosman - re-review, Paulo Graça - added feedback )

PRs Merged this week!

  1. (Rest Contract) (Entities) Rename properties and support for name variants:

Task List

This list was roughly prioritized in the meeting on May 23, 2019 (just before OR2019).  The prioritization below may change, but it gives a high level overview of what still needs to be done. NOTE: Keep in mind, just because an item is listed here does NOT guarantee it will be completed for DSpace 7.  Some of these tasks may need to be delayed for a future release.

  1. (Lieven, Ben, Tim, Fernando, Jose, Mark, Oliver, Paulo) Submission integration (creating Entities & relations using the Item submission process) - Mockups already created by Paulo previously. - In implementation
  2. (Lieven, Ben, Tim, Jose, Oliver, Paulo) Which metadata fields should be used for each Entity type. (DS-4223).  - In implementation
  3. (Lieven, Ben, Tim, Mark) Additional data for relations (essentially "metadata" or labels on relations) - Related to many other features / use cases.   - In implementation
  4. (Oliver, Paulo) Author name variants  - In implementation
  5. (Jose) Configuration of batch import (via CSV) for Entities - Already a CSV import available, but can only link entities in CSV to existing entities (in the system). Need to decide how to represent relations in CSV. - In implementation
  6. (Mark) Permissions on Relations (who has permissions to add/modify/delete relations) - Currently, if you have Edit permissions on the Entity, then you can edit/delete any relationships to/from that Entity. (NEEDS DISCUSSION)
  7. (Fernando) Deleting objects with Relations (How or should deletion propagate between closely related objects, e.g. delete entire Journal) - Currently, deleting a relation just decouples the two Entities.  E.g. If you delete a Person entity, that Person may no longer be listed on any Publications it is linked to (may want to copy info over after deletion).  - Discussed on Aug 6
    1. Relates to GDPR
  8. (Alexander) AIP Backup & Restore (of Entities)*
  9. Dynamic display of Relations - determine automatically how a list of entities displayed on an Item page (list vs search). Currently hardcoded based on entity type (in item page template). Want to make it configurable/dynamic. (NEEDS DISCUSSION)
  10. SWORD integration (submission of Entities via SWORD) - Uses same format as AIP. Once AIP is implemented, SWORD should be easy.
  11. OpenAIRE v4 implementation using Entities* - Brought up in Steering.  Possibly just an OAI-PMH configuration which maps Entity metadata fields to OpenAIRE v4
  12. ORCID integration with Entities (for Person Entities). (Related to #15)
  13. Best Practices around Entities in Collections.  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.  Can we hide these Collections which only serve to store Entity Type.
  14. The ability of pick the proper affiliation of a Person for a specific context. DSpace should address this use case to allow the user to describe something like in this document regarding the authors and affiliations. You have different persons, each can belong to an institution at the time of that publication. The affiliation shouldn't be changed afterwards. And the user should be able to pick the proper one if an Author has more than one.  (PER discussion on July 16, this is lower priority and may be more likely to be implemented in DSpace 8)
  15. (REQUIRED) Deeper dive discussion into how Entities will work with Authority Control, and how ORCID integration will work (as ORCID integrates with Authority Control). Some useful resources:  (NEEDS DISCUSSION - On agenda on Aug 27)


  • Discussion of Entities + Authority Control
    • Slides / Mockups presented by Lieven
    • Includes a brief status update of Entities in Submission progress (screenshots from active work).  Does not include all functionality yet, but has the basics of searching & selecting Entities via a popup module
      • Tim asks if it's time to do an initial PR of this work? Is this a good "first cut"?   Ben will talk to Art
    • Authority Control mockups
      • Cover cases of displaying Authority Control vs Entities, how to make it clear when users are importing from external sources (into either an authority record or Entity)
      • Does not yet cover how to convert Authority Record to Entity (or visa versa), or upgrading authority control (as needed)
      • Basic idea is a single search, but a tabbed view of results... "Local Entities", "Local Authority", one or more external source tabs (e.g. ORCID), and a "Current Selection" tab.
        • Tabbed approach was chosen because facets only apply to some tabs & search results are displayed slightly differently based on the source.  Also, it better clarifies external sources (which must be imported) vs internal sources
        • Also, worth noting that tabs would only appear based on field configuration. If entities is disabled in your system, the "Local Entities" tab would not appear.  Same if you don't have Authority Control configured on a field, then the "Local Authority" tab would not appear, etc.
      • All feel this approach is definitely clearer than Authority implementation in DSpace 6.
      • However, End Users may not understand "Entity" vs "Authority" concept. We may need clear documentation / use cases to define why an end user would choose one over the other.
        • E.g. some local policies may decide to have Entities for local staff and Authority Records for external collaborators (who work at a different institution)
        • We may also want to add descriptive hints / tooltips into the UI itself to describe Entity vs Authority.  E.g. for People, an end user might want an Entity if they want to create a Profile page.
      • When importing from an external source, user will have option to create either an Entity or an Authority.... also, system will check for existing Entities & Authority Records to prompt you to enhance them instead of creating a new one.
        • Might consider doing something similar to allow transforming an existing Authority into a new Entity.  However, that hasn't been fully figure out & other question exist (e.g. when creating an Entity from an Authority, would all relationships be auto-created based on where Authority record was linked?)
      • Overall, all agree this general design is a great first step.  We may have areas to enhance / improve on, especially as we do more user testing...but this is a nice design overall.
  • Assignment of PRs for this week
    • See updates to PRs Needing Review above.
  • Next meeting is next week, Tues Sept 3 at 15UTC.  Agenda topics are welcome, please send to Tim or mention on Slack (#entities-wg channel)

  • No labels


  1. I have had a chance to look quickly to these note and I cannot avoid to recall that we are now discussing a problem, Entities vs Authorities, that we have created ourself without IMHO a clear idea of why we need a new separate concept (the entities) instead than build upon the entities.

    That said, I see also a discussion around local authorities that I guess refer to the SolrAuthority implementation and so to the authority SOLR core. Please keep in mind that DSpace doesn't give and shouldn't give a prominent role to this authority. The authority framework doesn't know about Remote / Locale and there is no reason to introduce it... or at least I suggest to think two times before to go over an ORCID implementation that make use of "three" steps (remote, local, entity). If you want to have rich information about the author you should use the entity, if you are fine to just identify it use the authority framework and you can simply keep the ORCID as authority value (without all the complexity to keep the authority core, rebuild, etc.).

  2. Andrea Bollini (4Science) : I think it is important to realize that quite a bit of the context around these discussions may be lost in the simple meeting notes above.  While in the notes I described this discussion as "Entites vs Authorities", the discussion in this meeting was more around how to support & integrate both concepts (at the UI layer, especially in the submission) and make it clearer when users should use Entities and when they should use Authorities (much along the lines of exactly what you've described).

    Additionally, to clarify, the concept of "Local" and "Remote" actually doesn't imply any changes to the authority framework at all.  That was simply terminology we were using in the UI mockups to make it clearer (to end users) in the Submission UI when they are "importing" data from a remote source (e.g. creating a new "local" authority value or "local" Entity from an external source like ORCID) and when they are simply selecting an already existing "local" reference (e.g. either selecting an existing Entity or an existing Authority value).

    Obviously it's very hard to capture the full context of a discussion in meeting notes.  I just wanted to clarify that at no point in this meeting did we talk about changing the existing Authority framework.  We were more talking about how to design a UI that can both interact with Entities and Authority records, and help end users to understand the differences between them..... I don't think we've fully figured out that UI design, but the mockups presented some good initial progress. Though we have plans to also get feedback from actual users on how to make this all clearer.

  3. I should also note there was no discussion of a three step process of moving things from remote (e.g. ORCID) to local authority to entity.  Instead, as implied by the mockups, we were just discussing how to present the option of either pulling data from ORCID into an authority value or pulling data from ORCID into an Entity.

  4. thanks Tim Donohuefor your quick reply. Unfortunately, I found the terminology here and in the slides/wireframe confusing and I want to be sure that no one is mixing the concept of authority value with the way that the SOLRAuthority is implemented. When you talk about putting ORCID data into an authority value it seems to imply the SOLRAuthority implementation that again is just one possible implementation. If you look to the SherpaRomeo example authority for instance there is no "authority value" record at all but only the authorityvalue "column" inside the metadata value. In my opinion will be better to say external data are stored as authority in the metadatavalue avoiding the use of "into" that seems to imply richer information / additional structure.

    I appreciate your clarification about the absence of intention to change the authority framework because, as you know, this is a very important point of interest for me as DSpace-CRIS will rely on that and we want to keep the distance between dspace-cris 7 and dspace 7 minimal

  5. Just a sidenote (based on your response).  We didn't discuss in any great detail how the Authority System works right now.  So, when we were saying an "Authority Record" or "Authority Value" we were using that as a generic phrase to simply mean "the info that the Authority System is storing" (either in metadata or Solr). We were not referencing anything about the Authority implementation(s) themselves. 

    So, quite literally, this meeting's discussion was much higher level. It was involving how to design a UI that can "make sense" for both Authority & Entities, and ideally one that still works fine if you choose to only have Authority enabled or only have Entities enabled.  We honestly didn't dig into the Java layer or even the REST layer/design here, it was all a discussion at the Angular UI design level.

    All that said, obviously you are more than welcome to jump into one of these meetings when a topic of interest comes up.  I do my best to share the agenda for the meeting at least a day or so in advance in our Slack #entities-wg channel.  If more detailed discussion of how Authority works right now comes up, I'll try to remember to also let you know.

  6. Sorry for not being available for this meeting. But for what I read and understood from the notes and Mockups, I've got the same feeling as Andrea Bollini. That Authority Control and Entities integration was discussed in that meeting, not only at an Higher level as Tim mentioned. And another reason that reinforced that feeling was the recent Pull Requests for RestContracts regarding that integration. I tend to agree with Bollini, there isn't a consensual idea for a solution on this matter and Mark's envision on the document "" it's the proof for that.

    As I had the opportunity to comment on Mark's document or some comments on Lieven's documents, I see Entities taking more space in DSpace, assuming some of responsibility and centralizing and simplifying some existing mechanisms. One great example is the Authority Control mechanism. I see Authority Control more and more as a way to relate to External repository stuff. And it will make sense to transform this mechanism in a way to bring that stuff into the repository in the form of Entities and to provide ways to generally manage them. This is also the idea I've got from what Mark shared.

  7. Regarding the mockups, I generally tend to agree with the arrangement. I think it's a great idea for having those sources on separate tabs, my concern goes to "badge" with the counter. To accomplish that one must perform a query for every service and wait for the result. That might hang the user, or add more time to load a thing we want to use frequently, and even the requested service might not support totals, leaving us to follow each search page to grab the total of records. Which is impractical to do and to use. I would suggest to do only a search per tab, only when that tab separator is active and the query string is changed. But generally it's a good solution for our users to have each source in a tab. And each source it will be have a different layout, depending on what the source provider enables (filters, facets,...). Noting: ORCID have the importers concept, where the user must choose which importer to use to grab/bring data into ORCID.

    I also think "Local Authority" and "Local Entities" terms will be confusing for users because these are technical implementations separations, not a real valued feature if one it's only interested in finding a local stored resource. Doing this we are throwing complexity to the user and creating usability barriers. The solution for that it would be to only provide searching on entities. I understand this is a "radical" and disruptive thought and we need to have an intermediate solution, but looking at current DSpace feature, we only have a lookup feature for Authority to support. I think we should consider this as a separate Authority lookup, other than Entities lookup. Avoiding to introduce this complexity and usability barrier: "When importing from an external source, user will have option to create either an Entity or an Authority".

  8. An update to the discussions in these comments.  In today's (Sept 17) Entities Meeting, we revisited the outcomes/discussion of this Aug 27 meeting to clarify what was discussed and what definitely was not  discussed.  The Q&A was detailed in the notes here: 2019-09-17 DSpace 7 Entities WG Meeting#2019-09-17DSpace7EntitiesWGMeeting-Notes

    To summarize, Paulo pointed out that some of the Mockups had usability issues – we all agreed with that both on Aug 27 and today.  These mockups were never "finalized" but were treated more as brainstorms for how we might display/search Entities and Authorities alongside each other.  Paulo noted he'd get feedback from his team too & bring it back (and others are welcome to do the same)

    Paulo also pointed out that the Mockups seemed to imply a new feature for Authorities...that you could select a "Name Variant" (as names are shown as dropdowns in the Mockups).  This was a misunderstanding, and seems to be a copy & paste error in the mockups.  There are NO new features to be added to the existing Authority System in DSpace 7.  Therefore, "name variants" will only be a feature of Entities (and not available in Authorities). All discussion on Aug 27 was intended to simply find a way to allow Entities & Authorities to exist alongside each other.

    We also clarified today that some of these mockups would only appear if you (as a System Administrator) chose to enable both Entities and Authorities.  As both features are optional, you can choose to only enable one (which means there's no need to choose between them), or even neither.  However, we do want to support enabling both (if sites want to), which is the reason why the mockups present early brainstorms for how that might look.