Technical Principles

Technical Principles

Overview

The intent of this document is to provide those technical principles and guidelines that will promote the goals of the Industry Ontology Foundry (IOF) in creating a family of interoperable ontologies. Those goals include,

  • Creating a suite of open and principles-based ontologies, from which other domain dependent or application ontologies can be derived in a modular fashion
  • Providing principles and best practices by which quality ontologies can be developed that will support interoperability for industrial domains

These principles are intended as normative for Industrial Ontology Foundry ontologies, and ontologies submitted for contribution will be evaluated according to them. We consider these to be generally good practice, even if there are no plans to submit an ontology to the IOF.

Where we use capitalized words such as “MUST”, and “SHOULD”, they will be interpreted according to RFC 2119: Key words for use in RFCs to Indicate Requirement Levels when the principles are applied during reviews of ontologies for inclusion into the IOF.

 

Table of Contents

1 Introduction
2 IOF Ontology Architecture
3 Common Representations
4 Open Availability and Copyright
5 Scope and Context
6 Modularity
7 Ontological Considerations
8 Foundational Ontology – Use
9 Documentation
10 Textual Definitions
11 Identifiers and Naming Conventions
12 IRI and Identifier Space
13 Versioning
14 Maintenance
15 Contributed Ontologies: – Use
16 Collaboration

1 Introduction 

Ontologies provide a mechanism for several capabilities for both machines (e.g., information systems, cyber-physical systems) and humans. They represent knowledge of (some portion) a domain, support interoperability, inter-agent communication, make possible more flexible automation, and reduce risk. As mechanisms for knowledge representations, they should be expected to act as a glossary of notions used in that domain and be considered as representing a consensus about the interpretation of said notions in that domain.

To support the aforementioned capabilities,

  • IOF Ontologies MUST be both human understandable and machine interpretable
  • IOF Ontologies MUST provide documentation that allows a learning path for users
  • IOF Ontology definitions and documentation should help users to understand how notions or entities were or can be classified or otherwise represented

It is expected that IOF Ontologies will use natural language words, phrases, and constructs (e.g., compound or hyphenated words) in their construction. Given the ambiguity and confusion that can arise with the use of natural language this document will use the word ‘notion’ to refer to any of concepts, classes, relations, relationships, properties, or attributes in the context of knowledge representation or applied ontology. The word ‘term’ will refer to the natural language words or phrases that are used as identifiers of notions or entities represented in an ontology. As example, in OWL ontologies ‘term’ could refer to the identifier of a Class, Object property, or Data property.

  • Notion – The generic term to refer to a concept, class, relation, relationship, property, or attribute in the context of knowledge representation or applied ontology
  • Term –  A natural language word or phrase used as an identifier of a notion or entity represented in an ontology

It is expected that there will be implementations in multiple formal languages of the content of an IOF ontology. That is, the same ontology content, including all the notions represented therein, may be formalized in RDF, OWL, Common Logic, or other formats (including entirely in natural language).

2 IOF Ontology Architecture

The scope of the IOF is quite large and there will be many ontologies needed to meet the goals of the IOF. In order to facilitate a coherent and consistent development it is expected that there will be multiple ‘layers’ of ontologies where the ‘upper layers’ make use of the ‘lower layers’. But note, that not all ‘layers’ of ontologies will be under the auspices of IOF (see Figure 1). It is expected that organizations will extend IOF ontologies into sub-domains and applications relevant to the organization.

Starting from the most common or general (i.e., foundational, aka upper, ontology), to domain independent (reference) ontologies (e.g., reference ontologies for qualities, time, units of measure, etc.), to IOF domain reference ontologies, subdomain (i.e., more specific) ontologies, and finally application ontologies. The expectation is that this arrangement will allow IOF ontologies to be constructed cumulatively, built off ‘lower layers’.

However, to meet the goals of the IOF there cannot be a proliferation of ontologies that all claim to represent the same domain. Such a situation will be contrary to the goals of the IOF. IOF ontologies are intended to be reference ontologies representing the more common or general notions that occur in a domain. In contrast to application ontologies that provide additional levels of detail, distinction, and specialization needed to represent a subdomain or meet more stringent requirements of an application or a particular usage environment.

The following diagram, Figure 1, suggests a vision how an overall architecture of ontology ‘layers’ will be arranged and how IOF domains and subdomains may be partitioned and used. This diagram should be understood as subject to change.

Figure 1 – IOF Architecture Vision

The outlier ontology in this architecture is the ‘IOF Common Ontology’. This ontology will include various ‘bits’ needed to meet and conform to the principles identified herein and help with management. In particular it will include representations for copyright, license, versioning, provenance, contact information, etc., and other meta-notations to be used in IOF ontologies.

3 Common Representations

IOF ontologies shall be made available in both natural language and in at least one common formal language (e.g., OWL, Common Logic) using an accepted concrete syntax.

Purpose

  1. Natural language descriptions provide a human accessible mechanism to understand the notions that are represented in the ontology (and identified with terms in formal language).
  2. A common formal format facilitates the use and reuse an ontology with minimal effort.

