Registration / Certification Interoperability Architecture (overlay peer-review)

Herbert Van de Sompel @hvdsomp Martin Klein @mart1nkle1n
INRIA, Paris, France, 24 February 2020
Registration/Certification Interoperability – Architecture
Herbert Van de Sompel @hvdsomp (DANS)
Martin Klein @mart1nkle1n (LANL)

In This Talk
1. Historical Perspective
2. Relevant Standards
3. Possible Architecture

Functions of Scholarly Communication
• Registration: Allows claims of precedence for a scholarly finding
• Certification: Establishes validity of the claim
• Awareness: Allows actors in the system to remain aware of new
claims
• Archiving: Preserves the scholarly record over time
Roosendaal and Geurts (1997) Forces and Functions in Scientific Communication.
http://www.physik.uni-oldenburg.de/conferences/crisp97/roosendaal.html

Decoupling Registration from Certification
Paul Ginsparg (2001) Creating a global knowledge network.
http://www.cs.cornell.edu/~ginsparg/physics/blurb/pg01unesco.html

Van de Sompel, H (2000) CNI Fall Closing Keynote, San Diego, TX, 8 December 2000
https://www.dropbox.com/s/ishcrzo9tv3uq4c/coar_overlay_review.pptx?dl=0

Van de Sompel, H., et al. (2004) Rethinking scholarly communication: Building the System that
Scholars Deserve. D-Lib Magazine, 10(9). https://doi.org/10.1045/september2004-vandesompel
Pathways for a unit of scholarly
communication

Decoupling All Functions
• In a digital networked scholarly communication system:
• Each function can be fulfilled by a different party
• Each function can be fulfilled in different ways
• Each function can simultaneously be fulfilled by different parties,
potentially in different ways
• In order for this to be realistically feasible/scalable, interoperability
needs to be established between the parties/services that fulfill the
functions

Van de Sompel, H., et al. (2006) An Interoperable Fabric for Scholarly Value Chains. D-Lib
Magazine, 12(10). https://doi.org/10.1045/october2006-vandesompel
NSF Pathways: Early (2006) Attempt at Achieving Interoperability
• Focused very strongly on web-centric representation of compound
digital objects (meanwhile called Research Objects)
• Resulted in OAI-ORE (core ingredient of Research Objects model)
• The technology/standards were just not there yet

Web Technologies/Standards are Here, Now!
• Linked Data Notifications (LDN)
• Think email with structured payload suitable for machine
consumption
• Inbox automatically discoverable
• ActivityStreams2 (AS2)
• Think vocabulary/syntax to describe social interactions with web
content/platforms
• As payloads for LDN
• HTTP Links
• To support automatic discovery of e.g. Inbox, bibliographic
information, …
• Web Annotation
• To model a review as an annotation with assement motivation

W3C Linked Data Notifications
Capadisli, S. and Guy, A. (2017) W3C Recommendation: Linked Data Notifications
https://www.w3.org/TR/ldn/

W3C Activity Streams 2.0
Snell, J. and Prodromou, E. (2017) W3C Recommendation: Activity Streams 2.0
https://www.w3.org/TR/activitystreams-core/

IETF Web Linking
Mark Nottingham (2017) RFC8288: Web Linking.
http://tools.iets.org/rfc/rfc8288.txt (supersedes RFC5988)

LDN Inbox Discovery using Web Linking
Capadisli, S. and Guy, A. (2017) W3C Recommendation: Linked Data Notifications
https://www.w3.org/TR/ldn/

Discovery of Related Scholarly Resources using Web Linking
http://signposting.org
Signposting: Clarification of landing pages so machines can make sense of
them and discover related resources via Web Links, e.g. bibliographic
descriptions, author identifier, artefact identifier, “:the PDF”, …

• Sarven Capdisli’s “Linked Research” PhD suggests that these
technologies can be sufficient to provide an interoperable glue in a
highly decentralized and decoupled scholarly communication
system, see https://csarven.ca/linked-research-decentralised-web

• The Mellon-funded myresearch.institute work demonstrates how
these technologies can be used to provide an interoperable glue
between registration and archiving, see
https://myresearch.institute/about/

• A recently Mellon-funded UGent/DANS project will leverage these
technologies as the basis for spec-ing interoperability in a highly
decentralized/decoupled scholarly communication system

