treebase-devel — TreeBASE developer mailing list

[Treebase-devel] TreeBASE Production Build

[William P. <wil...@ya...>]

Does anyone object to a new production build today? 

Although the last one was 15 days ago, I think it's worth doing a new one today because Google is in the midst of indexing TreeBASE, and it was an oversight not to include the words "phylogeny" and "phylogenetic" together with each studies taxon list -- and this was just recently fixed. That way people googling a taxon name together with the word "phylogeny" will hit TreeBASE records. 

bp

Re: [Treebase-devel] ABI proposal for phyloinformatics

[Shyket, H. <har...@ya...>]

PostgreSQL 9.0 has begun implementing support for XML through an XML data type (although schema type must be DTD).  Strings can now be cast into an XML type.  This could open up for value retrieval, searching other similar functions in the future.

Harry Shyket
Digital Media Specialist
Yale University Peabody Museum
ph. 203-436-9428
har...@ya...


-----Original Message-----
From: Vladimir Gapeyev [mailto:vla...@du...] 
Sent: Thursday, June 16, 2011 12:34 PM
To: TreeBASE devel
Subject: Re: [Treebase-devel] ABI proposal for phyloinformatics


On Jun 16, 2011, at 4:03 AM, Roderic Page wrote:

> +1 for JSON
>
> JSON is clearly the way to go for moving data around on the web. XML  
> has some advantages for writing structured documents, so I see a  
> place for NeXML, but OMG can it be verbose. If you want broader  
> developer engagement, JSON is great (but please, please not some  
> hideous XML -> JSON conversion)


[This is sidetracking the main thread, but as someone who had a bit to  
do with XML in the past, I must try re-route part of XML frustrations  
towards the real problem. ]

XML and JSON are pretty much isomorphic in what they can represent.   
The *innate* difference in verbosity is very slight:

     where JSON says  "foo" : { .... }     XML says  <foo> ... </ 
foo>       (1)

Yes, XML uses a few more characters, but not that many more!  I'd  
claim that 80% of the perceived OMG-verboseness of XML comes from the  
way people design their XML formats, which, unfortunately, is strongly  
influenced by the multitude of cruft specs around XML (namespaces,  
Schema, ...).  In other words, the way you can screw up your format in  
XML, you can screw it up in JSON, too.  And conversely, if you can  
manage to create a clean format with JSON, you can mimic it in XML,  
with minimal overhead in verbosity, exactly as in (1). Some would even  
call it readability!

This remark is not to protest using JSON in place of XML. (After all,  
I admit, it should be more difficult to screw up with JSON.)  This is  
just  a word of caution not to overlook real design problems that  
might be behind the drive towards JSON as a new magic hammer. These  
problems would not solve themselves magically.  I do not know what  
they may be in the NeXML case, but a generic (aka hideous) XML -> JSON  
conversion might actually expose them to JSON aficionados!

--Vladimir 

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Treebase-devel mailing list
Tre...@li...
https://lists.sourceforge.net/lists/listinfo/treebase-devel

Re: [Treebase-devel] ABI proposal for phyloinformatics

[Vladimir G. <vla...@du...>]

On Jun 16, 2011, at 4:03 AM, Roderic Page wrote:

> +1 for JSON
>
> JSON is clearly the way to go for moving data around on the web. XML  
> has some advantages for writing structured documents, so I see a  
> place for NeXML, but OMG can it be verbose. If you want broader  
> developer engagement, JSON is great (but please, please not some  
> hideous XML -> JSON conversion)


[This is sidetracking the main thread, but as someone who had a bit to  
do with XML in the past, I must try re-route part of XML frustrations  
towards the real problem. ]

XML and JSON are pretty much isomorphic in what they can represent.   
The *innate* difference in verbosity is very slight:

     where JSON says  "foo" : { .... }     XML says  <foo> ... </ 
foo>       (1)

Yes, XML uses a few more characters, but not that many more!  I'd  
claim that 80% of the perceived OMG-verboseness of XML comes from the  
way people design their XML formats, which, unfortunately, is strongly  
influenced by the multitude of cruft specs around XML (namespaces,  
Schema, ...).  In other words, the way you can screw up your format in  
XML, you can screw it up in JSON, too.  And conversely, if you can  
manage to create a clean format with JSON, you can mimic it in XML,  
with minimal overhead in verbosity, exactly as in (1). Some would even  
call it readability!

This remark is not to protest using JSON in place of XML. (After all,  
I admit, it should be more difficult to screw up with JSON.)  This is  
just  a word of caution not to overlook real design problems that  
might be behind the drive towards JSON as a new magic hammer. These  
problems would not solve themselves magically.  I do not know what  
they may be in the NeXML case, but a generic (aka hideous) XML -> JSON  
conversion might actually expose them to JSON aficionados!

--Vladimir 

Re: [Treebase-devel] ABI proposal for phyloinformatics

[Westneat, M. <mwe...@fi...>]

Hi all, Picking this up again today, I agree with Bill that feasibility and
scope are key for this grant, so if it is focused on the TreeBASE
re-engineering and first steps of interop to ToLWeb, that seems like a
feasible project.  I didn't get that impression, however, from reading the
proposal draft (seemed like retooling of both projects), so it may need some
honing to make that clear.  So, for our ToLWeb group, in this grant we
should plan on open sourcing, and helping make the tie-ins with TreeBASE,
and perhaps use this exercise as a way to plan for future more complex
modifications to ToLWeb.
Trying to think this through, here are some questions, ideas, devil's
advocate positions, etc.
1. How many phylogenetic trees have been published?  The totality of all
phylogenetic knowledge is probably not very big.  Maybe 10,000 studies
proposing topologies?  For maybe a half million taxa?  Just a guess.  We
should map out the path to the capture of all phylogenetic knowledge, past
and future, and declare how far this grant will get us toward that goal.
2. What should the ultimate set of tools for phylogeny storage, retrieval,
viewing, and use look like?  Are we getting there by re-engineering
TreeBASE?  I think we are, but we better make that really clear in the
proposal that this time, a new TreeBASE is really going to be awesome and
give user joy to the community.  Reviewers will demand this, and I see the
various criticisms of TB2 as a potential risk of having this proposal be too
TreeBASE centric.
3. Will TreeBASE and ToLWeb remain independent projects during and after
this grant?  Or should they be somehow fundamentally joined to produce a
resource for storage, retrieval, and public display of evolutionary trees?
I can see advantages of either path, but we are going to have to make a
decision on this, defend it in the grant, and show reviewers that this is
headed where the community wants it to.
4. The idea of integrating social networking into TreeBASE (or ToLWeb) is
risky- I would advise against it.  There are plenty of ways to connect with
colleagues without trying to duplicate FaceBook tools.  IMO we would be
better off building a way to view and browse the trees.  Or, I like Hilmar's
suggestion of building a platform, flexible enough to incorporate social
tools and viz tools, etc.
5. The pushback on integrating tree viewers in this project is surprising to
me- I recommend against a rework of TreeBASE plumbing and infrastructure
without starting from what the users want, which is to be able to easily see
the trees.  Not sure if you have done any user needs survey or audience
assessment, but the lack of a friendly UI and tree viewer are the two most
common things I hear about TB2.
6. I like the idea of the links between TB and TW.  Thinking user
functionality, what will this provide? While browsing ToLWeb, an icon or
link will automatically take me to a TreeBASE tree that has any of the same
taxa.  Or while searching TreeBASE for primate trees, the ToLWeb site for
primates is offered as an option.  This will require taxonomic resolution of
clade names and tips between the two resources.  Is this name resolution
functionality part of the grant- has it been tried?  Shouldn't be too hard
to see what the matches and misses currently are, but an auto taxon mapping
tool may be more challenging.
Those are my thoughts for now- probably not helpful for actually writing the
grant, I'm afraid, but perhaps useful for deciding what kinds of things to
include.  Cheers, Mark


