Cardinality of ContibutorBlock and OrganisationBlock for RaidoMetadataSchemaV1

[ardc-shorn]

We're going to production soon and the first version of the RaidoMetadataSchemaV1 needs to be locked down.

From a metadata schema (SRO's google doc) perspective:
We need to decide on the lower-bound for the cardinality of these two fields. Specifically, is it 0 or 1?

Mechanically:
This is implemented in the OpenAPI definition by declaring which fields are "required" for RaidoMetadataSchemaV1.

This controls what V1 raids look like to people who read raids, and most importantly: what is the minimum required data to mint a raid:

raido/api-svc/idl-raid-v2/src/raido-metadata-schema.yaml

Line 179 in 27c007c

required: [ metadataSchema, id, titles, dates, contributors, access ]

Current Raido definition of RaidoMetadataSchemaV1:

• ContributorBlock is required
• OrganisationBlock is not required

Current Metadata definition:

• ContributorBlock is required
• OrganisationBlock is required

We need to align these two definitions.

If we make these fields mandatory - anybody who wants to mint a raid via Raido must provide a contributor ORCID and an organisation ROR.

About the current state of PID support for Contributor and Organisation blocks:
The two blocks are limited to ORCID and ROR at the moment because that's all we've implemented.
It is unclear what other kind of values these fields might contain in the future.
It is currently not defined in the Metadata schema document which which PIDs will be supported long-term (or even if there might be non-pid values).

[ardc-shorn]

On the one hand, I think we should align with what the Metadata schema definition says (make them required).
On the other hand, the current OpenAPI definition of RaidoMetadataSchemaV1 is very different from the Metadata schema anyway (we're missing a lot of blocks).j

If we defined the blocks as optional right now, but want to change them to required later - that is a breaking change and will require a new RaidoMetadataSchemaV2 definition, a new set of endpoints and to go through the process of deprecating the RaidoMetadataSchemaV1. See https://github.com/au-research/raido/blob/main/doc/service-level-guide.md#stable-endpoints.

[saross]

My inclination is still to make both Organisation and Contributor required, so as to avoid breaking changes later. With, however, the expanded ID Block in the latest metadata version, which includes 'Identifier Owner' and 'Service Point', we don't strictly need an Organisation, as we know who to contact about the RAiD. So, if anyone else has a good reason not to make Organisation mandatory, we have a fallback and I'm willing to keep it optional.

[ardc-shorn]

Test reply via email.

…

On Thu, 9 Feb 2023 at 10:30, Shawn A Ross ***@***.***> wrote: My inclination is still to make both Organisation and Contributor required, so as to avoid breaking changes later. With, however, the expanded ID Block in the latest metadata version, which includes 'Identifier Owner' and 'Service Point', we don't *strictly* need an Organisation, as we know who to contact about the RAiD. So, if anyone else has a good reason *not* to make Organisation mandatory, we have a fallback and I'm willing to keep it optional. — Reply to this email directly, view it on GitHub <#18 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZUJVL6VDF4JLNXBD45UHHDWWQ3BBANCNFSM6AAAAAAUV4RLN4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ardc-shorn]

Neat, it worked.

If you have GitHub discussion email notifications switched on, you can just hit reply in your email client and GitHub will post it as a discussion response, as above.

[mpfl]

1. ORCIDs are easy to get - minutes.
2. RORs are hard to get - months.

It is fine to require an ORCID, but it is problematic to require a ROR.

I am ambivalent about requiring an organisation, but if we require an organisation we need to clearly document that every organisation referenced in a RAiD needs to have a ROR.

[saross]

I need to check my notes, but I believe we discussed the difficulty of getting RORs, and that we would need fall-backs for organisations (local tax IDs or something), at least as a temporary / interim step (e.g., to accommodate industry partners on grants). 'If your organisation has a ROR you have to use it' is fair I think.

[ardc-shorn]

Slack chat 2023-02-10 - SRO, RLE, STO.

SRO changed the metadata definition to not-required.

Raido RaidoMetadataSchemaV1 Contributors and Organisations fields will not be changed.

The Raido RaidoMetadataSchemaV1 IdBlock will be aligned with the metadata schema including adding 'Identifier Owner' and 'Service Point'.

Tracking issue: https://ardc.atlassian.net/browse/RAID-6