Requirements

  1. 1. An IOF Ontology MUST have a natural language representation.
  2. 2. An IOF Ontology MUST be available in a machine-usable standard formal representation language.

Implementation

An IOF Ontology MUST be available in RDF/XML format.

Additionally, an IOF ontology MAY be available in at least one of the following formal representation formats:

  • Common Logic  
  • OWL or OWL2 concrete syntax
    • OWL2-XML                               
    • OWL2-Manchester Syntax          
    • Turtle

If the intended uses of an ontology is for semantic web applications, it SHOULD be available in OWL. OWL is part of the W3C’s Semantic Web technology stack, which includes RDF (RDF Concepts) and SPARQL.

NOTE: In lieu of a separate natural language document for an ontology, if the natural language representation is embedded in the formal representation, then there must be a mechanism to extract it into a document format.

4 Open Availability and Copyright

IOF ontologies are resources intended for the entire industrial community, thus MUST be openly available to be used by all without any constraint other than

  • acknowledgement of their origin and
  • should not be altered and subsequently redistributed in altered form using the original name, IRIs, or with the same identifiers.

Purpose

An explicitly stated copyright license clearly stating the acceptable use of IOF ontologies reduces legal risks for users (e.g., corporations) and promotes use and reuse.

Requirements

For ontology developers

  1. IOF ontologies must be copyrighted under the accepted IOF copyright license as defined by the IOF Governance Board.
  2. The license must be clearly stated in the ontology file using a ‘CopyrightLicense’ annotation or relation.

For ontology or term re-use

  1. The original source of an ontology must be credited according to the terms specified in the Copyright License of the ontology.
  2. After any external alterations to an ontology, the ontology MUST NOT be redistributed under the same name or with the same ontology IRI.
  3. If an individual term is reused (from a non-IOF ontology) without change to its definition, natural language or formal, then the original term IRI must be used. If the definition of a term, either its natural language or logical formalism is changed, the original term IRI MUST NOT be reused. Suggestions for changes or improvements to term definitions SHOULD be submitted to the appropriate group.
  4. If the content of an individual term in used (e.g., its natural language definition or formalization) the source of the term and its original IRI MUST be referenced.
  5. Regardless of which license an ontology uses, IOF requires that any reuse of an ontology attributes the source in accordance with the IOF Citation and Attribution Policy.

Remark

In general, United States copyright legislation states that entities that are not copyrightable are excluded from copyright protection. Therefore, some ontology content may not be copyrightable.

Implementation

For ontology developers

OWL

  • IOF Ontologies MUST specify the CopyrightLicense (i.e., reuse constraints) using the annotation dcterms:license in any publicly released OWL version of the ontology.

Example:


<dcterms:license rdf:datatype="&xsd;anyURI">http://opensource.org/licenses/MIT</dcterms:license>
  • IOF Ontologies that host terms developed by an external group (but which are not part of an existing IOF ontology) MUST credit the external group.

See below under ontology reuse for guidelines on importing individual terms from external ontologies.

For ontology reuse

Individual terms

The attribution method for individual terms reused from another ontology is via use of their original IRI or identifier.

In OWL – Any IOF ontology reusing individual terms from another ontology should:     

  1. Use the iof-av:importedFrom annotation on each imported term to link back to the ontology from which it was taken and/or the group maintaining it, where more information would be available about the applicable license.            
  2. Include all annotations (or other metadata) of the term including definition, authors, contributors, or editors from the original ontology.
  3. If the term is reused WITHOUT change, re-use the original term IRI
  4. If the term is reused WITH changes (i.e., the content of a term is reused), add an annotation to indicate the source (e.g., the original IRI).                              

Full ontology

The attribution method for importing an entire ontology in OWL is simply to import the ontology without modification.

Counter-examples

  • An ontology with no license statement is by default subject to the most restrictive copyright laws for those parts of the ontology that are copyrightable, and therefore is not useful within the IOF.   
  • CC BY-ND[1] allows for redistribution, commercial and non-commercial, as long as it is passed along unchanged and in whole, with credit to the creators. This license is too restrictive for the IOF, because it requires that the ontology be re-used in its entirety, which prevents the re-use of individual terms.

[1]   See https://creativecommons.org/licenses/by-nd/2.0/

5 Scope and Context

Ontologies have a scope of coverage usually described as some portion of a domain of interest, the ontology’s coverage (of that portion of the domain). In addition to the scope of an ontology there may be a context in which an ontology is developed or in which it is expected to be used.

IOF ontologies are intended to be reference ontologies and as such there should be only one for a particular domain. Having multiple reference ontologies that purport to represent the same domain (of coverage) can lead to non-use. Hence IOF ontologies must have a clearly specified scope together with content that adheres to that scope.

Ideally the scope should be sufficiently narrow to cover or address the intended coverage of the domain and its context with the intent and goal of allowing for extensions or specializations in sub-domains (i.e., an IOF ontology is intended to be a reference ontology). Content needed to support the representation of notions in the scope of an ontology or details of its content but are out of scope should be imported from other IOF ontologies. As example, if notions of time or geospatial location are needed to adequately describe the notions in the domain of scheduling, then ontologies that represent time or geospatial location should be brought in (e.g., in OWL the import mechanism would be used) and not recreated. This approach will enhance the modularity of IOF ontologies.

