merge Appendix changes and registry changes

Author: BONNAREL FRANCOIS

.gitmodules

@@ -0,0 +1,3 @@
+[submodule "ivoatex"]
+	path = ivoatex
+	url = https://github.com/ivoa-std/ivoatex

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

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}
 
@@ -438,10 +439,12 @@ \subsection{observational configuration and instrumental parameters}
 \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
@@ -659,34 +662,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 +713,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