Re: [Treebase-devel] [PhyloWS] PhyloWS, CQL, NeXML on TreeBASE2

[Hilmar L. <hl...@ne...>]

On Jul 7, 2009, at 8:17 PM, Rutger Vos wrote:

> I realize that I'm overloading the "recordSchema" token (and should  
> fix that)

That was my main point in this regard.

> but some way of saying "search THIS domain and project the results  
> into THAT domain" seems very, very handy - especially because CQL  
> doesn't have a notion of
> joins.

I fully agree. We may just be talking past each other, but I'm not  
seeing why something like

phylows/tree/find?query=study.identifier=S2484

doesn't achieve exactly that - it says search the study domain and  
project the results into the tree domain. Conversely,

phylows/study/find?query=tree.identifier=TB2484

says to search in the tree domain and project the results into the  
study domain (i.e., return studies that have a tree matching the query).

You aren't trying to suggest that dcterms.title or dcterms.identifier  
should mean different things for different finders, right?

I get the sense that you are tying URL patterns and implementations  
closely together; i.e., phylows/tree/find executes one and the same  
chunk of code no matter what the query is, and so there would be chunk  
of code sitting under phylows/study/find that finds trees and another,  
separate, chunk of code sitting under phylows/tree/find that finds  
trees. But of course the URL patterns and the code they execute (if  
any - it may just be indexed files and XSLTs) are two completely  
separate things. There is no reason that phylows/study/find and  
phylows/tree/find couldn't (in fact shouldn't) use the exact same tree  
finder class for finding trees.

I think we really need to look at the PhyloWS as a standardized  
pattern of web-service URLs that are completely decoupled from the  
underlying implementation which can take a multitude of shapes.

What we should pay attention to though is that the API *allows*  
optimizing of code reuse and clean design of implementations. Are you  
saying that it stands in the way of that, and if so, how does it  
prevent clean design of implementations?

	-hilmar



-- 
===========================================================
: Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
===========================================================