Annotation for AstroGrid Iteration 02 Resource Registry Schema

Initially we want to keep to standard units e.g. metres for the e-m spectrum - this is only a complete simplification if query units are also restricted. Ultimately we will have to do conversions at some stages and it is a matter of convenience not principle where. However as the Registry values have to be inclusive, not exact, it is not a big deal to homogneise Registry units anyway. The units/data formats I suggest are shown in bold followed by comments if necessary.

These follows Bob Hanisch et al. http://www.ivoa.net/internal/IVOA/IvoaResReg/ResourceServiceMetadataV7.pdf but with some additions and suggestions for future additions, motivated in italics . There are some differences with the schemas in http://www.ivoa.net/internal/IVOA/IVOARegWp03/MDinXML-Summary.html mainly because my ignorance of xml means I do not understand some of the structures in the examples therein. Some differences are because MDinXML^?-Summary.html is based on ResourceServiceMetadataV6^?. I have not yet used namespace references; these should be added as required - where possible using existing ones.

1. to provide definitions of elements (e.g. as in http://www.ivoa.net/internal/IVOA/IVOARegWp03/VOStdService.xsd)
2. to provide restricted lists (e.g. of UCDs)

Identity

• title string
• ticker string need namespace of recognised abbreviations?
• identifier anyURI - for AstroGrid access?

Curation

• publisher string
• publisherID string need namespace of recognised abbreviations?
• creator string
• subjectList>
  • subjectKeyword 0 or more keywords from namespace?
• description free text
• contributor string
• date YYYY-MM-DD
• version string
• referenceURL anyURI
• contact>
  • name string
  • email string
• dataSize> additional needed to optimise order/location of query execution
  • nBytes Mb
  • nPixels size of a single image e.g. xpixelsize x ypixelsize can this be done as an nDim array e.g. (wpixelsize, xpixelsize, ypixelsize, zpixelsize)?
  • nRows float, rows in table
  • nCols float, columns in table

Content

• ucdList> additional - to support just a simple match initially, eventually could be a separate layer
  • ucd Any number (eliminating repetition), from Vizier
• resourceType Up to 19, from "archive" "bibliography" "catalogue" "journal" "library" "simulation" "survey" "education" "outreach" "epoResource" "animation" "artwork" "background" "basicData" "historical" "photographic" "press" "integrated" "nameresolver"
• coverage>
  • coverageSpatial>
    • regionSpatial>
      • box>
        • cframe>
          • cframeType see last cframe occurence below
        • boxMin>
          • coordinateA decimal degrees
          • coordinateB decimal degrees
        • boxMax>
          • coordinateA decimal degrees
          • coordinateB decimal degrees
      • circle>
        • cframe>
          • cframeType see last cframe occurence below
        • circleCentre>
          • coordinateA decimal degrees
          • coordinateB decimal degrees
        • circleRadius arcsec
      • polygon>
        • cframe>
          • cframeType see last cframe occurence below
          • polygonAngle> 3 or more
            • coordinateA decimal degrees
            • coordinateB decimal degrees
      • healpix> added at Planck people's request
        • cframe>
          • cframeType see final entry below for cframe
        • healpixNo one or more numbers 1-12
    • cframe>
      • cframeType up to 6 from "ICRS" "FK5" "FK4" "GAL" "SGAL" "UNKNOWN" unknown added until we get Solar/STP sorted out or longer. Could use ID/IDREF to reference occurences above, but might be multiple options. If cframe uses RA and Dec then the A coordinates above are (15*(HH+(MM+SS/60)/60))
    • regionOfRegard Arcsec Search area e.g. max radius of image wrt catalogues centre coordinates or error circle of source catalogue. Often not the same as resolution. Needs extending to spectral and temporal search regions.
  • coverageSpectral>
    • coverageSpectralWaveband Up to 9 from "radio" "mmWave" "infrared" "optical" "uv" "euv" "xRay" "gammaRay" "unknown" unknown added
    • coverageSpectralBandpass Any e.g. U B V - optional Aimed at 'dumb' matching unless definitions are added, however much room for ambiguity etc. hence additional information needed i.e. Central or Minimum/Maximum Wavelength as below.
    • coverageSpectralCentralWavelength metres
    • coverageSpectralMinimumWavelength metres
    • coverageSpectralMaximumWavelength metres
  • coverageTemporal>
    • coverageTemporalStartTime YYYY-MM-DD
    • coverageTemporalStopTime YYYY-MM-DD
  • coverageDepth Limiting flux density, Jy
  • coverageObjectDensity Sources per sq degree if relevant
  • coverageObjectCount Total source count if relevant also want sky fraction covered by images and spectral and temporal equivalents
• resolution> added
  • resolutionSpatial arcsec
  • resolutionSpectral fractional e.g. deltaLambda/Lambda
  • resolutionTemporal sec
• dataQuality> added
  • photometryError fractional deltaJy/Jy
  • astrometryError arcsec
  • timingError sec
• contentLevel up to 9 from "general" "elementaryEducation" "middleSchoolEducation" "secondaryEducation" "communityCollege" "university" "research" "amateur" "informalEducation"
• facility One or more observatories/projects etc.
• instrument Instrument, code, other data source
• format up to 9 from "fits" "asciiText" "html" "xml" "VOTable" "gif" "jpg" "png" "other"
• rights one of "public" "proprietary" "mixed"

Other future additions

• Allow coverage to include multiple non-contiguous regions in spatial spectral and temporal domains, e.g. to allow for discrete radio wavebands covering 1.3-1.7 GHz, 4.5-6.7, 21-24 GHz etc. These are not bandpasses because any individual observation probably only covers a smaller region e.g. 16 MHz within this. Similarly for optical observations of variable stars which can only be observed when they are in the night sky, etc.
• Allow element values to be inter-dependent, e.g. the radio resolution depends on wavelength and in the above example varies by a factor of almost 20.

• We discussed adding (probably to CURATION) a set of elements to cover linked data sets, for example if the properties of observed sources and the coverage of the facility used are in separate tables. However this may be covered by the separate Data Collection section? Or is this more like an entire data centre e.g. MAST, LEDAS?

serviceMetadataConcepts

Also see RegistryServiceMetadataConcepts

• interfaceMetadata>
  • serviceInterfaceUrl
  • serviceBaseUrl
  • serviceHttpResults
• capabilitiesMetadata
  • serviceStandardUri
  • serviceStandardUrl
  • serviceRestriction
    • serviceMSR maximum radius (deg.) for cone search
    • serviceMaxImageSize in pixels? Mb? added as another example of a restriction also spatial, e.g. for a cut-out service. Other restrictions could include No of rows from a table, time interval to search for Solar data, etc.