ObsCore target name column and VO prefixes

[Francois Bonnarel]

My late comments on that.
Doug Tody a écrit :
> (Getting back to this between trips...)
>
> On Tue, 15 Jun 2010, Alberto Micol wrote:
>> I think obs_target is a less-than-optimal choice.
>> Several reasons:
>>
>> (1) target (or obs_target) to me is a category, or to say, an object 
>> class, not a single item.
>> There are various elements within such class: name, class, 
>> description, redshift, etc.
>
> I agree; I spoke too hastily earlier. Target is a class with any
> number of attributes, and we already have this in GDS/SSA for example,
> as shown in Bruno's web page and my earlier SSA data model spreadsheet.
>
>> (2) What would we gain by adding a prefix? What is the purpose? What 
>> does it give to us?
>
> This I am less sure about. What we would gain is primarily
> consistency, and grouping of related elements. We should go back
> and look at the overall model (not just the core) and ensure that we
> have a consistent scheme for this. For myself I will wait until I
> have time to review the latest draft ObsDM which Mireille distributed
> while I was away.
I agree with target_name. Dropping the obs prefix is ok because it would 
be nice to start
with something recalling the class name. There are very few attributes 
in the Observation CLASS
itself in the model (a class very similar to Dataset class in SSA).
Anyway we are discussing field names here where the syntax is less 
constrained than for DM names
( = utypes)
>
>> More generally, and way more importantly...
>>
>> In general, even in the case of utypes, I think we should not use too 
>> many prefixes if the concept
>> is well known and well understood by the community. I have heard 
>> several times, for example,
>> that curation.publisherDID could appear in the different models with 
>> a different prefix, as in:
>>
>> obs.curation.publisherDID
>> spectrum.curation.publisherDID
>> spectrum/curation.publisherDID
>> etc.
>>
>> I think this is fundamentally wrong because it multiplies the number 
>> of utypes for one and the same thing.
>> A unique concept should not be identified by a number > 1 of utypes.
>
> There are two aspects to this: data model namespace and the UTYPE
> itself. We still need to define the data model namespace for a
> UTYPE usage, e.g., "ssa:", "spec:", "obs:", and so forth, in order
> to define the context where the component data model is used, and
> to manage versioning. But I agree that "target.name" rather than
> "spectrum.target.name" or whatever is sufficient within such a name
> space (e.g. this is what we did in SSA).
>
Doug (and Mireille in her mail, included below) are right. Prefixes in the
field name and name spaces are different things. The latter is informing
on the data model we are using.
> In general we cannot guarantee that data model elements and their
> semantics will be identical in all contexts, because this does not
> support versioning or permit different software to evolve at different
> intervals. Of course we want to try to update things and resolve
> any inconsistencies when the next major version of an interface is
> generated, but in general there can be differences in the usage of a
> data model in different contexts or versions. Hence a global table of
> component data models and their UTYPEs is useful but not sufficient;
> the ultimate authority must remain the specification for whatever
> application or interface uses the data model (unless this defers to
> some external spec).
>
> - Doug
>
>
>
Excerpt of Mireille's mail, June 30th :

> What I suggested in Victoria for Utypes and class re-use from one 
> model to another is:
> 1- use a data model prefix for any utype and point to a document 
> covering the definition of the utypes of a specific version of a 
> specific model.
>
> In the example above, there will be only one class 'Curation' , reused in
> ObsCoreDM, SpectrumDM, etc.. corresponding to the following utypes:
> obs:curation.publisherDID
> spect:curation.publisherDID
>
> for the Observation class in ObsCore we would have
> obs:Observation.calib_level
> obs:Observation.dataproduct_type
>
> when this class combines other classes , then we will have
> "obs:Observation.curationRef" that points to the proper curation 
> element for this observation
> whose utype will be "obs:curation".
>
> or we could just include all below "obs:Observation." but then utypes 
> will be long.
>
> What ever strategy we adopt, in the serialisation of these metadata 
> for a set of, let say 10 observations , we will need to link one 
> particular observation to its components
> and not have sets of curations elements separated from sets of 
> observations (image,spectra, lightCurve, etc.)

> Mireille

-- 
=====================================================================
François   Bonnarel           Observatoire Astronomique de Strasbourg
CDS (Centre de données        11, rue de l'Université
astronomiques de Strasbourg)  F--67000 Strasbourg (France)

Tel: +33-(0)3 68 85 24 11     WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 68 85 24 25     E-mail: francois.bonnarel at astro.unistra.fr
---------------------------------------------------------------------