New release for Obscore 1.1

[Mark Taylor]

Mireille,

I'm afraid I don't understand this answer to my question, even if
it's a call for further discussion.  Both the options a) and b)
you mention in this response use the ObsCore 1.1 ivoid

   ivo://ivoa.net/std/ObsCore#core-1.1

which is what I expected.  But the ivoid defined in the recent
PR-ObsCore-v1.1-20160909 is

    ivo://ivoa.net/std/ObsCore#1.1

Does this correspond to another option c)?

Anyway I take from this unless otherwise advised that there is
still not agreement on this ivoid, so I won't update taplint
until it becomes clear which it's actually going to be.

Mark

On Tue, 13 Sep 2016, Mireille Louys wrote:

> 
> Hi Mark, hi all,
> 
> Thanks for the comment .
> 
> We had a recent discussion here Strasbourg , and noticed that
> the proposition I wrote in
> http://mail.ivoa.net/pipermail/dm/2016-September/005420.html, was actually an
> ID for a table and not for the model itself.
> 
> As I mentionned in the referenced mail above, a dedicated TAP service may
> serve extra tables together with the ObsTAP ivoa.ObsCore table.
> I feel uneasy to define the scope for an ObsTAP service and I guess we will
> have to discuss between several options among which:
> a- an ObsTAP service follows the TAP specification and contains at least the
> ivoa.Obscore table and possibly more tables defined in the TAP_SCHEMA .
> it has no version by itself , as all tables used have their own version
> specified in their identifier.
> in this way , ObsTAP is seen as a container with  a referenced model and
> additionnal tables, not necessarily standardized.
> b- an ObsTAP service contains only the ivoa.ObsCore table and its version is
> the one of the ObsCore DM.
> 
> I guess it is interesting to open the possibility for data providers to offer
> ObsCore++ services , and so warrant a core level of interoperability for the
> ObsCore metadata.
> However the consistency between the added tables and Obscore might be "swept
> under the carpet". ( not made explicit)
> 
>  * in case a) the TAPregext should have at least one declaration
>    specifying the table reference like the one proposed last june :
> 
> /<dataModel ivo-id="ivo://ivoa.net/std/ObsCore/v1.0">ObsCore-1.0</dataModel>
> for Obscore 1.0
> or /
> /<dataModel
> ivo-id="ivo://ivoa.net/std/ObsCore#core-1.1">ObsCore-1.1</dataModel> for
> Obscore 1.1
> /
> 
>  * in case b) we might have several datamodel references for the same
>    TAP service
> 
> for instance for version 1.1 if we want to add a Provenance table to the
> ObsCore core table, we would have:
> /<dataModel
> ivo-id="ivo://ivoa.net/std/ObsCore#core-1.1">ObsCore-1.1</dataModel>
> and <dataModel ivo-id="ivo://ivoa.net/std/Prov#core-1.0
> <ivo://ivoa.net/std/ObsCore#core-1.1>">Prov-1.0</dataModel>
> 
> or for a spectrum combined with annotated emission lines
> /
> /<dataModel
> ivo-id="ivo://ivoa.net/std/ObsCore#core-1.1">ObsCore-1.1</dataModel>/
> /<dataModel ivo-id="ivo://ivoa.net/std/SSLDM#1.0
> <ivo://ivoa.net/std/ObsCore#core-1.1>">ObsCore-1.1</dataModel>/
> Behind this I guess there is such a question :
> At which granularity level does the interoperability take place ?
> at the level of a model ? or at the level of a table definition ?
> 
> Your comments welcome.
> Cheers, Mireille.
> 
> 
> 
> Le 12/09/2016 à 13:58, Mark Taylor a écrit :
> > Mireille,
> > 
> > this version PR-ObsCore-v1.1-20160909 specifies in section 5 the
> > ObsCore 1.1 ivoid:
> > 
> >     ivo://ivoa.net/std/ObsCore#1.1
> > 
> > That is different from what was in the previous draft I saw
> > (PR-ObsCore-v1.1-20160709) and what I recall being agreed in
> > email discussions, e.g.
> > http://mail.ivoa.net/pipermail/dm/2016-September/005420.html,
> > which specified:
> > 
> >     ivo://ivoa.net/std/ObsCore#core-1.1
> > 
> > Can you confirm that the current draft is really as intended?
> > 
> > Thanks.
> > 
> > Mark
> > 
> > On Fri, 9 Sep 2016, Mireille Louys wrote:
> > 
> > > Dear DMers,
> > > 
> > > Please find here a revised version of the Obscore 1.1 specification .
> > > After discussion among authors about the addition of analysis results like
> > > source lists/catalogs, and calibration levels values,
> > > here is the proposal.
> > > More details next week about the pros and cons.
> > > 
> > > Thanks for your comments,
> > > 
> > > Mireille Louys
> > > 
> > --
> > Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> > m.b.taylor at bris.ac.uk  +44-117-9288776http://www.star.bris.ac.uk/~mbt/
> 
> 

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/