UCD question: how to specify reference to a flat field image?

[Brian Thomas]

On Tuesday 28 October 2008 08:46:09 am Andrea Preite Martinez wrote:
> Hello Brian,
> 
> remember that there is a service to help build ucds at
> 
> http://vizier.u-strasbg.fr/UCD/cgi-bin/descr2ucd
> 
> that works in a lot of cases.
> If you input  "flat-field calibration file"
> 
> you get:  instr.calib;meta.file
> 
> and a list of other possibilities.

Thanks Andrea, I think this has been the best suggestion/solution so far to my issue.

Nevertheless, I am chagrined that the 2 UCD which best (I think) describe
my data are both secondary in nature, and by strict interpretation of the rules,
not an allowed combination.

It makes me wonder if there is any utility in having 'primary' or 'secondary' UCDs 
in the first place? Most (if not all) other semantic tagging schemes appear to lack
this requirement, yet function quite well in practice.

Obviously, if no ordering were required, my example, 'flat-field calibration file", could be 
additionally expressed as "meta.file; instr.calib", so that a search for this bit of metadata 
would have to look for both UCD (2 possible matches).

Surely a parser can be build smart enough to understand the semantics without 
worrying about ordering. Is there some worry that too many possible combinations
will be allowed that ordering now prevents? 

I can't imagine it is a case that simple (exact) string match is required because users (scientists)
will only try one combination, or tools are too simple. Really, how many scientists are 
going to read the UCD spec, and then order their UCD-based query properly in whatever tool? 
Conversely, if the tool prevents the improperly ordered query, then it seems to me to be about the 
same amount  of work as simply having the tool initiate 2 queries (ordered differently) which could 
match data or (better) making the repository match the query regardless of UCD ordering.

But then there is the fact that we have 'Q' type UCDs, which may take any place in the sequence, which
means that we have to disregard ordering anyways in a search (either the user will try multiple queries
or the query tool/repository will have to look in either primary or
secondary slot to ensure a match), so the tools must already be enabled to handle 'orderless' UCD 
matching.

All of this leads me to believe there is small (if any utility) in ordering of the UCD's which label data.
Perhaps someone could illuminate me as to what I may have missed that makes this desirable?

Cheers,

-brian