On Wed, Jun 15, 2011 at 6:25 PM, Hilmar Lapp <hl...@ne...> wrote:

> Great discussion. To throw in my two cents: I think it's important to keep
> this vision of creating a platform in mind. A platform doesn't solve all
> problems and doesn't serve all needs, but it provides unified and easily
> programmable access to useful content (it's the data, stupid!) such that
> people with the skills and drive can innovate. The content being useful in
> this case to me implies that it is much more comprehensive than it is now
> (most published phylogenetic trees are not deposited in TreeBASE, and the
> ToL is far more incomplete than current state of published phylogenetic
> knowledge), and that it is much better annotated and curated than it is now,
> which I find hard to accomplish without a much improved connection between
> ToLWeb and TreeBASE, and without well-thought through approach to overcoming
> the social barriers to user engagement.
>
> Having said that, small proof-of-concept viz (and other) apps can serve
> well to guide and validate the "platform" and API goals. But they shouldn't
> take a scope that would start to distract from the main focus. Perhaps a
> good instrument for supporting these proof-of-concept efforts are
> developer-engagement events (challenges, hack-days, competitions, ?).
>
> -hilmar
>
> Sent with a tap.




-- 
Mark W. Westneat
Curator of Zoology
Robert A. Pritzker Director, Biodiversity Synthesis Center of the
Encyclopedia of Life
Field Museum of Natural History
1400 S Lake Shore Dr.,  Chicago, IL  60605-2496
(312) 665-7734

My website: http://synthesis.eol.org/users/mwestneat<http://biosync.fieldmuseum.org/users/mwestneat>
BioSynC website: http://synthesis.eol.org

Re: [Treebase-devel] ABI proposal for phyloinformatics

[Roderic P. <r....@bi...>]

+1 for JSON

JSON is clearly the way to go for moving data around on the web. XML has some advantages for writing structured documents, so I see a place for NeXML, but OMG can it be verbose. If you want broader developer engagement, JSON is great (but please, please not some hideous XML -> JSON conversion)

-1 for Facebook/Myspace

IMHO both are pretty yucky interfaces. It's not about understanding Facebook/MySpace, it's about understanding what users need (not necessarily the same as what they say they want), and obeying the cardinal rule ("don't make me think").  I should be able to type in any old thing (taxon name, DOI, author) and have the software figure out what I mean and show me the trees. Simples.

0 for viz people

There is some cool stuff in visualisation, but it's very hard to get a visualisation that works (much easier to make it pretty). 90% of computer visualisation stuff is ultimately pretty but useless, IMHO. Ask yourself why Google search results are presented as a simple list (see http://www.youtube.com/watch?v=ijLDxgALc2c ). So, by all means engage with the visualisation crowd, but don't expect miracles. For my own (obviously biased) take on visualisation, see http://www.slideshare.net/rdmpage/phylogeny-vizbi-2011

Regards

Rod


---------------------------------------------------------
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

Re: [Treebase-devel] Restarting TreeBASE Production Server

[William P. <wil...@ya...>]

On Jun 15, 2011, at 3:40 PM, David Palmer wrote:

> Everything is up again now.  I won't get into the details, but Duke security scanning created some issues with our VM environment.  Since the server was restarted during the process, we will not be restarting it at 8:00 am tomorrow.  Thanks for your assistance.
> 
> David

It's nice and speedy now. thanks. 

bp

Re: [Treebase-devel] Restarting TreeBASE Production Server

[David P. <dav...@ne...>]

Everything is up again now.  I won't get into the details, but Duke security scanning created some issues with our VM environment.  Since the server was restarted during the process, we will not be restarting it at 8:00 am tomorrow.  Thanks for your assistance.

David

From: William Piel <wil...@ya...<mailto:wil...@ya...>>
Date: Wed, 15 Jun 2011 14:43:23 -0400
To: David Palmer <dav...@ne...<mailto:dav...@ne...>>
Cc: TreeBASE devel <tre...@li...<mailto:tre...@li...>>
Subject: Re: [Treebase-devel] Restarting TreeBASE Production Server


On Jun 15, 2011, at 2:20 PM, David Palmer wrote:

The services have been restarted.  Please let me know if you see an improvement.


For me, it doesn't seem to be responding:

http://www.treebase.org/treebase-web/

something failed in the restart.

bp

Re: [Treebase-devel] Restarting TreeBASE Production Server

[William P. <wil...@ya...>]

On Jun 15, 2011, at 2:20 PM, David Palmer wrote:

> The services have been restarted.  Please let me know if you see an improvement.
> 

For me, it doesn't seem to be responding:

http://www.treebase.org/treebase-web/

something failed in the restart.

bp

Re: [Treebase-devel] ABI proposal for phyloinformatics

[Andrew H. <and...@gm...>]

Hi all,

Need to throw in my two cents here. I imagine these comments might
represent a slightly different pov than has come up.

Near-future grant proposals probably should not spend heavily on the
development of tree visualization tools with goals of long-term
sustainability. Instead, the next wave of proposals (I'm only talking
about viz here) should focus on a few pre-tool advancements. My idea
of what these advancements should be is based on

1) the future/now of viz is on the open-web (html5 etc).
2) the best data viz people are probably not in our community, they
are in their own or are unsuspecting tinkerers who will stumble upon
it.
3) the coolest innovations in tree viz aren't going to be wrapped into viz tools

So, with that, here is what I propose needs to happen,

1) PhyloJSON notations. XML on the web is slow and unnecessary. JSON
is quickly moving in on XML dominance. PhyloBox and other projects all
moved down their own paths for creating json phylogeny notation. This
is the normal way to do it, but our community could be developing some
common notations that we could all start using/expecting.

2) Advanced REST tree queries (TreeBASE) for strictly web-client based
consumption. What I mean here, is the use of cross-domain rest queries
to find, trim, scope, and combine trees. On top of that, wrapping the
results into the product of (1) above. This will allow web mashups and
tools to emerge that combine the data in unexpected ways.

3) Proof of concept tools and documentation. All I mean here, are
examples of how the products of (1) and (2) can be used to merge
phylogeny with external sources of data (wikipedia, eol, flickr, etc),
using the modern web, html5, css3, and javascript. This will provide
the foundations for a much larger pool of producer/consumers to do
interesting things with the data. Documentation is king. It will
enable those not at the table to understand the decisions made.

Each of those have clear integration points with treebase (especially
the meeting of 1 and 2) and other projects. More importantly, none of
them have been correctly explored with sufficient resources and
planning. On top of that, developing the three in coordination will
allow much better development of use-cases for phylogeny viz that feed
back into each of the three.

best,

a



