utype questions

[Norman Gray]

Doug, hello.

On 2009 May 12, at 16:54, Doug Tody wrote:

> 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

Then that turns into a formal requirement that the properties utypes  
represent, or the objects with the types the represent, can be present  
in a description only with a cardinality of zero or one.

That provides in turn an explicit articulation of The Uniqueness  
Problem: given a data model, is it feasible to generate a usable set  
of utypes which can reconstruct the data model under this restriction?

It's a pretty severe restriction.  If it weren't there the problem  
would be solvable almost trivially.

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

I get the feeling there are multiple accounts of what 'their whole  
purpose' is.  But that could be just my misunderstanding.

I'm not proposing parsing anything, by the way.  I was very careful to  
avoid proposing anything in the note I posted, but simply to point out  
what appear to me to be unanswered but significant questions.  I can  
see that in some cases (for example utype equality) each of the  
initial answers is unattractive to someone, but ... answers don't  
become any less unattractive by failing to ask the question!

> UFI [...] 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.

I appreciate it's a complicated issue.  But that's sounding like a  
large number of distinct elements to nibble at different parts of the  
problem, which means that keeping things consistent, intelligible, and  
free from ad-hockery, across multiple applications and disparate  
projects, could potentially become quite difficult.

Best wishes,

Norman


-- 
Norman Gray  :  http://nxg.me.uk
Dept Physics and Astronomy, University of Leicester