Curation workflow gap #163

New issue

Open

opened 2025-10-27 19:23:10 +00:00 by mih · 1 comment

mih commented

2025-10-27 19:23:10 +00:00

(Migrated from github.com)

Use case: See if any records where submitted by anyone and accept them.

Approach: Loop over all inboxes, fetch all records, submit to collection via curator access.

Following this approach has one of two problems, either one requires using schema information rather than API information.

The issue is that in the end records need to be submitted to the right endpoint (type). But either I need to read the schema to infer the list of (inbox) endpoints to query from and submit to, or I need to query a generic endpoint and need to infer the type from the record.

What is the best/desired workflow here?

Use case: See if any records where submitted by anyone and accept them. Approach: Loop over all inboxes, fetch all records, submit to collection via curator access. Following this approach has one of two problems, either one requires using schema information rather than API information. The issue is that in the end records need to be submitted to the right endpoint (type). But either I need to read the schema to infer the list of (inbox) endpoints to query from and submit to, or I need to query a generic endpoint and need to infer the type from the record. What is the best/desired workflow here?

christian-monch commented

2025-10-28 07:58:30 +00:00

(Migrated from github.com)

What about adding a schema_type_auto-attribute (or a schema_type_curator-attribute) to all records that are returned via curator access? Curator access will:

always return schema_type_auto-attribute in records that are read via curator access
never store schema_type_auto-attribute in records that are written via curator access

This would support simple type determination of a record type. It would also support storing the record unmodified (via curator access).

The workflow would then include submitting the record to the correct endpoint (type).

We need to ensure that whatever attribute name we use is not defined in the schema itself. This could be checked on service startup.

What about adding a `schema_type_auto`-attribute (or a `schema_type_curator`-attribute) to all records that are returned via curator access? Curator access will: - always return `schema_type_auto`-attribute in records that are read via curator access - never store `schema_type_auto`-attribute in records that are written via curator access This would support simple type determination of a record type. It would also support storing the record unmodified (via curator access). The workflow would then include submitting the record to the correct endpoint (type). We need to ensure that whatever attribute name we use is not defined in the schema itself. This could be checked on service startup.