On Wed, Jun 15, 2011 at 11:14 AM, Robert Guralnick
<Rob...@co...> wrote:
>  I see TreeViz and UI are partly overlapping.  There are a lot more
> interesting ways to explore and annotate trees that push back to
> overall UI design.  Also, it might be wise for us to both look
> internally to experts within the community, and also externally to
> those who do design in different biological (or other) arenas.  We
> want to develop for a broad set of users, and not necessarily simply
> for card carrying systematists.  I am very sympatico to the idea that
> we really do need to bring in HCI expertise, but am even more keen to
> find great and visually talented artists and designers can carry us a
> ways forward too, without getting too "academic".   In developing some
> UI and TreeViz software, our lab has found great value in having a
> talented visual designer (Sander Pick;
> http://plebeian.tv/#information) to help us think through some of the
> UI/Viz challenges.  Sander's skills transfer well across domains (he
> is now doing design work for clean energy).
>
> Best, Rob
>
>
> On Wed, Jun 15, 2011 at 10:49 AM, Rutger Vos <R....@re...> wrote:
>>> In talking with Rob G, we
>>> are both really interested in UI, and we both have programmers in our groups
>>> who are working on various UI features for Tree Viz, so that would be an
>>> area where I think we would be interested to help the project as the interop
>>> details are hammered out.
>>
>> Tree visualization and interaction design of web applications are two
>> different things. There is a lot of community expertise of the former
>> (and there are other people we might involve in this, e.g. Tamara
>> Munzner), but not enough of the latter. People complain about TreeBASE
>> in part because the workflows and visual metaphors aren't informed by
>> good HCI design, and this is not going to be addressed by better tree
>> viz. People will complain less about TreeBASE if we know why facebook
>> is nicer than myspace and apply those principles.
>>
>> --
>> 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
>>
>



-- 
Ecology and Evolutionary Biology
University of Colorado

http://biodiversity.colorado.edu
http://biodivertido.blogspot.com

Re: [Treebase-devel] Restarting TreeBASE Production Server

[David P. <dav...@ne...>]

The services have been restarted.  Please let me know if you see an improvement.

David

From: William Piel <wil...@ya...<mailto:wil...@ya...>>
Date: Wed, 15 Jun 2011 14:03:54 -0400
To: David Palmer <dav...@ne...<mailto:dav...@ne...>>
Cc: TreeBASE devel <tre...@li...<mailto:tre...@li...>>
Subject: Re: [Treebase-devel] Restarting TreeBASE Production Server


On Jun 15, 2011, at 1:44 PM, David Palmer wrote:

Thank you for the feedback William.  I have examined the logs on the server and do not see a cron job that restarts the server, but there is one that restarts Postgres and Tomcat at 6:00 am EST.  If the system is still sluggish I can restart these services without impacting the site for mor that 1-2 mintues.

David

Yeah, it's still unbearably slow... so if you could do a PostgreSQL - Tomcat reboot, that would be great.

bp

Re: [Treebase-devel] Restarting TreeBASE Production Server

[William P. <wil...@ya...>]

On Jun 15, 2011, at 1:44 PM, David Palmer wrote:

> Thank you for the feedback William.  I have examined the logs on the server and do not see a cron job that restarts the server, but there is one that restarts Postgres and Tomcat at 6:00 am EST.  If the system is still sluggish I can restart these services without impacting the site for mor that 1-2 mintues.  
> 
> David

Yeah, it's still unbearably slow... so if you could do a PostgreSQL - Tomcat reboot, that would be great. 

bp

Re: [Treebase-devel] Restarting TreeBASE Production Server

[David P. <dav...@ne...>]

Thank you for the feedback William.  I have examined the logs on the server and do not see a cron job that restarts the server, but there is one that restarts Postgres and Tomcat at 6:00 am EST.  If the system is still sluggish I can restart these services without impacting the site for mor that 1-2 mintues.

David

From: William Piel <wil...@ya...<mailto:wil...@ya...>>
Date: Wed, 15 Jun 2011 13:17:19 -0400
To: David Palmer <dav...@ne...<mailto:dav...@ne...>>
Cc: TreeBASE devel <tre...@li...<mailto:tre...@li...>>
Subject: Re: [Treebase-devel] Restarting TreeBASE Production Server


On Jun 15, 2011, at 12:44 PM, David Palmer wrote:

NESCent would like to schedule a maintenance restart of the TreeBASE production server on 6/16/11 at 8:00 am EST.  Let me know if you have questions or concerns.

Thanks, David
David Palmer
Computer Support Specialist
NESCent

Hi David,

I think Jon had a cron set up to restart TreeBASE every night (Google analytics puts our low-point for traffic around 1 AM) -- so an 8AM restart tomorrow won't be necessary.  I was thinking that TreeBASE would be restarted around now, seeing as performance feels clogged up.

bp

Re: [Treebase-devel] Restarting TreeBASE Production Server

[William P. <wil...@ya...>]

On Jun 15, 2011, at 12:44 PM, David Palmer wrote:

> NESCent would like to schedule a maintenance restart of the TreeBASE production server on 6/16/11 at 8:00 am EST.  Let me know if you have questions or concerns.
> 
> Thanks, David
> David Palmer
> Computer Support Specialist
> NESCent

Hi David,

I think Jon had a cron set up to restart TreeBASE every night (Google analytics puts our low-point for traffic around 1 AM) -- so an 8AM restart tomorrow won't be necessary.  I was thinking that TreeBASE would be restarted around now, seeing as performance feels clogged up. 

bp

Re: [Treebase-devel] ABI proposal for phyloinformatics

[Robert G. <Rob...@co...>]

 I see TreeViz and UI are partly overlapping.  There are a lot more
interesting ways to explore and annotate trees that push back to
overall UI design.  Also, it might be wise for us to both look
internally to experts within the community, and also externally to
those who do design in different biological (or other) arenas.  We
want to develop for a broad set of users, and not necessarily simply
for card carrying systematists.  I am very sympatico to the idea that
we really do need to bring in HCI expertise, but am even more keen to
find great and visually talented artists and designers can carry us a
ways forward too, without getting too "academic".   In developing some
UI and TreeViz software, our lab has found great value in having a
talented visual designer (Sander Pick;
http://plebeian.tv/#information) to help us think through some of the
UI/Viz challenges.  Sander's skills transfer well across domains (he
is now doing design work for clean energy).

Best, Rob


On Wed, Jun 15, 2011 at 10:49 AM, Rutger Vos <R....@re...> wrote:
>> In talking with Rob G, we
>> are both really interested in UI, and we both have programmers in our groups
>> who are working on various UI features for Tree Viz, so that would be an
>> area where I think we would be interested to help the project as the interop
>> details are hammered out.
>
> Tree visualization and interaction design of web applications are two
> different things. There is a lot of community expertise of the former
> (and there are other people we might involve in this, e.g. Tamara
> Munzner), but not enough of the latter. People complain about TreeBASE
> in part because the workflows and visual metaphors aren't informed by
> good HCI design, and this is not going to be addressed by better tree
> viz. People will complain less about TreeBASE if we know why facebook
> is nicer than myspace and apply those principles.
>
> --
> 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
>

Re: [Treebase-devel] ABI proposal for phyloinformatics

[Rutger V. <R....@re...>]

> In talking with Rob G, we
> are both really interested in UI, and we both have programmers in our groups
> who are working on various UI features for Tree Viz, so that would be an
> area where I think we would be interested to help the project as the interop
> details are hammered out.

Tree visualization and interaction design of web applications are two
different things. There is a lot of community expertise of the former
(and there are other people we might involve in this, e.g. Tamara
Munzner), but not enough of the latter. People complain about TreeBASE
in part because the workflows and visual metaphors aren't informed by
good HCI design, and this is not going to be addressed by better tree
viz. People will complain less about TreeBASE if we know why facebook
is nicer than myspace and apply those principles.

-- 
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

[Treebase-devel] Restarting TreeBASE Production Server

[David P. <dav...@ne...>]

NESCent would like to schedule a maintenance restart of the TreeBASE production server on 6/16/11 at 8:00 am EST.  Let me know if you have questions or concerns.

