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).
...
The following rules MUST be followed when reviewing this document, these are taken from IETF https://datatracker.ietf.org/doc/html/rfc2119 :
...
(simplified):
MUST: This word , or the terms "REQUIRED" or "SHALL", mean means that the definition is an absolute requirement of the specification.
MUST NOT: This phrase , or the phrase "SHALL NOT", mean means that the definition is an absolute prohibition of the specification.
SHOULD: This word , or the adjective "RECOMMENDED", mean 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 , or the phrase "NOT RECOMMENDED" mean 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 , or the adjective "OPTIONAL", mean 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. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)
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 www.industrialontologies.org
is used for illustrative purposes only. When decided, this document MUST be revised with the normative authority.
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 www.industrialontologies.org
unless it is not possible due to technical reasons. Otherwise, the authority may begin with an alternative such as www.industrialontologies.org
or onto.industrialontologies.org
.
IRI Path Root
The root of the path portion of the IRI MUST be /ontology
. This provides the ability to have documentation and other supporting resources referenced in alternate root directories, such as /documentation
or /references
. The IOF MUST designate each root resource name for a specified use.
Topic Area
A topic represents a domain area of concern addressed by one or more working groups. The topic organizes sub-topics and modules. The IOF provides the ontology organization rules for topics, sub-topics, and modules in publication (reference to organization structure). 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 second portion of the IRI. The topic areas MUST be all lower case 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:
...
IOF ontologies MUST provide an IRI and version IRI in the OWL XML file. The version IRI MUST use the release date of the version in YYYYMMDD
form, such as 20210601
for June 1, 2021. When a versioned IRI is formed, the date MUST appear after the topic. In the following examples, the sub-topic area is given to illustrate the placement of the version (see next fort sub-topic). All sub-topics and modules within a topic MUST share a common version date and be released together.
The IRI MUST always reference the latest released version of the ontology.
...
When specified, a sub-topic MUST appear after the version date in a versioned IRI or after the topic in a non-versioned IRI. In this case, metadata associated with the supplychain
model ontology is placed in the meta
location. The sub-topic MUST be lowercase with no separation or punctuation between words.
...
A data property MUST be a verb phrase starting with has
and MUST end with Value
. Examples:
hasTag
hasTagValue
hasDateValue
Annotation properties
...
.../ontology/foundation/20210611/meta/AnnotationVocabulary/usageNote
.../ontology/foundation/20210611/meta/AnnotationVocabulary/adaptedFrom
...
Old notes for reference…
IRI Structural Rules in the following order
Authority:
www.industrialontologies.org
Top:
/ontology
Topic areas are lowercase with no punctuation or separation:
/supplychain
/foundation
Versioned IRI:
Release date after highest level topic area
Date format:
YYYYMMDD
/supplychain/20210601
/foundation/20210601/meta
File-name Upper Camel Case with no punctuation:
AnnotationVocabulary
Uppercase first letter of each word, no separation
All acronyms are spelled out
Exceptions like
RADAR
, words appearing in the dictionary
Class and properties separated from path with a
/
/ontology/foundation/meta/AnnotationVocabulary/usageNote
Class name Upper Camel Case:
Uppercase first letter of each word, no separation
All acronyms are spelled out
Exceptions like
RADAR
, words appearing in the dictionary
Object property Lower Camel Case:
Lowercase first letter, uppercase each following word
All property names MUST be verb or verb phrase
hasParticipant
Data properties and annotation names Lower Camel Case
Lowercase first letter, uppercase each following word
Verb phrase starting with
has
hasTag
hasDateValue
Annotation properties
Lowercase first letter, uppercase each following word
usageNote
adaptedFrom
Versioned and unversioned forms MUST be provided.
Examples
Unversioned:
/ontology/foundation/meta/AnnotationVocabulary/usageNote
Versioned:
/ontology/foundation/20210601/meta/AnnotationVocabulary/usageNote
/ontology/supplychain/
...