ORCID Technical Advisory Group: relevant content on this site

ORCID – a taster of the API

Ben O'Steen — Tue, 13 Sep 2011 10:09:00 +0000

As the official draft API (googledoc) is both in flux and read-protected so that only those invited can see it, I am unable to give you a complete view of how things are shaping up.

However, I can relay a number of key points that everyone involved is concerned about:

It must have sensible (some may say RESTful) URLs
Human and machine-readable data is a must via
- Content-negotiation,
- and optionally, “suffix” negotiation (adding a “.xml” or “/xml”) for convenience.
OAuth is the current plan to share trust, allowing users the greatest control over what and who has access to their live profile data.
Profile creation/editing “By Proxy” is important, but shouldn’t take any control of the researcher’s basic profile information from the researcher themselves.

Some code!

Gudmundur A. Thorisson (University of Leicester and a member of the ORCID Technical Advisory Group) has put together an emulation of certain portions of the ORCID API, including some of the OAuth parts:

https://github.com/gthorisson/orcid-sandbox

Get the code from github and making sure you already have Rails/Ruby installed:

$ cd orcid-sandbox $ bundle install $ bundle exec rake db:migrate $ bundle exec rake db:setup $ rails server -p 3001 -d

(you may need “$ scripts/rails server -p 3001 -d)

Once you have the code up and running, you should be able to log in, make accounts and so on.

# OAuth-protected access to profile
[mummi@cambozola-2]curl  http://localhost:3001/profile -H "Accept: text/xml"  -I
HTTP/1.1 401 Unauthorized
X-Ua-Compatible: IE=Edge
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
Date: Thu, 08 Sep 2011 12:20:50 GMT
Server: WEBrick/1.3.1 (Ruby/1.8.7/2009-06-12)
X-Runtime: 0.087887
Content-Length: 0
Cache-Control: no-cache

# Public access to profile
[mummi@cambozola-2]curl  http://localhost:3001/cid/0723-1814-6587-5983 -H "Accept: text/xml" -I
HTTP/1.1 200 OK
X-Ua-Compatible: IE=Edge
Etag: "390c3560fce0064d65dd1373799f13d0"
Connection: Keep-Alive
Content-Type: application/xml; charset=utf-8
Date: Thu, 08 Sep 2011 12:20:49 GMT
Server: WEBrick/1.3.1 (Ruby/1.8.7/2009-06-12)
X-Runtime: 0.035443
Content-Length: 0
Cache-Control: max-age=0, private, must-revalidate

# Sample response (from Mike's XML examples)
[mummi@cambozola-2]curl  http://localhost:3001/cid/0723-1814-6587-5983 -H "Accept: text/xml"
<?xml version="1.0" encoding="UTF-8"?>
<orcid-bio-response xsi:schemaLocation="http://www.orcid.org/ns/orcid_bio_response_1.0.xsd"
    xmlns="http://www.orcid.org/ns/bio_response"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <response_version>1.0</response_version>
    <response_summary>
        <submission-date>09-10-2012 15:50:01</submission-date>
        <completion-date>09-10-2012 15:50:07</completion-date>
        <total-researchers-found>1</total-researchers-found>
        <!-- error message, if applicable -->
        <!-- unable to connect to ORCID, no matching researchers etc -->
        <error-desc>No researcher found for this institution.</error-desc>
    </response_summary>
    <profileList>
        <researcher-profile>
            <!--  ORCID elements will be present for every researcher found -->
            <orcid>XXXXXXXXXXXXXX</orcid>
            <!-- In short, researcher has claimed the profile if confirmed=true-->
            <confirmed>true</confirmed>
            <firstName>Josiah</firstName>
            <lastName>Carberry</lastName>
            <middleName>Stinkney</middleName>
            <other-names>
                <other-name>J. Carberry</other-name>
                <other-name>J. S. Carberry</other-name>
            </other-names>
            <researcher-urls>
                <url>http://library.brown.edu/about/hay/carberry.php</url>
                <url>http://en.wikipedia.org/wiki/Josiah_S._Carberry</url>
                <url>http://www.brown.edu/Administration/News_Bureau/Databases/Encyclopedia/search.php?serial=C0070</url>
            </researcher-urls>
            <institution>
                <name>Brown University</name>
                <address>
                        <addressLine1>38 Brown Street / Box 1920</addressLine1>
                        <city>Providence</city>
                        <state-or-province>Rhode Island</state-or-province>
                        <country>United States</country>
                        <postalcode>02912</postalcode>
                    </address>
                <departmentName>Psychoceramics</departmentName>
                <departmentName>High Energy Metaphysics</departmentName>
                <role>Researcher (Academic)</role>
                <start-date>1929</start-date>
            </institution>
            <bulk-institution>Brown University</bulk-institution>
            <sponsor>Brown University Library</sponsor>
            <affiliate-institution>
                <name> Wesleyan University</name>
                <address>
                        <addressLine1>Wesleyan University</addressLine1>
                        <addressLine2>Czech-Republic</addressLine2>
                        <city>Middletown</city>
                        <state-or-province>Connecticut</state-or-province>
                        <country>United States</country>
                        <postalcode>06459</postalcode>
                    </address>
                <departmentName>Bilocation</departmentName>
                <role>Researcher (Academic)</role>
                <start-date>1930</start-date>
            </affiliate-institution>
        </researcher-profile>
    </profileList>
