Version History

Overview

The following document specifies the requirements and strategies for incorporating non-IOF ontologies or their constructs into the IOF normative ontologies. To be considered for inclusion, the ontology MUST first meet all the business criteria, and then the working group must determine the best technical strategy.

The following rules MUST be followed when reviewing this document; these are taken from IETF RFC 2119 (simplified):

1. MUST: This word means that the definition is an absolute requirement of the specification.

2. MUST NOT: This phrase means that the definition is an absolute prohibition of the specification.

3. SHOULD: This word means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications MUST be understood and carefully weighed before choosing a different course.

4. SHOULD NOT: This phrase means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

5. MAY: This word means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item.

Terminology Used in This Document

• construct: class, object property, or data property

Business Requirements

• The ontology MUST adhere to FAIR (Findable, Accessible, Interoperable, and Reusable) principles.

  • Check ontocommons score for compliance with the FAIR principles.

    • See GitHub - FAIR-IMPACT/MOD: Metadata for Ontology Description and Publication Ontology for reference to the ontocommons rules. These are an example of such principles.

  • TBD: Decide which princlples IOF will require.

• The ontology MUST have a compatible license with the IOF:

• The ontology MUST NOT contain any copyleft language that may impede corporate use (e.g., Gnu Public Licenses)

  • Copyleft is a general method for making a program (or other work) free (in the sense of freedom, not “zero price”), and requiring all modified and extended versions of the program to be free as well. [https://www.gnu.org/licenses/copyleft.en.html ]

  • The issue pertains to requiring all use and derivative work free as well. Many corporations forbid use of strict copyleft content since it could force them to disclose their IP.

• If included in IOF without IOF assuming ownership

  • The ontology MUST be actively maintained by a standards body or an organization.

  • The ontology MUST be logically consistent

    • Specify which reasoner OWL – Pellet, Hermit?

    • The ontology MUST not rely on SWRL rules for reasoning instead of OWL DL axioms

  • All these rules MUST apply to all imported ontologies and dependencies

  • The ontology MUST be in OWL

  • The ontology MUST be available from a public Persistent URL

  • The ontology MUST be maintained and versioned on a publicly available version control system (e.g. github, gitlab)

• If IOF assumes ownership by copying constructs into IOF namespace and re-axiomatizing according to IOF rules and annotations

  • Attribution MUST be provided in all constructs incorporated in IOF ontology

• Sometimes, when an ontology is insufficient or does not meet the business requirements, the IOF MAY suggest using an ontology with a user guide and best practices until another solution can be found.

• All external ontologies MUST be cached.

• The ontology MUST be approved by the Technical Oversight Board (TOB).

Rules for Caching External Ontologies Files

• We MUST have an About file to load remotely or in a non-catalog-aware tool.

  • Definition: …

  • AboutIOFDev.rdf

  • AboutIOFProd.rdf

  • The top IRI https://spec.industrialontologies.org/ontology/AboutIOFProd/

  • The core ontology IRI https://spec.industrialontologies.org/ontology/core/AboutIOFProd/

  • The maintenance ontology IRI https://spec.industrialontologies.org/ontology/maintenance/AboutIOFProd/

  • The About and catalog files MUST be maintained in the same location as the ontology file

  • We MAY want to create special About files for the non-normative content like SWRL and PropertyChains.

• Each ontology directory in GitHub all ontologies MUST provide an About*.rdf ontology to import the correct versions of the ontologies

  • Currently available at the root level (once merged):

    • https://spec.industrialontologies.org/ontology/AboutIOFProd.rdf

    • https://spec.industrialontologies.org/ontology/AboutIOFDev.rdf

    • Branched versions:

      • https://spec.industrialontologies.org/ontology/cache_external_ontologies/latest/AboutIOFProd/

      • https://spec.industrialontologies.org/ontology/cache_external_ontologies/latest/AboutIOFDev/

  • The About*.rdf ontology MUST use the version IRIs

  • All imports in the About*.rdf file MUST reference the cached files

  • All imports for releases MUST use version IRIs

  • Users loading IOF from the https://spec.industrialontologies.org/ontology/ URI SHOULD use the AboutIOF*.rdf files to load the ontologies.

  • Rationale

    • Ensures consistent versions of ontologies will always be available and always provides the correct, consistent versions of the ontologies for a release.

    • Prevents failure of the ontology to load because of broken links or unexpected changes

    • Example: The BFO purl link needs to be fixed, and the latest version is an incorrectly formed ontology.

• Each ontology directory in GitHub MUST include a root, and all ontologies MUST provide a catalog*.xml file.

  • The catalog.xml file MUST reference the cached ontologies.

  • Tools not utilizing the catalog.xml file SHOULD use the About*.rdf or explicitly load the cached ontologies.

  • The catalog file in the same GitHub directory MUST resolve every import for the ontologies in the same directory

  • It MUST have a reference to the BFO cached version.

• We SHOULD use version IRIs for all external ontology dependencies during development.

  • Exceptions when we are using pre-released external ontologies or have no version IRI

• All external ontology MUST be cached

• The Architecture TG will investigate package managers like plow: Introduction – Plow

Technical Strategy

The following strategies may be used:

• Direct incorporation without modification

  • The ontology is used verbatim without changes and imported into IOF ontology (e.g. BFO)

  • The ontology MUST have the following characteristics:

    • The ontology must be compatible with Core and BFO

• Mapping layer from foreign to IOF ontology

  • Classes are used to map from the foreign ontology to IOF ontology

  • IOF is responsible for maintaining the mapping

  • IOF creates equivalent classes to map from the foreign ontology to the

• IOF assumes ownership by copying constructs from foreign ontology to IOF and assigning an IOF IRI

  • The IOF incorporates the constructs as IOF constructs

  • Attribution of the constructs references construct origin

  • IOF MUST create new IRIs in the IOF namespace

• MIREOT (Minimum Information to Reference an External Ontology Term) https://www.nature.com/articles/npre.2009.3574.1.pdf

  • MIREOT Methodology

  • Tools can be used for automating MIREOT procedure

• Provide a non-normative guide for users to utilize an ontology that provides a necessary capability

  • The IOF does not prescribe or suggest the use of the ontology.

  • The usage guide specifies best practices compatible with future changes to the IOF ontologies.

  • The IOF MAY prescribe another ontology in the future for the same capabilities. Transitions to the new ontology MUST be provided to the users who adhered to the procedures in the usage guide.

• We MUST cache all external ontologies including non-normative guides that IOF provides a suggested usage of that ontology. (Need to discuss with @Milos Drobnjakovic (Unlicensed) )

  • Consider situations where we have our own version of the ontology that we have repaired.

Voting