DSpace-CRIS technical level introduction

DSpace-CRIS @ TUHH
A technical level introduction to the DSpace-CRIS concepts
and the ORCID integration

• The DSpace-CRIS data model: additional entities,
interactions with the DSpace data model (authority
framework), enhanced metadata, inverse relations
• ORCID integration & technical details: available
features & use cases (authentication, authorization,
profile claiming, profile synchronization push &
pull, registry lookup), configuration, API-KEY, use of
the sandbox, metadata mapping
• 4Science support: service desk portal
Summary

The DSpace-CRIS data model
Additional entities, interactions with the DSpace data model
(authority framework), enhanced metadata, inverse relations,
metrics, statistics

www.cineca.itAn integrated view of the
research

www.cineca.it
DSpace & DSpace-CRIS
DSpace ITEM
DSpace-CRIS:
ResearcherProfile
DSpace-CRIS:
OrgUnit
DSpace-CRIS:
Project
DSpace ITEM
DSpace-CRIS:
ResearchObject (DynamicObject)
Authority
Authority
Authority
Authority
Pointer
Pointer
Pointer
Pointer

• The set of managed entities:
• ResearchOutputs: Publications, Datasets (DSpace ITEM
with “a profile”)
• Researchers, Organisations, Project (1st class citizen
DSpace-CRIS)
• Any other entity: DSpace-CRIS ResearcherObject with “a
profile”
• The relations between them:
• Semantics
• multiplicity
What define a data model?

• Communities and collections are entities useful to
aggregate DSpace Items by
• A common profile (metadata)
• Provenience and responsibility (license, workflow,
curation)
• They own the items, are often related to an
organisation by the mean that the community or
collection is maintained by it but are different
conceptually things!
What about communities & collections?

DSpace-CRIS doesn’t bind you to a predefined
datamodel. It provides support out-of-box for three
additional entities (researchers, organisations and
projects) but you are not required to use all of them.
 you can define additional entities
 you can define your own relations between
entities including the ones that you have defined
A flexible data model

DSpace-CRIS technical level introduction

• It can be performed via UI and exported to xls
• It can be imported from XLS files
Data model configuration
Default configuration
Documentation

• Flat metadata model
• All information are stored as string at the database
level with minimal support (and validation) for data
entry in the UI
DSpace-CRIS improves the metadata at the item level
providing:
- Additional input types for data entry (number, year
and regex validation)
- Partial support for nested metadata
Weakness of the DSpace Metadata model

New values for the <input-type> element
• year
• year_noinprint shows a In press label stored as 9999
 The configuration properties submission.date.min-year
(default 1950) and submission.date.new-years (default 0,
additive from the current year) are used to define the range
• number allows input of only digit values. The form element
use the html5 type number and js to assist the user in the
input. Validation is done on the server side using regex
(default d+)
<validation> can be used to validate the input in onebox,
textarea, number against any regex
Additional input types for data entry

A metadata value in dspace has a
• Text-value: the textual value of the
metadata
• Authority: an identifier from an authority
file that uniquely identify the linked
authority term
• Confidence: the level of confidence of the
authority value (-1 unset, 600 certain)
• Place: the order 1-based of the value
• Lang: the iso language code of the
text-value
Authority framework
Only for
configured
metadata
Mostly ignored

• It is activated in the dspace.cfg
• Defining the plugin that talk with each authority file
• Defining which metadata (ie. dc.contributor.author uses
which plugin/authority file)
• It is the bridge between DSpace and DSpace-CRIS
objects (DSpace-CRIS is the authority file)
See
https://wiki.duraspace.org/display/DSPACECRIS/Inte
gration+with+the+basic+DSpace+data+model
Authority framework - 2

Example: a publication has been fund by two
different grants and we want to store in the
publication metadata the projects names, funders
and grant numbers. This is the scenario from which
dspace-cris is started
Nested metadata: lack of data modelling
Project title#1
Funder: European Commision…
GrantNo: xxxx
Project title#2
Funder: Mellon Foundation…
GrantNo: yyyy
You need a linked entity
DSpace-CRIS: project
authority = pj00001
authority = pj00002

