Public Requirements

From NCBO Wiki
Revision as of 09:21, 28 January 2007 by Rubin (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

1. URI Requirements

Basic functional URI requirements

  1. Provide persistent URIs for all content in BioPortal terminologies and ontologies
  2. All URIs will contain the version info for the terminology so that new terminology releases do not invalidate older URIs (ie, no URI ever disappears).
  3. All URIs provided by NCBO will have a base format of "http://bioontology.org/..."
  4. The URI will contain the version number of the terminology/ontology so that NCBO provides unique URIs for every term in every version.
  5. Enable people to refer to a URI that always points to the most current version of a term

Future URI requirements

  1. Add a link between URIs of different versions of the same term (in doing so have a "linked list" representing the history). This is purely additive so this will not affect the task of making URIs unique and persistent per version.

2. Web API

  1. https://www.nescent.org/wg/fishevolution/index.php?title=Public:Ontology_Data_Service_API

3. Load scripts to incorporate new ontologies into BioPortal

  1. Load SNOMED and ICD
  2. Load newly submitting ontologies into LexGrid

4. Ontology alignment (Show mappings of terms in different ontologies)

  1. Display the mapping of a term in one ontology to a term in another ontology as a distinct link in graph view.
  2. Permit upload of bulk mappings
  3. Permit user to create a new mapping to a selected term

5. Basic ontology diff (compare ontology versions)

  1. Pre-compute diffs for versions of all ontologies in BioPortal
  2. Present tabular display of differences between two selected versions of ontologies

6. Critical enhancements to BioPortal 1.0

  1. Prioritize feature requests collected thus far

7. UVIC Jambalaya applet for advanced ontology visualization

  1. Create Java applet of Jambalaya, adapted to make API calls to BioPortal

8. Ontology Marginal Notes

  1. Permit user to select an ontology class in BioPortal and create structured and free text annotations on ontology classes

9. Integrate Degree of Interest Models into BioPortal

  1. Integrate Diamond prototype currently in Protege into BioPortal

10. Requirements related to Relations Ontology (RO)

Queries related to use of RO:

  • Which ontologies use this relation? How many links are made with this relation in each ontology? Which OBO ontologies use relations *not* in RO?

This kind of information is available in a hideously formatted table right now: http://www.berkeleybop.org/ontologies/stats.html

  • Which RO relations link *between* ontologies. For example, there may be part_of/has_part links between cellular components or cells in one ontology and multi-cellular anatomical entities in another ontology. There are some pitfalls here due to the recurring issue of species-specificity, but we have made some progress on these kinds of inter-ontology part of links. For background on linking across these kinds of granular levels with part relations, see: http://www.bioontology.org/wiki/index.php/CL:Aligning_species-specific_anatomy_ontologies_with_CL

And of course there is ongoing work linking GO to other ontologies, and phenotype ontologies to PATO and the other ontologies representing the kinds of entities that can 'bear' a quality as defined in PATO.

  • What kinds of entities can be linked using a relation in RO? For example, the has_participant relationship is between a process and an object. The RO page has a link to a bridge file defining these constraints. Interestingly, these constraints are now defined in terms of an upper ontology called BFO which has broad utility outside biology. How should BFO be accessed in BioPortal? There is an ongoing discussion here, so there's no correct answer at this stage.

I just want to stress that these kinds of questions explicitly asked as quite esoteric for the average biologist - however, I think it is important for many of the people using BioPortal which will be a wider community including bioinformaticians, ontologists and CS folk.

Part of the beauty of RO is what it does 'behind the scenes' - RO can also be seen as a contract the ontology maintainer enters into - this allows software developers to write tools that 'return the right answer' - for example, in deciding when to perform a transitive closure over a DAG to answer questions such as "what are the statistically significant types of process, function and location associated with this list of genes". So even in cases where it is appropriate for BioPortal to hide RO relations, it should still be using them to drive graph drawing and transitive closures.

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox