2019-08-27 DSpace 7 Entities WG Meeting

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.).

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.

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.

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

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 "https://wiki.duraspace.org/pages/viewpage.action?spaceKey=~mwood&title=Entities%3A++Thinking+Bigger" 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.

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".

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.