Example: a publication have two authors and we
want to store their ORCIDs for retrieval purpose and
affiliations to show the publication in the list of both
departments
Nested metadata: lack of data modelling
Researcher#1
ORCID: 0000-0000-0000-0001
Affiliation: xxxxx
Researcher#2
ORCID: 0000-0000-0000-0002
Affiliation: yyyyy
You need a linked entity
DSpace-CRIS: researcher profile
authority = rp00001
authority = rp00002

Example: a publication have two authors and we
want to store their affiliations to record the
attribution expressed by the authors in the
publication header
Nested metadata: a real need – solved in
DSpace-CRIS 5.7
Researcher #1
Researcher #2
Affiliation: xxxxx
Affiliation: yyyyy
You need to store such information because it is not enough to know
the affiliation of a research at a given time to reconstruct. You don’t
know the exact date to use, also when you know it you can have
multiple choices
dc.contributor.affiliation
dc.contributor.author
place = 1
place = 2

It can be use also to couple several metadata
DSpace-CRIS 5.7 (2)
Project title #1
Project title #2
Funder: xxxxx
Funder: yyyyy
Nice! we don’t need linked entities anymore!?
NO. This solution doesn’t provide data normalization (same
project could have different description in different items), you
are not able to list all the project with a specific funder, etc.
dc.relation.projectfunder
dc.relation.project
place = 1
place = 2
dc.relation.grantno
grantno: 123
grantno: ABC

It is configured in the input-form, a new <parent>
element has been introduced. See
https://wiki.duraspace.org/display/DSPACECRIS/Nested+
metadata+in+DSpace+items
Known limitations:
1. Children metadata supports only the “onetext” input
(limitation to be removed soon)
2. There is not yet support for “coupled” visualization of
these metadata in the item splash page
3. Nested metadata cannot be repeatable but you can
create an arbitrary number of metadata to store
reasonable prelimited-multiple values (affiliation1,
affiliation2, affiliation3)
DSpace-CRIS 5.7 (3)

• We don’t embrace a specific metadata schema / format
as many standards are equally valid for different
communities we prefer to support easy crosswalk to all
the needed formats
• Data are stored in typed columns: number, date, string,
reference to other entities – ready for further
characterization of the value (semantics, date-range
validity), not currently implemented in the UI
• Nesting is managed natively with the support for
children objects. No limitation about repeatable nested
metadata
• Data structure is keep in the database instead than in
an external configuration file (input-form) to enforce
data integrity
DSpace-CRIS entities: metadata aka
properties

• Each DSpace-CRIS entity instance has a status flag
• Public: the details page is visible to anyone and it will be
linked where appropriate. The record is included in
public search results
• Private: only administrators can access the details page.
The entity is indexed only for use as authority entry
• Each property value has an edit mode:
• Editable
• Visibility flag only
• Only Administrators
• Read only
• A property become visible when included in a
public visible tab/box
DSpace-CRIS visibility and security
This only apply to non-admin users
allowed to edit DSpace-CRIS entities.
Out-of-box only RP supports editing by
non-admin, the RP owner

• Visibility of a tab or box can be restricted to
System administrators
Only RP owner
Admins and RP Owner
 specific users and groups related to the entity instance
• To restrict the visibility of a box or tab to specific
groups or users one or more properties must be
indicated containing the users and/or groups that
have access to the protected box / tab
• In this way it is possible to make visible a box of a
department only to the department director and
secretary or a project box only to the investigators
DSpace-CRIS visibility and security - 2

• DSpace-CRIS objects can be exposed to the DSpace
functionalities as normal DSpace objects with metadata
• Each property is exposed as a metadata with
schema = default value depending on the CRIS entity type
element = shortname of the property
• The value is the string representation of the property value.
For pointer (link to other entities)
• <schema>.<element> has the “display value” of the pointer as value
and the CRIS ID as authority
• <schema>.<element>.<qualifier> is automatically mapped to the
property with shortname = qualifier in the linked dspace-cris entity
• For nested objects (or combo) the qualifier gives access to
the specific property in the nested
• The last two “expansion” mechanisms don’t work for *
wildcard metadata access (crisrp.*.* or crisrp.dept.*)
Addressing dspace-cris entities in the
dspace “way”

