Skip to content

Conversation

@bkhelifi
Copy link
Collaborator

This PR update the list of Use Cases:

  • EQ -> =
  • ivoa.obscore-hea -> ivoa.obscore_he
  • Add the TeV UC w and w/o DataLink, with the event_type, etc

@ Mireille and François: could you check the DataLink releated topics?

@bkhelifi bkhelifi mentioned this pull request Jul 25, 2025
10 tasks
@iannevans
Copy link
Collaborator

I would prefer to keep the nomenclature hea in ivoa.obscore-hea rather than changing to ivoa.obscore_he.

HEA ("High Energy Astrophysics") is well recognized as spanning the energy range from soft X-ray to the highest energies observed. However, HE ("High Energy") can be mistaken for a restricted energy band that covers just a part of that energy range. Since we want this extension to span the all of high energy astrophysics unambiguously I suggest keeping hea.

As to whether to use a "-" or an "_", I tried to follow other draft proposed obscore extensions although I note these have migrated somewhat. Draft 1.0 (2024-07-17) of the time extension I have uses "-" (see section 5 where it mentions "... different tables : ivoa.obscore, ivoa.time-obscore, ivoa.radio-obscore, ivoa.heig-obscore etc...), although draft 1.0 (2024-06-14) of the radio extension seems to use both ivoa.obscore_radio and ivoa.ObscoreRadioExtended in different parts of the document. Perhaps some standardization discussion would be beneficial?

@kosack
Copy link
Contributor

kosack commented Jul 29, 2025

I would prefer to keep the nomenclature hea in ivoa.obscore-hea rather than changing to ivoa.obscore_he.

I might be wrong, but sincewADQL is currently implemented in PostGRESql, it doesn't allow for column or table names to have hyphens in them. I agree with keeping the "A" though, we can just redefine the glossary entry for \gls{HE} to have "HEA" as the abbreviation everywhere.

\item dataproduct\_type = ``event-bundle''
\end{enumerate}

\begin{verbatim}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tip: if you want this to look nicer, use the minted package and then do:

% in the header
\usepackage{minted}
\usemintedstyle{friendly}

...

\begin{minted}{sql}
SELECT * FROM ivoa.obscore
NATURAL JOIN  ivoa.obscore_he 
WHERE
  (target_name = 'Cas A'  OR CONTAINS(POINT(s_ra, s_dec), CIRCLE, 350.8584, +58.8113, 0.16667) = 1) 
  AND (dataproduct_type = 'event-bundle')
  AND (ev_xel >= 1000000)
\end{minted}

Then you get nice syntax highliting like:

SELECT * FROM ivoa.obscore
NATURAL JOIN  ivoa.obscore_he 
WHERE
    (target_name = 'Cas A'  OR  CONTAINS(POINT(s_ra, s_dec), CIRCLE, 350.8584, +58.8113, 0.16667) = 1) 
    AND (dataproduct_type = 'event-bundle')
    AND (ev_xel >= 1000000)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great... I will make the editing in this direction ;)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunatly, the IVOA standard Makefile is using latexmk, and this is not compatible. To be checked later

@mbtaylor
Copy link
Member

It's true that the minus sign "-" is not a legal character in an ADQL identifier, while underscore "_" is (see ADQL 2.1 sec 2.1.5). So it's a good idea to avoid minus signs in table names, otherwise you'll have to mess with delimited identifers, e.g. ivoa."obscore-hea" which is not fun.

Copy link
Contributor

@kosack kosack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking if we expose data from existing IACT like HESS/MAGIC/VERITAS, it would be nice to show an example of using the analysis_mode or event_type (in the case of Fermi). That would be a good example of why we need those.

Also, a common use case for IACTs in particular would be to find all event-bundles for observations of a source that were taken at a zenith angle below 40 degrees, for example (since zenith angle affects energy threshold and PSF and other aspects). Is that possible with ObsCore? Or would that only be possible with specialized observatory-specific science archives? If not, what is the recommendation: to use the s_angres or energy_min values? If so, then are they specified sufficiently that they would give the same result? e.g. are we required (recommended?) to fill energy_min such that it is the threshold energy , vs some generic bracketing energy?

@bkhelifi
Copy link
Collaborator Author

I was thinking if we expose data from existing IACT like HESS/MAGIC/VERITAS, it would be nice to show an example of using the analysis_mode or event_type (in the case of Fermi). That would be a good example of why we need those.

I agree, this is why I made Use Case --- Search for SWGO event lists and their \glspl{IRF} for the event type very-good' in the region of Cygnus loop for a TeV spectromorphology study`

Also, a common use case for IACTs in particular would be to find all event-bundles for observations of a source that were taken at a zenith angle below 40 degrees, for example (since zenith angle affects energy threshold and PSF and other aspects). Is that possible with ObsCore? Or would that only be possible with specialized observatory-specific science archives? If not, what is the recommendation: to use the s_angres or energy_min values? If so, then are they specified sufficiently that they would give the same result? e.g. are we required (recommended?) to fill energy_min such that it is the threshold energy , vs some generic bracketing energy?

Indeed, the optional fields of a data release.... I forget to discuss that in the document. Very good point... Having a recommendation just for the IACT could be difficult to accept. But the notion of "optional fields proper to a data release", it might be great... I will discuss this point and if accepted I will add a UC.

@kosack
Copy link
Contributor

kosack commented Aug 1, 2025

Indeed, the optional fields of a data release.... I forget to discuss that in the document. Very good point... Having a recommendation just for the IACT could be difficult to accept. But the notion of "optional fields proper to a data release", it might be great... I will discuss this point and if accepted I will add a UC.

Some of those optional fields could also be standardized, since things like the horizontal coordinates (or air column density, or similar) are not specific to HEA instruments, but to any ground-based instrument.

@bkhelifi
Copy link
Collaborator Author

bkhelifi commented Aug 4, 2025

Some of those optional fields could also be standardized, since things like the horizontal coordinates (or air column density, or similar) are not specific to HEA instruments, but to any ground-based instrument.

If you have any concrete proposal, do not hesitate ;)

@bkhelifi bkhelifi merged commit 22b35ec into ivoa:main Aug 4, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants