Epic: Get the existing ROR plug-in working on the dataverse demo

[mreekie]

This script completes a single field on a form. Author affiliation

definition of done:

• [x] If it acts as intended, in particular the last time it broke other pages, the we can call this complete.
• [x] If it works well, we can put it out on demo.
• [ ] Make a recommendation as to if it can go into production
  • If this is the case this will lead to a separate issue to move the script into production

[mreekie]

priority discussion with Stefano;

• Size this.
• If it's not overly large, get it to the top of the sprint ready backlog
• Moved from NIH Deliverables Backlog to Ordered Backlog

[mreekie]

Top priority for upcoming sprint

[mreekie]

sizing:

• discussion is in the description
• size: 3

[mreekie]

sprint:

• Steve, Jim working through a blocker.
• Notes in slack

[mreekie]

Resizing for next sprint

• The original operating assumption was that what we started with was working. It's not.
• This makes the size grow.
• The original devs indicated that they understand that it's broken and we don't think that we can depend on them for fixed code.
• Part of what we will need to do is get into the controlled vocabulary. There is "first time" cost to this one.
• sizing at: 80

[mreekie]

Monthly update review

bump: @sekmiller

Steve, would it be possible to drop some breadcrumbs on this in such a way that my 5th grader brain can process them? The context is that I'm working on the monthly update

Here's my shot at it. Lemme know if it's accurate.

In this issue we installing a script for pulling down the Author affiliation field from the Research Organization Registry (ROR) in our demo dataverse. This previously ran and it represents a new lightweight way of retrieving this information and having more control over the user experience.

The feature no longer works out of the box as of 5.12 and so the scope of work has expanded to understanding what we need to do to get this working.

I'm unsure of whether the info that follows is within the expanded scope of this issue or will be in additional issues:

Coming out of our meeting on the topic of PIDs we decided that our initial level of support for ROR will include:

• The UI displaying information that is easily interpreted by the user
• The updating of the database with the data.
  • I don't recall that we agreed on anything further than what is done already in the existing ROR plug-in terms of what data will be stored to the database.
• Once it's working we'll get it out on demo.
• Then Make a recommendation as to if it can go into production
  • If this is the case this will lead to a separate issue to move the script into production

[mreekie]

sprint sizing:

• no change
• Still discovering

[pdurbin]

As discussed at the sprint kickoff just now 🏈 🏈 🏈 the backend code for this issue is dependent on this (currently draft) PR by @qqmyers:

• #9402

[qqmyers]

See https://github.com/IQSS/dataverse/issues/9150#issuecomment-1466871104 for info on an implementation mirroring the FundReg and ORCID scripts.

[mreekie]

See #9150 (comment) for info on an implementation mirroring the FundReg and ORCID scripts.

Daily

• Sounds like both of these will be handled in the same way for next steps.
• As mentionedSee: #9150

[cmbz]

Question for @qqmyers and @pdurbin:

• @mreekie's comment on 2023/03/14 seems to indicate that this NIH GREI deliverable (1.2.1) may be complete because https://github.com/IQSS/dataverse/issues/9150 has been closed (see: https://github.com/IQSS/dataverse/pull/9402).
• However, this issue: ROR/Author Affiliation example doesn't seem to "just work" as of 5.12 #12 seems to indicate that an implementation problem still exists.

Is this NIH GREI deliverable (1.2.1) complete?

[qqmyers]

#12 is obsolete and refers to the example that existed before #9150. Before the deliverable is complete, there are a few things to do:

