ObsCore target name column and VO prefixes

[Alberto Micol]

<ad>
Have a look at Bruno's
http://www.ivoa.net/internal/IVOA/InterOpNov2009DM/sample.html
</ad>
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.

(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:

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.

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
http://www.ivoa.net/internal/IVOA/InterOpNov2009DM/utypes_2009_rino.pdf

BUT PLEASE SEE A RUNNING EXAMPLE FIRST at:
http://www.ivoa.net/internal/IVOA/InterOpNov2009DM/sample.html
and imagine that to be a IVOA-maintained repository.
(Excuse my ad again...)
Wouldn't that be useful to everyone?

Alberto
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  
> "target".
> 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  
> of
> 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