Thanks, David
David Palmer
Computer Support Specialist
NESCent

Re: [Treebase-devel] ABI proposal for phyloinformatics

[Westneat, M. <mwe...@fi...>]

Hi everyone, sorry for joining this thread a bit late but I am catching up
and have been discussing some things about ToLWeb and user interface ideas
with the phylorf committee.  Regarding ToLWeb, we agreed that we need a
point person and so I have volunteered to be that person, with David and
Karen joining to form a three-person group to help steer ToLWeb issues in
this ABI grant.  We are totally open to all ideas about where ToLWeb should
head- we mainly thought having a group with a point person would help get
decisions made.  In order to be effective, I am trying to aggregate
information on ToLWeb features and site maps, existing strengths and
weaknesses, steps needed to go open source, features we need/want, user
interface ideas, past discussions like ToLWebII, etc.  Regarding user
interface issues, I think we can probably all agree that UI design and
implementation is a key issue for both TB and TW.  In talking with Rob G, we
are both really interested in UI, and we both have programmers in our groups
who are working on various UI features for Tree Viz, so that would be an
area where I think we would be interested to help the project as the interop
details are hammered out.  More soon-  Thanks, Mark

On Tue, Jun 14, 2011 at 2:42 PM, David Maddison <
dav...@sc...> wrote:

