ObsCore target name column and VO prefixes

[Mireille Louys]

Dear Alberto, dear all ,

I'll give my 2c here too and my contribution in the text below .
Cheers, Mireille

Alberto Micol wrote:
>
> <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.
>
I agree:
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.
>
ok
> 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.
>
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.)


> 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.
>
agreed.

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