DeepFieldSurveys analysed for registry requirements

Stages in the DeepFieldSurveys Science Case . See also DeepFieldSurveysSD (Sequence diagram) but note the order of steps may be slightly different in this.

This science case predates the AVO First Light demo, but as this used the GOODS data for which there is the Aladin data server tree basd on the IDHA data model (see data model VOTable description, these requirements should be compared with that (comments in italics below, including things which should probably be added to the ResourceMetadata Schema).

1. RegistryQuery for DataSets covering a known Deep Field position

   INPUT: User Criteria:

   • DataSets with a minimum astrometric and photometric accuracy and resolution (do this first to avoid having to check too many catalogues for angular coverge)
   • Angular region of sky of interest (less than c. 1 square degree).
   OUTPUT: List of DataSets

2. DataSets processing to find a data set to provide sources for astrometric alignment

   INPUT: List of DataSets from 1. and user criteria for DataSets prioritisation and source selection.

   • The user might want the data set with the most accurate absolute positions or with a certain balance of position accuracy and source density/likelihood of counterparts at other wavelengths.
   • The data set selected might be a catalogue, or might require source extraction from images.
   • If extracted from images, sources should meet certain criteria e.g. posess a compact bright feature.
   • Additional catalogue information might be used to reject unsuitable sources e.g. Galactic sources, sources with a classification suggesting extension or very different structure at different wavelengths such as radio FR2s.
   • Maximum size of image which can be directly handled (e..g above this size, send to cutout server!).

   OUTPUT: A list of sources with good and unambiguous astrometry - store as MySpace catalogue

3. DataSets selection to provide the list of scientifically interesting candidates

   INPUT: List of DataSets from 1. and user defined criteria e.g. for containing candidate high-redshift galaxies such as:

   • Catalogues of optical colours
   • Sensitive radio images
   OUTPUT: List of DataSets

4. RegistryQuery to attain access to tools for astrometric alignment

   INPUT: User request (human or automatic)

   • This could request an automatic process (see [http://wiki.astrogrid.org/bin/view/Astrogrid/HDFNorthAstrometry][HDF(N) Astrometry etc.]] for suggestions)
   • Or an interactive process e.g. Aladin
   OUTPUT: A route to suitable services

5. DataSets processing to align the DataSets selected in 3. with the astrometric reference sources from 2.

   INPUT: MySpace catalogue from 2. and datasets from 3. and service from 4.
   

   • Cone seach DataSets using catalogue
   • Apply criteria to eliminate inherantly inaccurate matches (e.g. objects with no clear core)
   • Apply tools for alignment
   OUTPUT: A matrix of offsets or a single shift to be applied to the positions in the DataSets from 3.

6. DataSetQuery/Evaluation to provide the source list used as science starting point

   INPUT: List of DataSets from 3., corrections from 5. and user defined criteria e.g. properties of high-redshift starburst galaxies or user's own list

   • Could be for selection from a catalogue e.g. list of optical sources with very red colours
   • Could be an existing list uploaded by the user.
   • Could require source extraction from images e.g. radio sources <100 microJy
   OUTPUT: A list of interesting sources identified by position, and properties extracted at this stage (e.g. colour or radio flux density).

7. RegistryQuery to find catalogues giving relevant properties (e.g. from publications)

   INPUT: DataSets from 1. and user list of properties e.g. redshift which can be interpreted as UCDs
   OUTPUT: List of catalogues containing such properties

8. DataSetQuery/Evaluation to find known properties of the interesting sources

   INPUT: List of sources from 6, DataSets from 7. and properties to be found e.g.

   • Redshifts
   • Spectral energy distribution
   • Flux density below certain limits at certain wavelengths
   • Source morphology
   • Cone search catalogues with such properties
   At this stage further iterations of astrometric alignment may be needed and also analagous processes for photometric alignement (the latter may also require reference to DataSets describing the properties of the instrument or observation). Also access to other external packages e.g. statistical.

   OUTPUT: List of sources from 6 plus new properties/values and uncertainties and/or probabilities of position-based identification.

9. DataSetQuery/Evaluation to find more new properties of the interesting sources

   As 8. but involving extracting information from images, e.g. using the SED to get a photometric redshift.

10. Catalogue evaluation to classify candidate sources

    INPUT: List of sources from 7. with properties from 8., 9. plus user-defined or library models defining relevant source type e.g. dust-enshrouded starburst galaxy and statistical/number-crunching packages.

    OUTPUT: List of sources with probability that they are high-redshift starbusts galaxy (or whatever).

11. Alternative criteria for 'interesting' e.g. searching for asteroids

    This was another part of the AVO Demo and involved looking for sources only seen at one epoch at a given position but appearing at a nearby position at successive epochs. This could be done by source sorting or by giving different epochs different false colours, mkaing a colour composite and looking for outliers. This requires the same steps as above e.g. good relative astrometry and photometry of optical data, various packages and also

    • Time resolution and accuracy better than certain levels
    See Brown Dwarf case for more about proper motion determination requirements.

Deep Field Science Resource Metadata requirements

using the terms in DataServiceSchema.

content "facility"
content "instrument"
content "format" value = "ascii", = "VOTable", = "FITS"
content "ndimdatasetsizemin" value = decimal
content "ndimdatasetsizemax" value = decimal
content "nndimdatasets" value = integer
content "type" value = "catalogue", = "survey"
< content "subjectkeyword" value = "Null", = "Galaxies", = "Milky Way", = "Solar System", = "Stars"

coverage "wavelengthrange" value = "radio", = "mm", = "ir", = "optical", = "uv", = "xray"
coverage "wavelengthshort" value = decimal
coverage "wavelengthlong" value = decimal
coverage "decmin" value = decimal
coverage "decmax" value = decimal
coverage "ramin" value = decimal
coverage "ramax" value = decimal
AVO Tree uses central position and radius coverage "sensitivity" value = decimal
coverage "startdate" value = decimal
coverage "enddate" value = decimal
coverage "angularfraction" value = decimal
coverage "sourcedensity" value = decimal
The AVO tree uses slightly different names for these elements, compared with Keith's schema and/or Hanisch et al. - how far is it worth homogenising these?

resolution "angularresolution" value = decimal
resolution "spectralresolution" value = decimal

dataquality "astrometryerror" value = decimal dataquality "photometryerror" value = decimal dataquality "timingerror" value = decimal

UCDs

Exact terms awaiting adoption of a convention, see the AVO tree etc. for an example of a more detailed implimentation. This does assume that we will be able to generate unique UCDs e.g. for 'ID' or 'Error' by using a hierarchy of XML elements, attributes etc.

• Identifiers for observations, (sub)fields, epochs, etc.
• Terms describing astrometric and photometric accuracy, resolution etc. (these may be functions of other properties of the same dataset e.g. distance from centre) (
• Terms to allow searching catalogues of instrument properties etc. if necessary (e.g. for zeropoint for conversion of magnitude to units which can be compared across different insruments or wavebands)
• Terms for the processing state of nDim data, e.g. 'raw', 'calibrated visibility data', 'processed image' and to allow interfaces to processing if necessary/possible to produce the required image or other product. The AVO tree uses ObservingProgram as the root note
• Terms describing images so that they can be displayed and information can be extracted and compared across wavebands
• Terms which can be linked to definitions of filters/bandpasses etc. (acros the whole range from radio to x-ray)
• Terms for properties like redshift (photometric or spectroscopic), source classification and morphology
• Errors and probabilities

-- AnitaRichards - 09 May 2003