Alice’s pod
Artifact
URI-A
INBOX
(1) register
URI-A
(0) create
Registration Service Hub
register(R-SH,URI-A)
INBOX
Registration Certification
(3)
request
registration
Certification Service Hub
E2: certify(C-SH,URI-A)
INBOX
Awareness Service Hub
E3: disseminate(W-SH,URI-A)
INBOX
Archiving service hub
E4: archive(A-SH,URI-A)
INBOX
Awareness
(6)
notify
of
certification
Archiving
(4)
notify
of
registration
(5)
request
certification Orchestrator
(2) trigger
registration
(8)
acknowledge
existence
(10)
notify
of
archiving
(7)
notify
of
existence
Policy rules
E1
E1 E2 E3 E4
E2 E3 E4
(9)
request
archiving
Scholarly
Dashboard

Overlay Review Scenario: Interop Goals
• Uniform communication between repositories and overlay review
services in various registration/certification scenarios
• Ability to link from preprint to review outcome
• Ability to link from review outcome to preprint

Overlay Review Scenario: Interop Ingredients
• Communication protocol:
• Linked Data Notifications send/receive
• Parties expose their LDN Inbox using Web Linking techniques
• Payloads
• ActivityStreams2/JSON-LD payloads for notifications
• Profiling of the notifications/payloads to match requirements of
the scenario
• Discovery
• Discovery of remote LDN Inboxes that are exposed using Web
Linking techniques
• Expose metadata about hosted resources (e.g. preprint, review)
using Web Linking techniques

Overlay Review Scenario: A Sample Flow
• The exact way in which to profile notifications and payloads needs
to be determined in function of a requirement analysis
• Number of notifications involved
• Choice of activity types
• Required vocabularies
• Etc.
• In the following approach, the scenario is modeled using 3
notifications:
• The IR asks an overlay whether it is willing to review a preprint
• The overlay notifies the IR whether it is willing or not to do so
• If the overlay is willing, it later notifies the IR of the review
outcome

• Preprint URI-P exists in IR
(1)

• Introduce interoperability
requirement for both IR
and Overlay:
• Support LDN Send
• Support LDN Inbox
• Support discovery of
LDN Inbox

• IR sends review request (2)
to LDN Inbox of overlay
• IR needs baseURL of
target Overlay
• Overlay needs to
support discovery of its
LDN Inbox
• Payload is AS2/JSON-LD:
• Preprint is the object
• Identified by PID-
URI
• Other URIs may be
in payload
• Activity type is offer
• Might also need
specific scholarly
activity types
• Description of URI-P
may be in the payload
or retrievable from IR

• Overlay receives
notification (2) - review
request for URI-P - sent by
IR in its LDN Inbox
• Regarding URI-P, the
Overlay may need to
obtain descriptive
metadata (in case not in
notification payload)
and/or content
• Via URIs in payload or
via Web Linking
support by IR

• In (3), the overlay
considers organizing a
review process for the
preprint

• After consideration, the
overlay sends a
notification (4) to the IR:
• The offer sent in (2) is
the object
• Which itself has
information on
URI-P
• Activity type is accept
or reject depending on
whether the overlay
will organize review or
not
• accept pertains to
the offer sent in
(2), not to the
preprint
• reject pertains to
the offer sent in
(2), not to the
preprint

• The IR receives the
notification (4) from the
Overlay in its LDN Inbox
and may add pertinent
review status information
to what it already knows
about the preprint (5)
• If the activity type of (4) is
reject, the scenario ends
• If the activity type of (4) is
accept, the scenario
continues

• If the Overlay decided to
review the preprint, the
review outcome is
published by the Overlay
at URI-R (7)
• The review process
(6) is considered a
black box for this
interoperability
exercise
• Since it is known to the
Overlay that URI-R is the
outcome of reviewing the
preprint, the Overlay can
establish a relation/link
between the outcome and
the preprint (8)

• The overlay sends a
notification (9) to the LDN
Inbox of the IR
• IR needs to support
discovery of its LDN
Inbox
• Payload is AS2/JSON-LD:
• Review outcome URI-
R is the object
• Activity type is
inReplyTo
• The reply is to the
preprint URI-P

• The IR receives the
notification (9) from the
Overlay in its LDN Inbox
and adds pertinent review
status information to what
it already knows about the
preprint (10)
• Based on the payload of
notification (8), the IR can
establish a relation/link
between the preprint and
the review outcome (11)

Herbert Van de Sompel @hvdsomp (DANS)
Martin Klein @mart1nkle1n (LANL)
Registration/Certification Interoperability – Architecture

Registration / Certification Interoperability Architecture (overlay peer-review)

More Related Content

What's hot

Similar to Registration / Certification Interoperability Architecture (overlay peer-review)

More from Herbert Van de Sompel

Recently uploaded

Registration / Certification Interoperability Architecture (overlay peer-review)