> Sorry, folks for being silent.  Travelling, daughter's graduation, mom's
> visit, yada yada yada...
>
> Here are some comments, and I must say I haven't read the proposal yet,
> just the pitches, and the emails.
>
>  I like the general plan.
>
> I agree that Jim that fundamentally ToLWeb should be viewed as a test case
> for interoperability, even if there is specific effort in the project on it.
>  I would go so far to say that even TreeBASE should be viewed here as a test
> case.  The most important thing that would be built in the process of doing
> this the vision, understanding of needs, standards, design of the tools, and
> community building and inspiration, rather than the particular
> implementations that will come out in TreeBASE and ToLWeb.    The products
> should be done with enough abstraction that they will serve for other cases.
>  I always find that it is good to have two test cases, just to force one to
> think about alternatives at various decision points.  There is a cost to
> that, of course, and that is the added funds that would be needed to support
> other test cases.  But if we could have a light-weight alternative to
> TreeBASE as an alternative test case at that end, and a light-weight
> alternative to ToLWeb to serve as a test case there, then it might be worth
> thinking about including a bit of effort there that to force greater
> abstraction.
>
> ToLWeb is "emotionally" open source.  That is, it's fully available as far
> as I am concerned, but we haven't gone through the effort of actually making
> it open source.  Anyone who wants the source can have it.  So, I am
> enthusiastically in support of having a small portion of the budget devoted
> to the effort to push it onto Source Forge or somewhere.  Ideally that would
> involve a bit of contract money to Andy Lenards, and possibly Danny Mandel
> (programmer that proceeded Andy; Danny understands more of the source, I
> suspect).
>
> OK, more comments after I look at the proposal.
> David
>
>
> On 7 Jun  2011, at 10:53 AM, Karen Cranston wrote:
>
> >> Karen,
> >>
> >> Will you be sending the pitch to Reed and asking for feedback?  I
> suspect he will want to talk about some of the technical points being
> discussed in the googledoc in order to be certain that this is an ABI
> development proposal.   My sense from our last discussion is that
> development project proposals should include pretty watertight plans for
> software/database engineering and testing.
> >
> > I am putting together two pitches of ~1 page each to send to NSF. One
> > is the grand ToLWeb + TreeBASE version, and the second is the TreeBASE
> > and MIAPA-focused ideas that you, Bill and Rutger submitted (I am
> > merging these into a single doc). This way, we can get a sense of
> > which version is more likely to be viewed favourably by the panel and
> > program officers. Working madly, hoping to send this ASAP.
> >
> > Karen
> >
> >>
> >> Bests,
> >> Jim
> >>
> >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >> Jim Leebens-Mack
> >> Department of Plant Biology
> >> University of Georgia
> >> Athens, GA 30602-7271
> >>
> >> Phone: 706-583-5573
> >> Fax: 706-542-1805
> >> email: jle...@pl...
> >> url: http://www.plantbio.uga.edu/~jleebensmack/JLMmain.html
> >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >>
> >>
> >> ----- Original Message -----
> >> From: Karen Cranston
> >> [mailto:kar...@ne...]
> >> To: Arlin Stoltzfus
> >> [mailto:ar...@um...]
> >> Cc: MIAPA [mailto:mia...@go...],
> >> ph...@go..., TreeBASE devel
> >> [mailto:Tre...@li...]
> >> Sent: Mon, 06 Jun 2011
> >> 10:04:48 -0400
> >> Subject: Re: ABI proposal for phyloinformatics
> >>
> >>
> >>> There are several pitches now in the Google doc, with a fair bit of
> >>> overlap between them. I am willing to consolidate into a single page
> >>> and send to NSF (Reed?) and see what he has to say about the various
> >>> components. It seems like these components are:
> >>> 1. some level of re-engineering of TreeBASE
> >>> 2. further development of MIAPA, with annotation tools and TreeBASE
> >>> integration
> >>> 3. use of ToLWeb as a crowd sourcing and data synthesis platform
> >>> 4. NeXML refinement and development
> >>>
> >>> I don't think this one-pager needs to capture all of the ideas and
> >>> details we currently have, but instead give a general sense of what we
> >>> are proposing and if all / some of these ideas is potentially
> >>> fundable.
> >>>
> >>> Everyone in agreement? I will post the single page in the doc later
> today.
> >>>
> >>> Karen
> >>>
> >>> On Fri, Jun 3, 2011 at 3:38 PM, Arlin Stoltzfus <ar...@um...> wrote:
> >>>> Today is the deadline for our 1-page synopsis to pitch to an NSF
> program
> >>>> officer (before going further).   Currently we seem to have 3 pitches.
> >>>  It
> >>>> is time now for some energetic person to consolidate this, so that we
> can
> >>>> move ahead.
> >>>>
> >>>> Arlin
> >>>>
> >>>> On May 31, 2011, at 12:19 PM, Karen Cranston wrote:
> >>>>
> >>>>> Tomorrow morning (Wed, June 1) looks to be good for everyone, and
> >>>>> sooner seems better than later. I propose we talk at 9:00 am EST. I
> >>>>> will send connection information later today.
> >>>>>
> >>>>> Cheers,
> >>>>> Karen
> >>>>>
> >>>>> On Thu, May 26, 2011 at 3:00 PM, Karen Cranston
> >>>>> <kar...@ne...> wrote:
> >>>>>>
> >>>>>> There has been some interest among various groups in an ABI proposal
> >>>>>> for development of phyloinformatics resources. This email is an
> >>>>>> attempt to connect those threads and move the process forward. The
> >>>>>> conversations that have been happening up to this point are:
> >>>>>>
> >>>>>> 1. The Phyloinformatics Research Foundation (phylofoundation.org,
> >>>>>> stewards of TreeBASE and ToLWeb) started a Google doc aimed at
> >>>>>> TreeBASE
> >>>>>> 2. MIAPA developers started a wiki page
> >>>>>> (https://www.nescent.org/sites/evoio/NSF_ABI_2011), recognizing the
> >>>>>> need for coordination with TreeBASE and other resources
> >>>>>> 3. NESCent (Todd, Hilmar and myself), as the current TreeBASE host
> and
> >>>>>> as a third party interested in coordinated development across
> >>>>>> resources started a third document (now added to the already
> mentioned
> >>>>>> Google doc)
> >>>>>>
> >>>>>> If you are interested in this discussion and do not already have
> >>>>>> access to the Google doc entitled TreeBASE_ABI.doc, let me know and
> I
> >>>>>> can grant you access. Hilmar and I made some substantial edits
> earlier
> >>>>>> this morning. I point you specifically to the section at the end
> >>>>>> entitled "An attempt to re-think all of this". Briefly, we wanted to
> >>>>>> encourage some radical thinking and explore the idea of developing a
> >>>>>> PhyloCommons that incorporates both TreeBASE and ToLWeb into the
> >>>>>> proposal (as the data repository and the data sharing /
> dissemination
> >>>>>> / synthesis platform, respectively).
> >>>>>>
> >>>>>> The ABI deadline is July 7, so we have a short period of time to
> pull
> >>>>>> this together. Here is a link to a Doodle poll for an initial
> >>>>>> teleconference.
> >>>>>>
> >>>>>> http://doodle.com/zf2tz7sftyk3naxy
> >>>>>>
> >>>>>> During this meeting, we hope to come to agreement on the broad
> >>>>>> direction of the grant, identify possible leaders of the various
> >>>>>> components and create a plan for getting this pulled together in
> time
> >>>>>> for the deadline. Please feel free to continue the conversation on
> the
> >>>>>> Google doc between now and the teleconference. If there are others
> who
> >>>>>> you think should be invited, feel free to do so. Not everyone who
> >>>>>> participates in this first phase will end up being named on the
> grant,
> >>>>>> but these resources require input from a much larger group.
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Karen
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>>>>> Karen Cranston
> >>>>>> Training Coordinator and Informatics Project Manager
> >>>>>> nescent.org
> >>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>>>> Karen Cranston
> >>>>> Training Coordinator and Informatics Project Manager
> >>>>> 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
> >>>>
> >>>> --
> >>>> 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
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>> Karen Cranston
> >>> Training Coordinator and Informatics Project Manager
> >>> 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
> >>>
> >>
> >
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Karen Cranston, PhD
> > Training Coordinator and Informatics Project Manager
> > nescent.org
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> ---------------------------------
> David R. Maddison
> Department of Zoology
> 3029 Cordley Hall
> Oregon State University
> Corvallis, OR  97331   USA
>
> dav...@sc...
>
> http://david.bembidion.org
> http://mesquiteproject.org
> http://macclade.org
> http://tolweb.org
>
> (541) 737 2834
>
>
>
>
>


-- 
Mark W. Westneat
Curator of Zoology
Robert A. Pritzker Director, Biodiversity Synthesis Center of the
Encyclopedia of Life
Field Museum of Natural History
1400 S Lake Shore Dr.,  Chicago, IL  60605-2496
(312) 665-7734

My website: http://synthesis.eol.org/users/mwestneat<http://biosync.fieldmuseum.org/users/mwestneat>
BioSynC website: http://synthesis.eol.org

Re: [Treebase-devel] ABI proposal for phyloinformatics

[David M. <dav...@sc...>]

Sorry, folks for being silent.  Travelling, daughter's graduation, mom's visit, yada yada yada...

Here are some comments, and I must say I haven't read the proposal yet, just the pitches, and the emails.

 I like the general plan.    

I agree that Jim that fundamentally ToLWeb should be viewed as a test case for interoperability, even if there is specific effort in the project on it.  I would go so far to say that even TreeBASE should be viewed here as a test case.  The most important thing that would be built in the process of doing this the vision, understanding of needs, standards, design of the tools, and community building and inspiration, rather than the particular implementations that will come out in TreeBASE and ToLWeb.    The products should be done with enough abstraction that they will serve for other cases.  I always find that it is good to have two test cases, just to force one to think about alternatives at various decision points.  There is a cost to that, of course, and that is the added funds that would be needed to support other test cases.  But if we could have a light-weight alternative to TreeBASE as an alternative test case at that end, and a light-weight alternative to ToLWeb to serve as a test case there, then it might be worth thinking about including a bit of effort there that to force greater abstraction.  

ToLWeb is "emotionally" open source.  That is, it's fully available as far as I am concerned, but we haven't gone through the effort of actually making it open source.  Anyone who wants the source can have it.  So, I am enthusiastically in support of having a small portion of the budget devoted to the effort to push it onto Source Forge or somewhere.  Ideally that would involve a bit of contract money to Andy Lenards, and possibly Danny Mandel (programmer that proceeded Andy; Danny understands more of the source, I suspect).  

OK, more comments after I look at the proposal.
David


On 7 Jun  2011, at 10:53 AM, Karen Cranston wrote:

>> Karen,
>> 
>> Will you be sending the pitch to Reed and asking for feedback?  I suspect he will want to talk about some of the technical points being discussed in the googledoc in order to be certain that this is an ABI development proposal.   My sense from our last discussion is that development project proposals should include pretty watertight plans for software/database engineering and testing.
> 
> I am putting together two pitches of ~1 page each to send to NSF. One
> is the grand ToLWeb + TreeBASE version, and the second is the TreeBASE
> and MIAPA-focused ideas that you, Bill and Rutger submitted (I am
> merging these into a single doc). This way, we can get a sense of
> which version is more likely to be viewed favourably by the panel and
> program officers. Working madly, hoping to send this ASAP.
> 
> Karen
> 
>> 
>> Bests,
>> Jim
>> 
>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> Jim Leebens-Mack
>> Department of Plant Biology
>> University of Georgia
>> Athens, GA 30602-7271
>> 
>> Phone: 706-583-5573
>> Fax: 706-542-1805
>> email: jle...@pl...
>> url: http://www.plantbio.uga.edu/~jleebensmack/JLMmain.html
>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> 
>> 
>> ----- Original Message -----
>> From: Karen Cranston
>> [mailto:kar...@ne...]
>> To: Arlin Stoltzfus
>> [mailto:ar...@um...]
>> Cc: MIAPA [mailto:mia...@go...],
>> ph...@go..., TreeBASE devel
>> [mailto:Tre...@li...]
>> Sent: Mon, 06 Jun 2011
>> 10:04:48 -0400
>> Subject: Re: ABI proposal for phyloinformatics
>> 
>> 
>>> There are several pitches now in the Google doc, with a fair bit of
>>> overlap between them. I am willing to consolidate into a single page
>>> and send to NSF (Reed?) and see what he has to say about the various
>>> components. It seems like these components are:
>>> 1. some level of re-engineering of TreeBASE
>>> 2. further development of MIAPA, with annotation tools and TreeBASE
>>> integration
>>> 3. use of ToLWeb as a crowd sourcing and data synthesis platform
>>> 4. NeXML refinement and development
>>> 
>>> I don't think this one-pager needs to capture all of the ideas and
>>> details we currently have, but instead give a general sense of what we
>>> are proposing and if all / some of these ideas is potentially
>>> fundable.
>>> 
>>> Everyone in agreement? I will post the single page in the doc later today.
>>> 
>>> Karen
>>> 
>>> On Fri, Jun 3, 2011 at 3:38 PM, Arlin Stoltzfus <ar...@um...> wrote:
>>>> Today is the deadline for our 1-page synopsis to pitch to an NSF program
>>>> officer (before going further).   Currently we seem to have 3 pitches.
>>>  It
>>>> is time now for some energetic person to consolidate this, so that we can
>>>> move ahead.
>>>> 
>>>> Arlin
>>>> 
>>>> On May 31, 2011, at 12:19 PM, Karen Cranston wrote:
>>>> 
>>>>> Tomorrow morning (Wed, June 1) looks to be good for everyone, and
>>>>> sooner seems better than later. I propose we talk at 9:00 am EST. I
>>>>> will send connection information later today.
>>>>> 
>>>>> Cheers,
>>>>> Karen
>>>>> 
>>>>> On Thu, May 26, 2011 at 3:00 PM, Karen Cranston
>>>>> <kar...@ne...> wrote:
>>>>>> 
>>>>>> There has been some interest among various groups in an ABI proposal
>>>>>> for development of phyloinformatics resources. This email is an
>>>>>> attempt to connect those threads and move the process forward. The
>>>>>> conversations that have been happening up to this point are:
>>>>>> 
>>>>>> 1. The Phyloinformatics Research Foundation (phylofoundation.org,
>>>>>> stewards of TreeBASE and ToLWeb) started a Google doc aimed at
>>>>>> TreeBASE
>>>>>> 2. MIAPA developers started a wiki page
>>>>>> (https://www.nescent.org/sites/evoio/NSF_ABI_2011), recognizing the
>>>>>> need for coordination with TreeBASE and other resources
>>>>>> 3. NESCent (Todd, Hilmar and myself), as the current TreeBASE host and
>>>>>> as a third party interested in coordinated development across
>>>>>> resources started a third document (now added to the already mentioned
>>>>>> Google doc)
>>>>>> 
>>>>>> If you are interested in this discussion and do not already have
>>>>>> access to the Google doc entitled TreeBASE_ABI.doc, let me know and I
>>>>>> can grant you access. Hilmar and I made some substantial edits earlier
>>>>>> this morning. I point you specifically to the section at the end
>>>>>> entitled "An attempt to re-think all of this". Briefly, we wanted to
>>>>>> encourage some radical thinking and explore the idea of developing a
>>>>>> PhyloCommons that incorporates both TreeBASE and ToLWeb into the
>>>>>> proposal (as the data repository and the data sharing / dissemination
>>>>>> / synthesis platform, respectively).
>>>>>> 
>>>>>> The ABI deadline is July 7, so we have a short period of time to pull
>>>>>> this together. Here is a link to a Doodle poll for an initial
>>>>>> teleconference.
>>>>>> 
>>>>>> http://doodle.com/zf2tz7sftyk3naxy
>>>>>> 
>>>>>> During this meeting, we hope to come to agreement on the broad
>>>>>> direction of the grant, identify possible leaders of the various
>>>>>> components and create a plan for getting this pulled together in time
>>>>>> for the deadline. Please feel free to continue the conversation on the
>>>>>> Google doc between now and the teleconference. If there are others who
>>>>>> you think should be invited, feel free to do so. Not everyone who
>>>>>> participates in this first phase will end up being named on the grant,
>>>>>> but these resources require input from a much larger group.
>>>>>> 
>>>>>> Cheers,
>>>>>> Karen
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>> Karen Cranston
>>>>>> Training Coordinator and Informatics Project Manager
>>>>>> nescent.org
>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>> Karen Cranston
>>>>> Training Coordinator and Informatics Project Manager
>>>>> 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
>>>> 
>>>> --
>>>> 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
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> Karen Cranston
>>> Training Coordinator and Informatics Project Manager
>>> 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
>>> 
>> 
> 
> 
> 
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Karen Cranston, PhD
> Training Coordinator and Informatics Project Manager
> nescent.org
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------------
David R. Maddison
Department of Zoology
3029 Cordley Hall
Oregon State University
Corvallis, OR  97331   USA

dav...@sc...

http://david.bembidion.org
http://mesquiteproject.org
http://macclade.org
http://tolweb.org

(541) 737 2834

Re: [Treebase-devel] analysis metadata in TreeBASE, some experiments

[Enrico P. <epo...@cs...>]

I don¹t believe the two things are exclusive - a single step is just a
"big step" that can be refined into a sequence of smaller steps if one
wants to. 
I believe Maryam is currently looking at the "leaves" of this hierarchical
tree that decomposes the analysis (by looking at the individual tools that
can be used in the analysis).

Enrico

-- 
Dept. Computer Science,
New Mexico State University
MSC CS, Box 30001, Las Cruces, NM 88003
Voice: 575-646-6239   Fax: 575-646-1002





On 6/14/11 9:03 AM, "William Piel" <wil...@ya...> wrote:

>
>Interesting solution. MIAPA will definitely need to tackle analysis info,
>even if it's at a rudimentary level (like what produced what from what).
>TreeBASE used to only have analysis records -- the analysis step records
>was introduced with the idea that submitters might want the ability to
>describe more complex analysis in a multi-step fashion (e.g. took matrix
>x and produced set of trees y, took set of trees y and produced consensus
>tree z, etc). But alas, very few submitters have taken advantage of this
>-- most just have one step per analysis. Yet having multiple steps adds a
>slightly greater mouse-clicking burden.  Maybe we should consider
>abandoning the multi-step design, and collapsing it down to single-step
>analysis entries? How might MIAPA come to an opinion on matters like this?
>
>bp
>
>On Jun 13, 2011, at 8:37 AM, Rutger Vos wrote:
>
>> Hi all,
>> 
>> over the weekend I did some experimentation with how additional
>> metadata having to do with phylogenetic analyses stored by TreeBASE
>> could be serialized. Attached is the result as produced by a test case
>> that I committed to the TreeBASE source.
>> 
>> For context, here is how TreeBASE sees the world: every submission to
>> TreeBASE consists of the results of one or more analyses. Each
>> analysis consists of one or more analysis steps. For each step, we
>> store the "algorithm" (e.g. neighbor joining) and the "software" (e.g.
>> PAUP). Optional additional metadata can consist of a textual
>> description of the algorithm, a version number and URL of the software
>> and a text string containing analysis step commands (perhaps something
>> like a PAUP block).
>> 
>> Every analysis step has input and output data. These data can be trees
>> and matrices. The set of taxa in the input must be a superset of the
>> taxa in the output (i.e. some sort of taxon pruning is allowed, but
>> new taxa cannot be introduced during an analysis step). All data
>> that's accessible to third parties (i.e. all public, non-embargoed
>> data) must be the input or output of at least one analysis step, i.e.
>> we don't allow orphaned data in completed submissions.
>> 
>> In the attached example, I'm annotating the study (i.e. the root of
>> the nexml document) to specify the permanent URLs of any associated
>> analyses, and I annotate those analysis URLs with their respective
>> analysis steps, specifying their PURLs and any additional metadata as
>> described above. This is shown in lines 3-13.
>> 
>> Then, for every data object I specify for which analysis step(s) it is
>> the input and/or output (a data object can be both input and output if
>> analysis steps are chained together). This is shown in line 448 for a
>> character state matrix and line 1849 for a tree.
>> 
>> This is all highly experimental but I figured I'd share at as a
>> discussion piece for refining actual implementation of MIAPA
>> annotations.
>> 
>> Rutger
>
>
>-- 
>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

