TeV update of the note: includes most changes proposed by Ian #23
Conversation
In fact the latest version of UCD list is in UCD 1.6 : available on the ivoa.net/Documents/ page stat.likelihood.profile : more discussion needed to understand what can be the content of a column tagged by this proposed UCD. |
|
On Thu, Oct 09, 2025 at 02:09:51AM -0700, Mireille LOUYS wrote:
In fact the latest version of UCD list is in UCD 1.6 : available on the ivoa.net/Documents/ page
part Semantics [https://www.ivoa.net/documents/UCD1+/20241218/index.html](https://www.ivoa.net/documents/UCD1+/20241218/index.html)
The link has not been updated on the ivoa.net/rdf/ vocabularies
page . I will mention this in semantics group.
Ah, sorry. UCDs are still a special case, and there are no automatic
updates of their metadata [side note in case someone looks here
later: it's directly on the ivoa RDF repo, metadata is in
ucd/META.INF]. I'm now linking to the UCD EN landing page, so
there's less chance of getting things becoming badly out of date.
|
|
This PR being mostly minor corrections, it will be merged and further discussed in other issues. |
|
hanks for all this work. very minor comments (on the version circulated by Janet on Ocotber 28th 2025)
Section 3. It is nicely explained in Section 3 that changes are both proposed for the ObsCore standard, and for the Vocabularies documents. Maybe it’s worth restating this at the begining of Section 5 for clarity. On the use cases : E.g. A11 and A16 A18 and A19 refer to search for event lists, could be grouped (or next to each other) typos: very very minor : e.g., (comma missing after, I was recently it is required in american writing convention) page 6 : density funtion -> density function the hereafter modification proposal faces to the issue -> faces the issue page 12 : not not encode -> not encode Use case A.1.3 : to remove instrumetal -> to remove instrumental event-list table -> throughout the document sometimes the hyphen is not here, should be consistent through the note |
4 participants
Following the comment #15 (comment)
In issue #15
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.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/} ≥3 that" -> "(with {\em calib_level/} ≥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 cary over 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!