Closed jbstatgen closed 1 year ago
Discussed at 16th Feb meeting.
tl;dr: every other field in ObjectGroup is an array except for this one, description
and collectionName
so fundamentally it makes no sense to have baseTypeOfCollection
standing alone as a single-value field, so we should change this to being an array fo strings. BUT, we need to make it clear in docs/recipes that if you model your OG with a lot of arrays, you're not going to be able to quantify any of those characteristics.
Can/Should we include this recipe in the CollectionDescriptionScheme Class or at least cross reference?
I think it should stay a single string, having multiple descriptions or names for a collection also does not make much sense and kind of defeats the purpose of unifying collection descriptions. If you need more than one term to describe the base type you are probably not using the right term?
Looking at the given examples (material samples, information artefacts), an array would make sense.
Updated to repeatable = Yes in csv.
https://github.com/tdwg/cd/blob/79070c8bbff1959d4f534290decd8bc3d638a03c/standard/json-schema/object-group.json#L18
Object groups might include entities of different basic types, e.g. physical objects (ie. MaterialEntities) and their associated photographs (ie. InformationArtifacts). This is especially the case for derived, compound object groups representing, eg. organization-wide collections.
Thus, we might consider to change the expected data type to be
array
instead ofstring
. See eg.collectionManagementSystem
, which is also a property withinltc:ObjectGroup
and has its data type set toarray
.