Re: [Treebase-devel] analysis metadata in TreeBASE, some experiments

[Rutger V. <R....@re...>]

There isn't really a community process that decides what is or is not
MIAPA, so at this stage these sorts of experiments are to inform
people who are working on fleshing out the details of terms and
concepts expressed in MIAPA. The person who's most involved in
implementation details is Maryam - who I assumed was in the relevant
mailing list but who's cc'ed here as well.

On Tue, Jun 14, 2011 at 4:03 PM, William Piel <wil...@ya...> wrote:
>
> Interesting solution. MIAPA will definitely need to tackle analysis info, even if it's at a rudimentary level (like what produced what from what).  TreeBASE used to only have analysis records -- the analysis step records was introduced with the idea that submitters might want the ability to describe more complex analysis in a multi-step fashion (e.g. took matrix x and produced set of trees y, took set of trees y and produced consensus tree z, etc). But alas, very few submitters have taken advantage of this -- most just have one step per analysis. Yet having multiple steps adds a slightly greater mouse-clicking burden.  Maybe we should consider abandoning the multi-step design, and collapsing it down to single-step analysis entries? How might MIAPA come to an opinion on matters like this?
>
> bp
>
> On Jun 13, 2011, at 8:37 AM, Rutger Vos wrote:
>
>> Hi all,
>>
>> over the weekend I did some experimentation with how additional
>> metadata having to do with phylogenetic analyses stored by TreeBASE
>> could be serialized. Attached is the result as produced by a test case
>> that I committed to the TreeBASE source.
>>
>> For context, here is how TreeBASE sees the world: every submission to
>> TreeBASE consists of the results of one or more analyses. Each
>> analysis consists of one or more analysis steps. For each step, we
>> store the "algorithm" (e.g. neighbor joining) and the "software" (e.g.
>> PAUP). Optional additional metadata can consist of a textual
>> description of the algorithm, a version number and URL of the software
>> and a text string containing analysis step commands (perhaps something
>> like a PAUP block).
>>
>> Every analysis step has input and output data. These data can be trees
>> and matrices. The set of taxa in the input must be a superset of the
>> taxa in the output (i.e. some sort of taxon pruning is allowed, but
>> new taxa cannot be introduced during an analysis step). All data
>> that's accessible to third parties (i.e. all public, non-embargoed
>> data) must be the input or output of at least one analysis step, i.e.
>> we don't allow orphaned data in completed submissions.
>>
>> In the attached example, I'm annotating the study (i.e. the root of
>> the nexml document) to specify the permanent URLs of any associated
>> analyses, and I annotate those analysis URLs with their respective
>> analysis steps, specifying their PURLs and any additional metadata as
>> described above. This is shown in lines 3-13.
>>
>> Then, for every data object I specify for which analysis step(s) it is
>> the input and/or output (a data object can be both input and output if
>> analysis steps are chained together). This is shown in line 448 for a
>> character state matrix and line 1849 for a tree.
>>
>> This is all highly experimental but I figured I'd share at as a
>> discussion piece for refining actual implementation of MIAPA
>> annotations.
>>
>> Rutger
>
>
> --
> 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
>