</orcid-bio-response>

ORCID: some questions and answers

Ben O'Steen — Tue, 13 Sep 2011 09:38:00 +0000

The following is from an email exchange with Nicky Ferguson. These are my answers to the questions
he posed, and as such shouldn’t be considered the opinion of the ORCID project itself. They are the
answers I believe are correct, based on the meetings and discussions I have been part of on the
technical advisory group.

If any other member of the advisory group can correct any inaccuracies in the comments, I’d be
most appreciative.

> 1. ISNI, ORCID, VIAF etc … will they each or should they be a
> subset of UUID, in a world where there is a need for identifiers for
> all sorts of things from lab notebooks to datasets to institutions, as
> well as researchers?

ORCID and VIAF have both plumped for a ‘short’ number and a verbal
prefix (eg VIAF ID: 747462). It is intended (eventually) that the profile
corresponding to a given ORCID should be able to be found from
an ORCID site, and not necessarily the ORCID site.

You can currently construct URLs for both
where that ID number is used as a suffix to do a lookup on that
researcher/author/etc, with effort and consideration being made so
that the URL prefix will not change in the near future. It is naive to
think that any URL prefix that will never, ever change but keeping the
URL usable for as long as humanly possible is given serious thought.

With UUIDs, you will have to do something identical as there is no DNS
lookup *system* for them but a handful of individual sites that record
links as it suits them. Due to the UUID range being so large, the key
advantage of the scheme is that given a suitably random manner to
generate them, collisions between UUIDs made on separate systems are
incredibly rare. I’m not sure that anyone has recorded a collision
yet, (disregarding those due to poorly configured entropy pools on
virtual machines) This means that it is perfectly reasonable to
generate UUIDs for things completely independently of any central
organising body, and so makes them very cheap and long-lasting.

People do not like them however – subjectively – they do not like them
as part of visible URLs, they do not like them as identifiers to
wield, and they do not like identifiers for themselves that they
cannot remember by rote.

> 2. Who decides who is a researcher? In the UK some universities call
> all their members of staff ”teacher/researchers”, others make a clear
> distinction. What about schoolchildren who jointly author a paper?
> What about researchers in charities or industry who may never author a
> paper. What about peer-reviewers and research “users”?

ORCID currently is an “Allow then Deny Later” system. The main
‘ORCID’ site will be a self-signup website (with an initially limited
ability for proxies to sign up and create and amend profiles for others)
and the ‘researcher-iness’ of profiles will not be policed as there is no need to,
unless the profile claims something untruthful.

