Mitchell O'Hara-Wild

### Why vitae?

::: {.float-left}
<figure class="m-0">
<img src="PeFoXDy.png"
style="  object-fit: cover; object-position: center;  height: 250px;  width: 250px; margin-right: 15px"
data-zgotmplz="" alt="vitae logo" />
<p>The process of maintaining a CV can be tedious. It’s a task I often
forget about - that is until someone requests it and I find that my
latest is woefully out of date. To make matters worse, these
professional updates often need repeating across variety of sites (such
as ORCID and LinkedIn).</p>
<p>Having seen several CVs put together into an R Markdown document
(including my own, featuring a few quick and dirty hacks to make it
work), the need for an R package was obvious. With many attendees of the
<a href="https://ozunconf18.ropensci.org/">2018 rOpenSci OzUnconf</a>
having converted their CV to use R Markdown, the conference was the
perfect space to develop and formalise the ideas that many of us have
worked on independently in the past. Progress on the <code>vitae</code>
package progressed much faster than expected, in fact it took less time
to produce a functional prototype than it did to tidy the data for the
<a href="https://github.com/ropenscilabs/ozbabynames/">ozbabynames</a>
package! The <code>vitae</code> project was primarily worked on by
myself (<a
href="https://twitter.com/mitchoharawild">@mitchoharawild</a>) and Rob
Hyndman (<a href="https://twitter.com/robjhyndman">@robjhyndman</a>),
with ideas/discussion from <a
href="https://github.com/ropensci/ozunconf18/issues/24">many other
participants</a>.</p>
</figure>
:::

The `vitae` package leverages the dynamic nature of R Markdown to
quickly produce and update CV entries from a variety of data sources.
With use of the included templates, examples and helper functions, it
should be possible to produce a reasonable looking and data-driven CV in
less than an hour.

Based on the twitter community's response to the package announcement,
CV maintenance is just as unenjoyable for others as it is for me!
Hopefully this package makes it a little bit easier.

