recording of version 4 Hub demo

[jm.orc...@gmail.com]

Hello all,

By popular request, last week's Hub demo (17 May 2018) was recorded.

Version 4 of the Hub has now been released to production.

The demo covers the writing of:

affiliation (employment and education items)

funding items

works

peer-review

The link to listen to this 35 minute recording is https://drive.google.com/drive/folders/0B9xSYAcL09d4UmZCWHpVMFRORXc

Jill

[Jason Gush]

Some errata for the eagle-eyed who might've been puzzled on a watch through.

1/ How did "Generic Contributor" become "Generic Contributor2"?

We'd been seeing some intermittent problems with mailinator not getting the Hub's mail (the long suffering may recall this as a spanner in an earlier Hub showcase), as a consequence I used an email but didn't think through the consequences of using one that had already been through the Hub.

At 3:30 you see me inviting jag...@gmail.com as "Generic Contributor" and giving a, possibly unnecessary, discussion of how the Hub doesn't know the email behind any given ORCID record.

However through the OAuth dance and particularly when I'm returned to the Hub I'm now revealed as "Generic Contributor2" <jagu04orcidtest@mailinator".  

That piece of legerdemain is accomplished because as jag...@gmail.com was already linked in the test Hub with an sandbox ORCID iD, the Hub broke when attempting to create a new organisation relationship for a known user but with a different ORCID iD.

This rare, but not impossible, case caused some hiccups and we've cut out ~10 minutes of dealing with the error that ultimately end with instead inviting "Generic Contributor2".   

2/ Why when you had batched three rich affiliations to write was the result two vanilla affiliations? 

When I hit Contributor2's sandbox record a 8:40 instead of seeing the expected rich education and two rich employment items written from the file, instead there's only a single vanilla education and employment item.  

This was a consequence of a/ the Hub's legacy of self-service Tuakiri-mediated affiliations and b/ me being just a little too quick to check the user's record.  What is happening behind the scenes is when the affiliation file is activated, a user is created in the Hub with the staff and student flags set according to the "affiliation type" against their email address.  As soon as the user returns to the Hub with permission, the Hub acts on those flags as if the user had come through a Tuakiri-mediated login. When the next batch cycle happens, i.e., about a minute later, the Hub writes any items from the batch task with the behaviour being to overwrite any vanilla affiliations in the record before creating a new item.  That's why when we next visit the user's record at ~29:00, we can see the correct three affiliations were in fact written.

3/ What's this about contributor emails in your files. Are they a privacy risk or not.

At ~17:30 I go on a bit of a rant about being careful when putting emails in the data that will produce the ORCID message to be written, concerned that this will have the same visibility as the item.  I've been pleasantly suprised to discover the contributor emails written as part of a public item are themselves not public.  This accords with behaviour that was described for the v1.2 ORCID message but can be a little hard to find for v2.0/v2.1,  Contributor emails are a field that's always private, and are used to automatically add ORCID iD's whenever there's an ORCID iD associated with that email address.  As a consequence, they can improve the file you're writing and will not incidentally expose an otherwise private email address.    

[Alainna]

Hello everyone, 

I wish to clarify one item: 

3/ What's this about contributor emails in your files. Are they a privacy risk or not.
At ~17:30 I go on a bit of a rant about being careful when putting emails in the data that will produce the ORCID message to be written, concerned that this will have the same visibility as the item.  I've been pleasantly suprised to discover the contributor emails written as part of a public item are themselves not public.  This accords with behaviour that was described for the v1.2 ORCID message but can be a little hard to find for v2.0/v2.1,  Contributor emails are a field that's always private, and are used to automatically add ORCID iD's whenever there's an ORCID iD associated with that email address.  As a consequence, they can improve the file you're writing and will not incidentally expose an otherwise private email address.    

Contributor emails are stripped by the ORCID API, and they are not used to automatically add iDs whenever there's an iD associated with that email address.  For example, if the system writes a work with a contributor email field, the system will not be able to read that work and see the contributor email, because the system strips it rather than storing it. 

This is a feature that we had considered in the past, but later scrapped. We need to make this clearer, and will be updating the support page on contributors (https://support.orcid.org/knowledgebase/articles/895974 ) within the week to reflect, and aim to have this clearer in the next round of the ORCID XSD. 

Let me know if we can provide any further details. 

Warm regards, 

Alainna 

[Jason Gush]

Sincere thanks for the appearance and clarification Alainna, it will be nice to have ORCID's documentation accord with actual behaviour :).

In short, don't bother writing contributor emails, they'll only be discarded.  

The other part of the advice is "We suggest you add contributor's ORCID iDs only if you have authenticated the ORCID iD, or have collected the ORCID iD from a source which has authenticated it."  Which makes good sense.  Write away if you've collected the ORCID iD from your Elements or earlier with the Hub, but avoid iDs that may have been collected in the past via a text field.