IRI Structure and Format V2.2
Version History
Version | Date | Comment | Lead Editor | Contributors |
---|---|---|---|---|
1 | 2021-06-18 | First version | @William Sobel | @Evan Wallace @tschneider @Farhad Ameri @Chris Will @Elisa Kendall @Ana Correia @Serm Kulvatunyou |
2 | 2022-10 | Updated authority from purl to spec and changed version IRI to YYYYNN. | @William Sobel | @Evan Wallace @tschneider @Jim Logan @Barry Smith (Unlicensed) @Arkopaul Sarkar @Farhad Ameri @Chris Will @Stephen Kahmann @Elisa Kendall @Ana Correia @Serm Kulvatunyou @Milos Drobnjakovic @Pawel Garbacz @Melissa Weller |
2.1 | 2022-11 | Moved the version number to occur before the topic. Removed development IRI. | @William Sobel | @Evan Wallace @tschneider @Jim Logan @Barry Smith (Unlicensed) @Arkopaul Sarkar @Farhad Ameri @Chris Will @Stephen Kahmann @Elisa Kendall @Ana Correia @Serm Kulvatunyou @Milos Drobnjakovic @Pawel Garbacz @Melissa Weller |
2.2 | 2023-02 | Minor fixes: Removed struck out development IRI section. | @William Sobel |
|
Contents
- 1 Version History
- 2 Contents
- 3 Overview
- 3.1 Protocol and Authority
- 3.2 IRI Path
- 3.3 IRI Path Root
- 3.4 Topic Area
- 3.5 IRI and Version IRI
- 3.5.1 Public Release IRI
- 3.5.2 OWL IRI Specification
- 3.6 Sub-Topic (Optional)
- 3.7 Ontology
- 3.8 Class Names
- 3.9 Property Names (Relations)
- 3.9.1 Object Properties
- 3.9.2 Data Properties
- 3.9.3 Annotation properties
- 4 Appendix
- 4.1 Votes
Overview
The IRI structure of the IOF references the OWL documents providing a versioned and not-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).
This document provides the normative requirements for all IRIs created in the IOF for consistency and usability. An English language class and property naming scheme was selected after considering a numerical identity scheme to facilitate the use of the ontologies. 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):
MUST: This word means that the definition is an absolute requirement of the specification.
MUST NOT: This phrase means that the definition is an absolute prohibition of the specification.
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.
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.
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 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. The authority spec.industrialontologies.org
is used for illustrative purposes only. When decided, this document MUST be revised with the normative authority.
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
Topic Area
A topic represents a domain or area of concern addressed by one or more working groups. The topic organizes sub-topics and modules. The IOF will provide the ontology organization rules for topics, sub-topics, and ontologies in a future publication. All content within a topic MUST be released with a common version. The version of one topic does not constrain another topic’s version.
The topic areas MUST form the path part of the IRI. The topic 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 topic areas:
https://spec.industrialontologies.org/ontology/supplychain
https://spec.industrialontologies.org/ontology/foundation
https://spec.industrialontologies.org/ontology/productionprocess
IRI and Version IRI
IOF ontologies 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
The 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 topic. 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-Topic (Optional)
When specified, a sub-topic MUST appear after the version date in a versioned IRI or after the topic in a non-versioned IRI. For example, metadata associated with the supplychain
ontology is placed under the smeta
sub-topic. There MAY be multiple sub-topics for any topic. The sub-topic MUST be lowercase with no separation or punctuation between words. Sub-topics MAY have multiple ontologies.
The meta
sub-topic area MUST be used for ontologies consisting solely of annotations properties. For example:
IRI:
https://spec.industrialontologies.org/ontology/core/meta/AnnotationVocabulary/
Version IRI:
https://spec.industrialontologies.org/ontology/20210601/core/meta/AnnotationVocabulary/
Ontology
An 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 topic and sub-topic 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 thedomainindependent
sub-topic of thecore
topic
https://spec.industrialontologies.org/ontology/core/domainindependent/Stasis/Stasis
Class
Stasis
in theStasis
ontology of thedomainindependent
sub-topic of thecore
topic.
https://spec.industrialontologies.org/ontology/core/domainindependent/Stasis/triggers
Object property
triggers
in theStasis
ontology of the domain-independent sub-topic of the core topic.
https://spec.industrialontologies.org/ontology/supplychain/SupplyChainReferenceOntology/SupplyChainShippingProcess
Class
SupplyChainShippingProcess
of theSupplyChainReferenceOntology
ontology of thesupplychain
topic.
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. The following parts of the IRI, 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
rdf:resource
reference MUST use the IRI with a trailing /
.
<owl:imports rdf:resource="<https://spec.industrialontologies.org/ontology/core/domainindependent/Stasis/>"/>
Class Names
Class names MUST be given in Upper Camel Case, each word capitalized, and no separation or punctuation between words. As with the module names, no acronyms MUST NOT occur except those in the dictionary, such as RADAR.
/ontology/supplychain/SupplyChainReferenceOntology/SupplyChainShippingProcess
The versioned forms are as follows:
/ontology/202106/supplychain/SupplyChainReferenceOntology/SupplyChainShippingProcess
Property Names (Relations)
All property names MUST be in lower Camel Case, the first word lower case and each subsequent word capitalized with no separation or punctuation between words.
/ontology/foundation/meta/AnnotationVocabulary/usageNote
The versioned forms are as follows:
/ontology/202106/foundation/meta/AnnotationVocabulary/usageNote
Object Properties
All object property names MUST be verbs or a verb phrase. For example:
hasParticipant
participatesIn
Data Properties
A 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
.
Examples:
hasTagValue
hasDateValue
isTransferable
Annotation properties
Must follow property capitalization rules and MUST be placed in the meta
sub-topic area, as follows.
.../ontology/202106/foundation/meta/AnnotationVocabulary/usageNote
.../ontology/202106/foundation/meta/AnnotationVocabulary/adaptedFrom
Appendix
Votes
Member | Vote |
| |
---|---|---|---|
1 | @William Sobel | YES |
|
2 | @Farhad Ameri | YES |
|
3 | @Elisa Kendall | YES |
|
4 | @Chris Will | YES |
|
5 | @Dusan Sormaz | YES |
|
6 | Walter Terkaj |
|
|
7 | @Melinda Hodkiewicz | YES |
|
8 | @Rebecca Siafaka |
|
|
9 | @Dimitris Kiritsis | YES |
|
10 | @Serm Kulvatunyou | YES |
|
11 | @Evan Wallace | YES |
|
12 | @Hedi Karray | YES |
|
13 | Hyunmin Cheong |
|
|
14 | @Jinzhi Lu | YES |
|
15 | @Ana Correia | YES |
|
16 | @tschneider | YES | With reservations:
|
17 | @Peter Denno | YES |
|
18 | @Alexandru Todor |
|
|
19 | Thomas Hanke |
|
|
20 | Total |
| YES: 14, NO: 0, No Response: 5 |