UCD use cases

[Thomas McGlynn]

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....

	Tom


> 
> (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:
     src;instance
         meta.id[.type];value
	pos;instance
             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.id;instance
	     meta.id;value
	     meta.id.resolver;value

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
> center.

Basic UCDTree is:

       obs;instance
	   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
        obs;filter.cutout;instance
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
            obs;instance
                 meta.id;value
                 pos;instance

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]
	   obs.instance
		meta.id;value
                 obs;meas.center
			pos;instance
	   obs.instance
		meta.id;value
		obs;meas.background
			pos;instance


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;instance
	pos.eq.ra;value
	pos.eq.dec;value
	pos.eq.ra;meas.error         Errors in the coordinates
	pos.eq.ra;meas.error
	pos;meas.2d.error            This is a circular 2-d error
	pos;meas.2d.error.elliptical;instance
              pos;meas.2d.error.elliptical.x
              pos;meas.2d.error.elliptical.y
              pos;meas.2d.error.elliptical.posang
	

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.,

      phot.mag;em.optical.filter.v.johnson;value
      phot.flux;em.optical.filter.v.johnson;value
and
      phot.counts;em.optical.filter.v.johnson;value
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
> measure?


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
     src.[type];instance
you can search the registry for tables of the form
     src.supernova;instance

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

    src.supernovae;instance
    //phot*;em.xray*;value
    //phot*;em.optical*;value

[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
multiple tables.

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
parameter inside.

> 
> (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
     flux.phot*;em.pol*;value
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.