update sect. 4 & 5+ typo correction, harmonize table names#81
update sect. 4 & 5+ typo correction, harmonize table names#81Bonnarel merged 9 commits intoivoa-std:mainfrom
Conversation
ObsCoreExtensionForRadioData.tex
Outdated
|
|
||
| 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}. | ||
| In that case, DataLink \citep{2023ivoa.spec.1215B} may provide a solution to attach these auxiliary data files to ObsCore records. The link , described in the specification as \{link\} |
There was a problem hiding this comment.
La link response c'est la table complete. moi j'enleverai "described in the specification as \link response.
There was a problem hiding this comment.
I think it would be clearer if we show an example of the link response with all fields set up .
I did not find any example in the JIVE implementation . may be we can mimic a datalink scenario.
There was a problem hiding this comment.
after introducing the example "described in the specification as \link response." should be removed
ObsCoreExtensionForRadioData.tex
Outdated
| When we will have other extensions (for example for time) we may want to | ||
| discover services which deliver several extensions in addition to obscore | ||
| When we will have other extensions (for example for time series or high energy data) we may want to | ||
| discover services which supporting several extensions in addition to the obscore |
There was a problem hiding this comment.
"Which" has also to be removed
ObsCoreExtensionForRadioData.tex
Outdated
| main table. | ||
|
|
||
| This could be done by queries such as | ||
| Querying ObsTAP services with multiple extensions could be done by querying the relational registry such as: |
There was a problem hiding this comment.
"this way" instead of "such as"
ObsCoreExtensionForRadioData.tex
Outdated
| The largest angular scale is also variable along the spectral range. That's why we bound it with \emph{s\_largest\_angular\_scale\_min} and \emph{s\_largest\_angular\_scale\_max} estimated as respectively $\lambda\_min/l$ and $\lambda\_max/l$ | ||
|
|
||
|
|
||
| The largest angular scale is also variable along the spectral range. That's why we bound it with \emph{s\_largest\_angular\_scale\_min} and \emph{s\_largest\_angular\_scale\_max} estimated as respectively $\lambda\_min/l$ and $\lambda\_max/l$F |
ObsCoreExtensionForRadioData.tex
Outdated
|
|
||
| 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}. | ||
| In that case, DataLink \citep{2023ivoa.spec.1215B} may provide a solution to attach these auxiliary data files to ObsCore records. The link , described in the specification as \{link\} |
There was a problem hiding this comment.
after introducing the example "described in the specification as \link response." should be removed
| all columns described in following tables ~\ref{tab:ExtensionAtt} , ~\ref{tab:ExtensionAtt_interferometry} and \ref{tab:ExtensionAtt_instrumental} must be gathered in the \verb|ivoa.obscore_radio| | ||
| table, although some of them may be NULL if no value apply . At least a foreign key into \verb|ivoa.obscore| will typically | ||
| make the extension table user-visible. | ||
| %Additional free columns (such as \emph{f\_min}, \emph{f\_max} ) may also be added. |
There was a problem hiding this comment.
recent discussions about obscore : optional columns need extra processing on the client side .
if we speak about f_min, f_max , they should be properly defined in the standard in order to be comparable .
free is anything while optional is defined ans sometimes not filled.
ObsCoreExtensionForRadioData.tex
Outdated
| When we will have other extensions (for example for time) we may want to | ||
| discover services which deliver several extensions in addition to obscore | ||
| When we will have other extensions (for example for time series or high energy data) we may want to | ||
| discover services which supporting several extensions in addition to the ObsCore |
ObsCoreExtensionForRadioData.tex
Outdated
| $$ | ||
|
|
||
| In addition the schema containing the ObsCore main table and potentially some of the extensions | ||
| In addition the TAP schema containing the ObsCore main table and potentially some of the extensions |
There was a problem hiding this comment.
It is not the TAP_ schema but a tableset schema.
loumir
left a comment
There was a problem hiding this comment.
replaced by 'tableset schema'
Bonnarel
left a comment
There was a problem hiding this comment.
I approve these changes
lighten text in sec. 4 and 5
appendix on new page
table names 'obscore_radio' in appendix and main text.