ObsCore target name column and VO prefixes
amicol.ivoa at googlemail.com
Tue Jun 15 02:41:09 PDT 2010
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
> 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.
(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.
(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,
and not for the longish obs_target_class, obs_target_description,
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:
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.
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
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?
PS: Next time I should remember to attach a jingle...
On 11 Jun 2010, at 19:41, Patrick Dowler wrote:
> In the latest draft, Table 2 says "obs_target" and section 4.9 says
> I cannot recall why I changed the column name in Table 2, but it may
> have been
> to remember to discuss and then I forgot to bring it up.
> Any preferences for this column name? In the model, Target hangs off
> Observation, so maybe obs_target is better for consistency?
> Patrick Dowler
> Tel/Tél: (250) 363-0044
> Canadian Astronomy Data Centre
> National Research Council Canada
> 5071 West Saanich Road
> Victoria, BC V9E 2M7
> Centre canadien de donnees astronomiques
> Conseil national de recherches Canada
> 5071, chemin West Saanich
> Victoria (C.-B.) V9E 2M7
More information about the dm