TeV update of the note

[bkhelifi]

co-authors: @mservillat , @bkhelifi

Description

This issue describes the update of the draft in link to the VHE data. It permits to include the discussions in the issue #4 and #5.

The upgrades of each section have been split into different PR in order to facilitate the review process. And we propose a slightly updated structured of the section. Here are the details:

• Section 1, Introduction: Update of the Section1, Introduction #11
• Section 2, High Energy Astrophysics Data: Update of the Section 2, High Energy Astrophysics Data #12
• Section 3, ObsCore Attribute Definitions for High Energy Astrophysics Data: Section 3 (take over Matthieu's PR) #18 (based on Update of the Section 3, ObsCore Attribute Definitions for High Energy Astrophysics Data #16)
• Section 4, Extensions to ObsCore Specific to High Energy Astrophysics Data: Update of the section 4, Extensions to ObsCore Specific to High Energy Astrophysics Data #13
  • Add of event_type
• Section 5, Vocabulary Enhancements: Section 5 (take over the Mathieu PR) #19 (based on Updates of the Section 5: 'Vocabulary Enhancements' #17)
  • a new sub-structure is proposed:
    • 5.1: Evolution of the Data Product Type vocabulary
      • With the subsubsections: Event list, Response functions, Event bundle, Advanced data products, Summary table, Clarification of ``flux'' in some term definitions
    • 5.2: DataLink vocabularies
    • 5.3: UCD Enhancements : See Implement comments associated to UCDs #25
      • With the subsubsections: Pulse Height, Electromagnetic spectrum description in UCD, Event Type, Particles, Statistical UCDs, Evolution of UCD list
    • 5.4: MIME-type Enhancements
• Section 6, Proposal for the ivoa.obscore_he attributes: Update of the section 6, Proposal for the ivoa.obscore_he attributes #14
• Section 7: Do we need a Summary section???
  • @iannevans will start writing this section
• Appendix A, Detailed Science Use Cases for ObsCore: Update of the Appendix A #10
  • Many adds of VHE Use cases
  • Feedback from Mireille and François would be very welcome;)
• Appendix C, Contributions to the note: Update of the Appendix C #9

This issue is including comments form #5 , #4 and #2.

Review

Review from the whole HEIG group is kindly asked.

For information, the merging order should follow the section order, to minimize merge conflicts

A global editing check after all PR merges might be required.

[iannevans]

Hi folks,

Here are the updates to the current preview version that I see are needed. While many of these are typographical or grammatical corrections, there are a number of more substantive issues. These can largely be identified in the list below because they span multiple lines.

Thanks,
--Ian

• Abstract - Update abstract

• Section 1 - Spell out High Energy Astrophysics the first time HEA is used.

• Section 2 - Generalize - don't limit to photons, cosmic rays, neutrinos.

• Section 2 - HE or HEA?

• Section 2 - Correct footnote 3 to not use the term "aperture photometry" (the correct term is "signal integrating").

• Section 2 - Move up footnote 7 about not using "IRF" in a normative sense to the first time we use "IRF".

• Section 3 - 2nd para needs a grammatical rework.

• Section 3.1 - "Obscore" -> "ObsCore"; "IVOA vocabularly is of Product Types" -> "IVOA Vocabulary of Data Product Types"; ``event'' -> {\bf event}; ``event-list'' -> {\bf event-list}.

• Section 3.1 - We need to tweak the last sentence of the definition of event-bundle. "Data in an event-bundle may thus be used to produce higher level data products such as images or spectra when containing IRFs." The last 8 words are the issue, since they imply that the event-bundle must contain IRFs in order to produce data products such as images or spectra, and this is not the case. For example, in X-ray one can typically produce images and counts spectra without IRFs at all. Furthermore, an event-bundle might include ancillary data products that allow the user to construct responses needed to produce higher level data products, rather than the responses themselves. How about "Data in an event-bundle may thus be used to produce higher level data products calibrated in physical units when containing IRFs or other data products that can be used to construct IRFs."?

• Section 3.1 - Remove extraneous "particle-detection".

• Section 3.1 - "i.e." -> "{\em i.e.\/}".

• Section 3.1 - Fix inconsistent bolding in section on measurements.

• Section 3.1 - Fix extraneous vspace before last para.

• Section 3.3 - "response-funtions" -> "response-functions".

• Section 3.3 - "we suggest" -> "we {\em suggest\/}".

• Section 3.4 - "response functions" -> "{\bf response-function}s".

• Section 3.7 - "we recommend" -> "we {\em recommend\/}".

• Section 3.7 - "we suggest" -> "we {\em suggest\/}".

• Section 3.8 - "we recommend" -> "we {\em recommend\/}".

• Section 3.8 - "we suggest" -> "we {\em suggest\/}".

• Section 3.9 - "we recommend" -> "we {\em recommend\/}".

• Section 3.9 - "we suggest" -> "we {\em suggest\/}".

• Section 3.10 - "(and {\bf event-bundle}s," -> "(and {\bf event-bundle}s),".

• Section 3.10 - "that is likely not be necessary," -> "that is likely not necessary".

• Section 4.2 - "both spatial resolution and sky coverage, and spectral resolution," -> "spatial resolution, sky coverage, and spectral resolution".

• Section 4.3 - Add last sentence "We recognize that performing such queries will require enhancements to ADQL, but this capability is sufficiently important for some HEA data discovery scenarios that we have chosen to add {\em t\_intervals\/} in anticipation that ADQL will eventually provide this functionality."

• Section 4.5 - Add sentence to the end of 1st para "For example, the {\em Chandra\/} ACIS instrument typically produces {\bf event-list}s with 2-dimensional spatial coordinates ({\em i.e.\/}, imaging) but has an observation mode that continuously reads-out the detector, effectively producing an {\bf event-list} with a single spatial dimension (and the other spatial dimension is collapsed); users looking for imaging data would want to restrict their queries to exclude the latter observing mode."

• After section 4.5 - Reinstate prior section 4.6 scan_mode. Our proposal is supposed to generally represent the entire HEA facility community, not just CTAO and Chandra. Just because CTAO and Chandra happen to not support scans per se does not mean that other facilities don't or won't (e.g., eROSITA). Add "\subsection{{\em scan\_mode}} Some HEA facilities can obtain observations using different spatial scan modes ({\em e.g.\/}, target pointing, spatial scans [including raster scans], and so on) that will affect the content of the observation. We propose to add an optional attribute {\bf scan_mode} that allows the data provider to specify the scan mode for an observation. Constraints on scan mode can provide a simple way to discover data sets for a specific facility/instrument combination. We note that permissible scan_mode values may vary from facility to facility and from instrument to instrument."

• Section 4.7 - "{\em event-bundle\/} -> "{\bf event-bundle}".

• Section 4.7 - "more than one are applied" -> "more than one is applied".

• Section 4.7 - "will vary" -> "may vary".

• Section 4.8 - First sentence is unclear and must be re-written for clarity. What does "event partitioning based on a data analyis quality associated with the reconstruction and the discrimination" mean?

• Section 4.8 - "partitionning" -> "partitioning".

• Section 4.8 - Last sentence of first para is unclear. "And for each" -> "For each"; what does "should be derived" mean in this context?; what does "and can be render public" mean?

• Section 4.8 - Why is this called "event_type" if it only specifies a data quality flag? Can "event_type" be defined more generally, with data quality being just one example?

• Section 4.8 - "will vary" -> "may vary".

• Section 4.9 - Delete this section, which is irrelevant to the HEA Extension. This section simply reiterates completely the content of section 4.22 of the IVOA ObsCore Recommendation, which is the overarching document.

• Section 5 - Fix inconsistent heading capitalization in all subsection heading throughout this section.

• Section 5.1.2 - "indictate" -> "indicate".

• Section 5.1.2 - Reorder the entries in alphabetical order for consistency with the table ins Section 5.1.5 (consider keeping response-function first).

