Skip to content

Designing the new CEOS-ARD Self-Assessment and Review procedure/tools #94

Description

@m-mohr

Introduction

We will develop a CEOS-ARD Assessor for self-assessment and review.
It consists of two interfaces: One for self-assessment (data provider assessing their products) and one for review of submitted self-assessments (e.g. by GA). It supports the whole process (iteratively), making it more efficient. Self-assessments are stored in a database.

Data providers can select the PFS(es) to assess against. They can upload supporting documents (e.g. metadata) and connect the requirements in the PFSes with specific components in the supporting documents. A growing set of automations will be made available, e.g. some level of validation. Self-assessments against new PFS versions can be based on previous assessments.

Reviewers can review the submitted self-assessments and see the connections between requirements and supporting documents that data providers provided. They can leave comments and approve / (temporarily) reject submissions. Multiple iterations are possible where data providers can improve their submission based on reviewer feedback.

Requirements

  • XML Path / XML Schema
  • JSON Path / JSON Schema

...

Server implementation

  • Login via GitHub or Google Account

Tech stack:

  • Extent CEOS-ARD Server, so Python as server language
  • Move from SQLite to a different database
    ...

Client/UI implementation

Similar to CEOS-ARD Editor:

  • Login
  • Self-Assessments / Products (similar to workspaces)
  • Editor
    • Tree with categories & requirements
      • Color coded depending on the status
      • ...
    • Assessment/Review pane
      • Rendered requirement
      • Comments from Provider
      • Checkboxes [Reviewed/...] / Comments from Reviewer
      • ...
    • Metadata/Data panel
      • Upload files
      • Show files
      • Select/Mark parts of the file
      • ...
    • Create connections between metadata and review (JSON/XML Path) etc
    • Each review has to be approved by the reviewer. Only after approval the changes made (e.g. comments) get visible.
    • After approval a summary is generated and shown to the reviewer. The summary is also sent via email to the provider. Before approval no communication is made.

Tech stack:

  • Extend CEOS-ARD Editor
  • Rename repo ceos-ard-editor to ceos-ard-ui or so
  • Vue.JS 3, Vuetify, etc.

Building blocks

Additional information

  • Flag whether a panel review is required or not?
  • Weight of the requirement?

metadata

metadata is the entry point in the building blocks. Underneath we propose the following structure:

  • List of "sub-requirements" with an id
    • Human readable title from the document
    • Additional comments/notes?
    • Schema(s) - either generically or in JSON/XML Schema
    • XPath [for SAR XML]/JSON Path/Pointer(s) [for STAC]

Metadata

Metadata

Assignees

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions