Metadata for Parameters/Targets

[dasmy]

Currently, parameters/targets only contain a name and some specific properties like bounds or possible values. However, it would be desirable, to allow for conveniently adding some metadata like description, unit, etc. to keep all information about a parameter in a single place and also ensure they are serialized properly. This would allow for making e.g. user interfaces like BayChem more user friendly and more versatile by enabling the tool to grab labels, descriptions, units, etc. e.g. from the deserialized Campaign.

I'd imagine and additional parameter in the constructor along the lines of

p = NumericalContinuousParameter(name="T1", bounds=(0, 100), metadata= {"comment": "water temperature", "unit":  "°C")

Here, metadata could be any kind of serializable object. In the case above, access to the metadata could be as usual:

print(p.name, p.metadata["comment"], p.metadata["unit"]

[AdrianSosic]

Hi @dasmy, thanks for the suggestion. I see how this could be useful for many users, especially when there are many objects involved / they want the actual names to be consistent with the cryptic identifiers one sometimes finds in real-world systems 👍🏼

I don't think there should be a big problem to enable this, but there is one design decision to be made: Parameters and targets are immutable, for good reason. I see that the metadata attribute could become an exception because – by definition – it should never affect any other parts of the system. But still, the question is: does it need to be mutable? Do you see any good reasons for/against?

Also, what is @Scienfitz's take?

[dasmy]

Honestly, I do not really see why the metadata that I thought of should be mutable as they would be mostly descriptive. Maybe others have different ideas, though.

[dasmy]

Just thought things a bit further: Possibly, it makes sense to allow adding metadata to many more (all?) serializable objects. E.g. also for constraints, the possibility to add descriptions/explanations might be useful. Similar for campaigns that - when stored to disk would benefit from allowing users to add descriptions/a time stamp etc. - Again, particularly tools like BayChem could considerably benefit from this as a serialized campaign would then be more like an actually self-contained project file.

Again: Metadata would be completely optional, type/content should be up to the user/developer (as long as it is serializable) and the field should be guaranteed to be ignored by BayBE itself.

[AdrianSosic]

I guess if we explicitly follow the paradigm user is responsible for metadata and also clearly state this premise in the docs, then we could potentially even less strict in terms of requirements. For example, we could even allow the metadata field to hold custom attrs/dataclass classes, since they can be natively unstructured with the existing serialization machinery. So next to regular dicts and type dicts (for a lightweight typed implementation), this would also enable attribute-based access to content 🤔

The other question is if/how to actually enforce serializability. I see two options:

• We don't enforce it --> responsibility again at the user end. If they want to serialize stuff, they better pass something that is serializable, otherwise they get a runtime error.
• We do enforce it, by actually testing for serializability at validation time and raising a validation error otherwise. Not sure if that is even necessary though.