New release for Obscore 1.1
Laurent Michel
laurent.michel at astro.unistra.fr
Fri Sep 23 11:43:59 CEST 2016
Dear all,
The Obscore IVOID is meant to say that a resource (a TAP service e.g..) supports this model.
There is an ambiguity in a sense that Obscore is both a model an a table implementation, but it is acknowledged that a TAP
resource supporting Obscore 1.1 (ivo://ivoa.net/std/ObsCore#core-1.1) will expose a table named ivoa.obscore with the desired
columns.
If a future version of Obscore (ivo://ivoa.net/std/ObsCore#core-2.0 e.g.) requires 2 tables (ivoa.obscore and ivoa.parts e.g.),
TAP resources supporting Obscore 2.0 will have to expose those 2 tables because they are required by the standard.
My trouble is the exact meaning of an ivoid such as ivo://ivoa.net/std/ObsCore#parts-2.0. Does it mean that the service is just
exposing the table ivoa.parts which is a component of Obscore 2.0? How should a client interpret this?
This interrogation was the reason why we clumsily suggested to go back to ivo://ivoa.net/std/ObsCore#1.1. This id refers to a
model version which has no option and extra capabilities either.
I agree with you to put back ivo://ivoa.net/std/ObsCore#core-1.1 for Obcore 1.1 and ivo://ivoa.net/std/ObsCore#core-X.Y for
Obcore X.Y; but I'm still not seeing any consistent way to use some vocabulary to prefix the version number while we are taking
about models. If we would do so, we would have to define and validate sub-models with their own ivoids.
Cheers
LM
Le 20/09/2016 à 00:55, Patrick Dowler a écrit :
> 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/
>
>
>
--
jesuischarlie/Tunis/Paris/Bruxelles
Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
laurent.michel at astro.unistra.fr <mailto:laurent.michel at astro.unistra.fr>
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg
http://amwdb.u-strasbg.fr/HighEnergy/spip.php?rubrique34
More information about the dm
mailing list