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: Hilmar L. <hl...@ne...> - 2011-11-11 22:09:41
|
On Nov 7, 2011, at 9:08 AM, Arlin Stoltzfus wrote: > 5. Is it problematic that MEGA is not open-source, e.g., with > respect to devoting resources to working with a non-open-source? That depends on the framework and what resources are devoted to. For example, code developed under NESCent sponsorship (such as a NESCent- sponsored hackathon) must be or become available as open-source. But there are different moving parts in, for example, making MEGA support NeXML output. Perhaps some moving parts, specifically those benefitting from collaborating with non-MEGA people, can be coded as open-source. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
From: Rutger V. <R....@re...> - 2011-11-10 15:37:29
|
It is still happening, but actually, come to think of it, I'm now behind a different firewall too so I need to find out first whether it's blocking any ports. I should check at home first before I bug he...@ne... because it might be on my end after all. On Thu, Nov 10, 2011 at 4:14 PM, Hilmar Lapp <hl...@ne...> wrote: > BTW Rutger, can you still reproduce this? We've had a power outage > last night for several hours, and while most services weren't affected > by that, a server that acts as one source of authentication services > was. > > -hilmar > > On Nov 10, 2011, at 7:43 AM, Rutger Vos wrote: > >> Hi all, >> >> I'm trying to connect to treebasedev through JDBC (inside eclipse, I >> didn't change anything about the configuration on my end) but my >> connection is being refused. Have the login credentials changed? Any >> other ideas what might be happening? I'm posting this to a public list >> so if the credentials have somehow changed please don't just reply >> with user names and passwords. >> >> Here's a stack trace: >> >> [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1] WARN >> com.mchange.v2.resourcepool.BasicResourcePool - >> com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@66c8e4de -- >> Acquisition Attempt Failed!!! Clearing pending acquires. While trying >> to acquire a needed new resource, we failed to succeed more than the >> maximum number of allowed acquisition attempts (30). Last acquisition >> attempt exception: >> org.postgresql.util.PSQLException: Connection refused. Check that the >> hostname and port are correct and that the postmaster is accepting >> TCP/IP connections. >> at >> org >> .postgresql >> .core >> .v3 >> .ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java: >> 123) >> at >> org >> .postgresql >> .core.ConnectionFactory.openConnection(ConnectionFactory.java:66) >> at >> org >> .postgresql >> .jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java: >> 124) >> at >> org >> .postgresql >> .jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:30) >> at org.postgresql.jdbc3.Jdbc3Connection.<init>(Jdbc3Connection.java: >> 24) >> at org.postgresql.Driver.makeConnection(Driver.java:386) >> at org.postgresql.Driver.connect(Driver.java:260) >> at >> com >> .mchange >> .v2 >> .c3p0 >> .DriverManagerDataSource.getConnection(DriverManagerDataSource.java: >> 134) >> at >> com >> .mchange >> .v2 >> .c3p0 >> .WrapperConnectionPoolDataSource >> .getPooledConnection(WrapperConnectionPoolDataSource.java:182) >> at >> com >> .mchange >> .v2 >> .c3p0 >> .WrapperConnectionPoolDataSource >> .getPooledConnection(WrapperConnectionPoolDataSource.java:171) >> at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool >> $ >> 1PooledConnectionResourcePoolManager >> .acquireResource(C3P0PooledConnectionPool.java:137) >> at >> com >> .mchange >> .v2.resourcepool.BasicResourcePool.doAcquire(BasicResourcePool.java: >> 1014) >> at com.mchange.v2.resourcepool.BasicResourcePool.access >> $800(BasicResourcePool.java:32) >> at com.mchange.v2.resourcepool.BasicResourcePool >> $AcquireTask.run(BasicResourcePool.java:1810) >> at com.mchange.v2.async.ThreadPoolAsynchronousRunner >> $PoolThread.run(ThreadPoolAsynchronousRunner.java:547) >> Caused by: java.net.ConnectException: Connection refused >> at java.net.PlainSocketImpl.socketConnect(Native Method) >> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) >> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java: >> 195) >> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) >> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:432) >> at java.net.Socket.connect(Socket.java:525) >> at java.net.Socket.connect(Socket.java:475) >> at java.net.Socket.<init>(Socket.java:372) >> at java.net.Socket.<init>(Socket.java:186) >> at org.postgresql.core.PGStream.<init>(PGStream.java:62) >> at >> org >> .postgresql >> .core >> .v3 >> .ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java: >> 77) >> ... 14 more >> >> Thanks, >> >> Rutger >> >> -- >> Dr. Rutger A. Vos >> School of Biological Sciences >> Philip Lyle Building, Level 4 >> University of Reading >> Reading, RG6 6BX, United Kingdom >> Tel: +44 (0) 118 378 7535 >> http://rutgervos.blogspot.com >> >> ------------------------------------------------------------------------------ >> RSA(R) Conference 2012 >> Save $700 by Nov 18 >> Register now >> http://p.sf.net/sfu/rsa-sfdev2dev1 >> _______________________________________________ >> Treebase-devel mailing list >> Tre...@li... >> https://lists.sourceforge.net/lists/listinfo/treebase-devel > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : > =========================================================== > > > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel > -- Dr. Rutger A. Vos School of Biological Sciences Philip Lyle Building, Level 4 University of Reading Reading, RG6 6BX, United Kingdom Tel: +44 (0) 118 378 7535 http://rutgervos.blogspot.com |
From: Hilmar L. <hl...@ne...> - 2011-11-10 15:15:07
|
BTW Rutger, can you still reproduce this? We've had a power outage last night for several hours, and while most services weren't affected by that, a server that acts as one source of authentication services was. -hilmar On Nov 10, 2011, at 7:43 AM, Rutger Vos wrote: > Hi all, > > I'm trying to connect to treebasedev through JDBC (inside eclipse, I > didn't change anything about the configuration on my end) but my > connection is being refused. Have the login credentials changed? Any > other ideas what might be happening? I'm posting this to a public list > so if the credentials have somehow changed please don't just reply > with user names and passwords. > > Here's a stack trace: > > [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1] WARN > com.mchange.v2.resourcepool.BasicResourcePool - > com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@66c8e4de -- > Acquisition Attempt Failed!!! Clearing pending acquires. While trying > to acquire a needed new resource, we failed to succeed more than the > maximum number of allowed acquisition attempts (30). Last acquisition > attempt exception: > org.postgresql.util.PSQLException: Connection refused. Check that the > hostname and port are correct and that the postmaster is accepting > TCP/IP connections. > at > org > .postgresql > .core > .v3 > .ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java: > 123) > at > org > .postgresql > .core.ConnectionFactory.openConnection(ConnectionFactory.java:66) > at > org > .postgresql > .jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java: > 124) > at > org > .postgresql > .jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:30) > at org.postgresql.jdbc3.Jdbc3Connection.<init>(Jdbc3Connection.java: > 24) > at org.postgresql.Driver.makeConnection(Driver.java:386) > at org.postgresql.Driver.connect(Driver.java:260) > at > com > .mchange > .v2 > .c3p0 > .DriverManagerDataSource.getConnection(DriverManagerDataSource.java: > 134) > at > com > .mchange > .v2 > .c3p0 > .WrapperConnectionPoolDataSource > .getPooledConnection(WrapperConnectionPoolDataSource.java:182) > at > com > .mchange > .v2 > .c3p0 > .WrapperConnectionPoolDataSource > .getPooledConnection(WrapperConnectionPoolDataSource.java:171) > at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool > $ > 1PooledConnectionResourcePoolManager > .acquireResource(C3P0PooledConnectionPool.java:137) > at > com > .mchange > .v2.resourcepool.BasicResourcePool.doAcquire(BasicResourcePool.java: > 1014) > at com.mchange.v2.resourcepool.BasicResourcePool.access > $800(BasicResourcePool.java:32) > at com.mchange.v2.resourcepool.BasicResourcePool > $AcquireTask.run(BasicResourcePool.java:1810) > at com.mchange.v2.async.ThreadPoolAsynchronousRunner > $PoolThread.run(ThreadPoolAsynchronousRunner.java:547) > Caused by: java.net.ConnectException: Connection refused > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) > at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java: > 195) > at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:432) > at java.net.Socket.connect(Socket.java:525) > at java.net.Socket.connect(Socket.java:475) > at java.net.Socket.<init>(Socket.java:372) > at java.net.Socket.<init>(Socket.java:186) > at org.postgresql.core.PGStream.<init>(PGStream.java:62) > at > org > .postgresql > .core > .v3 > .ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java: > 77) > ... 14 more > > Thanks, > > Rutger > > -- > Dr. Rutger A. Vos > School of Biological Sciences > Philip Lyle Building, Level 4 > University of Reading > Reading, RG6 6BX, United Kingdom > Tel: +44 (0) 118 378 7535 > http://rutgervos.blogspot.com > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
From: Hilmar L. <hl...@ne...> - 2011-11-10 14:20:25
|
Can you send this to he...@ne... and ask whether this could be due to a change in firewall settings? We did tighten up our firewall. -hilmar On Nov 10, 2011, at 7:43 AM, Rutger Vos wrote: > Hi all, > > I'm trying to connect to treebasedev through JDBC (inside eclipse, I > didn't change anything about the configuration on my end) but my > connection is being refused. Have the login credentials changed? Any > other ideas what might be happening? I'm posting this to a public list > so if the credentials have somehow changed please don't just reply > with user names and passwords. > > Here's a stack trace: > > [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1] WARN > com.mchange.v2.resourcepool.BasicResourcePool - > com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@66c8e4de -- > Acquisition Attempt Failed!!! Clearing pending acquires. While trying > to acquire a needed new resource, we failed to succeed more than the > maximum number of allowed acquisition attempts (30). Last acquisition > attempt exception: > org.postgresql.util.PSQLException: Connection refused. Check that the > hostname and port are correct and that the postmaster is accepting > TCP/IP connections. > at > org > .postgresql > .core > .v3 > .ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java: > 123) > at > org > .postgresql > .core.ConnectionFactory.openConnection(ConnectionFactory.java:66) > at > org > .postgresql > .jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java: > 124) > at > org > .postgresql > .jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:30) > at org.postgresql.jdbc3.Jdbc3Connection.<init>(Jdbc3Connection.java: > 24) > at org.postgresql.Driver.makeConnection(Driver.java:386) > at org.postgresql.Driver.connect(Driver.java:260) > at > com > .mchange > .v2 > .c3p0 > .DriverManagerDataSource.getConnection(DriverManagerDataSource.java: > 134) > at > com > .mchange > .v2 > .c3p0 > .WrapperConnectionPoolDataSource > .getPooledConnection(WrapperConnectionPoolDataSource.java:182) > at > com > .mchange > .v2 > .c3p0 > .WrapperConnectionPoolDataSource > .getPooledConnection(WrapperConnectionPoolDataSource.java:171) > at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool > $ > 1PooledConnectionResourcePoolManager > .acquireResource(C3P0PooledConnectionPool.java:137) > at > com > .mchange > .v2.resourcepool.BasicResourcePool.doAcquire(BasicResourcePool.java: > 1014) > at com.mchange.v2.resourcepool.BasicResourcePool.access > $800(BasicResourcePool.java:32) > at com.mchange.v2.resourcepool.BasicResourcePool > $AcquireTask.run(BasicResourcePool.java:1810) > at com.mchange.v2.async.ThreadPoolAsynchronousRunner > $PoolThread.run(ThreadPoolAsynchronousRunner.java:547) > Caused by: java.net.ConnectException: Connection refused > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) > at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java: > 195) > at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:432) > at java.net.Socket.connect(Socket.java:525) > at java.net.Socket.connect(Socket.java:475) > at java.net.Socket.<init>(Socket.java:372) > at java.net.Socket.<init>(Socket.java:186) > at org.postgresql.core.PGStream.<init>(PGStream.java:62) > at > org > .postgresql > .core > .v3 > .ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java: > 77) > ... 14 more > > Thanks, > > Rutger > > -- > Dr. Rutger A. Vos > School of Biological Sciences > Philip Lyle Building, Level 4 > University of Reading > Reading, RG6 6BX, United Kingdom > Tel: +44 (0) 118 378 7535 > http://rutgervos.blogspot.com > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
From: Rutger V. <R....@re...> - 2011-11-10 12:43:23
|
Hi all, I'm trying to connect to treebasedev through JDBC (inside eclipse, I didn't change anything about the configuration on my end) but my connection is being refused. Have the login credentials changed? Any other ideas what might be happening? I'm posting this to a public list so if the credentials have somehow changed please don't just reply with user names and passwords. Here's a stack trace: [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1] WARN com.mchange.v2.resourcepool.BasicResourcePool - com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@66c8e4de -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (30). Last acquisition attempt exception: org.postgresql.util.PSQLException: Connection refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections. at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:123) at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66) at org.postgresql.jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java:124) at org.postgresql.jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:30) at org.postgresql.jdbc3.Jdbc3Connection.<init>(Jdbc3Connection.java:24) at org.postgresql.Driver.makeConnection(Driver.java:386) at org.postgresql.Driver.connect(Driver.java:260) at com.mchange.v2.c3p0.DriverManagerDataSource.getConnection(DriverManagerDataSource.java:134) at com.mchange.v2.c3p0.WrapperConnectionPoolDataSource.getPooledConnection(WrapperConnectionPoolDataSource.java:182) at com.mchange.v2.c3p0.WrapperConnectionPoolDataSource.getPooledConnection(WrapperConnectionPoolDataSource.java:171) at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.acquireResource(C3P0PooledConnectionPool.java:137) at com.mchange.v2.resourcepool.BasicResourcePool.doAcquire(BasicResourcePool.java:1014) at com.mchange.v2.resourcepool.BasicResourcePool.access$800(BasicResourcePool.java:32) at com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask.run(BasicResourcePool.java:1810) at com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547) Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:432) at java.net.Socket.connect(Socket.java:525) at java.net.Socket.connect(Socket.java:475) at java.net.Socket.<init>(Socket.java:372) at java.net.Socket.<init>(Socket.java:186) at org.postgresql.core.PGStream.<init>(PGStream.java:62) at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:77) ... 14 more Thanks, Rutger -- Dr. Rutger A. Vos School of Biological Sciences Philip Lyle Building, Level 4 University of Reading Reading, RG6 6BX, United Kingdom Tel: +44 (0) 118 378 7535 http://rutgervos.blogspot.com |
From: Rutger V. <R....@re...> - 2011-11-08 14:52:48
|
> The "low-hanging fruit" version that Bill describes would mean just > putting a text blob into a NeXML "submission" or "miapa_checklist" > element designed specifically for this purpose. Given external > vocabulary support, NeXML can support something a bit better than > this, which is to have a "submission" or "miapa_checklist" bag filled > with RDF-like triples (using NeXML's scheme for this). A further step > might be to build some of the logical structure of the MIAPA checklist > into the NeXML schema, though this raises the question of whether it > all belongs in a "miapa-checklist" element or should be distributed in > various places in the file (e.g., alignment method with characters, > tree method with tree, author data at the top level, etc). I don't think a text blob is truly a low hanging fruit if that means it is some sort of opaque flat text syntax that would have to be parsed separately from NeXML syntax. XML element structures can be the values/objects of semantic annotations so I would suggest that as the entry-level (but still suboptimal) way of doing this. Since parts of MIAPA metadata are applicable to specific types of data objects (e.g. alignment parameters apply to multiple sequence alignments) of which there can be multiples in a single document, I would strongly suggest distributing checklist elements to relevant positions in a document. > 3. If we want to build in support for measuring MIAPA conformance > (i.e., this submission gets a 3.2 out of 7 checklist items), then > there must be some kind of standardized grammar so that a machine can > detect whether or not a record has specified a particular checklist > element, e.g., alignment method. A text blob will not suffice for > this. So the more granular the annotations are, the better - though I think it unrealistically optimistic to expect us to be able to validate individual annotation values (e.g. do these alignment parameters make sense?). But at least we'd be able to report presence/absence. > 4. None of this addresses where we are going to get controlled > vocabularies to specify alignment methods, for instance. Several > people have tried to address this, and there are resources out there > that have some elements of the desired vocabulary (mygrid services > ontology; O'Meara's treetapper resource; CDAO). Its easy to start > this but hard to finish. As Bill mentioned, it was a goal of CIPRES, > too. Every time someone tries to do this, they end up with a hornet's > nest. But maybe that is due to the lack of a clear target-- which > perhaps is remedied by having a miapa checklist and an auto-submission > problem to solve. That seems to be the way things are done around here :-) > 5. Is it problematic that MEGA is not open-source, e.g., with respect > to devoting resources to working with a non-open-source? According to > Sudhir (I asked him specifically about this) "the source code for the > computational core is available upon request and permission is granted > to use the computational core of MEGA for personal research and > testing only", but that the GUI is based on proprietary components and > the source code is not available. Would this prevent us from working > with MEGA programmers at a NESCent hackathon, for instance? Would we > ask Sudhir to open-source the submission component of the code as a > separate module? I can't imagine that's a showstopper. Either the submission component is factored out as a separate module - which is probably the best way to go about it anyway from MEGA's design p.o.v. - or any other hackers are just going to have to promise not to look at the proprietary GUI components, which are irrelevant here anyway. Or something. Rutger > On Nov 6, 2011, at 7:50 PM, Hilmar Lapp wrote: > >> Hi Arlin, >> >> I spoke with Sudhir earlier this year at the ISMB conference about >> pretty much the same thing. The Dryad-TreeBASE interface isn't secret >> in any way [1,2], and as Bill points out is quite limited in what it >> achieves. >> >> In the ABI grant proposal we submitted in July [3], we actually >> propose to create precisely such a submission API that 3rd party >> applications can use to submit richly annotated data to TreeBASE >> directly, and indeed we propose to build on the Dryad/TreeBASE hand- >> shaking interface to accomplish this. If Sudhir has resources >> available to prototype this now, at the end of TreeBASE or MEGA or >> both, that'd be terrific, and I'd be happy to help as far as I can to >> facilitate that better. >> >> BTW I also spoke with Sudhir about possibly supporting NeXML from >> within MEGA, and he appeared very open to that - he said that >> essentially all he needs is someone who can help by providing the >> guidance on NeXML implementation. MEGA supporting NeXML wouldn't help >> with TreeBASE submission right now, but I imagine that the envisioned >> programmable submission API would certainly rely on NeXML. >> >> -hilmar >> >> [1] https://datadryad.org/wiki/TreeBASE_Submission_Integration >> [2] https://datadryad.org/wiki/BagIt_Handshaking >> [3] http://www.evoio.org/wiki/ABI_2011_proposal >> >> On Nov 4, 2011, at 7:53 AM, Arlin Stoltzfus wrote: >> >>> Hello all. Yesterday I had a talk with Sudhir Kumar, author of MEGA, >>> which probably is responsible for more published trees than any other >>> phylogeny inference package (not necessarily the most trees among the >>> phylogeny elite represented in TreeBASE). I discovered that MEGA >>> has >>> a graphical name-reconciling interface for users to align mismatched >>> OTU names between tree and alignment files-- this is a common problem >>> and a barrier to re-use that I have encountered personally multiple >>> times. >>> >>> He suggested the idea that, to facilitate effective archiving, it >>> might be useful to have a way for phylogeny applications to >>> generate a >>> submission in TreeBASE, providing metadata such as software version >>> and run conditions. >>> >>> Probably you have heard this suggestion before (I heard it earlier >>> this week from Joseph Hughes in regard to BEAST). >>> >>> I mentioned that TreeBASE has a top-secret interface that Dryad uses >>> to submit NEXUS files, and that this could be the basis for a >>> submission interface for other applications. My understanding is >>> that >>> this is done via web-services, and that the user gets a link to a >>> temporary submission that must be completed interactively. I hope I >>> didn't give the wrong impression. >>> >>> Anyway, Sudhir was very interested in this. He said that he has >>> programmers with time to work on this kind of thing. If the MEGA >>> team prototyped a direct-submission interface, they could write a >>> brief paper about it, and maybe we could get other developers >>> together >>> to hash out the metadata terms to support, based on the recent MIAPA >>> exercise at TDWG. If we could get MEGA and the top 3 TreeBASE >>> programs (PAUP, MB, RAXML-- right?), that would cover a very large >>> segment of users. >>> >>> I realize that this approach might not be the best way to promote >>> archiving in the long-term. However, it might be more effective in >>> the short term, and we might learn a lot from it. >>> >>> I'd like to hear any thoughts you have on this. Would this be a >>> useful exercise? What are the disadvantages? How could it fit >>> into a >>> larger strategy? >>> >>> Arlin >>> ------- >>> Arlin Stoltzfus (ar...@um...) >>> Fellow, IBBR; Adj. Assoc. Prof., UMCP; Research Biologist, NIST >>> IBBR, 9600 Gudelsky Drive, Rockville, MD >>> tel: 240 314 6208; web: www.molevol.org >>> >>> >>> ------------------------------------------------------------------------------ >>> RSA(R) Conference 2012 >>> Save $700 by Nov 18 >>> Register now >>> http://p.sf.net/sfu/rsa-sfdev2dev1 >>> _______________________________________________ >>> Treebase-devel mailing list >>> Tre...@li... >>> https://lists.sourceforge.net/lists/listinfo/treebase-devel >> >> -- >> =========================================================== >> : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : >> =========================================================== >> >> >> > > ------- > Arlin Stoltzfus (ar...@um...) > Fellow, IBBR; Adj. Assoc. Prof., UMCP; Research Biologist, NIST > IBBR, 9600 Gudelsky Drive, Rockville, MD > tel: 240 314 6208; web: www.molevol.org > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel > -- Dr. Rutger A. Vos School of Biological Sciences Philip Lyle Building, Level 4 University of Reading Reading, RG6 6BX, United Kingdom Tel: +44 (0) 118 378 7535 http://rutgervos.blogspot.com |
From: Arlin S. <ar...@um...> - 2011-11-07 14:08:36
|
Based on what Bill and Hilmar are saying, there is some enthusiasm for this. So let me make some comments and ask a few questions with the aim of stimulating discussion on what is the best way to proceed. 1. We now have a clear (albeit provisional) target for a metadata standard, which is the reconciled MIAPA draft checklist from the recent TDWG workshop: http://wiki.tdwg.org/twiki/bin/view/Phylogenetics/MIAPADraft#Reconciled_draft_checklist This specifies what kinds of things needs to be said to satisfy "minimum" reporting, e.g., "alignment method". But it does not provide a controlled vocabulary, a grammar, or a syntax for that. 2. The submission interface could be based on NeXML, as Bill suggests, i.e., all of the metadata could be packed into NeXML elements and streamed to TB. This has some advantages in terms of promoting standardization and building on all of the grammar and syntax that NeXML has already. The "low-hanging fruit" version that Bill describes would mean just putting a text blob into a NeXML "submission" or "miapa_checklist" element designed specifically for this purpose. Given external vocabulary support, NeXML can support something a bit better than this, which is to have a "submission" or "miapa_checklist" bag filled with RDF-like triples (using NeXML's scheme for this). A further step might be to build some of the logical structure of the MIAPA checklist into the NeXML schema, though this raises the question of whether it all belongs in a "miapa-checklist" element or should be distributed in various places in the file (e.g., alignment method with characters, tree method with tree, author data at the top level, etc). 3. If we want to build in support for measuring MIAPA conformance (i.e., this submission gets a 3.2 out of 7 checklist items), then there must be some kind of standardized grammar so that a machine can detect whether or not a record has specified a particular checklist element, e.g., alignment method. A text blob will not suffice for this. 4. None of this addresses where we are going to get controlled vocabularies to specify alignment methods, for instance. Several people have tried to address this, and there are resources out there that have some elements of the desired vocabulary (mygrid services ontology; O'Meara's treetapper resource; CDAO). Its easy to start this but hard to finish. As Bill mentioned, it was a goal of CIPRES, too. Every time someone tries to do this, they end up with a hornet's nest. But maybe that is due to the lack of a clear target-- which perhaps is remedied by having a miapa checklist and an auto-submission problem to solve. 5. Is it problematic that MEGA is not open-source, e.g., with respect to devoting resources to working with a non-open-source? According to Sudhir (I asked him specifically about this) "the source code for the computational core is available upon request and permission is granted to use the computational core of MEGA for personal research and testing only", but that the GUI is based on proprietary components and the source code is not available. Would this prevent us from working with MEGA programmers at a NESCent hackathon, for instance? Would we ask Sudhir to open-source the submission component of the code as a separate module? Arlin On Nov 6, 2011, at 7:50 PM, Hilmar Lapp wrote: > Hi Arlin, > > I spoke with Sudhir earlier this year at the ISMB conference about > pretty much the same thing. The Dryad-TreeBASE interface isn't secret > in any way [1,2], and as Bill points out is quite limited in what it > achieves. > > In the ABI grant proposal we submitted in July [3], we actually > propose to create precisely such a submission API that 3rd party > applications can use to submit richly annotated data to TreeBASE > directly, and indeed we propose to build on the Dryad/TreeBASE hand- > shaking interface to accomplish this. If Sudhir has resources > available to prototype this now, at the end of TreeBASE or MEGA or > both, that'd be terrific, and I'd be happy to help as far as I can to > facilitate that better. > > BTW I also spoke with Sudhir about possibly supporting NeXML from > within MEGA, and he appeared very open to that - he said that > essentially all he needs is someone who can help by providing the > guidance on NeXML implementation. MEGA supporting NeXML wouldn't help > with TreeBASE submission right now, but I imagine that the envisioned > programmable submission API would certainly rely on NeXML. > > -hilmar > > [1] https://datadryad.org/wiki/TreeBASE_Submission_Integration > [2] https://datadryad.org/wiki/BagIt_Handshaking > [3] http://www.evoio.org/wiki/ABI_2011_proposal > > On Nov 4, 2011, at 7:53 AM, Arlin Stoltzfus wrote: > >> Hello all. Yesterday I had a talk with Sudhir Kumar, author of MEGA, >> which probably is responsible for more published trees than any other >> phylogeny inference package (not necessarily the most trees among the >> phylogeny elite represented in TreeBASE). I discovered that MEGA >> has >> a graphical name-reconciling interface for users to align mismatched >> OTU names between tree and alignment files-- this is a common problem >> and a barrier to re-use that I have encountered personally multiple >> times. >> >> He suggested the idea that, to facilitate effective archiving, it >> might be useful to have a way for phylogeny applications to >> generate a >> submission in TreeBASE, providing metadata such as software version >> and run conditions. >> >> Probably you have heard this suggestion before (I heard it earlier >> this week from Joseph Hughes in regard to BEAST). >> >> I mentioned that TreeBASE has a top-secret interface that Dryad uses >> to submit NEXUS files, and that this could be the basis for a >> submission interface for other applications. My understanding is >> that >> this is done via web-services, and that the user gets a link to a >> temporary submission that must be completed interactively. I hope I >> didn't give the wrong impression. >> >> Anyway, Sudhir was very interested in this. He said that he has >> programmers with time to work on this kind of thing. If the MEGA >> team prototyped a direct-submission interface, they could write a >> brief paper about it, and maybe we could get other developers >> together >> to hash out the metadata terms to support, based on the recent MIAPA >> exercise at TDWG. If we could get MEGA and the top 3 TreeBASE >> programs (PAUP, MB, RAXML-- right?), that would cover a very large >> segment of users. >> >> I realize that this approach might not be the best way to promote >> archiving in the long-term. However, it might be more effective in >> the short term, and we might learn a lot from it. >> >> I'd like to hear any thoughts you have on this. Would this be a >> useful exercise? What are the disadvantages? How could it fit >> into a >> larger strategy? >> >> Arlin >> ------- >> Arlin Stoltzfus (ar...@um...) >> Fellow, IBBR; Adj. Assoc. Prof., UMCP; Research Biologist, NIST >> IBBR, 9600 Gudelsky Drive, Rockville, MD >> tel: 240 314 6208; web: www.molevol.org >> >> >> ------------------------------------------------------------------------------ >> RSA(R) Conference 2012 >> Save $700 by Nov 18 >> Register now >> http://p.sf.net/sfu/rsa-sfdev2dev1 >> _______________________________________________ >> Treebase-devel mailing list >> Tre...@li... >> https://lists.sourceforge.net/lists/listinfo/treebase-devel > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : > =========================================================== > > > ------- Arlin Stoltzfus (ar...@um...) Fellow, IBBR; Adj. Assoc. Prof., UMCP; Research Biologist, NIST IBBR, 9600 Gudelsky Drive, Rockville, MD tel: 240 314 6208; web: www.molevol.org |
From: Arlin S. <ar...@um...> - 2011-11-07 14:00:19
|
On Nov 5, 2011, at 1:14 PM, William Piel wrote: > (In the meantime, I've been hoping to find time to write up > instructions for submitting data to TreeBASE from MEGA -- it's not > difficult, but many people are still naive as to how to do this). I think "how to" docs could have a huge impact on this. We already know where most of the trees in TB come from-- PAUP, MrBayes, MEGA, RAXML, BEAST. If users could find out, in each case, how to get their data into the right form, this would be a huge help. Arlin ------- Arlin Stoltzfus (ar...@um...) Fellow, IBBR; Adj. Assoc. Prof., UMCP; Research Biologist, NIST IBBR, 9600 Gudelsky Drive, Rockville, MD tel: 240 314 6208; web: www.molevol.org |
From: Hilmar L. <hl...@ne...> - 2011-11-07 00:51:01
|
Hi Arlin, I spoke with Sudhir earlier this year at the ISMB conference about pretty much the same thing. The Dryad-TreeBASE interface isn't secret in any way [1,2], and as Bill points out is quite limited in what it achieves. In the ABI grant proposal we submitted in July [3], we actually propose to create precisely such a submission API that 3rd party applications can use to submit richly annotated data to TreeBASE directly, and indeed we propose to build on the Dryad/TreeBASE hand- shaking interface to accomplish this. If Sudhir has resources available to prototype this now, at the end of TreeBASE or MEGA or both, that'd be terrific, and I'd be happy to help as far as I can to facilitate that better. BTW I also spoke with Sudhir about possibly supporting NeXML from within MEGA, and he appeared very open to that - he said that essentially all he needs is someone who can help by providing the guidance on NeXML implementation. MEGA supporting NeXML wouldn't help with TreeBASE submission right now, but I imagine that the envisioned programmable submission API would certainly rely on NeXML. -hilmar [1] https://datadryad.org/wiki/TreeBASE_Submission_Integration [2] https://datadryad.org/wiki/BagIt_Handshaking [3] http://www.evoio.org/wiki/ABI_2011_proposal On Nov 4, 2011, at 7:53 AM, Arlin Stoltzfus wrote: > Hello all. Yesterday I had a talk with Sudhir Kumar, author of MEGA, > which probably is responsible for more published trees than any other > phylogeny inference package (not necessarily the most trees among the > phylogeny elite represented in TreeBASE). I discovered that MEGA has > a graphical name-reconciling interface for users to align mismatched > OTU names between tree and alignment files-- this is a common problem > and a barrier to re-use that I have encountered personally multiple > times. > > He suggested the idea that, to facilitate effective archiving, it > might be useful to have a way for phylogeny applications to generate a > submission in TreeBASE, providing metadata such as software version > and run conditions. > > Probably you have heard this suggestion before (I heard it earlier > this week from Joseph Hughes in regard to BEAST). > > I mentioned that TreeBASE has a top-secret interface that Dryad uses > to submit NEXUS files, and that this could be the basis for a > submission interface for other applications. My understanding is that > this is done via web-services, and that the user gets a link to a > temporary submission that must be completed interactively. I hope I > didn't give the wrong impression. > > Anyway, Sudhir was very interested in this. He said that he has > programmers with time to work on this kind of thing. If the MEGA > team prototyped a direct-submission interface, they could write a > brief paper about it, and maybe we could get other developers together > to hash out the metadata terms to support, based on the recent MIAPA > exercise at TDWG. If we could get MEGA and the top 3 TreeBASE > programs (PAUP, MB, RAXML-- right?), that would cover a very large > segment of users. > > I realize that this approach might not be the best way to promote > archiving in the long-term. However, it might be more effective in > the short term, and we might learn a lot from it. > > I'd like to hear any thoughts you have on this. Would this be a > useful exercise? What are the disadvantages? How could it fit into a > larger strategy? > > Arlin > ------- > Arlin Stoltzfus (ar...@um...) > Fellow, IBBR; Adj. Assoc. Prof., UMCP; Research Biologist, NIST > IBBR, 9600 Gudelsky Drive, Rockville, MD > tel: 240 314 6208; web: www.molevol.org > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
From: William P. <wil...@ya...> - 2011-11-05 17:15:06
|
On Nov 4, 2011, at 6:53 AM, Arlin Stoltzfus wrote: > I mentioned that TreeBASE has a top-secret interface that Dryad uses > to submit NEXUS files, and that this could be the basis for a > submission interface for other applications. My understanding is that > this is done via web-services, and that the user gets a link to a > temporary submission that must be completed interactively. I hope I > didn't give the wrong impression. Although note that is is really basic and primitive: it just saves the user the pain of retyping the citation; saves the user re-uploading the datasets; and it creates mutual linking IDs between the Dryad submission and the TreeBASE submission. But nothing fancier than that.. What would surely be useful is if we had an XML/OWL/RDF standard for describing any kind of analysis parameters in a generic fashion. That was one of the goals of CIPRES: a common communication format than any software program could be taught to understand and socket into, and one that TreeBASE could store, or that Kepler could incorporate in a pipeline. Rutger's NeXML had its origins in that, but only so far as replicating what the universal blocks in NEXUS could store. The ability to describe substitution parameters or tree search strategies in generic fashion did not materialize out of CIPRES. Short of this, TreeBASE has a primitive and generic way of storing a list of commands for a program -- i.e. as a text blob -- the downside being that it's only interpretable by the program that it's designed for, and it may or may not be valid (usually not valid -- e.g. when taxa are referenced with numbers, yet the order of taxa in the taxa block are easily shuffled). So a low-hanging-fruit solution is to have programs like MEGA express NeXML along with a text-blob of whatever MEGA-commands were used between the input data and the output data. TreeBASE would be taught to ingest this, validate the NeXML, and then populate the analysis records with the MEGA-command blob. (In the meantime, I've been hoping to find time to write up instructions for submitting data to TreeBASE from MEGA -- it's not difficult, but many people are still naive as to how to do this). At any rate, thanks for pursuing these valuable conversations with Sudhir, etc. bp |
From: Arlin S. <ar...@um...> - 2011-11-04 17:53:58
|
I added a link to Linnaeus (see last slide) in my PowerPoint presentation of this problem: http://dl.dropbox.com/u/7727158/name_matching.pptx Let me know if there are other resources that I should note. That way we won't lose the knowledge that we accumulated in this discussion thread. Arlin On Aug 27, 2011, at 5:28 AM, Hilmar Lapp wrote: > I spoke with the developer, Martin Gerner. He thought it might be > well applicable to this task, even though the tool does a lot more > than we possibly need here. For example, it tokenizes the input, and > also is capable of applying some special "inference" rules (for > instance, "HeLa cells" will be tagged with "Homo sapiens") that are > quite useful if the purpose is linking of text to knowledge terms, > but go beyond simple synonym matching (which it does, too, though). > The dictionaries are pluggable, and apparently it is quite fast in > principle. > > -hilmar > > On Aug 22, 2011, at 6:39 PM, Mark Holder wrote: > >> Hi all, >> I just noticed that Hilmar tweeted a link to Linnaeus: http://linnaeus.sourceforge.net/ >> which seems relevant to this thread. >> >> all the best, >> Mark >> >> On Aug 19, 2011, at 11:06 AM, Arlin Stoltzfus wrote: >> >>> On Aug 15, 2011, at 4:09 AM, Roderic Page wrote: >>> >>>> Mapping tree names to matrix names could be formulated as a >>>> bipartite matching problem, where we have two lists of names and >>>> want to find the best matching. See http://iphylo.blogspot.com/2007/09/matching-names-in-phylogeny-data-files.html >>>> for more details. >>> >>> In computer science, this is called the "marriage problem" when >>> the two lists are the same size. We have a set { X } and a set >>> { Y } of elements with some properties. We have a function >>> f( X_i, Y_j ) that computes a match score for each pair, using the >>> properties. In our case, the only property is the name-string. >>> The marriage problem is to find a pairwise mapping that is optimal >>> in some way. If optimality means minimizing the cost of the >>> worst match, then this is (apparently, to me) the same as the >>> linear bottleneck assignment problem. >>> >>> An obvious function to use (not necessarily the best for our case) >>> is the edit distance, i.e., the number of character-wise edit >>> operations to convert X_i into Y_j. This is called the >>> Levenshtein distance (http://en.wikipedia.org/wiki/Levenshtein_distance >>> ). >>> >>> But there is nothing to stop us from creating a distance function >>> that is optimized to work well in phyloinformatics. We could test >>> different functions using real cases such as the ones in my >>> slideshow. >>> >>> One special condition is that, for us, the cost of a s/ >>> <underscore>/<space> / edit is very low. Another special >>> condition is reflected in Rod's longest-common-substring method of >>> matching-- we often have pairs of matching names that have long >>> matching substrings and differ by interruptions. Maybe we need a >>> gap-open and gap-extend penalty like in sequence alignment >>> algorithms. >>> >>> Arlin >>> >>>> This approach could extended to, say, matching names in a NEXUS >>>> file to those in a publication, or a GenBank POPSET from a >>>> publication. For example, if we have a NEXUS file and a POPSET we >>>> could compute the best matching between the two sets of names. Or >>>> taxon names and/or accession numbers could be retrieved from the >>>> publication. >>>> >>>> This would also help provide the context to help avoid homonyms, >>>> such as matching animal names to plant names. >>>> >>>> Regards >>>> >>>> Rod >>>> >>>> >>>> On 15 Aug 2011, at 05:13, Rutger Vos wrote: >>>> >>>>>> this calls for easy-to-use NeXML editors. e.g. add the ability >>>>>> to enter >>>>>> Genbank accession numbers in Mesquite, and then save as NeXML, >>>>>> thus >>>>>> preserving "Homo_sapiens" consistently in all alignments and >>>>>> resulting >>>>>> trees, while still communicating the respective accession >>>>>> numbers for each >>>>>> locus. Summer-of-Code project here. >>>>> >>>>> Indeed. >>>>> >>>>>> C- The basic data model of matrix-rows-matching-with-tree-OTUs >>>>>> works for 99% >>>>>> of datasets, but a growing number of studies use BEAST species >>>>>> inference >>>>>> (and other similar methods) where the tree ends in species >>>>>> OTUs, but the >>>>>> alignment has many more haplotype OTUs. -- i.e. there is, on >>>>>> purpose, a >>>>>> complete mismatch between alignment row labels and tree OTUs. >>>>>> Mesquite can >>>>>> handle this using a taxon association table, though I don't >>>>>> know that this >>>>>> is formal NEXUS or just a Mesquite invention. I don't think >>>>>> that NeXML or >>>>>> PhyloML can handle this. This calls for expanding the >>>>>> capabilities of NeXML >>>>>> and PhyloML. >>>>> >>>>> Yes and no. Multiple matrix rows can reference the same otu, but >>>>> that's not quite what we want. Multiple, separately annotatable >>>>> matrix >>>>> row segments would be a good feature to have, also for TreeBASE's >>>>> needs. >>>>> >>>>> >>>>> >>>>> -- >>>>> Dr. Rutger A. Vos >>>>> School of Biological Sciences >>>>> Philip Lyle Building, Level 4 >>>>> University of Reading >>>>> Reading, RG6 6BX, United Kingdom >>>>> Tel: +44 (0) 118 378 7535 >>>>> http://rutgervos.blogspot.com >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> uberSVN's rich system and user administration capabilities and >>>>> model >>>>> configuration take the hassle out of deploying and managing >>>>> Subversion and >>>>> the tools developers use with it. Learn more about uberSVN and >>>>> get a free >>>>> download at: http://p.sf.net/sfu/wandisco-dev2dev >>>>> _______________________________________________ >>>>> Treebase-devel mailing list >>>>> Tre...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/treebase-devel >>>>> >>>> >>>> >>>> --------------------------------------------------------- >>>> Roderic Page >>>> Professor of Taxonomy >>>> Institute of Biodiversity, Animal Health and Comparative Medicine >>>> College of Medical, Veterinary and Life Sciences >>>> Graham Kerr Building >>>> University of Glasgow >>>> Glasgow G12 8QQ, UK >>>> >>>> Email: r....@bi... >>>> Tel: +44 141 330 4778 >>>> Fax: +44 141 330 2792 >>>> AIM: rod...@ai... >>>> Facebook: http://www.facebook.com/profile.php?id=1112517192 >>>> Twitter: http://twitter.com/rdmpage >>>> Blog: http://iphylo.blogspot.com >>>> Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html >>>> >>> >>> ------- >>> Arlin Stoltzfus (ar...@um...) >>> Fellow, IBBR; Adj. Assoc. Prof., UMCP; Research Biologist, NIST >>> IBBR, 9600 Gudelsky Drive, Rockville, MD >>> tel: 240 314 6208; web: www.molevol.org >>> >>> ------------------------------------------------------------------------------ >>> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, >>> user administration capabilities and model configuration. Take >>> the hassle out of deploying and managing Subversion and the >>> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2_______________________________________________ >>> Treebase-devel mailing list >>> Tre...@li... >>> https://lists.sourceforge.net/lists/listinfo/treebase-devel >> >> ------------------------------------------------------------------------------ >> uberSVN's rich system and user administration capabilities and model >> configuration take the hassle out of deploying and managing >> Subversion and >> the tools developers use with it. Learn more about uberSVN and get >> a free >> download at: http://p.sf.net/sfu/wandisco-dev2dev >> _______________________________________________ >> Treebase-devel mailing list >> Tre...@li... >> https://lists.sourceforge.net/lists/listinfo/treebase-devel > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : > =========================================================== > > > > > -- > You received this message because you are subscribed to the Google > Groups "MIAPA" group. > For more options, visit this group at > http://groups.google.com/group/miapa-discuss?hl=en ------- Arlin Stoltzfus (ar...@um...) Fellow, IBBR; Adj. Assoc. Prof., UMCP; Research Biologist, NIST IBBR, 9600 Gudelsky Drive, Rockville, MD tel: 240 314 6208; web: www.molevol.org |
From: Arlin S. <ar...@um...> - 2011-11-04 11:54:09
|
Hello all. Yesterday I had a talk with Sudhir Kumar, author of MEGA, which probably is responsible for more published trees than any other phylogeny inference package (not necessarily the most trees among the phylogeny elite represented in TreeBASE). I discovered that MEGA has a graphical name-reconciling interface for users to align mismatched OTU names between tree and alignment files-- this is a common problem and a barrier to re-use that I have encountered personally multiple times. He suggested the idea that, to facilitate effective archiving, it might be useful to have a way for phylogeny applications to generate a submission in TreeBASE, providing metadata such as software version and run conditions. Probably you have heard this suggestion before (I heard it earlier this week from Joseph Hughes in regard to BEAST). I mentioned that TreeBASE has a top-secret interface that Dryad uses to submit NEXUS files, and that this could be the basis for a submission interface for other applications. My understanding is that this is done via web-services, and that the user gets a link to a temporary submission that must be completed interactively. I hope I didn't give the wrong impression. Anyway, Sudhir was very interested in this. He said that he has programmers with time to work on this kind of thing. If the MEGA team prototyped a direct-submission interface, they could write a brief paper about it, and maybe we could get other developers together to hash out the metadata terms to support, based on the recent MIAPA exercise at TDWG. If we could get MEGA and the top 3 TreeBASE programs (PAUP, MB, RAXML-- right?), that would cover a very large segment of users. I realize that this approach might not be the best way to promote archiving in the long-term. However, it might be more effective in the short term, and we might learn a lot from it. I'd like to hear any thoughts you have on this. Would this be a useful exercise? What are the disadvantages? How could it fit into a larger strategy? Arlin ------- Arlin Stoltzfus (ar...@um...) Fellow, IBBR; Adj. Assoc. Prof., UMCP; Research Biologist, NIST IBBR, 9600 Gudelsky Drive, Rockville, MD tel: 240 314 6208; web: www.molevol.org |
From: Rutger V. <R....@re...> - 2011-10-30 19:15:10
|
Hi all, here's a post about what I put together yesterday: https://plus.google.com/u/0/105469729345350166208/posts/AMS4uyMuTGo Rutger -- Dr. Rutger A. Vos School of Biological Sciences Philip Lyle Building, Level 4 University of Reading Reading, RG6 6BX, United Kingdom Tel: +44 (0) 118 378 7535 http://rutgervos.blogspot.com |
From: Hilmar L. <hl...@ne...> - 2011-10-27 22:47:29
|
Let me just add here that there is no requirement that every metadata attribute available for querying through PhyloWS is also a column in some database table, or an attribute for which the database stores a value. It is up to phylogenetic data providers how to resolve a PhyloWS query, and there is no reason that the TreeBASE CQL to SQL mapper couldn't translate a query for hasBranchLengths=true (as an example) into SQL that would filter results to exclude trees that don't have branch lengths. -hilmar On Oct 27, 2011, at 6:35 PM, William Piel wrote: > > On Oct 27, 2011, at 2:12 PM, Carl Boettiger wrote: > >> I think the primary thing I noticed was that I couldn't identify if >> a tree had branch-length information without downloading the actual >> data file. > > hmm.. The database itself does not store a flag to indicate whether > a tree has or has not any branch-lengths. But it has been our > intention to comply more fully with the PhyloWS specs and provide > URIs to all objects, including nodes. Hence, presumably there could > eventually be a query like this: > > /phylows/node/find?query=brlen>0&recordSchema=tree > > Is that what you have in mind? > > Alternatively, perhaps it would be better to pre-calculate and store > metadata separately, like "longest root to tip path", "tree > balance", "mean clade support", etc. > > bp > > > ------------------------------------------------------------------------------ > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev_______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
From: William P. <wil...@ya...> - 2011-10-27 22:35:55
|
On Oct 27, 2011, at 2:12 PM, Carl Boettiger wrote: > I think the primary thing I noticed was that I couldn't identify if a tree had branch-length information without downloading the actual data file. hmm.. The database itself does not store a flag to indicate whether a tree has or has not any branch-lengths. But it has been our intention to comply more fully with the PhyloWS specs and provide URIs to all objects, including nodes. Hence, presumably there could eventually be a query like this: /phylows/node/find?query=brlen>0&recordSchema=tree Is that what you have in mind? Alternatively, perhaps it would be better to pre-calculate and store metadata separately, like "longest root to tip path", "tree balance", "mean clade support", etc. bp |
From: Carl B. <cbo...@gm...> - 2011-10-27 21:12:56
|
Hi Rutger, Thanks. Overall the API has been great - I still need to add a few of the recent prism additions to the phylo-ws side, I'm doing most of the meta-data over OAI-MPH. I think the primary thing I noticed was that I couldn't identify if a tree had branch-length information without downloading the actual data file. If there's a way to do this from the metadata it could be very helpful. (Ideally identify as well whether or not the branch lengths were in units of time; i.e. a time-calibrated chronogram vs an example where branch lengths are still in mutational steps. Also, I love how treebase has the methods encoded for creating the trees; e.g. which software was used; but I didn't see how to pull that out with the API? My apologies if I overlooked something. Cheers, Carl On Thu, Oct 27, 2011 at 6:56 AM, Rutger Vos <R....@re...> wrote: > Hi Carl, > > very cool - great to see the TreeBASE API being built upon. I'd be > interested to hear about any bugs/idiosyncrasies you've encountered. > > Best wishes, > > Rutger > > On Wed, Oct 26, 2011 at 3:14 AM, Carl Boettiger <cbo...@gm...> > wrote: > > Hi list, > > I have created a simple R package for accessing phylogenetic trees in > > treebase from the R interface, which is now on cran. I've posted a few > > examples of how to do simple queries, replicate published examples, and > > create automatically updating meta-analyses here. (Also included in R's > > demo() package function). > > Hope this is useful, I'd welcome bug reports or feature requests. > > Cheers, > > Carl > > -- > > Carl Boettiger > > UC Davis > > http://www.carlboettiger.info/ > > > > > > > ------------------------------------------------------------------------------ > > The demand for IT networking professionals continues to grow, and the > > demand for specialized networking skills is growing even more rapidly. > > Take a complimentary Learning@Cisco Self-Assessment and learn > > about Cisco certifications, training, and career opportunities. > > http://p.sf.net/sfu/cisco-dev2dev > > _______________________________________________ > > Treebase-devel mailing list > > Tre...@li... > > https://lists.sourceforge.net/lists/listinfo/treebase-devel > > > > > > > > -- > Dr. Rutger A. Vos > School of Biological Sciences > Philip Lyle Building, Level 4 > University of Reading > Reading, RG6 6BX, United Kingdom > Tel: +44 (0) 118 378 7535 > http://rutgervos.blogspot.com > -- Carl Boettiger UC Davis http://www.carlboettiger.info/ |
From: Rutger V. <R....@re...> - 2011-10-27 13:57:02
|
Hi Carl, very cool - great to see the TreeBASE API being built upon. I'd be interested to hear about any bugs/idiosyncrasies you've encountered. Best wishes, Rutger On Wed, Oct 26, 2011 at 3:14 AM, Carl Boettiger <cbo...@gm...> wrote: > Hi list, > I have created a simple R package for accessing phylogenetic trees in > treebase from the R interface, which is now on cran. I've posted a few > examples of how to do simple queries, replicate published examples, and > create automatically updating meta-analyses here. (Also included in R's > demo() package function). > Hope this is useful, I'd welcome bug reports or feature requests. > Cheers, > Carl > -- > Carl Boettiger > UC Davis > http://www.carlboettiger.info/ > > > ------------------------------------------------------------------------------ > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel > > -- Dr. Rutger A. Vos School of Biological Sciences Philip Lyle Building, Level 4 University of Reading Reading, RG6 6BX, United Kingdom Tel: +44 (0) 118 378 7535 http://rutgervos.blogspot.com |
From: Carl B. <cbo...@gm...> - 2011-10-26 17:53:20
|
On Wed, Oct 26, 2011 at 10:12 AM, William Piel <wil...@ya...>wrote: > > > On Oct 26, 2011, at 9:19 AM, Hilmar Lapp wrote: > > That's awesome, thanks Carl! -hilmar > > > Ditto. > > Thanks a million Carl. > > I'd like to create a link from our TreeBASE wiki to > http://www.carlboettiger.info/archives/3019 , but how stable is that? > Would you mind if I copied verbiage/examples from your page and put it in > our wiki? > > bp > > Thanks Bill! Feel free to copy the examples, all content on my site is cc-by anyhow. > > > On Oct 25, 2011, at 10:14 PM, Carl Boettiger wrote: > > Hi list, > > I have created a simple R package for accessing phylogenetic trees in > treebase from the R interface, which is now on cran. I've posted a few > examples of how to do simple queries, replicate published examples, and > create automatically updating meta-analyses here<http://www.carlboettiger.info/archives/3019>. > (Also included in R's demo() package function). > > Hope this is useful, I'd welcome bug reports or feature requests. > > Cheers, > Carl > > -- > Carl Boettiger > UC Davis > http://www.carlboettiger.info/ > > > -- Carl Boettiger UC Davis http://www.carlboettiger.info/ |
From: William P. <wil...@ya...> - 2011-10-26 17:12:57
|
On Oct 26, 2011, at 9:19 AM, Hilmar Lapp wrote: > That's awesome, thanks Carl! -hilmar Ditto. Thanks a million Carl. I'd like to create a link from our TreeBASE wiki to http://www.carlboettiger.info/archives/3019 , but how stable is that? Would you mind if I copied verbiage/examples from your page and put it in our wiki? bp > On Oct 25, 2011, at 10:14 PM, Carl Boettiger wrote: > >> Hi list, >> >> I have created a simple R package for accessing phylogenetic trees in treebase from the R interface, which is now on cran. I've posted a few examples of how to do simple queries, replicate published examples, and create automatically updating meta-analyses here. (Also included in R's demo() package function). >> >> Hope this is useful, I'd welcome bug reports or feature requests. >> >> Cheers, >> Carl >> >> -- >> Carl Boettiger >> UC Davis >> http://www.carlboettiger.info/ >> |
From: Hilmar L. <hl...@ne...> - 2011-10-26 16:20:23
|
That's awesome, thanks Carl! -hilmar On Oct 25, 2011, at 10:14 PM, Carl Boettiger wrote: > Hi list, > > I have created a simple R package for accessing phylogenetic trees > in treebase from the R interface, which is now on cran. I've posted > a few examples of how to do simple queries, replicate published > examples, and create automatically updating meta-analyses here. > (Also included in R's demo() package function). > > Hope this is useful, I'd welcome bug reports or feature requests. > > Cheers, > Carl > > -- > Carl Boettiger > UC Davis > http://www.carlboettiger.info/ > -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
From: Carl B. <cbo...@gm...> - 2011-10-26 02:14:26
|
Hi list, I have created a simple R package for accessing phylogenetic trees in treebase from the R interface, which is now on cran. I've posted a few examples of how to do simple queries, replicate published examples, and create automatically updating meta-analyses here<http://www.carlboettiger.info/archives/3019>. (Also included in R's demo() package function). Hope this is useful, I'd welcome bug reports or feature requests. Cheers, Carl -- Carl Boettiger UC Davis http://www.carlboettiger.info/ |
From: William P. <wil...@ya...> - 2011-10-25 16:01:03
|
TreeBASE's time-zone is in EST, so finding all TreeBASE citations published in 2010 or later means searching prism.publicationDate for any time point between 2010-01-01T05:00:00Z and 2011-01-01T04:59:59Z. So in theory, the following should find anything published in 2011 or later in the journal Evolution: http://purl.org/phylo/treebase/phylows/study/find?query=prism.publicationName=="Evolution"+and+prism.publicationDate>"2011-08-30T05:00:00Z" ... but evidently the "and" bit is broken, so it appears to be ignoring the date... shucks. Sorry... bp On Oct 25, 2011, at 8:22 AM, Arlin Stoltzfus wrote: > Hello, all. I have some newbie questions about how to use phyloWS to > get counts of studies in TreeBASE from the publication year 2010, from > specific journals. I could not search for a year using the web > interface-- with no field restriction, searching in citation gives > inconsistent results. > > Is prism.publicationDate the right field? Using phyloWS with > publicationDate=="2010" gives an untrapped exception error. > > So, then I looked at the API page (http://sourceforge.net/apps/mediawiki/treebase/index.php?title=API > ) and noticed the thing with specifying the exact date and time. I > found that I could use phyloWS to search for anything later that the > last second of 2009: > > http://treebase.org/treebase-web/search/studySearch.html?query=prism.publicationDate >> "2009-12-31T23:59:59Z" > > but this yielded studies with publication dates in 2009. Is that a > bug or am I missing something here? > > When I tried to combine search terms, like this: > > http://treebase.org/treebase-web/search/studySearch.html?query=prism.publicationDate >> "2009-12-31T23:59:59Z"&prism. publicationDate <"2011-01-01T00:00:00Z" > > or this > > http://treebase.org/treebase-web/search/studySearch.html?query=prism.publicationDate >> "2009-12-31T23:59:59Z"&prism.publicationName=="Evolution" > > the results suggest that the second term is being ignored. > > Arlin > ------- > Arlin Stoltzfus (ar...@um...) > Fellow, IBBR; Adj. Assoc. Prof., UMCP; Research Biologist, NIST > IBBR, 9600 Gudelsky Drive, Rockville, MD > tel: 240 314 6208; web: www.molevol.org |
From: Arlin S. <ar...@um...> - 2011-10-25 15:23:04
|
Hello, all. I have some newbie questions about how to use phyloWS to get counts of studies in TreeBASE from the publication year 2010, from specific journals. I could not search for a year using the web interface-- with no field restriction, searching in citation gives inconsistent results. Is prism.publicationDate the right field? Using phyloWS with publicationDate=="2010" gives an untrapped exception error. So, then I looked at the API page (http://sourceforge.net/apps/mediawiki/treebase/index.php?title=API ) and noticed the thing with specifying the exact date and time. I found that I could use phyloWS to search for anything later that the last second of 2009: http://treebase.org/treebase-web/search/studySearch.html?query=prism.publicationDate >"2009-12-31T23:59:59Z" but this yielded studies with publication dates in 2009. Is that a bug or am I missing something here? When I tried to combine search terms, like this: http://treebase.org/treebase-web/search/studySearch.html?query=prism.publicationDate >"2009-12-31T23:59:59Z"&prism. publicationDate <"2011-01-01T00:00:00Z" or this http://treebase.org/treebase-web/search/studySearch.html?query=prism.publicationDate >"2009-12-31T23:59:59Z"&prism.publicationName=="Evolution" the results suggest that the second term is being ignored. Arlin ------- Arlin Stoltzfus (ar...@um...) Fellow, IBBR; Adj. Assoc. Prof., UMCP; Research Biologist, NIST IBBR, 9600 Gudelsky Drive, Rockville, MD tel: 240 314 6208; web: www.molevol.org |
From: Hilmar L. <hl...@ne...> - 2011-09-30 21:42:57
|
Hi Arlin - sorry for the slow response. I think that's a great idea. I had originally expected that we'd put most emphasis on identifying MIAPA attributes important for reuse by biodiversity science-oriented applications, but even then there should surely be room for such an activity in parallel. I've been meaning to get a page for the event up on the wiki, so we can start pooling the suggestions (and participants) there in advance. Will hopefully get to that within the next days, but if you have time, please feel free to beat me to it. BTW re: the original emphasis as stated above, I'm a little worried by now that we have had no expressions of interest from biodiversity scientists. I don't want to speculate yet whether that means that biodiversity science doesn't care about (reusing) phylogenies, but we should probably nonetheless distribute a reminder. -hilmar On Sep 23, 2011, at 12:14 PM, Arlin Stoltzfus wrote: > I'd like to get some feedback on an idea for a workshop project. > This came up earlier today in a discussion with Jim Leebens-Mack, > Enrico Pontelli & Maryam Panahiazar. We are interested in > annotating a set of phylogenetic studies (one of the suggested > deliverables below). The process of annotation would help us to > work out the metadata attributes needed to describe a study-- in > particular, describing phylogenetic methods and workflows is a > thorny problem--, and the resulting set of annotated studies could > serve as a benchmark or training set for automated methods. > > We talked about using random samples of phylogeny publications, or > some set of canonical or exemplary publications. > > Then the thought occurred to us: if ultimately we are trying to > facilitate data-sharing, why waste our time annotating publications > for which we are not offering the supporting data for public re-use > via some searchable interface? Instead, why not annotate some > studies that are already poised for re-use, with the data available > via a searchable interface? An example would be the ~300 studies > that were deposited last year in TreeBASE. If we work with the > TreeBASE providers, perhaps we could provide an search interface > that takes advantage of the extra annotations. Another important > set of re-useable trees is the set of trees agglomerated into the > APG tree, or the ToLWeb tree. > > Any thoughts on this? Would this compromise our other goals of > working out problems in annotation while creating a benchmark set of > publications? What is the best set of publications to annotate? > > Arlin > > On Aug 15, 2011, at 10:36 AM, Nico Cellinese wrote: > >> TDWG MIAPA Workshop >> Call For Participation: >> Steps towards a Minimum Information About a Phylogenetic Analysis >> (MIAPA) Standard >> Synopsis >> >> Many phylogenetic analysis results are published in ways that >> present serious barriers to their reuse in numerous research >> applications that would stand to benefit from them. While some of >> these barriers are well understood, such as issues with adherence >> to standard exchange formats, those centering on the associated >> metadata necessary for researchers to evaluate or reuse a published >> phylogeny have only recently begun to be articulated. One of the >> critical next steps towards formalizing these metadata requirements >> as a minimum reporting standard is to convene meetings of key >> stakeholder communities with the goal to identify information >> attributes necessary and desirable for facilitating reuse, and to >> build consensus on their priority. To this end, we are holding a >> workshop at the 2011 Biodiversity Information Standards (TDWG) >> Conference to determine how a future reporting standard for >> phylogenetic analyses can best serve biodiversity science and >> related research applications. We invite all interested colleagues >> to participate. >> Background >> >> The workshop of the Biodiversity Information Standards (TDWG) >> Phylogenetics Standards Interest Group held at the 2010 TDWG >> conference included a project focused on how to publish re-usable >> trees that can be linked into an emerging global web of data. >> Through follow-up work, this led to the following tangible results: >> An online draft report of the 2010 TDWG workshop [1], and a >> corresponding manuscript on best practices for publishing >> phylogenetic trees (Stoltzfus et al. in preparation); >> An 2011 iEvoBio presentation on “Publishing re-usable phylogenetic >> trees, in theory and in practice” [2]; >> A lighting talk presentation and Birds-of-a-Feather gathering at >> 2011 iEvoBio, and >> A survey group that explored barriers to re-use and developed plans >> for a survey >> These activities have considerably clarified our understanding of >> the theory and practice of publishing re-usable phylogenetic trees: >> how many phylogenies are published each year, the (low) frequency >> of archiving, what archives and tools are available, what policies >> are in force, etc. We have identified a number of barriers to re- >> use involving such aspects as technology, standards, culture, and >> access. >> Many of these barriers can be interpreted as a consequence of the >> lack of a community-agreed standard for what constitutes a well >> documented phylogenetic record. In the absence of such a standard, >> trees are often archived as image files rather than in appropriate >> data exchange formats, and lack important accompanying information >> (metadata), such as externally meaningful identifiers, that would >> be needed to make them useful to others. The idea of a Minimum >> Information About a Phylogenetic Analysis (MIAPA) standard has been >> suggested [3], but so far there has not been a deliberate process >> to develop and disseminate a community standard. Meanwhile, a >> number of systematics and evolution journals have begun to require >> archiving of the data underlying published research findings [4]. >> The emerging cultural shift in data archiving and sharing promoted >> by this policy change offers a unique window of opportunity to move >> ahead with the development and actual specification of a MIAPA >> standard. >> Similar to other minimum reporting standards [5], the primary focus >> of a future MIAPA standard would be on defining a “checklist” of >> metadata information attributes that, at a minimum, needs to >> accompany an archived phylogenetic analysis, and to which standards >> values for these attributes would need to adhere. The key step in >> developing community consensus on these elements of the standard is >> to convene a series of meetings that collectively involve >> participants from all major groups of stakeholders who would be >> affected by such a standard, such as users, producers, publishers, >> or archivists of phylogenetic analyses. To aid this process, the >> Phylogenetics Standards Interest Group is holding a workshop at the >> 2011 TDWG conference, with the goal to obtain consensus >> requirements and priorities for a MIAPA checklist for the purposes >> of biodiversity science, taxonomy, museum collections, and related >> research applications. >> Goals and deliverables >> >> The main goal of the workshop is to develop a shared understanding >> of the role that a MIAPA standard could play in facilitating re-use >> of phylogenetic analyses for the biodiversity science and related >> communities, and what the standard would need to specify in order >> to best fill that role. Possible deliverables include >> A draft set of information attributes that should or could be >> included in a provisional MIAPA checklist, with a level of >> consensus for each of them. >> A database with use-cases based on exemplifying publications, that >> report phylogenies to elucidate a broad spectrum of questions >> relating to biodiversity science. >> A refined MIAPA survey to be informed by biodiversity science cases >> for reuse. >> A plan for further community engagement and consensus-building >> among biodiversity science stakeholders. >> Workshop format >> >> The workshop will start with a few presentations focused on (i) >> introducing MIAPA and its potential in facilitating reuse (J. >> Leebens-Mack); (ii) summarizing recent developments and current >> status of MIAPA-related efforts (A. Stoltzfus); and (iii) past >> experiences and resulting best practice recommendations on >> developing a minimum reporting checklist standard (D. Field). The >> rest of the workshop will be hands-on. Participants in the >> workshop will break out into groups to address separate issues >> according to the anticipated deliverables and best practice >> recommendations. >> The workshop will be 1.5 days in duration, and be held during the >> 2011 Biodiversity Information Standards (TDWG) conference, to take >> place Oct 17 to 21, 2011 in New Orleans, USA. (http://www.tdwg.org/conference2011/ >> ). The workshop will start in the afternoon of Monday, Oct 17, and >> end on Tuesday. Oct 18. >> How to participate >> >> Participation in the workshop is open to everyone interested. >> However, space is limited, and we therefore ask that, if you are >> interested in attending, to please communicate your interest >> through the MIAPA discussion group [6]. This will also allow us to >> include you in pre-workshop planning. Since the workshop is part of >> the TDWG conference, participants will need to register either for >> the full conference, or for the days of the workshop. >> The organizers will provide an electronic venue for participants to >> share ideas and develop plans in advance of the workshop. After >> the initial presentations, participants will self-organize into >> task groups. >> Organizers >> Nico Celinese, University of Florida >> Hilmar Lapp, NESCent >> Jim Leebens-Mack, University of Georgia >> Enrico Pontelli, New Mexico State University >> Arlin Stoltzfus, NIST & University of Maryland >> References >> >> [1] Whitacre et al. (2010). Current Best Practices for Publishing >> Trees Electronically. http://wiki.tdwg.org/twiki/bin/view/Phylogenetics/LinkingTrees2010 >> [2] O’Meara et al. (2011). Publishing re-usable phylogenetic trees, >> in theory and practice. Available from Nature Precedings <http://dx.doi.org/10.1038/npre.2011.6048.1 >> > >> [3] Leebens-Mack, J., T. Vision, et al. (2006). "Taking the first >> steps towards a standard for reporting on phylogenies: Minimum >> Information About a Phylogenetic Analysis (MIAPA)." Omics 10(2): >> 231-7. >> [4] Whitlock, M., M. McPeek, M. Rausher, L. Rieseberg, and A. Moore >> (2010). Data Archiving (Editorial). The American Naturalist 175(2): >> 145. >> [5] Taylor, C.F., D. Field, S. Sansone, J. Aerts, R. Apweiler, M. >> Ashburner, C.A. Ball, et al. (2008). Promoting coherent minimum >> reporting guidelines for biological and biomedical investigations: >> the MIBBI project. Nature Biotechnology 26(8): 889-96. doi:10.1038/ >> nbt.1411 >> [6] MIAPA discussion group: http://groups.google.com/group/miapa-discuss >> Published by Google Docs–Report Abuse–Updated automatically every 5 >> minutes >> <ATT00001.txt> > > ------- > Arlin Stoltzfus (ar...@um...) > Fellow, IBBR; Adj. Assoc. Prof., UMCP; Research Biologist, NIST > IBBR, 9600 Gudelsky Drive, Rockville, MD > tel: 240 314 6208; web: www.molevol.org > > > -- > You received this message because you are subscribed to the Google > Groups "MIAPA" group. > For more options, visit this group at > http://groups.google.com/group/miapa-discuss?hl=en -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
From: Hilmar L. <hl...@ne...> - 2011-09-27 19:32:41
|
Just FYI, CrossRef has stated earlier this year that DOIs should now always be presented in their HTTP URI form. While it's perhaps not too surprising that publishers have been slow to follow suit, that need not mean that we should move at the same pace in following the recommendation, in particular as it goes in precisely the right direction in terms of making our data more Linked Data compliant. Ryan pointed out to me in a recent conversation we've had here that Dryad DOIs are DataCite DOIs, not CrossRef DOIs, but while DataCite apparently so far hasn't taken an official position on whether it is in line with this change, I would argue that they have little reason not to, and so it would seem fair enough for us to preempt that. -hilmar On Sep 26, 2011, at 10:31 PM, William Piel wrote: > Hi Carl, > > Were you deciding to use our OAI service because it allowed search- > by-date? If so, you might want to know that TreeBASE's PhyloWS API > now supports search-by-date, such as: > > /study/find? > query=prism.creationDate>"2011-08-30T05:00:00Z"&format=rss1 > > This now works for prism.creationDate, prism.modificationDate, and > prism.publicationDate. Use the prism.publicationDate for searching > on the publication year of the article -- hence > prism.publicationDate>"2011-01-01T05:00:00Z" includes all papers > with the year 2011 and later (but a second earlier and it would also > include all papers with the year 2010, because in TreeBASE's world, > time is EST, which is 5 hours after London). Use > prism.modificationDate to catch older papers that were since modified. > > The returned data contains article DOIs like so: > > <prism:doi xmlns:prism="http://prismstandard.org/namespaces/1.2/ > basic/">10.1006/mpev.2000.0752</prism:doi> > > Which presumably can be matched with article DOIs in Dryad. > > In our last conversation, I think Ryan said that "For the metadata > on the Dryad end, we still need to correct some issues with the > relationships to TreeBASE objects." > > For the TreeBASE end, we had discussed whether TreeBASE should use > "dcterms:source" or "dcterms:isPartOf" (prefixed with http://dx.doi.org/) > . > > I think we decided on "dcterms:isPartOf" -- I'll check that we're > exposing Dryad DOIs like so. Note that we will be using the "data > package" DOI (e.g. "10.5061/dryad.tf48r") rather than the "data set" > DOI (e.g. "10.5061/dryad.tf48r/2") because only the former is > equivalent to a TreeBASE study. > > bp > > > -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |