diff --git a/Appendix.tex b/Appendix.tex index d057931..49c0c18 100644 --- a/Appendix.tex +++ b/Appendix.tex @@ -89,6 +89,7 @@ \subsection{Use case - dataproduct\_type} IV. dataproduct\_type = spatial\_profile or scan\_mode contains map\\ V. 51544 < observation time (MJD) < 60309 \\ + \begin{verbatim} SELECT * FROM ivoa.obscore NATURAL JOIN ivoa.obscore-radio @@ -180,6 +181,7 @@ \subsection{ use case - visibility data product and target object selection } \end{verbatim} + \subsection{Use case - maximum angular scale selection} \textit{Any visibility dataset Within an arcec around FRB 121102 where maximum angular scale is larger than 1 minute .}\\ \\ Show me all datasets satisfying:\\ @@ -247,7 +249,8 @@ \subsection{Use case - instrument type and mode selection } CONTAINS(POINT(s_ra,s_dec), CIRCLE(187.2779159404900, +02.0523882305500,0.05)) = 1) \end{verbatim} -% use case FB + + \subsection{Use case - instrument type and frequency selection } \textit{Any single dish or beam forming dataset with spectral range inside the 500 Mhz - 1Ghz band and in the Coma Cluster.}\\ \\ Show me all datasets satisfying:\\ @@ -261,12 +264,13 @@ \subsection{Use case - instrument type and frequency selection } NATURAL JOIN ivoa.obscore-radio WHERE (instr_type = 'SD' OR instr_type = 'beamForming') - AND f_min > 500 - AND f_max < 1000 + AND 299792458 / em_max > 500 + AND 299792458 / em_min < 1000 AND CONTAINS(POINT(s_ra,s_dec),CIRCLE(194.93502, +27.91246, 0.3) = 1 \end{verbatim} + \subsection{Use case - instrument parameters selection } \textit{Any interferometry data of good quality and significant spatial resolution from the instrumental point of view. }\\ \\ Show me all datasets satisfying:\\ diff --git a/Makefile b/Makefile index 30c9e91..75d2641 100644 --- a/Makefile +++ b/Makefile @@ -7,7 +7,7 @@ DOCNAME = ObsCoreExtensionForRadioData DOCVERSION = 1.0 # Publication date, ISO format; update manually for "releases" -DOCDATE = 2025-04-25 +DOCDATE = 2025-06-02 # What is it you're writing: NOTE, WD, PR, or REC DOCTYPE = PEN diff --git a/ObsCoreExtensionForRadioData.tex b/ObsCoreExtensionForRadioData.tex index 932bc81..ef0dd83 100644 --- a/ObsCoreExtensionForRadioData.tex +++ b/ObsCoreExtensionForRadioData.tex @@ -41,12 +41,13 @@ + %definition of table names %\def\radioexttable {ivoa.obscore-radio-ext} % explicit \def\radioexttable {ivoa.obsradio} % not explicitely related to Obscore \def\radioexttable {ivoa.obscore-radio} %definition of standard id for utypes content -%\def\obsradioSTDID {ivo://ivoa.net/std/obscore-radio-ext#table-1.0} +%\def\obsradioSTDID {ivo://ivoa.net/std/obscore-radio-ext#table-1.0} \begin{document} @@ -429,19 +430,60 @@ \subsection{observational configuration and instrumental parameters} We note that \emph{instr\_feed} could also account for the number of beams in the case of a beam forming/PAF receiver. The scanning strategy adopted in an observation is described by the parameter \emph{scan\_mode}. This parameter covers both spatial -and frequency scanning modes (see Sect.~\ref{subsec:sd} for details). +and frequency scanning modes (see Sect.~\ref{subsec:sd} for details and table~\ref{tab:scanmode} for possible values). It is applicable to SD as well as interferometry cases. -Pointing mode distinguishes targeted observations from fixed alt-azimuth or wobble ones. The ObsLocTAP specification \citep{2021ivoa.spec.0724S} defines the term \emph{tracking\_type} for describing this as well as a vocabulary for these modes. -We include the same term here in the extension. + +\begin{longtable}{ p{6cm} p{7cm} } +\sptablerule + \textbf{value}&\textbf{definition}\cr +\sptablerule +\sptablerule + \texttt{on-source}&\texttt{pointed measurement}\cr +\sptablerule + \texttt{on-off}&\texttt{switched measurements between two positions (source and background)}\cr +\sptablerule + \texttt{raster-map}&\texttt{successive measurement spots on a rectangular mesh}\cr +\sptablerule + \texttt{on-the-fly-cross-scan}&\texttt{successive continuous measurements along two orthogonal directions}\cr +\sptablerule + \texttt{on-the-fly-map}&\texttt{successive continuous measurements along parallel directions}\cr +\sptablerule + \texttt{skydip}&\texttt{long strip of measurements}\cr +\sptablerule + \texttt{frequency-switching}&\texttt{switch from line frequency band to a lineless frequency band }\cr + +% \texttt{target}&\texttt{extrasolar target follow up}\cr +\sptablerule +\caption{scan-mode attribute values} +\label{tab:scanmode} +\end{longtable} + + +Pointing mode distinguishes observations pointed on a fixed target from +observations fixed on a given elevation and azimuth. +%In addition the wobble mode observes both the source and the surrounding background. +The ObsLocTAP specification \citep{2021ivoa.spec.0724S} defines the term +\emph{tracking\_type} for describing this as well as a vocabulary for +these modes. We include the same term here in the extension. The two +possible values for radio astronomy data are the following: +\begin{itemize} + \item Sidereal : observations pointed on a fixed target, as defined in + ObsLocTAP + \item Fixed-az-el-transit : observations fixed on a given elevation + and azimuth, as in ObsLocTAP +% \item Wobble : observations measuring both the source and the surroundings +\end{itemize} \subsection{Auxiliary datasets useful for data quality estimation} Auxiliary datasets such as \emph{uv} distribution map, dirty beam maps, frequency/amplitude plots, phase/amplitude plots are useful for astronomers to check data quality. + In that case DataLink \citep{2023ivoa.spec.1215B} may provide a solution to attach these auxiliary data to ObsCore records. The \texttt{semantics} FIELD in the \{link\} response will contain \#auxiliary for links to these maps or plots while the \texttt{content\_qualifier} FIELD introduced from 1.1 could contain a term from a defined vocabulary (to be defined) following the IVOA vocabulary definition \citep{2021ivoa.spec.0525D}. + \section{The ivoa.obscore\_radio table} \label{sec:implementation} The ObsCore Extension for Radio is accessed as a table within a TAP @@ -606,9 +648,9 @@ \section{The ivoa.obscore\_radio table} \sptablerule \texttt{instr\_feed}&\texttt{number of feeds}&\texttt{Provenance.ObsConfig.\newline Instrument.Feed}&instr.param&& radio \cr \sptablerule -\texttt{scan\_mode}&\texttt{scan mode (on-off, \newline raster map, on-the-fly map,...)\newline }&\texttt{Provenance.\newline Observation.\newline sky\_scan\_mode}&instr.param&& radio \cr +\texttt{scan\_mode}&\texttt{sky and spectral axis scan mode }&\texttt{Provenance.\newline Observation.\newline sky\_scan\_mode}&instr.param&& radio \cr \sptablerule -\texttt{tracking\_mode}&\texttt{targeted, alt-azimuth, wobble, ...)\newline }&\texttt{Provenance.\newline Observation.\newline tracking\_mode}&instr.param&& radio \cr +\texttt{tracking\_type}&\texttt{target tracking modes}&\texttt{Provenance.\newline Observation.\newline tracking\_mode}&instr.param&& radio \cr \caption{ObsCore extension proposal for instrumental parameters for radio data} \label{tab:ExtensionAtt_instrumental} \end{longtable} @@ -659,6 +701,11 @@ \section{Registry Aspects} Services compliant with this specification are registered using VODataService \citep{2021ivoa.spec.1102D} tablesets. +Compliant tables use the utype +$$ +\hbox{\nolinkurl{ivo://ivoa.net/std/ObsCore#radioExt-1.0}.} +$$ +% %The view table providing the %join between the basic ObsCore table and the obscore\_radio table %use the utype @@ -666,27 +713,31 @@ \section{Registry Aspects} %\hbox{\nolinkurl{ivo://ivoa.net/std/obscore#radioext-1.0}.} %$$ %and this is a signature of the compliance of the service with the current specification. -Due to the status of the current specification as an endorsed note, and in prevision of a major -upgrade of the ObsCore specification itself which will address the definition of standardID for the -different extensions and recommand how to expose them in the compliant services, we don't define -any standardID for the extension yet. The discovery of the services and schema containing the -radio extension table MUST be done using the table\_name only as stated below. +%Due to the status of the current specification as an endorsed note, and in prevision of a major +%upgrade of the ObsCore specification itself which will address the definition of standardID for the +%different extensions and recommand how to expose them in the compliant services, we don't define +%any standardID for the extension yet. The discovery of the services and schema containing the +%radio extension table MUST be done using the table\_name only as stated below. +While it is admitted that the table only sits in the tableset of the +embedding TAP service, implementors are urged to use a seperate registry +record with the main TAP service as an auxiliary capability +\citep{2019ivoa.spec.0520D}. In this way, meaningful information +on coverage in space, time, and spectral axes as per VODataService 1.2 can +be communicated to the Registry, which, again, data providers are urged +to do. +%There is no expectation that the coverage information only +%pertains to data with entries in \verb|ivoa.obscore_radio|, i.e., it may be +%a copy of the coverage of the basic ObsCore table.\footnote{Is that +%acceptable? Or should we require pure radio coverage?} + However, discovering the obscore\_radio table alone would be irrelevant because querying this -extension table per se doesn't make sense. The same schema MUST also contain the ObsCore table. -Being sure our \textit{ivoa} schema contains these both tables, +extension table per se doesn't make sense. The same service delivering the \verb|obscore_radio| table +MUST also contain the ObsCore table. +Being sure our service contains these both tables, the user is able to build any natural JOIN query between these two tables. -%While it is admitted that the table only sits in the tableset of the -%embedding TAP service, implementors are urged to use a seperate registry -%record with the main TAP service as an auxiliary capability -%\citep{2019ivoa.spec.0520D}. In this way, meaningful information -%on coverage in space, time, and spectral axes as per VODataService 1.2 can -%be communicated to the Registry, which, again, data providers are urged -%to do. There is no expectation that the coverage information only -%pertains to data with entries in \verb|ivoa.obscore_radio|, i.e., it may be -%a copy of the coverage of the basic ObsCore table.\footnote{Is that -%acceptable? Or should we require pure radio coverage?} + %A sample registry record for an obscore\_radio table comes with this %specification\footnote{\auxiliaryurl{sample-record.xml}}. @@ -701,7 +752,63 @@ \section{Registry Aspects} query like: \begin{lstlisting} -SELECT DISTINCT(access_url), schema_name, table_name +SELECT DISTINCT(access_url), table_name +FROM rr.res_table + NATURAL JOIN rr.capability + NATURAL JOIN rr.interface +WHERE + standard_id LIKE 'ivo://ivoa.net/std/tap%' + AND intf_role='std' + AND table_utype LIKE 'ivo://ivoa.net/std/ObsCore#radioExt-1.%' + AND EXISTS (select 1 from rr.res_table where + table_name LIKE '%obscore') +\end{lstlisting} + +In the current status of the ObsCore specification the last statement in the WHERE clause +is the simplest one to ensure the service also delivers the main obscore table. +In the future this statement could be replaced by +\begin{lstlisting} + AND EXISTS (select 1 from rr.res_table where + table_utype LIKE 'ivo://ivoa.net/std/obscore#core-1.%') +\end{lstlisting} + +When we will have other extensions (for example for time) we may want to +discover services which deliver several extensions in addition to obscore +main table. + +This could be done by queries such as + +\begin{lstlisting} +SELECT DISTINCT(access_url), table_name +FROM rr.res_table + NATURAL JOIN rr.capability + NATURAL JOIN rr.interface +WHERE + standard_id LIKE 'ivo://ivoa.net/std/tap%' + AND intf_role='std' + AND table_utype LIKE 'ivo://ivoa.net/std/ObsCore#radioExt-1.%' + AND EXISTS (select 1 from rr.res_table where + table_utype LIKE 'ivo://ivoa.net/std/ObsCore#timeExt-1.0' + AND EXISTS (select 1 from rr.res_table where + table_name LIKE '%obscore') +\end{lstlisting} + +assuming that the standardID for the time extension currently in progress will be +$$ +\hbox{\nolinkurl{ivo://ivoa.net/std/ObsCore#timeExt-1.0}} +$$ + +In addition the schema containing the ObsCore main table and potentially some of the extensions +SHOULD use the root ObsCore standardID utype : +$$ +\hbox{\nolinkurl{ivo://ivoa.net/std/ObsCore}} +$$ + + +in such a way that the query + +\begin{lstlisting} +SELECT DISTINCT(access_url), table_name, schema_name FROM rr.res_table NATURAL JOIN rr.capability NATURAL JOIN rr.interface @@ -709,23 +816,11 @@ \section{Registry Aspects} WHERE standard_id LIKE 'ivo://ivoa.net/std/tap%' AND intf_role='std' -AND table_name LIKE '%obs_radio' -AND schema_name LIKE '%ivoa%' +AND schema_utype LIKE 'ivo://ivoa.net/std/ObsCore' \end{lstlisting} -%Alternatively the schema and tables can be discovered this way +would allow to discover all services delivering ObsCore and which extension tables they deliver. -%\begin{lstlisting} -%SELECT DISTINCT(access_url), table_name, schema_name -%FROM rr.res_table -%NATURAL JOIN rr.capability -%NATURAL JOIN rr.interface -%NATURAL JOIN rr.res_schema -%WHERE -%standard_id LIKE 'ivo://ivoa.net/std/tap%' -%AND intf_role='std' -%AND schema_utype LIKE 'ivo://ivoa.net/std/ObsCore#obscore-radioExt-%' -%\end{lstlisting} \appendix diff --git a/ivoatex b/ivoatex index 2927181..08e2ab1 160000 --- a/ivoatex +++ b/ivoatex @@ -1 +1 @@ -Subproject commit 292718147b8126f21c5b734523c4c76766c8bafc +Subproject commit 08e2ab11cb90d37d08f2927ac0e095b4790627fa