-
Notifications
You must be signed in to change notification settings - Fork 4
Description
many fields support giving a single value OR multiple values, mainly because the fields were mostly single values only in the past, and we extended them to be multiple values.
it is possible to support that with JSON-Schema, but ... in a way, from a data-model/IT/cleanliness point of view, it is not optimal.
so we could switch to support only multiple values, where the only down-sides would be:
- that people could not use the more simple single-value syntax anymore
- practically all the existing manifests out there would have to be adjusted or converted to the new version on the fly
The thing is that in TOML, especially the mutli-value syntax is very confusing to many people (including me),
so then it might be a good idea to think about switching back to YAML as the default format.
Examples from our schema
-
a single- or multi-values property (
cpcId):
https://github.com/iop-alliance/OpenKnowHow/blame/e59f7a037a740a0fd1738f4ceb89ff66ed4a305e/src/schema/okh.schema.json#L76C1-L88C8
this can be either a string,m or an array of strings -
a multi-values only property (
slots) - it always has to be an array (though in this case, supports two different kinds of values):
OpenKnowHow/src/schema/okh.schema.json
Line 263 in e59f7a0
"slots": { -
and then there are even these kind of properties (like here
licensor):
OpenKnowHow/src/schema/okh.schema.json
Line 913 in e59f7a0
"anyOf": [
It supports a single string, and array of strings, an "object" (something that has sub-properties, like first-name, last-name, email, ....), or an array of such objects.
This one will probably still look strange in the generated form, even if we only support multiple values
Relation to the Ontology
in the future, we want to generate the JSON-Schema from the ontology (OWL/RDF/Turtle or LinkML), but for now, the two are kept in sync manually, as good as possible.