UType proposals

[Doug Tody]

Hi Norman -

This discussion is getting very long and involved so I will only
respond to your first few points for now.  I will try to respond more
fully later after I have time to read your full message carefully and
try to synthesize it down to whatever the key points or disagreements
are.

On Thu, 18 Jun 2009, Norman Gray wrote:
> The problems with the current informal UTYPE usage are:
>
> * The UTYPEs are unversioned -- there seems no provision for v1.1 of a UTYPE

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.

> * The UTYPEs are 'dead' strings -- they don't lead to documentation or 
> further machine-readable information.  We live in a networked world, and it 
> seems perverse to ignore that.

UTYPEs are used to tag data model elements, identifying the field
of the associated data model they refer to.  While it could be
useful to resolve a single UTYPE into some help text, in general
one will want to understand the full data model, and will need to,
to understand the meaning of an individual data model attribute.
The issue of how to gain access to online information about the data
model is important and something we should address, but there are many
ways to deal with this (referencing a data model schema for example,
calling a lookup service, resolving a UTYPE into a URL via some rule,
etc.), without having this fundamentally drive how we specify a UTYPE.

> * There is no underlying model for UTYPEs, beyond the vague assertion that 
> they 'point into a data model'.  The current UTYPE documents go into some 
> detail about the punctuation within a UTYPE, but don't even approach such 
> basic questions as 'is this a property or a type?'  This means that things 
> like the composite UTYPEs of Mireille's draft (the ones with the semicolon, 
> which I believe are eminently defensible) are introduced without any 
> framework for a discussion of what is actually going on here.  Without some 
> such framework, there is nothing ahead but muddle.

I agree that we do have some finer points regarding UTYPE usage
to resolve, but in general it is up to the context (data model or
whatever) which uses the UTYPEs to define their meaning.  We have
fairly well developed concepts for how to map a set of classes
to UTYPEs for example; SSA/SpectrumGDS, Char, SimDB, etc. do this
already and it is pretty straightforward.

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

> I take it that a UTYPE standard is intended to be useful for the next two to 
> four decades of developments on the web, and larger, more intricate, and more 
> heterogeneous datasets in astronomy. ...

It is a mistake to assume that we should be Web-centric about the
facilities we provide for processing astronomical data and manipulating
science data models.  Data models are abstractions which are technology
neutral.  In general processing modules in science software should not
know anything about how they are being used, and we often want such
software to survive many years of evolution of external infrastructure
technology such as the Web.  We also have plenty of cases where we want
such software to be able to function without an Internet connection.
We have many other similar cases like this, e.g., UCD and Unit are
also not Web-centric in any way.

Cheers,

 	- Doug