Initial GHGA Registry Service (Apollo)

[Cito]

The Apollo epic aims at creating a first working implementation of the GHGA Registry Service.

[lkuchenb]

Thanks for the spec, great work!

Some things I would like to discuss in the meeting tomorrow:

• Why the temporary auth concept, is there a major overhead to go directly to the CRS from the start?
• Why do we need the pre-publish state? I could imagine validation to happen immediately at POST, i.e. no invalid data to be ever accepted. Data can be immediately processed and previewed as updates progress.
• Publications must be entirely dynamic with no ties to the study lifecycle other than that the corresponding study must exist (in any state). They also do not require an accession number, citing a citation makes little sense, was more of an artifact of embedding them in the metadata

Something else I realized we should be thinking about rather sooner than later is the global uniqueness of identifiers across all classes. Currently our ingress model does not require that (thus you have to specify class + identifier). Post-accession assignment this is currently guaranteed (yet we don't make use of it at the API level). Also, the idea was to transfer the user-specified aliases from the ingress data directly to the GHGA accessions in the future, which opens the question in how far we have to transition to making this a constraint in the ingress data.

[Cito]

Thanks for all the great input so far here and in separate discussions. I updated the epic spec accordingly for another round of review.

[TheByronHimes]

I thought the AltAccession events were published as outbox events. If this is true, then this will not work as currently arranged. The AltAccession is stored with id as the primary key, which means the event key will be set to id by hexkit.