The schema used are as follow
• ResearcherPage  crisrp
• Project  crispj
• Organisation  crisou
• ResearcherObject  cris<shortname> (crisjournal, crisevent,
etc.)
Some examples
• crisrp.fullName is the name of a researcher
• crisrp.dept contains the name of the department as value and
the ID of the CRIS OrgUnit as authority
• crisrp.dept.description is the description of the department
where the researcher is affiliated
• crisrp.affiliation.affiliationorgunit are the organisation listed
in the nested affiliation objects (with value and authority)
Addressing dspace-cris entities in the
dspace “way” - 2

• The Item object has been wrapped to add support
for virtual metadata
• The wrapper is defined in the cris-metadata-
enhancers.xml spring file
• Using AOP (intercept calls to getMetadata*
methods) it adds virtual metadata calculated using
logic from a
• CrisItemEnhancer: to expose as crisitem.<alias>
information from linked CRIS entities
• ItemEnhancer: to expose as item.<alias> information
generated from an item metadata
(placeholder.placeholder.placeholder allows the
generation of values regardless of existent metadata)
Exposing dspace-cris info to dspace items

Examples include
• use researcher metadata (project, journal, etc.) to
index linked publications
• expose researcher (project, journal, etc.) metadata
over OAI-PMH as item metadata
 crisitem.author.dept exposes the mainAffiliation
of the linked researcher profiles
 crisitem.project.grantno exposes the
projectNumber recorded in the linked project
(dc.relation)
Exposing dspace-cris info to dspace items

• Information from nested objects or linked cris
object are available on cris object only when
directly accessed using the getMetadata (no *
wildcard support)
• In many cases it is needed to access all the
“metadata” of a CRIS object (search, browse, etc.)
• A CrisEnhancher infrastructure is available for that.
It is recommended to use where possible the same
syntax of the natural traversing to expose the
information i.e. crisrp.dept.description etc.
Expose nested cris informations

• DSpace-CRIS can use the SOLR indexes to reverse a
relation
• Publications are linked to the researcher profile 
• But you can also list the publications under a
specific researcher profile 
• Relations are defined in the configuration spring file
cris-relationpreference.xml and characterized by
• A name
• The target entity (a CRIS Entity or a DSpace Item)
• The SOLR query with {0}, {1} placeholders to be replaced
with the CRIS-ID or the uuid of the source CRIS instance
Navigate the inverse relations

• Inverse relations can be
• Visualized
• Used to show aggregated statistics (discussed later)
• To be visualized, relations are embedded in
components (see cris-components.xml)
• Components are pluggable JAVA logic to be
executed at the time that a CRIS object is visualized
• They typically provides information (i.e. act a
Controller in the MVC pattern) to be visualized by a
custom JSP fragment (V). Each box can declare to
use a custom JSP
Navigate the inverse relations - 2

• Out-of-box are available components
implementations to allow configurable rendering of
inverse relation for each entities (dspace items or
dspace-cris entities)
• It is possible
• to configure which facets show in the component
• to apply filters to the relation
• It is possible to enable a clustering using custom
categories defined by facet queries
• It is aware of the preference expressed for the
relation
Clustering of related objects

• An object can be hidden in the list of linked objects
from a CRIS object because it is not “so relevant”
(for instance old publications, old versions or
different edition of the same publication in a
researcher profile)
• An object can be promoted to be part of a selected
(ordered) list of linked objects for a specific CRIS
object (primary publications of a researcher)
• An object could be wrongly linked to a CRIS object
so it should be unlinked by the CRIS object owner
• This actions can be performed using the Manage
relation preference tool
Hidden, unlinked and selected objects

• Support to collect metrics information about all the
entities in the system (both dspace objects than
dspace-cris objects). Data are stored in the database
(cris_metrics), other than the ref to the object
• metrictype: A short alias of the metric (scopuscitation, etc.)
• metriccount: The recorded value for the metric (double)
• remark: custom details (JSON String)
• startdate – enddate: observed period
• timestamp[created|modified] Data acquisition time/update
• Scripts to
• automatically capture bibliometrics from Scopus, Web of
Science and PubMed Central
• freeze statistics data from the SOLR core as usage metrics
• calculate derivative metrics (percentile, growth, cumulative)
DSpace-CRIS Metrics framework