-- 
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

Re: [Treebase-devel] analysis metadata in TreeBASE, some experiments

[William P. <wil...@ya...>]

Interesting solution. MIAPA will definitely need to tackle analysis info, even if it's at a rudimentary level (like what produced what from what).  TreeBASE used to only have analysis records -- the analysis step records was introduced with the idea that submitters might want the ability to describe more complex analysis in a multi-step fashion (e.g. took matrix x and produced set of trees y, took set of trees y and produced consensus tree z, etc). But alas, very few submitters have taken advantage of this -- most just have one step per analysis. Yet having multiple steps adds a slightly greater mouse-clicking burden.  Maybe we should consider abandoning the multi-step design, and collapsing it down to single-step analysis entries? How might MIAPA come to an opinion on matters like this?

bp

On Jun 13, 2011, at 8:37 AM, Rutger Vos wrote:

> Hi all,
> 
> over the weekend I did some experimentation with how additional
> metadata having to do with phylogenetic analyses stored by TreeBASE
> could be serialized. Attached is the result as produced by a test case
> that I committed to the TreeBASE source.
> 
> For context, here is how TreeBASE sees the world: every submission to
> TreeBASE consists of the results of one or more analyses. Each
> analysis consists of one or more analysis steps. For each step, we
> store the "algorithm" (e.g. neighbor joining) and the "software" (e.g.
> PAUP). Optional additional metadata can consist of a textual
> description of the algorithm, a version number and URL of the software
> and a text string containing analysis step commands (perhaps something
> like a PAUP block).
> 
> Every analysis step has input and output data. These data can be trees
> and matrices. The set of taxa in the input must be a superset of the
> taxa in the output (i.e. some sort of taxon pruning is allowed, but
> new taxa cannot be introduced during an analysis step). All data
> that's accessible to third parties (i.e. all public, non-embargoed
> data) must be the input or output of at least one analysis step, i.e.
> we don't allow orphaned data in completed submissions.
> 
> In the attached example, I'm annotating the study (i.e. the root of
> the nexml document) to specify the permanent URLs of any associated
> analyses, and I annotate those analysis URLs with their respective
> analysis steps, specifying their PURLs and any additional metadata as
> described above. This is shown in lines 3-13.
> 
> Then, for every data object I specify for which analysis step(s) it is
> the input and/or output (a data object can be both input and output if
> analysis steps are chained together). This is shown in line 448 for a
> character state matrix and line 1849 for a tree.
> 
> This is all highly experimental but I figured I'd share at as a
> discussion piece for refining actual implementation of MIAPA
> annotations.
> 
> Rutger

Re: [Treebase-devel] ABI proposal for phyloinformatics

[Rutger V. <R....@re...>]

I just shared some sketches (thinking out loud about TreeBASE3) with
various people on these lists (Arlin, Hilmar, Karen, Bill, Harry).
MIAPA might play a role in the automated submission process, so if
anyone else is interested in seeing these documents please let me or
any of the other people with access now and we can share it with you.

