/
Modelling Policy and Pattern: Internationalized Resource Identifier (IRI) Structure, Format, and Ontology Naming Conventions

Modelling Policy and Pattern: Internationalized Resource Identifier (IRI) Structure, Format, and Ontology Naming Conventions

Owned by Elisa Kendall
Nov 20, 2024
7 min read

Overview

Namespaces provide the mechanism for grouping objects in a domain. Examples include

  • file systems, which organize files and provide a means of assigning names to those files

  • networks and data distribution schemes, which organize resources and allow naming of those resources according to some protocol

The Semantic Web leverages the web architecture to provide conventions for namespaces and naming via internationalized resource identifiers (IRIs).  An ontology IRI represents the base namespace (identifier) shared by all resources in a vocabulary or ontology.

The IRI structure for ontologies developed for all EDM Council Innovation Laboratory projects follows recommendations provided in a number of W3C and IETF documents, including but not limited to:

The approach described below recommends the use of both a versioned and not-versioned form of the IRI, each of which are also Uniform Resource Locators (URLs) for the ontology. The non-versioned form of the ontology IRI will always resolve to the latest released version of an ontology, vocabulary, or other resource once that resource has been published, i.e., acting as a non-versioned URL. The versioned form of the IRI will always resolve to the specific version of the ontology published at the URL corresponding to the version IRI. For the IRI syntax, please refer to RFC 3987 from The Internet Engineering Task Force (IETF). The EDM Council infrastructure publishes the ontologies at both the versioned and non-versioned URLs, with content negotiations resolving the latest version of any ontology to the non-versioned URL, as stated above, while retaining every released version of each ontology at its versioned URL.  This approach allows our user community to migrate to a later version when it makes sense for them. It minimizes confusion and provides a clear history for users.  It also ensures that applications don't break when we publish a new version. 

This document provides the normative requirements for all IRIs minted for any EDM Council project for consistency, reusability, and maintenance over time. An English language class and property naming scheme was selected after considering a non-human readable, numerical identity scheme (such as the scheme used by ontologies that are published by the OBO Foundry) to facilitate the use of the ontologies by tools such as UML tools that support diagramming, documentation, and development of related artifacts, and, more importantly, for understanding by non-ontologist users. The following sections define the rules for constructing the IRI and version IRI per OWL 2 specifications (reference below).

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.

Protocol and Authority

All EDM Council IRIs, regardless of the project, MUST be resolvable and refer to a resource that can be retrieved from the internet. For GitHub-based work in progress and internal infrastructure process to work properly, the form of the IRI MUST specify the protocol as HTTPS and the authority MUST be a domain administered and owned by the EDM Council for conformance with the governance infrastructure for the project. The authoritative (and default) IRI for ontologies developed for any of our projects MUST use a single, normative authority, namely spec.edmcouncil.org. Use of another authority is possible depending on the project and requirements of its participants.

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. A slash-style IRI facilitates server-side processing, which is needed for many of the projects we support.

IRI Path Root

The IRI Path Root is project-specific, and must be determined by the governance team for any project. For example, for FIBO the IRI path root MUST be /fibo/. The Root provides the ability to have documentation and other supporting resources referenced in alternate Root resources, such as /fibo/documentation or /fibo/src. The relevant project governance team MUST designate each root resource for a specified use.  This includes the path root for other published versions of any ontology, such as a SKOS vocabulary, which might be published at /fibo/vocabulary, for example, rather than /fibo/ontology, to avoid punning.

Subject Area

It is likely that a number of focus areas will emerge from the body of work produced by any EDM Council ontology project.  Such topics may range from standards-specific, to use case specific, to other domain areas that form natural divisions for relevant subject matter.  A subject area represents a domain or area of interest addressed by one or more working groups, and enables further subject-specific organization of sub-topics and modules. Guidelines for establishing high-level subject areas and for organizing sub-topics and ontologies may emerge over time. Currently, the governance infrastructure assumes that the names of subject areas are UPPER CASE alphabetic strings not longer than 6 characters. For the initial phase of the project, goals included publishing ontologies that can be used well beyond the end of the project, thus the following topic areas are currently in use:

EXT - The ontologies managed under this subject area for any project represent extensions and examples that reuse the primary ontologies for that project. They include extensions to the core ontologies that are unlikely to be standardized as well as examples, some of which will be used for regression testing. These ontologies are the least stable and will continue to evolve over the course of the project. 

<PROJECT-SPECIFIC SUBJECT> – The ontologies managed under a top-level subject area represent primary domain areas for that project, such as FND, BE, DER, SEC, and the like for FIBO, and ISO for the IDMP project, or (2) a module (subset) of a given subject area, such as Debt, under the SEC domain area in FIBO. Coverage of most sub-domain areas can, although not necessarily will, ultimately include multiple ontologies, each of which will be managed under the relevant topic.

META - The ontologies managed under the META subject area support the inclusion of metadata that is project specific.

For example:

Note that the 'EXT', or 'extensions' partition will be where we include extensions that may extend other project ontologies required for use in examples as well as the examples themselves.

Ontology IRI and Version IRI

All EDM Council project ontologies MUST include a versioned and non-versioned IRI. The version IRI MUST use the release date of the version in YYYYMMDD form, such as 20241231 for December 31, 2024. When a versioned IRI is formed, the version (date) MUST appear following the subject area. The non-versioned IRI represents the latest version of the ontology and will dereference to the most current version when published by the EDM Council.

Ontology IRIs MUST follow a slash-style '/' rather than hash-style '#' structure as mentioned above. This approach facilitates server-side processing of content published to the URL corresponding to the ontology IRI as described in Best Practice Recipes for Publishing RDF Vocabularies , which we believe will be essential to a number of the use cases identified for any project.

Module (Sub-Topic, Optional)

When specified, a sub-topic MUST appear after the version (date) in a versioned IRI or after the subject area in a non-versioned IRI. For example, in FIBO/LOANS/, there are three sub-topics, LoansGeneral, LoansSpecific, and RealEstateLoans. There MAY be multiple sub-topics for any subject area. Sub-topics MAY include multiple ontologies. For example:

Ontology Naming and Ontology IRIs

An ontology is a set of related ontological classes, properties, and axioms encoded using a specific serialization format, such as RDF/XML, Turtle, or JSON-LD. 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 subject and sub-topic resource locations, in a non-versioned IRI, the ontology name MUST be given without extension as follows:

The ontology name MUST be in Upper Camel Case, each word capitalized with no separation between words, unless a given project governance team requests a delimiter, as shown in the IDMP-O case, above. All acronyms MUST be spelled out except when in the dictionary, like RADAR, or for those that are approved by the governance team.  The ontology name MUST NOT have any extensions in the IRI (e.g., <OntologyName>.owl). Subsequent parts of the IRI, such as class and property names, MUST be separated from the file name by a forward slash '/' and the IRI MUST end with a forward slash' /'.  owl:imports and rdf:resource references MUST use the IRI with a trailing '/'.

Care should be taken to limit the ontology name to fewer than 255 characters (including the names of the classes, properties, and nominals contained in those ontologies) to allow for implementation across the broadest number of technologies and approaches.

 

Related content