The core of the system is based on trust – if a person claims an institutional affiliation,
that will be marked as untrusted until that institution
verifies this. If an institution or research group doesn’t verify the
data, care is being taken that this is displayed as clearly as
possible.

There is no need to police people, only to police the claims they make
about themselves and the works they claim to have a hand in
publishing.

>
> 3. Even institutions which pride themselves on their research may
> only have 20-30% of their staff who are researchers, how do you sell a
> business case to them that they should alter their systems to
> accommodate an identifier for only a minority of the staff on their
> finance/HR/security systems?

Again, the ORCID system (and to an extent the VIAF system) is geared
to help the researcher – at a basic level, keeping a note of the ID
which a researcher has is all that is required to begin to benefit
from it. I think that due to the well understood pace at which change
occurs within the administrative systems of an institution, the first
meeting at which a business case for change might need to be presented
will occur many, many months after the researchers have adopted the
system for themselves as just part of the academic toolset. And if the
researchers do not find it useful, then it will disappear like so many
of the previous ID systems.

> 4. Similar question about researchers themselves – they have been
> disappointingly reluctant to deposit their papers in repositories and
> to use grant numbers in their publications, even when “mandated” – who
> will design the compelling interfaces which will encourage them to use
> ORCID … in the academic community we don’t have a great track record
> at designing compelling interfaces?

It is not an academic community that is designing the interface for
one – it has already been outsourced to a small team of local
designers and developers that Crossref have had good working
relationships with so there is hope there. The key will be
whether or not the system will save time for the researcher and make
certain tasks that they already do easier.

The API for the ORCID
service is very much the focus at the moment and certain use-cases
have been thought through, such as encouraging publishers and journal
submission processes to use the ID system, rather than get the
researcher (or PA/postgrad by proxy) to fill in all their information
again, as well as bootstrapping the ORCID database with information
already within existing bibliographic databases so that many profiles
need only be claimed and verified, rather than generated anew.

I do not mean to knock the institutional repository scene unduly
(having been an institutional repo person myself) but I have yet to see
more than a few repositories strive to make the researcher’s
lives easier and better. It is worth noting that those repositories
are the one’s that are thriving.

>
> 5. What role would a national registry need to play to map ORCID (or
> a.n.other identifier) with key information? and finally …

In short, include something semantically similar to ‘rdf:seeAlso’
within the database/triplestore/profile for the national registry’s
version of the same person. Many of the codebase changes occurring at
this time are so that the informational claims within other
whitelisted registries can be automatically shown and interpreted
within the ORCID store, moving towards a multi-trust system.

>
> 6. I understand that the idea is that the researchers themselves
> would control the registration and updating processes – but
> institutions, funders and government agencies will surely want to
> maintain their own registries/database using the ID … yes? Is the
> mechanism for change control of personal information thought out?
>

As mentioned above, the changes occurring and being implemented are to
effect a solid multi-trust control system, which will allow for the
kind of distributed profiles you mention to be accepted. However, the
systems have to provide data such that a machine can use it, and that
may be the sticking point for a few of these systems.

“The path to academic personal identifiers…

Ben O'Steen — Fri, 15 Jul 2011 11:43:00 +0000

… is littered with the wrecks and remains of many failed projects.”

The varied attempts to start, maintain or promote a single identifier scheme for academics, whether applied locally or internationally, can arguably be described as being a mix of successes and abject failures. I do not wish to dwell on what a failure is in this respect, but wish to simply define it as being a scheme that is not seen to be a necessary part of an academic’s ‘life’ – that of research, producing outputs, self-promotion, discovery of work and communicating with their collegues and the wider world.

It is far more instructive to look at the schemes that have worked in academia, and also at schemes which a broader section of the population have adopted. The first case that is most instructive is that of RePEc -

RePEc (Research Papers in Economics) is a collaborative effort of hundreds of volunteers in 74 countries to enhance the dissemination of research in economics. The heart of the project is a decentralized database of working papers, journal articles and software components. All RePEc material is freely available. Participation in RePEc as a provider only involves the cost of your time in preparing and maintaining metadata describing your publications.

