Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Notation Conventions in this Document

 

 

Info
iconfalse
  • Property names are italicized.

  • Class names are in 'single quotes'.

  • Individual names are in monospace font. 

  • Important concepts and references to sections, tables, or figures are bolded.

 

 

Glossary of Concepts and Terms

...

Info
iconfalse

See the Table of Annotation and Domain Layer Files for a list of IRIs, key features and descriptions content of files that comprise the domain and application layers.

Concept 2: Extended vs Core Domain Content (model / files / classes)

 

This is an artificial distinction made based on how MIREOTed content is stored and loaded into memory.

 

 

"Extended" content (files / taxonomies / terms) comes from five ontology imports (Uberon, GO, MP, Pato, DOID). Due to their size, these are stored in owl files separate from the ero.owl core file that holds all other domain content. Their content makes these files too large to be loaded into memory as the application runs, and are therefore indexed separately and dynamically called as needed. These files are also handled separately by build scripts and housed in separate files at the end of the build pipeline.

 

The descriptor "extended" may be used below to refer to files, taxonomies, or terms:

  • "Extended files/modules" are these five import files and their associated app files
  • "Extended taxonomies' are the class hierarchies these files contain
  • "Extended terms" are classes/properties/individuals in these hierarchies

 

 

"Core" content includes all other domain content that lives in the ero.owl module. This includes terms defined natively in the ERO namespace (ERO_XXXXXXX), and content MIREOTed from other ontologies, such as OBI, SWO, SO, OCRE, etc.   

 

 

The extended vs core distinction is important, as specific application annotations are needed to guide the software in finding axioms in the right files, as detailed in the Table of Annotation Properties and in the Task Workflow and Scenarios below. The classification of each file in the eagle-i ontology as being extended vs core is indicated in the far right column of the Table of Annotation and Domain Layer Files .

Concept 3:  Resource Classes (aka Instantiated Classes)

 

“Resource” classes represent entities considered to be research resources for which instances are created in the eagle-i data. Subtypes of this concept include "primary" resources that are cataloged and shared, "embedded" resources that are directly related (1:1) with a single primary resource instance, and "stubbed" resources that can be related to more than one primary or embedded resource instance (and also not cataloged or shared in eagle-i).

Class TypeDescriptionExamples
Primary Resource ClassesRepresents the main resources types cataloged and shared as instances in the eagle-i data.
Examples include: 'antibody reagent', 'software', 'service offering', 'instrument', ‘cell line’, etc.
Embedded Resource ClassesRepresents non-primary resources for which instances are created and that are linked 1:1 with a single resource instance. Embedded resources are not cataloged and shared by eagle-i.
Examples include: 'construct inserts' as embedded resource types for 'DNA constructs', 'phenotype annotations' as embedded resource types for 'organisms'.
Stubbed Resource ClassesRepresents non-primary resources for which instances are created that can be linked to more than one resource instance. Stubbed resources are also not cataloged and shared by eagle-i.Examples include: 'genetic alteration’ instances, which can be associated with both primary resources or other stubbed resources (such as a ‘cell line’ instance and a ‘human subject’), and 'human subject' instances, which can be linked to more than one 'primary cell line' instance.