<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<p>Dear all,</p>
<p>I wrote an issue to propose a solution to help users to discover
services containing the radio extension<br>
</p>
<p><a class="moz-txt-link-freetext" href="https://github.com/ivoa-std/ObsCoreExtensionForRadioData/issues/73">https://github.com/ivoa-std/ObsCoreExtensionForRadioData/issues/73</a></p>
<p>The last Pull Request on ObsCoreExtensionForRadioData (which is
not merged) describes this solution. </p>
<p>Cheers</p>
<p>Fr<i>ançois </i></p>
<p>
<blockquote type="cite">
<table class="d-block user-select-contain"
data-paste-markdown-skip="">
<tbody class="d-block">
<tr class="d-block">
<td
class="d-block comment-body markdown-body js-comment-body">
<p dir="auto"><i>If we want to complete the basic
ObsCore table by a set of new standard attributes (=
columns) in the TAP_SCHEMA we can define this
specific set of columns as an "ObsCore profile"</i></p>
<p dir="auto"><i>The profile is relevant to a "schema"
in the tableset which should contain all the columns
in whatever tables inside the schema.</i></p>
<p dir="auto"><i>It is admitted that in the radio case
the basic ObsCore parameters and the radio extension
specific parameters will be hosted in two different
tables belonging to the same "ivoa" schema. The
recommendation is that the basic ObsCore table is
called ivoa.obscore and that the extension table is
called ivoa.obscore_radio.</i></p>
<p dir="auto"><i>The main reason is that the same TAP
service may contain data in the radio domain and
data outside this domain for which the extension
parameters are irrelevant.<br>
So storing everything in the same table would imply
that many rows in the table will show NULL values
for the extension parameters.</i></p>
<hr>
<p dir="auto"><i>But how do we help users to discover
services which serve these two tables ?</i></p>
<p dir="auto"><i>Each standard data model has a
standardID. This is the case of ObsCore, of EPN-TAP,
of RegTAP....</i></p>
<p dir="auto"><i>From the registry point of view, the
occurrence of an ObsCore table itself in a service
is recognized via the datamodel element of a service
capability. This practice has the drawback to match
a datamodel with a service and not with the tables
it serves.</i></p>
<p dir="auto"><i>That's the reason why the practice
changed and why EPN-TAP and RegTAP used another
method.</i></p>
<p dir="auto"><i>This is summarized in this recent IVOA
note published by Markus :</i></p>
<p dir="auto"><i><a
href="https://ivoa.net/documents/Notes/TableReg/20240821/"
rel="nofollow" class="moz-txt-link-freetext">https://ivoa.net/documents/Notes/TableReg/20240821/</a></i></p>
<p dir="auto"><i>So if the model is serialized in a
single table, let's set the standardID of this model
as the value of the utype attribute of the table in
the registry record</i></p>
<p dir="auto"><i>So if the model is serialized in
several tables, let's set the standardID of this
model as the value of the utype attribute of the
schema grouping all these tables in the registry
record.</i></p>
<p dir="auto"><i>What can happen for the ObsCore
extension for radio data ? Obscore and it's
extension are actually part of the same data model.
So they have the same basic standardID
"ivo://ivoa.net/std/ObsCore" and the presence of the
extension columns may be rendered by a fragment in
the URI "ivo://ivoa.net/std/ObsCore#RadioEXt-1.0"</i></p>
<p dir="auto"><i>Now where can we put this standardID in
the registry ?<br>
Currently the thing is organized in two tables which
are strongly related. So they are in the same
"schema". However setting<br>
utype="ivo://ivoa.net/std/ObsCore#RadioEXt-1.0" on
the schema is not appropriate. This would mean all
the tables in the schema are dealing with radio
data. But we may have dataset in the ObsCore table
which are outside the radio domain.</i></p>
<p dir="auto"><i>Another solution could be to set the
utype="ivo://ivoa.net/std/ObsCore#RadioEXt-1.0" on
the ivoa.obscore_radio table only.</i></p>
<p dir="auto"><i>But this may be confusing and encourage
users to try to query this table only which would be
a nonsense. The obscore_radio table alone is useless
Only a query on a natural join between obscore and
obscore_radio makes sense.</i></p>
<p dir="auto"><i>Hence the proposal to set the
standardID utype on a "view" table defined as the
natural join of the ObsCore and obscore_radio
tables. If such a utype is discovered in a service
we know that the schemac ontaining this view will
also contain ObsCore and obscore_radio tables. Of
course in practice it may be more efficient to query
the two tables by a direct join instead of this
view. But the view is there to inform registry users
that this service serves ObsCore with its radio
extension.</i></p>
<p dir="auto"><i>By the way the concept of specific
profiles of ObsCore defined this way as a full set
of columns is agnostic about in which real table we
find the columns. Hence if we decide later to move
some of the extension columns in the basic Obscore
it's very easy to redefine the profile in a new
version. This will not break anything.</i></p>
</td>
</tr>
</tbody>
</table>
</blockquote>
<br>
</p>
</body>
</html>