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