> Introducing the
> [\#rstats](https://twitter.com/hashtag/rstats?src=hash&ref_src=twsrc%5Etfw)
> vitae package, developed by myself and
> [@robjhyndman](https://twitter.com/robjhyndman?ref_src=twsrc%5Etfw) at
> [\#ozunconf18](https://twitter.com/hashtag/ozunconf18?src=hash&ref_src=twsrc%5Etfw)
> 📦🥳. The package provides Résumé/CV templates for use with R
> Markdown, and functions to add entries using data (great for
> integration with other packages!)  
> 🔗<https://t.co/yeDiLsTGeV>
> [pic.twitter.com/ndR9fmUknk](https://t.co/ndR9fmUknk)
>
> --- Mitchell O\'Hara-Wild (@mitchoharawild) [November 23,
> 2018](https://twitter.com/mitchoharawild/status/1065851259888914432?ref_src=twsrc%5Etfw)

### Keeping it simple

When developing an R package, it is easy to focus on features that are
specific to your needs. Without concern for the interface, adding an
abundance of specific features can make the package less useful overall.
The `vitae` package is an excellent example of simpler is better, and
less is more. `vitae` helps users to create a CV populated with data
from ORCID, Google Scholar, local spreadsheets, online databases, CRAN,
and endless others. However the `vitae` package does not directly
provide functionality for any of these features, instead it relies on a
common data format (a data-like object, such as a `data.frame` or
`tibble`).

This allows `vitae` to integrate seamlessly with other R packages to
pull in data for the CV.

- Want to get publications from ORCID? Try the
  [rorcid](https://github.com/ropensci/rorcid) package!
- How about Google Scholar? Heard of
  [scholar](https://github.com/jkeirstead/scholar)?
- Have a few CRAN packages? Include them with
  [pkgsearch](https://github.com/metacran/pkgsearch/).
- Employment history from LinkedIn? Well, I can't find a working package
  for that yet. Someone reading this, please get on that!

Another example of simplicity being best is the interface used to add CV
entries. Initially, we hastily started work on a function that produced
entries for education. We created an `education` function, with some
context specific arguments such as `degree`, `institution` and `awards`.
However when it came to adding functions for professional experiences
and related fields, we found that the resulting output was essentially
the same. These CV entries could be simplified into a more generic
`detailed_entries` function, that accepts more general arguments of
`what`, `when`, `with`, `where` and `why`. The usage of these functions
is now separated from a specific purpose, giving flexibility to use
these functions for any CV section. Similar can be said for entries
relating to awards and achievements, where the `brief_entries` function
can be used to include less detailed sections.

As an added bonus, simpler design decisions makes the package easier to
learn, and easier to develop!

### vitae for R

The `vitae` package is now available on CRAN, making it easy to install
with:

``` {tabindex="0"}
install.packages("vitae")
```

In version `0.1.0`, the `vitae` package provides four commonly used
LaTeX CV templates that have been modified for use with R Markdown. With
the `vitae` package installed, CV templates can be accessed from the
RStudio R Markdown template selector:

![RStudio template selector](Pib5DDC.png)

Like other R Markdown documents, the file is split into two sections:
the YAML header, and the main body.

``` {tabindex="0"}
---name: Mitchell O'Hara-Wilddate: "`r format(Sys.time(), '%B, %Y')`"qualifications: BCom(Hons), BScaddress: Melbourne, Australiaprofilepic: pic.jpgemail: mail@mitchelloharawild.comwww: mitchelloharawild.comgithub: mitchelloharawildlinkedin: mitchelloharawildtwitter: mitchoharawildheadcolor: 414141output: vitae::awesomecv---```rknitr::opts_chunk$set(echo = FALSE, warning = FALSE, message = FALSE)library(vitae)```# Professional SummaryThis is a good opportunity to introduce yourself professionally and summarisewhy your skills are well suited to the job you are applying for!
```

The YAML header contains general entries that are common across many
templates, such as your name, address and social media profiles. You can
also see that the output is set to `vitae::awesomecv`, which indicates
that this CV uses the [Awesome
CV](https://github.com/posquit0/Awesome-CV) template.

The main body of the document contains standard R Markdown code, which
is being used to set some document options, load the `vitae` package,
and add a professional summary to the CV.

Let's add to the main body with some education history. These details
are available on [ORCID](https://orcid.org) with my ID of
[0000-0001-6729-7695](https://orcid.org/0000-0001-6729-7695), which can
be dynamically accessed using the
[rorcid](https://github.com/ropensci/rorcid) package.

``` {tabindex="0"}
library(vitae)edu <- do.call("rbind",  rorcid::orcid_educations("0000-0001-6729-7695")$`0000-0001-6729-7695`$`affiliation-group`$summaries)edu %>%  detailed_entries(    what = `education-summary.role-title`,    when = glue::glue("{`education-summary.start-date.year.value`} - {`education-summary.end-date.year.value`}"),    with = `education-summary.organization.name`,    where = `education-summary.organization.address.city`  )
```

The CV entries functions from `vitae` using a similar syntax to
`dplyr::mutate`, where data manipulation can occur within the
`detailed_entries` function. This is used above to combine the starting
and ending year of my educations using the
[glue](https://github.com/tidyverse/glue) package. Also note that I have
not specified anything for `why` here. Any of the arguments can be
excluded, which will result in the corresponding CV field being left
empty.

Knitting the document will generate the CV with up to date data directly
from ORCID.

![Resulting CV output](Roj4jTZ.png)

To learn more about how `vitae` can be used to automate your CV this
year, the [*Introduction to vitae*
vignette](https://pkg.mitchelloharawild.com/vitae/articles/vitae.html)
is a great place to begin.

### Contributing to vitae

Résumé/CV templates are abundantly available in many varieties of themes
and layouts. The `vitae` package provides a few of the more popular
templates that are suitable for most resumes. The included templates are
far from comprehensive - your favourite template may not be included, or
perhaps you have created your own template.

The `vitae` package has been developed in a way that makes extending it
to support new templates simple! If you use a template that you'd like
to convert for usage with `vitae`, the package includes a vignette for
[*Creating vignette
templates*](https://pkg.mitchelloharawild.com/vitae/articles/extending.html).

You can then make your converted template available for anyone to use
via a pull request to the project's GitHub repository:
<https://github.com/ropenscilabs/vitae>


Why vitae? The vitae package leverages the dynamic nature of R Markdown to quickly produce and update CV entries from a variety of data sources. With use of the included templates, examples and helper functions, it should be possible to produce a reasonable looking and data-driven CV in less than an hour.

vitae: Dynamic CVs with R Markdown

Cameron Neylon

Following on from my [post last
month](http://cameronneylon.net/blog/a-specialist-openid-service-to-provide-unique-researcher-ids/)
about using [OpenID](http://openid.net) as a way of identifying
individual researchers,Â  [Chris
Rusbridge](http://digitalcuration.blogspot.com/) made the sensible
request that when conversations go spreading themselves around the web
it would be good if they could be summarised and aggregated back
together. Here I am going to make an attempt to do that -- but I won't
claim that this is a completely unbiased account. I will try to point to
as much of the conversation as possible but if I miss things out or
misprepresent something please correct me in the comments or the [usual
places](http://friendfeed.com/cameronneylon).

The majority of the conversation around my post occured on friendfeed,
at [the item
here](http://friendfeed.com/e/c1fd00ec-15f9-d894-4ea9-4ffeaac5ae28/A-specialist-OpenID-service-to-provide-unique/),
but also see commentary around Jan Aert's
[post](http://saaientist.blogspot.com/2009/01/who-o-o-are-you-who-who-who-who.html)
(and [friendfeed
item](http://friendfeed.com/e/cf559daf-90c4-4613-9fe7-b27ca3dbf1a7/Who-o-o-are-you-Who-who-Who-who/))
and Bjoern Bremb's [summary
post](http://bjoern.brembs.net/news.php?item.495.5). Other commentary
included posts from [Andy
Powell](http://efoundations.typepad.com/efoundations/2009/01/openids-researchers-and-delegation.html)
(Eduserv), [Chris
Leonard](http://blogs.openaccesscentral.com/blogs/pmcblog/entry/some_thoughts_on_unique_author)
(PhysMathCentral),
[Euan](http://www.ghastlyfop.com/blog/2009/01/specialist-openid-service-to-provide.html),
[Amanda
Hill](http://namesproject.wordpress.com/2009/01/22/a-flurry-of-author-id-discussions/)
of the [Names project](http://names.mimas.ac.uk/), and [Paul
Walk](http://blog.paulwalk.net/2009/01/22/openid-and-name-authority/)
(UKOLN). There was also a [related
article](http://www.timeshighereducation.co.uk/story.asp?sectioncode=26&storycode=405184&c=1)
in Times Higher Education discussing the
[article](http://www.ploscompbiol.org/article/info%3Adoi%2F10.1371%2Fjournal.pcbi.1000247)
(Bourne and Fink) in PLoS Comp Biol that kicked a lot of this off \[Ed
-- Duncan Hull also pointed out there is a parallel discussion about the
ethics of IDs that I haven't kept up with -- see the [commentary at the
PLoS Comp Biol
paper](http://www.ploscompbiol.org/annotation/getCommentary.action?target=info%3Adoi%2F10.1371%2Fjournal.pcbi.1000247)
for examples\]. [David
Bradley](http://www.sciencebase.com/science-blog/) also pointed out to
me a [post he
wrote](http://www.sciencebase.com/science-blog/paperid-an-open-source-identifier-for-research-papers.html)
some time ago which touches on some of the same issues although from a
different angle. [Pierre](http://plindenbaum.blogspot.com) set up [a
page on
OpenWetWare](http://openwetware.org/wiki/Biogang:Discussion/UniqueAuthorID)
to aggregate material to, and [Martin
Fenner](http://network.nature.com/people/mfenner/blog/) has a collected
set of [bookmarks with the tag authorid at
Connotea](http://www.connotea.org/tag/authorid).

The first point which seems to be one of broad agreement is that there
is a clear need for some form of unique identifier for researchers. This
is not necessarily as obvious as it might seem. With many of these
proposals there is significant push back from communities who don't see
any point in the effort involved. I haven't seen any evidence of that
with this discussion which leads me to believe that there is broad
support for the idea from researchers, informaticians, publishers,
funders, and research managers. There is also strong agreement that any
system that works will have to be credible and trustworthy to
researchers as well as other users, and have a solid and sustainable
business model. Many technically minded people pointed out that building
something was easy -- getting people to sign up to use it was the hard
bit.

Equally, and here I am reading between the lines somewhat, any workable
system would have to be well designed and easy to use for researchers.
There was much backwards and forwards about how "RDF is too hard", "you
can't expect people to generate FOAF" and "OpenID has too many technical
problems for widespread uptake". Equally people thinking about what the
back end would have to look like to even stand a chance of providing an
integrated system that would work felt that FOAF, RDF, OAuth, and OpenID
would have to provide a big part of the gubbins. The message for me was
that the way the user interface(s) is presented have to be got right.
There are small models of aspects of this that show that easy interfaces
can be built to capture sophisticated data, but getting it right at
scale will be a big challenge.

Where there is less agreement is on the details, both technical and
organisational of how best to go about creating a useful set of unique
identifiers. There was some to-and-fro as to whether CrossRef was the
right organisation to manage such a system. Partly this turned on
concern over centralised versus distributed systems and partly over
issues of scope and trust. Nonetheless the majority view appeared to be
that CrossRef would be right place to start and CrossRef do seem to have
plans in this direction (from Geoffry Bilder see [this Friendfeed
item](http://friendfeed.com/e/c1fd00ec-15f9-d894-4ea9-4ffeaac5ae28/A-specialist-OpenID-service-to-provide-unique/)).

There was also a lot of discussion around identity *tokens* versus
*authorisation*. Overall it seemed that the view was that these can be
productively kept separate. One of the things that appealed to me in the
first instance was that OpenIDs could be used as either tokens (just a
unique code that is used as an identifier) as well as a login mechanism.
The machinery is already in place to make that work. Nonetheless it was
generally accepted, I think, that the first important step is an
identifier. Login mechansisms are not necessarily required, or even
wanted, at the moment.

The discussion as to whether OpenID is a good mechanism seemed in the
end to go around in circles. Many people brought up technical problems
they had with getting OpenIDs to work, and there are ongoing problems
both with the underlying services that support and build on the standard
as well as with the quality of some of the services that provide
OpenIDs. This was at the core of my original proposal to build a
specialist provider, that had an interface, and functionality that
worked for researchers. As [Bjoern pointed
out](http://bjoern.brembs.net/news.php?item.495.5), I should of course
be applying my own [five criteria for successful web
services](http://www.slideshare.net/CameronNeylon/social-networks-for-scientists)
(got to the last slide) to this proposal. Key questions: 1) can it offer
something compelling? Well no, not unless someone, somewhere requires
you to have this thing 2) can you pre-populate? Well yes, and maybe that
is the key...(see later). In the end, as with the concern over other
"informatics-jock" terms and approaches, the important thing is that all
of the technical side is invisible to end users.

Another important discussion, that again, didn't really come to a
conclusion, was who would pass out these identifiers? And when? Here
there seemed to be two different perspectives. Those who wanted the
identifiers to be completely separated from institutional associations,
at least at first order. Others seemed concerned that access to
identifiers be controlled via institutions. I definitely belong in the
first camp. I would argue that you just give them to everyone who
requests them. The problem then comes with duplication, what if someone
accidentally (or deliberately) ends up with two or more identities. At
one level I don't see that it matters to anyone except to the person
concerned (I'd certainly be trying to avoid having my publication record
cut in half). But at the very least you would need to have a good
interface for merging records when it was required. My personal belief
is that it is more important to allow people to contribute than to
protect the ground. I know others disagree and that somewhere we will
need to find a middle path.

One thing that was helpful was the fact that we seemed to do a pretty
good job of getting various projects in this space aggregated together
(and possibly more aware of each other). Among these is
[ResearcherID](http://researcherid.com), a commercial offering that has
been running for a while now, the [Names
project](http://names.mimas.ac.uk/), a collaboration of
[Mimas](http://mimas.ac.uk) and the [British Library](http://www.bl.uk)
funded by JISC, [ClaimID](http://claimid.com/) is an OpenID provider
that some people use that provides some of the flexible "home page"
functionality (see [Maxine Clark's](http://claimid.com/maxine) for
instance) that drove my original ideas,
[PublicationsList.org](http://publicationslist.org) provides an online
homepage but does what ClaimID doesn't, providing a
[PubMed](http://pubmed.org) search that makes it easier (as long as your
papers are in PubMed) to populate that home page with your papers (but
not easier to include datasets, blogs, or wikis -- see
[here](http://publicationslist.org/cameronneylon) for my attempts to
include a blog post on my page). There are probably a number of others,
feel free to point out what I've missed!

So finally where does this leave us? With a clear need for something to
be done, with a few organisations identified as the best ones to take it
forward, and with a lot of discussion required about the background
technicalities required. If you're still reading this far down the page
then you're obviously someone who cares about this. So I'll give my
thoughts, feel free to disagree!

1.  **We need an identity token, not an authorisation mechanism.**
    Authorisation can get easily broken and is technically hard to
    implement across a wide range of legacy platforms. If it is possible
    to build in the option for authorisation in the future then that is
    great but it is not the current priority.
2.  **The backend gubbins will probably be distributed RDF.** There is
    identity information all over the place which needs to be aggregated
    together. This isn't likely to change so a centralised database, to
    my mind, will not be able to cope. RDF is built to deal with these
    kinds of problems and also allows multiple potential identity tokens
    to be pulled together to say they represent one person.
3.  **This means that user interfaces will be crucial.** The simpler the
    better but the backend, with words like FOAF and RDF needs to be
    effectively invisible to the user. Very simple interfaces asking
    "are you the person who wrote this paper" are going to win, complex
    signup procedures are not.
4.  **Publishers and funders will have to lead.** The end view of what
    is being discussed here is very like a personal home page for
    researchers. But instead of being a home page on a server it is a
    dynamic document pulled together from stuff all over the web. But
    researchers are not going to be interested for the most part in
    having another home page that they have to look after. Publishers in
    particular understand the value (and will get most value out of in
    the short term) unique identifiers so with the most to gain and the
    most direct interest they are best placed to lead, probably through
    organisations like CrossRef that aggregate things of interest across
    the industry. Funders will come along as they see the benefits of
    monitoring research outputs, and forward looking ones will probably
    come along straight away, others will lag behind. The main point is
    that pre-populating and then letting researchers come along and
    prune and correct is going to be more productive than waiting for
    ten millions researchers to sign up to a new service.
5.  **The really big question is whether there is value in doing this
    specially for researchers**. This is not a problem unique to
    research and one in which a variety of messy and disparate solutions
    are starting to arise. Maybe the best option is to sit back and wait
    to see what happens. I often say that in most cases generic services
    are a better bet than specially built ones for researchers because
    the community size isn't there and there simply isn't a sufficient
    need for added functionality. My feeling is that for identity that
    there is a special need, and that if we capture the whole research
    community that it will be big enough to support a viable service.
    There is a specific need for following and aggregating the work of
    people that I don't think is general, and is different to the
    authentication issues involved in finance. So I think in this case
    it is worth building specialist services.

The best hope I think lies in individual publishers starting to
disambiguate authors across their existing corpus. Many have already put
a lot of effort into this. In turn, perhaps through CrossRef, it should
be possible to agree an arbitrary identifier for each individual author.
If this is exposed as a service it is then possible to start linking the
information up. People can and will and the services will start to grow
around that. Once this exists then some of the ideas around recognising
referees and other efforts will start to flow.


Following on from my post last month about using OpenID as a way of identifying individual researchers,Â  Chris Rusbridge made the sensible request that when conversations go spreading themselves around the web it would be good if they could be summarised and aggregated back together. Here I am going to make an attempt to do that – but I won’t claim that this is a completely unbiased account.

Contributor IDs &#8211; an attempt to aggregate and integrate

Following on fromÂ [Science Online
09](http://www.scienceonline09.com/index.php/wiki/)Â and particularly
discussions on [Impact Factors and researcher
incentives](http://www.scienceonline09.com/index.php/wiki/Reputation_authority_and_incentives/)Â (also
onÂ [Friendfeed](http://friendfeed.com/e/ff6e8043-e771-45ec-9ff6-9bddff241017/Bjorn-Brembs-and-Peter-Binfield-How-to-get-rid-of/)Â and
some video available atÂ [Mogulus](http://mogulus.com/cameron_neylon)
via video on demand) as well as theÂ [article in PloS Computational
Biology](http://www.ploscompbiol.org/article/info:doi/10.1371/journal.pcbi.1000247)Â by
Phil Bourne and Lynn Fink the issue of unique researcher identifiers has
really emerged as absolutely central to making traditional publication
work better, effectively building a real data web that works, and making
it possible to aggregate the full list of how people contribute to the
community automatically.

Good citation practice lies at the core of good science. The value of
research data is not so much in the data itself but its context, its
connection with other data and ideas. How then is it that we have no way
of citing a person? We need a single, unique way, of identifying
researchers. This will help traditional publishers and the existing
ecosystem of services by making it possible to uniquely identify authors
and referees. It will make it easier for researchers to be clear about
who they are and what they have done. And finally it is a critical step
in making it possible to automatically track all the contributions that
people make. We've all seen CVs where people say they have refereed for
Nature or the NIH or served on this or that panel. We can talk about
micro credits but until there are validated ways of pulling that
information and linking it to an identity that follows the person, not
who they work for, we won't make much progress.

On the other hand most of us do not want to be locked into one system,
particularly if it is controlled by one commercialÂ organization.
Â Thomson ISI'sÂ [ResearcherID](http://www.researcherid.com/)Â is
positioned as a solution to this problem, but I for one am not happy
with being tied into using one particular service, regardless of who
runs it.

In the PLoS Comp Biol article Bourne and Fink argue that one solution to
this isÂ [OpenID](http://openid.net/). OpenID isn't a service, it is a
standard. This means that an identity can be hosted by a range of
services and people can choose between them based on the service
provided, personal philosophy, or any other reason. The central idea is
that you have a single identity which you can use to sign on to a wide
range of sites. In principle you sign into your OpenID and then you
never see another login screen. In practice you often end up typing in
your ID but at least it reduces the pain in setting up new accounts. It
also provides in most cases a "home page". If you go
toÂ <http://cameron.neylon.myopenid.com>Â you will see a (pretty
limited) page with some basic information.

OpenID is becoming more popular with a wide range of webservices
providing it as a login option
includingÂ [Dopplr](http://dopplr.com),Â [Blogger](http://blogger.com),
and research sites includingÂ [MyExperiment](http://myexperiment.org).
Enabling OpenID is also on the list for a wide range of other services,
although not always high up the priority list. As a starting point it
could be very easy for researchers with an OpenID simply to add it to
their address when publishing papers, thus providing a unique, and
easily trackable identifier that is carried through the journal,
abstracting services, and the whole ecosystem services built around
them.

There are two major problems with OpenID. The first is that it is poorly
supported by big players such as Google and Yahoo. Google and Yahoo will
let you use your account with them as an OpenID but they don't accept
other OpenID providers. More importantly,Â [people just don't seem to
get OpenID](http://electronicmuseum.org.uk/2008/07/16/openid-fail/). It
seems unnatural for some reason for a person's identity marker to be a
URL rather than a number, a name, or an email address. Compounded with
the limited options provided by OpenID service providers this makes the
practical use of such identifiers for researchers very much a minority
activity.

So what about building an OpenID service specifically for researchers?
Imagine a setup screen that asks sensible questions about where you work
and what field you are in. Imagine that on the second screen, having
done a search through literature databases it presents you with a list
of publications to check through, remove any mistakes, allow you to add
any that have been missed. And then imagine that the default homepage
format is similar to an academic CV.

Problem 1: People already have multiple IDs and sometimes multiple
OpenIDs. So we make at least part of the back end file format, and much
of what is exposed on the
homepageÂ [FOAF](http://www.foaf-project.org/), making it possible to at
least assert that you are the same person as, say
cameronneylon@yahoo.com.

Problem 2: Aren't we just locking people into a specific service again?
Well no, if people don't want to use it they can use any OpenID
provider, even set one up themselves. It is an open standard.

Problem 3: What is there to make people sign up? This is the tough one
really. It falls into two parts. Firstly, for those of us who already
have OpenIDs or other accounts on other systems, isn't this just (yet)
another "me too" service. So, in accordance with the five rules I have
proposed for successful researcher web services, there has to be a
compelling case for using it.

For me the answer to this comes in part from the question. One of the
things that comes up again and again as a complaint from researchers is
the need to re-format their CV (seeÂ [Schleyer et al,
2008](http://www.jmir.org/2008/3/e24/)Â for a study of this). Remember
that the aim here is to automaticallyÂ aggregate most of the information
you would put in a CV. Papers should be (relatively) easy, grants might
be possible. Because we are doing this for researchersÂ we know what the
main categories are and what they look like. That is we have
semantically structured data.

Ok so great I can re-format my CV easier and I don't need to worry about
whether it is up to date with all my papers but what about all these
other sites where I need to put the same information? For this we need
to provide functionality that lets all of this be carried easily to
other services. Simple embed functionality like that you see
onÂ [YouTube](http://youtube.com), and most other good file hosting
services, which generates a little fragment of code that can easily be
put in place on other services (obviously this requires other services
to allow that -- which could be a problem in some cases). But imagine
the relief if all the poor people who try to manage university
department websites could just throw in some embed codes to
automatically keep their staff pages up to date? Anyone seeing a
business model here yet?

But for this to work the real problem to be solved is the vast majority
of researchers for whom this concept is totally alien. How do we get
them to be bothered to sign up for this thing which apparently solves a
problem they don't have? The best approach would be if journals and
grant awarding bodies used OpenIDs as identifiers. This would be a dream
result but doesn't seem likely. It would require significant work on
changing many existing systems and frankly what is in it for them? Well
one answer is that it would provide a mechanism for journals and grant
bodies toÂ publiclyÂ acknowledgeÂ the people who referee for them. An
authenticated RSS feed from each journal or funder could be parsed and
displayed on each researcher's home page. The feed would expose a record
of how many grants or papers that each person has reviewed (probably
with some delay to prevent people linking that to the publication of
specific papers). Of course such a feed could be used for lot of other
interesting things as well, but none of them will work without a unique
person identifier.

I don't think this is compelling enough in itself, for the moment, but a
simpler answer is what was proposed above -- just encouraging people to
include an OpenID as part of their address. Researchers will bend over
backwards to make people happy if theyÂ believeÂ those people have an
impact on their chances of being published or getting a grant. A little
thing could provide a lot of impetus and that might bring into play the
kind of effects that could result from acknowledgement and ultimately
make the case that shifting to OpenID as the login system is worth the
effort. This would particularly the case for funders who really want to
be able to aggregate information about the people they fund effectively.

There are many details to think about here. Can I use my own domain name
(yes, re-directs should be possible). Will people who use another
service be at a disadvantage (probably, otherwise any business model
won't really work). Â Is there a business model that holds water (I
think there is but the devil is in the details). Should it be non-profit
or for profit or run by a respected body (I would argue that for-profit
is possible and should be pursued to make sure the service keeps
improving -- but then we're back with a commercial provider).

There are many good questions that need to be thought through but I
think the principle of this could work, and if such an approach is to be
successful it needs to get off the ground soon and fast.

*Note:Â I am aware that a number of people are working behind the scenes
on components of this and on similar ideas. Some of what is written
above is derived from private conversations with these people and as
soon as I know that their work has gone public I will add references and
citations as appropriate at the bottom of this post.Â *


Following on fromÂ Science Online 09Â and particularly discussions on Impact Factors and researcher incentivesÂ (also onÂ FriendfeedÂ and some video available atÂ Mogulus via video on demand) as well as theÂ article in PloS Computational BiologyÂ by Phil Bourne and Lynn Fink the issue of unique researcher identifiers has really emerged as absolutely central to making traditional publication work better,

Rogue Scholar Beiträge

vitae: Dynamic CVs with R Markdown

Contributor IDs – an attempt to aggregate and integrate

A specialist OpenID service to provide unique researcher IDs?