search

openMetadataInitiative / openMINDS_core

The openMINDS core metadata model includes schemas that can be used to describe the general origin, location and content of research products.
MIT License
20 stars 19 forks source link

Why do we have a minItems in "otherContribution"? #170

Closed olinux closed 3 years ago

olinux commented 3 years ago

I don't understand the requirement for minItems in "otherContribution", especially since the property is not required. I would argue an empty list as payload (although not nice) should not be invalid. Instead, it could be seen as an explicit "there is no other contribution" to differentiate from "not filled in"

https://github.com/HumanBrainProject/openMINDS_core/blob/802161ff8ac0ece09487a090ffb1dc15fc617a9f/schemas/products/researchProductVersion.schema.tpl.json#L111

lzehl commented 3 years ago

@olinux this was a decision we made a while ago. We introduced it consistently for all array types, but (if I remember correctly) out of the reason that for obligatory properties the empty list would pass the validator which is of course not what we want in that case.

Also consistently we introduced "uniqueItems" for array types (I think so far we do not have a case where we would explicitly allow non-unique items in an array)

UlrikeS91 commented 3 years ago

@lzehl, I think you misunderstood his suggestions. I think what @olinux is trying to suggest, is to actively remove this from just this one property so that you can explicitly express that there are no other contributions (since you need to actively add an empty contribution.

But I fear that we will run into some consistency issues (and general confusions). Explicitly expressing that there are no other contributions will look exactly like forgetting to fill in any fields in the schema for contribution. Humans make mistakes, and I can see how this could happen.

Additionally, to be consistent, we should then apply this logic to other properties as well. I’m sure there are others that could benefit from this logic. But this would also mean that we would need to train the curators (and all other openMINDS users) to understand the difference. It would be more user-friendly to stick to the simpler logic with required vs. optional, but when you fill in an optional property you actually need to have at least one (properly filled in) item. This will make the maintenance of the content much easier.

lzehl commented 3 years ago

@UlrikeS91 no I think I understood correctly. It comes back to consistency. Of course we could say all non required properties of type array do not have the "minItems": 1, because there the empty list is not really a problem, but would introduce a if/else logic which we always need to explain.

IMHO I would rather go with the consistent way: All properties of type array have to have at least one item (if the property is not required just do not use it).

The only reason to change this would be if a non required property technically is anyway required in the JSON-LD (with a null value). @olinux is that the case?

lzehl commented 3 years ago

@olinux is your question solved? (or is there still a technical issue with the previous decision on this that I did not understand, yet?)

lzehl commented 3 years ago

may reevaluated at a later point. we will close this for now.