Date: Fri, 21 Feb 2003 18:30:38 -0500
Here is a first cut at a highest level astronomical query language. This is going to need some introduction so you can begin to see where we are going with this. The goal here is to create an XML language that can capture the scientific spirit of the NVO use cases. This requires using object/property relationships and therefore builds on many of concepts in AMASE such as the idea that the key items are the astronomical object and their classes. The scientist should be able to build up a query from a form or gui. An integrator service then analyses the voql and breaks it down to its atomic parts. The integrator checks the metadata registries to see which atomic parts go to which data centers. The integrator checks with the WSDL documents to create queries properly for each data center. I would imagine that XML Query will play a big role here. But, XML Query is meant for query on a specific XML database of well known schema, and is not appropriate at the distributed level. We can of course make voql look quite XML Queryish. When the responses come back, the integrator applies the logic functions to see which objects have all of the required data. It may send some results out to services and finally it forms the return tables applying the requested statistics.
Thus, we need to get our metadata registries into shape so that this ontological type query can be useful (such as "these galaxies are members of this cluster", "these layers are regions of stars", "FRII is a subclass of radio-galaxy" etc). And, we need to develop and intelligent integrator. But, if Web Services are properly used, atleast the interactions between the services and the integrator will be quite straightforward. The recent development of WS at CDS, ADECC and the paper by Brian Thomas and myself are a good beginning down this road. But now I am starting the road from the scientists into the VO.
A request has any number of "constraints" which specifies an object/@class and a number of properties (or properties within a range of values). As it is discovered that objects of this class are known the values and errors are saved to variables. These variables can be used in the following "constraints". Services may be used along the way, and we can only enter an element named "service" which allow for arbitrary attributes at this time. Finally, a "result" consists of a table where we specify which variables fall into each field. We may also do statistics on the variable and enter the results into that field.
The schema does an xs:include on the Coords.xsd that Arnold Rots worked on. You can tell those elements because they begin with a capital letter. I did have to do some liberal editing on Coords to make it work well in this.
Further annotation of the schema is coming.
Notes on use case 1:
Specifically this request says:
Constrain results to clusters of galaxies with ROSAT X-ray measurements
and images and at least one cataloged galaxy member.
It must also have a name, RA, and DE (ie. The galaxies MAY also have a
ROSAT X-ray flux (optional
properties are in <or> elements). The $variables do not set a range on the
required measurement. The variable is set by the database. For a variable
lists use @.
Ed
Received on 2003-02-22Z00:34:01