On Mon, Jun 13, 2011 at 1:22 PM, Arlin Stoltzfus <ar...@um...> wrote:
> After our telecon, which suggested that splitting out the  MIAPA part was a better strategy, I started a separate doc for this here:
>
>  https://docs.google.com/document/d/16bno1sB3gBHHnew5TnoCLawScuoydG-i5LCPcB30OZY/edit?hl=en_US
>
> The focus of this, as currently conceived, is to combine problem-solving with development of a draft standard.  The problem-solving attempts to address relevant user needs (e.g., helping users to create a properly formatted and annotated archive submission).  This way, we will be developing technology support at the same time as the draft standard (which, ideally, will encourage the broader community to try it out and work with us).
>
> If you are interested, please take a look at the proposal, help us to identify problems to address and possible strategies to address them by leveraging available technologies and resources.  Those who are interested will need to solidify partnerships as soon as possible, as there is only a month left to formulate the plan and write the proposal.
>
> Arlin
> ________________________________________
> From: mia...@go... [mia...@go...] On Behalf Of Karen Cranston [kar...@ne...]
> Sent: Thursday, June 09, 2011 12:58 PM
> To: ph...@go...; MIAPA; TreeBASE devel
> Subject: Re: ABI proposal for phyloinformatics
>
> Hilmar and I talked to Anne Maglia from NSF this morning. The notes
> are on the "Pitches for TreeBASE_ABI" document (which is now editable
> by anyone with the link, BTW). She did not see any major issues and
> had plenty of advise on how to avoid common pitfalls when writing for
> the ABI panel.
>
> Summary:
> 1. Making the MIAPA component into a separate Innovation proposal is
> probably a good idea.
> 2. The TreeBASE / ToLWeb piece is well-suited for a Development
> proposal, and we can discuss MIAPA in this proposal as long as we have
> a concrete contingency plan for the possibility that this gets funded
> and the MIAPA proposal does not.
> 3. There is no general rule about incremental improvement vs major
> re-engineering, but the goals of the proposal must be novel in some
> way and have intellectual merit. A re-engineering proposal could be
> computationally novel, while a proposal with only incremental
> improvements must instead have novel interface components or strong
> biological motivations.
> 4. There seems to be an empty niche for proposals that include novel
> front-end as well as back-end development, but we need to make sure we
> have the appropriate expertise for the former.
> 5. She suggests sharing the draft with someone from BIO (perhaps
> Maureen Kearney) to get the user community perspective
>
> Please fill out the doodle poll so that we can plan the next course of action!
>
> Cheers,
> Karen
>
> On Wed, Jun 8, 2011 at 4:24 PM, Hilmar Lapp <hl...@ne...> wrote:
>> It looks like a response from NSF is still pending. There is not a lot of
>> time left until the submission deadline, and I'll be out of commission for
>> at least 7 days during that time starting Wed next week. So I suggest we
>> start planning and get together independently of the NSF response to hash
>> out over a conference call possible contributions and commitments. Here's a
>> Doodle poll for scheduling.
>>
>> http://www.doodle.com/8zvwbidtxm9gzxcp
>>
>> To make sure that we can have a relatively targeted discussion, my
>> suggestion would be that everyone who is willing to play a role in this
>> proposal enter their availability, and come prepared for the following
>> questions:
>>
>> 1. What aims would a proposal need to have to for you to commit to be part
>> of it, and conversely, what aims should it not have. (Ideally, the aims
>> would be from either pitch A or pitch B that Karen sent to NSF for
>> feedback.)
>>
>> 2. What aims, expertise, and partners are we missing from the group. Do you
>> have suggestions for how to pull those in.
>>
>> 3. What role are you interested in playing, for which aim(s). What kind and
>> how many resources do you anticipate requiring support for to accomplish
>> those aims.
>>
>> At the end of this, ideally we have a concrete sense for whether there are
>> 0, 1, or 2 proposals that are viably going to come together, what size of
>> proposal(s) we are talking about, who would take responsibility for what,
>> and who else we need to reach out to.
>>
>> Comments / suggestions / additional items for the enumeration above welcome.
>>
>>        -hilmar
>> --
>> ===========================================================
>> : Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
>> ===========================================================
>>
>>
>>
>>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Karen Cranston, PhD
> Training Coordinator and Informatics Project Manager
> 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
>
> --
> 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
>



-- 
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

Re: [Treebase-devel] Including logicals in searches of phylows

[Rutger V. <R....@re...>]

Hi Carl,

sorry about the late uptake on this. It's possible there's a bug
there. Perhaps you could post a report on the bug tracker
(http://sourceforge.net/tracker/?group_id=248804&atid=1126676) so this
doesn't slide into the memory hole?

Thanks,

Rutger

On Thu, Jun 2, 2011 at 9:09 PM, Carl Boettiger <cbo...@gm...> wrote:
> Dear list,
> I see the wiki mentions that logicals are supported on the phylo-ws queries,
> i.e.
> http://purl.org/phylo/treebase/dev/phylows/study/find?query=dcterms.contributor=Ronquist%20and%20dcterms.contributor=Hulesenbeck&format=rss1&recordSchema=tree
> http://purl.org/phylo/treebase/dev/phylows/study/find?query=dcterms.contributor=Ronquist%20or%20dcterms.contributor=Hulesenbeck&format=rss1&recordSchema=tree
> http://purl.org/phylo/treebase/dev/phylows/taxon/find?query=tb.title.taxon==%22Homo%20sapiens%22%20AND%20%22Pan%20troglodytes%22&format=rss1&recordSchema=tree
>
>
> This works, except that it seems that "and" is always treated as "or".  Am I
> constructing the query incorrectly somehow?
> -Carl
> --
> Carl Boettiger
> UC Davis
> http://www.carlboettiger.info/
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> 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

Re: [Treebase-devel] analysis metadata in TreeBASE, some experiments

[Rutger V. <R....@re...>]

It looks like the example file was blocked by the mailman software so
I committed it to the nexml examples directory. Here it is:
http://nexml.svn.sourceforge.net/viewvc/nexml/trunk/nexml/examples/treebase-record.xml?revision=1697&view=markup

On Mon, Jun 13, 2011 at 1:37 PM, Rutger Vos <R....@re...> wrote:
> Hi all,
>
> over the weekend I did some experimentation with how additional
> metadata having to do with phylogenetic analyses stored by TreeBASE
> could be serialized. Attached is the result as produced by a test case
> that I committed to the TreeBASE source.
>
> For context, here is how TreeBASE sees the world: every submission to
> TreeBASE consists of the results of one or more analyses. Each
> analysis consists of one or more analysis steps. For each step, we
> store the "algorithm" (e.g. neighbor joining) and the "software" (e.g.
> PAUP). Optional additional metadata can consist of a textual
> description of the algorithm, a version number and URL of the software
> and a text string containing analysis step commands (perhaps something
> like a PAUP block).
>
> Every analysis step has input and output data. These data can be trees
> and matrices. The set of taxa in the input must be a superset of the
> taxa in the output (i.e. some sort of taxon pruning is allowed, but
> new taxa cannot be introduced during an analysis step). All data
> that's accessible to third parties (i.e. all public, non-embargoed
> data) must be the input or output of at least one analysis step, i.e.
> we don't allow orphaned data in completed submissions.
>
> In the attached example, I'm annotating the study (i.e. the root of
> the nexml document) to specify the permanent URLs of any associated
> analyses, and I annotate those analysis URLs with their respective
> analysis steps, specifying their PURLs and any additional metadata as
> described above. This is shown in lines 3-13.
>
> Then, for every data object I specify for which analysis step(s) it is
> the input and/or output (a data object can be both input and output if
> analysis steps are chained together). This is shown in line 448 for a
> character state matrix and line 1849 for a tree.
>
> This is all highly experimental but I figured I'd share at as a
> discussion piece for refining actual implementation of MIAPA
> annotations.
>
> 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
>



-- 
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

[Treebase-devel] analysis metadata in TreeBASE, some experiments

[Rutger V. <R....@re...>]

Hi all,

over the weekend I did some experimentation with how additional
metadata having to do with phylogenetic analyses stored by TreeBASE
could be serialized. Attached is the result as produced by a test case
that I committed to the TreeBASE source.

For context, here is how TreeBASE sees the world: every submission to
TreeBASE consists of the results of one or more analyses. Each
analysis consists of one or more analysis steps. For each step, we
store the "algorithm" (e.g. neighbor joining) and the "software" (e.g.
PAUP). Optional additional metadata can consist of a textual
description of the algorithm, a version number and URL of the software
and a text string containing analysis step commands (perhaps something
like a PAUP block).

Every analysis step has input and output data. These data can be trees
and matrices. The set of taxa in the input must be a superset of the
taxa in the output (i.e. some sort of taxon pruning is allowed, but
new taxa cannot be introduced during an analysis step). All data
that's accessible to third parties (i.e. all public, non-embargoed
data) must be the input or output of at least one analysis step, i.e.
we don't allow orphaned data in completed submissions.

In the attached example, I'm annotating the study (i.e. the root of
the nexml document) to specify the permanent URLs of any associated
analyses, and I annotate those analysis URLs with their respective
analysis steps, specifying their PURLs and any additional metadata as
described above. This is shown in lines 3-13.

Then, for every data object I specify for which analysis step(s) it is
the input and/or output (a data object can be both input and output if
analysis steps are chained together). This is shown in line 448 for a
character state matrix and line 1849 for a tree.

This is all highly experimental but I figured I'd share at as a
discussion piece for refining actual implementation of MIAPA
annotations.

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