Registry Query Language

Ray Plante rplante at
Wed Apr 30 10:02:26 PDT 2003


A few items to think about with regard to approaching queries to 

1.  Overlap with VOQL WG:  

    I don't see much difference between searching a registry and any other 
    searchable database.  The main difference, perhaps, is in the 
    metadata you invoke.  Thus, I think it makes sense that Registries 
    should ultimately support the general QL that comes out of the VOQL 
    working group.

    That said, we may need to adopt something early to work with until we 
    have a VOQL.  This experience can provide important input to the VOQL 
    development process.

2.  Metadata vs. QL

    To ensure that the QL adapts well to our evolving metadata model(s), 
    they need to be independent.  That is, the QL syntax must be metadata 
    neutral.  It may place requirements on how the metadata is defined, 
    but it should not care what specifically appears left or right of an 
    equal sign.

    I believe Keith's strawman reflects this.  (This is particularly 
    obvious in the XML version.)

3.  Registry Metadata

    As you know we have a separate WP for this topic.  A general schema 
    for registries is proposed in text form in the RSM document and an XML 
    version based on it is posted at the RWP03 page:  Other proposals 
    are welcome there.  

    In my mind, what we should concentrate on in RWP03 is the metadata 
    about Resources in particular.  For astronomical related 
    information--which certainly should be included as part a resource 
    description (e.g. coverage)--we should leverage off the data models 
    that come out of the DM WG.  We should not plan to make up our own 
    just for use with registries.  

    For example, in my proposed schema (VOResource), it is intended that 
    the "Coverage/Spatial" node would use elements from the Space-Time 
    Coordinates and Regions schema being developed by Arnold Rots et al.  

4.  XML-based QL vs. SQL vs. XML Query

    The motivation for using an XML-based QL is that it is easier to parse 
    than SQL and XQuery.  In my mind, this is a critical requirement for 
    the general QL because at some point in the chain (most sensibly at 
    the data provider's site), catalog queries must be transformed into 
    a native format.  It is not just a matter of transforming to SQL; the 
    metadata itself must be transformed to the local schema.  (A definite
    requirement of an XML-based QL would be that it is easily transformed 
    into SQL and XQuery.)

    This parsing requirement is less critical, I think, for registries, 
    but it could still be.  It all depends on how the registry data is 
    actually stored internally (which we don't want to mandate!).  Still, 
    in the short term, XML Query is not a bad choice, especially if we 
    plan to use an OO/XML-based metadata model (which I think we should).

    Keep in mind: straight SQL is only straight-forward if the  schema used 
    in the query matches what is actually in the (relational!) database.  
    If you can't guarantee this, you have to parse the SQL.  

More information about the registry mailing list