new version of high level languge
gaffney at stsci.edu
Thu Feb 27 12:46:37 PST 2003
I think this is a great start on a query language. As someone who might
write a client to use the VO, this is what I would love to have to get
One thing I want to reflect a little on a broader issue. The question
is how much buy in cost do we expect VO service providers to have to
bear and what will the VO provide to aid in this? I know we want it to
be as "small as possible". Supporting this query language though seems
to create a significantly larger buy in cost than say our cone searches
or SIA mostly due to is flexability. For a some participant, this would
require significantly more effort to support. I'm not saying that this
is a bad thing, as we do want the VO to be useful (and not being able to
do some of these things would essentially make it not very usefull at
all), but we have to recognize this. Making services use a common data
model is essental to the VO but we do have to look at this issue and
explore where to draw the line of who does what conversions and
manipulations to maximize participation and functionallity of the VO as
a whole. Requiring all services to implement such things as math and
unit conversions in the query language and expect all providers to
support that (correctly) is one of these things we should look at.
To reduce buy in for this very flexable query language, do we (the VO)
anticipate providing some black box VO middle ware that would allow
providers to describe their holdings and access methods in some way and
have the black box use the access methods to get the data and then do
the conversions and handling of the math? I recognize that in many
cases it would be strait forward to create an XSLT that could convert
this query into SQL that is optimized for their database for an XML/SQL
guru. I don't know if that would be true for many potential providers,
nor how many this would scare off simply as they do not have the
resources. I also don't know if it is reasonable to try to make a
generic black box as each system can be so different.
Alternately do we want to have different extensions to the query
language and have the service know how to reveal which extensions it can
use, either by interogation or in fields in the registry (or both with
efficient harvesting). Supports Math, Supports Unit Conversions,
Supports 3D geometry queries...whatever. This gives me goosebumps as I
know what this sort of thing has done to many other languages such as
SQL. Then those who wanted to provide advanced services like unit
conversion and math could do so and clients that needed these services
could restrict who they query to only the advanced ones they need.
Or do we simply have many different VO query entry points. Cone Search
and SIA like services stay with us as the simplest entry level for
queries. VOQL then becomes a higher entry level (and perhapse has a
simple way to cast itself into a cone search interface or a SIA
interface). These advanced services can easily provide wrappers to act
as Cone Searches or SIA searches. Then the clients use the services
that are at the level of complexity they need to do what they need to do
knowing the lower they get the more data they can access, but the higher
they go the less they have to do, but the more complex a system they
have to support.
I know this is a bit off topic, but this query provides a good example
for this issue and one that I think these groups should make some
recomendations on for the rest of the VO to look into.
Ed Shaya wrote:
> Oops, that is not the URL for the documentation. Here it is:
> Sorry about that.
> Ed Shaya wrote:
>> I have made numerous additions/changes, most notably adding
>> arithmetic, logic, inequalities,
>> so that one can take response variables and put constraints on them.
>> I tried to be consistent with MathML whereever appropriate. I did
>> not get in all of the annotation that I hoped, but there are some
>> short statements about each Type. You can see an extensive auto
>> generated documentation along with the latest schemas at
>> Also, the spaceTime parts are now in a separate namespace, but for
>> some reason I had to
>> drop all default values to do this, don't understand why.
>> <?xml version="1.0" encoding="UTF-8"?>
>> <!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com) by Ed
>> Shaya (NASA) -->
>> <request xmlns="http://www.vo.org/ql"
>> <object class="clusterOfGalaxies">
>> <measurement name="X-ray_brightness"
>> <image type="Xray" project="ROSAT"
>> <measurement name="redshift" units="@czunits">
>> <lo inclusive="yes">0.6</lo>
>> <object class="galaxy">
>> <Coords coord_system_id="equatorial">
>> <CoordSystem coord_system_id="equatorial"
>> coord_epoch="@epoch" coord_ref_frame="FK5"/>
>> <Coords coord_system_id="equatorial">
>> <measurement project="ROSAT"
>> name="Xraybrightness" units="@xrayUnits">@gXray</measurement>
>> <image band="optical"
>> <cn units="Jansky">3.0E3</cn>
>> <return type="VOTable" name="Cluster Info">
>> <for-each object="@clusterName">
>> <field name="clusterName"
>> <field name="clusterXray"
>> <field name="image" units="unitless">@image</field>
>> <field name="redshift" units="@czunits">@cz</field>
>> <field name="Number of Galaxies" units="unitless">
>> <for-each object="@galaxyName">
>> <field name="galaxyName"
>> <field name="gRA" units="unitless">@gRA</field>
>> <field name="gDE" units="unitless">@gDE</field>
>> <field name="Xray" units="@xrayUnits">@gXray</field>
>> <field name="mType" units="unitless">@mType</field>
>> <field name="images" units="unitless">@@images</field>
>> <field name="imageQuality" units="unitless">@@q</field>
More information about the voql