VOResource v0.8.2

[Anita Richards]

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