Querying

[Ed Shaya]

Folks,

	In the XQUERY Working Draft ( http://www.w3.org/TR/xquery/#N400DC8 ). 
There is a section on constructors and there is an example query:

<example>
            <p> Here is a query. </p>
            <eg> $i//title </eg>
            <p> Here is the result of the above query. </p>
            <eg>{ $i//title }</eg>
</example> 

Which results in:

<example>
           <p> Here is a query. </p>
           <eg> $i//title </eg>
           <p> Here is the result of the above query. </p>
           <eg><title>Harold and the Purple Crayon</title></eg>
</example>

The brackets {} tell the XQuery app that this is not a literal string, but
the query which should fill in at this point.  I believe this mechanism is
what you desire for transforming a VOTable into a query system.

Ed


Francois Ochsenbein wrote:
> 
> Clive,
> 
> Let me comment on Clive's propositions about "Querying Astronomical
> Catalogues with the Virtual Observatory" (I've also put a link
> to it at http://vizier.u-strasbg.fr/doc/VOTable/voqueries_1.html
> (the document is also mentioned in  http://vizier.u-strasbg.fr/doc/VOTable/ )
> 
> Contrary to Wil, I do not see a single catalogue as the unit of
> discovery -- there are thousands of catalogues around. And in practice
> I'm not convinced that highly complex query mechanisms are useful or
> even desirable as a front query mechanism -- any similar experience
> which imposed complex interfaces on partners has failed up to now
> (do you remember Z39.50?)
> 
> I appreciate the list of the "Types of Queries", but the straight route
> suggested in this section misses the flexibility which can be introduced
> by a real dialog between the data provider  and the data consumer -- in
> other terms an answer to a question is quite generally a starting point
> for another question, which can't be limited to an arbitrary list.
> And note also that getting an empty table is exactly what is contained in
> the "Details of columns in an individual catalogue" -- a typical example
> of an answer which contains the necessary details for the next question !
> 
> About the types of query, keep it simple ! Again in practice, introducing
> a complex language which has to be understood by each data server
> will most likely lead to a failure -- complex queries are better
> converted to a set of successive simple queries by the data consumer (portal).
> If this succession would imply too much data transfer, it could also be
> envisaged to send the selection code (in Java) to be executed on the data
> provider.
> 
> On the other hand, one of the most important querying capabilities for
> strings (match some defined kind of regular expression) seems to be missing.
> Also, a possibility of specifying the consumer's prefered ordering of
> the result seems to be missing -- quite important in practice !
> The LITBIG query type is in fact nothing else than a sorting order
> associated to a maximal number of output records -- a maximal number of
> output records HAS to be specifed too if there is a wish to control the
> data flux.
> 
> --Francois
> ================================================================================
> Francois Ochsenbein       ------       Observatoire Astronomique de Strasbourg
>    11, rue de l'Universite F-67000 STRASBOURG       Phone: +33-(0)390 24 24 29
> Email: francois at astro.u-strasbg.fr   (France)         Fax: +33-(0)390 24 24 17
> ================================================================================