search

gbif / portal16

GBIF.org website
https://www.gbif.org
Apache License 2.0
24 stars 15 forks source link

Allow linking a user's ORCID account with a their GBIF.org account #297

Closed kbraak closed 6 years ago

kbraak commented 7 years ago

Allow linking a user's ORCID account with their GBIF.org account. ORCID is the standard persistent digital identifier for researchers.

Linking a GBIF.org account to an ORCID account would have the following benefits:

Here is how it would work:

Additional information:

Related to Implementation Plan item 1.a.i: "Develop mechanisms to support and reflect the skills, expertise and experience of individual and organizational contributions to the GBIF network, including revision of identity management system and integration of ORCID identifiers"

@dschigel @ahahn-gbif

peterdesmet commented 7 years ago

Excellent idea! I would go even further and eventually fase out registrations that are not done via ORCID. That's the approach ImpactStory took (example), which now bases all its altmetrics on ORCID. It has the advantage that 1) there is an incentive to add ORCIDs to your works (so you could see their altmetrics) and 2) you only have to manage the link between your works and your identity on ORCID.org.

Advantages (some already mentioned):

  • allows GBIF to show the user a list of datasets they have contributed to (where their ORCID is included in the dataset's metadata)

Well, that can technically already be seen in a DataCite search, on your ORCID profile (but not filtered on datasets) or ImpactStory (example) (but not filtered on GBIF datasets), but not a lot of people know that and it is still nice to have it on your GBIF profile.

  • allows GBIF to ensure the contact information shown (e.g. on dataset page) is up to date pulling information from the ORCID versus using what could be stale data

Yes! Although I'm not sure if the option should still exist to toggle between the two? Contact management in the IPT (https://github.com/gbif/ipt/issues/1166) is partly to blame for the stale data.

And if GBIF also exposes these metrics (or at least metrics for a dataset) via the API, then these could be be integrated with ImpactStory (cc @jasonpriem @hpiwowar).

peterdesmet commented 7 years ago

In fact, I’d like to (publicly) see datasets, occurrences, maps, citations associated with an ORCID (and publisher, network, country) before I want the ORCID to be integrated with the user registration. 😄

rdmpage commented 7 years ago

We can also connect ORCIDs to taxa. Many recent taxonomic papers with have authors with ORCIDs, and GBIF is consuming some sources of recent taxonomic work (e.g., Plazi). We could link those papers to ORCIDs (e.g., via their DOI, see https://enchanting-bongo.glitch.me for a simple tool that does this). This way we build profiles for users before they even register, plus we can show that people are contributing to GBIF even if they don't know it (see http://iphylo.blogspot.co.uk/2015/08/possible-project-itaxonomist-combining.html ).

dshorthouse commented 7 years ago

We could also connect ORCIDs to BOLD records & GenBank accessions, though we'd have to walk along many edges to fill gaps.

...but before @gbif-portal goes down this new road, it would be worth thinking very strategically about what a focus on users really means. It's been historically focused on data providers & nodes. This could be a very significant shift in model. If you want people to create accounts &/or link their ORCID & then ask them to execute a task (eg "are these your type specimens"?), that's when they'll be most active. You'll never see the majority of users ever again. Where does that leave the data providers and nodes in a user-centred focus on the portal? Do they receive any benefit? There will be one chance to get this right. This stickiness/linkage between ORCID & GBIF should mean something. If I were to log into ORCID, would it know anything in GBIF as it does with Crossref? ORCID makes a nice CV for me, shouldn't it also draw-in a summary of all my determinations? I'd be much more inclined to pay attention if the link between ORCID and GBIF were bidirectional.

rdmpage commented 7 years ago

@dshorthouse Good point. If the ORCID model is "here are all the 'works' associated with your ID" and those works are currently papers, data sets, and parts of papers (e.g., figures) then one approach is to have a 'work' associated with something meaning for both GBIF and the user. One model is "nano publications" where some activity is captured and given a DOI. This then raises the question of what is a meaningful unit of work, and can the GBIF platform support that work. For example, if I view a specimen image on GBIF and make a determination ("this is species 'x'"), can I mint a DOI for that 'work'? GBIF isn't close to being able to support this sort of activity, but it's work thinking about.

MortenHofft commented 7 years ago

This is informative. So general agreement we should do something with ORCiD, but based on

In fact, I’d like to (publicly) see datasets, occurrences, maps, citations associated with an ORCID (and publisher, network, country) before I want the ORCID to be integrated with the user registration @peterdesmet

and

There will be one chance to get this right. This stickiness/linkage between ORCID & GBIF should mean something. @dshorthouse

I take it that you do NOT want to see an ORCiD login until GBIF can do something more meaningful with it. How much as a minimum is open for discussion.

Is that correctly understood?

dshorthouse commented 7 years ago

@MortenHofft I agree that something meaningful should be done with ORCiD, but it depends how ambitious GBIF wants to be. If, as I hope it is, the overarching goal is to get as many researchers to log in with their ORCiD as possible, then it's in GBIF's best interest to make sure that the new experience is rewarding for both sides.

At the moment, https://www.gbif.org/user/profile (when logged in) is sparse and does not encourage repeat visits. Besides drawing in publicly available information from one's ORCiD to present here in this profile, what can GBIF show me that is "my" stuff? This is where you have a spectrum of options ranging from very easy to very hard.

Easy: a dataset list by matching user's ORCiD in indexed eml documents from the registry. But, is this meaningful to either me as a user or to GBIF? Not really. Hard: list of "my" occurrences (eg my name in identifiedBy, recordedBy, scientificNameAuthorship). Is this meaningful? Absolutely. But, it'll be dependent on data providers having already associating occurrences with ORCiDs and then sharing that information via an as yet non-existent DwC-A extension. You otherwise have to resort to string matching - you don't need a relationship with ORCiD for that.

Assuming the "Hard" option above is immediately intractable, is there something a bit more ambitious than "Easy"? What if when you log in to GBIF via ORCiD, you are prompted to:

  1. Make your GBIF profile public, populated with what's known from ORCiD - you'd never have free-entry fields for user profiles, but could have a button to allow the user to refresh their profile from ORCiD if the cached information at GBIF's end is stale
  2. Prompt user to ask if they want their now public profile included on a Country page/report (or elsewhere on GBIF pages where that might be useful).
dschigel commented 7 years ago

I guess many here would agree that data activities should become part of the key academic activities that together make a profile / CV / ORCID page. Today, such activities are publications, training, degrees, positions held, funding received, students supervision, opponent and committee roles, society memberships etc. Any CVs would have those. There are also emerging activities, that has been there, but were not counted until recently - look what Publons does with publication reviews. Data activities are similar - everyone works with data but this work is rarely reported as a measure of academic or curatorial performance. We know that in some context data activities if measured and used at the right moment, do make a difference for receiving funding and jobs - Amy Zanne, one of the GBIF User Club speakers told she successfully used the fact in her uni that her dataset was the most downloaded from Dryad for a year or so. I suggest when selecting the meaningful data activities to add to the user profile, we will not only look on what's feasible and what will look good but also what makes a person active in GBIF to be even more active, so the lists and metrics will grow. I guess this is in line choices summarised by @dshorthouse. Put together, individual data metrics provide a possibility for calculating tresholds for e-badges and also magic numbers, such as Research Gate score and Data citation indeces, with all the controversy magic numbers bring. To me a natural start would be from the GBIF roles and some summary starts for each person: originator of X datasets (N records), metadata author of Y datasets (M records). By bringing in some Publons-like functionality we will come closer to the peer-review of datasets.

dshorthouse commented 7 years ago

re: magic numbers

To push this even further, we could suppose that GBIF be the organization that leads the calculation of a transparent "magic number". I've toyed with this a little bit and it's worth additional thought: http://collector.shorthouse.net/about.

The index rewards the identification of one's own specimens to species (the "naturalist" component) and one's network of fellow collectors along with deposition of specimens in multiple museums (the "sociability" component).

What we'd hope from this sort of metric is that academics use it on their CVs, and outright encourage gaming of the system because doing so would result in more digitization of specimens across many more institutions.

It also permits GBIF to expose answers to questions such as:

  1. Who is an expert collector or determiner of taxon X (eg http://collector.shorthouse.net/taxon/Cannabaceae)
  2. Who is an expert collector or determiner of taxon X in a particular region of the world)? (eg http://bit.ly/2xg7Wmb)
  3. Who has collected at a particular place in the world (+ when)? [and as a consequence, should be familiar with the local collecting regulations and how to apply for permits]
peterdesmet commented 7 years ago

Good ideas! There were also ideas about giving credit to reviewers of datasets (and maybe adding a role for that in the IPT...), which is something I'd particularly like to be counted. 😄

dshorthouse commented 7 years ago

...I strongly advise not using the word "role", but instead think of these as particular actions with a URI. Role is too heavy a term because it often devolves into what one's administrative position is while executing a particular action. I don't think we want to open that door unless absolutely necessary. However, we don't yet have a controlled vocabulary w/ URIs for actions and afaik none such exist. These should also be featured in whatever might eventually be an "Agent Actions" DwC extension. Terms I have to date are:

authored, borrowed, collected, conserved, contributed, created, curated, described, determined, illustrated, organized, participated, photographed, processed, reviewed

dschigel commented 7 years ago

I like verb based approach, actions matter more than positions.

peterdesmet commented 7 years ago

Agreed: I actually hate the roles in the IPT. 😄 I now add everyone (as authors). Verb based approach seems better indeed.

MortenHofft commented 6 years ago

Allow linking a user's ORCID account with a their GBIF.org account ORCIDs are now something that can be linked to. Currently however we do very little with it. But it is a first step. We use it to identify people on dataset pages (see https://github.com/gbif/portal16/issues/6#issuecomment-348112782)

This issue has gotten to be a more wide discussion about the use of ORCIDs, GBIFs role, dataset reviewing etc. Many of those ideas nicely link to other issues i see. They are also linked in https://github.com/gbif/portal16/issues/342. If you find that your idea isn't captured properly, then please create it in a separate issue.