evoinfo / planning

Wiki, planning, projects, milestones, discussion etc
0 stars 0 forks source link

Value in consolidating EvoInfo artifacts & resources? #1

Open hlapp opened 7 years ago

hlapp commented 7 years ago

I created this Github organization as a suggestion for how we could consolidate some of the currently quite disparate resources that originated under the EvoIO umbrella. There are at least the following:

Even if several of these are not actively maintained or might even be considered abandoned, they target use-cases that remain relevant to actively developed projects, such as MIAPA for tree annotation and quality in OpenTree, PhyloWS for tree store API conventions in OpenTree and Phylotastic, NeXML for data exchange to/from Phenoscape, and CDAO and MIAPA for Phyloreferencing.

More broadly, they target interoperability for evolutionary informatics, and there may well be other resources that fit that umbrella and that don't necessarily have (or need) an obvious home of their own. For example, the Phyloreferencing ontology could well be put under the Phyloref project, but it could conceivably also get a permanent home under a larger umbrella such as this one.

This is in part a draft proposal open for refinement, and a request for comments. I'm also happy to take it down again if the consensus is that this isn't a good idea - I haven't put much more time here yet than needed to write this post.

@kcranston @mtholder @arlin @rvosa @ncellinese @gaurav (please feel free to tag others)

rvosa commented 7 years ago

Hi Hilmar,

good idea to at least evaluate what we want to do with these things. I would argue that NeXML is housed reasonably well: the website is hosted at Naturalis and relevant code artifacts fall under a github organization (thanks to @yeban).

I, personally, am most concerned about CDAO. I've noticed at the latest BioHackathon that it is, in fact, being used - by people that semantically integrate orthology databases - so it needs a good place.

Rutger

hlapp commented 7 years ago

I would argue that NeXML is housed reasonably well

Just perhaps to clarify, I didn't so much mean to argue about how well any of these is currently housed (much of which tends to be a matter of opinion -- some would argue that something housed at SourceForge under SVN is housed well). Rather, one of the questions I wanted to raise is whether there isn't additional value to be had from these being housed less disparately, even if they are currently housed well (in someone's definition of that).

That said, I do agree about CDAO.

arlin commented 7 years ago

Thanks for initiating something. I think what is needed is a forum that brings us together in a way that NESCent activities used to do, with the effect of increasing networking, awareness of available technologies, awareness of common challenges, creating opportunities for collaboration, and so on. For instance, Phylotastic is going to have to present some kind of solution to serializing richly annotated trees, including MIAPA-guided workflow annotations. We would rather have community input on that, but getting community input in a formal way is a huge time-consuming process.

I'd like to suggest a monthly session that begins with a 15-minute progress report from a representative of a project (OT, Phylotastic, GlobalNames, Phyloreferencing, EOL, etc), followed by 15 minutes of discussion on that project, followed by another half-hour of open discussion. New tree-viz web sites are popping up every few months. Who are these people and what are their aims? Surely they would be interested in working with others like us to expand the interoperability of their products.

rvosa commented 7 years ago

I definitely would like us to be connected in a way that NESCent used to do. Not sure if this is something that calls for a technological solution (which is how I sort of read @hlapp's original post) or something social. I also, in this context, would like to point somewhat embarrassedly at the more or less abandoned lot known as the Phyloinformatics Research Foundation.

hlapp commented 7 years ago

I don't think at all that this is an either-or question. To me it's really two separate (even if very much connected) issues. A scattered and disparate community will suffer (as in, be much less effective than they could be in advancing their causes) from lack of coordination and knowledge exchange. Technical products that are scattered and disparate will be more difficult to discover for the non-initiated (i.e., the vast majority), and the bigger picture that ties them together will tend to be lost.

I think Arlin's "Community Call" idea is a really good one for the social side of things. Judging by the when the Mozilla Science Lab's calls of this kind do well, for this to succeed it needs a person designated to making it happen on a recurring schedule, including coordinating content, advance notices, moderating the call, drawing contributors out of the woodwork, to name a few things. Who can step up to this role? (At MSL, it's a paid staff person.)

Then there's still the side of the technical products that are at risk of slowly being lost to history if the unifying big picture that makes them more than their simple union is absent.

rvosa commented 7 years ago

I think it would be great if there was some sort of community organizer but indeed for this to work it would likely have to be a (semi-)paid position otherwise we'd already be doing this as volunteers.

hlapp commented 7 years ago

FYI, I have now moved here the following artifacts:

I've taken these steps not so much as a final commitment to push consolidating everything EvoIO here than as an attempt to make this a more practical than abstract consideration.

arlin commented 7 years ago

@hlapp can you invite @epontell to this repo? CDAO is being actively extended by his team for use in metadata annotation and in workflow composition.

hlapp commented 7 years ago

@arlin @epontell do you mean this (the 'planning') repo, or the CDAO repo to which I just migrated the svn repo? If the latter, term requests (via issues) and additions (via pull requests) are welcome there. If write access is needed, we should start on the cdao repo with an issue to discuss who should be designated maintainer (right now this is @balhoff).

Note that the Phyloref project will be actively extending CDAO as well. So maybe we need to put a process in place so that changes are properly reviewed, discussed, and coordinated, similar to other OBO ontologies.