5
Rank as percentile compared to
the other objects in the
repository
Grown tracked locally
Metric value (citation number)
linked to an external detail page
when provided

org.dspace.app.cris.metrics.[scopus|wos].script.
ScriptRetrieveCitation
• Get citation count for DSpace items that have an
identifier suitable for the provider ( DOI, PMID, EID, UT)
• Cumulate citation and number of items as metric on the
researcher profile
• Work on a configurable number of items, skipping
recent processed items and sleeping between requests
to meet API usage limit
• Can save the provider identifier to the item metadata
• PMC Script has an additional structure to store fine-
grain information about citing item including
mining of cross-reference between DSpace items
DSpace-CRIS Metrics framework - 2

• The current value of each metric (last = true) is
exposed as dynamic field crismetrics_<metrictype>
in the SOLR search document for sorting and
projection
• SOLR server accesses the DSpace database using the
credentials configured in the database.properties file
• Data are cached in memory by SOLR and updated
when a new searcher is opened (something write
to the disk), new metrics are collected from the
built-in scripts or a refresh metric cache is manually
trigged
${solr.url}/search/select?q=*:*&fl=clearcache-crismetrics

Internal and derivative metrics are build by
configurable providers defined as spring beans
• usage data from the statistics core (view &
download)
• variation of a metric over predefined period
(_period1, _period2)
• percentile positioning of the object compared to
the other objects in the repository by the metric
value
• many other computed metrics can be configured
reading from an item or cris object metadata

• The absolute link to the detailed statistic page is
stored in the remark of the metric. Pay attention if
you clone existent database
• Last week (_period1) and last month (_period2) are
calculated from the recorded metrics. Need manual
fix if you withdrawn/fix usage data between run
• The cris_metric table grows unlimited a
purge/archive strategy for old/unused data should
be setup

• Served by Spring two configurable controller (one
for DSpace objects one for DSpace-CRIS objects)
• For each entity it is possible to define the statistics
components to show (tabs)
• For instance a collection show
• View of the collection
• View of items in the collection
• Download of items in the collection (view of item’s bitstreams)
• Upload of item in the collection
• For DSpace-CRIS entities the default is to use the same
components used for the visualization
Statistics: DSpace-CRIS enhancements

• It uses SOLR Join queries to aggregate statistics of
related objects including bitstream view under a
specific item.
• There are some consequences:
• Use of SOLR shards is not possible as you will need to join
over distributed SOLR cores
• It is unnecessary to rebuild statistics indexes, a very very
expensive operation, if the repository structure change
(merge of collections, change of item metadata, etc.)
• An additional field is stored in the SOLR statistics document
with the unique id of the corresponding object in the search
core (the uuid or the resourcetype-resourceid)
Please note that DSpace-CRIS statistics data remain
compatible with a standard DSpace as they only include
an additional field
Statistics: DSpace-CRIS enhancements

Repository Sections “home page”

Relations between items
publication(s)
back link

• Authority to provide lookup over (a subset of) the
repository items
• Consumer to automatically add the inverse relation
to the target item once the linking item is published
(approved)
Relations between items

• 4Science has released, free and open source, an
integration with CKAN, the world's leading open-
source data management platform
• Using an extendible viewer framework you can now
offer data discovery, exploration, preview, sampling
and visualization from your DSpace-CRIS repository
• CKAN makes open webservices for tabular data
available: https://ckan.org/
• DSpace-CRIS & DSpace-CKAN add-on:
https://github.com/4Science/dspace-ckan
DSpace-CRIS use cases: Research Data

DSpace-CRIS use cases: Research Data

CKAN Add-On Module: preview tabular & geospatial data
Paginated and filterable

Graph visualization

Interactive map visualization

CKAN Integration Add-On: architecture
backend
proxing
• Open access
• Embargo
• Restricted
Can be integrated
with LTP strategy
Open Source, get it from GitHub!

