New release for Obscore 1.1
Patrick Dowler
pdowler.cadc at gmail.com
Tue Sep 20 00:55:33 CEST 2016
We had agreed awhile back that standardID values defined in documents
needed to have the form:
<resource identifier for the standards record>#<label for some feature>
The use of the fragment allows for a single record in the registry for
each standard; within (#) that record a user can find out about all
versions. So that is why the old /v1.0 form is discouraged in a
standardID.
For labels it is usually tempting to just put the version number when
there is a single "feature" defined, but that has proven to be painful
when things evolve... specifically, when you add a feature and don't
change the existing feature it is really preferrable for everyone
(clients and services) to keep using the previous identifier. For
example, if we write ObsCore-1.2 and add some other table (#foo-1.2)
but we don't change the "core" table then all clients and services
still use #core-1.1 and some may also have #foo-1.2 (in the dataModel
elements of TAPRegExt-enhanced VOSI-capabilities documents). On the
other hand, if ObsCore-1.2 were to specify a change in the
ivoa.ObsCore table *and* a new mandatory table, then #core-1.2 could
be defined to mean both of those tables (e.g. core means mandatory) or
another label could be introduced for the additional table. So, one
can but does not have to create standardID values for every table.
Yes, it does mostly look like #core-1.1 is the version of that table,
but that is consistent with the use in a dataModel element because
that is what clients care about. So, I feel strongly that ObsCore-1.1
only needs to define the ivo://ivoa.net/std/ObsCore#core-1.1
identifier and nothing else. It does the intended job with the minimum
pain going forward.
Pat
On 19 September 2016 at 01:35, François Bonnarel
<francois.bonnarel at astro.unistra.fr> wrote:
> Dear Mark,
>
> As far as I understand, the question is still discussed among authors,
> despite the solution proposed on the list in June .
>
> The issue is the following:
>
> What is the exact nature of the datamodel tag in the TAP reg EXT schema
> ?
>
> Is it a tag for a full model ? or for a "sub" model ( a package,
> serialized as a single table maybe ?)
>
> Let's look at the structure of the ivoid
>
> ivo://ivoa.net/std/ObsCore#<something>-version
>
> If we are refering to a full model, <something> should be null and this
> will let "version" alone, the choice which Mireille did in the last version
> of the draft.
>
> If we are refering to a package or "sub data model", as we have in
> "ivo://ivoa.net/std/ObsCore#core-1.1" proposed by Pat, we imagine that we
> can have
>
> "ivo://ivoa.net/std/ObsCore#parts-1.1" and other things like in Pat's
> example.
>
> But this is not part of OBscore yet. maybe it will be in OBscoRE 2.
> Maybe it will be another model or view or package of the dataset metadata
> model.
>
> So we cannot be sure that
> "ivo://ivoa.net/std/ObsCore#parts-2.0" will be valid in the future...
>
> In addition if we are giving ivoid for data model packages there is the
> tag <datamodel> apptropriate.
>
> This tag should be for general information on the datamodels involved
> in the tap service. Details will come with the tap schema which we can
> retrieve from the TAP service.
>
> Cheers
> François
>
>
>
> Le 15/09/2016 23:52, Mark Taylor a écrit :
>>
>> 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/
--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada
More information about the dm
mailing list