[DAS2] query language description

[chris mungall]

On Mar 16, 2006, at 2:46 PM, Andrew Dalke wrote:

> Hi Chris,
>
>> I presume one constraint is that you want to preserve standard CGI URL
>> syntax?
>
> Yes.

I'm guessing you've been through this debate before, so no comment..

>
>>  I think this is the best that can be done using that constraint,
>> which is to say, fairly limited.
>
> Then again, the functionality we need is also fairly limited.

ignorant question.. (I have only been tangentially aware of the outer 
edges of the whole das2 process)..

how are you determining the functionality required? surely someone 
somewhere will want to write a das2 client that implements boolean 
queries

I speak from experience - I designed the GO Database API to have a very 
similar constraint language (it's expressed using perl hash keys rather 
than CGI parameters but the same basic idea). For years people have 
been clamouring for the ability to do more complex queries - right now 
they are forced bypass the constraint language and go direct to SQL.

>
>>  This lacks one of the most important features of a real query
>> language, composability. These ad-hoc constraint syntaxes have their
>> uses but you'll eventually want to go beyond the limits and end up
>> adding awkward extensions. Why not just forego the URL constraint and
>> go with a composable extendable query language in the first place and
>> save a lot of bother downstream?
>
> Because no one can decide on a generic language which is more
> powerful than this.
>
> Anything more powerful would need to support .. boolean algebra?
> numeric searches?  regexps?  What about quoting rules for "multiple
> word phrases"?
>
> Is it SQL-like?  XPath/XQuery-like?  Is it a context-free grammar?
> How easy is it to implement and work cross-platform?

None of these really lit into the DAS paradigm. I'm guessing you want 
something simple that can be used as easily as an API with get-by-X 
methods but will seamlessly blend into something more powerful. I think 
what you have is on the right lines. I'm just arguing to make this 
language composable from the outset, so that it can be extended to 
whatever expressivity is required in the future, without bolting on a 
new query system that's incompatible with the existing one.

The generic language could just be some kind of simple extensible 
function syntax for search terms, boolean operators, and some kind of 
(optional) nesting syntax.

If you have boolean operators and it's composable, then yep it does 
have to be as expressive as boolean algebra.

I'd argue that implementing a composable query language is easier than 
an ad-hoc one

> For what people need now, this search solution seems good.
>
> For the future we can have
>
>    <CAPABILITY type="xpath-query" query_uri="http://whatever" />
>
> and clients which understand that interface will know that it's
> there.

hmm, not sure how useful this would be - surely you'd want something 
more dasmodel-aware?

if you're going to just pass-through to xpath or sql then why have a 
das protocol at all?

>
> 					Andrew
> 					dalke at dalkescientific.com
>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2