Image files (medical, astrophysics, cultural
heritage: digitalized manuscript, rare books,
etc.) need to be consulted online, discussed
and commented / annotated
IIIF protocols and formats allow you to meet
these requirements in a standard and
understandable way (for both humans and
machine)
DSpace-CRIS use cases: beyond publications

• An astrophysics image can be over 5GB!
• High-quality scanned books have images
typically over 100MB for each page
• Medical images can also be very large
• The structure of image sequences are
complex and relevant (page sequences,
evolution of phenomena in medical images,
etc.)
DSpace-CRIS use cases: Images

The same requirements apply to audio and
video content
- Streaming
- Internal structure
- Annotation / commenting / transcript
Adopt an open standard: the MPEG-DASH
format allows adaptive streaming over simple
html client with full support for multiple
tracks, ToC, subtitles
DSpace-CRIS use cases: beyond publications

• You can add viewers simply implementing the JSPViewer
interface and exposing them as spring beans in your DSpace
Spring context
• You can mark a bitstream to be used with one or more
viewers using the metadata bitstream.viewer.provider. The
metadata value must match the viewer bean id
• You can avoid direct download of the bitstream adding the
value nodownload to the previous metadata
• The UI as been extended to provide edit capabilities for
metadata on all the DSpace objects. You can edit bundle and
bitstream using the button provided in the administrative
edit-item or you can build your own link following the syntax
below
${dspace.url}/tools/edit-dso?resource_id=xxx&resource_type=yyy
(use the uuid parameter in DSpace-CRIS 6.x)
DSpace-CRIS Viewers framework

The IIIF Image Viewer, Document Viewer,
OCR & Transcription, Video/Audio Streaming
are add-on modules presently distributed by
4Science with an innovative business model:
contribute to make them open source soon!
http://www.4science.it/en/dspace-add-ons/
DSpace-CRIS add-ons

• Versioning was broken in DSpace-CRIS 5.7, it is now
solved in the maintenance and master branches
• The UnityFVG project has a customization that expose
(RP, PJ, OU, Journal) over OAI-PMH in the CERIF XML
format. We have recently take over the project, we are
reviewing the implementation to make it suitable for
general inclusion in DSpace-CRIS
• DSpace-CRIS provides an additional strategy to mint
DOI for items that meet specific conditions in a
controlled, semi-automatic process. It is possible to
specify set of items and associate to each set a different
algorithm to generate the DOI and the metadata to
register (using dedicated schemas for theses, datasets,
etc). It works using a queue processed by batch scripts
(the CrossRef and Datacite agencies are supported)
DSpace-CRIS: other functionalities

• System prompts potential duplicate during
submission and workflow
Duplication alert

• Two items are flagged as potential matches if they
share at least one signature (this is largely inspired by
the SOLR official de-duplication approach)
• A signature is a value that summarize the information in the
item using a pluggable transformation (case insensitive, ascii
transcription, identifier normalisation, etc)
• Feedback on potential matches (reject or duplicate
flag) are stored in the database table dedup_reject
• Signatures and matched groups are stored on a
dedicated SOLR core that is maintained using
DedupEventConsumer
• Use DedupClient to rebuild the index or build it the first time
if you are migrating from a previous version
Deduplication technical details

• Scripts are provided to query periodically the
following bibliographic databases for publication of
the institution
• PubMed Europe
• Scopus
• Web of Science
• Records are mapped to the DSpace internal
metadata schema and queue in the DBMS Border
tables to be imported
• Deduplication can be used to merge records found
in multiple sources or previously entered
Scanning of external databases

CORE Recommender for Items [NEW]
config/modules/core-aggregator.cfg

• Signposting is an approach to make the scholarly
web more friendly to machines, exposing relations
as Typed Links in HTTP Link headers
• The following patterns are supported in DSpace-
CRIS:
• Author: links to authors ORCID or VIAF records
• Identifier: link to ORCID from DSpace-CRIS researcher
pages, link to the Handle/DOI from the landing page or
fulltext (PDF, etc.)
• Publication Boundary: links to the actual fulltext from
the landing page
• See https://wiki.duraspace.org/display/DSPACECRIS/Signposting
New features in DSpace-CRIS 5.7 & 6

