IOF Ontology Naming Rules 1.0

IOF Ontology Naming Rules 1.0

Version History

Version

Date

Comment

Lead Author

Contributors

Version

Date

Comment

Lead Author

Contributors

1

 Mar 14, 2026

Copied from https://oagi.atlassian.net/wiki/x/AYAPawE

@William Sobel

@Jim Logan @Milos Drobnjakovic @tschneider @Evan Wallace

Glossary

  • Ontology: Constructs and annotations related to a particular domain or sub-domain

  • Ontology-IRI: The fully resolvable reference to the ontology that, when requested, will retrieve the file containing the ontology.

    • Therefore, to make Ontology-IRIs resolvable, the domain path and file name must match the domain and the ontology name.

  • Module: May be used as a synonym for a file or an ontology. Not used in this document.

  • Ontology Name: the final segment of an Ontology-IRI that denotes an ontology, without a path or suffix.

  • Ontology File Base Name: The ontology name of the ontology without the domain path and does not include the content-type suffix (.rdf).

  • Ontology File Name: The Ontology File Base Name with the content-type extension (.rdf)

Overview and Rationale

IOF working groups require rules when creating and maintaining ontologies. In the IOF, the ontology file base name MUST match the ontology name so that the ontology file's contents can be retrieved from the internet using the IRI. Otherwise, the mapping of an Ontology-IRI to an ontology file becomes very complex and confusing.

These rules provide patterns and processes to help the IOF maintain a consistent set of ontologies that are less likely to require changes over time. Having stable names makes it easier for users to rely on ontology imports, which is a key usability requirement.

The IOF has decided that all ontology names must be unique across all domains. The rationales for using unique names are as follows:

  • Supporting downloading ontologies into a common directory

  • Importing them into ontology databases without name conflicts.

  • Reducing confusion about core vs. domain-specific extended ontologies.

To support unique naming, all non-core ontologies MUST prefix the names of their ontologies that do not match the domain name with the domain name. For example, supplychain/SupplyChain/ is allowed because “supplychain” matches “SupplyChain” (case insensitive), but supplychain/Agent is not allowed. The ontology name must be prefixed as supplychain/SupplyChainAgent/, and the ontology file name must be supplychain/SupplyChainAgent.rdf The only place the Agent ontology name is allowed without a prefix is in the core domain: core/Agent/ and core/Agent.rdf respectively.

An ontology name may be approved by the TOB as unprefixed if the TOB agrees that the name is specific to the domain. This allows ontologies to be developed in other domains, whether cross-domain and destined to be moved to the core domain, or specific to a single domain. Regardless, they MUST have a unique name and be approved by the TOB.

The following section details the rules.

See: Proposed: IOF Ontology Creation and Refactoring Policy (Informative) for a more detailed discussion of Ontology Creation, policies, and procedures.

Rules for Ontology Naming

  • All ontologies' ontology names MUST be unique, even when other exceptions apply.

  • An ontology name MUST NOT contain conjunctions like And or Or unless the TOB votes to approve.

    • Unless the associated conjoined concerns or domains have cyclic references and are inseparable and should be approved by the TOB. For example: MonitoringAndControl.

  • An ontology name MUST NOT be in plural form unless the TOB votes to approve.

    • This rule ensures consistent naming across all our ontologies.

  • An ontology file base name MUST match the ontology name given in the non-versioned Ontology-IRI.

    • This allows for resolvable Ontology-IRIs.

    • The directory structure MUST match the Ontology-IRI structure in the reference repository.

  • All ontology names MUST be unique across all domains.

    • This requirement implies that all ontology file names MUST be unique.

  • The core domain:

    • Core ontologies MUST be named without a domain prefix.

      • Example: core/Agent/ would not be core/CoreAgent/

  • Other domains: (For released ontologies):

    • When the ontology name is not the same as the domain name:

      • The ontology name MUST be prefixed with the domain name

        • Example: Equipment ontology in the biopharma domain MUST be prefixed as follows: /biopharma/BiopharmaEquipment

      • Exception: An ontology name MAY remain unprefixed if the IOF TOB approves the ontology name:

        • Example biopharma/Recipe

        • The working group is responsible for this ontology, as it resides in their field of expertise

      • Exception: For provisional ontologies:

        • Ontologies MAY not be prefixed upon introduction by the Working Group.

        • Names MAY be singular or plural as prescribed by the Working Group.

    • When the ontology name is the same as the domain name, the name MUST not be prefixed:

      • maintenance/Maintenance must not be prefixed by Maintenance

Member

Vote

Comments

Member

Vote

Comments

1

@tschneider

Yes

 

2

@Evan Wallace

Yes

the Architecture group should revisit the pattern for using MUST and SHOULD. It would be clearer to users and more consistent with our definitions in the Annotation Guide for MUST, SHOULD and MAY, if we either used SHOULD for cases with known exceptions to the rule or included the exception as part of any rule statement including MUST.

IOF Annotation Property Guide 2.5: https://oagi.atlassian.net/wiki/x/AYBZOwE

3

@Serm Kulvatunyou

 

 

4

@Elisa Kendall

Yes

Same comment as Evan

5

@Barry Smith

Yes

 

6

@Jim Logan

Yes

 

7

@Milos Drobnjakovic (Unlicensed)

Yes

 

8

@Farhad Ameri (Unlicensed)

 

 

9

@Ana Correia

 

 

10

@Dusan Sormaz

Yes

 

11

@William Sobel

Yes

 

12

@Melinda Hodkiewicz

Yes

 

13

@Alexandru Todor

 

 

14

@Arkopaul Sarkar (Arko)

Yes

 

15

@Hyunwoong Ko

 

 

16

@Ana Nikolov

Yes

 

17

@Stephen Granite

 

 

18

Total

YES: 11, NO: 0, No Response: 6