Generalized quantitiy attached to Tracks

[BrieucF]

We currently have

  edm4hep::RecDqdx:
    Description: "dN/dx or dE/dx info of a Track"
    Author: "EDM4hep authors"
    Members:
      - edm4hep::Quantity dQdx         // the reconstructed dEdx or dNdx and its error
    OneToOneRelations:
      - edm4hep::Track track           // the corresponding track

to attach dN/dx or dE/dx information to a track.

Given the generality of the Quantity object, and the fact that we want to attach more than just dQ/dx objects to tracks (e.g. emitted Cherenkov photon angles in a RICH like detector), I want to call for opinions on generalizing this. From a first quick look, it could potentially be as simple as renaming RecDqdx to something like TrackQuantity and dQdxto something like quantity.

[tmadlener]

My main question would be whether all the information cleanly fits into a edm4hep::Quantity which essentially is a value and an error. If that is not the case than we would need to discuss whether we want to generalize the RecDqdx to accommodate that information or whether we keep it and introduce more specific things for specific tracking devices.

Specifically for the RICH like detectors, is the photon angle (and their errors) the only thing we would like to store, or would we also like to add, e.g. a first PID estimate (which could also be added to dQ/dx, thinking about it..).

Do we have a collection of information already somewhere of things for some other tracking devices that we would like to store? I think it would be easier to go from something concrete here, rather than get lost in possibilities of abstract devices.

[BrieucF]

I have no immediate other use cases than the Cherenkov photon angles in mind, for which Quantity would be fine for what we want to do now. But I can indeed not anticipate all possible future needs.

Regarding the PID estimate, this could indeed be interesting to have because we might want to refit a track with the right particle hypothesis, without going through a RecontructedParticle. Nevertheless, I don't think this PID estimate would belong to the TrackQuantity object: a typical workflow would be that one algorithm derives the TrackQuantity and serves other algorithm(s) that derive ParticleID based on it. To align with the decisions taken for other similar situations, I would feel more natural to have a ParticleID that points to Track.