Merge pull request #78 from Bonnarel/main

Changes before June 2025 interop

Author: Bonnarel

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:\\

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
 

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,34 +701,43 @@ \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
 %$$
 %\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,31 +752,75 @@ \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
 NATURAL JOIN rr.res_schema
 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