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

[François Bonnarel]

Hi Mireille, all

Le 26/06/2016 22:38, Mireille Louys a écrit :
>
> 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.
>
  I think this is a good summary and conclusion. I approve the PR to be 
updated according to this

Best regards
François
> 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/20160901/8ab6b15c/attachment.html>