PCI Endorsement

Draft workflow
This is a workflow where the author of a preprint stored in a repository can request an endorsement from PCI.
Owner of this workflow: Peer Community In (PCI)
Systems using this workflow: HAL
Platforms supporting this workflow:

This workflow was originally developed between PCI and HAL, but it can be used by other repositories wishing to interoperate with PCI.

flowchart LR
    1(["`**1** Initiate`"])
    2["`**2** *Request
    Endorsement*`"]
    3{"`**3** Process
    request`"}
    4["`**4** *Reject*`"]
    5(["`**5** Accept
    decision`"])
    6["`**6** *Tentative Accept*`"]
    7["`**7** Note
    under review`"]
    8{"`**8** Conduct
    review`"}
    9["`**9** *Reject*`"]
    10(["`**10** Accept
    decision`"])
    11["`**11** *Announce
    Review*`"]
    12["`**12** Record
    review`"]
    13["`**13** *Announce
    Endorsement*`"]
    14(["`**14** Record
    decision`"])
    
    1 --> 2
    2 --> 3
    3 --> 4
    4 --> 5
    3 --> 6
    6 --> 7
    7 --> 8
    8 --> 9
    9 --> 10
    8 --> 11
    11 --> 12
    12 --> 13
    13 --> 14

Repository

Notifications

PCI

1 Author initiates a review request for a preprint
The corresponding author chooses a PCI X in a dropdown menu on their repository (obtained from PCI API) and sends a review request
2 Request Endorsement right arrow

The repository requests an endorsement from PCI.

If there has been a previous round of evaluation of this repository resource, then this notification may include an inReplyTo property that references the Activity ID of the previous Reject notification. The notification includes:

  • the DOI (URL that includes the version) of the preprint
  • the Email of the author ("mailto:" URI in the ID property of the actor)

@context

The @context must include:

actor

The actor describes the party responsible for this activity. The actor has:

  • An id which must be a URI identifying the actor (HTTP URIs are preferred, but any valid URI is permitted)
  • A type which should be one of: Application, Group, Organization, Person or Service from AS 2.0.
  • The actor may also have a name

id

Notify payloads must describe an AS 2.0 activity. The activity has an id which must be a URI, and the use of URN:UUID is recommended. An HTTP URI may be used instead, but in such cases the URI should resolve to a useful resource.

object

The object describes the resource which is the main focus of this notification.

In this particular example:

  • An id which is the HTTP URI of the "landing page" for the resource.
  • A type which should include the value AboutPage from schema.org.
  • An ietf:cite-as which contains the persistent HTTP URI (sometimes called the "PID") which is to be used to cite or link to the resource.
  • An ietf:item containing the details of the actual content resource. The ietf:item has:
    • An id containing the HTTP URI of the content file for the resource.
    • A type describing the content file.
    • A mediaType which contains the MIME Type of the content file.

origin

The origin describes the system which has sent the notification. The origin has:

  • An id which is an HTTP URI identifying the sending system
  • A type which should include the value Service from AS 2.0.
  • An inbox which is the HTTP URI of the LDN inbox for the origin

target

The target describes the system which is intended to receive the notification. The target has:

  • An id which is an HTTP URI identifying the receiving system
  • A type which should include the value Service from AS 2.0.
  • An inbox which is the HTTP URI of the LDN inbox for the target

type

The activity has a type which should include Offer & coar-notify:EndorsementAction

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://purl.org/coar/notify"
  ],
  "actor": {
    "id": "mailto:[email protected]",
    "name": "Josiah Carberry",
    "type": "Person"
  },
  "id": "urn:uuid:0370c0fb-bb78-4a9b-87f5-bed307a509dd",
  "object": {
    "id": "https://research-organisation.org/repository/preprint/201203/421/",
    "ietf:cite-as": "https://doi.org/10.5555/12345680",
    "ietf:item": {
      "id": "https://research-organisation.org/repository/preprint/201203/421/content.pdf",
      "mediaType": "application/pdf",
      "type": [
        "Article",
        "sorg:ScholarlyArticle"
      ]
    },
    "type": "sorg:AboutPage"
  },
  "origin": {
    "id": "https://research-organisation.org/repository",
    "inbox": "https://research-organisation.org/inbox/",
    "type": "Service"
  },
  "target": {
    "id": "https://https://peercommunityin.org",
    "inbox": "https://peercommunityin.org/inbox/",
    "type": "Service"
  },
  "type": [
    "Offer",
    "coar-notify:EndorsementAction"
  ]
}
3 PCI processes the offer

PCI processes the offer. This offer is either an initial submission or a resubmission. The process is different depending on the case.

Initial submission

This is indicated by the absence of a inReplyTo property. The process is as follows:

  1. PCI gets the metadata from signposting and creates a pre-submission page
  2. PCI sends an email to the authors containing the URL that would send the author directly to the prefilled submission/resubmission page of PCI X after registering if needed and after login in PCI X website.
  3. The authors check the pre-filled information, complete the metadata (e.g. links to data, scripts, codes, PCI thematic fields) and complete the submission.
  4. If no validation by the Managing board or no handling by a recommender (negative outcome) then an email is sent to the authors and the process stops. PCI sends a Reject notification.
  5. If validation by the managing board and handling by a recommender (positive outcome) then an email is sent to the authors and the review process begins. PCI sends a TentativeAccept notification.

Re-submission

This is indicated by the presence of a inReplyTo property referencing the Activity ID of the previous Reject notification. The process is as follows:

  1. PCI sends an Email to the author containing the link to the resubmission form
  2. PCI digests the new URL with the new version and prefill the resubmission form with signposting (optional), and keep other old data (eg opposed reviewers)
  3. The author completes the resubmission form and replies to reviewers
  4. If no validation by the Managing board or no handling by a recommender (negative outcome) then an email is sent to the authors and the process stops. PCI sends a Reject notification.
  5. If validation by the managing board and handling by a recommender (positive outcome) then an email is sent to the authors and the review process begins. PCI sends a TentativeAccept notification.
left arrow 4 Reject

PCI rejects the offer to endorse the preprint

@context

The @context must include:

id

Notify payloads must describe an AS 2.0 activity. The activity has an id which must be a URI, and the use of URN:UUID is recommended. An HTTP URI may be used instead, but in such cases the URI should resolve to a useful resource.

inReplyTo

In this particular example: inReplyTo is specified because this is a response to a previous notification. inReplyTo takes the URI (URN:UUID or HTTP URI) which identifies the activity for which this is a response.

origin

The origin describes the system which has sent the notification. The origin has:

  • An id which is an HTTP URI identifying the sending system
  • A type which should include the value Service from AS 2.0.
  • An inbox which is the HTTP URI of the LDN inbox for the origin

target

The target describes the system which is intended to receive the notification. The target has:

  • An id which is an HTTP URI identifying the receiving system
  • A type which should include the value Service from AS 2.0.
  • An inbox which is the HTTP URI of the LDN inbox for the target

type

The activity has a type with the value Reject

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://purl.org/coar/notify"
  ],
  "id": "urn:uuid:668f26e0-2c8d-4117-a0d2-ee713523bcb1",
  "inReplyTo": "urn:uuid:0370c0fb-bb78-4a9b-87f5-bed307a509dd",
  "origin": {
    "id": "https://https://peercommunityin.org",
    "inbox": "https://peercommunityin.org/inbox/",
    "type": "Service"
  },
  "target": {
    "id": "https://research-organisation.org/repository",
    "inbox": "https://research-organisation.org/inbox/",
    "type": "Service"
  },
  "type": "Reject"
}
5 The repository accepts the decision and takes no further action
If PCI sent a Reject notification in step 4 then the workflow ends here
workflow terminates here
left arrow 6 Tentatively Accept

PCI tentatively accepts the offer to begin the process of reviewing and potentially endorsing the preprint

@context

The @context must include:

id

Notify payloads must describe an AS 2.0 activity. The activity has an id which must be a URI, and the use of URN:UUID is recommended. An HTTP URI may be used instead, but in such cases the URI should resolve to a useful resource.

inReplyTo

In this particular example: inReplyTo is specified because this is a response to a previous notification. inReplyTo takes the URI (URN:UUID or HTTP URI) which identifies the activity for which this is a response.

origin

The origin describes the system which has sent the notification. The origin has:

  • An id which is an HTTP URI identifying the sending system
  • A type which should include the value Service from AS 2.0.
  • An inbox which is the HTTP URI of the LDN inbox for the origin

target

The target describes the system which is intended to receive the notification. The target has:

  • An id which is an HTTP URI identifying the receiving system
  • A type which should include the value Service from AS 2.0.
  • An inbox which is the HTTP URI of the LDN inbox for the target

type

The activity has a type with the value TentativeAccept

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://purl.org/coar/notify"
  ],
  "id": "urn:uuid:4fb3af44-d4f8-4226-9475-2d09c2d8d9e0",
  "inReplyTo": "urn:uuid:0370c0fb-bb78-4a9b-87f5-bed307a509dd",
  "origin": {
    "id": "https://https://peercommunityin.org",
    "inbox": "https://peercommunityin.org/inbox/",
    "type": "Service"
  },
  "target": {
    "id": "https://research-organisation.org/repository",
    "inbox": "https://research-organisation.org/inbox/",
    "type": "Service"
  },
  "type": "TentativeAccept"
}
7 The repository notes that the preprint is under review
The repositorymay wish to internally prevent the preprint from being offered elsewhere for review while this review is ongoing
8 PCI proceeds with review of the preprint

PCI proceeds with evaluation of the preprint until an editorial decision is reached. The authors are emailed to inform them of the decision and to share the reviews with them.

If the editorial decision is to endorse the preprint, then the outcome is published on the PCI site.

In the editorial decision is that a revision is required, then the author is emailed to explain that resubmission will have to be made through the repository (as before)

left arrow 9 Reject

Having reviewed the preprint, PCI rejects the offer to endorse it. If the editorial decision is that a revision is required, then the author is emailed to explain that resubmission will have to be made through the repository (as before).

@context

The @context must include:

id

Notify payloads must describe an AS 2.0 activity. The activity has an id which must be a URI, and the use of URN:UUID is recommended. An HTTP URI may be used instead, but in such cases the URI should resolve to a useful resource.

inReplyTo

In this particular example: inReplyTo is specified because this is a response to a previous notification. inReplyTo takes the URI (URN:UUID or HTTP URI) which identifies the activity for which this is a response.

origin

The origin describes the system which has sent the notification. The origin has:

  • An id which is an HTTP URI identifying the sending system
  • A type which should include the value Service from AS 2.0.
  • An inbox which is the HTTP URI of the LDN inbox for the origin

target

The target describes the system which is intended to receive the notification. The target has:

  • An id which is an HTTP URI identifying the receiving system
  • A type which should include the value Service from AS 2.0.
  • An inbox which is the HTTP URI of the LDN inbox for the target

type

The activity has a type with the value Reject

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://purl.org/coar/notify"
  ],
  "id": "urn:uuid:668f26e0-2c8d-4117-a0d2-ee713523bcb1",
  "inReplyTo": "urn:uuid:0370c0fb-bb78-4a9b-87f5-bed307a509dd",
  "origin": {
    "id": "https://https://peercommunityin.org",
    "inbox": "https://peercommunityin.org/inbox/",
    "type": "Service"
  },
  "target": {
    "id": "https://research-organisation.org/repository",
    "inbox": "https://research-organisation.org/inbox/",
    "type": "Service"
  },
  "type": "Reject"
}
10 The repository accepts the decision and takes no further action
If PCI sent a Reject notification in step 8 then the workflow ends here
workflow terminates here
left arrow 11 Announce Review

Having decided to endorse the preprint, PCI publishes the review and announces this

@context

The @context must include:

actor

The actor describes the party responsible for this activity. The actor has:

  • An id which must be a URI identifying the actor (HTTP URIs are preferred, but any valid URI is permitted)
  • A type which should be one of: Application, Group, Organization, Person or Service from AS 2.0.
  • The actor may also have a name

context

When the object describes the result of some service acting on a resource, the context may be used to refer to that second resource.

In this particular example:

  • An id which is the HTTP URI of the "landing page" for the resource.
  • A type which should include the value AboutPage from schema.org.
  • An ietf:cite-as which contains the persistent HTTP URI (sometimes called the "PID") which is to be used to cite or link to the resource.
  • An ietf:item containing the details of the actual content resource. The ietf:item has:
    • An id containing the HTTP URI of the content file for the resource.
    • A type describing the content file.
    • A mediaType which contains the MIME Type of the content file.

id

Notify payloads must describe an AS 2.0 activity. The activity has an id which must be a URI, and the use of URN:UUID is recommended. An HTTP URI may be used instead, but in such cases the URI should resolve to a useful resource.

inReplyTo

In this particular example: inReplyTo may be specified if this is a response to a previous notification. inReplyTo takes the URI (URN:UUID or HTTP URI) which identifies the activity for which this is a response.

object

The object describes the resource which is the main focus of this notification.

In this particular example:

  • id is the HTTP URI of the "landing page" for the resource.
  • type should include the value Document from AS 2.0, and sorg:Review
  • ietf:cite-as contains the persistent HTTP URI (sometimes called the "PID") which is to be used to cite or link to the resource.

origin

The origin describes the system which has sent the notification. The origin has:

  • An id which is an HTTP URI identifying the sending system
  • A type which should include the value Service from AS 2.0.
  • An inbox which is the HTTP URI of the LDN inbox for the origin

target

The target describes the system which is intended to receive the notification. The target has:

  • An id which is an HTTP URI identifying the receiving system
  • A type which should include the value Service from AS 2.0.
  • An inbox which is the HTTP URI of the LDN inbox for the target

type

The activity has a type which should include Announce & coar-notify:ReviewAction

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://purl.org/coar/notify"
  ],
  "actor": {
    "id": "https://review-service.com",
    "name": "Review Service",
    "type": "Service"
  },
  "context": {
    "id": "https://research-organisation.org/repository/preprint/201203/421/",
    "ietf:cite-as": "https://doi.org/10.5555/12345680",
    "ietf:item": {
      "id": "https://research-organisation.org/repository/preprint/201203/421/content.pdf",
      "mediaType": "application/pdf",
      "type": [
        "Article",
        "sorg:ScholarlyArticle"
      ]
    },
    "type": "sorg:AboutPage"
  },
  "id": "urn:uuid:94ecae35-dcfd-4182-8550-22c7164fe23f",
  "inReplyTo": "urn:uuid:0370c0fb-bb78-4a9b-87f5-bed307a509dd",
  "object": {
    "id": "https://review-service.com/review/geo/202103/0021",
    "ietf:cite-as": "https://doi.org/10.3214/987654",
    "type": [
      "Document",
      "sorg:Review"
    ]
  },
  "origin": {
    "id": "https://https://peercommunityin.org",
    "inbox": "https://peercommunityin.org/inbox/",
    "type": "Service"
  },
  "target": {
    "id": "https://research-organisation.org/repository",
    "inbox": "https://research-organisation.org/inbox/",
    "type": "Service"
  },
  "type": [
    "Announce",
    "coar-notify:ReviewAction"
  ]
}
12 The repository records the link to the review
The repository records (and optionally displays) the link to the review
left arrow 13 Announce Endorsement

Having decided to endorse the preprint, PCI announces this

@context

The @context must include:

actor

The actor describes the party responsible for this activity. The actor has:

  • An id which must be a URI identifying the actor (HTTP URIs are preferred, but any valid URI is permitted)
  • A type which should be one of: Application, Group, Organization, Person or Service from AS 2.0.
  • The actor may also have a name

context

When the object describes the result of some service acting on a resource, the context may be used to refer to that second resource.

In this particular example:

  • An id which is the HTTP URI of the "landing page" for the resource.
  • A type which should include the value AboutPage from schema.org.
  • An ietf:cite-as which contains the persistent HTTP URI (sometimes called the "PID") which is to be used to cite or link to the resource.
  • An ietf:item containing the details of the actual content resource. The ietf:item has:
    • An id containing the HTTP URI of the content file for the resource.
    • A type describing the content file.
    • A mediaType which contains the MIME Type of the content file.

id

Notify payloads must describe an AS 2.0 activity. The activity has an id which must be a URI, and the use of URN:UUID is recommended. An HTTP URI may be used instead, but in such cases the URI should resolve to a useful resource.

inReplyTo

In this particular example: inReplyTo may be specified if this is a response to a previous notification. inReplyTo takes the URI (URN:UUID or HTTP URI) which identifies the activity for which this is a response.

object

The object describes the resource which is the main focus of this notification.

In this particular example:

  • An id which identifies the resource representing the endorsement.
  • An ietf:cite-as which contains the persistent HTTP URI (sometimes called the "PID") which is to be used to cite or link to the resource representing the endorsement.
  • A type describing the content file.

origin

The origin describes the system which has sent the notification. The origin has:

  • An id which is an HTTP URI identifying the sending system
  • A type which should include the value Service from AS 2.0.
  • An inbox which is the HTTP URI of the LDN inbox for the origin

target

The target describes the system which is intended to receive the notification. The target has:

  • An id which is an HTTP URI identifying the receiving system
  • A type which should include the value Service from AS 2.0.
  • An inbox which is the HTTP URI of the LDN inbox for the target

type

The activity has a type which should include Announce & coar-notify:EndorsementAction

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://purl.org/coar/notify"
  ],
  "actor": {
    "id": "https://overlay-journal.com",
    "name": "Overlay Journal",
    "type": "Service"
  },
  "context": {
    "id": "https://research-organisation.org/repository/preprint/201203/421/",
    "ietf:cite-as": "https://doi.org/10.5555/12345680",
    "ietf:item": {
      "id": "https://research-organisation.org/repository/preprint/201203/421/content.pdf",
      "mediaType": "application/pdf",
      "type": [
        "Article",
        "sorg:ScholarlyArticle"
      ]
    },
    "type": "sorg:AboutPage"
  },
  "id": "urn:uuid:94ecae35-dcfd-4182-8550-22c7164fe23f",
  "inReplyTo": "urn:uuid:0370c0fb-bb78-4a9b-87f5-bed307a509dd",
  "object": {
    "id": "https://overlay-journal.com/articles/00001/",
    "ietf:cite-as": "https://overlay-journal.com/articles/00001/",
    "type": [
      "Page",
      "sorg:WebPage"
    ]
  },
  "origin": {
    "id": "https://https://peercommunityin.org",
    "inbox": "https://peercommunityin.org/inbox/",
    "type": "Service"
  },
  "target": {
    "id": "https://research-organisation.org/repository",
    "inbox": "https://research-organisation.org/inbox/",
    "type": "Service"
  },
  "type": [
    "Announce",
    "coar-notify:EndorsementAction"
  ]
}
14 The repository records the link to the endorsement
The repository records (and optionally displays) the link to the endorsement
workflow terminates here