ORCID integration &
technical details
Available features & use cases (authentication, authorization,
profile claiming, profile synchronization push & pull, registry
lookup); configuration, API-KEY, use of the sandbox, metadata
mapping

Login via ORCID iD
also for external
co-authors (if liked)
Lookup the registry
Transfer information from the repository
to the ORCID Registry and viceversa
Connect local profile with the ORCID registry
Create new record - facilitate the creation
of new ORCID records for researchers

ORCiD login
By default a new Researcher Profile can be
immediately created capturing information
from ORCID

The following options are available
• ORCID Login embedded in the “Password Login”
screen
• ORCID Login offered as an independent
authentication method
• ORCID Login disabled (only connect to ORCID and
claim existent researchers profiles)
config/modules/authentication-oauth.cfg#L85
ORCID login

Import publications from ORCID (NEW)

Import publications from ORCID (NEW)
Full integration with ORCiD,
pull and push APIs
for all entities:
Profiles
Publications
Projects

ORCiD Registry Lookup
A local profile is created at the end of the process

• An ORCIDAuthority plugin allows to search the local
Researchers Profiles and the ORCID Registry
• Results from the two registries are concatenated
without deduplication; use the local entry or the ORCID
entry at the end will lead to the same association
• Entry selected from the ORCID Registry get a temporary
authority key
will be generated::orcid::<orcid-id>
• A DSpace consumer watches for deposited items
transforming all the temporary keys in an actual CRIS
Object. The item will be updated to refer to the real
CRIS-ID
ORCIDAuthority

will be generated::<ext-auth>::<ext-id>
• The consumer provides a general infrastructure to
create CRIS objects as part of an item submission that
go beyond the simple ORCID use case
• Depending on the involved external authority a Filler
implementation is invoked and the generated CRIS
object or its metrics are filled with one or more
information extracted from other item metadata or
dynamically retrieved from the authority or any other
custom logic
• ORCIDImportFiller is responsible to PULL biography
data from ORCID when a new ResearcherProfile is
created
Pull information from ORCID

Connect existent profiles to ORCiD
From his Researcher Page, via the specific
“tab” ORCiD preferences it is possible to check
and connect the local profile to ORCiD

Connect existent profiles to ORCiD

ORCiD Synchronization preferences

• The system can automatically synchronize changes
from DSpace-CRIS to ORCID (batch mode) or left the
user to manually synchronize one or more changes to
ORCID
• The batch mode requires the execution of a CRON Script
• User that opt for manual synch will receive an email inviting
them to login in the system to check and synchronize
• Sometime a PUT operation is required, this happen
when an item is deleted or withdrawn from the system
or when the user change his preference. This is due to a
limitation of the ORCID v1 API that doesn’t allow to
delete a single publication or project
• Batch mode execute PUT requests by default when
required but this can be prevent.
Synchronization mode

Projects or publications preferences
• All projects mean any projects
that is linked to the researcher
page also if not displayed
• Selected projects are only the
projects that were pickup by
the researcher in the
management projects tool
• My projects are all the projects
linked to the researcher except
the ones that were hided

Biography preferences
• The researcher choices which
properties can be synch with
ORCID
• Preference properties are prefixed
with orcid-profile-pref- followed
by the name of the source
properties in DSpace-CRIS. The
label is the target property name
in the ORCID model
https://wiki.duraspace.org/display/DSPACECRIS/ORCID+Integration#ORCIDIntegratio
n-MappinglocalpropertiestoORCID

Synchronization queue
The queue
Synchronization activated
Manual PUSH

• The ORCID queue (cris_orcid_queue table) is populated
using a
• dspace consumer that observe all changes to DSpace Items
(org.dspace.app.cris.integration.authority.CrisOrcidQueueConsumer)
• Hibernate listener that observe all changes to DSpace-CRIS
objects (org.dspace.app.cris.model.listener.OrcidQueueListener)
• The queue is processed by the batch script or by the UI
when the user hit the send button
• The need for a PUT request is a tracked with a special
placeholder
• The cris_orcid_history table contain the response
message and code for any push action to ORCID. The
PUT code assigned to the “generated” object in the
ORCID registry is stored here
ORCID Sync queue & history

