Hi all,
in dspace-cris we have actually implemented two integrations with ORCID,
for both we have benefit of great work already available in the communty:
1) ORCID authentication: the user is able to login using his ORCID
account and gain privileges to edit/manage her DSpace-CRIS researcher
profile if automatically created using the ORCID lookup in submission
(see point 2) - this functionality is based on the code found on the
Dryad project
2) ORCID registry lookup during the submission: when a new item is
created the contributor.author (the metadata is configurable) can be
lookup in the local Researchers directory (the DSpace-CRIS researcher
list maybe keep in sync with your HR staff directory) and with the
public ORCID registry. If a new researcher is pick from the ORCID
registry a basic profile for her is created in DSpace-CRIS when the
publication is installed. This functionality is based on the code
available for DSpace XMLUI 5
We are finalizing a new integration that will allow the researchers to
export their publications, projects and biography from DSpace-CRIS to
ORCID. This functionality will be available shortly, before the end of
this month. Next we will work on reverse side, i.e. the ability to
import publications from the ORCID profile in DSpace-CRIS.
You can see some screen here:
slides 59+
http://www.slideshare.net/DuraSpace/32415-slides-new-possibilities-developments-with-dspace-and-orcid?qid=d52315d4-7de1-4b62-a03b-645c059c6fa4&v=default&b=&from_search=4
slides 30+
http://www.slideshare.net/dtpalmer/once-future-2
Hope this help,
Andrea
Il 17/06/2015 17.38, Hilton Gibson ha scritto:
Thanks Mark,
The application of ORCID is one hook that definitely gets the
attention of top management here.
Good luck with pursuing further implementation! I look forward to it.
Regards
hg
*Hilton Gibson*
Ubuntu Linux Systems Administrator
Stellenbosch University Library
http://staff.lib.sun.ac.za/~hgibson/docs/cv/cv.html
<http://staff.lib.sun.ac.za/%7Ehgibson/docs/cv/cv.html>
On 17 June 2015 at 16:40, Mark H. Wood <mw...@iupui.edu
<mailto:mw...@iupui.edu>> wrote:
On Wed, Jun 17, 2015 at 03:56:35PM +0200, Hilton Gibson wrote:
> Hi Mark
>
> Thanks for the reply.
>
> Now I am bamboozled.
> The directive to apply ORCID came from our Vice-Rector Research.
> He would like to have reports extracted from our repository
about campus
> researcher output.
> He would also like the same campus researchers to submit
primarily to the
> repository any current research works.
This sounds to me like a very common desire, and one that DSpace
should support.
> Now what role does a campus researcher (author/advisor) in this
case have
> on DSpace, which I am sure is a common case with most academic
research
> repositories?
> user, Eperson or ORCID?
The user (a real-world person) is represented in DSpace by an EPerson
object. Today the EPerson exists only to hold credentials for
authenticating identity at logon, and to support subscription to
update emails when new content arrives in a subscribed Collection.
Authors (and other contributors to an Item) are (poorly) represented
by strings in the Item metadata, and not connected with EPersons.
ORCIDs are today not provided for at all in DSpace, but there is much
interest in rectifying that.
To address your question: if a researcher wishes to submit works for
inclusion in the repository, or to subscribe to new-accession notices,
or both, then the researcher must create a user account (an EPerson)
in your DSpace. If a researcher wishes his deposits known by his
ORCID, stock DSpace has no place for that information, but you can
define a metadata field for ORCIDs and extend the submission forms as
needed. DSpace lets you make a place to keep ORCIDs, but released
versions go no further.
I took a quick look and, while I am definitely not a metadata expert,
it seems to me that neither QDC nor DCTerms defines a field for
*author* identifiers, so a hypothetical identifier.ORCID field should
be defined elsewhere. There may be a namespace which already defines
such a field, which DSpace (or your instance) could adopt and, if so,
that is probably the best approach.
There may be things you can do with DSpace's authority control support
that will make it easier to ensure the quality of these metadata and
ease their (correct) entry. I haven't yet looked at authority control
at all, so can't say more.
There's another aspect to all this: now that EPerson has metadata
support, it would be easy to just extend the 'eperson' metadata
namespace with eperson.identifier.ORCID. Making use of this field
would require substantially more work, though. It would need
additions to the user profile UI pages, and some logic to offer the
option to pre-fill a submission field from the user's profile (and
from other user profiles, if several local users are authors of a
single Item). Still more work would be needed to support lookup of
(or by!) ORCIDs assigned to non-local authors.
> It seems we created more ambiguity/complexity with ORCID, rather
than
> simplifying and removing author ambiguity.
To take advantage of the growing interest in ORCID to simplify and
disambiguate is work yet to be done.
I want to mention that, if your repository is like many others, the
author information may be...messy. There's no mandatory control on
author name strings, and people tend to write the same person's name
in different ways at different times. I suspect that a rigorous
examination and cleanup of author names will be a necessary step in
implementing unique identifiers for authors at every site that chooses
to do such an implementation. It is something that can be begun now
and which will be beneficial now. You may also have sources of
authority that you can begin using now to prevent acceptance of any
*more* names that will have to be cleaned up.
I'm considering how to build tools which can help in doing this
cleanup.
I would like to exhort all early adopters of ORCID in DSpace to talk
early and often about their work, so that we can develop common
conventions for basic things like how ORCIDs are stored, for works and
for authors.
Meanwhile, I think @mire has been working on ORCID support. I also
believe that Dryad is pursuing ORCID integration. There should be
little trouble in assembling an interest group to make these things
happen.
--
Mark H. Wood
Lead Technology Analyst
University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu <http://www.ulib.iupui.edu>
------------------------------------------------------------------------------
_______________________________________________
Dspace-general mailing list
Dspace-general@lists.sourceforge.net
<mailto:Dspace-general@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/dspace-general
------------------------------------------------------------------------------
_______________________________________________
Dspace-general mailing list
Dspace-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-general
--
Andrea Bollini
Soluzioni per la Ricerca Istituzionale
Cineca
Via dei Tizii, 6
00185 Roma, Italy
tel. +39 06 44 486 087 - mob. +39 348 82 77 525
http://www.cineca.it
------------------------------------------------------------------------------
_______________________________________________
Dspace-general mailing list
Dspace-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-general
