Menu
▾
▴
treebase-devel — TreeBASE developer mailing list
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
(1) |
Apr
(41) |
May
(41) |
Jun
(50) |
Jul
(14) |
Aug
(21) |
Sep
(37) |
Oct
(8) |
Nov
(4) |
Dec
(135) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(145) |
Feb
(110) |
Mar
(216) |
Apr
(101) |
May
(42) |
Jun
(42) |
Jul
(23) |
Aug
(17) |
Sep
(33) |
Oct
(15) |
Nov
(18) |
Dec
(6) |
| 2011 |
Jan
(8) |
Feb
(10) |
Mar
(8) |
Apr
(41) |
May
(48) |
Jun
(62) |
Jul
(7) |
Aug
(9) |
Sep
(7) |
Oct
(11) |
Nov
(49) |
Dec
(1) |
| 2012 |
Jan
(17) |
Feb
(63) |
Mar
(4) |
Apr
(13) |
May
(17) |
Jun
(21) |
Jul
(10) |
Aug
(10) |
Sep
|
Oct
|
Nov
|
Dec
(16) |
| 2013 |
Jan
(10) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Val T. <va...@ci...> - 2009-08-31 19:12:30
|
On Aug 31, 2009, at 2:49 PM, youjun guo wrote: > Dear TreeBasers; > > TreeBase is using maven2 as its project management tool. Right now a > major repository is hosted by SDSC server. My question is : should > we still have that maven facility after migration of the project? Er, ... not at SDSC, no. The current situation is that the data has already been moved to NesCENT in the form of some special files that are currently being loaded into PostgeSQL and the software is in SourceForge. We haven't yet given the SDSC folks green light to delete the files there because we want to wait until the app runs correctly at NesCENT. Before we give them the delete all message we should have the project management also at NesCENT. Youjun, are you volunteering to move the maven repository to NesCENT :)? Val > > Thanks > > Youjun > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel |
|
From: youjun g. <you...@ya...> - 2009-08-31 18:50:03
|
Dear TreeBasers; TreeBase is using maven2 as its project management tool. Right now a major repository is hosted by SDSC server. My question is : should we still have that maven facility after migration of the project? Thanks Youjun |
|
From: youjun g. <you...@gm...> - 2009-08-31 18:40:10
|
Dear TreeBasers; By exploring the TreeBase project setting I realized that it use maven2 as its project management tool. Right now a major repository is hosted by SDSC server. My question is : should we still have that maven facility after migration of the project? Thanks Youjun |
|
From: youjun g. <you...@ya...> - 2009-08-28 23:14:10
|
_Y |
|
From: youjun g. <you...@gm...> - 2009-08-28 19:43:37
|
_Y |
|
From: William H. P. <pi...@tr...> - 2009-08-28 18:58:37
|
this is a test -- please ignore. bp |
|
From: Hilmar L. <hl...@du...> - 2009-08-26 17:51:30
|
On Aug 26, 2009, at 1:21 PM, William Piel wrote: > How close are we for me to switch off TreeBASE1 and start the final > migration? Just as a reminder, regardless of the technical aspects of migrating and switching, we had agreed that before we flip the switch we would complete user-testing of the beta-release, fix the bugs that arise (or arose) from that, and we would complete a series of benchmark performance tests against which satisfactory performance on the NESCent servers would be validated. Have these all been completed? -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu : =========================================================== |
|
From: William P. <wil...@ya...> - 2009-08-26 17:21:37
|
Hi all, I was wondering how things are going with the SDSC->NESCent migration of TreeBASE2. How close are we for me to switch off TreeBASE1 and start the final migration? regards, Bill |
|
From: William H. P. <pi...@tr...> - 2009-08-18 00:11:17
|
Thanks! That fabulous. When the next version comes out we will need to see if we can adapt the headless code to serve as TreeBASE2's parser. (The one we currently use has had it's code modified by one of our programmers -- the same will need to be done with the new version). bp On Aug 17, 2009, at 6:13 PM, Wayne Maddison wrote: > Bill, > > Good news. We've put in the ability to read tree files with and > without translation tables into Mesquite. Next release. Thanks for > the urging... > > Wayne |
|
From: Wayne M. <wma...@in...> - 2009-08-17 22:13:11
|
Bill,
Good news. We've put in the ability to read tree files with and
without translation tables into Mesquite. Next release. Thanks for
the urging...
Wayne
At 5:24 PM -0400 23.6.2009, William Halliday Piel wrote:
>Dear David and Wayne,
>
>As you know, TreeBASE is using a headless version of Mesquite to
>parse all incoming data.
>
>I've noticed that although Mesquite is happy parsing a tree with a
>translation table (but without a taxon block), for some reason it
>doesn't like trees that lack a translation table and a taxon block.
>
>For these tree files (e.g. the default tree file produced by MrBayes
>-- see attached), I get the following message:
>
>A block of trees has been read for which no corresponding block of
>taxa has been found, and no block of taxa could be created for it.
>If you had expected that the trees would have applied to an existing
>block of taxa, it is possible that the taxa no longer correspond
>because of changes in names or in which taxa are included.
>
>However, if a translation table exists, I get the following message
>-- which is similar, but has a much happier outcome (i.e., the tree
>gets parsed):
>
>A block of trees has been read for which no corresponding block of
>taxa is available; a new block of taxa has been created for it. If
>you had expected that the trees would have applied to an existing
>block of taxa, it is possible that the taxa no longer correspond
>because of changes in names or in which taxa are included.
>
>How is it that in one case a new block of taxa is created, but in
>the other case "no block" could be created?
>
>Is there a workaround (e.g. a preferences flag?) that we can use so
>that Mesquite will parse MrBayes tree files without taxon blocks?
>
>thanks,
>
>Bill
>
>
>Dear David and Wayne,
>
>As you know, TreeBASE is using a headless version of Mesquite to
>parse all incoming data.
>
>I've noticed that although Mesquite is happy parsing a tree with a
>translation table (but without a taxon block), for some reason it
>doesn't like trees that lack a translation table and a taxon block.
>
>For these tree files (e.g. the default tree file produced by MrBayes
>-- see attached), I get the following message:
>
>A block of trees has been read for which no corresponding block of
>taxa has been found, and no block of taxa could be created for it.
>If you had expected that the trees wo isting block of taxa, it is
>possible that the taxa no longer correspond because of changes in
>names or in which taxa are included.
>
>
>However, if a translation table exists, I get the following message
>-- which is similar, but has a much happier outcome (i.e., the tree
>gets parsed):
>
>A block of trees has been read for which no corresponding block of
>taxa is available; a new block of taxa has been created for it. If
>you had expected that the trees would have applied to an existing
>block of taxa, it is possible that the taxa no longer correspond
>because of changes in names or in which taxa are included.
>
>
>How is it that in one case a new block of taxa is created, but in
>the other case "no block" could be created?
>
>thanks,
>
>Bill
>
>
>Attachment converted: Thrandina:RNF213IRBPMLLRhodomin3.zip
>(pZIP/«IC») (00260B04)
--
--------------------------------------------------------
Wayne Maddison
Professor and Canada Research Chair
Depts. of Zoology and Botany and
Biodiversity Research Centre
& Director
Beaty Biodiversity Museum
6270 University Boulevard
University of British Columbia
Vancouver, BC V6T 1Z4 Canada
email: wma...@in... FAX: +1 604 822-2416
Mesquite: http://mesquiteproject.org
MacClade: http://macclade.org
Salticidae: http://salticidae.org
Tree of Life: http://tolweb.org
Beaty Biodiversity Museum: http://beatymuseum.ubc.ca
Home page: http://salticidae.org/wpm/home.html
|
|
From: Hilmar L. <hl...@du...> - 2009-08-10 20:43:33
|
Well you don't need a triple store for that - BioSQL for example could store the data. BioSQL is weakly typed, though, so yes, that's a difference. We'll fix that. -hilmar On Aug 10, 2009, at 4:35 PM, Rutger Vos wrote: > Is TreeBASE (to some extent) a triple store? No. But it would be nice > if it could collaborate with one. I'd love to talk about some sort of > community effort to make that work. But for now TreeBASE is strictly > based on a strongly typed relational schema, so you can understand > that it can't capture phenoscape annotations. > > On Fri, Aug 7, 2009 at 6:22 AM, William Piel<wil...@ya...> > wrote: >> >> On Aug 6, 2009, at 10:54 AM, Hilmar Lapp wrote: >> >>> I understand that TreeBASE2 can now output NeXML. However, can it >>> also ingest and store the contents of NeXML? >> >> no. >> >>> More specifically, can TreeBASE2 ingest and store arbitrary metadata >>> attached to trees, nodes, and matrix cells? >> >> no -- only the standard pre-colon and post-colon vaules; and for each >> tree, a fixed set of metadata (tree quality, tree type, etc) plus >> values that authors are free to enter whatever they want (tree title, >> label, comments, etc). >> >>> We would be very interested in this in the context of the Phenoscape >>> project (http://phenoscape.org) where we create NeXML files with the >>> phylogenetic character data and tree with embedded formal phenotype >>> assertions that are attached to matrix cells. Is it possible to >>> submit these files to TreeBASE2, and to get those back out, e.g., >>> using the REST API? >> >> TreeBASE2 uses a headless version of Mesquite to parse nexus files. >> If >> a module is developed to parse NeXML into Mesquite, that would be one >> way to bring NeXML into TreeBASE2. Alternatively, we would need to >> write a NeXML parser. Our schema is largely designed to capture data >> that are transportable via nexus files -- for matrix files that means >> character labels and state labels. If "phenoscape assertions" can be >> coded as character labels and state labels, then there should be no >> problem storing them in TreeBASE. >> >> bp >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports >> 2008 30-Day >> trial. Simplify your report design, integration and deployment - >> and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Treebase-devel mailing list >> Tre...@li... >> https://lists.sourceforge.net/lists/listinfo/treebase-devel >> > > > > -- > NOTE: I will soon lose my UBC email address, please start using my > gmail address instead (rut...@gm...) > > Dr. Rutger A. Vos > Department of zoology > University of British Columbia > http://www.nexml.org > http://rutgervos.blogspot.com -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu : =========================================================== |
|
From: Rutger V. <rut...@gm...> - 2009-08-10 20:35:57
|
Is TreeBASE (to some extent) a triple store? No. But it would be nice if it could collaborate with one. I'd love to talk about some sort of community effort to make that work. But for now TreeBASE is strictly based on a strongly typed relational schema, so you can understand that it can't capture phenoscape annotations. On Fri, Aug 7, 2009 at 6:22 AM, William Piel<wil...@ya...> wrote: > > On Aug 6, 2009, at 10:54 AM, Hilmar Lapp wrote: > >> I understand that TreeBASE2 can now output NeXML. However, can it >> also ingest and store the contents of NeXML? > > no. > >> More specifically, can TreeBASE2 ingest and store arbitrary metadata >> attached to trees, nodes, and matrix cells? > > no -- only the standard pre-colon and post-colon vaules; and for each > tree, a fixed set of metadata (tree quality, tree type, etc) plus > values that authors are free to enter whatever they want (tree title, > label, comments, etc). > >> We would be very interested in this in the context of the Phenoscape >> project (http://phenoscape.org) where we create NeXML files with the >> phylogenetic character data and tree with embedded formal phenotype >> assertions that are attached to matrix cells. Is it possible to >> submit these files to TreeBASE2, and to get those back out, e.g., >> using the REST API? > > TreeBASE2 uses a headless version of Mesquite to parse nexus files. If > a module is developed to parse NeXML into Mesquite, that would be one > way to bring NeXML into TreeBASE2. Alternatively, we would need to > write a NeXML parser. Our schema is largely designed to capture data > that are transportable via nexus files -- for matrix files that means > character labels and state labels. If "phenoscape assertions" can be > coded as character labels and state labels, then there should be no > problem storing them in TreeBASE. > > bp > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel > -- NOTE: I will soon lose my UBC email address, please start using my gmail address instead (rut...@gm...) Dr. Rutger A. Vos Department of zoology University of British Columbia http://www.nexml.org http://rutgervos.blogspot.com |
|
From: William P. <wil...@ya...> - 2009-08-07 13:22:50
|
On Aug 6, 2009, at 10:54 AM, Hilmar Lapp wrote: > I understand that TreeBASE2 can now output NeXML. However, can it > also ingest and store the contents of NeXML? no. > More specifically, can TreeBASE2 ingest and store arbitrary metadata > attached to trees, nodes, and matrix cells? no -- only the standard pre-colon and post-colon vaules; and for each tree, a fixed set of metadata (tree quality, tree type, etc) plus values that authors are free to enter whatever they want (tree title, label, comments, etc). > We would be very interested in this in the context of the Phenoscape > project (http://phenoscape.org) where we create NeXML files with the > phylogenetic character data and tree with embedded formal phenotype > assertions that are attached to matrix cells. Is it possible to > submit these files to TreeBASE2, and to get those back out, e.g., > using the REST API? TreeBASE2 uses a headless version of Mesquite to parse nexus files. If a module is developed to parse NeXML into Mesquite, that would be one way to bring NeXML into TreeBASE2. Alternatively, we would need to write a NeXML parser. Our schema is largely designed to capture data that are transportable via nexus files -- for matrix files that means character labels and state labels. If "phenoscape assertions" can be coded as character labels and state labels, then there should be no problem storing them in TreeBASE. bp |
|
From: Mark D. <mjd...@ge...> - 2009-08-06 18:29:23
|
Mark Dominus wrote: > 2. Then I need to import the data that we dumped at SDSC. This is now in progress. Most of it will go in quickly, but getting the matrix elements in will take at least several days. Load speed seems to be around 44,000 records per minute, and the matrixelement table contains 3.05e8 records. |
|
From: Hilmar L. <hl...@du...> - 2009-08-06 14:54:22
|
I understand that TreeBASE2 can now output NeXML. However, can it also ingest and store the contents of NeXML? More specifically, can TreeBASE2 ingest and store arbitrary metadata attached to trees, nodes, and matrix cells? We would be very interested in this in the context of the Phenoscape project (http://phenoscape.org) where we create NeXML files with the phylogenetic character data and tree with embedded formal phenotype assertions that are attached to matrix cells. Is it possible to submit these files to TreeBASE2, and to get those back out, e.g., using the REST API? -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu : =========================================================== |
|
From: Mark D. <mjd...@ge...> - 2009-08-05 18:42:16
|
With Jon Auman's help, I have been setting up the development and production environment. As of last week, I can run some trivial applications that use all the infrastructure (Pg, Hibernate, etc.) that TreeBase will require. I had Hibernate generate a new empty database for TreeBase to use; this part seems to be working properly. The next steps are: 1. TreeBase has an initialization script that preloads the database with a few initial items, such as the names of the various security roles. I need to run this on the empty database. 2. Then I need to import the data that we dumped at SDSC. 3. Finally, I need to delete the data that was inserted into the SDSC database during beta-testing. I will probably send mail about these items in the next few days as I do them or if I need advice. |
|
From: Mark D. <mj...@ge...> - 2009-08-05 18:41:24
|
Hilmar Lapp wrote: > FYI. Has the TreeBASE code been fixed meanwhile to store passwords > only encrypted so they cannot be recovered? > > If not, I'm inclined to ask that this be fixed before we open up the > application on a NESCent server. In other words, if it hasn't been > addressed yet, can we make this a priority now? I have code for this close to finished; I will try to have it checked in by the end of the week. |
|
From: youjun g. <you...@ya...> - 2009-08-01 02:52:16
|
That's Did help thanks. Youjun On Fri, Jul 31, 2009 at 6:37 PM, Rutger Vos <rut...@gm...> wrote: > Hi Youjun, > > thanks for catching up, it was nice meeting you in Berkeley. > > The TreeBase source is located on sourceforge.net, and it's subdivided > in two main source trees: > > * (svn co) > https://treebase.svn.sourceforge.net/svnroot/treebase/trunk/treebase-core/ > this is the part that handles ORM > * (svn co) > https://treebase.svn.sourceforge.net/svnroot/treebase/trunk/treebase-web/ > this is the part that handles MVC web app > > I would check out both as separate eclipse projects, we have .project > files under svn that provide a starting point, you may have to modify > the settings a bit in accordance with your system. > > Hope that helps, > > Rutger > > On Fri, Jul 31, 2009 at 1:33 PM, youjun guo<you...@ya...> wrote: > > Hi, Rutger, > > > > Do you know what is the best way for me to check out the TreeBase source > > code repository? > > > > > > Thank you very much! > > > > Youjun > > > > > > -- > Dr. Rutger A. Vos > Department of zoology > University of British Columbia > http://www.nexml.org > http://rutgervos.blogspot.com > |
|
From: Rutger V. <rut...@gm...> - 2009-07-31 22:38:04
|
Hi Youjun, thanks for catching up, it was nice meeting you in Berkeley. The TreeBase source is located on sourceforge.net, and it's subdivided in two main source trees: * (svn co) https://treebase.svn.sourceforge.net/svnroot/treebase/trunk/treebase-core/ this is the part that handles ORM * (svn co) https://treebase.svn.sourceforge.net/svnroot/treebase/trunk/treebase-web/ this is the part that handles MVC web app I would check out both as separate eclipse projects, we have .project files under svn that provide a starting point, you may have to modify the settings a bit in accordance with your system. Hope that helps, Rutger On Fri, Jul 31, 2009 at 1:33 PM, youjun guo<you...@ya...> wrote: > Hi, Rutger, > > Do you know what is the best way for me to check out the TreeBase source > code repository? > > > Thank you very much! > > Youjun > -- Dr. Rutger A. Vos Department of zoology University of British Columbia http://www.nexml.org http://rutgervos.blogspot.com |
|
From: Hilmar L. <hl...@du...> - 2009-07-30 14:59:58
|
FYI. Has the TreeBASE code been fixed meanwhile to store passwords only encrypted so they cannot be recovered? If not, I'm inclined to ask that this be fixed before we open up the application on a NESCent server. In other words, if it hasn't been addressed yet, can we make this a priority now? -hilmar Begin forwarded message: From: Chris Fields <cjf...@gm...> Date: July 30, 2009 9:27:57 AM EDT To: BioPerl List <bio...@li...> Subject: [Bioperl-l] Perlmonks hacked All, In case there are a few users who haven't been notified, PerlMonks has been hacked rather severely: http://perlmonks.org/ The site was unsecure; all passwords were (astonishingly) stored as plain text, are out in the open, can be easily found (I did, and not I will not point them out). If anyone has decided to use a common password for, say Perlmonks and PAUSE (or Amazon, or CitiBank, or...), make sure to change both. Also realize that PerlMonks is NOT https, and that they have NOT patched the security hole yet, so any changed password may be further compromised (don't use a common password). In fact, your PAUSE account may be frozen already due to this: http://use.perl.org/~Alias/journal/39372 It's hard to overstate the intense irony of all this. For some reaction: http://perlhacks.com/2009/07/perl-monks-passwords.php http://blog.afoolishmanifesto.com/archives/1028 <now you can smack you hand against your head in frustration> Good luck! chris _______________________________________________ Bioperl-l mailing list Bio...@li... http://lists.open-bio.org/mailman/listinfo/bioperl-l -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu : =========================================================== |
|
From: Hilmar L. <hl...@ne...> - 2009-07-08 07:47:32
|
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 : =========================================================== |
|
From: Hilmar L. <hl...@ne...> - 2009-07-08 05:43:11
|
On Jul 7, 2009, at 8:58 PM, Rutger Vos wrote: >> You aren't trying to suggest that dcterms.title or >> dcterms.identifier should >> mean different things for different finders, right? > > I kind of am: in find/study, dcterms.identifier is a study ID, in > find/tree, dcterms.identifier is a tree ID. I think that's a very bad idea. It defeats the purpose of a controlled vocabulary (let alone ontology) to formalize unambiguously what we mean, and that we mean the same thing when we use the same term in the same application. > Internally, the finders traverse a CQL parse tree and translate > these predicates into more refined subproperties > (tb.identifier.study and tb.identifier.tree, > respectively). In other words, if a tree is the subject, then the > predicate dcterms.identifier is interpreted as the refined subproperty > tb.identifier.tree. To me this is backwards to how an ontology works. You would use the refined sub-properties, and if an agent doesn't understand what to do with it it would use the ontology to get at a more general term which it might recognize. In RDF and OWL properties don't change their meaning based on subject or object. Rather, subject and object can change their semantics by applying a property (that has range or domain defined) to them. > By the way, I made a simple ontology (attached) that formalizes this > inheritance. What I can see is that they are declared as subproperty of dc.identifier. They make no assertions about range or domain, no? > I've seen many examples using dublin core predicates whose exact > semantics are context-dependent. Yes, but not within the same application profile (metadata vocabulary), right? > >> 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? > > I think it stands in the way of clean design because any finder > (find/tree, find/matrix, find/study) potentially needs to process > predicates from any other domain (e.g. find/tree apparently needs to > know about study IDs But that is only true for TreeBASE. That one finder implementation in TreeBASE should not cooperate with another finder implementation in TreeBASE is your design decision, not one from PhyloWS, right? -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Rutger V. <rut...@gm...> - 2009-07-08 05:43:00
|
Hi Hilmar, all, thanks for your comments! >> I notice that this departs a bit from the phylows that is proposed here. >> For example, the proposed phylows puts "/find/" before "/tree/", whereas >> you have it the other way. > > Right, this is not in compliance with the spec. find/ comes first as it > changes the resource from a record and its URI to a finder. Right, switching that around is fairly trivial, so I'll do that. > Also, find/taxon/ would imply that you are finding (and returning) taxa, > which if I understand correctly is not the case - rather it seems you have > one query parameter in the URI path (namely that you are searching by > taxon?) and one in the query string. So if this is searching trees, it needs > to be find/tree/, and if you are matching against taxon names, the query > parameter needs to be tb.taxon.name or whatever the blessed metadata term > for this purpose is. > > Third, recordSchema=tree means that you want records back in the tree > schema. Unless you have invented that schema meanwhile, this is in all > likelihood not what you want. Rather, the value should be nexml I suppose. > find/tree already implies that you are finding (and returning) trees, so > there is no point in expressing that redundantly in the query string. You > might want to specify that you only want the tree and not also the matrix, > but that would be a separate query parameter and should not be confounded > with the return format. Mmmmm... I think this warrants a little more discussion. It's probably true that for most implementors their searches can be conveniently decomposed into several domains (tree search/matrix search/taxon search/etc.) and that for each domain the metaphor is that of searching a single table where the CQL indices are that table's columns. Then, within each domain there is a limited number of concerns: how to search on the provided indices and how to format the results. For example, for a search like http://8ball.sdsc.edu:6666/treebase-web/search/studySearch.html?query=dcterms.identifier=S2484&format=rss1&recordSchema=tree the implementation is thus: * there is a self-contained study searcher * the searcher knows how predicates map onto columns in the study table (e.g. dcterms.identifier is the same as study.id) * the searcher knows how to unpack a study object and get the trees out if instead we'd have phylows/tree/find?query=study.identifier=S2484, the implementation would be something like: * there is a tree searcher * the tree searcher needs to know not just about the tree table but also about how all other predicates map onto all other tables, and how they join with the tree table * the tree searcher needs to know how to traverse study objects and where trees are inside the study object * (and similar overlap of concerns becomes necessary if we want the trees for a given matrix, or for a taxon, or what have you) To me that seems like bad design. We'll lose any separation of concern and might end up with a lot of redundancy between searchers - and a lot more code (and bugs) to write. I realize that I'm overloading the "recordSchema" token (and should fix that) 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. Rutger -- Dr. Rutger A. Vos Department of zoology University of British Columbia http://www.nexml.org http://rutgervos.blogspot.com |
|
From: Rutger V. <rut...@gm...> - 2009-07-08 04:54:58
|
> You aren't trying to suggest that dcterms.title or dcterms.identifier should > mean different things for different finders, right? I kind of am: in find/study, dcterms.identifier is a study ID, in find/tree, dcterms.identifier is a tree ID. Internally, the finders traverse a CQL parse tree and translate these predicates into more refined subproperties (tb.identifier.study and tb.identifier.tree, respectively). In other words, if a tree is the subject, then the predicate dcterms.identifier is interpreted as the refined subproperty tb.identifier.tree. By the way, I made a simple ontology (attached) that formalizes this inheritance. Would be nice to have this available as http://purl.org/phylo/treebase/terms# or whatever (speaking of which: have you had a chance to add me to the treebase & phylows purl domains?) Seems to me that's pretty much in line with the Contextual part of CQL - I've seen many examples using dublin core predicates whose exact semantics are context-dependent. (By the way 2, you're saying "*should* mean different things for different finders". I don't know whether they *should*, but that's certainly how they are implemented now.) > 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? I think it stands in the way of clean design because any finder (find/tree, find/matrix, find/study) potentially needs to process predicates from any other domain (e.g. find/tree apparently needs to know about study IDs), which is harder than just having to deal with your own domain and subsequently having to project your result set into a different domain. Rutger -- Dr. Rutger A. Vos Department of zoology University of British Columbia http://www.nexml.org http://rutgervos.blogspot.com |
|
From: Rutger V. <rut...@gm...> - 2009-07-08 04:09:37
|
Sorry, the PhyloWS URL of the search example is (at present): http://8ball.sdsc.edu:6666/treebase-web/phylows/study/find?query=dcterms.identifier=S2484&format=rss1&recordSchema=tree On Tue, Jul 7, 2009 at 5:17 PM, Rutger Vos<rut...@gm...> wrote: > Hi Hilmar, all, > > thanks for your comments! > >>> I notice that this departs a bit from the phylows that is proposed here. >>> For example, the proposed phylows puts "/find/" before "/tree/", whereas >>> you have it the other way. >> >> Right, this is not in compliance with the spec. find/ comes first as it >> changes the resource from a record and its URI to a finder. > > Right, switching that around is fairly trivial, so I'll do that. > >> Also, find/taxon/ would imply that you are finding (and returning) taxa, >> which if I understand correctly is not the case - rather it seems you have >> one query parameter in the URI path (namely that you are searching by >> taxon?) and one in the query string. So if this is searching trees, it needs >> to be find/tree/, and if you are matching against taxon names, the query >> parameter needs to be tb.taxon.name or whatever the blessed metadata term >> for this purpose is. >> >> Third, recordSchema=tree means that you want records back in the tree >> schema. Unless you have invented that schema meanwhile, this is in all >> likelihood not what you want. Rather, the value should be nexml I suppose. >> find/tree already implies that you are finding (and returning) trees, so >> there is no point in expressing that redundantly in the query string. You >> might want to specify that you only want the tree and not also the matrix, >> but that would be a separate query parameter and should not be confounded >> with the return format. > > Mmmmm... I think this warrants a little more discussion. It's probably > true that for most implementors their searches can be conveniently > decomposed into several domains (tree search/matrix search/taxon > search/etc.) and that for each domain the metaphor is that of > searching a single table where the CQL indices are that table's > columns. > > Then, within each domain there is a limited number of concerns: how to > search on the provided indices and how to format the results. For > example, for a search like > http://8ball.sdsc.edu:6666/treebase-web/search/studySearch.html?query=dcterms.identifier=S2484&format=rss1&recordSchema=tree > the implementation is thus: > > * there is a self-contained study searcher > * the searcher knows how predicates map onto columns in the study > table (e.g. dcterms.identifier is the same as study.id) > * the searcher knows how to unpack a study object and get the trees out > > if instead we'd have phylows/tree/find?query=study.identifier=S2484, > the implementation would be something like: > > * there is a tree searcher > * the tree searcher needs to know not just about the tree table but > also about how all other predicates map onto all other tables, and how > they join with the tree table > * the tree searcher needs to know how to traverse study objects and > where trees are inside the study object > * (and similar overlap of concerns becomes necessary if we want the > trees for a given matrix, or for a taxon, or what have you) > > To me that seems like bad design. We'll lose any separation of concern > and might end up with a lot of redundancy between searchers - and a > lot more code (and bugs) to write. I realize that I'm overloading the > "recordSchema" token (and should fix that) 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. > > Rutger > > -- > Dr. Rutger A. Vos > Department of zoology > University of British Columbia > http://www.nexml.org > http://rutgervos.blogspot.com > -- Dr. Rutger A. Vos Department of zoology University of British Columbia http://www.nexml.org http://rutgervos.blogspot.com |
9 messages has been excluded from this view by a project administrator.