• Section 5.1.2 - Eliminate footnote 10 on aeff and instead add the reference to Deil and Wood 2022 for consistency with the other entries.

• Section 5.1.3 - We need to tweak the last sentence of the definition of event-bundle. "Data in an event-bundle may thus be used to produce higher level data products such as images or spectra when containing IRFs." The last 8 words are the issue, since they imply that the event-bundle must contain IRFs in order to produce data products such as images or spectra, and this is not the case. For example, in X-ray one can typically produce images and counts spectra without IRFs at all. Furthermore, an event-bundle might include ancillary data products that allow the user to construct responses needed to produce higher level data products, rather than the responses themselves. How about "Data in an {\bf event-bundle} may thus be used to produce higher level data products calibrated in physical units when containing IRFs or other data products that can be used to construct IRFs."?

• Section 5.1.4 - "(with {\em calib\_level\/} $\ge 3$ that" -> "(with {\em calib\_level\/} $\ge 3$) that".

• Section 5.1.4 - "({\em i.e.\/}, they can be equally applicable to UV/optical, IR, and radio datasets:" -> "({\em i.e.\/}, they can be equally applicable to UV/optical, IR, and radio datasets):"

• Section 5.1.4 - Fix inconsistent bolding in section on measurements.

• Section 5.1.5 - Fix column spacing in table (columns currently overlap). Convert table to landscape.

• Section 5.1.5 - Ensure descriptions in the table are consistent with the definitions elsewhere in Section 5 (not currently the case).

• Section 5.1.6 - Fix bulletized list; better representation of units using mathematical representations with real exponents etc., rewrite TeV to SI, correct interpretation of counts as particles (thery are not the same), last bullet is end of sentence.

• Section 5.1.6 - "And these are not all covered by UCD vocabulary." -> "These are not all covered by the UCD vocabulary.".

• Section 5.1.6 - "Janskeys" -> "Jansky"; rework this sentence.

• Section 5.1.6 - Last para - the proposed restatement does not work! Counts are not particles. For example, in X-ray astronomy, estimating a photon flux in an energy band from a counts flux requires application of the responses. So the proposed definition would not allow one to call (e.g.,) count rate vs. time a "lightcurve" or counts vs. channel a "spectrum" but these are common usages in HEA. We could suggest changing the descriptions in the Data Product Type vocabularly to be "Flux of an observable or physical quantity, or magnitude" in each case, but a better alternative would be to define "Flux" as "The rate of flow of an observable or physical quantity passing through a given surface." However, at this time I don't think the IVOA has a Vocabulary for such definitions, so I think we will have to go with updating the descriptions in the Data Product Type vocabulary.

• Section 5.2 - What does "we proposed to show" mean?

• Section 5.3.1 - Delete last paragraph which is a duplicate of the last sentence of the previous paragraph.

• Section 5.3.4 - This is too vague and must be refined or deleted.

• Section 5.3.5 - First paragraph is too vague and must be refined or deleted.

• Section 5.3.5 - Second paragraph is too vague and must be refined or deleted.

• Section 5.3.6 - Table 2 should note em.gamma.hard is a redefinition of an existing UCD; how does phys.particle.energy differ from existing UCD phys.energy?; how does phys.particle.electron differ from existing UCD phys.electron?; "stats.error.negative" -> "stat.error.negative"; "stats.error.positive" -> "stat.error.positive"; stat.upperlimit, stat.lowerlimit both need more clear descriptions than "Upper limit" or "Lower limit"; stat.confidenceLevel is already a defined UCD and should be deleted; stat.likelihood.profile needs a more clear description, do you mean stat.likelihood.distribution?; phot.strcount again you are confusing counts and particles but phot.strcount described as "Flux expressed in counts per steradian" is somewhat defensible and follows on from existing UCD phot.count (but would it be phot.count.str ?); phot.diffcount again you are confusing counts and particles but if you want a differential count flux density then following from existing phot.flux.density UCD formats wouldn't you define phot.count.density and then phot.count.density.diff described as "Differential flux density expressed in counts (per wl/freq/energy interval)"?; phot.strflux, phot.enflux should similarly follow on from phot.flux as something like phot.flux.str and phot.flux.density.en; remove units specifications as section 1.1 of the IVOA UCD Recommendation specifies that "A UCD does not define the units nor the name of a quantity".