Why is RePEc an important service to consider?

The service(s) were created and later shaped due to the needs of its community by volunteers – started by Thomas Krichel in 1993 (in every practical sense), the team has grown over the years.
It is a great example of a ‘bottom-up‘ (from the authors/peer group) service, not a ‘top-down’ service (institutional/publishing org driven.)
Being a product of the community, there is a great deal of trust in the services. The barrier to interaction with the site is low.
It has provided community-policed freedom for Economists to create and garden their own profiles for a number of years - http://authors.repec.org - the service now has over 25,000 author profiles, added primarily by the authors themselves and it is loosely labelled an Author ‘CV’ on the front page of the RePEc website.
- “The RePEc Author Service aims to link economists with their research output in the RePEc bibliographic database.” (more info)
It allows the community of economists to communicate their ideas and discover each other’s related research in a better manner than would be possible without it.
It allows the community to self-promote and compare one author’s output to another’s, based on their profiles and citations.

These are the key points that I think have contributed to making RePEc and its collection of services a success – it addresses the real needs of a community who trust it, who can freely add to and correct information about themselves and it allows them to communicate better, to self-promote and compare themselves to their peers and to discover further related research with greater ease.

Why are the publisher’s not fulfilling this role? One of the key pieces of research currency used by Economists is the Working paper – a paper that by its very nature is subject to revision, alteration and hopefully, amelioration. Unlike some other subjects, it is seen to be important for this ‘imperfect’ work to be scrutinised in a more public manner than other academic cultures might tolerate. A Work (used in the FRBR sense) whose contents will shift from the time of first publication, such that many versions of it may exist, are an anathema to conventional fire-and-forget publishing, where what is published may be retracted or given an errata, but its structure and findings are not expected to change.

Some may refer to this sort of output as ‘grey literature’ – I will give the most current (Prague Definition 2010) below:

“Grey literature stands for manifold document types produced on all levels of government, academics, business and industry in print and electronic formats that are protected by intellectual property rights, of sufficient quality to be collected and preserved by library holdings or institutional repositories, but not controlled by commercial publishers i.e., where publishing is not the primary activity of the producing body.”

Under this definition, working papers do fall into this category, although RePEc does not limit authors to listing only these forms of outputs. I consider the lack of a limit here to provide a greater sense of ownership to the community and another aspect that a successful service would likely emulate.

The fact that RePEc can be considered to be ‘owned’ by a community lends trust to its brand, but that is by no means the only way to garner the trust of a community. It’s actions and developments have won the trust of its community over the years. It is perfectly feasible for a publisher or private entity to produce a service which has similar success in this area. For example, consider the SSRN (Social Science Research Network).

SSRN

Like RePEc, the SSRN was created and shaped due to the needs of its community but in this case, the organisation behind it is privately owned.
It is focussed on the needs of authors and many of its services, if not all of them, are designed to be used by those within the research peer-group
- A somewhat subjective example is from their site’s navigation banner - http://www.ssrn.com/hen/index.html - there are options for ‘Top Papers’ and ‘Top Authors’ but nothing for ‘Top Institution’.
There is a great deal of trust in the services, as the SSRN spend a lot of effort validating, amending and checking the outputs of its services. While the ethereal nature of ‘download statistics’ may be familiar to many of those who run and administer websites, it is treated with great reverence by the users of the SSRN as the organisation expends great time and effort filtering and heavily examining downloads to render this insubstantial statistic less so. It is the appearance of solidity and formality with which the services are delivered that contributes towards the trust of the community.
It allows the community of economists to communicate their ideas and discover each other’s related research in a better manner than would be possible without it.
It allows the community to self-promote and compare one author’s output to another’s, based on their profiles and citations.
It also responds to criticism and errors within its service rapidly, as it is something that it takes pride in.

Many of the points here, mesh with those from RePEc, including the key (IMHO) ones of trust, comparison amongst peers, self-promotion and discovery. It has more limits than RePEc (contributions to the service are less free in the sense of ‘libre‘) but these same limits provide extra trust in the information provided by the service; an air that the information within is policed well and hard to falsify.

