ObsCore target name column and VO prefixes
mireille.louys at unistra.fr
Wed Jun 30 02:07:49 PDT 2010
Dear Alberto, dear all ,
I'll give my 2c here too and my contribution in the text below .
Alberto Micol wrote:
> Have a look at Bruno's
> You'll encounter this ad again later... ;-)
> On 11 Jun 2010, at 20:52, Douglas Tody wrote:
>> I agree that "obs_target" is preferable. This will then leave us with
>> only "dataproduct_type" and "calib_level" without a class prefix in the
>> core model, which seems appropriate as these are more specific to the
>> ObsCore index itself. - Doug
> 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.
> Hence, obs_target is potentially confusing.
> Is obs_target the target description or the target name? The second
> one. Hence, let's call it with its
> well-established name: target_name.
in ObsCoreDM we are partly re-using the target class defined in SpectrumDM.
Then all items can simply be target_name , target_class, etc... when needed.
> (2) What would we gain by adding a prefix? What is the purpose? What
> does it give to us?
> Let's keep it simple.
> Let's not add prefixes just for the sake of clarity if this means
> multiplying the possibility
> of mistakes when writing or parsing.
> Not that a simple string like "obs_" could add much chances for
> confusion, but I hope you get my point:
> it is matter of principles. And the principle is: let's make things as
> simple as possible, not simpler.
> Following such principle, I would vote for target_name, if that is
> universally recognised as an
> unambiguous concept. (Is it not? if so, I'd like to hear what other
> target name we have in astronomy)
> That would also call for target_class, target_description,
> target_redshift, etc,
> and not for the longish obs_target_class, obs_target_description,
> obs_target_redshift, etc.
> 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:
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
In the example above, there will be only one class 'Curation' , reused in
ObsCoreDM, SpectrumDM, etc.. corresponding to the following utypes:
for the Observation class in ObsCore we would have
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.)
> 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.
Best regards, Mireille
> In general, we possibly need not much more than a simple
> well-maintained central repository of metadata.
> This is what Bruno was suggesting at the Interop in Munich last November.
> Please see Bruno's presentation at
> BUT PLEASE SEE A RUNNING EXAMPLE FIRST at:
> and imagine that to be a IVOA-maintained repository.
> (Excuse my ad again...)
> Wouldn't that be useful to everyone?
More information about the dm