ORCID Mapping
• Mapping between the Researcher Page properties
and the ORCID profile is implicitly managed by the
biography preference properties configuration
• Mapping from the DSpace Item metadata to the
ORCID Work is done in orcid-work-metadata.properties
• The orcid.citation_crosswalk configuration properties
defines the dissemination crosswalk to use to create the
citation record (BibTeX, etc)
• Mapping from the CRIS Project properties and the
ORCID Funding is done in orcid-funding-metadata.properties

• An access token, valid for all the scopes configured
in authentication-oauth.cfg#L71, is obtained when
an user login with ORCID or connect his ORCID
profile
• The access token is stored in the
eperson.orcid.accesstoken of the loggedin EPerson
and copied, for each granted scope, in the following
RP properties (system-orcid-token-authenticate, system-orcid-token-
orcid-profile-read-limited, system-orcid-token-orcid-bio-update, system-orcid-
token-orcid-works-create, system-orcid-token-orcid-works-update, system-orcid-
token-funding-create, system-orcid-token-funding-update)
ORCID Access tokens

• If a researcher profile is not linked to a DSpace
EPerson there are two potential way to claim the
profile
• If the profile has an email, you can guess the email
address to get an email with a forget password link and
a new account with such email will be created and
linked to the researcher profile
• If the profile has an ORCID, you can simply login via
ORCID to prove that you are the owner of the profile
• Automatic claiming of existent profiles is performed
by the system at login time using the ORCID ID and
the email address as a “post login action”
Claim a researcher profile

External identifiers can be used to directly address the profile page
without knowing the internal CRIS identifier
/cris/rp/details.htm?lt=orcid&lv=0000-0002-2312-0318
Any type of identifier is allowed (including the ones created locally
by the institution – e.g.: staff #)
/cris/rp/details.htm?lt=<ext_id>&lv=<ext_value>
This permits an easy and direct integration with other
institutional sites (staff directory, etc.)

• DSpace-CRIS doesn’t use the SOLR Authority index.
Generally speaking the DynamicObject offer a much
complete solution to manage any other local or locally
cached authority but technically, once enabled, nothing
prevent to use the SOLR Authority Index if needed.
• ORCID and AccessToken available in the EPerson
metadata as eperson.orcid and
eperson.orcid.accesstoken are automatically reused
during RP creation to PULL richer information from
ORCID
• Via API is it possible to fill a ResearcherProfile from a
specific ORCID supplying an accesstoken (or the public
access)
Additional questions on the ORCID
integration

• Public or Member API?
• Public: login, claim, search of ORCID registry, pull of
public information during researcher profile creation
• Member API: write to the ORCID registry, access to
limited information on single researcher
• Production or sandbox environment?
• Sandbox: you can test member API also if you are not
yet a member, including Premium services (webhooks
reserved to national agreements – not used by DSpace-
CRIS so far). You can create multiple “user” accounts to
facilitate testing
• Production: you can conduct limited test involving
volunteer real users
Configuration of the ORCID API-KEY

All is set in the authentication-oaut.cfg (via build.properties /
local.cfg)
• API endpoints
• orcid-api-url
• application-authorize-url
• application-token-url
• Authorized Scopes (application-client-scope)
• /authenticate /orcid-profile/read-limited /orcid-bio/update /orcid-works/create /orcid-
works/update /funding/create /funding/update /activities/update
• Client credentials
• application-client-id
• application-client-secret
• application-redirect-uri (you can use fake hosts entry to simulate
production URL)
• application-client-name (only required for v1.2)
Environment configuration

Andrea Bollini
<andrea.bollini@4science.it>
mobile: +39 333 934 1808
skype: a.bollini
linkedin: andreabollini
orcid: 0000-0002-9029-1854
Thanks for your attention

DSpace-CRIS technical level introduction

More Related Content

What's hot (20)

Similar to DSpace-CRIS technical level introduction (20)

More from 4Science (20)

Recently uploaded (20)

DSpace-CRIS technical level introduction