ORCID in a nutshell (current strategy):
- ORCID is a registry of profiles for people involved in research – a profile can be created by the person themselves (self-registry) or by what is termed a Trusted Partner, such as a University or Publisher.
- The people using the system decide who is and is not a researcher, not the system itself.
- A self-registered profile, for “John Smith” for example, can state that it is the same ‘John Smith’ in a profile created by a Trusted Partner and vice-versa. (akin to the semantic web’s “sameAs”)
- Profiles which are linked like this in both directions (researcher to trusted partner and back again) are trusted more than a profile without such verifying claims.
- Profile data can have varying levels of privacy: fields can be made public (anyone can see the data), protected (only those that a researcher authorises can see the data) or private (only the researcher can see it). It is expected that when profiles are linked in the above manner, the researcher’s privacy settings will cover the data submitted by the other parties too (but this mechanism is by no means confirmed or implemented yet.)
- A researcher will be able to authorise other parties to access their protected data using a scheme called OAuth. This is a simple process for the user, and requires little to be remembered on their part. An example Twitter OAuth authorisation can be seen in the first 30 seconds of http://www.youtube.com/watch?v=yhrbmUbF0IE – blink and you’ll miss it.
- The main selling point for the system at this time is that it is attempting to save a researcher’s time spent filling in publisher and funder forms for article and bid submissions by having the pertinent details automatically drawn from their ORCID profile (once the publisher/funder’s system has been authorised via the aforementioned OAuth)
- The later selling point, when a tipping point of signed up users is reached, is expected to be for the universities, funders and publishers. The ability to draw up an REF return or to see which publications have been made as a result of which project funding is an expected feature.
- It is expected that usable ORCIDs will be assigned from Q2 2012
Money:
(much of the following is taken from Ed Pentz’s powerpoint presentation: http://orcid.org/sites/default/files/bwgsep11.pptx WARNING: new Powerpoint required to view.)
- Current projections suggest that the ORCID system will require operating costs of around $2.1 million a year for the next few years.
- The organisation has approximately 6 months left of funding capital left to work with and is on a funding drive at this moment.
- It is looking to follow in other CrossRef project’s footsteps by asking publishers and the like for loans – it projects that it will reach the break-even point in 5 to 6 years.
- No researcher is going to pay for access to the service to create and use a profile and its ID.
- The Trusted Partners are expected to pay – what the value-added services might be for these parties are still in discussion.
- The 5 to 6 years break-even point is based on what seems to be a conservative uptake by these parties – however, the system still needs to be sold to them! The following figures are extremely preliminary (tiering is based on number of people/size of organisation):
[Ben: Just repeating – these figures are pre- pre- pre-alpha and subject to change at the drop of a hat. In fact, I’d bet that they already have]
Things yet to be dealt with (my opinion):
- Whilst no-one has stated a problem with ORCID’s software being Open Source, it has yet to be released as an Open Source Project. The code base that they are working on, IP belonging to Thomson-Reuters, has been scrubbed of any Thomson-Reuters specific code and they (T-R) have agree that it is suitable to be placed under an OSI licence. It just hasn’t been done yet.
- The ORCID software release was planned to be just a deployable .war file – without source code. This obviously is not acceptable if the O in ORCID is to remain to stand for Open (in spirit if not pedantically.)
- How privacy is to be handled with multiple parties asserting various pieces of information is not yet decided or agreed upon. This type of functionality is quite a deal-breaker for many academics.
- How malicious or false claims are going to be dealt with, at a policy level, has not been clear. What level of recourse will an individual have against false claims made (mistakenly) by a trusted partner and vice-versa? Researchers making multiple accounts? Profiles made by bored teenagers for ‘fun’?
- There is still a short-term gap of investment funding required of $2.75 million dollars – it remains to be seen what occurs if the code is still not made open source by the end of six months if no other sources of capital is found.
- Whilst other identifier schemes can be easily included within an ORCID profile, it is not clear if – at an organisational level – if they would be happy if another organisation used the ORCID code to set up another ‘ORCID’ system. Due to the timeline of when ORCID might go live (Q2 2012), the urgency with which other organisations require them might force other systems to be put into place much earlier. For example, as Andrew Treloar jokingly quoted on the ORCID outreach event’s live chat: “If you guys have an ORC-ID, then I want an ELF-ID” – could the next ORCID-free six months force some funders to take matters into their own hands?
- ORCID exit-strategies – both for the organisation and for individual profiles. What happens when the money runs out? What happens to the data? If someone wanted ‘out’, is there a way for them to remove all their data and take it with them? (in a similar vein to http://www.dataliberation.org/)
- The authorisation system relies on OAuth (which is no bad thing) but I don’t think that the time required for existing organisation to adopt this has been adequately estimated. ORCIDs use on other systems to save time and effort filling in forms is a crucial part of the ‘sales pitch’ to academics – this hasn’t gotten the visible focus I would’ve expected.
Posted in: ORCID
Simon Kerridge
September 22, 2011
Great Summary!
Thanks Ben
Geoffrey Bilder
September 23, 2011
Nice summary.
A few clarifications on “things to be dealt with”:
“The code base that they are working on, IP belonging to Thomson-Reuters, has been scrubbed of any Thomson-Reuters specific code”.
Pedantic clarification- ORCID is not scrubbing the project of TR code. That would be rather defeating the point of having been donated the TR code 🙂 We are scrubbing it of branding and stubbing out dependencies on other backend TR systems (e.g. authentication/authorisation) so that we can replace them.
“The ORCID software release was planned to be just a deployable .war file – without source code.”
We said that an *interim* release of a mocked-API might just be a WAR file. In our principles (http://orcid.org/principles), we have been clear that the final ORCID system code will be released under an OSI license. In fact- we also announced at the CERN event that it would be an MIT license.
“Whilst other identifier schemes can be easily included within an ORCID profile, it is not clear if – at an organisational level – if they would be happy if another organisation used the ORCID code to set up another ‘ORCID’ system.”
So first, if we release the code under an OSI license, it doesn’t matter what ORCID thinks of what people do with it- the license allows anybody to do just about whatever they please with it. Having said that, If another organisation can take the code and launch a system with the backing of the relevant stakeholders, we would do nothing but collectively doff our hats to them, heave a sigh of relief, and go back to our real jobs. The difficulty in this project has not been getting or developing code- it has been (as with most things) in creating an organisation that can run and sustain the service.
“ORCID exit-strategies – both for the organisation and for individual profiles. What happens when the money runs out? What happens to the data?”
First- I’d rephrase it to “what happens *if* then money runs out?” But we’ve tried to be clear on this point. ORCID has, in its principles, made a commitment to release all researcher-claimed profiles (subject to researcher privacy preferences) under a CC0 waver. We made this commitment specifically to serve as an ultimate guarantee that the service and data could be preserved and resurrected by other parties if ORCID itself failed.
“If someone wanted ‘out’, is there a way for them to remove all their data and take it with them?”.
Again, in the principles, we have tried to be clear that the researcher controls their claimed profile. The only thing they can’t hide and/or delete is the identifier itself as that would rather undermine the idea of a persistent identifier…. Also- as the claimed records will be released under a CC0 waver, they can, of course, be copied and moved to other systems.
“OAuth2 […] I don’t think that the time required for existing organisation to adopt this has been adequately estimated. ORCIDs use on other systems to save time and effort filling in forms is a crucial part of the ‘sales pitch’ to academics – this hasn’t gotten the visible focus I would’ve expected.”.
At the CERN meeting we tried to emphasise that our development priority was to provide working API code ASAP (e.g. By end of Nov. 2011) so that third parties can start this kind of integration while the rest of the ORCID phase 1 system is completed (taget date- end of March 2012). We scheduled the work this way precisely because it has been highlighted to us that third-party integration is critical to ORCID’s success. Now- it is possible that this is *still* inadequate time, but just because we have completed the phase 1 coding doesn’t mean we have to launch then. If we need more time for third parties to integrate- then we might choose to delay launch until we are confident that integration has taken place.
Hope this provides clarification on at least some of the outstanding issues.
–G