Discussion about ParticleID metadata

[tmadlener]

This came up in a discussion with @BrieucF and @saracreates. Before diving too far into an implementation, I would like to see what people prefer from an interface / usage point of view.

TL;DR: We need an easy way to access ParticleID related metadata that makes using the PIDHandler in algorithms easily possible. Main question: Do we want another service specifically for this or can we adapt the metadata svc?

---

EDM4hep has some utilities to conveniently write particle id related metadata, e.g. algorithm and parameter names associated with a given ParticleIDCollection. These utilites are defined in edm4hep/utils/ParticleIDUtils.h. On a very basic level they are just some fancy wrappers around Fame parameters that use a naming convention to store the collection level metadata. If the metadata follow these conventions it is easy to construct a edm4hep::utils::PIDHandler which can then be used to more easily retrieve the metadata, but also to directly access the correct algorithm and / or specific parameters for an algorithm. The utilities all effectively assume that they have access to a Frame, but the API can also be used with the edm4hep::utils::ParticleIDMeta to pass the necessary metadata in.

It is currently already possible to mimic what the utilities are doing by just carefully putting the necessary metadata into the MetadataSvc. However, this is rather error prone, and I would ideally like to hide this from the users.

There are several possible approaches

• We could change the IMetadataSvc interface to also have a put overload that takes an edm4hep::utils::ParticleIDMeta and also add either a template specialization to get or add a getAlgoInfo (or similar) that returns a std::optional<edm4hep::utils::ParticleIDMeta>.
• We could introduce an entirely new service, e.g. ParticleIDMetadataSvc that offers only this specific functionality.
• We open the IMetadataSvc to give access to it's internal Frame and people could use the EDM4hep utilities directly.

For me the third option is not really on the table, since we explicitly wanted to avoid the direct access to the Frame.

The first option would be pretty straight forward to add, since we have access to the metadata Frame inside the IMetadataSvc and can simply call the EDM4hep utilities from there. The second option sounds like the cleanest solution, but it would need to integrate with the metadata service in any case, and I am not sure how many dedicated small services we want. From a usage point of view these two would probably be very similar as the interface would still work mostly with the ParticleIDMeta that needs to be prepared by the user and then we can hide the call to the EDM4hep utilities inside the service. I think if we make option one have a template specialization for get even the interface could be the same, so it would mainly be a matter of which service to use in the end.