Page History

...

A) Defining Referenced Taxonomy Pick-Lists (Pointing a Property to a Referenced Taxonomy): A referenced taxonomy is a hierarchy of controlled terms used as values of properties to describe a given resource. Instances of these classes are not created in the data - rather, its IRI is used as the object of an rdf triple describing the resource. When a pick-list is needed to constrain the value set for a metadata field in the SWEET, the root class of the desired hierarchy can be added to a logical range declaration axiom. This axiom can live in the domain layer (in cases where it makes sense generally speaking for the range of the property to be defined as such) or in the application layer (when this is not the case). As we saw for defining object property domains above, an alternative way to define the range of a property is to create in the application layer an eagle-i range constraint annotation that holds the IRI of the range class as a value.  Here, one annotation axiom should be made per range to be declared, but multiple annotations can be made if the domain is a union of many classes.

After declaring a given class as the range of a property, two specific annotations are required on the class to make it the root of a referenced taxonomy:

• • • An InClassGroup annotation with the value Class Referenced Taxonomy is needed.
      • If the taxonomy root class lives in the core ero.owl file, this annotation should live only in the eagle-i-core-app.owl file (e.g. 'technique', 'data format specification').
      • If the taxonomy root class lives in an extended owl file (e.g. 'material anatomical entity' in uberon-import.owl), the annotation needs to live in the appropriate application layer owl file  (e.g. uberon-import-app.owl), and then duplicated in the eagle-i-core-app.owl file.
    • An eagle-i referenced taxonomy IRI annotation holding the IRI of the application ontology for the extended ontology where the taxonomy content lives is also needed on the root of the referenced taxonomy.
      • For a class in the core ero.owl file, the value of this annotation will be "http://eagle-i.org/ont/app/1.0/eagle-i-core-app.owl"
      • For a class  in an extended owl file, the value will the IRI of the appropriate application layer file (e.g. "http://eagle-i.org/ont/app/1.0/uberon-import-app.owl" for a referenced taxonomy rooted in uberon-import.owl). This annotation lives in the eagle-i-core-app.owl file. The IRIs of all app layer ontology files that might be values of the eagle-i referenced taxonomy IRI property can be found in Table 3 above.

For an example of how this works for a referenced taxonomy rooted in an extended owl file, see the 'material anatomical entity' class.  Here, the InClassGroup annotation lives in the uberon-import-app.owl file AND the eagle-i-core-app.owl file. And the eagle-i referenced taxonomy IRI annotation lives in the eagle-i-core-app.owl file, and holds the value "http://eagle-i.org/ont/app/1.0/uberon-import-app.owl". The duplicated InClassGroup annotation is needed so that the root of the referenced taxonomy is flagged in a file that is loaded into memory, and then the eagle-i referenced taxonomy IRI  annotation tells the application logic where to go to retrieve the content of this referenced taxonomy. Compare this to a referenced taxonomy rooted in the core ero.owl file such as 'technique' or 'data format specification' - where the duplication is not required.

An important variation on this workflow is pointing a property to a sub-hierarchy of an existing referenced taxonomy: When pointing a property at a descendant of a core ero.owl class that is already declared as the root of a referenced taxonomy, no additional annotations are needed if the class lives in the core ero.owl file. However, if the class lives in an extended owl file, an additional eagle-i referenced taxonomy IRI annotation holding the IRI of the relevant app layer file is required to direct the application logic to this file and load it into memory (e.g. "http://eagle-i.org/ont/app/1.0/uberon-import-app.owl" for a referenced taxonomy rooted in uberon-import.owl). An example of this can be found on the 'germ layer/neural crest' class that is a descendant of the 'material anatomical entity' class, and declared as the range of the has_potency property that hangs from 'stem cell lines'

B) Defining Resource-Instance Pick Lists / Inter-Resource Links (Pointing a Property to Another Resource):
Enabling a metadata field for a given resource to take a related resource IRI as a value is an important feature of the eagle-i application, as it creates inter-resource links in the data that support navigation and builds a true knowledge graph. This is achieved by first pointing a property from a resource (the domain) to the class of resources with which the link is desired (the range). To do this use one of the two mechanisms for defining property domains ranges as described above. The target class is a resource and therefore should already have an InClassGroup Class Instance Create annotation axiom, along with an additional InClassGroup annotation defining it as Primary or Embedded where applicable. Details on creating these annotations are provided above. With these annotations in place, the SWEET will recognize the specified metadata field as linking form a resource instance to another resource instance, and provide a picklist of existing resource instances (along with a means to create a new resource instance with which to link).

...