Difference between revisions of "KB-OWL"
Jim Balhoff (talk | contribs) (→Data model) |
Jim Balhoff (talk | contribs) (→Data model) |
||
| Line 2: | Line 2: | ||
==Data model== | ==Data model== | ||
| + | ===Phenotypes=== | ||
Phenotypes in the new data model are modeled as OWL class expressions. They are now constructed in an inverse fashion from the form in the original KB - rather than describing classes of particular qualities which inhere in particular structures, we describe parts which bear particular qualities (at the level of instance data the model is the same — ''inheres_in'' is the inverse of ''bearer_of''). | Phenotypes in the new data model are modeled as OWL class expressions. They are now constructed in an inverse fashion from the form in the original KB - rather than describing classes of particular qualities which inhere in particular structures, we describe parts which bear particular qualities (at the level of instance data the model is the same — ''inheres_in'' is the inverse of ''bearer_of''). | ||
| Line 15: | Line 16: | ||
The has_part formulation also provides the benefit of automatic "present" inferences for structures used in any phenotype, not just "present" phenotypes. | The has_part formulation also provides the benefit of automatic "present" inferences for structures used in any phenotype, not just "present" phenotypes. | ||
| + | |||
| + | ===Taxa and phenotype annotations=== | ||
==Reasoning== | ==Reasoning== | ||
Revision as of 21:46, 4 January 2012
This page describes the data model, data loading process, and query methods being developed for a new version of the Phenoscape Knowledgebase built on top of RDF and making use of standard OWL reasoners.
Contents
[hide]Data model
Phenotypes
Phenotypes in the new data model are modeled as OWL class expressions. They are now constructed in an inverse fashion from the form in the original KB - rather than describing classes of particular qualities which inhere in particular structures, we describe parts which bear particular qualities (at the level of instance data the model is the same — inheres_in is the inverse of bearer_of).
For example, "serrated dorsal fin":
- old: exhibits some (serrated and inheres_in some dorsal_fin)
- new: has_part some (dorsal_fin and bearer_of some serrated)
We can now model absence correctly. The previous version of the KB uses a quality class called 'absent' in a way which produces unintended inferences. In the new model we use universal quantification with negation. For "dorsal fin, absent":
- has_part only (not dorsal_fin)
For a localized absence we would use a nested has_part:
- has_part some (head and has_part only (not scale))
The has_part formulation also provides the benefit of automatic "present" inferences for structures used in any phenotype, not just "present" phenotypes.