In addition to the scope of ontology there is its context of development or intended uses. Many times the context of development or intended uses is not made sufficiently clear with the result that implicit assumptions valid in the context of the developers of an ontology may not be valid by arbitrary users of an ontology (i.e., implicit context assumptions may be manifested in the ontology).

Another aspect of scope involves dependencies on other ontologies. It will likely be the case that IOF ontologies will make use of other ontologies in order to adequately represent their domain of coverage. For instance use of ontology of time, qualities, units of measure, or geospatial entities may be needed. These contribute to the context and scope of the ontology and such dependencies need to be made explicit.

Purpose

An ontology with a clearly specified scope and context should

  • Enhance modularity by minimizing overlaps between ontologies (e.g., duplication or conflicting representations of notions or terms),                                
  • Facilitate user searches for specific content and relevant ontologies,            
  • Enable quick selection of ontologies of interest, yet still allow for new terms to be created via (logical) combinations of existing terms,
  • Allow maximum possible use and reuse.

As a corollary to this, the domain boards should strive for community acceptance of a single ontology for its domain, rather than encouraging rivalry between ontologies.

Requirements

  1. The scope of an ontology should be sufficiently small to support modularity.
  2. The scope of an ontology and its context must be clearly stated. The statement should be brief and free of jargon.                      
  3. The scope statement must appear in any manifestation of the ontology. 
  4. The dependence on other ontologies must be made explicit.
  5. Use cases can be used as an adjunct to the required textual description and may be an aid in describing the context of an ontology.         
  6. The content of the ontology should stay within the confines of its stated scope.
  7. The name of an ontology should be appropriate to the scope of the ontology.

Implementation

In OWL ontologies the following annotation should be used.

           dcterms:abstract – <description of scope and/or context>

Example

<dcterms:abstract>The IOF Core Ontology contains notions found to be common across multiple manufacturing domains. This file is an RDF implementation of these notions. The ontology utilizes the Basic Formal Ontology or BFO as a top-level ontology but also borrows terms from various domain-independent or mid-level ontologies. The purpose of the ontology is to serve as a foundation for ensuring consistency and interoperability across various domain-specific reference ontologies the IOF publishes.</dcterms:abstract>

 

6   Modularity

To meet the goals of the IOF vision, IOF ontologies, as reference ontologies, must be modular. The notions of modularity addressed herein cover both the technical sense[1], involving conservative extensions, and the practical aspects of creating and using ontologies effectively. The former is a well developed theory, the latter involves a bit more (e.g., IOF architecture, goal of a single reference ontology per domain, well defined scope, and minimal ontological commitment).

Purpose

The use of modularity is needed to meet the goals of interoperable ontologies and a single reference ontology for a domain of coverage. Having a single reference ontology for a domain will facilitate the development of consistent extensions to subdomains and application ontologies.

Requirements

  • IOF ontologies should strive to be modular

Implementation

Modularity may be achieved in several ways

  • Having an initial well defined and constrained scope of domain coverage
  • Applying the principle of minimal ontological commitment (see section 8.1)
  • Create only conservative extensions as needs arise
  • Refactor to arrive at a more appropriate scope for an ontology       

NOTE: It is to be expected that during the creation of IOF ontologies refactoring will take place.

7   Ontological Considerations

The scope of the IOF is quite large with the space of application of IOF ontologies even larger. To promote the development of modular IOF ontologies and their uses the application of the following design principles will facilitate coherence and consistency.

Purpose

In order to create a family of modular interoperable reference ontologies that allow the expected growth to new domains, subdomains, and reuse there are several ontological principles that should be applied.

7.1  Ontological Commitment

Notions represented in the ontology (e.g., formalized as classes or relations) should be created to allow maximum reuse thus not overly constrain interpretations beyond the stated context or scope of the ontology or intended interpretation.

  • IOF ontologies should make only those ontological commitments necessary to meet IOF goals of reusability and adequate to the ontology’s scope. In particular, minimal ontological commitments are preferred.

7.2  Semantic Parsimony and Explicitness

The term or expression used for the identifier or label of a notion must not have expected semantics beyond that of its natural language definition and stated scope of the ontology: (i.e., no implicit assumptions about interpretations): Expected semantics or interpretations must be explicitly expressed via (formal) distinctions or constraints.

This means that classes and relations should have terms whose breadth is reflected by the corresponding definition. As example, the term ‘Bank’ should not be used to identify ‘an institution that provides financial services’, because the word ‘bank’ has multiple interpretations (i.e., it’s ambiguous). ‘bank’ can also refer to ‘land bordering a river’. Instead, for each interpretation of ‘bank’, a more specific term should be used that reflects or distinguishes the intended interpretation that ‘bank’ should have: ‘financial bank’ and ‘river bank.’ Such an additional or explicit label should be used even if the (explicit) scope of the ontology is the financial domain, because as a reference ontology, if it where to be brought into another ontology that uses the term ‘bank’ an inconsistency would be introduced.

  • Formal distinctions or constraints (i.e., axiomatizations) must be made to constrain interpretations of a term to the intent of the natural language definition it identifies and the term should be in correspondence with such constraints.