Let’s now consider a fundamentally similar service, similar in all of the above, but it is focus is not academic, and it is free only in the sense of it being ‘gratis’ and absolutely not ‘libre’

Facebook

Like RePEc, Facebook was created and shaped due to the needs of a community but it can be stated quite clearly that the community that it primarily serves are not those of its users. A quick glance at their current terms and conditions (or Rights and Responsibilities) can justify that assertion. Look at point 2, subsection 1 for a legal bombshell of a statement that should worry any user uploading personal videos or pictures to the site.
- As people tend to blank out when they are presented with T&C legalese, I’ll copy the pertinent section here: …. photos and videos (“IP content”), …: you grant us [opt-out, not opt-in] a non-exclusive, transferable, sub-licensable, royalty-free, worldwide license to use any IP content that you post on or in connection with Facebook (“IP License”)
It is focussed on the needs of users as it gained venture capitol based primarily on numbers of users – a ‘potential’ source of profit, rather than profitability in of itself. The organisation had a drive to gain and retain users, and had to do so by offering useful services.
There is ironically still a great deal of trust in the services they provide – in my opinion, this is because it is a mainstream service whose privacy transgressions and related reports which would erode that trust are never truly treated to mainstream media coverage.
- For example, tabloid newspapers make the UK population aware when the UK government or related bodies lose ‘CDs of valuable data‘ by running frontpage-level story campaigns over the course of days without any information on whether that data is being misused, but I have yet to find stories reported with similar intensity or visibility about the times Facebook openly attempted to sell personal data, finding articles from the Independent, Guardian and the Telegraph, individual articles that I doubt made the front pages of any of those.
- (As an aside, the irony of this Facebook group “We sue facebook if they sell our personal data!”(sic.) provides ample material to mull the issue of trust over: http://www.facebook.com/group.php?gid=52991492388 )
Even though the users’ should assess whether they should trust it, Facebook does allow the community of users to communicate and discover each other in a better manner than would be possible without it.
It allows the community to self-promote and socially compare based on their profiles.

Let’s now move swiftly on to consider an arguable failure in this realm – Thomson-Reuters’ ResearcherID:

ResearcherID

It was created primarily due to the needs of a publisher, who needed to keep track of researchers, who published which paper, co-authors and so on. This is actually a direct need of authors as well, but it is a hard notion to convey as each subject area seems to have its own coping mechanisms and acceptable losses when it comes to citations, metrics and the like.
It tried to focus on the needs of the users as well, but without the drive from a community that already existed, it was unclear what its focus is. This is perhaps a compromise between the publisher’s desire to make it as widely applicable as possible, and the individual desire to make it relevant to their own, personal community.
As this was a product by a publishing business, targeted at no specific community, the service inherited much of the same level of trust that the publishing business has within the wider academic community. That is to say, no-one trusted it to remain open and freely reusable without the threat of a hefty subscription introduced at some point later on. Thomson-Reuters own surveys confirmed that the primary reason ResearcherID was under-used was due to a lack of trust, both longterm and short term, in the service.
Without many profiles in the system, it never reached a tipping-point - it wasn’t a useful service to use in order to communicate and discover other researchers in your field of work.
Likewise, the ability to self-promote and compare was never tested, as there simply was not a great enough use of this service to do so.

The key failings of the ResearcherID service was that it did not target any community successfully, instead targeting all academic communities, and that it lacked its users’ trust in the service.

What does this mean for ORCID?

Although ORCID is technically a ‘child’ of the ResearcherID project, it does so with the knowledge of its parent failure and hopefully, as a project, will strive to correct this. While Thomson-Reuters play a part in the ORCID project, they are actively trying to relegate themselves to be no more influential in the proceedings and discussions that of any of the members of the boards administering and plotting out the direction for ORCID.

As a member of the Technical Advisory Group for ORCID, you can be sure that the aspects of trust and of community involvement will be at the forefront of any discussions I have with that group.