Difference between revisions of "CarrotBase"

From Evolutionary Informatics Working Group
Jump to: navigation, search
(List of data resources to target)
Line 13: Line 13:
For more information, and analysis of target potential, see [[Data Resources]].
For more information, and analysis of target potential, see [[Data Resources]].
* resources for systematics  
* resources for systematics
** taxonomies such as NCBI; uBio; for more, see list from Rod Page paper
** taxonomies such as NCBI; uBio; for more, see list from Rod Page paper
** [http://tolweb.org Tree of Life], note example implementation, e.g. [http://nexml.org/nexml/phylows/tolweb/16299 hominidae subtree (node 16299)]
** [http://tolweb.org Tree of Life], note example implementation, e.g. [http://nexml.org/nexml/phylows/tolweb/16299 hominidae subtree (node 16299)]
Line 24: Line 24:
** [http://pbil.univ-lyon1.fr/databases/hovergen.php Hovergen], [http://pbil.univ-lyon1.fr/databases/hogenom.php hogenom]
** [http://pbil.univ-lyon1.fr/databases/hovergen.php Hovergen], [http://pbil.univ-lyon1.fr/databases/hogenom.php hogenom]
** organism-centered gene-family databases, e.g., for plasmodium
** organism-centered gene-family databases, e.g., for plasmodium
* Other
* Other
** [http://phylomedb.bioinfo.cipf.es/ PhylomeDB]
** [http://phylomedb.bioinfo.cipf.es/ PhylomeDB]
** [http://loco.biosci.arizona.edu/pb/ PhyLoTA]
** [http://loco.biosci.arizona.edu/pb/ PhyLoTA]
Line 32: Line 32:
** [http://www.morphbank.net/ MorphBank]
** [http://www.morphbank.net/ MorphBank]
== Notes on how to approach this ==
=== Our notes from the working group meeting ===
=== Our notes from the working group meeting ===

Revision as of 13:28, 23 September 2008

News flash: the 4th meeting of the working group will be a Database_Interop_Hackathon that takes on some of the interoperability challenges described below.


The goal of improving interoperability is not served merely by developing artefacts such as CDAO and nexml. In order to improve interoperability, these artefacts must be used in the research community and, ideally, they must become popular. Thus, to achieve its goals, the working group wishes to promulgate its artefacts, and in particular, we wish to develop a strategy to reach a "critical mass" in which there are sufficiently many operations and resources that rely on an artefact to ensure that the self-interested researcher (or the lazy programmer) embraces the artefact simply because its useful and not just for some intangible long-term benefit of "interoperability".

Our main focus is on the "carrots" part of a "carrots and sticks" strategy, but first we should explain the "sticks" part. Journals that serve the evolution research community have indicated a desire and a willingness to impose data archiving requirements on authors as soon as the technology becomes feasible (Todd Vision, pers. comm.; see Dryad project); also, the research community has called for a minimal reporting standard, MIAPA. These two aspects of interoperability go together: the repository goal favors a minimal reporting standard such as MIAPA to ensure that archived data are re-usable. Furthermore, these two aspects of interoperability go together with a third aspect, which is a file format that is MIAPA-compliant and that is accepted by archives. The "stick" part of our nexml-CDAO strategy is that we intend to support MIAPA, which means that some users may resort to using nexml-CDAO if it is the most convenient way to achieve MIAPA-compliance or to archive data.

The tentatively named CarrotBase project is intended to provide a more positive incentive, i.e., to represent the "carrots" part of the strategy. When we constituted the working group in 2006, we clearly were targeting developers of phylogenetics applications software. This might have been the best way to start developing the technology for interoperability-- artefacts such as nexml and CDAO-- but now we are faced with a different problem of promulgating these technologies. Targeting applications does not seem like the best way to generate carrots for users. Targetting data resources might be more effective.

List of data resources to target

For more information, and analysis of target potential, see Data Resources.

Notes on how to approach this

Our notes from the working group meeting

Data resource interop project

  • rationale
    • need to develop critical mass for nexml-cdao (critical mass of community involvement, use-cases, eyes on code)
    • hard to get critical mass by targeting app developers
    • hard to show value by targeting app developers
    • strategy of targeting data resources puts data in hands of users
    • however there also are carrots for db maintainers:
      • interchange with other sources
      • common treatment of keys such as taxonomy
  • data resources to target (see Data Resources page)
  • implementation strategy
    1. recruit participants
      • possible leadership from Hilmar, other suggestions (Rod Page, Bill Piel, Encyc of Life, TOL)
      • other participants drawn from projects above
    2. develop project plan
      • consider implementing a coordinated db with families from many sources (similar philosophy to InterPro for protein family alignment dbs?)
      • CDAO to providing constraining vocabulary for nexml schema
        • disagreement over whether this is a good idea
        • to succeed, we must provide users a way to expand nexml, thus to expand cdao
        • mechanism is the feature request, e.g., I want to represent Bremer values
          1. user contacts nexml.org about how to represent new type of data
          2. if a formal mechanism is desired but does not exist
          3. user is referred to cdao feature request (must provide searchable interface and front page link to feature request form)
          4. cdao developers are obliged to respond
    3. get support
      • NSF grant
      • NESCent-sponsored hackathon

More notes, from telecon with Hilmar and Arlin (5/29/08)

Outline of the basic plan

  1. expand CDAO to support more metadata
  2. map CDAO to a relational schema (CDAO already is mapped to nexml and NEXUS)
  3. develop a database interface that has some nice features
    • better query interface than TreeBase or Pandit because it has more access to semantics
    • output in rich, structured format (nexml)
    • some nice integrated tools such as ATV and jalview, iTOL
  4. pick two or three data resource managers to come work with us to develop a mapping, so that the content of their resources can be uploaded automatically into the database application via nexml-CDAO
  5. finally, hold a hackathon where we bring in other data resource managers to create their own mappings
  • the goal is to develop an integration platform
    • integrate taxonomy, phylogeny, gene family databases
  • data resource manager can take existing content, load it into db package, and automatically get the cool features
    • taxonomic links
    • standard services API
    • allows data submission, returns data in nexml or equiv
    • accepts metadata and transmits it
    • reasons over metadata, e.g., validate MIAPA compliance
  • NSF grant
    • Advances in Biological Informatics (due August 12)
    • program has explicit shift in focus away from database creation . . .
    • . . . but that's ok because we won't focus on One Database That Rules Them All, but on the infrastructure that supports them all
  • questions
    • isn't this proposing the same thing as pPOD?
    • apparent overlap with pPOD is strong; need buy-in from them
    • do we need a pilot project to get preliminary results?
    • do we need to hire interface programmers to do this? A: can do it by contract, at least initially