Configuring metadata schemas

This page describes how metadata schemas are stored in Yoda, and how Yoda keeps track of what schema to use for each group.

Schema storage

Schemas are stored in iRODS collection /zone/yoda/schemas, with each schema having a separate sub-collection.

The internal structure of schemas

Each schema consists of two parts:

  1. A JSON schema that is used to validate the metadata of a data package (filename: metadata.json).

  2. A UI schema file that contains information for the web portal regarding how to display a form for metadata with this schema, optionally including placeholders and help text for each field. This information is stored in files named uischema.json.

A minimal schema is available as the core-1 schema.

Schema configuration

In Yoda, metadata schemas can be defined on three levels:

  1. On the environment level (the default schema)

  2. On the community (also known as the category) level

  3. On the group level (in Yoda 1.9 and higher)

The most specific level has priority. That is: a group will use its configured schema. If it does not have one, it will fall back to the community metadata schema. If the community has no configured metadata schema, it will fall back to the default metadata schema.

The default schema and community-level schema need to be configured by a technical admin (Surf or maybe ISSC a.t.m). They are stored in an iRODS sub-collection of /zone/yoda/schemas/. The default metadata schema is located in the default sub-collection, whereas the community-level schemas are stored in a sub-collection with the same name as the community. See https://universiteitleiden.atlassian.net/wiki/spaces/RIS/pages/2405793909 for instructions about how to replace a schema.

Group-level schemas are configured by the user who creates the group. The schema name is stored in the schema_id AVU that is set on the research group.

Â