amoeba
commented
7 years ago I think this is pretty interesting. At a high level, I'm thinking "What's the benefit to the user?" and "Why would they do work for us?" I think the answer to this is "help us help you help us". Linking ORCIDS enables:
- Us to show people your other datasets across DataONE (which right now we often can't or, if we can, we can't do it with confidence)
- Us to show people your other scholarly works elsewhere online via your ORCID
- Us to auto-fill your ORCID profile with your datasets (probably cool for some people?)
I would bundle this type of work along with all of the related work (or wishing) to get users to hang around DataONE a bit more, make profiles, contribute (e.g., annotations). So while this could only have a small impact given how rare emails are in DataONE, it would be part of a larger objective.
To your questions:
-
Whether to support ORCID annotations outside of metadata document editing, and where to store the information
I think linking datasets to ORCIDs is a no-brainer in 2017.
The flow I can imagine would be a dataset gets published on a Member Node with names, emails, etc., but no ORCIDs. Then, either on the MN or CN, emails are sent to users to fill in their ORCIDs. At that point, they'd click a link to go link their ORCID on our site. Is that about what you imagined?
That last step, the linking, is a bit of a challenge to wrap my head around. Immediate ideas include:
- If we choose to just store these linkages as Annotations, we could do the linking directly on the dataset landing page, treating it like any other annotation, and the user would click around on the page on the parties they wanted to claim. This would be a client-oriented interaction
- Add a page to the user Profile of all the unclaimed ORCID linkages and they would just click one button and be done. I think this is the best because a user may have many claims to process so doing the linking directly on the dataset landing page would be cumersbome. This would be a mix of client and server actions (background jobs, persistence)
-
Whether to send notifications to users in Creator fields that have emails but don't have an associated ORCID
This gets into spammy behavior real quick. But at the same time, if someone submits your dataset to a repository it's also kind of a nice service to get notified of getting credit. Certainly these publishers do these kinds of cold-emails all the time.
-
How to implement the feature in Metacat and MetacatUI
My ideas above enter into this territory a bit. I think the best way would be to kick off a background job on createObject and updateObject that parses through the metadata and finds parties w/o ORCIDs but w/ emails, stores what it finds in a database, and does the emailing. Then, for MetacatUI, we'd need to expand the D1 API a bit so MetacatUI could query for the linkages a user needs to confirm and confirm them via the API
RIght now the only way to get an ORCID in the system is to have the submitter include an ORCID inside their metadata record. For journal publications, when I am listed as an author on a paper, I get an email asking me to claim my authorship by associating my ORCID with the paper. See the email attached below for an example.
For this ticket, let's evaluate whether it makes sense to support a notification and claims system like they do in journals, and if so where and how we would store those annotations. One possibility ios to associate the ORCID with a canonical user identity, and then associate data sets with that (e.g., from the GeoLink graph work).
To close this, make design decisions on: