[Proposal] Evaluate an optional RO-Crate export for submission packets

[JUhalt]

Status and fit

Research-informed proposal for scope review; not assigned to a release. PaperRoute already plans exact submission packets (#25), route reports (#30), and a portable-sharing decision. An optional self-describing export could let a researcher understand selected packet files and their version context outside PaperRoute without needing its database.

Research and standard

Soiland-Reyes et al. (2022), Packaging research artefacts with RO-Crate, describes packaging research files with machine-readable identifiers, provenance, and relationships: published paper, author manuscript.

The official RO-Crate specification introduction describes JSON-LD metadata and a human-readable preview; its data-entity rules define relationships to packaged files. These sources motivate interoperability; they do not demonstrate that this export improves PaperRoute users' outcomes or that publishers accept it. Choose and pin a supported specification version during evaluation rather than assuming 1.2 is the newest release.

Bounded evaluation

• Compare a plain packet manifest with RO-Crate using a small, wholly synthetic submission packet; document the useful differences and maintenance cost.
• Map packet membership, exact manuscript version, known DOI/ORCID values, selected submission/round context, and existing integrity metadata without inventing identifiers or history.
• Define explicit preview and per-file inclusion. Exclude correspondence, reviewer identities, private notes, and absolute local paths by default.
• Keep export local and user-initiated; no automatic upload, publisher submission, or external file copying.
• Distinguish the software license from the researcher's content rights; never assign GPL to exported manuscripts by default.
• Represent missing dates or unknown rights explicitly; do not fabricate manuscript publication dates to satisfy packaging metadata.
• Validate one synthetic export against the selected RO-Crate version and verify that it can be understood without PaperRoute, while leaving source records and files unchanged.
• Record adopt/defer/reject and link any accepted implementation issue from the roadmap.

This complements packet preservation and reporting; it does not replace PaperRoute backup/restore or promise journal-system integration.