BBOP OBD visit

From phenoscape
Revision as of 21:04, 22 August 2008 by Jpb15 (talk | contribs) (Notes)

Setup

Checkout code from NCBO GForge

  • OBDAPI
  • OBDUI

Developers recommended to use Eclipse

Everything can be run from command line; eventually everything can be run from a RESTy web admin interface.

  • TODO: web admin interface (PUNT)
  • TODO: add instructions for setting up PATH

Initialization

Core database plus ontologies

Run

obd-create-db.pl -h <HOST> -d obdevo -c obdevo.conf

Then run

obd-reasoner.pl -d obdevo@HOST

This populates the deductive closure

  • TODO: create and test obdevo.conf (1 day)

This is just a newline separate list of ontology IDs (teleost_anatomy quality etc) or URLs

(Optional: sources can be loaded later)

Load Phylogenies

OPEN. Is this entirely covered by loading TTO? Do we want to load alternative phyogenetic hypotheses? Metadata on how the tree was arrived at? Branch lengths? How will these be used in queries?

Loading of PhyloXML or NHX files would be easiest for us

Load annotations

Run

obd-exec --format org.obd.parser.NESCENTPhenoteConfigParser <TAB-FILES>

  • TODO: write org.obd.parser.NESCENTPhenoteConfigParser (1 day)

(use NCBO one as a template)

Note that we could write a phenote mapping to org.obo.annotation instead. This is probably the way to go in the long run, but it will slow us in the short term. See Phenote section below


Once the annotations are loaded we run the reasoner again:

obd-reasoner.pl -d obdevo@HOST

This computes the subsumption relations between EQs

  • TODO: add NESCENT specific rules (3+ days) (PUNT)

TBD: discuss the relation between a higher taxon and phenotypes instantiated by sub-taxa. How to deal with loss?

See also phylogenies above

Set up UI / REST interface

ROB: fill in generic OBD TomCat instructions here

The web interface is bare bones, but it will allow you to navigate taxon-taxon, taxon-phenotype, phenotype-phenotype, phenotype-taxon

(here phenotype encompasses EQ class expressions as well as individual ontology classes)

Also uses reasoner results in querying

PLAN: set up initial install, demo, discuss further requirements, what is required from API to implement them

Annotation and Ontology Lifecycle

For now the easiest way to deal with lifecycle is to recreate the database from scratch. If all primary data is in cvs/svn/ftp we lose nothing, but there is admin overhead etc

Longer term OBD will support incremental loading

  • TODO: incremental annotation loading support (PUNT)

Medium term the entire load cycle can be automated, so long as everything is configured:

  • TODO: add NESCENT .tab file location to annotations metadata file

This is the file here: http://obo.cvs.sourceforge.net/obo/obo/website/cgi-bin/annotations.txt?view=log

It is easiest for OBD if all sources are registered.

  • TODO: load + reason entire OBD database automatically from config

Phenote integration

  • TODO: write org.phenote.datamodel.NESCENTTaxonPhenotypeMappingDriver (3 days) (PUNT)

As noted above, this can be sidestepped in the short term for OBD loading

  • TODO: write adapter GUI in Phenote

Additional capabilites

TBD. Some ideas:

  • evo-devo lenses (Jim/Rob)
  • integration with wider phenotype database

e.g. to do integrate ZFIN genotype-phenotype annotations with evo-debo ones This can be done dynamically with a MultiShard

Notes

OBD model

  • Began mapping of Phenex data model to OBD model. This is currently implemented in org.phenoscape.bridge.OBDModelBridge.java, in the Phenex source.
    • "Adminsistrative" entities such as the character matrix, characters, and states, are modeled as instances of types from CDAO. This is currently done in a placeholder manner, e.g. "cdao:CharacterStateDataMatrix".
    • Need to interact with EvoInfo group to confirm correct usage of types and relations from CDAO.
    • Mapping of specimens is still to be implemented.
  • Phenotypes
    • Quantities such as measurement are not yet handled. This will require further discussion between Cartik, Chris, and Jim. Beyond basic quantities, we want to also handle min and max, as defined in PhenoXML.
    • We may want to remove the count field from Phenex and input counts as measurements instead. The "count" unit is available in the units ontology. This is up for discussion at the moment.

OBD SQL

OBD API

  • We used the OBD Java API to implement the mapping in Phenex (above).
  • We successfully connected to and manipulated a local OBD database as well as an OBD instance at darwin.nescent.org via the OBD API.

OBD Web UI

Phenex OBD interaction