utypes: a proposal

[Douglas Tody]

Hi -

There is no problem with having short-name aliases for Utypes
(data model parameters actually), and this is often done in current
implementations.  Normally though these are only used in a limited and
controlled context, reserving the full Utypes for interchange.  The
FITS keyword aliases for Spectrum are an example, also the shortname
IDs in SSA (https://webtest.aoc.nrao.edu/ivoa-dal/ssap-keywords.xls,
first column "Field ID").  Using short names for interchange might
be possible if the short names were globally unique, and conversion
back-and-forth were easy.

In much actual usage however, e.g., with VOTable, Utypes are often
used for things like FIELD name declarations hence only one copy is
required for the whole table, regardless of the size and number of
rows in the table.  Also, many of the Utypes currently defined are
already quite short (Target.Name etc.).

Perhaps if the Utypes are getting too long and complex the data model
is growing too complex and should be refactored, e.g., into component
models which are aggregated and associated within a container.
This results in smaller models (with short Utypes) which can be more
flexibily used to model more complex entities.  Also, the container
mechanism can then be used to navigate to object instances.

 	- Doug


On Fri, 31 Oct 2008, Roy Williams wrote:

> Paul
>
> Once the utype syntax has been decided, it would be nice if it is possible to 
> do what tinyurl does (tinyurl.com), so that a 80-character utype, all full of 
> dots and colons and semantic wizardry, can be converted to four or five 
> random characters. In this way, utypes could be used effectively in GET type 
> service calls, like this:
>
> http://my.ser.vice.org?h4gys=6.0&u58dj=273&w98kd=yes
>
> It seems that all we do with utypes is string compare and lookup. Is that 
> true? If so, can we at least have a scheme that keeps the names short?
>
> Roy
>
> Paul Harrison wrote:
>> 
>> On 2008-10 -30, at 20:45, Norman Gray wrote:
>> 
>>> 
>>> On 2008 Oct 30, at 16:19, Paul Harrison wrote:
>>> 
>>>> one of Norman's earlier suggestions 
>>>> http://www.ivoa.net/Documents/latest/utype-uri.html.
>>> 
>>> Just to be clear, what I'm suggesting here is independent of this earlier 
>>> one.  I think that some of the advantges of the earlier one would 
>>> naturally attach to this proposal, but in particular the extra explanatory 
>>> structure is not part of what I proposed here.  The utype-as-xpath 
>>> suggestion is purely syntactical.
>>>> 
>> 
>> I have to admit, I am not really keen on the implication that the UType has 
>> anything to do with xml - it should be related to a "purer" representation 
>> of the data model, as championed by the Theory IG. Having the XML 
>> representation of the data model as the "canonical" representation causes 
>> problems because of the design decisions that the vagaries of the XML 
>> schema language force on the data model author.
>> 
>> Perhaps the problem is that there is  a notion that there should be some 
>> way of "reasoning" about the UType from its form, and I think I agree with 
>> Doug that the name might allow a human to make some deductions, but in 
>> general I think that a machine will not be able to make any - this is why I 
>> like your http://www.ivoa.net/Documents/latest/utype-uri.html proposal as 
>> it does allow a way to add back the ability to do some machine reasoning.
>> 
>> To take a concrete example - from the using STC in VOtable document 
>> http://www.ivoa.net/Documents/latest/VOTableSTC.html
>> 
>> <FIELD name="RAJ2000" ucd="pos.eq.ra;meta.main" ref="Coo1" ID="RAJ2000" 
>> utype="stc:AstroCoords.Position2D.Value2.C1" datatype="float" precision="4" 
>> unit="deg" />
>> When writing software to read this, what are you going to do with the UType 
>> here? You could mechanically decompose it and build an STC document that 
>> you then parse, but that would seem a little perverse - more likely you 
>> will want to directly parse the values into an internal representation of 
>> the STC model, an in which case the most likely implementation will be a 
>> direct mapping of the UType as a whole to the internal model. This example 
>> also shows that the amount of semantic information that a human can read 
>> from the UType is also highly dependent on the data model - in this case 
>> the UCD is more semantically precise than the UType (which only says that 
>> it is the first coordinate of a 2d position), making the UType somewhat 
>> redundant, and the software is already going to know the correspondence 
>> between the UCD and the position in the STC data model. This makes me 
>> wonder whether UTypes and UCDs are really fulfilling distinct roles.....
>> 
>> Cheers,
>>     Paul.
>> 
>
> -- 
>
> California Institute of Technology
> 626 395 3670
>