RFC period started for Obscore 1.1/ ivo ID for the Tapregext record

[Mireille Louys]

Dear all,

Just to summarize the discussion on the new identifier we expect to use 
for publishing ObsTap services :

let me reformulate what I understood from the discussion :

1- for existing Tapregext registry records defining ObsTAP services 
following ObsCore1.0

We do not expect to change existing registry records: the data model 
IVOAID remains :

<dataModel ivo-id="ivo://ivoa.net/std/ObsCore/v1.0">ObsCore-1.0</dataModel>

2- for new services following Obscore v1.1 specifications

Tapregext should contain :

   <dataModel ivo-id="ivo://ivoa.net/std/ObsCore#core-1.1">ObsCore-1.1</dataModel>

following the new specification on IVOA Identifiers , version 2.0.
As a few changes happened in names, types, ucd in the TAP-SCHEMA tables 
with addition of new terms for axes length,
ObsCore1.1 supersedes the previous version of ObsCore.
Then only one <dataModel ... > tag should appear.

The #core-1.1 extension allows adding extra tables to the Tap schema if 
necessary,like :

ivo://ivoa.net/std/ObsCore#cube-1.2  as in Pat's example
ivo://ivoa.net/std/ObsCore#Prov-1.1  if we would like to bind a TAPschema table with simple provenance information, for instance.

If we could agree on this, I would be able to give a final editing step 
to the spec.

Many thanks  for your comments and suggestions already given ,
Mireille





Le 21/06/2016 à 18:54, Patrick Dowler a écrit :
> I might call that thing #core-1.1 so that if we defined more tables
> they could have their own #symbol.
>
> eg the ObsFile and ObsPart stuff I showed in Sesto,  or
>
> eg possibly dataproduct_type-specific tables that could be joined to
> ObsCore, eg ObsCube (#cube-1.2) or ObsTimeSeries (#time-1.3) since
> those were alternative solutions we discussed in the context of
> extending ObsCore for the cube use cases.
>
> Not saying we would do those, but #core-1.1 seems appropriately specific.
>
> Pat
>
>
> On 21 June 2016 at 09:46, Patrick Dowler <pdowler.cadc at gmail.com> wrote:
>> I agree with this. Keep compat but do it right from here on.
>>
>> Pat
>>
>> On 14 June 2016 at 01:38, Markus Demleitner
>> <msdemlei at ari.uni-heidelberg.de> wrote:
>>> Dear DM,
>>>
>>> On Thu, Apr 28, 2016 at 09:04:57AM +0200, Laurent Michel wrote:
>>>>>> The RFC period for Obscore 1.1 is started. It will cover a 6 weeks period from
>>>>>> now until May 15th.
>>> Ahem.  Sorry that Registry hasn't put in their opinion yet.  I
>>> promise it's not going to take much longer.  However, there is one
>>> point I'd like to make here with my Registry chair hat on to see if
>>> fixing this would cause problems for anyone, and that's the standard
>>> identifier (sect. 5).
>>>
>>> The current standard says:
>>>
>>>    The standard identifier for the ObsCore model described here is
>>>    ivo://ivoa.net/std/ObsCore/v1.1.
>>>
>>> This is somewhat suboptimal, as it implies that for every ObsCore
>>> version there's going to be a separate StandardsRegExt record --
>>> remember, an ivoid is supposed to resolve in the Registry, and we in
>>> the Registry WG intend to be a bit stricter in this in the future.
>>>
>>> It is for this reason that Identifiers 2.0 recommends to have
>>> standard identifiers of the form
>>>
>>>    ivo://ivoa.net/std/<standard name>/<something>-<version>
>>>
>>> where <something> is a particular aspect of the standard; that's a
>>> good idea because many standards at some point needed several
>>> different concepts versioned.  For Obscore, this would mean we'd like
>>> the standard id to be
>>>
>>>    ivo://ivoa.net/std/ObsCore#table-1.1
>>>
>>> Sure, this will look a bit odd because we cannot fix the standard id
>>> for version 1.0, and so, further down on p. 27, it will have to say:
>>>
>>>    Since ObsCore-1.1 is a superset of 1.0, TAP services that support
>>>    ObsCore-1.1 also support ObsCore-1.0 and should include both
>>>    'dataModel' elements, e.g.:
>>>
>>>    <dataModel ivo-id="ivo://ivoa.net/std/ObsCore/v1.0">ObsCore-1.0</dataModel>
>>>    <dataModel ivo-id="ivo://ivoa.net/std/ObsCore#table-1.1">ObsCore-1.1</dataModel>
>>>
>>>    This will allow clients looking for ObsCore-1.0 to find and use...
>>>
>>> Not particularly pretty, but I think it's still better keeping
>>> churning out one registry record per version.
>>>
>>> So -- does anyone object to fixing this this late in the process?
>>>
>>> Cheers,
>>>
>>>             Markus
>>
>>
>> --
>> Patrick Dowler
>> Canadian Astronomy Data Centre
>> Victoria, BC, Canada
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20160626/fe14d2e4/attachment.html>