• Section 5.3.6 - Table 3 delete; section 1.1 of the IVOA UCD Recommendation specifies that "A UCD does not define the units nor the name of a quantity".

• Section 6 - Fix heading bolding.

• Section 6 - "Obscore" -> "ObsCore".

• Section 6 - Add a table number and title; general clean-up: change column names to italic for consistency; italicize e.g., i.e.; consider alphabetizing; consider landscaping.

• Section 7 - Do we need? Neither the ObsCore Recommendation nor the radio or time extensions include a summary section?

• Glossary - Good time interval, Stable time interval should have leading capitalization.

• Appendix A - Change all ivoa.obscore_he to ivoa.obscore_hea for consistency with Section 6.

• Appendix A.1.2 - add third constraint "(iii) ev_xel >= 1,000,000".

• Appendix A.1.3 - fourth constraint should be on a new line and identified as (iv).

• Appendix A.1.4 - "downloadedcatalog: -> "downloaded catalog".

• Appendix A.1.5 - "Find the CTAO dataset satisfying:" -> "Find CTAO datasets satisfying:"; is the constaint on obs_id = 4374 really supposed to be here (looks like a caryyover from the previous use case)?; change line splitting to avoid truncation.

• Appendix A.1.7 - Missing several constraints in the textual description.

• Appendix A.1.8 - Change line splitting to avoid truncation; should there be follow-on to last sentence (similar to A.1.9)?

