Page History

...

3) Creating a New Application-Specific Property Type (Supports data collection in the SWEET UI when the property is linked to a resource - see #4 below)
Creation of new properties is covered in the eagle-i Resource Ontology section. We extend these guidelines here to cover cases where the desired property is application specific and not suitable for broad community re-use, i.e. is overly specific in its meaning or domain/range constraints in order to support application needs. Unfortunately, there is not a clear rule to decide whether this is the case, and we will have to rely on the judgement of the editor and their knowledge of the ontology landscape.

In such cases, the property should live in the application layer (ero-app.owl). Additionally, a practice was partially implemented whereby the IRIs of such properties were created in a different namespace (http://eagle-i.org/ont/app/1.0/), instead of the standard http://purl.obolibrary.org/obo/ namespace. In practice, this was a good idea; however it was never consistently implemented, and only a handful of properties use this (roughly 20, e.g. http://eagle-i.org/ont/app/1.0/has_related_study_design). If it is decided to pursue this strategy, refactoring of the existing application-specific eagle-i property IRIs to use this new namespace needs to occur.

...

5) Defining a Property’s Values (Reference Taxonomies and Inter-Resource Links) (Creates the pick-list that constrains value entry for a given controlled metadata field)

As noted in the eagle-i Resource Ontology Viewing and Editing the Ontology in Protege instructions, owl:DatatypeProperties are used when linking a resource to a free-text description, and owl:ObjectProperties are used when linking between entity IRIs. The types of entities that are allowed as values for a given owl:ObjectProperty are defined by the range of the property. The identity of the classes declared as the range of a property drives the pick-lists that appear in the UI when entering controlled metadata about a resource.

...

• • • 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  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.

...