UCD use cases
tam at lheapop.gsfc.nasa.gov
Tue Oct 21 12:51:17 PDT 2003
Here are some thoughts about how the new UCD scheme I've
proposed might help in Roy's scenarios. I'd sent
this to Roy directly earlier without realizing
that it had been sent to the UCD and DM groups....
> (1) Cone search. How to decide which columns are the RA,Dec that was used in
> the search. What frame (B1950, J2000, ...) do these come from? If there are
> columns with ID, what sort of ID is it, and how do I resolve it?
UCDtrees look something like:
ra/dec, l/b columns
pos.coosys;value Optional, either table coosys element
of the table or a table wide parameter
Look for highest pos;instance and meta.id;value to get the correct id and pos columns.
If we want to handle B1950 coordinates then we need to include a table parameter
or parameters including the coordinate system. Of course the cone search protocol
requires that the output be in J2000, but it would be easy to support genericity
if we want. I suggested that the coosys element in tables could have a UCD, but
less controversial would be a table parameter giving the information. That's not
quite as elegant. However I don't like duplicating metadata information. Maybe
the best solution is to include a parameter but make it point to the coosys using
the XML ID.
Not sure what you mean by resolve the id, but assuming that this isn't addressed
by specific subtypes of id, replace meta.id;value with
meta.resolver;value would presumably be a parameter but in principal if there
was a different resolver for each row in the table it could be a column.
> (2) SIAP search. Find the column that contains the URLs where the images
> are. Find out if there are other columns that have RA,Dec of the image
Basic UCDTree is:
meta.id;value # The required id field
meta.link;value # The link field
pos;instance # The required position
These are mandated columns in the SIAP protocol and the protocol should
also specify that there is only one pos, meta.id and meta.link element
at the top level. Note, by the by, that if we want to allow the SIAP protocol
to return galactic positions, it's easy to do. [This isn't necessarily a
good idea for SIAP, but the it shows the expressivity of the UCDTrees.]
Could there be an image center that is distinct from this image? This would
require there to be an associated observation to the main observation.
[If I really want to go overboard I might have made the table UCD
but I don't think that that is going to be useful to most people,
though it does show a nice use of my suggested filter hierarchy.]
This could be suggested by adding the following to the tree
The issue which is harder to address is understanding the relationship between
this secondary observation and the primary observation. This is a semantic issue
not a structural one, so a UCD must be involved. E.g., we need to define
concepts for background, center, offset, ... If we have done that (and I would
suggest they belong in my meas tree since they have to do with idea of a measurement)
then the previous addendum becomes [and I've put in a background image for good measure]
How do I find this... I look for associated observations and search for
one which has the desired measurement attribute. I believe an XQuery expression
can do this pretty easily.
> (3) We have for example a crossmatch service that is clever enough to know
> about error ellipses. How does it get from a table the most sophisticated
> error info that is there: (a) position (b) circular error (c) ellipse error.
This is pretty easy...
Looking just at a given position, we might have:
pos.eq.ra;meas.error Errors in the coordinates
pos;meas.2d.error This is a circular 2-d error
which gives all three of these. While there may be
a better name for the last two errors, I don't think it matters
much. Whatever error there is is directly associated with the position
and it's easy to find out what errors are availalbe. The question
of which error the user should use, is not appropriate for
the UCD scheme. That's up to the user. The UCDs indicate
which errors are available.
I'm not sure if we want to elaborate the measurement tree
to this level, maybe it could be done more simply in some other way.
However I don't think this is an unreasonable approach.
> (4) We want to compare photometry in two tables covering the same star
> cluster. How do I decide if they share measurements in the same filter? One
> has R band, the other has Halpha. What happens if fluxes are expressed
> differently -- eg number / energy /
> magnitude / luminosity density.
Well I don't think unit conversions are an issue that UCDs should address.
So I'll pass on that. [That's what units keywords are for after all.]
The columns should describe the bands in which they were taken. If
we want to assure that we actually have the same filter, then we
need UCDs that are specific down to the filter level. The old UCD tree
(and I assume you've kept it in the current one) puts all of that info
in the initial word. I'd tend to use the em modifier here to define
the band. E.g.,
for magnitude, flux and counts (in a photon counting instrument)
If the question is whether the filters overlap, then I don't think
this is a question the UCDs answer directly. It's expert knowledge
about the concepts (Just like the exact relationship between RA and Dec
isn't specified in the UCD. That's expert knowledge too.)
> (5) I want distances to stellar objects measured in meters, so I can make a
> 3D display for the children. How do I recognize a redshift (z) value, how do
> I recognize a radial velocity, how do I recognize an actual distance
Units are not a UCD issue.
The other questions simply need distinct UCDs. As I understand the schema they
would just be different elements of the phys tree but that's a bit of a guess.
Redshift is a different concept from distance as is a radial velocity. They can
be converted into each other in certain circumstances, but it is not the role
of UCDs to understand the transformation rules -- just as it is not the role
of UCDs to understand how to convert from RA,Dec to L,B. I think it may be reasonable
to have all of the base concepts:
phys.distance A distance of some kind
phys.distance.z A redshift in a cosmological context
phys.distance.vrad A radial velocity in a cosmological context
phys.z A redshift in non-cosmological context
phys.vrad A radial
or to only have the single distance concept and leave it to the user to recognize
that they are in a cosmological context so that radial velocities can be converted
to distances. That's probably safer from the context
of trying to ensure that there is only one UCD for a given concept so I'd
tend to go that way. Users put z in a table rather than distance for a reason.
UCDs describe what a column is, they need not and should not describe what you
can do with a column. I gather that is the role of ontologies.
> (6) I am looking for supernovae that have both optical and Xray
> measurements. Can I (should I) use UCD to help my search?
You can certainly try. This depends a bit upon the specific UCD tree.
If table UCDs are often of the form
you can search the registry for tables of the form
Similarly ou can use search columns the phot and look for
optical and X-ray qualifiers. If you get tables that meet all the
criteria you've got a great place to start. I.e., look for UCDTree
that matches the template
[Where this is some Xqueryish kind of match to the UCDTree hierarchy]
and you've got a great chance that this has the information you wnat.
Even if there is no match, you can consider tables that are partial
hits and look to see if you can join information appropriately using
A real win here would be a VO service to enable comparison of class
information among tables. Right
now source classes are a real mess and we need a Simbad- or NED-like service to address
it. That will probably be needed if you want to interrogate the vast
majority of UCDTrees that with have src;instance and some classification
> (7) How do I find 21cm observations (that may be redshifted), which also
> have polarization information?
Look for all tables that have columns that match
to get polarization information
Limit to tables that have a flux value in the 21cm region
-- don't know if that has it's own special UCD -- or which has
flux in the region from 10-100 cm and a redshift or radial velocity.
This assumes there is some service that gives me the em qualifiers
I need to look for given a specific energy/wavelength/frequency range.
It wouldn't be too hard by hand either.
This is a straightforward analysis of the column UCDs that doesn't
need to worry about the structure UCDs at all.
More information about the ucd