• Merge #14
• perform some review/QA of the overall changes to Dataverse (#9150) with the new JavaScript (#14) w.r.t. the goals of the deliverable - could be done before or after #14 is merged
• fix any issues required to meet the goals for the deliverable (one potential issue is that the ror service can be slow and someone could decide that running our own copy is required to make things fast enough for production deployment)
• deploy where desired for the deliverable - which field(s) and whether this is to demo or dataverse.harvard.edu

These steps are somewhat generic and probably apply to FundReg and to ORCID as well (at least the parts related to the external vocab/lookup of people at the ORCID service).

[cmbz]

2023/12/18

• This feature is available on demo.dataverse.org
• Plugin doesn't "just work", as per: https://github.com/gdcc/dataverse-external-vocab-support/issues/12. This is a blocker for adding functionality to Harvard Dataverse.
• @jggautier will followup with @pdurbin to determine status and next steps for this issue and the related issue and update here.

[qqmyers]

FWIW: The "just work" issue is out-of-date, which is why ROR works on demo.dataverse.org - #9402 was added to v5.14 and the scripts were updated in https://github.com/gdcc/dataverse-external-vocab-support/pull/14. Whether the way it works on demo is good-enough to use in production or if further work is desired is a reasonable question, but if it is acceptable as a start, it's a size3 to put it on Harvard.

[jggautier]

Ah thanks. I was just about to ask about the "just work" issue. Should I just close https://github.com/gdcc/dataverse-external-vocab-support/issues/12 then? @pdurbin what do you think?

About determining if the way it works on demo is good enough, I think we've heard a bit from the ROR folks about best practices for using ROR that we could consider. We could do usability testing to determine how much of those best practices we should be following before we apply these changes to the Author Affiliation field in Harvard Dataverse.

And I have questions about how this affects several metadata exports, based on a quick review of the exports in Demo Dataverse, but I could start documenting those so they can be reviewed and worked on later if needed. If we did this, I would be concerned about us not finding the bandwidth to improve this later, similar to other issues where Dataverse exports were improved but extra steps are needed to apply those improvements to datasets that have already been published in Dataverse repositories, e.g. https://github.com/IQSS/dataverse.harvard.edu/issues/222 and https://github.com/IQSS/dataverse.harvard.edu/issues/146

[pdurbin]

@jggautier good catch. I just closed https://github.com/gdcc/dataverse-external-vocab-support/issues/12 in favor of this one.

[jggautier]

Thanks @pdurbin.

As discussed during today's Dataverse monthly meeting, the next step could be to evaluate the implementation and recommend more next steps.

We could do the following:

• Compare the change to the Author Affiliation field on Demo Dataverse - which includes a type ahead that makes suggestions from ROR's database - and ROR's best practices for using ROR. This could be a heuristic evaluation, where we ask ourselves how the current implementation does and does not follow ROR's best practices.
• Open issues about how the implementation affects how Author metadata is included in Dataverse's metadata exports and how it should be included

But ROR can be used to help users add other types of information, like:

• the names of authors that are organizations and the names of other types of contributors that are organizations (including "distributors", "producers" and funders)
• and the affiliations of authors and of other types of contributors that are people

So while it'll be helpful to evaluate at how ROR is implemented for just this Author Affiliation field, if we make any changes to how ROR is implemented for just this Author Affiliation field, apply those changes to Harvard Dataverse, and encourage other installations to do the same, we risk needing to re-evaluate those changes once we're able to consider the use of ROR and other external controlled vocabularies, like ORCID, across all of the metadata fields that Dataverse ships with, which is part of what https://github.com/IQSS/dataverse.harvard.edu/issues/230 is about. That work should involve considering larger changes, such as potential re-designs to the metadata model and the forms in the UI.

So I'm recommending that we:

• Evaluate the change to the Author Affiliation field on Demo Dataverse, comparing it to ROR's best practices
• Not apply this ROR implementation to the Author Affiliation field in Harvard Dataverse but instead...
• Document that evaluation so that we can build on it as we're looking at the use of ROR and other controlled vocabularies, like ORCID, across all of the metadata fields that Dataverse ships with

[jggautier]

We'll close this issue and open a new issue for what I recommended in my earlier comment about evaluating what's been put on Demo Dataverse and building on that evaluation as we're looking at the use of ROR and other controlled vocabularies, like ORCID, across all of the metadata fields that Dataverse ships with.