utype questions

[Doug Tody]

Hi Norman -

I only had time to look quickly through your document and will try
to give it a more careful read before the interop.  But as the one
who (along with Francois O.) originally created utypes it might
help to briefly state the original concept and motivation again.
While it is probably true that there are still some issues to be
resolved it is important to not lose track of the basic concept,
which is quite simple.

The purpose of utypes is to "parameterize a data model", that is,
assign unique tags to each field of a data model.  The data model
in question may have some hierarchical structure, and in the process
of parameterizing the data model we "flatten" it, reducing it to
a set of name-value pairs.

The reason we do this is to separate the semantics of the data model
from the representation, to allow the same semantic content to be
reliably represented in many different ways, both externally and in
program structures and containers.  Hence, we can take a data model
instance, parameterize it via utypes, and store the resultant data
in the fields of a table, in a parameter set, in a hashmap in Java,
or even in a FITS header (provided unique FITS keyword names are
associated with the utypes, as for example in SSA).

As you suggest, a data model composed into utype-value pairs in this
way is a lot like an object property, and is used in much the same
way.  So for example we can take WCS keywords from a FITS header and
instantiate a WCS object, using getters and setters in our application
to use or modify the WCS.  Or we can store the same WCS in the fields
of a table, and create the same WCS object instance, using the utype
tags to identify the properties of the stored data model instance.
The same WCS instance could be stored in a flat parameter set.
There are many other such examples,

Since the purpose of utype tags is to simplify manipulation of data
model instances by providing a simple keyword-value mechanism, we do
not want to parse utypes as this would defeat their whole purpose.
Rather we require that simple (case insensitive) string equivalence
be usable to get/set individual utypes.

Utypes pertain to a specific data model hence have a namespace,
indicated with a prefix, e.g., "ssa:Target.Name".  There are various
complexities associated with namespaces and data model reuse etc. which
I won't go into here, but clearly it is useful since multiple utypes
are used to describe an object, to identify the object (data model)
type with a namespace.

That is the basic concept.  The kinds of issues that keep coming up
are things like data model complexity and modularization, runtime
navigation of containers, and length of utype strings.  These are
too complex to get into in a short email, but very briefly, I would
suggest that: the solution to data model complexity is to aggregate
simpler component data models; a UFI type mechanism can be used to
provide runtime navigation of a votable (in general different types of
containers will require different mechanisms); utype string length is
not an issue so long as data model complexity is kept under control
by modularization, plus we have other tags such as ID and NAME which
can provide shorter tags within a controlled context.  Examples of
all of the above are already in use in implementations and code today.

 	- Doug




On Tue, 12 May 2009, Norman Gray wrote:

>
> Greetings, all.
>
> I am often confused about what utypes are and are for, and when I
> talk to people who claim to be less confused, they give a variety of
> very certain and confident answers, which are rarely compatible with
> each other.  These incompatibilities are not merely differences of
> opinion about syntax, but appear to represent fundamentally different
> perceptions of how utypes are scoped and designed.
>
> I've collected a number of my puzzles about utypes into a single document, at
>
>   http://nxg.me.uk/note/2009/utype-questions/
>
> I don't think these are necessarily hard questions.  The problem is that some 
> of them have multiple obvious answers, which are incompatible, and all of 
> which I've heard represented as The Consensus.  I don't believe this is a 
> secure basis on which to build a robust standard.
>
> I hope the questions are useful.
>
> All the best,
>
> Norman
>
>
>