UType proposals

[Douglas Tody]

On Fri, 26 Jun 2009, Norman Gray wrote:

>> Not so.  UTYPEs are defined by a data model, and it is the data model
>> which is versioned.  UTYPEs have no meaning unless they are defined
>> by some such data model.  There is always a higher level versioned
>> context whenever a UTYPE is used.  The UTYPEs in SSA for example are
>> defined by the specific version of the SSA protocol in use.
>
> I think this is a key point.  The corollary of this is that SSA UTYPEs will 
> _lose_ their meaning once they're separated from their context, and thus if 
> you want to store the UTYPEs outside of the context of a SSA transaction 
> (such as in a database, or a FITS file, or some other format yet to be 
> invented), then you are absolutely required to retain the link to (the 
> version of) the SSA transaction which initially retrieved the object.  In 
> other words, it means that the SSA _data model_ is closely tied to the SSA 
> _protocol_, which will make it at least inconvenient to reuse it in some 
> different application.

Again, data model attributes are not generally used separately without
any knowledge of the overall data model of which they are a part.
If we could usefully reduce a complex data model to a single value
we could merely define a new UCD and we would not need UTYPEs.

The data model version must be specified in some fashion to fully
understand any data model attribute.  In the case of SSA/Spectrum the
model itself specifies the version via the "DataModel" attribute, e.g.,
"Spectrum-1.0".  A similar approach applies to global units within a
data model.  With a data model there is always some global context
which deals with this problem.  Clearly, the assumption is that a
data model facility should describe an actual data model.  If an
application needs to extract a single attribute for use independent
of the data model that is possible, but implies a reduction to some
more fundamental form.

This discussion still misses the point that it is more important to
specify the version of the entire data model than that of a single
attribute, since we are dealing here with data models, not single
quantities.  Whatever solution we adopt should take this as the first
priority.

> Further, the Characterisation data model isn't even associated with a 
> protocol, so each application's reuse of those UTYPEs would have to specify 
> some additional, ad-hoc machine-readable mechanism for associating the UTYPEs 
> with a document version.  If some application then wanted to use two 
> different versions of the Char'n UTYPEs at once (for example to indicate for 
> compatibility reasons that a particular value was a Char'n v1 Position _and_ 
> a Char'n v2 Position), then it would have to do that disambiguation in some 
> application-specific way.

Reuse of component data models is an important issue, although not in
the sense that you suggest.  If a data model is big enough to require
a separate implementation then it should stand on its own as a full
up object (including verisoning etc.).  Otherwise we reuse component
data models by incorporating them into models such as SSA/Spectrum or
GDS/Observation, etc., much in the way that code is often reused.
In this case we have a new model which in a sense inherits the
component data model.  *Not* in the sense of fully general class
inheritance, since we do not want to reinvent something as complex
as C++, but rather the model is incorporated into the larger model
and the definition of the overall model is what applies.

>>> Although they should of course be informed by implementations, standards 
>>> do not exist merely to 'document current practice'.
>> 
>> It is not just a matter of implementations.  We have a number of
>> standards already in use which define UTYPEs.  While we might refine
>> the concept and usage of a UTYPE, we cannot afford to invalidate
>> existing VO standards and their implementations (aka "current
>> practice"), unless their is a very compelling reason to do so.
>
> The point of this current exercise (I take it) is to retrospectively clarify 
> what UTYPEs are.

Sure.  The point is to further refine the concept and usage to make
it more rigorous, to avoid confusion and possible ambiguity.  Not to
replace it by something else, at least not without a very compelling
justification.

 	- Doug