7.3  Context Neutrality

An entity (that is, a type of some notion) may simultaneously be part of multiple contexts. A person can be an employee, a customer, a supplier, a supervisor, etc. In each context the same entity may have characteristics or an identifier with which they are distinguished or individuated in that context, but which may not be valid in other contexts.

  • Notions in an ontology should be represented in a context-neutral fashion. If a notion is valid in multiple contexts, then characteristics or constraints used to define or distinguish that notion should be valid across all those multiple contexts. The characteristics of a notion across all contexts relevant to an ontology, and not only those of particular contexts, situations, events, or processes in which the notion may be part of, participate in, or have a role in, should be the criteria used for its definition and distinction.

7.4  Roles

Many terms used in colloquial discourse or expressions are commonly understood to refer to entities in some particular physical, social, or institutional situation (i.e., context) that confer additional distinguishing characteristics or may require the existence of additional (different) entities: there is a dependence.

Examples of such terms include customer, lawyer, doctor, product, asset, or resource. But the entity to which such characteristics or distinctions may apply in a particular physical, social or institutional context would not exist if the context changed (i.e., the context characteristics were no longer applicable.

A drill press may be created and sold as a product by one company and bought by another. But the entity involved in the (financial) transaction continues to exhibit the characteristics of a drill press (i.e., the functions or dispositions it realizes). A doctor is still a person even when they no longer want to or are allowed to practice medicine any longer. A person is still a person even when a purchase transaction is completed and they are no longer a customer.

Such terms are in fact referring to a role an entity bears or materializes in a situation or for some period(s) of time. A role can be detected by determining whether the notion or entity in question would cease to exist or their material constitution would change if it ceased to have that distinction or designation (that lead to distinguishing or identifying that notion or entity as such). As example, a medical doctor is a person who has gone through training and evaluation to be granted a license (in most jurisdictions) to practice medicine. If their license is revoked or they are otherwise stopped from practicing medicine, hence stop from being a doctor, does the person still exist? If so, then the notion of ‘doctor’ is a role.

  • A Role type should be used to distinguish a term or entity if it bears temporally or situationally dependent characteristics which are used as a means for classification.

This principle is related to that of Context Neutrality. A role may embed or provide context for a particular domain in which the role may be an important distinction or constituent.

8   Foundational Ontology Use   

To be effective and semantically interoperable IOF ontologies require ontological consistency. Given the scope of IOF some mechanism is needed to meet this requirement. An obvious choice is a foundational ontology, also known as an upper or top-level ontology, one that is domain neutral and domain general.

Purpose

Use of a foundational ontology provides the basis for ontological consistency and facilitates semantic interoperability.

Requirements

  • Each IOF ontology will be ontologically consistent with the selected IOF Foundational Ontology. As of 2019 the foundational ontology selected by the IOF is Basic Formal Ontology (BFO) 2.0.
  • Use of a foundation ontology shall not impede use of IOF ontologies.

Implementation

For each publicly released IOF ontology there shall be two versions. One version shall explicitly import and use the IOF’s selected foundational ontology. The other version shall include sufficient information to able to create a mapping from the ontology to the IOF’s selected foundational ontology (e.g. using annotations).

9  Documentation

Purpose

Documentation can serve multiple purposes, among them

  • It can allow a potential user to easily ascertain whether the ontology is of value to their domain of effort.
  • It can aid developers in correcting, modifying, or extending the ontology. 
  • It can serve as a criterion for assessing its quality.    

Requirements

There are (at least) two types of ontology documentation required for IOF ontologies. The following lists provide a core checklist, distinguishing the general documentation needed for the overall or entire ontology and the documentation needed per-notion, that must appear in any manifestation of an IOF ontology and/or external ontology documentation.

Implementation (see Appendix 0 for specifics)

In Situ or Embedded Documentation

In situ or embedded documentation addresses the overall ontology and each of the notions represented (e.g., classes and relations):

     Overall ontology (i.e., in toto)

  • Scope/Context                        
  • Assumptions (if any)
  • Copyright/License
  • Version           
  • Creator(s)  (e.g., IOF Domain Board)            
  • Maintainer(s) contact information                 
  • Location of external ontology documentation (e..g, user’s guides, use cases, videos,etc.)

      Per Notion

  • [Internal] Label          
  • Natural language definition                
  • Assumptions (if any)
  • Alternate common definition(s) if significantly different from the IOF definition. 
  • Source of definition (e.g., a standard, dictionary, IOF Domain Board consensus)
  • Explanation of any decisions or rationale used in creating the representation (as needed) 
  • Synonyms      
  • Alternate spellings

External Documentation

External documentation is additional information about the ontology not embedded in the ontology itself.

Such documentation can include:

  • Documentation providing more detail about the ontology’s raison d’etre, requirements, its coverage or context, or assumptions
  • Use cases or user stories
  • Diagrams or examples of use of the ontology
  • Competency questions or actual queries (in a query language)         
  • How to produce semantic web document compatible with the representation intended by the developers (e.g., OWL examples, OWL coding patterns)                    
  • Any additional sources (e.g., standards) used in the creation of the ontology or particular notions or terms
  • Processes or tools used in the development of the ontology
  • Instructions for submitting change requests
  • User guides or presentations
  • Videos                                    

The documentation should detail any processes specific to an ontology’s life cycle (e.g., development, changes, maintenance) and target appropriate audiences (e.g., users and developers).

10   Textual Definitions

IOF ontologies are intended to provide a consensus view of a domain (to the extent possible) and the notions and terms used therein. As such they should be able to be used as a glossary for their domain.

Purpose

Ultimately humans will decide whether the notion or terms represented in an ontology are appropriate for their use: Will the potential interpretations of the term (aka models) be consistent with my usage or application?

To facilitate such decisions an understanding (by humans) of a notion or term, its intent, and potential interpretations is required.

Requirements

  1. Every class (i.e., unary relation) term MUST be accompanied by a textual (natural language) definition.
  2. Textual definitions should be unique (i.e. no two terms should share a definition)              
  3. Relations (i.e., binary and higher n-ary) relations may be accompanied with a (natural language) textual definition or description of intent.
  4. [Natural language] Terms or expressions are routinely ambiguous (i.e., multiple interpretations); notions should be defined so that their intended interpretations within the context of the ontology is clear to a human reader and devoid of implicit semantics.

11   Identifiers and Naming Conventions

Herein a ‘term’ is an identifier for a notion (e.g., class or relation) or entity and a ‘label’ is an annotation or relation distinct from an identifier related to it.

Terms must be unique among IOF ontologies. For IOF a term identifier shall be created from natural language words. A ‘term’ identifier could consist of multiple natural language words[1] (e.g., a phrase). Single terms should be the goal. When multiple words are used, as in the case of creating an OWL subclass, the term shall be written using a variant of Upper_Camel_Case notation except that the first letter of each word used in the ‘term’ must be capitalized.

Purpose

A consistent identifier format makes it easier to understand where a class term is defined (among the many IOF ontologies), helps in creating interoperable ontologies, and aids in the development of software that use the IOF ontologies (e.g., queries, parsing, and automated processing).

Requirement

  1. Write class or unary relation identifiers using natural language terms or phrases in Upper_Camel_Case.
  2. Identifiers should be created so as to be unambiguous and not need to look at parent terms.
  3. Class or unary relation identifiers MUST represent their location in the taxonomy. When read right-to-left, be (mostly) comprehensible as a natural language word or phrase.   The identifier for the parent class, if there is one other than the super class of all classes (e.g., ‘Thing’ in OWL), shall be the initial segment in the sub-class identifier.          
  4. Write binary relation identifiers using natural language words starting with a verb (e.g., hasRole, inheresIn) unless a single verb conveys the intent of the relation e.g., bears.  Exception: There are terms is use that have evolved from acronyms but are now accepted and treated as proper words (i.e., they appear as words in standard dictionaries). Examples include laser (light amplification by stimulated emission of radiation), radar (ra(dio) d(etection) a(nd) r(anging)), etc.    
  5. Acronyms and Abbreviations should NEVER be used for identifiers. They allow for ambigutiy and their interpretations are usually context dependent. Abbreviations or acronyms shall only occur as an annotation or a relation other than the primary label and never be used as an identifier.  
  6. Identifiers and labels must be unique within an ontology and among IOF ontologies.
  7. Identifiers and primary/internal labels are not expected to be used for Human Machine Interface (HMI) display in applications.             Labels used in applications should use a different annotation or relation to present a label in a HMI.
  8. Use a unique annotation or relation (e.g., rdfs:label) for the primary [internal] natural language label
  9. Include exactly one primary label for every represented entity (e.g., class, relation)
  10. Make the primary [internal] labels to be as unambiguous as possible: Mirror the word(s) used in the identifier of the entity. Remember, the ontology is expected be used in different contexts from that for which it was originally intended. Remember also of course that the label should be unambiguous without looking at parent terms.

Examples

●  A term/identifier for the notion of system could be ‘System’. In OWL the (class) term/identifier may look like the following where the term occurs in the Systems ontology,

      <owl:Class rdf:about="http://www.iof.org/Systems.owl#System">

  • A term/identifier for an engineered system could be ‘System_Engineered’.  In OWL the (class) term/identifier may look like,

<owl:Class rdf:about="http://www.iof.org/Systems.owl#System_Engineered">

  • Or biological system, ‘System_Biologic’ may have an OWL (class) term/identifier like,

<owl:Class rdf:about="http://www.iof.org/Systems.owl#System_Biologic">

  • A OWL label annotation for ‘System_Engineered’ could be

      <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Engineered System</rdfs:label>

●  The organization of qualities and the mass quality as a subclass of quality

            Quality

                        Quality_Physical

                                    Quality_Physical_Mass

Counter-Examples

●          Quality

                        Physical

                                    Mass

12   IRI and Identifier Space

Each term (i.e., class and relation in OWL) in an IOF ontology must have a unique IRI. The IRI should be constructed from a base IRI, a prefix that is unique within the IOF and a local identifier (e.g. System).

The ID-space must be registered with the IOF library in advance.

IOF Format Ontologies

The ontologies possess a unique identifier space within the IOF. If the source ontology is in IOF-Format, then this is automatically satisfied so long as all IDs are of the form <IDSPACE> : <TERM>

The source of a term (i.e. class) from any ontology can be immediately identified by the ID-space of the identifier of each term. Therefore, it is imperative that this ID-space be unique.

Examples

Counter-Examples ● There are systems that use alpha-numeric identifiers for entities in an ontology devoid of any comprehensible natural language terms. This is not allowed in IOF ontologies.

13   Versioning

Ontologies change during their lifecycle and users need to be aware that changes have occurred. However, it is assumed that changes will not be so rapid as to require a detailed or sophisticated versioning mechanism that are used in software.

Purpose

To help distinguish when changes to an ontology have been made.

In the case of dependencies (i.e., in OWL ontologies importing of other ontologies), knowing which version of dependent ontologies can be critical to the maintenance or evolution of an ontology.

Requirements

  1. A date indicating when an IOF ontology is made available to the public shall be used as its version identifier.
  2. The version of any dependent ontologies (i.e., explicitly included ontologies) must be made explicit.

Examples

In OWL use the annotation iof:Version: <owl:versionInfo>”2018_Aug_11”</owl:versionInfo>.

In OWL use of the Import annotation can be used to make explicit dependence.

Counter-Examples

14  Maintenance

IOF ontologies need to reflect changes in domain consensus in order to remain accurate and useful over time.

Requirement

Each domain board must provide a public change request and resolution mechanism.

Implementation

Ideally, the maintaining Domain Board of an ontology should actively monitor for any changes in domain consensus, but at a minimum, the maintaining Domain Board needs to be responsive in a timely manner (less than 3 months) to requests from the community pointing out such changes in consensus.

Review Criteria

The Domain Boards need to have a policy specifying how they are planning to maintain their ontologies. There is an expectation that an ontology will be maintained for at least 3 years from the time of review.

15  Contributed Ontologies – Use

If an ontology is submitted for include in the IOF the ontology developers must document that the ontology is used by multiple independent organizations to the extent possible. Since commercial organizations are usually reluctant to publicize details of technology they use, conformance to this principle may be difficult.

Purpose

This principle aims to ensure that the contributed ontology addresses a relevant area and does so in a usable and sustainable fashion.

Implementation

The ontology developers should provide links/citations to evidence of use (see examples below).

Recommendation: It is important to be able to illustrate usage outside of the immediate circle of ontology developers and stakeholders. An ontology that has not been used by other than the developer(s) or their organization is not yet ready for contribution to the IOF. Note that the ontology can still be listed in other ontology portals while publicizing the resource in appropriate channels and searching for users with needs the ontology can meet.

Examples

  1. Use of the target ontology’s term IRIs in other ontologies. This can be evidenced by linking to the other ontology that uses an ontology term IRI from this ontology
  2. Imports in other ontologies, again, evidenced through a link to the importing ontology
  3. A documentation page with links to databases using the ontology for annotation
  4. Use in semantic web projects
  5. Use in diverse software applications, including data mining or analysis pipelines
  6. Citations to the ontology in publication(s); such citations are only relevant if the authors indicate actual use of the cited ontology within some community (mere mention of the existence is not enough to warrant inclusion)
  7. Documentation of change requests from users
  8. Use of the terms from the ontology to structure or annotate data

Counter-Examples

Mere mention of the existence of an ontology in a publication is not enough to count as evidence of usage

Review Criteria

To pass review, the ontology developers must demonstrate external use. External use may be defined either as organizations not significantly overlapping in personnel with the developers or an independent group that use the ontology.

16   Collaboration

IOF ontology development, in coordination with many other standards-oriented activities, should be carried out in a collaborative fashion.

Purpose

The benefits of collaboration are threefold:

  1. Avoid duplication of work
  2. Increase interoperability; and
  3. Ensure that ontology content is both sound and meets community needs.

Recommendation

It is expected that IOF domain boards will collaborate in ensuring modularity of distinct ontologies, in re-using content from other ontologies in cross-product definitions where appropriate, and in establishing and evolving IOF principles to advance the IOF suite of ontologies to better serve users.

Where there are multiple ontology providers in a particular domain, they are encouraged to get together and determine how the domain may be subdivided between the ontologies, or whether the ontologies should be merged into a single artifact. Should it be determined that there is a competing ontology in the same domain, the IOF Domain Board should invite the developers of the external ontology to collaborate and strive to negotiate an arrangement that is beneficial to both projects.

Appendix 0 – IOF Annotation Properties and IRIs

 

The following are the annotations, their IRIs, and guidance for use in IOF ontologies.

General Guidance

  1. The intention of using annotations is to
    1. help a potential user decide if the ontology or a notion therein meets his or her needs and
    2. help a developer understand the ‘elements’ in the ontology and how to interpret them consistent with the intended interpretation of the IOF.
  1. Annotation Usage Conditions

The particular annotations that are required or used will depend on the representation language used. IOF ontologies are published using either OWL or Common Logic. As example, if using Common Logic the iof-av:firstOrderLogicDefinition annotation should not be used.

  1. Formal Definitions – A ‘formal definition’ is a statement or expression made using a formal language.
    1. A Formal Language can be considered as composed of symbols (aka the alphabet, aka signature), logical symbols (for conjunction, disjunction, implication, equivalence, and quantification), non-logical symbols, and a a set of rules for creating (well formed) statements/expressions in the language. In the case of OWL there are non-logical symbols for classes, object properties, and data properties and these non-logical symbols are usually natural language terms or phrases.
    2. For the IOF these formal languages include First Order Logic (FOL), Common Logic (CL), and OWL. Note that the last two are used for ontology development in the IOF.
    3. For classes, the only Formal statements or expressions in an IOF ontology are the OWL or Common Logic (class or relation) axioms and the First Order Logic Definition annotation (if using OWL).
    4. Note, in the case of a primitive or axiomatic notion there will be no (complete) necessary and sufficient formal definition or axioms.
    5. One point to bear in mind in the way the IOF is using formal languages is that the majority of the symbols used are not from the Greek alphabet nor single characters (usually) but are derived from natural language terms or phrases. This distinction must be kept in mind.
  1. There will be some notions (e.g. classes) that are taken as primitive or axiomatic. They will not have Formal definitions, but will have an Elucidation (using the iof-av:elucidation annotation) to explain the intended interpretation.
  1. Acronym Use

While acronyms and other abbreviations may be provided as annotations to elements in an IOF ontology, they must NOT BE USED as part of class or relation IRIs, identifiers, or labels, except where they have become the primary designator for a notion where the full ‘name’ is no longer commonly known or recognized. Examples include, LASER: Light Amplification by Stimulated Emission of Radiation; RADAR: RAdio Detection And Ranging; MODEM: Modulator-DEModulator; SCUBA: Self-Contained Underwater Breathing Apparatus; etc.

Annotation Properties

The following annotations apply to the elements (i.e. classes or relations) in a (published) IOF ontology.

  • Natural LanguageDefinition – iof-av:naturalLanguageDefinition
    • This annotation is Required for each non-primitive or non-axiomatic class of an IOF (OWL or Common Logic) ontology.
    • It is optional for primitive (aka axiomatic) classes since such the Elucidation annotation (iof-av:elucidation) is required and will satisfy the role of a natural language definition.
    • This annotation is optional, but recommended, for relations when the intent or interpretation of a relation may be misunderstood.
    • There should be at most one.
    • The natural language definition should be subject matter expert friendly and consistent with any formal definition or elucidation.
    • Natural language definitions should use class and relation names with following caveats:
      • Relations – For those relations whose label (i.e. local identifier) consist of multiple terms hyphenate the terms of the label: e.g. ‘hasPlan’ would be written as ‘has-plan’
      • Classes – For classes whose label has multiple distinct terms, e.g, ManufacturingOperationSpecification, separate the terms but bound them with apostrophe marks: ‘Manufacturing Operation Specification’.
  • First Order LogicDefinition – iof-av:firstOrderLogicDefinition
    • The First Order Logic Definition annotation is comprised of the (complete) necessary and sufficient conditions.
    • This annotation is Required for each non-primitive (aka non-axiomatic) class (i.e. unary relation) of a published IOF OWL ontology. This is the most authoritative and comprehensive definition of an IOF element.
    • IOF Common Logic ontologies do not require this annotation, but if included it must be logically equivalent to the Common Logic definition.
    • A primitive (aka axiomatic) term will not have a First Order Logic definition in either an OWL or Common Logic IOF ontology.
    • There should be at most one First Order Logic definition.
    • The specific symbols to be used for existential and universal quantification along with those for conjunction, disjunction, negation, conditional (i.e. if-then), and equivalence will be those commonly used in the mathematical formulas and statement.
      • Conjunction – ∧; Disjunction – ∨; Negation – ¬; Existential Quantification – ∃; Universal Quantification – ∀; Conditional – →; Equivalence – ↔; Left/Right Parentheses – (,); Left/Right Brackets – {,}.
    • An example of a First Order Logic definition for ‘Product’ might be (again bearing in mind the natural language terms appearing should be regarded as symbols in the IOF signature):
      • Continuant(x) ∧ ¬(SpecificallyDependentContinuant(x) ∨ Person(x) ∨ Organization(x)) ∧ ∃r (ProductRole(r) ∧ hasRole(x, r))
  • Semi-Formal Natural LanguageDefinition – iof-av:semi-formalNaturalLanguageDefinition
    • This annotation is Required if an element in an IOF OWL ontology has a First Order Logic definition or where the element is defined using Common Logic (i.e. in a Common Logic ontology).
    • The intent of this annotation to provide a transition or bridge from the First Order Logic definition of a element to the natural language definition. This definition is intended to help a user understand the intended interpretation of the element.
    • As example, using the First Order Logic definition of ‘Product’ above, a semi-formal translation of that might be:
      • Product =def. Continuant that is not a Person and not an Organization and not a Specifically Dependent Continuant and there is a Product Role that the thing bears.
  • Elucidation (aka explanation) – iof-av:elucidation
    • This annotation is Required for primitive/axiomatic class notions.
    • It is intended to provide guidance or explain (in a natural language style) how to interpret the notion.
    • It is used for terms without formal logical definitions of Necessary and Sufficient conditions.
    • The format should include no CamelCase, capitalization, or periods (i.e. do not use common grammar)
    • The annotation should be used in cases where the complete necessary and sufficient conditions have yet to be determined. As example, in the case of a sub-class at least one necessary condition can be described (e.g. the super or parent class).
    • Example: From the BFO 2.0 Specification document of 2015, the elucidation of the primitive notion ‘Continuant’:
      • “A continuant is an entity that persists, endures, or continues to exist through time while maintaining its identity.”
  • BFO Location – iof-av:relationToBasicFormalOntologyElement
    • IOF Ontologies are to be published in two versions. One which directly imports and uses the foundational ontology, BFO. And one which does not directly import BFO.
    • For those versions that do not directly import BFO an annotation must be included that represents the position or location of the class or relation in the BFO hierarchy.
    • The intent and goal of this annotation is to provide
      • a) a way for users to understand how the class or relation is related to BFO and thus help in understanding the distinctions made in its definition, and
      • b) a computer actionable representation to allow reconstruction of the position of the class or relation in the BFO taxonomy
    • Example: ‘Agent’ is a subclass of the BFO class ‘material entity’, which in turn is a subclass of the BFO class ‘independent continuant’, which in turn is a subclass of the BFO class ‘continuant’. So the position of ‘Agent’ is ‘material entity ← independent continuant ← continuant’.
  • External Documentation – rdfs:seeAlso
    • The information provide via annotations in an ontology should be concise and to the point.
    • Additional or extended explanations, history, decisions, rationale, etc. can be placed in an ontology’s External Documentation.
    • The External Documentation need not be elaborate. If using Github to publish an ontology is could be part of the Read.Me element. Or it could be a single document.
    • In most cases the content of this annotation may be a URL (e.g. the GitHub site of the ontology).
  • Source – dcterms:source
    • The intent is to provide a user with a reference for the element being annotated,
    • The ‘Source’ annotations would likely be used as an annotation on an annotation. For instance annotating a Natural Language definition annotation.
    • Direct Source – iof-av:directSource
      • The intent of this annotation is to provide the reference to the definitive source of any material used in the development of the element being annotated.
      • It can be a URL to a standard, common dictionary (e.g. Oxford), or similar reference.
    • Derived/Adapted Source – iof-av:adaptedFrom
      • The intent of this annotation is to provide a short description of where, or from what, the entity being annotated was adapted from.
  • Internal Label – rdfs:label
    • The de facto use of rdfs:label is to exactly reflect the local name of an element in an ontology (i.e. in OWL the final segment of the IRI after the #, the local name).
    • Example: If the IRI of a class was www.industrialontologies.org/core#ManufacturedProduct, the rdfs:label might be ‘Manufactured Product’
  • Example – skos:example
    • Use of this annotation is optional, but recommended if it will help a user understand the intended interpretation(s).
    • This annotation should use at most twice with/on a notion.
    • Additional examples or more elaborate examples should be placed in the External Documentation (using rdfs:seeAlso).
  • Comment – rdfs:comment
    • This annotation is optional
    • It use is not recommended. But if used, use it only once.
    • This is a catch-all annotation to account for extra information or other bits of useful data to help a user understand the intent of an element.
  • Synonym – Abbreviation, Acronym, Symbol
    • Synonym – iof-av:synonym
      • An alternate label that may help users discover the element.
    • Abbreviation – iof-av:abbreviation
      • An alternate short label for the element
    • Acronym – iof-av:acronym
      • A specialized abbreviation.
      • Use this annotation when there is a commonly accepted acronym
      • The intent is to support a weakly constrained notion of abbreviation that takes the form of a few concatenated letters extracted from the words in the label, regardless of whether the resulting abbreviation is spoken as a word or as a sequence of letters.
    • Symbol – iof-av:symbol
      • A terse designation (abbreviation) for the element.
      • Use this annotation when there is a standard symbol for the element: e.g. chemicals, units of measure, etc.

The following annotations apply to an entire (published) IOF ontology and not to individual elements of the ontology (e.g. at the top of the file).

  • Copyright – iof-av:copyright
    • Required for an IOF ontology.
  • License – dcterms:license
    • Required for an IOF ontology.
  • Version – owl:versionInfo
    • The version information applies to the entire ontology.
    • The exact format or strategy for formatting has yet to be decided. But at least the month and year of publication should be included.
    • Additional details about a version of an (entire) ontology can be kept in the External Documentation.
    • If a Working Group deems it useful to provide version information per notion, such information can be provided in the External Documentation.