ObsCore target name column and VO prefixes

[Doug Tody]

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

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

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