VOResource v0.8.2

[Arnold Rots]

Anita,

Apologies for the slow response.

You have a good point and I agree that the coverage can, and in many
case should be, approximate.  The same for resolutions.
However, I think there is merit in providing very precise information
on the coordinate system that is in use, not to nail down the coverage
are to a fraction of a mas, but to allow the client to assess whether
it can actually handle the data (i.e., can it do the required
coordinate transformations, or does the resource have the required
precision).  This becomes especially important when we start mixing
with, for instance, the PDS.

Here is a way to write the XML information in text:

ResourceProfile = 
  (CoordSystem[ID="CXOCoordSys"] =
    (TimeFrame =
      ((TimeScale = "TT")
      and (TimeRefPosition = (RefPos = "TELESCOPE"))
      and (CoordFlavor[coord_naxes="2",coord_type="SPHERICAL",coord_vel="false"]))
    and (SpaceFrame =
      (CoordFrame =
        ((RefSystem = "ICRS") and (StandardPole = "EQUATORIAL"))
      and (CoordRefPosition = (RefPos = "TELESCOPE"))))
    and (SpectralFrame = "OBSERVATORY")))

  and (CoordArea[ID="CXOCover",coord_system_id="CXOCoordSys"] =
    (TimeInterval =
      (StartTime =
        ((ISOTime = "1999-07-23T00:00:00") and (TimeScale = "TT")))
    and (CoordInterval =
      ((LoLimit2Vec[pos1_unit="deg"] = (Value = "0.0 -90.0"))
      and ((HiLimit2Vec[pos1_unit="deg"] = (Value = "0.0 -90.0"))))
    and (SpectralInterval =
      ((LoLimit[spectral_unit="keV"] = (Value = "0.15"))
      and ((HiLimit[spectral_unit="keV"] = (Value = "12.0"))))

  and (CoordSpec[ID="CXOCoordSpec",coord_system_id="CXOCoordSys"] =
    (Time = 
      (CoordError[time_unit="s"] = (Value = "0.0001"))
      and (CoordResolution[time_unit="s"] = (Value = "0.000016")))
    and (Pos2Vector =
      (CoordError[pos1_unit="arcsec"] = (Value = "1.0"))
      and (CoordResolution[pos1_unit="arcsec"] = (Value = "0.5")))
    and (Spectrum = 
      (CoordError[spectral_unit="keV"] = (Value = "2.0"))
      and (CoordResolution[spectral_unit="keV"] = (Value = "1.0"))))

This may look imposing, but it is clear that one can easily produce,
say, an html form that will allow users to fill in the values, as well
as a parser for producing an xml document.

  - Arnold

Anita Richards wrote:
> > > Coverage
> > > Spatial, Spectral, Temporal - maybe Resolution should be one of the
> > > subelements in each of these, along with dimensional coverage,
> > > accuracy, regionOfRegard etc. - maybe depth/sensitivity is extra?
> > > RSMv0.8 seemed to do very well, with a little reorganisation. The STC
> > > seems very comprehensive but we will only find out how complete the
> > > related schemas are and how far it is necessary to go when using them
> > > to answer queries.  The Registry should only use a tiny fraction of
> > > their complexity
> 
> >
> > Most definitely not!
> > Well, if we limit the VO to only deal with data in ICRS or FK5/J200,
> > and restrict users to objects outside the solar system, we can.
> > But if the registry is to be useful for handling data collections and
> > users who use a wide variety of space-time coordinate systems, then it
> > is absolutely crucial that that information be stored in precise
> > detail.  Shortcuts and "common sense" assumptions are going to get us
> > into a lot of trouble.
> 
> There seems to be a conflict of assumptions here, as I think there are
> things which you see as a registry function which I was (maybe wrongly)
> thinking of as being dealt with elsewhere e.g. VOQL, job control etc.  As
> I understand it the Registry exists to select services which *might* be
> able to answer a query.  Hence we can describe coverage approximately but
> inclusively, rounding lower limits down and upper limits up etc.  In many
> cases the information for an exact description is not readily available
> e.g. magnitudes to Jy.   In AstroGrid we have been developing the Registry
> to be consistent with RSMv0.8 using this approach, for Solar and STP data
> as well as extra-solar.  However we don't have any science cases for solar
> system data (planetary etc) so it is hard to know if it will work.
> 
> In this approach, the precise interpoperability conversions (flux units,
> coordinate systems etc) are done in response to queries with the accuracy
> which the query demands.  For example, for a radio-to-x-ray SED, using a
> generic definition of Vmag to produce Jy would be OK; for calculating a
> photometric redshift using only optical data you would need to know a lot
> more about the photometric system.  Or, converting from B1950 to J2000 for
> comparison with arcsec-resolution data does not need to know about leap
> seconds, but for VLBI it does.  The high precision functions may need to
> call specialised external services and slow down queries if they are not
> needed; moreover they may be dynamic conversions (better determination of
> photometric standards; propoer motions in positions).
> 
> I would like to know what other people think - if anyone else wants a
> simple registry, then how to we use the full details provided by the STC
> schemas? Called as a service? Alberto and others have suggested a
> multi-level registry, would that work? I am sure AstroGrid will attempt to
> fit in with the IVOA as much as possible, but if national VOs want to
> impliment more or less detail, will that work as long as the overall
> structure is the same?
> 
> > The real issue is not how simple of complicated the description of a
> > resource is in the registry, but how user-friendly the tool is that
> > allows people to register their resources.
> > And is isn't really so terribly complicated.  For an example see:
> >
> > 	http://hea-www.harvard.edu/~arots/nvometa/CXOResource.xml
> 
> Yes, but that is the xml product; how can we give people an interface
> which guides them to the appropriate fields when they only need to
> complete, say, 15 out of 150 potential entries?
> 
> I am open to being convinced by Arnold's approach - especially by
> practical examples of use on heterogenous data and testing an interface
> for data providers/other means of gathering the necessary details.
> 
> > > and will impose added restrictions (I hope!) e.g. units.
> >
> > I'm all in favor of restrictions on units - but that's an issue of the
> > interface tool, again - but I am suspicious of unspecified restrictions.
> 
> Point taken.  See
> http://wiki.astrogrid.org/bin/view/Astrogrid/AnnotatedSchemaWithUnits
> for an example.  This is now outdated and all up for discussion,
> but is a model for handling coverage in a restricted registry.
> 
> Data providers could enter descriptions in their native units as long as
> we have some definition to use to translate.
> 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Dr. Anita M. S. Richards, AVO Astronomer
> MERLIN/VLBI National Facility, University of Manchester,
> Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
> tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).
> 
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head-cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------