Target Convenience: Store Details of Construction as Metadata

[Scienfitz]

Stemming from a recent discussion with @dasmy as well as a recent bug introduced that was aimed at utilizing target bounds.

After the target redesign, some info about the construction is lost, or at least is implicitly transferred into the transformation object. This can be extremely inconvenient.

Examples:

• Obtain the interval in which a target variant has an influence (commonly referred to as bounds in the old target formalism)
• Classify targets whether they do maximization, minimization, or matching

Proposal:
While maybe not entirely impossible, it is extremely inconvenient to do this purely based on the transformation. Instead, it would be very helpful to have the context of the target creation stored for later usage in situations where that context is otherwise lost. This could mean for instance to remember

• what constructor has been used
• what keywords were passed to the constructor

These data could be stored as part of the already existing metadata entry

[dasmy]

Unsurprisingly +1 from me :-)

As discussed, I see a lot of potential/need for this considering the different roles of BayBE users:

• developers / optimization problem designers normally know what they set up or can read in their code wile creating an app / a solution for a specific problem
• users of that app / solution however do not have a straightforward possibility to obtain information on the specifities of the set up problem: With the current capabilities it is very cumbersome to generically show the user the mentioned properties of targets as they cannot be retrieved easily.

Also, BayChem-like frontend that allow for interactive configuration / storing / loading of BayBE setups will definitely benefit from the ability to retrieve the settings used to create a specific setup.

[dasmy]

Further thinking about this, you might consider instead of putting the construction information into the user-defined metadata (i.e. whatever is available via metadata.misc (https://emdgroup.github.io/baybe/stable/_autosummary/baybe.utils.metadata.Metadata.html#baybe.utils.metadata.Metadata.misc), in the end, to add another field to the Metadata class e.g. like metadata.details to store all construction parameters / type info, etc.

This would avoid any kind of interference with actual user-defined metadata.

[AdrianSosic]

I also thought about this problem a while ago and agree that we probably need a solution for it. I guess we all have the same kind of uses cases in mind, namely for example to access the match value or similar infos that were used for construction but are then available only implicitly in the resulting object, right?

My only concern is that we may probably want to do this is a type-safe approach, because most of the times we'd like to access these attributes programmatically. So for example, having to do checks like if (match_value := target.metadata.details.get("match_value", None) would be rather annoying and inelegant, I think. And storing them directly as attributes (e.g. metadata.details.match_value) also doesn't make sense because they don't always exist.

So I'm wondering if it make sense to somehow either classify the targets either according to their "semantic type" or according to the used construct type, i.e. either having an enum for the constructors or an enum for the target type, that is then explicitly set. This would then allow us to access the info more programmatically 🤔 Perhaps we should think it through a bit more thoroughly before we just dump everything into a dict.

[Scienfitz]

wouldt a type safety here be a big pain due to the large variety constructors and signatures?

I think having this stored in a non-type safe way is still substantially better than not having it stored at all like currently.

[AdrianSosic]

Unclear, but we can go incrementally, if you prefer. A simple half-way approach would be to at least type the context, perhaps. Something like adding an additional field, e.g. constructor or named appropriately, either to the metadata field or perhaps even as direct attribute (not sure yet what makes more sense here) and then make this similar to:

@dataclass
class ConstructorContext  # <-- or similar name
    name: str
    args: tuple[Any]  # <-- or perhaps kwargs, or both

Or if you want to go really low effort, do the dict approach as you proposed, but I would then request having the option to refine this further later if needed (i.e. experimental feature, if you will)

[Scienfitz]

@AdrianSosic I assigned you here as I think you have the most concrete ideas and requirements for metadata, I will take over other tasks in the 0.14.2 milestone

[AdrianSosic]

I'm on it