You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PR: [when the PR is created, put a link to it here. DO NOT use the "linked PR" feature]
User Test Scripts: [when there are user test scripts available link them here]
How are endorsements recorded on the Invenio record?
What information is stored on the Invenio record? It’s recommended that full meta info of the review is attached to the record as this is valuable to downstream users. For example:
The source of the review (e.g. PCI)
The date of the endorsement
The number of reviews
A link to the endorsement page
Meta information about the review should be written into all versions of the record without triggering new versions themselves
Who can add/remove the review from the record? Some options:
The user - if it is plain metadata it can be managed like all other metadata
An admin - in order to prevent it being removed except if in error
CERN discussed internally how to model all this information. From the functional point of view, it would be nice in Zenodo/InvenioRDM to search for all records that have been reviewed. This means not all indexing this info in OpenSearch, but also display it in the search results and the record’s landing page.
We should store review info by record’s version, however we should display the reviews for any versions, so this info is more visible to users.
About the data model (taking this https://zenodo.org/records/4028830 as an example), to be able to be independent of the reviews provider, we should have one db row per review (and not only one row for the final endorsement). We should also store rejections when available.
Possible DB table schema for the reviews:
Parent record id
Record version id
Review id (PID, URL, DOI, …)
Review date
Endorsement status (or better field naming?): accepted, misused, rejected, etc… (suggestion to check statuses in OJS, and also RR\ID Strength of Evidence Scale)
Text string (a blob where any info could be stored and then displayed)
Source (the provider, name or URL) - maybe more complex?
Row created/updated dates
The endorsement status can allow the repo to show the reviews info in different ways, for example as a banner for the record above in Zenodo when controversial, or in side bar/bottom tabs otherwise.
Technically, the info in this table should be resolved in the record and indexed as a system field. The user has no control over this.
Acceptance Criteria
List the criteria which must be met for the issue to be considered complete
A set of notifications can be parsed and turned into the appropriate "review" datastructure which is the indexed on the record and is suitable to use in search results and landing pages
The text was updated successfully, but these errors were encountered:
How are endorsements recorded on the Invenio record?
What information is stored on the Invenio record? It’s recommended that full meta info of the review is attached to the record as this is valuable to downstream users. For example:
The source of the review (e.g. PCI)
The date of the endorsement
The number of reviews
A link to the endorsement page
Meta information about the review should be written into all versions of the record without triggering new versions themselves
Who can add/remove the review from the record? Some options:
The user - if it is plain metadata it can be managed like all other metadata
An admin - in order to prevent it being removed except if in error
CERN discussed internally how to model all this information. From the functional point of view, it would be nice in Zenodo/InvenioRDM to search for all records that have been reviewed. This means not all indexing this info in OpenSearch, but also display it in the search results and the record’s landing page.
We should store review info by record’s version, however we should display the reviews for any versions, so this info is more visible to users.
About the data model (taking this https://zenodo.org/records/4028830 as an example), to be able to be independent of the reviews provider, we should have one db row per review (and not only one row for the final endorsement). We should also store rejections when available.
The endorsement status can allow the repo to show the reviews info in different ways, for example as a banner for the record above in Zenodo when controversial, or in side bar/bottom tabs otherwise.
Technically, the info in this table should be resolved in the record and indexed as a system field. The user has no control over this.
Acceptance Criteria
List the criteria which must be met for the issue to be considered complete
The text was updated successfully, but these errors were encountered: