Version History

Contents

Terms from Standards Used in this Document

• construct: refers to an OWL class, object property, or data property

• expanded name: An expanded name is a pair consisting of a namespace name and a local name. [https://www.w3.org/TR/xml-names/ ]

  • namespace name: For a name N in a namespace identified by a URI I, the namespace name is I. For a name N that is not in a namespace, the namespace name has no value. [https://www.w3.org/TR/xml-names/ ]

  • local name: In either case the local name is N. [https://www.w3.org/TR/xml-names/ ]

    • The last portion of the IRI that identifies the ontology, construct, annotation, or individual

Overview

This document outlines the normative requirements for all IRIs created in the IOF, ensuring consistency and usability.

In the IOF, every OWL ontology, construct, annotation property, or individual is identified by an IRI. The IRI for a construct, annotation, or individual does not use the base IRI (namespace) of the ontology that defines it, resulting in IRIs in IOF OWL documents differing from those for constructs and other resources defined within those documents.

These differences decouple the organization of IOF domain and ontologies from the signifiers associated with the constructs and other resources within them, allowing for changes and evolution of content organization without impacting code referencing IOF constructs. The rules specified in this document require the value of the annotation property, rdfs:isDefinedBy, to provide the associated ontology of the construct, annotation, or individual. In addition, the rules require annotations that track and document each change to the associated ontology.

An English language class and property naming scheme were selected after considering a numerical identifier scheme to facilitate the use of the ontologies. The following sections define the rules for constructing the IRI and version IRI in accordance with OWL 2 specifications (reference below).

The IRI for the ontologies provides a versioned and non-versioned form. The latter form will always refer to the latest released version of the documents. For the IRI syntax, please refer to RFC 3987 from The Internet Engineering Task Force (IETF).

The following rules MUST be followed when reviewing this document. These rules 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.

Rules

The IOF ontologies adhere to the following rules on IRI management and assignment. These rules are designed to minimize deprecation of constructs in the IOF ontologies and allow for relocation of constructs to other ontologies when necessary. As domain ontologies mature, constructs are migrated to common cross-domain ontologies. The IOF aims to reduce the burden of moving constructs between different ontologies for both users of the ontologies and the IOF.

The IOF collaborates with other organizations that will contribute constructs to the ontologies. The collaborator’s ontology may have general constructs that MAY be moved to common, cross-domain ontologies in the IOF.

These rules apply to IOF ontologies, and end-users MAY use their own best practices.

Rules for Construct and Annotation IRIs

• All construct IRIs MUST use the following structure:

  • Base IRI for all constructs: https://spec.industrialontologies.org/ontology/construct/

  • https://spec.industrialontologies.org/ontology/construct/<Construct Name>

• All annotation IRIs MUST have the following structure:

  • Base IRI for all annotations: https://spec.industrialontologies.org/ontology/annotation/

  • https://spec.industrialontologies.org/ontology/annotation/<Annotation Name>

• All individual IRIs MUST have the following structure:

  • Base IRI for individuals: https://spec.industrialontologies.org/ontology/individual/

  • https://spec.industrialontologies.org/ontology/individual/<Individual Name>

• Every construct MUST be defined, along with its axioms, in one ontology.

  • Exception: We MAY need to add axioms to external ontologies where an extension is required. Example: Capability was inserted between BFO disposition and BFO function, necessitating the additional subClassOf: Capability axiom for the BFO class function.

• Every construct local name MUST be unique across all IOF ontologies.

• Every construct rdfs:label MUST be unique for each localized language.

• Every annotation property MUST only be defined, along with its natural language definition, in one ontology

• Every annotation property local name MUST be unique across all IOF ontologies.

• Every annotation property rdfs:label MUST be unique for each localized language.

• Every construct or annotation MUST have an annotation rdfs:isDefinedBy to indicate the module in which the construct is defined.

  • rdfs:isDefinedBy is an instance of rdf:Property that is used to indicate a resource defining the subject resource.

  • Rationale: as constructs change ontologies or modules, the annotation indicates in which ontology the construct is curated.

  • For example, for the Validator construct in the biopharama Agent module.

    <owl:Class rdf:about="https://spec.industrialontologies.org/ontology/construct/Validator"> <rdfs:isDefinedBy rdf:resource="https://spec.industrialontologies.org/ontology/biopharma/Agent/"/> ... </owl:Class>

• Rules for moving constructs to another ontology or module

  • Every construct MUST be independent of any module beyond the destination module and its imports

  • If a construct is generalized to a higher-level ontology, the axioms MAY be weakened for the general case, and the domain-specific axioms may be associated with a new domain-specific term.

  • It MUST have an iof-av:wasDefinedBy annotation added that indicates the previous ontology it was defined in.

    • For example:

    • The Validator construct is moved from the /biopharma/Agent/ to the /core/Core ontology, as it is a general term used throughout IOF. It has finally been moved to a more specific /agent/Agent/ ontology for all constructs related to Agents.

      <owl:Class rdf:about="https://spec.industrialontologies.org/ontology/constuct/Validator"> <rdfs:isDefinedBy>https://spec.industrialontologies.org/ontologies/agent/Agent/</rdfs:isDefinedBy> <iof-av:wasDefinedBy> <rdf:Description> <iof-av:wasMovedFrom>https://spec.industrialontologies.org/ontology/biopharma/Agent/</wasMovedFrom> <iof-av:wasMovedOn rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2025-07-25T00:00:00Z</wasMovedOn> </rdf:Description> </iof-av:wasDefinedBy> <iof-av:wasDefinedBy> <rdf:Description> <iof-av:wasMovedFrom>https://spec.industrialontologies.org/ontology/core/Core/</wasMovedFrom> <iof-av:wasMovedOn rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2025-08-21T17:00:00Z</wasMovedOn> </rdf:Description> </iof-av:wasDefinedBy> ... </owl:Class>

      iof-av:wasDefinedBy MUST have two parts:

      • iof-av:wasMovedFrom specifying the previous ontology IRI that the construct was located in.

      • iof-av:wasMovedOn specifying the date and time the change occurred.

      • The changes are

    • The previous ontology MUST have a skos:changeNote indicating the constructs that were moved and their new location.

Rules for Collaborative Domain Ontologies

The IOF collaborates with other organizations whose ontologies are part of the greater IOF ontology offering. These ontologies will adhere to the same rules and IRI requirements for constructs, annotation properties, and individuals as the IOF ontologies. They MUST also have the following additional constraints on IRIs identifying OWL ontologies and their versions:

• For collaborative ontologies, the ontologies MUST be maintained in a domain representing the collaborative organization:

  • Example: https://spec.industrialontologies.org/ontology/biopharma/Recipe/

• The constructs in the ontologies MUST remain in the IOF construct namespace:

  • Example: https://spec.industrialontologies.org/ontology/construct/GeneralRecipe/

• The releases of a collaborative domain MUST be released in a separate release branch

  • The branch will have maturity of Released

  • The branch must have the suffix: -main

    • For example: biopharma-main

  • The Release IRI MUST be set to the next release in the sequence for the year:

    • For example, release IRI version: 202501

      • https://spec.industrialontologies.org/ontology/202501/biopharma/Recipe/

IRI Structure

Protocol and Authority

All IOF IRIs MUST be resolvable and refer to a resource that can be retrieved from the internet. The form of the IRI MUST specify the protocol as HTTPS and the authority MUST be a domain administered and owned by the IOF or its parent organization. The IOF MUST choose a single authority for all ontologies released by the IOF.

• For the given IRI: https://spec.industrialontologies.org/ontology/supplychain

• The protocol: https

• The authority: spec.industrialontologies.org

The authority MUST be a domain administered and owned by the IOF or its parent organization. The IOF MUST choose a single authority for all ontologies released by the IOF. The authority MUST be spec.industrialontologies.org unless it is not possible due to technical reasons.

IRI Path

In accordance with IETF RFC 3987, the Path component of the IRI MUST immediately follow the authority starting with a forward-slash (/), and the Path parts MUST be separated by forward-slashes (/). The first part of the Path is referred to as the Path Root.

• For the given IRI: https://spec.industrialontologies.org/ontology/supplychain

• The path component: /ontology/supplychain

IRI Path Root

The IRI Path Root MUST be /ontology. The Root provides the ability to have documentation and other supporting resources referenced in alternate Root resources, such as /documentation or /references. The IOF MUST designate each root resource for a specified use.

• For the given IRI: https://spec.industrialontologies.org/ontology/supplychain

• The root part: /ontology

Domain

The domain and subdomains of the IRI MUST only be present in the ontology IRI. The construct, annotation, and individual IRIs MUST not contain the specific domains.

A domain is an area of concern addressed by one or more working groups. The domain organizes sub-domains and modules. The IOF will provide the ontology organization rules for domains, sub-domains, and ontologies in a future publication. All content within a domain MUST be released with a common version. The version of one domain does not constrain another domain’s version.

The domain areas MUST form the path part of the IRI. The domain areas MUST be all lowercase with no separation or punctuation between words. All acronyms MUST be spelled out, except for words defined in the dictionary like radar (RADAR) always given in lowercase. The following are examples of domain areas:

• https://spec.industrialontologies.org/ontology/supplychain

• https://spec.industrialontologies.org/ontology/foundation

• https://spec.industrialontologies.org/ontology/productionprocess

IRI and Version IRI

Every IOF ontology MUST provide a non-version IRI (referred to as the IRI) and version IRI in the RDF/XML serialized OWL file.

Development and release version IRIs differ where development ontologies are stamped using a year, month, and day (date version) as opposed to the release version IRIs composed of a year and an increasing number (numeric version). All ontologies released together MUST have the same year and number.

Public Release IRI

Every publicly released version IRI MUST use a numeric version formed with the release year and a monotonically increasing number NN in YYYYNN form, such as 202202 for the second release in 2022. If the IOF releases every quarter, NN represents the quarter when the ontology was released. When a versioned IRI is formed, the version MUST appear before the domain. All IOF ontologies that are part of a release MUST share a common version.

This version IRI will be automatically changed during the release and publication process. The version IRI in GitHub will not be changed by the publication process.

The non-versioned IRI MUST always reference the latest released version of the ontology.

• Versioned IRI: https://spec.industrialontologies.org/ontology/202202/supplychain/meta

• Non-Versioned IRI: https://spec.industrialontologies.org/ontology/supplychain/meta

OWL IRI Specification

The IRI specification is given in OWL 2 Web Ontology Language, Section 3.1 standard as follows:

Each ontology may have an ontology IRI, which is used to identify an ontology. If an ontology has an ontology IRI, the ontology may additionally have a version IRI, which is used to identify the version of the ontology. The version IRI may be, but need not be, equal to the ontology IRI. An ontology without an ontology IRI MUST NOT contain a version IRI.

Sub-Domain (Optional)

The sub-domain MUST immediately follow its parent domain in the IRI. For example, metadata associated with the supplychain ontology is placed under the meta sub-domain. There MAY be multiple sub-domains for any domain. The sub-domain MUST be lowercase with no separation or punctuation between words. Each sub-domain MAY have multiple ontologies.

The meta sub-domain area MUST be used for ontologies consisting solely of annotation properties. For example:

• IRI: https://spec.industrialontologies.org/ontology/core/meta/AnnotationVocabulary/

• Version IRI: https://spec.industrialontologies.org/ontology/20210601/core/meta/AnnotationVocabulary/

Ontology

Every ontology is a set of related ontological classes, properties, and axioms encoded in a specific representation, such as RDF/XML, Turtle, or CLIF. A given HTTP server delivers an ontology in a serialization using the HTTP/1.1 Accept header of the request. See Section 14 of IETF RFC 2616. The serialized representation is referred to as an ontology file.

Following the domain and sub-domain resource locations, the ontology name MUST be given without extension as follows:

• https://spec.industrialontologies.org/ontology/core/meta/AnnotationVocabulary/

• https://spec.industrialontologies.org/ontology/core/domainindependent/Stasis/

  • The Stasis ontology of the domainindependent sub-domain of the core domain

The ontology name MUST be in Upper Camel Case, each word capitalized with no separation between words. All acronyms MUST be spelled out except when in the dictionary, like RADAR.

The ontology name MUST NOT have any extensions in the IRI, and it MUST end with a forward slash (/). owl:imports rdf:resource reference MUST use the IRI ending with a forward slash ( /).

• <owl:imports rdf:resource="https://spec.industrialontologies.org/ontology/core/domainindependent/Stasis/"/>

Class IRI Structure

Every class local name MUST be given in Upper Camel Case, each word capitalized, and no separation or punctuation between words. As with the module names, acronyms MUST NOT occur, except those in the dictionary, such as RADAR.

• .../ontology/construct/SupplyChainShippingProcess

Property (Relation) IRI Structure

Property Capitalization Rule

The Property Capitalization Rule applies to object, data, and annotation properties.

Every property local name MUST be in lower Camel Case, the first letter of the first word MUST be lower case and the first letter of each subsequent word MUST be capitalized, with no separation or punctuation between words.

• .../ontology/construct/hasCapability

Object Property Naming Rules

Every object property local name MUST be a verb or a verb phrase. For example:

• hasParticipant

• participatesIn

Data Property Naming Rules

Every data property MUST be a verb phrase starting with is for boolean (true/false) or has for any other data type. The data property SHOULD end with Value unless it is a boolean.

Examples:

• hasTagValue

• hasDateValue

• isTransferable

Annotation Property Naming

Every IOF annotation property must follow property capitalization rules and MUST be defined in the meta sub-domain area. There are no additional constraints on the annotation names at present.

• .../ontology/core/meta/AnnotationVocabulary/

Every annotation property will use the path designation annotation as the context for all IOF annotations:

• .../ontology/annotation/usageNote

Individual IRI Structure

Every individual local name MUST be given in Upper Camel Case, the first letter of each word capitalized, and no separation or punctuation between words. As with the module names, an acronyms MUST NOT occur except those in the dictionary, such as RADAR.

• .../ontology/individual/Released

• .../ontology/individual/Maturity

Addenda

Addenda consists of non-normative content release as part of the ontologies that MAY be used at the user's discretion. IOF MUST place rules, property chains, and shape constraints in the addenda directory.

• Rules MUST be in a subdirectory called addenda under the related ontology directory in the IRI.

  • Examples:

    • /ontology/core/addenda/swrl/CoreRules

    • /ontology/core/temporal/addenda/swrl/AllensTemporalRules

    • /ontology/core/addenda/shacl/CoreShapes

    • /ontology/core/addenda/propertychain/CorePropertyChains

• The following naming rules MUST be used for the following artifacts:

  • .../addenda/swrl/ : the directory swrl MUST be used for all SWRL (Semantic Web Rule Language) files

  • .../addenda/shacl/ : the directory shacl MUST be used for all SHACL (Shape Constraint Language) files

  • .../addenda/propertychain/ : the directory propertychain MUST be used for all files containing property chains