stoltzfus_evoio_2010

June 29, 2010 iEvoBio

EvoIO Community-driven standards for sustainable interoperability

Rutger VosUniversity of Reading, Reading, RG6 6BX, United Kingdom

Nico CellineseUniversity of Florida, Florida Museum of Natural History, Gainesville, FL 32611

Karen CranstonField Museum of Natural History, Chicago, IL 50506

Arlin StoltzfusNational Institute of Standards and Technology, Gaithersburg, MD [email protected]

Hilmar LappNational Evolutionary Synthesis Center (NESCent), Durham, NC 27705

Sheldon McKayCold Spring Harbor Laboratory, Cold Spring Harbor, NY 11724

Enrico PontelliDepartment of Computer Science, New Mexico State University, Las Cruces, NM 88003

www.evoio.org

mailto:[email protected]


Outline • an interop disaster story• the EvoIO “stack”

• neXML (data format)• phyloWS (web services)• CDAO (ontology)

• process (organization, strategy, hackathons)• implementations• how to get involved


An interop disaster storySeck & Evans, 2004. NISTIR 7158

The Great Baltimore Fire of 1904

Fireplug conforming to NFPA Standard (1905)


standards are voluntary

The Oakland Firestorm of 1991Image: wikipedia

Seck & Evans, 2004. NISTIR 7158

Oakland conforms to standard


LessonsInteroperability standards are developed by stakeholders• organize in response to problem • collectively develop the solution

Standards are voluntary• compliance is a business decision

To further the goal of interoperability• mitigate costs of compliance• enhance benefits of compliance


EvoIO “stack”


Character-state data model

(widely used model underlying CDAO and neXML)


CDAO development

Ontology refinement

Specification: Study use-cases to clarify scope

Choice of representation: Choose language and development tools

Conceptualization: • Identify terms from use cases,

artefacts• Build concept glossary• Classify key concepts and relations

Implementation: Formalize the concepts and relations using

the chosen language and tools

Evaluation: Test the ontology for its ability to represent

data called for in the use cases, and to support reasoning

Some CDAO concepts and relations in regard to trees

neXML<!—

nested inside /nexml/characters element -->

<format> <states id="states1">

<state id="s1" symbol="1"/> <state id="s2" symbol="2"/> <state id="s3" symbol="3"/> <state id="s4" symbol="4"/> <polymorphic_state_set id="s5" symbol="5">

<mapping state="s1"/> <mapping state="s2"/>

</polymorphic_state_set> <uncertain_state_set id="s6" symbol="6">

<mapping state="s3"/> <mapping state="s4"/>

</uncertain_state_set> </states> <char states="states1" id="c1"/> <char states="states1" id="c2"/>

</format> 

formally defined syntax OTS tools to validate extensible versioned


PhyloWS URL API

Permanent URL resolver domain

Subdomain forany phylogeneticresource

Subdomainfor TreeBASE

Subdomain forPhyloWS API

Object ID

http://purl.org/phylo/treebase/phylows/study/TB2:S1787


ProcessPhylohackathon (Durham)

Planning meeting (Philly)

2011

2009

2007

2010

2008

Evolutionary Informatics Working Group

Google Summer-of-Code

WG1

WG2

WG3

WG4

PhyloWS (Tokyo)

CDAO (Durham)

DB interop hackathon (Durham)

Phyloinformatics VoCamp (Montpellier, Fr)

neXML




2009 Data resource interop hackathon

Image: Hilmar Lapp


ImplementationsNexml IO implementations• Bio::Phylo, BioPerl, HIVQuery (Perl)• DAMBE (C)• Mesquite, TreeBase (Java) *• Phenex (Java via XMLbeans)• DendroPy (Python)• NCL (C++)• BioRuby (Ruby)

PhyloWS• Phylr• TreeBase2• Bio::Phylo (ToLWeb and TimeTree via screen-scraping)

CDAO• Nexplorer3• CDAO-store• translations

Rutger VosUniversity of Reading, Reading, RG6 6BX, United Kingdom

Brandon ChishamNew Mexico State University, Las Cruces, NM

Vivek GopalanBioinformatics and Computational Biosciences Branch (BCBB), NIAID

Jim BalhoffNational Evolutionary Synthesis Center, Durham, NC


How to get involvedwww.evoio.org

Interop targets

Stack development

Hilmar

Rutger

Arlin

Nico

Karen

Enrico

Sheldon


Extra slidesNot used, due to time limitations


Organizational valuesFlexible task-specific groupsHeavy use of electronic collaboration toolsOpen-source codeOpen development teamsConsensus decision-making Flexible leadershipCoffee


The hackathon modelBefore the event

Organizers develop theme Organizers recruit participants

At the event, day 1 Initial presentations, group discussion Participants self-organize around “pitches”

At the event, after day 1 Participants work on project goals

After the event . . .