From c368914d5558dafc96b3eb1fdd0b6dcee2509f5d Mon Sep 17 00:00:00 2001 From: Ian Nigel Evans Date: Fri, 4 Sep 2026 15:02:18 -0400 Subject: [PATCH] September 4 Final putbacks (1) Updated makefile date; (2) Minor tweaks for typos, grammar, or formatting; (3) Added recent Interop talks references to Contributions page. --- Dataproducts-Summary-table.tex | 2 +- HighEnergyObsCoreExt.tex | 29 ++++++++++--------- Makefile | 4 +-- UseCases.tex | 28 +++++++++--------- extendedAccessTonewtypesOfproducts.tex | 16 +++++----- ...ndedAccessTonewtypesOfproductsAppendix.tex | 12 ++++---- 6 files changed, 48 insertions(+), 43 deletions(-) diff --git a/Dataproducts-Summary-table.tex b/Dataproducts-Summary-table.tex index 14a2d76..fa091aa 100644 --- a/Dataproducts-Summary-table.tex +++ b/Dataproducts-Summary-table.tex @@ -36,7 +36,7 @@ \subsubsection{Summary Table} {\bf psf} &\raggedright Point Spread Function & A dataset that records the probability density function of spatial/angular spreading of incident particles from a point source caused by the instrument (detector and/or mirror and/or analysis) & \#response-function, \#pdf \cr \noalign{\vspace{20pt}} \hline -\multicolumn{4}{|r|}{{\bf Considered for addition to an IVOA Advanced Data Products Vocabulary}} \\ \hline +\multicolumn{4}{|r|}{{\bf Considered for addition to an IVOA Advanced Data Product Types Vocabulary}} \\ \hline \noalign{\vspace{6pt}} {\bf draws} & Draws & A dataset that records statistical draws computed from a probability distribution or a sample population, for example Markov chain Monte Carlo (MCMC) draws used when computing the Bayesian marginal probability density function for a random variable, or the DeltaTS associated with a quantity from a frequentist analysis & none \cr \noalign{\vspace{2pt}} diff --git a/HighEnergyObsCoreExt.tex b/HighEnergyObsCoreExt.tex index 4c36be3..312ef11 100644 --- a/HighEnergyObsCoreExt.tex +++ b/HighEnergyObsCoreExt.tex @@ -198,11 +198,11 @@ \subsection{{\em dataproduct\_type}} %\TODO{ mireille: Rewrite this paragraph to avoid measurements: no agreement exist for this term among ObsCore Implementors in practice. } %%% There is no way to rewrite this paragraph without referring to measurements. The term "measurements" is defined in the ObsCore Recommendation and this recommendation modifies the wording of that definition somewhat. The measurements concept is actually quite important as it's use avoids having to dramatically increase the the number of data product type terms one would otherwise require (some of which may be facility dependent). -Many different types of data products are served by \gls{HEA} facilities, including datasets that consist of generic tabular data (an {\bf hea-event-list} is in fact a {\em specific type\/} of tabular data). Some \gls{HEA} facilities require a {\em dataproduct\_type\/} that represents such generic tabular data. We note in passing that such a {\em dataproduct\_type} actually falls at the same level as ({\em e.g.\/}) the {\bf image} {\em dataproduct\_type\/}: an {\bf image} has two spatial axes, but the observable axis is not defined; while commonly the observable axis for an {\bf image} is flux, it could easily be ({\em e.g.\/}) color, spectral-index, significance, and so on, and additional refinement such as {\em dataproduct\_subtype\/} may be required to more precisely specify the nature of a data product. Some of these data products are essential for further data analysis or important in their own right, but may be uncommon across multiple facilities possibly because of the way the observations are obtained. +Many different types of data products are served by \gls{HEA} facilities, including datasets that consist of generic tabular data (an {\bf hea-event-list} is in fact a {\em specific type\/} of tabular data). Some \gls{HEA} facilities require a {\em data\-product\_type\/} that represents such generic tabular data. We note in passing that such a {\em dataproduct\_type} actually falls at the same level as ({\em e.g.\/}\null) the {\bf image} {\em dataproduct\_type\/}: an {\bf image} has two spatial axes, but the observable axis is not defined; while commonly the observable axis for an {\bf image} is flux, it could easily be ({\em e.g.\/}\null) color, spectral-index, significance, and so on, and additional refinement such as {\em dataproduct\_subtype\/} may be required to more precisely specify the nature of a data product. Some of these data products are essential for further data analysis or important in their own right, but may be uncommon across multiple facilities possibly because of the way the observations are obtained. In the ObsCore Recommendation Version 1.1, the {\em dataproduct\_type\/} {\bf measurements} is adequate for such generic tabular datasets. However, users of those products often may not be interested in the progenitor datasets, especially as some advanced data products may be derived from multiple observations, or multiple advanced data products may be extracted from the same single progenitor or a few progenitors ({\em e.g.\/}, advanced data products associated with multiple sources detected in a single observation field). Referring to the ObsCore Recommendation Version 1.1, we propose to delete the caveat associated with {\em dataproduct\_type\/} = ``measurements'' in the ObsCore IVOA Recommendation (\S~4.1.1) that requires the derived data products be exposed ``{\bf together} with the progenitor observation dataset''. The recovery of progenitor observation datasets may be achieved using provenance information, if desired. -In the \gls{IVOA} Data Product Type Vocabulary\footnote{\url{https://www.ivoa.net/rdf/product_type}.}, the term {\bf measurements} is described as ``Generic tabular data not fitting any of the other terms'' and that similarly matches what is needed here. While the description goes on to state ``Because of its lack of specificity, this term should generally be avoided, and new, more precise terms should be introduced instead.'', as indicated above there are circumstances under which doing so does not make sense. We are aware that there is currently a proposal to eliminate the {\bf measurements} data product type given it's previous loose definition. If that is done, then we would need a replacement, such as {\bf tabledata\/}, that can be used to represent generic tabular data, as there is no other data product type to represent this type of dataset. +In the \gls{IVOA} Data Product Type Vocabulary\footnote{\url{https://www.ivoa.net/rdf/product_type}.}, the term {\bf measurements} is described as ``Generic tabular data not fitting any of the other terms'' and that similarly matches what is needed here. While the description goes on to state ``Because of its lack of specificity, this term should generally be avoided, and new, more precise terms should be introduced instead.'', as indicated above there are circumstances under which doing so does not make sense. We are aware that there is currently a proposal to eliminate the {\bf measurements} data product type given its previous loose definition. If that is done, then we would need a replacement, such as {\bf tabledata\/}, that can be used to represent generic tabular data, as there is no other data product type to represent this type of dataset. \subsection{{\em dataproduct\_subtype}} @@ -392,7 +392,7 @@ \subsection{{\em messenger\_pdgid}} We propose to add an optional attribute {\em messenger\_pdgid\/} that specifies the PDG ID of the messenger type for an observation. Constraints on {\em messenger\_pdgid\/} can provide a simple way to discover data sets for a specific messenger with a finer granularity than is possible with the {\em messenger\_name\/} attribute alone. The value should be a string that specifies the messenger particle's PDG ID as `{\em $\pm$nn\/}' (where the sign is mandatory). For example, a muon, $\mu^{-}$, may be specified as `+13'. -The difference between {\em messenger\_name\/} and {\em messenger\_pdgid} is that ({\em e.g.\/}) a data discovery query that includes {\tt messenger\_name = `neutrino'} would enable the user to identify datasets with a neutrino (any kind) messenger particle, whereas a data discovery query that includes {\tt messenger\_pdgid = `+16' OR messenger\_pdgid = `-16'} would restrict the search to include only $\tau$ neutrinos ($\nu_\tau$) or antineutrinos ($\nu_\tau^{-}$). +The difference between {\em messenger\_name\/} and {\em messenger\_pdgid} is that ({\em e.g.\/}\null) a data discovery query that includes {\tt messenger\_name = `neutrino'} would enable the user to identify datasets with a neutrino (any kind) messenger particle, whereas a data discovery query that includes {\tt messenger\_pdgid = `+16' OR messenger\_pdgid = `-16'} would restrict the search to include only $\tau$ neutrinos ($\nu_\tau$) or antineutrinos ($\nu_\tau^{-}$). The downside of {\em messenger\_pdgid} is that PDG ID very unlikely to be recognized outside of the particle astrophysics and high energy particle physics communities. We choose to include both {\em messenger\_name\/} and {\em messenger\_pdgid} because the majority of astrophysicists --- even experienced high-energy astrophysicists --- are unlikely to recognize PDG ID\null. While any astrophysicist is likely to be able to write a query such as {\tt messenger\_name = `photon'}, very few would be able to cast that query as {\tt messenger\_pdgid = `+22'} from memory. @@ -512,7 +512,7 @@ \subsubsection{Response Functions} {\bf rmf}: A dataset that records the probability density function mapping from energy space into detector pulse height (or position) space \citep{ogip_spectrum_1998}. \end{quote} -These terms have been declared in coordination with the IVOA Semantics working group in a specialized IVOA data product vocabulary dedicated to response functions and available at \url{https://www.ivoa.net/rdf/response-type/}. +These terms have been declared in coordination with the IVOA Semantics working group in a specialized IVOA data product vocabulary dedicated to response functions, available at \url{https://www.ivoa.net/rdf/response-type/}. \subsubsection{Advanced Data Products} @@ -528,7 +528,7 @@ \subsubsection{Advanced Data Products} {\bf region}: A dataset that includes an encoding of (one or more) regions of parameter space, for example a spatial region or a region of phase space covered by a dataset. The set of dimensions represented by the region can be arbitrary. \end{quote} -An advanced-dataproduct-type Vocabulary \footnote{\url{https://github.com/ivoa-std/VEPs/pull/21/changes\#diff-25a867536b53bdb6848baeba09cfc4df1e4ad42da919d440902e57b917dd9abc}.} is proposed to the Semantics WG to register these terms in a standard vocabulary, that can be extended to other spectral domains, e.g radio astronomy. +An advanced data product type vocabulary\footnote{\url{https://github.com/ivoa-std/VEPs/pull/21/changes\#diff-25a867536b53bdb6848baeba09cfc4df1e4ad42da919d440902e57b917dd9abc}.} is proposed to the Semantics WG to register these terms in a standard vocabulary, that can be extended to other spectral domains, {\em e.g.\/}, radio astronomy. %mireille proposal for vocabularies @@ -541,7 +541,7 @@ \subsubsection{Clarification of ``Flux'' in Data Product Type Vocabulary Definit We propose to clarify the IVOA Data Product Type Vocabulary\footnote{\url{https://www.ivoa.net/rdf/product_type}.} definitions that use the word ``flux'' in the description of some terms, currently {\bf light-curve}, {\bf polarization-resolved-dataset}, {\bf polarized-spectrum}, and {\bf spectrum}, so that the definitions are applicable to \gls{HEA} data products. -The issue is that the term ``flux'' is not defined in the vocabulary, and the standard astronomical definition of ``flux'' is an energy flux (with SI units $\rm W\,m^{-2}$). This interpretation is bolstered by the statements ``flux or magnitude'' applied to several of the descriptions since optical/IR magnitude and energy flux density are tightly related. However, with this definition, many \gls{HEA} data products that may have fluxes defined using units of counts or particles ({\em e.g.\/}, photons), but not calibrated in units of energy, would not satisfy the current descriptions of ({\em e.g.\/}) {\bf light-curve} or {\bf spectrum}, even though that is how those products are used. +The issue is that the term ``flux'' is not defined in the vocabulary, and the standard astronomical definition of ``flux'' is an energy flux (with SI units $\rm W\,m^{-2}$). This interpretation is bolstered by the statements ``flux or magnitude'' applied to several of the descriptions since optical/IR magnitude and energy flux density are tightly related. However, with this definition, many \gls{HEA} data products that may have fluxes defined using units of counts or particles ({\em e.g.\/}, photons), but not calibrated in units of energy, would not satisfy the current descriptions of ({\em e.g.\/}\null) {\bf light-curve} or {\bf spectrum}, even though that is how those products are used. For \gls{HEA}, because the mappings between observed counts, incident particles, and incident particle energy depend on the {\bf response-function}s (which in some cases may not be determinable without knowledge of the individual science use case) we often use several definitions of photometric properties such as flux, radiance, and flux density: @@ -557,7 +557,7 @@ \subsubsection{Clarification of ``Flux'' in Data Product Type Vocabulary Definit \item Energy flux density (differential flux), with units $\rm J\,m^{-2}\,s^{-1}\,\hbox{eV}^{-1}$. \end{itemize} -The common \gls{HEA} flux, radiance, and flux density definitions listed above are not all covered by the UCD vocabulary. We propose to add new UCDs in \S~\ref{sec:UCDs} below to address this, and where appropriate refine the definitions of existing UCDs based on dimensionality. With the proposed additions and refinements, we can, for example, easily distinguish between a counts flux with UCD {\em phot.counts\/}, a photon flux with UCDs {\em phot.flux.particle;phys.particle.photon\/}, and an energy flux with UCD {\em phot.\-flux.energy\/}. These refinement will also be particularly useful for cases where a \gls{HEA} quantity should have the same UCD as ({\em e.g.\/}) a radio measurement but where very different units are used. For example, $\rm Jy$ ( Jansky) and $\rm erg\,cm^{-2}\,s^{-1}\,TeV$ are both spectral flux densities but the unit analysis doesn’t agree due to the frequency-energy equivalency. +The common \gls{HEA} flux, radiance, and flux density definitions listed above are not all covered by the UCD vocabulary. We propose to add new UCDs in \S~\ref{sec:UCDs} below to address this, and where appropriate refine the definitions of existing UCDs based on dimensionality. With the proposed additions and refinements, we can, for example, easily distinguish between a counts flux with UCD {\em phot.counts\/}, a photon flux with UCDs {\em phot.flux.particle;phys.particle.photon\/}, and an energy flux with UCD {\em phot.\-flux.energy\/}. These refinement will also be particularly useful for cases where a \gls{HEA} quantity should have the same UCD as ({\em e.g.\/}\null) a radio measurement but where very different units are used. For example, $\rm Jy$ (Jansky) and $\rm erg\,cm^{-2}\,s^{-1}\,TeV$ are both spectral flux densities but the unit analysis doesn’t agree due to the frequency-energy equivalency. Restating the existing IVOA Data Product Type Vocabulary descriptions that use the term ``flux'' to explicitly state ``count/particle/energy flux or magnitude'' where appropriate would resolve the concern raised above with the current use of the term ``flux''. @@ -749,12 +749,15 @@ \section{Contributions to the Note} Further material can be found with those links: \begin{itemize} - \item 2025-04-29: French ASOV workship ``High Energy in the VO'', \url{https://indico.obspm.fr/event/2674/}, - \item 2024-11-16: IVOA Malta meeting, DM session with two High Energy presentations (B. Kh\'elifi/I. Evans), \url{https://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpNov2024DM}, - \item 2024-11-15: IVOA Malta Plenary, CSP Plenary session, \url{https://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpNov2024CSPPlenary}, - \item 2024-05-21: IVOA Sydney meeting, DM Session High Energy focus, \url{https://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpMay2024DM}, - \item 2023-06-28: IVOA standards for High Energy Astrophysics (French VO Workshop), \url{https://indico.obspm.fr/event/1963/}, - \item 2023-05-11: IVOA Bologna meeting: presentation (``DM for High Energy astrophysics'', M. Servillat) and first IVOA HE group meeting, \url{https://wiki.ivoa.net/internal/IVOA/IntropMay3023DM/2023-05-11_IVOA_meeting_-_VOHE.pdf}, + \item 2026-06-09 IVOA Strasbourg meeting, ObsCore Extensions plenary with one High Energy presentation, 4 demonstrations, and panel discussion (I. Evans, M. Servillat, S. Hallman), \url{https://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpJune2026HEIG}; + \item 2025-11-15 IVOA Goerlitz meeting, DM session with one High Energy presentation (M. Louys), \url{https://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpNov2025DM}; + \item 2025-06-04: IVOA College Park meeting, DM session with ObsCore Extension progress report, \url{https://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpJune2025DM}; + \item 2025-04-29: French ASOV workshop ``High Energy in the VO'', \url{https://indico.obspm.fr/event/2674/}, + \item 2024-11-16: IVOA Malta meeting, DM session with two High Energy presentations (B. Kh\'elifi/I. Evans), \url{https://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpNov2024DM}; + \item 2024-11-15: IVOA Malta Plenary, CSP Plenary session, \url{https://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpNov2024CSPPlenary}; + \item 2024-05-21: IVOA Sydney meeting, DM Session High Energy focus, \url{https://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpMay2024DM}; + \item 2023-06-28: IVOA standards for High Energy Astrophysics (French VO Workshop), \url{https://indico.obspm.fr/event/1963/}; + \item 2023-05-11: IVOA Bologna meeting: presentation (``DM for High Energy astrophysics'', M. Servillat) and first IVOA HE group meeting, \url{https://wiki.ivoa.net/internal/IVOA/IntropMay3023DM/2023-05-11_IVOA_meeting_-_VOHE.pdf}; \item 2022-10-11: Virtual Observatory and High Energy Astrophysics (French VO Workshop), \url{https://indico.obspm.fr/event/1489/}. \end{itemize} diff --git a/Makefile b/Makefile index e6e66b0..b057aea 100644 --- a/Makefile +++ b/Makefile @@ -8,14 +8,14 @@ DOCNAME = HighEnergyObsCoreExt DOCVERSION = 1.0 # Publication date, ISO format; update manually for "releases" -DOCDATE = 2026-09-01 +DOCDATE = 2026-09-04 # What is it you're writing: NOTE, WD, PR, REC, PEN, or EN DOCTYPE = PEN # An e-mail address of the person doing the submission to the document # repository (can be empty until a make upload is being made) -AUTHOR_EMAIL=ian.evans@ , bruno.khelifi@, mathieu.servillat@ +AUTHOR_EMAIL=ian.evans@, bruno.khelifi@, mathieu.servillat@ # Source files for the TeX document (but the main file must always # be called $(DOCNAME).tex) diff --git a/UseCases.tex b/UseCases.tex index 4b92268..9359b70 100644 --- a/UseCases.tex +++ b/UseCases.tex @@ -17,10 +17,10 @@ \begin{itemize} \item {\bf Proposal 1}: Serve all data products in the {\tt ivoa.obscore} table. The attribute {\em dataproduct\_type\/} in {\tt ivoa.obscore} can contain any term from one of the three vocabularies \textsl{product-type}, \textsl{advanced-product-type}, or \textsl{response-type}: -All products are distributed via the {\tt ivoa.obscore} table as in -Chandra use cases A.1.8, A.2.1, and A.2.3, CTAO use case A1.9 and A2.4, and SWGO use case A1.3. +All products are distributed via the {\tt ivoa.obs\-core} table as in +Chandra use cases A.1.8, A.2.1, and A.2.3, CTAO use cases A1.9 and A2.4, and SWGO use case A1.3. -This has the advantage that it is easy for the end-user to understand. All data products are accessed from the same table and the user does not have to know details about which data products need to be queried from what table. +This approach has the advantage that it is easy for the end-user to understand. All data products are accessed from the same table and the user does not have to know details about which data products need to be queried from what table. A potential disadvantage is that the results of queries for multiple types of datasets will be harder to correlate, especially if the different data products types don't have a one-to-one cardinality relationship. For example, if you search for {\bf hea-event-list} or {\bf light-curve} in a sky region together with {\bf response-function} files, for instance {\bf psf}s, the query response may provide all datasets together mixing the various data product types together. The user will therefore have to determine which {\bf psf}(s) are associated with each {\bf hea-event-list} or {\bf light-curve}. @@ -28,20 +28,20 @@ In practice, many advanced data products of the same type may be associated with a single {\bf hea-event-list} and so archives that serve such products will generally provide adequate metadata to allow the correlations to be performed. These metadata may not be directly accessible through the ObsCore TAP service however, which would place the onus on the end-user to perform these correlations after-the fact. -\item {\bf Proposal 2}: Add new terms to the product-type vocabulary and distinguish among response types and advanced product types using {\em dataproduct\_subtype\/} in {\tt ivoa.obscore}. -The terms pdf, draws, region, response-function are added to product-type vocabulary. +\item {\bf Proposal 2}: Add new terms to the product-type vocabulary and distinguish among response types and advanced product types using {\em data\-product\_subtype\/} in {\tt ivoa.obscore}. +The terms {\bf pdf}, {\bf draws}, {\bf region}, and {\bf response-function} are added to product-type vocabulary. All products are distributed with the {\tt ivoa.obscore} table. See use cases A.1.10 and A.1.13 for KM3NeT and Chandra use case A.1.8. -This approach is included largely for compatibility with the ObsCore Recommendation Version 1.1, which has a limited set of {\em dataproduct\_type\/}s and so requires the use of {\em dataproduct\_subtype\/} to discriminate between different data product types that share the same {\em dataproduct\_type\/}. +This approach is included largely for compatibility with the ObsCore Recommendation Version 1.1, which has a limited set of {\em dataproduct\_type\/}s and so requires the use of {\em dataproduct\_subtype\/} to discriminate between different data product types that share the same {\em data\-product\_type\/}. A disadvantage of this approach is that queries on two ObsCore attributes are required to identify certain types of data products, for example different types of {\em response-function\/}s. The interpretation of the {\em dataproduct\_subtype\/} attribute may be ambiguous as the content could be ({\em e.g.\/}) a type of {\bf response-function}, or a category of image ({\em e.g.\/}, an excess map or significance map) or some specific description chosen by a specific archive. -A standardized vocabulary for {\em dataproduct\_subtype\/} will be beneficial. We have proposed standardized terms for various types of {\bf response-function}s in \S~5. However, there are several types of images that are commonly used in \gls{HEA} that could, with some additional discussion, also be standardized. +A standardized vocabulary for {\em dataproduct\_subtype\/} will be beneficial. We have proposed standardized terms for various types of {\bf response-function}s in \S~5. However, there are several types of {\bf image}s that are commonly used in \gls{HEA} that could, with some additional discussion, also be standardized. -However, the ability for each individual archive to use {\em dataproduct\_subtype\/} ``to more precisely define the nature of the dataset'' (ObsCore Recommendation Version 1.1 \S~4.1) should not be discounted. Each archive is likely to have many different types of data products that would otherwise have the same {\em dataproduct\_type\/} that will need to be discriminated to be useful. Some data products may be unique to a particular observatory but nevertheless highly significant for end-users of that observatory's data. +However, the ability for each individual archive to use {\em dataproduct\_sub\-type\/} ``to more precisely define the nature of the dataset'' (ObsCore Recommendation Version 1.1 \S~4.1) should not be discounted. Each archive is likely to have many different types of data products that would otherwise have the same {\em dataproduct\_type\/} that will need to be discriminated to be discovered efficiently. Some data products may be unique to a particular observatory but nevertheless highly significant for end-users of that observatory's data. -\item {\bf Proposal 3}: Separate the three kinds of products defined in the three distinct vocabularies as proposed with Semantics WG. +\item {\bf Proposal 3}: Separate the three kinds of products defined in the three distinct vocabularies as proposed with Semantics WG\null. Implement one table for each kind: \begin{itemize} \item {\tt ivoa.obscore} uses {\em dataproduct\_type\/} from the \textsl{product-type} vocabulary; @@ -49,12 +49,14 @@ \item {\tt ivoa.adp} uses {\em dataproduct\_type\/} from the \textsl{advanced-product-type} vocabulary. \end{itemize} -The benefits lie in tracing clearly the connections between response files and/or advanced data products to datasets from the currently included in the \textsl{product-type} vocabulary. This separation also addressed concerns that most {\bf response-function}s are not ``on-the-sky'' data products, despite their importance to \gls{HEA} data analysis. (Advanced data products currently proposed for inclusion in ObsCore are all ``on-the-sky'' data, although the definitions of the products are sufficiently general that this is not necessarily the case.) +The benefits lie in tracing clearly the connections between response files and/or advanced data products to primary datasets currently included in the \textsl{product-type} vocabulary. This separation also addressed concerns that most {\bf response-function}s are not ``on-the-sky'' data products, despite their importance to \gls{HEA} data analysis. (Advanced data products currently proposed for inclusion in ObsCore are all ``on-the-sky'' data, although the definitions of the products are sufficiently general that this is not required to be the case.) The disadvantage of this approach is that the end-user will need to know which vocabularies would need to be queried for which data product types and this may require a level of knowledge of IVOA implementation internals that would go beyond what is otherwise required of end-users. This will be more important for end-users who prefer to write their own queries directly using ADQL (for example, using TOPCAT), and could be particularly troublesome if the end user needs to change the syntax of their {\em dataproduct\_type\/} query depending on which vocabulary is used. This strategy still needs to be investigated in detail. Some hints for implementing this approach are provided in Appendix~\ref{sec:accessoptionsappendix}. -\end{itemize} +\end{itemize} + +\pagebreak \subsection{Event-List Data and Responses} @@ -518,8 +520,8 @@ \subsubsection{Use Case --- Search for M31 source light curves and aperture phot \begin{verbatim} -SELECT obs_publisher_did, dataproduct_type, calib_level, energy_min, energy_max, -t_min, t_max, access_url FROM ivoa.obscore +SELECT obs_publisher_did, dataproduct_type, calib_level, energy_min, +energy_max, t_min, t_max, access_url FROM ivoa.obscore NATURAL JOIN ivoa.obscore_hea WHERE (CONTAINS(POINT(s_ra, s_dec), CIRCLE(10.6847, +41.2688, 1.5)) = 1) diff --git a/extendedAccessTonewtypesOfproducts.tex b/extendedAccessTonewtypesOfproducts.tex index 5b5e7b5..ee06e01 100644 --- a/extendedAccessTonewtypesOfproducts.tex +++ b/extendedAccessTonewtypesOfproducts.tex @@ -53,7 +53,7 @@ \subsection{Direct Access to a Data Product or {\bf hea-event-bundle}} \hline {\em access\_estsize\/}&414720&216000\\ \hline -\caption{Excerpt of the ObsCore Response for {\bf hea-event-bundle}s (Inspired by the \gls{HESS} ObsTAP Prototype at Paris Observatory).} +\caption{Excerpt of the ObsCore Response for {\bf hea-event-bundle}s (inspired by the \gls{HESS} ObsTAP Prototype at Paris Observatory).} \label{tab:bundle} \end{longtable} %\end{landscape} @@ -154,8 +154,8 @@ \subsubsection{Datalink Access Using a Service Descriptor} JOIN datalink.response ON ivoa.obscore.obs_publisher_did = datalink.response.ID WHERE (INTERSECTS(s_region, CIRCLE(312.775, 30.683, 1.5)) = 6) - AND (dataproduct_type = `hea-event-list') - AND semantics = `#this') + AND (dataproduct_type = ’hea-event-list') + AND semantics = ’#this') \end{verbatim} } @@ -168,9 +168,9 @@ \subsubsection{Datalink Access Using a Service Descriptor} JOIN datalink.response ON ivoa.obscore.obs_publisher_did = datalink.response.ID WHERE (INTERSECTS(s_region, CIRCLE(312.775, 30.683, 1.5)) = 6) - AND (dataproduct_type = `hea-event-list') - AND (semantics = `#calibration') - AND (content_qualifier = `psf') + AND (dataproduct_type = ’hea-event-list') + AND (semantics = ’#calibration') + AND (content_qualifier = ’psf') \end{verbatim} } @@ -183,9 +183,9 @@ \subsubsection{Datalink Access Using a Service Descriptor} JOIN datalink.response ON ivoa.obscore.obs_publisher_did = datalink.response.ID WHERE (INTERSECTS(s_region, CIRCLE(312.775, 30.683, 1.5)) = 6) - AND (dataproduct_type = `hea-event-list') + AND (dataproduct_type = ’hea-event-list') AND (semantics = '#auxiliary') - AND (content_qualifier = `bkgimage') + AND (content_qualifier = ’bkgimage') \end{verbatim} } diff --git a/extendedAccessTonewtypesOfproductsAppendix.tex b/extendedAccessTonewtypesOfproductsAppendix.tex index 2caf550..9048cab 100644 --- a/extendedAccessTonewtypesOfproductsAppendix.tex +++ b/extendedAccessTonewtypesOfproductsAppendix.tex @@ -53,8 +53,8 @@ \subsubsection*{Retrieve {\bf psf} {\bf response-function}s for {\em obs\_id\/} When using the response table defined in Table \ref{tab:response_table}, we can join the {\tt ivoa.obscore} table with the {\tt ivoa.response} table on one of the two keys ({\em obs\_id\/} and {\em obs\_publisher\_did\/}), for example: {\small \begin{verbatim} -SELECT o.obs_publisher_did, o.obs_id, s_ra, s_dec, s_fov, t_min, t_max, -energy_min, energy_max, access_url, access_format, +SELECT o.obs_publisher_did, o.obs_id, s_ra, s_dec, s_fov, t_min, +t_max, energy_min, energy_max, access_url, access_format, resp_publisher_did, r.obs_publisher_did, r.obs_id, resp_access_url, resp_access_format, resp_energy_max, resp_energy_min FROM ivoa.obscore as o @@ -67,18 +67,18 @@ \subsubsection*{Retrieve {\bf psf} {\bf response-function}s for {\em obs\_id\/} AND (o.obs_collection = 'HESS') \end{verbatim} } -If additional constraints are required, for instance on time, then we can add another set of columns in {\tt ivoa.response} ({\em e.g.\/}) {\em resp\_t\_min\/} and {\em resp\_t\_max\/}, and constrain the time interval by adding a clause like: +If additional constraints are required, for instance on time, then we can add another set of columns to the {\tt ivoa.response} table, ({\em e.g.\/}\null) {\em resp\_t\_min\/} and {\em resp\_t\_max\/}, and constrain the time interval by adding a clause like: {\small \begin{verbatim} -AND (resp_t_min > 56000.0 and resp_t_max < 56001.5) +AND (resp_t_min > 56000.0 and resp_t_max < 56001.5) \end{verbatim} } \subsubsection*{Retrieve {\bf edisp} {\bf response-function}s for data sets constrained by {\em obs\_id} or position and by {\em scan\_mode}} {\small \begin{verbatim} -SELECT o.obs_publisher_did, o.obs_id, s_ra, s_dec, s_fov, t_min, t_max, -energy_min, energy_max, access_url, access_format, scan_mode, +SELECT o.obs_publisher_did, o.obs_id, s_ra, s_dec, s_fov, t_min, +t_max, energy_min, energy_max, access_url, access_format, scan_mode, resp_publisher_did, resp.obs_id, resp_access_url, resp_access_format, resp_energy_max, resp_energy_min, FROM ( SELECT o.obs_publisher_did, o.obs_id, scan_mode