New release for Obscore 1.1
Patrick Dowler
pdowler.cadc at gmail.com
Fri Sep 23 21:09:19 CEST 2016
You can think of the fragment as an opaque string that is defined in
the document. For example we could just say the current one is
ivo://ivoa.net/std/ObsCore#flubber
Anyone who sees it can strip off the fragment, look up the ivo-id in
the registry and find the record for the standard. There will be one
or more documents listed. They read the documents and find out what
"flubber" means. In this case it means you have the ivoa.ObsCore table
in the document for version 1.1. A client (topcat) could easily deal
with #flubber and really would not care aside from it is meaningless
so easier to make mistakes that are hard to see at a glance. The
reason to use #core-1.1 instead of #flubber is that it is more
readable to humans.
I think of "core" to mean "mandatory" so #core-1.1 means "the stuff
that is mandatory in 1.1" which is a single table (also with Core in
the name) and a set of columns. In 1.2 we could add more mandatory
stuff and define #core-1.2 (that could be more columns and/or more
tables) *or* we could define something optional, in which case
#core-1.1 does not change meaning and we have to define a different
fragment for the optional thing.
So, #core-1.1 is safe for now and how it evolves depends on what we
add later, if anything.
On 23 September 2016 at 02:43, Laurent Michel
<laurent.michel at astro.unistra.fr> wrote:
> 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
--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada
More information about the dm
mailing list