VEP associated to the PHA

[bkhelifi]

Dear all,

Before starting the discussion into the Semantics WG, here is the VEP for the PHA.

You can see the state of the discussion here: https://voparis-gitlab.obspm.fr/vespa/ivoa-standards/semantics/vep-ucd/-/blob/master/VEP-UCD-015.txt

The proposal is to not create a new UCD, but user rather: "phys.electCharge;src.var.pulse;stat.uncalib". Any objection?

[msdemlei]

Me, I'm skeptical of complex UCD words that are so non-obvious that some

[iannevans]

Dear all,

Before starting the discussion into the Semantics WG, here is the VEP for the PHA.

You can see the state of the discussion here: https://voparis-gitlab.obspm.fr/vespa/ivoa-standards/semantics/vep-ucd/-/blob/master/VEP-UCD-015.txt

The proposal is to not create a new UCD, but user rather: "phys.electCharge;src.var.pulse;stat.uncalib". Any objection?

This suggestion makes no sense! It's very similar to the prior suggestion (src.var.amplitude;src.var.pulse;stat.uncalib) that we explicitly argued makes no sense in the draft HEIG ObsCore document (section 5.3.2).

PHA ("pulse height amplitude") is an instrumental quantity, and arguably one of the most important quantities in high energy astrophysics. That's why we proposed the UCD "instr.event.pulseHeight" as an instrumental quantity representing the pulse height of a detected event. We added the instrument.event hierarchy as common base for consistency because we also proposed "instr.event.grade" for event grade and "instr.event.type" for event type.

Now "src.var.pulse" is defined as "pulse" on top of "src.var" which is "variability of source" on top of "src" which is "observed source viewed on the sky" (definitions taken from the "UCD1+ Controlled Vocabulary" version 1.6). However, instrumental pulse height is a quantity that is present irrespective of whether there is an "observed source viewed on the sky". A significant contributor to pulse height is background, which may be astrophysical but is more often instrumental or derives from the environment in which the instrument is located (e.g., the local particle background in the vicinity of the detector - particularly relevant for space-based facilities). So "src.var.pulse" would not be appropriate in this context.

"stat.uncalib" is defined as "qualifier of a generic uncalibrated quantity" on top of "stat" which is "statistical parameters". But pulse height is not a statistical parameter! Pulse height is a precise measurement of the amplitude of a pulse. So "stat.uncalib" is not appropriate in this context either.

"phys.electCharge" ("electric charge", on top of "phys" - "physical quantities") may be appropriate, in the sense that the pulse height (which is a digital number, not a charge in Coulombs) is typically based on detected electrical charge. But then I could argue that other "instr" UCDs (e.g., "instr.det.noise" - "instrument noise", "instr.saturation" - "instrument saturation threshold", "instr.sensitivity" - "instrument sensitivity, detection threshold") should similarly be shoe-horned into fitting on "phys.electCharge" because ultimately they depend on the quantity of electric charge in some circuit in the detector. And that just doesn't make sense.

So yes I object most strongly! This proposal is wrong on a technical level. And pulse height is at least as important as quantity in high energy astrophysics as many other existing "instr" UCDs are in other wavebands.