UTYPEs and UCDs

[Martin @ ROE]

David Berry wrote:

> Jonathan,
> 
>>Now Gerard and Pat (and maybe even Brian?) would say, I imagine, that
>>the right way to do this in a data model is not to use UCDs, but to have
>>separate classes for each physical concept. What that loses, for me, is
>>the fact that for a broad group of applications the two different
>>observables `flux density' and `surface brightness' and the two
>>different coordinates `wavelength' and `frequency' will be handled by
>>software in the same way; all we care about for many purposes is that
>>it's a one-dimensional array, not what the axes are. 

I know you're saying that most times a lot of software is just dealing 
with primitive values, but from the VO's data modelling point of view we 
have to be more careful.  You might just be plotting wavelength against 
something, but if some of your quantities are arriving as wavelength and 
some as frequency (with associated Accuracy, resolution, etc), then from 
a software point of view it might actually be easier to handle separate 
classes that 'know' how to transform into each other, rather than UCD 
dictionaries.

>>Using a model in
>>which the commonality is explicit and the differences are handled by
>>having the UCD attribute with different values instead of by having
>>different classes is a compromise between
>>old-style-everything-hard-coded and extreme OO approach; we simplify the
>>problem by having relatively few software classes and handing the hard
>>work over to the UCD definition list.
> 
> 
> I agree with this view. There are many potential classes of Frame
> in which the only difference would be the associated UCD, and it makes no
> sense to define different classes of Frame for them all. My only point
> would be that there *are* some Frames which require extra information,
> for instance a SkyFrame will have different properties to a FluxFrame.
> So having a UCD as a component of Frame will cut down a lot on thenumber
> of sub-classes of Frame which we need, but it will not reduce that number
> to one!

Yes - certainly we don't automatically need a new class for every 
existing UCD.

I think there is still room for UCDs to describe something about the 
context of an object (eg is this a position of an image, or a position 
of a star, etc) when that context is not otherwise present.  But we 
should build our object models with structure and purpose (of those 
objects) in mind; I don't think that has anything to do with UCDs.

My feeling is that an object model combined with UCDs should allow us to 
do all the ontology-related stuff we wanted to do last year, but I'm 
ignorantly naive about ontologies.

> 
> 
>>I haven't assimilated the 50 mails that happened while I was at lunch;
>>more this evening.
> 
> 
> Hope is in sight - Europe is going out to the Pub shortly!

In fact I'm off!  You'll all get some peace and quiet now until I get 
back.  Make sure you read all the emails and do your homework.... :-)

-- 
Martin Hill
www.mchill.net
07901 55 24 66

-- 
Martin Hill
Software Engineer, AstroGrid (ROE)
07901 55 24 66