Are UCDs Metadata?

This is a response to Guy's RefactoringUCDs and UCDAtomsPreliminaryList and Anita's WhatAreUCDsFor. I'm not sure how qualified I am to make this response - as a non-astronomer I don't understand how terms should be combined to be meaningful - but as a long time data and systems analyst, some of my experience may prove useful.

I was wondering if the UCDs need to be as long as they are. In commercial systems, if I define a table of customer data and call it CUSTOMER then add a column for the name of the customer, I'd call the column NAME, not CUSTOMER_NAME. The idea being that the name of the customer occurs only in that table - if you need to print the name of the customer on an invoice, you use the CUSTOMER_ID on the invoice to link back to the customer table and retrieve the name.

In atomic UCDs, this relates to Anita's use of INST_, OBS_ etc. I can see that this would be necessary if a table has both instrument and observational quantities in the same row of a table, but even so, are there any quantities which would have the same name other than these prefixes? If not, aren't the prefixes redundant.

The same applies to WAVELENGTH. Do we really need to prefix that with LENGTH_? Is a WAVELENGTH ever anything other than a length? If not, the prefix is redundant.

The argument may be that we need to have these expanded column names in order to relate columns with the same meaning in separate tables. But this is unnecessary if people are looking at the data - they can make the relevant mental connections. As for software: should we rely on the sameness of the column names to relate the same data?

My argument would be that it is in the metadata of the instrument, observation and columns that we should put semantic content and not try to bundle it all into the column names.

(I'd say the same for the data. If a piece of data is the same for every row in a table, it belongs in some higher level table.)

If you want to match two quantities in a table, the software should be able to deduce from the metadata for each column, which columns to use, just as it would use the units metadata for those columns to do on-the-fly translation. I know that the software is unable to do that now, but if we are considering changing the way UCDs are used - ie, atomising them - then the software will need rewriting anyway.

So, the answer to the question posed by the title of this page is: Yes, but they shouldn't be. Keep the metadata separate from the column names. It will be easier and involve fewer arguments about what name a column should have.

One side-benefit of such an approach will be that relating metadata terms in an AstroOntology will be much easier than if we try to embed part or all of the metadata into the column names.

-- TonyLinde - 16 Oct 2002

Tony is quite right that the metadata handle for a particular column of data do not need to be long, just unique within that catalogue. The information which is common to all entries in a particular catalogue should indeed be in a header - but it does need to be attatched to the column metadata as required by the execution of a query. Guy's concept of atoms could allow that. What we seem to be doing at the moment is building up a data model out of atoms strung together into UCDs. I think this is valid to help humans understand how to describe data correctly, but as Tony says we should realise that we should probably design the VO to store the different atoms of metadata in something like INST_BANDPASS_SHAPE or SOURCE_FLUX_PHOTOMETRIC_RADIO_1.6G etc. in different places.

However this presupposes the catalogue authors provide the correct information in the right places. In the case of major catalogues, VO curators may be in a position to either influence the catalogue author or add the required information, but for tables from papers we may be stuck with all sorts of anomalies.

-- AnitaRichards - 28 Oct 2002