[Manageable Affordances TF] (decentralized) scholarly communication

[phochste]

Title: (decentralized) scholarly communication

Submitter(s):

Patrick Hochstenbach

Motivation:

Scholarly communication is very much monopolized by a handful of publishers that control more than 50% of the market (in some fields more than 70%). The scholarly community is investing for more than 20 years in alternative, decentralized communication systems. Institutions worldwide run institutional/subject repositories where publications can be submitted. There is a growing network of service providers that can provide all the functions of scholarly communication on top of this network: registration (to claim priority of research), certification (peer-review), endorsement (overlay journals, index databases) and archiving (web archives). To decouple these functions of scholarly communication, that are traditional centralized, some form of automation is required for the provision of these services. Also, the trust in the outcome of these processes is traditionally centralized and based on reputation of the service. In a decentralized web, reputation is difficult when there are very many actors involved. Some form of machine verification can be imagined so that trust can be objectively be verified.

Expected Participating Entities:

Data nodes such as repositories, archives, digital heritage institutions that provide (research) artifacts on the web equipped with affordances for discovery of metadata, provenance information and receive information about value-adding services pertaining to the artifacts (e.g. linkage information, review, comments, etc etc).

Service nodes such as timestamping services, peer-review systems, indexing databases, journal systems and web archives that provide affordances for the provision of scholary services and the discovery of provenance information of this process.

Workflow:

In the network automated agents (orchestrators) are introduced as smart assistants for the network actors. According to configurable rule sets these orchestrators execute typically workflows such as:

• When an article is submitted to the repository
  • the departmental database should be updated
  • a trusted timestamp of the article should be requested
  • a web archive should be contacted to create an archival copy
  • a citation extraction should extract all citations from the article and contact the cited repositories about new citations to their articles

The rules specify what should be done, but not how. Using affordances by all the network actors the provisioning of these services can be requested and traced to create a provenance trail.

Related Use Cases (if any):

• https://www.coar-repositories.org/notify/
• https://dans-labs.github.io/ddps-docs/
• https://erfgoedpod.github.io/usecases/
• https://journal.code4lib.org/articles/17823

Existing solutions:

Experimental work

• https://github.com/eyereasoner/Koreografeye

Identified Requirements by the TF:

1. Target entity(ies) of the motivating scenario: web repositories related to scholarly communication such as institutional repositories, service providers such as open access journals, abstracting&indexing databases, web archives. In all these scenarios an artifact (a scholarly resource) is the focus of the interaction. For this scenario it is important that in many cases a 'human is in the loop'.
2. Life cycle: there are no fixed life cycles in scholarly communication. At most lifecycles are declared and published by the entities. E.g. if an agent connects to service X, the lifecycle steps are A,B,C,D
3. Information conveyed about affordances:
   i. Information about the artifact (author ids (e.g. OCRID), publication status, global identifiers (e.g. DOI), fulltext location, license)
   ii. Information about the provenance trail for the artifact (which services were already provided by the network for this artifact and what was the result)
   iii. Information about who initiated the service, to whom this service was requested, what artifact is in focus, and what is the result of a service.
4. How the life cycle is influenced: target entities communicate asynchronously point-to-point using Linked Data Notification messaging. The messages provide information about which service are requested, information if a service provide is willing to provide a service for a particular artifact, information about the result of a service that was provisioned for an artifact
5. Communication protocols: Linked Data Notifications using Event Notifications payloads
6. Representation formats: JSON-LD
7. Security and privacy considerations: none yet, we assume open access publishing, open peer review in a public scholarly communication setting.

Comments:

[phochste]

Examples of configurable rules that should be available for different actors in scholarly communication settings. We use here the affordances and terminology used in Event Notifications protocol to present possible approaches a web agent could take.

User-defined

Triggered by observing local resources

A researcher makes a dataset available on her website. In order to claim precedence, she, as soon as possible, wants the data set to be archived in a web archive and indexed in a specialized search engine of her choice.

Possible approach

The researcher defines two rules for her personal web agent, respectively expressing that, when she adds a new data set to her personal website, the orchestrator must send out Event notifications about the data set to her preferred archiving and indexation service node.

Organization-defined

Triggered by resource state changes

A university department has a policy stating that it must be informed whenever a staff member submits a paper to a conference.

Possible approach

The department translates this policy into a rule document, publishes it on the departmental homepage, and informs all researchers. A researcher adds this departmental rule to her personal web agent. The submission of her paper to a conference is itself managed by event notifications: a submission request notification (with a link to her paper) is sent to the conference service node and a submission request acknowledgment is returned. The latter results in a status change of the paper to “registered”. This status change triggers the departmental rule and results in sending a notification to the departmental publication registration system.

Community defined

Triggered by time and status constraint

A government demands that one year after a research output has been peer-reviewed it must be registered in a national research portal.

Possible approach

The government translates this policy into a rule document publishes it on the research portal homepage and forwards the rule to all national institutes, which will inform their researchers. A researcher decides to add the time-based rule to her
personal orchestrator. As a result, the orchestrator will monitor the status changes of her research outputs. One year after an output went through peer review, a notification is generated and sent to the national portal.

[egekorkan]

@phochste thank you for the scenario proposal! We are now going to extract the requirements from each use case and we need you to extend your first comment with the types of requirements listed at #34. You can have a look at an example at #24