<div dir="ltr">Hi Dave, Mark, and all,<div><br></div><div><br></div><div>Sorry for the delay, just getting back to this now.</div><div><br></div><div>For the VOSI description of tables, it sounds like we're back to something like what Mark originally proposed (in this thread: <a href="http://mail.ivoa.net/pipermail/grid/2016-July/002853.html">http://mail.ivoa.net/pipermail/grid/2016-July/002853.html</a>), where the service decides the naming of their tables, based on the rules in TAP.</div><div><br></div><div> "<span style="font-size:12.8px">The child resource must be named with the fully-qualified table name,</span><span style="font-size:12.8px"> as it appears in the name child of the corresponding Table element."</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Except that we don't want to mention "fully-qualified", so perhaps (keeping in mind this is for the VOSI /tables definition only) it can be shortened still:</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"> "The child resource must be named as it appears in the name of the corresponding child Table element."</span></div><div><br></div><div>So does this, followed by the example and snippet of response XML, sit well with everyone?</div><div><br></div><div><br></div><div>Cheers,</div><div>Brian</div><div><br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 20, 2016 at 2:12 AM, Mark Taylor <span dir="ltr"><<a href="mailto:M.B.Taylor@bristol.ac.uk" target="_blank">M.B.Taylor@bristol.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Dave.<br>
<span class="gmail-"><br>
On Tue, 19 Jul 2016, Dave Morris wrote:<br>
<br>
> I agree with Mark that we should be consistent across the different metadata<br>
> sources. However I am concerned that the term 'official name' implies a level<br>
> of standardization beyond the consensus that we have achieved. To an external<br>
> user, referring to [twomass.data] as the 'official name' may imply that we<br>
> have standardized this as the name for the twomass point source catalog across<br>
> the whole of the VO.<br>
<br>
</span>I agree that "official name" is not a very good choice of terminology<br>
and can probably be improved. Having said that I don't think there's<br>
too much danger of confusing external users; this term/concept is<br>
only going to be used in IVOA standards documents, it's not something<br>
the user has to see or think about.<br>
<br>
I will suggest as an alternative "canonical name". I think it's<br>
accurate, though I agree it's a bit obscure. However (a) users<br>
won't see this term, so it doesn't matter if it would stump astronomers<br>
and (b) it's distinctive enough that people will probably recognise<br>
it as a term they've seen elsewhere when it crops up in a standard.<br>
I'm happy if a better suggestion can be found, but I'm not keen<br>
on "optimally qualified", for the reasons below.<br>
<span class="gmail-"><br>
> May I suggest an alternative term, 'optimally qualified', defined as "the<br>
> optimal level of qualification that makes a name unique in the context within<br>
> which it is being used".<br>
><br>
> Taking the GAVO TAP service as an example, there are several tables called<br>
> 'data', so the optimally qualified name would need to include the schema name<br>
> to make them unique.<br>
><br>
> [unqualified name] [data]<br>
> [optimally qualified] [antares10.data]<br>
> [fully qualified] [antares10.data]<br>
><br>
> [unqualified name] [data]<br>
> [optimally qualified] [veronqsos.data]<br>
> [fully qualified] [veronqsos.data]<br>
><br>
> On the other hand, at the moment there is only one table called<br>
> 'unidentified', so the optimally qualified name could/should use the short<br>
> name.<br>
><br>
> [unqualified name] [unidentified]<br>
> [optimally qualified] [unidentified]<br>
> [fully qualified] [arigfh.unidentified]<br>
<br>
</span>Well, no. Services have their own rules about table name syntax.<br>
As a matter of fact, DaCHS/GAVO does not permit you to omit the<br>
"<schema>." part of a table name, so even in absence of multiple<br>
tables with the name "*.unidentified", the "optimally qualified"<br>
version you quote above won't work. Other TAP implementations<br>
(e.g. ones based on Gregory Mantelet's parsers) typically do allow<br>
that shortcut. TAP/ADQL does not attempt to legislate about this<br>
kind of thing, nor should it. For that reason, I don't think<br>
that the optimally qualified concept is useful as part of the<br>
standards landscape.<br>
<br>
Instead I believe the canonical name should be opaque (which is my<br>
understanding of the way it works now); it's whatever the service<br>
says it is, with whatever qualifications/delimitations<br>
the implementation sees fit to apply. The only rule is<br>
that the same name has to be used in all relevant places,<br>
and accepted in queries.<br>
Services *may* at their option also allow different forms of the<br>
name (e.g. with less or more qualification, or even aliases etc)<br>
in submitted queries, though using such forms might fox<br>
TAP_SCHEMA-based ADQL validation.<br>
<br>
Given that, I don't think that we should say anything in the<br>
standards about what other forms of the name might look like<br>
or when they can or should be used, so I don't think it's going to be<br>
helpful to define {Un,Optimally ,Fully }qualified names.<br>
<span class="gmail-"><br>
> However, if GAVO add another schema that contains a table called<br>
> 'unidentified', then the optimally qualified name would have to be updated to<br>
> include the schema name in order to distinguish between them.<br>
><br>
> [unqualified name] [unidentified]<br>
> [optimally qualified] [arigfh.unidentified]<br>
> [fully qualified] [arigfh.unidentified]<br>
><br>
> [unqualified name] [unidentified]<br>
> [optimally qualified] [newschema.unidentified]<br>
> [fully qualified] [newschema.unidentified]<br>
><br>
> I agree with Mark, it is up the the service provider to decide what level of<br>
> qualification is appropriate for the optimally qualified names in their<br>
> service.<br>
><br>
> We can stress that in a client-server scenario, the optimally qualified name<br>
> is the name that the client application would normally present to the user,<br>
> and as such it should be as simple as possible while still ensuring that it<br>
> is sufficiently unique to be used as-is in queries and examples without<br>
> requiring the user to add additional qualification, but I don't think we can<br>
> mandate that a service always uses the minimum level of qualification in the<br>
> optimally qualified name.<br>
<br>
</span>So I agree with you that the form of the name is not mandated,<br>
but I disagree that there should be an expectation to use any<br>
particular form of the name under "normal" circumstances - I say we<br>
just leave that to the services' implementation requirements and<br>
common sense.<br>
<br>
As far as I understand it, I'm not proposing anything new here,<br>
only a clarification of wording in the standards, possibly<br>
backed up by a well-defined term ("canonical [table] name" or<br>
something along those lines).<br>
<br>
Mark<br>
<div><div class="gmail-h5"><br>
> If for example, the GAVO team had plans to add another schema containing a<br>
> table called 'unidentified' in a few months time, then even though the<br>
> unqualified name is currently unique, they may choose to include the schema<br>
> name in the optimally qualified name now, in preparation for the introduction<br>
> of the new schema later.<br>
><br>
> I suggest we should define these three terms in the TAP specification and then<br>
> we can refer to them in the TAP, ADQL and VOSI standards.<br>
><br>
> Suggested definitions :<br>
><br>
> Unqualified (short name)<br>
><br>
> * The name of a catalog, schema, table or column, without reference to<br>
> the object's parents in the hierarchy.<br>
> * An unqualified name MUST NOT include qualifying references to the<br>
> object's parents, even if it means that the name is not unique in the context<br>
> within which it is being used.<br>
><br>
> Optimally qualified (optimal name)<br>
><br>
> * The name of a catalog, schema, table or column with a an optimal<br>
> level of qualification sufficient to make it unique in the context within<br>
> which it is being used.<br>
> * An optimally qualified name MUST include sufficient qualification to<br>
> make it unique in the context within which it is being used.<br>
> * An optimally qualified name MAY include more qualification than<br>
> required to make it unique in the context within which it is being used.<br>
><br>
> Fully qualified (full name)<br>
><br>
> * The full name of a catalog, schema, table or column, including the<br>
> names of all the parent objects in the hierarchy.<br>
> * A fully qualified name MUST include qualifying references to all of<br>
> the object's parents, even if they are not required to make the name unique in<br>
> the context within which it is being used.<br>
><br>
> What do you think. Would defining these terms be useful ?<br>
><br>
> Hope this helps,<br>
> Dave<br>
><br>
> --------<br>
> Dave Morris<br>
> Software Developer<br>
> Wide Field Astronomy Unit<br>
> Institute for Astronomy<br>
> University of Edinburgh<br>
> --------<br>
><br>
><br>
><br>
><br>
<br>
</div></div>--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bris.ac.uk">m.b.taylor@bris.ac.uk</a> <a href="tel:%2B44-117-9288776" value="+441179288776">+44-117-9288776</a> <a href="http://www.star.bris.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~<wbr>mbt/</a><br>
</blockquote></div><br></div></div></div></div>