• Appendix A.1.9 - Missing WHERE; should "10e+12" be "1.0e+12"?; clean up follow-on (# To Be Checked).

• Appendix A.2.2 - obs_collection in query does not match obs_collection in description, which one is correct?; instrument_name in query does not match instrument_name in description, which one is correct?; is the \ correct in the CAST statements?

• Appendix A.2.3 - Add comment to the effect that ADQL for intersecting a TMOC does not currently exist so the syntax is undefined.

• Appendix A.2.4 - The dataproduct_type = "image" specification in the description is inconsistent with the query.

• Appendix C - "IVOA HE group" -> "IVOA HEIG".

• Remove "It" at the start of a sentence and rewrite everywhere!

That's all folks!

[iannevans]

That's all folks!

Well, actually one more thing I was thinking about last night ...

Section 5.3.1 - For pulse height we proposed UCD phys.pulseHeight largely based on the fact that UCD was previously proposed (but not approved) in VEP-UCD-023. However, on reflection I wonder whether phys.pulseHeight is appropriate or whether the UCD should really be instr.pulseHeight? The reason for this is that pulse height (PHA, PI, etc.) is an instrumental measurement rather than a physical quantity. All of the defined "phys" UCDs appear to refer to true physical values, while the set of "instr" UCDs includes other values (such as instr.obsty.seeing, instr.skyLevel, instr.skyTemp) that are instrumental measurements of physical quantities, similar to pulse height.

[esabol]

I don't think non-approved UCDs should be used unless you are confident you can get them approved. That means updating the UCD spec, which hasn't been done in a long time, I think. Just going by memory here.

[esabol]

Yeah, the list of UCDs hasn't been updated since 2018.

I feel an approved UCD that would be appropriate is instr.param, which isn't very descriptive, I admit.

[iannevans]

I don't think non-approved UCDs should be used unless you are confident you can get them approved. That means updating the UCD spec, which hasn't been done in a long time, I think. Just going by memory here.> Yeah, the list of UCDs hasn't been updated since 2018.

Agreed - I don't think anyone would plan on using non-approved UCDs. However, the purpose of the HEA ObsCore Extension and Data Discovery PEN is for the High Energy Interest Group to propose the updates needed to support meaningful discovery of HEA data, and proposing updates to the UCD list is one aspect of this.

I feel an approved UCD that would be appropriate is instr.param, which isn't very descriptive, I admit.

instr.param is not useful for these data discovery use cases.

[esabol]

[...] proposing updates to the UCD list is one aspect of this.

Well, OK then. Fwiw, I agree that instr.pulseHeight would be better than phys.pulseHeight.

[msdemlei]

On Wed, Aug 27, 2025 at 08:18:48AM -0700, Ed Sabol wrote: esabol left a comment (ivoa/HighEnergyObsCoreExt#15) Yeah, the list of UCDs hasn't been updated since 2018.

Oh, no, the UCD list is regularly updated. It just has switched to being an endorsed note (and we hope to move it to a plain vocabulary later). See https://ivoa.net/documents/UCD1+/20241218/ for the current state.

[esabol]

Well, a PDF is 100% useless for this. Seriously. What are people who need a list of approved UCDs for validation purposes supposed to do? Parse the PDF? The list of approved UCDs needs to be a plain ASCII text file, and I recommend asking the CDS to update the list at https://cds.unistra.fr/UCD/ucd1p-words.txt, which hasn't been updated since 2018, according to their web page.

Sorry, this is all beyond the scope of the High Energy ObsCore Extension, of course.

[molinaro-m]

@esabol you can find the text file list here: https://github.com/ivoa-std/UCDList

There are mailing list to raise questions and get information from.

[esabol]

@esabol you can find the text file list here: https://github.com/ivoa-std/UCDList

Well, that's good to know. Thanks for the link. But how is this GitHub repository supposed to be discoverable? There's not a single instance of "github" in the UCD PDF at https://ivoa.net/documents/UCD1+/20241218/.

[molinaro-m]

You are right, it's hidden, and the files exist also on ivoa.net/documents.
I'll ping IVOADoc for a solution.

In the meantime, in appendix E there's the list of associated files, as I said, quite hidden.

[msdemlei]

On Wed, Aug 27, 2025 at 09:00:54PM +0000, Ed Sabol wrote: esabol left a comment (ivoa/HighEnergyObsCoreExt#15) > ***@***.***(https://github.com/esabol) you can find the text file list here: https://github.com/ivoa-std/UCDList Well, that's good to know. Thanks for the link. But how is this GitHub repository supposed to be discoverable? There's not a single instance of "github" in the UCD PDF at https://ivoa.net/documents/UCD1+/20241218/.

Well, it's better this way because that file is HEAD, i.e., changes with the development of the UCD list. The "release" files are on ivoa.net; see appendix E of the UCD list. Except I notice that these files have not been installed. Bummer. I'll try to get this fixed. But then: All this is hacky anyway. What we should be working towards is making the UCD list a normal IVOA vocabulary. There is a PR that would cover the technical side, ivoa-std/Vocabularies#31, but there is substantial political pushback about this. Asking for something like that on the semantics mailing list might help moving that along.

[iannevans]

In some of my comments to section 3.1 and section 5.1.3 I wrote

How about "Data in an event-bundle may thus be used to produce higher level data products calibrated in physical units when containing IRFs or other data products that can be used to construct IRFs."?

but this doesn't read clearly.

Instead, how about "Data in an event-bundle may thus be used to produce higher level data products calibrated in physical units if the event-bundle includes IRFs or other data products that can be used to construct IRFs."?

[loumir]

Discussing what to add as data products type in the VO framework :
It seems clear to me that all proposed data products can be listed in ivoa.net/rdf/ product-type table.
But the problem I have is that the axes along which the data spans may be different if I consider an observed image example HST image , and a PSF image used for calibration .
The span axes considered in the ObsCore data products are s, em, t, pol, observable.
this is ok for HST .
The PSF information can be delivered as a 1D function ( lsf , as for spectra, a 2D image or 2D+lamba cube) and the observable is a percentage for instance .
So it becomes difficult to compare the retrieved datasets collected in the response if we just write , for instance
select * from ivoa.obscore
where data product_type : 'psf'
and obs_collection like 'XMM'

we need to select first the s, em, t, pol, etc axes from a primary obscore data product , to restrict the search, and then use the linked data proposed in the service , namely via a datalink service.
Advanced data products of Chandra , like draws , pdf , regions do not match with the nature of an observed data set considered in Obscore .
They seem , as far as I understand , to be computed from data products already calibrated. I understand they bring valuable information on the scientific usage the user can expect , from the statistical properties analyses on theses results .
To me , these data products belong to refined datasets for data analysis. so to a calibration, analysis data base.
They offer new selection criteria among specialized indicators of the specific content of Chandra data, based on the specific analysis workflow .
how are they examined , compared? visually ? computationally? compared to a threshold ? etc.

I am not convinced we can directly compare the representation of pdf data advanced products across several archives .

Probably an example of two data collections from different projects distributing 'pdf' probabilities data should be shared here to clarify this.

If "draws", "pdf" , "regions" would be data products distributed in a calibration/analysis specific table 'Chandra.cal' , we must consider what is the cardinality of the relationship between a draws data product and the calibrated observations in the obscore table.
can we have several draws , or pdf d.p applicable to one event-list?
is the relationship 1..1 , N..1, or N..M?

Sorry for so many questions about how the observed data are logically connected to the other dataset carying the probabilistic behavior and quality indicators.

[iannevans]

Discussing what to add as data products type in the VO framework : It seems clear to me that all proposed data products can be listed in ivoa.net/rdf/ product-type table. But the problem I have is that the axes along which the data spans may be different if I consider an observed image example HST image , and a PSF image used for calibration . The span axes considered in the ObsCore data products are s, em, t, pol, observable. this is ok for HST . The PSF information can be delivered as a 1D function ( lsf , as for spectra, a 2D image or 2D+lamba cube) and the observable is a percentage for instance . So it becomes difficult to compare the retrieved datasets collected in the response if we just write , for instance select * from ivoa.obscore where data product_type : 'psf' and obs_collection like 'XMM'

That is already the case for data product types already supported by ObsCore. For example, as described in ObsCore section 3.3.1, for dataproduct_type = 'cube' the axes could be "a spectral image cube, a polarization cube, a full Stoked radio data cube, a time image cube, etc." One cannot simply compare retrieved cube datasets easily, unless the number and types of the cube axes are consistent. Even if one considers 'image', there are many possible different organizations of the image data depending on the facility and instrument. For example, multi-CCD instruments may merge the data into a single FITS image HDU, while others might separate the individual CCD images into multiple HDUs (sometimes this will depend on the calibration level); some images may have EQ world coordinates but others may have coordinates defined in a co-moving frame for example.

we need to select first the s, em, t, pol, etc axes from a primary obscore data product , to restrict the search, and then use the linked data proposed in the service , namely via a datalink service.
Advanced data products of Chandra , like draws , pdf , regions do not match with the nature of an observed data set considered in Obscore . They seem , as far as I understand , to be computed from data products already calibrated.

We often need to specify spatial/spectral/temporal/polarization constraints for most queries (but not necessarily all queries - one may not want to provide constraints for some of these properties for example). However, I disagree that one would always want to use datalink to access such products. Users will want to retrieve many of these data products without first searching for what you term a "primary obscore data product", as most of these products stand on their own. They can generally be identified using spatial/spectral/temporal/polarization constraints just like any other data product, and just need an appropriate dataproduct_type and other constraints as appropriate as part of the query, as the examples in Appendix A.2 of the draft PEN illustrate.

Again ObsCore already supports similar data product types, as illustrated by ObsCore section 3.3.1, for dataproduct_type = 'sed', which is another type of "advanced data product" that may (mostly will since you can't typically construct an SED from a single observation) be "produced by combining data from multiple observations".

I understand they bring valuable information on the scientific usage the user can expect , from the statistical properties analyses on theses results . To me , these data products belong to refined datasets for data analysis. so to a calibration, analysis data base. They offer new selection criteria among specialized indicators of the specific content of Chandra data, based on the specific analysis workflow . how are they examined , compared? visually ? computationally? compared to a threshold ? etc.

To me they are no different from advanced data products with calib_level >= 3 (such as 'sed') that the ObsCore claims to support (e.g., calib_level = 4 corresponds to "Analysis data products generated after some scientific data manipulation or interpretation" [ObsCore section 3.3.2]). I also note that ObsCore (section 4.4) states "some advanced data products (with calib_level >= 3), the data product may be the result of combining data from multiple primary (physical) observations".

If these types of product are not intended to be included in ObsCore, then the REC would not mention "advanced data products" or support calib_levels > 2. However, these concepts are explicitly described in the ObsCore REC so ObsCore must support them.

I think the statement suggesting that these data products are limited to "Chandra data" are much too constraining. These are not Chandra-specific (or even HEA-specific) concepts. Use of probability density functions and MCMC draws to describe confidence distributions of measured or derived properties is very normal in modern astrophysics, and they are becoming common in many astrophysical analysis workflows. The Chandra Source Catalog (CSC) primarily uses probability density functions to describe photometric measurements of sources using a Bayesian X-ray Aperture Photometry technique. This is partly because X-ray astronomy is sensitive down to the extreme Poisson regime (our detection threshold is ~4-5 photons) where distributions can become distinctly non-Gaussian, but also doing so provides a simple method in principle to consider how uncertainties in the calibration products themselves (which are also derived from "observations") affect the derived photometry, and include those uncertainties in a robust manner. This is an area that is starting to be considered extensively in HEA.

As to how such products are used, they may be examined similarly to images, spectra, lightcurves, or any other data products. Some scientists may want to review them visually, while others will take them as input to computational algorithms. This depends largely on the type of analysis being performed. A significant fraction of CSC science is analysis of a single or a small number of sources, and these scientists are more likely to want to visually inspect the data products. A similarly large fraction of CSC science is what I term "catalog science" where large numbers of sources are analyzed as a set; in these cases the data products are typically used as input to computational algorithms, such as machine learning or AI.

I am not convinced we can directly compare the representation of pdf data advanced products across several archives .

As described above, that already is not be possible for many data products supported by ObsCore. I don't see anything in the ObsCore REC that states that the representations of data products from different archives with the same datatype must be directly comparable. If that were an ObsCore requirement then I expect that a large fraction of the data products currently served via ObsCore would not meet that requirement.

Probably an example of two data collections from different projects distributing 'pdf' probabilities data should be shared here to clarify this.

If "draws", "pdf" , "regions" would be data products distributed in a calibration/analysis specific table 'Chandra.cal' , we must consider what is the cardinality of the relationship between a draws data product and the calibrated observations in the obscore table. can we have several draws , or pdf d.p applicable to one event-list? is the relationship 1..1 , N..1, or N..M?

As I described earlier, none of these are Chandra-specific, or even HEA-specific concepts. They have much broader scope across all wavebands. As to cardinality, I would suggest that many-to-many is the best description, but that depends on your definitions. For example, a single event list will typically include many X-ray sources in the field of view, so (continuing to use our aperture photometry example) we could perform aperture photometry on each of the sources. But there may be multiple observations of a field, so we can also compute a composite aperture photometry probability density function for a source that uses data from multiple observations (for CSC, we typically do this after first performing a multi-band Bayesian Blocks analysis of the data to ensure that the source has consistent intensity and color). On the other hand, one could for example compute a single aperture photometry probability density function for the background level distribution on a single detector. However, probability density functions and draws can be computed for any measured property, so the cardinality depends on the type of probability density functions or draws being considered. For example, CSC computes draws for the aperture photometry (which are collapsed to form the probability density functions), but also computes draws for the position (+uncertainty) in the location of an X-ray source on the sky (so these are 2-dimensional). Probability density functions and draws are very general concepts.

Sorry for so many questions about how the observed data are logically connected to the other dataset carying the probabilistic behavior and quality indicators.

Happy to try to answer questions where I can.