ORCID API: relevant content on this site

Draft ORCID API is now open for viewing!

Ben O'Steen — Thu, 29 Sep 2011 13:57:00 +0000

The API draft is now available for public viewing and covers:

Levels of privacy and other contextual terminology.
Public query API by way of illustrative HTTP query dialogues.
Protected Data query via OAuth.
- OAuth Workflow is illustrated in some depth

This is a pre-release of the API; it is nearly there, but it would be foolish to assume that the API will not change if any difficulties arise or if a better way is agreed upon.

Google Doc version of API:

https://docs.google.com/document/d/1hEHwKEpQ3wH-qmgmQAgdxdcEIG1jmv6e2-FgdEfW89I/edit?hl=en_GB

As the document is ‘view-only’, you cannot comment on it directly. Please post queries and observations to the ORCID Researcher Google group.

NB Posting a comment here will not directly reach the other members of the ORCID board.

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.

ORCID update – ResearcherID system and a call for API

Ben O'Steen — Mon, 18 Jul 2011 08:53:00 +0000

A quick update:

ORCID service:
- Geoff Bilder (Crossref) is leading the developmental work on the ORCID system
- The first instance of this system will be based on the code produced for the Thomson-Reuters ResearcherID system which has the following characteristics:
  - Java 1.6 (current version is 1.6.021)
  - iBatis 2.3.0.677 (current version is 3.0.2)
  - Struts2
  - Tomcat 5.5.x (current version is 7.0.2)
  - MySQL 5.0.19 (current 5.1.50)
  - Standard XML RPC
  - Quartz Scheduler
ORCID development phases have not changed much since the beginning:
- Phase 1 – create an author ‘self-claim’ system, based on the ResearcherID code but with changes made to accommodate desired APIs and phase 2 integration work.
- Phase 2 – create a multi-trust system – where trusted bodies (institutions) can publish information on ORCIDs they know about and validate and verify the data held on those ORCIDs in other systems.

One key component of this has been the desire to ‘nail-down’ the desired API for access to ORCID profile information as early as possible. The discussions are not occurring on a publically-accessible mailing list yet although I and others have put forward this as something that is highly desirable if not essential.

In the meantime, I would welcome any API ideas, desires or queries that I can take to the ORCID TAG.