Version History
...
construct: refers to an OWL class, object property, or data property
OWL Referenceentity (object): item that is perceivable or conceivable
Note 1 to entry: The terms ‘entity’ and ‘object’ are catch-all terms analogous to ‘something’. In terminology circles
[ISO/IEC 21838-1:2021(E)]particular: individual entity
Note 1 to entry: In contrast to classes or types, particulars are not exemplified or instantiated by further entities
Note 2 to entry: only relevant to first-order logic
[ISO/IEC 21838-1:2021(E)]instance: particular that instantiates some universal
Note 1 to entry: two types of particular, one XX is an instance of a universal and the other is not
Note 2 to entry: only relevant to first-order logic
[ISO/IEC 21838-1:2021(E)]individual: instance of an OWL class
OWL Referenceprimitive: expression for which no non-circular definition can be provided
Note 1 to entry: construct lacking necessary or sufficient conditions
[ISO 21838-2:2021 (E)]
Note 2 to entry: definition refers to a first-order logic definition or OWL definitionuniversal: item that is perceivable or conceivable that has indefinitely many instances
Note 1 to entry: only relevant to first-order logic
[ISO 21838-2:2021 (E)]axiom: statement that is asserted as true but which is not derivable from other statements
Note 1 to entry: Axioms may be formulated as natural language sentences or as formulae in a formal language. In the OWL community, ‘Axiom’ is used to refer to statements that say what is true in the domain that are ‘basic’ in the sense that they are not inferred from other statements.[ISO/IEC 21838-1:2021(E)]
Note 2 to entry: A statement may be a formula of first-order logic or a sentence of natural language or of the semi-formal counterpart
...
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 user 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.
...
MUST provide non-versioned ontology IRI (See: IRI Structure and Format V2.2 )
When released, MUST provide version IRI(
owl:VersionIRI
)(See: IRI Structure and Format V2.2 )MUST provide label
MUST provide title
MUST provide abstract
MUST provide copyright
MUST provide license
MUST provide maturity
MUST provide a versionInfo
MUST provide changeNotes for each release.
For all constructs:
MUST provide label
MUST provide natural language definition
...
natural language definition –
iof-av:naturalLanguageDefinition
Definition: plain text for industry practitioner understanding
Exactly one natural language definition MUST be given for any construct
Note: this definition MUST be present for both primitive and non-primitive constructs
State the source as a class, property, or other. Check if the serializer removes annotations on annotations. Open Issue regarding how the serializer does this.
No nested annotations in the serializer and moved to the bottom of the file. Should fix the serializer. See: ARCH-86
The definition MUST adhere to ISO 704 rules and requirements for terminology
For non-primitive constructs, the natural language definition MUST NOT be circular
For primitive constructs, the natural language definition SHOULD NOT be circular
The definition MUST be substitutable in a sentence where the term appears
We MAY reconsider this as a requirement if there is no way to express it as a formal substitutable definition. There MUST be a rationale, expressed as an
explanatory note
, for why this is the case and the rationale MUST be agreed to by the Architecture TG.
The definition MUST NOT begin with an article (The, A or An).
One SHOULD avoid jargon and domain-specific terminology
It MUST be understandable by a practitioner in the industrial domain
It MUST NOT use specialized ontological terminology
Examples: perdurant, endurant, continuant, etc.
Ontological construct label MUST be provided in parenthesis
Example: role held by (bearer of) a material entity when it is a proper part of another material entity or is planned to be a proper part of another material entity
It MUST NOT use special formatting for properties or classes referenced in the definition
MUST NOT use upper camel case capitalization
MUST NOT use apostrophes to contain terms as a parenthetical
Examples: must not be as follows: ‘part-of’, ‘Information Content Entity', InformationContentEntity
It MUST NOT contain acronyms or abbreviations
Acronyms MAY be accepted if they appear in the dictionary and are widely used in conversation. Use of such an acronym use MUST be approved by the Architecture TG.
If the definition is taken from another source,
dcterms:source
or one of its sub-properties MUST cite the original reference. Seedcterms:source
in the Source Annotations section below.Examples:
shipment preparation process: planned process in which some material entities are prepared to be transported together to a receiver’s location
postal address: designation of a location (site) to which mail is delivered
...
The following rules MUST be followed when using variables in a first-order logic axiom (formalization) or definition and semi-formal natural language axiom or definition
MUST NOT nest variables in single quotes
Examples: 'instance i' ‘, 'continuant c’
MUST use lower case variable for particular (individual or instance) of a universal
Multiple first-order logic axioms MUST be considered as a combined set using the
∧
(conjunction operator).The axioms can be rewritten using the conjunction operator and remain logically consistent
Variable SHOULD use the first letter of a construct’s label when possible
Variable MUST only be one letter
MUST append numeric suffixes (
x1
,x2
, etc.) OR one or more primes (x'
,x''
, etc.) for multiple instances of the same constructMUST reserve the use of
t
,t'
, etc., for temporal regions; expressions such as 'for all times' SHOULD be interpreted as meaning ‘for all temporal regions’MUST only use
r
,r'
,s
,s'
, etc., for spatial and spatiotemporal regionsMUST only the use of
R
,R'
, etc. for relationsMUST NOT use the character
a
orA
The following rules MUST be followed in a first-order logic axiom (formalization) or definition
References to classes and properties MUST use the
label
. The label MUST be transformed where the spaces are removed and classes labels MUST use UpperCamelCase and properties MUST use lowerCamelCase.Examples:
material entity
becomesMaterialEntity
has part at some time
becomeshasPartAtSomeTime
See also: IRI Structure and Format for the format of constructs
All terms MUST use a prefix if they are external to the current ontology
All prefixes referenced MUST be declared in the ontology prefixes even if not used in the axioms of the ontology
The syntax MUST adhere to part one of the following article: https://www.cs.ox.ac.uk/people/james.worrell/lecture9-2015.pdf
MUST only use thefollowing symbols:
...
Examples:
product
:obo:Continuant(c) ∧ ¬(obo:SpecificallyDependentContinuant(c) ∨ Person(c) ∨ Organization(c)) ∧ ∃r (ProductRole(r) ∧ obo:hasRole(c, r))
first-order logic definition
–Jira Legacy server System Jira serverId e40ab0a4-b576-382d-85fc-495e1da7d966 key ARCH-64 iof-av:firstOrderLogicDefinition
Definition: formal definition of construct using predicate logic semantics
The first-order logic definition MUST occur exactly once if the term is not primitive (is primitive is
false
)The definition MUST provide individually necessary and sufficient conditions
semi-formal natural language definition –
iof-av:semiFormalNaturalLanguageDefinition
Definition: transitional definition expressing first-order logic definition using semantics
understandable by ontologically knowledgable domain practitioner without predicate logic semanticsJira Legacy server System Jira serverId e40ab0a4-b576-382d-85fc-495e1da7d966 key ARCH-66 The semi-formal natural language definition MUST be provided if the term is not primitive (is primitive is
false
)The semi-formal natural language definition MUST only occur once
Variables SHOULD be removed if they do not need to be referenced later in the expression
Rules for writing necessary axioms, sufficient axioms, and necessary and sufficient axioms:
SHOULD use “every instance of {term} is defined as exactly an instance of {conditions}” for necessary and sufficient conditions
Agent(x) ↔ (Person(x) ∨ GroupOfAgents(x) ∨ EngineeredSystem(x)) ∧ ∃y (AgentRole(y) ∧ hasRole(x,y))
every instance of ‘agent’ is defined as exactly an instance of ‘person’, ‘group of agents’, or ‘engineered system’ that ‘has role’ some ‘agent role’
The following syntax MUST be used:
A construct label MUST be used and its exact syntax preserved for constructs in this or an imported ontology
Quotes (
'
) MUST surround all labelsThe words “is a” MUST NOT be used without a qualification
“is a subclass of” MUST be used to indicate a subclass relationship
“is an instance of” MUST be used to indicate an instance of a universal
Variables SHOULD be used where needed in formulating the definition
The rules for natural language definitions MUST be applied otherwise
Examples:
‘product’: every instance of ‘product' is defined as exactly an instance of (‘continuant’ and not ‘person’ and not ‘organization’ and not ‘specifically dependent continuant’) that ‘bears' some ‘product role’
‘agent’: every instance of ‘agent’ is defined as exactly an instance of ‘person’, ‘group of agents’, or ‘engineered system’ that ‘has role’ some ‘agent role’
first-order logic axiom
-Jira Legacy server System Jira serverId e40ab0a4-b576-382d-85fc-495e1da7d966 key ARCH-65 iof-av:firstOrderLogicAxiom
Definition: axiom of construct using predicate logic semantics
First-order logic axiom MAY be provided if the construct is primitive or non-primitive.
With the implication arrow → the left is sufficient, and the right is necessary
A construct MAY have more than one first-order logic axiom annotation
A first-order logic axiom value MUST adhere to first-order logic definition syntax
Multiple first-order logic axioms MUST be considered as a combined set using the
∧
(conjunction operator).The axioms can be rewritten using the conjunction operator and remain logically consistent
If there is more than one axiom:
the axiom MUST be associated with the semi-formal natural axiom
The axiom MUST use a prefix consisting of a name and a colon.
The name MUST use
LA<n>:
where<n>
is a monotonically increasing number starting at1
.
Examples:
Code Block iof-av:firstOrderLogicAxiom: "LA1: BusinessFunction(x) → Function(x) ∧ ∃o,∃i(Organization(o) ∧ ObjectiveSpecification(i) ∧ functionOf(x,o) ∧ genericallyDependsOnAtSomeTime(i,o) ∧ prescribedBy(x,i)) ∧ ∀y(hasRealization(x,y) → BusinessProcess(y))" iof-av:firstOrderLogicAxiom: "LA2: Function(x) ∧ ∃o,∃i,∃p(Organization(o) ∧ ObjectiveSpecification(i) ∧ BusinessProcess(p) ∧ functionOf(x,o) ∧ genericallyDependsOnAtSomeTime(i,o) ∧ prescribedBy(x,i)) ∧ hasRealization(x,p)) → BusinessFunction(x)"
semi-formal natural language axiom -
iof-av:semiFormalNaturalLanguageAxiom
Definition: transitional definition expressing first-order logic axiom using semantics understandable by ontologically knowledgable domain practitioner without predicate logic semantics
Semi-formal natural language axioms MAY be provided if the term is primitive (is primitive is
true
)A construct MAY include more than one semi-formal natural language axiom annotation
The definition MUST adhere to semi-formal natural language definition syntax
If there is more than one axiom:
The axiom MUST be associated with the first-order logic axiom
The axiom MUST use a prefix consisting of a name and a colon.
The name MUST use
LA<n>:
where<n>
is a monotonically increasing number starting at1
.
Example:
Code Block iof-av:semiFormalNaturalLanguageAxiom: "LA1: if x is a 'business function' then x is a 'function' that is 'function of' some 'organization' and that is 'prescribed by' some 'objective specification' and whenever x 'has realization' y that y must be a 'business process'" iof-av:semiFormalNaturalLanguageAxiom: "LA2: if x is a 'function' that is 'function of' some 'organization' and that is 'prescribed by' some 'objective specification' and that 'has realization' some 'business process' then x is a 'business function'"
All variables refer to instances
Rules for writing a necessary or sufficient axiom:
SHOULD use if and then to indicate the implication/conditional pattern for necessary or sufficient axiom: if antecedent, then consequent
AgentRole(x) → Role(x) ∧ ∃m ∃n ((MaterialEntity(m) ∧ ¬FiatObjectPart(x)) ∧ (Person(n) ∨ GroupOfAgents(n) ∨ EngineeredSystem(n)) ∧ actsOnBehalfOfAtSomeTime(m, n) ∧ roleOf(x,m))
'agent role': if x is an instance of 'agent role', then x is an instance of 'role' that is the 'role of' some ('material entity' and not 'fiat object part') that 'acts on behalf of at some time' some other 'person', 'group of agents', or 'engineered system'
SHOULD use some type of for a universal pattern
InformationContentEntity(x) ∧ ∃c, ∃r ( continuant(c) ∧ RequirementSpecification(r) ∧ satisfies(x,r) ∧ prescribes(x,c)) ∧ ∀c'(prescribes(x,c') → Continuant(c')) → DesignSpecification(x)
if d is a ‘design specification’, then d is an ‘information content entity’ that ‘prescribes' some type of 'continuant'
SHOULD use whenever when representing a multi-place temporal expression
∀ p,q,t (hasContinuantPart(p, q, t) ∧ instanceOf(p, MaterialEntity, t) → instanceOf(q, site, t) ∨ instanceOf(q, ContinuantFiatBoundary, t) ∨ instanceOf(q, MaterialEntity, t)
whenever a ‘material entity’ ‘has part’ y then y must be a ‘site’ or a ‘material entity’ or a ‘continuant fiat boundary’
Complete Example with more than one axiom:
Code Block iof-av:firstOrderLogicAxiom "LA1: Assembly(x) → MaterialArtifact(x) ∧ ∃c,∃c'(MaterialComponent(c) ∧ MaterialComponent(c') componentPartOfAtAllTimes(c,x) ∧ componentPartOfAtAllTimes(c',x) ∧ ¬(c=c'∨ (componentPartOfAtAllTimes(c,c') ∨ componentPartOfAtAllTimes(c',c))))" iof-av:semiFormalNaturalLanguageAxiom "LA1: if x is an 'assembly' then x is a 'material artifact' and there are at least two distinct 'material component' that are 'component part of at all times' x" iof-av:firstOrderLogicAxiom "LA2: MaterialArtifact(x) ∧ ∃p(AssemblyProcess(p) ∧ isSpecifiedOutputOf(x,p)) → Assembly(x)" iof-av:semiFormalNaturalLanguageAxiom "LA2: Material Artifact x that 'is specified output of' some Assembly Process p implies x is an Assembly"
...
see also –
rdfs:seeAlso
Definition:
rdfs:seeAlso
is an instance ofrdf:Property
that is used to indicate a resource that might provide additional information about the subject resource [rdfs]see also: https://www.w3.org/wiki/UsingSeeAlso
The reference MUST be a concise reference to the related documentation
The reference SHOULD be a URL, if possible, otherwise a brief description of the external reference
replaced by –
iof-av:replacedBy
Definition: reference to the IRI of the target of a deprecated construct
The value MUST be an IRI referencing the target construct
Addressing Citations
A source is a related resource from which the described resource is derived. Since annotations can be applied to annotations, the appropriate source annotation property described below SHOULD be attached to the element where the influence of the source manifests. This element could be an entire construct or an annotation on a construct such as a natural language definition. A source annotation SHOULD be concise, but may be in the form of a URL, bibliographic citation, or other standard description.
...
comment–rdfs:commentcomment MUST NOT be used. Use one of the following instead:
iof-av:explanatoryNote
iof-av:usageNote
skos:scopeNote
explanatory note –
iof-av:explanatoryNote
Definition: supplemental information used to clarify or describe the construct
explanatory note MAY be used to supplement the natural language definition of the construct
Example: “Item is another term semantically close to Product. But it is more general because the Item may not sellable. It is an overloaded term used by information systems to capture catalog information about real and sort of unreal (e.g., product family or option class which is a group of similar products) materials the enterprise concerns with.”
usage note –
iof-av:usageNote
Definition: describes how to use the term in particular situations
usage note MAY be used to describe how the term is used in particular situations through an example instantiation.
Example: “This is how the Supplying Relation class may be used to convey who supplies what to who. SupplierRole(sr1) and BuyerRole(br1) and Product(p1) and SupplyingRelation(s1) and specificallyDependsOn(s1, sr1) and specificallyDependsOn(br1, s1) and specificallyDependsOn(p1,s1)”
scope note –
skos:scopeNote
If required, scope note MUST be used to provide additional domain contextualization on the use of the term
From skos:
A note that helps to clarify the meaning and/or the use of a concept
Example:
change note -
skos:changeNote
: The note MUST have the following information:Reference to the Jira issue related to the change
Brief description of the change
Synonyms and Abbreviations
General Rules
Synonyms and abbreviations MUST include language tag
xml:lang
.
synonym –
iof-av:synonym
Definition: alternate label that may help users discover the construct
synonym MAY be used to indicate alternate term. If alternate term is context specific, it SHOULD be supplemented with the scope note annotation.
Example:
“process plan” is a synonym for the “plan specification” in the context/scope of discrete manufacturing, “recipe” is a synonym for the “plan specification” in the context/scope of batch and continuous manufacturing.
symbol –
iof-av:symbol
Definition: terse designation (abbreviation) for the construct
One SHOULD use symbol when a commonly used abbreviation exists, such as chemical symbols or units of measure
Examples:
m (meter)
C (carbon)
abbreviation –
iof-av:abbreviation
Definition: alternate short label for the element
OneSHOULDuse abbreviation when there is an alternate short label
One MUST use symbol if the abbreviation is a chemical or unit of measure.
acronym –
iof-av:acronym
Definition: specialized abbreviation
One SHOULD use acronym when there is a commonly accepted acronym
Examples:
PLM (Product Lifecycle Maintenance)
CAD (Computer Aided Design)
Maturity
Description
Maturity designates an ontology's development status and how it will integrate into the development and release process. released
indicates that the ontology has been through the entire release and voting process and is now a normative part of the IOF ontologies. provisional
indicates that the ontology is in development and may contain errors or omissions. A maturity annotation encompasses an entire ontology, and all constructs, axioms, and annotations in that ontology file have the same maturity. Two workflows depend on whether the ontology has been released. If an ontology has never been released, a new file is created with a provisional
maturity
using the name of the ontology. If the ontology has been released, annotated with released
maturity
, then a new ontology file is in the provisional
subdirectory (provisional/Xxx
), where Xxx
is the base name of the ontology and the target of the new ontology file. All new constructs, properties, and axioms are added to the provisional/Xxx
file. One caveat is the constructs in the provisional/Xxx
file must have the IRI of the base target ontology.
A few examples:
A new ontology:
A new development branch is created.
A new ontology file is created with the ontology's name and a
provisional
maturity
.Constructs are added to the new ontology file.
When complete, the working group votes on the new ontology. Upon successful vote, the
maturity
changes toreleased,
and a pull request is created to merge into master.Two reviewers must approve the new ontology, and it must pass the CI/CD tests
Upon approval and tests are passed, the TOB votes on the release of the ontology
Once TOB approves, the changes are merged into the master branch
An existing ontology:
A new development branch is created
An ontology file is created in the
provisional
directory below the target ontology file with the same name as the target ontology file. Thematurity
isprovisional
.Changes and additions are made to the provisional ontology file.
The IRIs match the target ontology.
When complete, the working group votes on the new ontology. Upon successful vote, the changes are merged into the target ontology, and a pull request is created to merge into master.
Two reviewers must approve the new ontology, and it must pass the CI/CD tests
Upon approval and tests are passed, the TOB votes on the release of the ontology
Once TOB approves, the changes are merged into the master branch
Some changes are not approved in a new ontology:
Follow same process as a new ontology.
New constructs that are not approved are moved into a provisional ontology in the
provisional
sub-directory with the name of the target ontology.Remaining constructs follow the previous release procedure.
Some changes are not approved in an existing ontology.
Follow same process for an existing ontology.
Only merge approved constructs into the target ontology.
Continue on with the release process.
Rules
maturity – iof-av:maturity
...
Definition: annotation property used to indicate the development status of an ontology.
...
Each IOF ontology MUST have exactly one maturity annotation with a value of type iof-av:MaturityLevel
...
All new constructs, axioms, and annotations MUST be placed in an ontology file with an iof-av:maturity
of iof-av:Provisional
...
Provisional ontologies MUST be included in the AboutIOFDev.rdf
file in the directory of the target ontology
...
Provisional ontologies MUST NOT be included in the related AboutIOFProd.rdf
file in the directory of the target ontology
...
Only released constructs, axioms, and annotations MUST be placed in an ontology file with iof-av:maturity
of iof-av:Released
...
Once released, the ontology maturity MUST remain released
and MUST NOT change back to provisional
...
Released constructs MUST NOT be dependent on provisional constructs
...
For a new ontology, the following procedure MUST be followed:
A new ontology is created, and with
iof-av:maturity
ofiof-av:provisional
The maturity MUST be changed to
iof-av:released
after the working group votes to release the ontology
...
For an existing ontology, the following procedure MUST be followed:
A provisional ontology MUST be created in a
provisional
sub-directory relative to the target ontologyThe target ontology refers to the ontology into which the provisional ontology will be merged
In the
provisional
directory, the additions or changes MUST be in a separate file namedXxx,
whereXxx
is the target ontology being developedIf the provisional ontology is in a sub-topic, a subdirectory MUST be created as follows:
provisional/<sub-topic>/Xxx
from the base directory where<sub-topic>
is the sub-topic directory under the topic as outlined in the IRI structure and format.The IRI must match the target ontology
Provisional constructs in the
iof-av:provisional
ontology file MUST be moved to the released ontology after the working group votes to release the ontology
...
IF the working group wants to use a version IRI, the ontology in a development branch MUST use a version IRI formatted using YYYYMMFLNN
where F
is the first initial and L
is the last initial of the person making the change or chair if WG change and NN
is a monotonically increasing number for each change in that month.
Each ontology MUST use the following vocabulary when specifying the maturity:
...
iof-av:Released
Will not be removed from the ontology for a reasonable length of time
Indicates an ontology that is considered to be stable and mature from a development perspective
Release notes will be provided for any changes concerning released content, and any revisions will be backward compatible with the prior version to the degree possible
iof-av:Provisional
...
Indicates an ontology that is considered to be under development
...
Provisional sub-topic ontologies require a sub-directory in the provisional
directory for their ontologies; the provisional directory is not created under the sub-topic directory.
Rules
maturity –
iof-av:maturity
Definition: annotation property used to indicate the development status of an ontology.
Each IOF ontology MUST have exactly one maturity annotation with a value of type
iof-av:MaturityLevel
All new constructs, axioms, and annotations MUST be placed in an ontology file with an
iof-av:maturity
ofiof-av:Provisional
Provisional ontologies MUST be included in the
AboutIOFDev.rdf
file in the directory of the target ontologyProvisional ontologies MUST NOT be included in the related
AboutIOFProd.rdf
file in the directory of the target ontologyOnly released constructs, axioms, and annotations MUST be placed in an ontology file with
iof-av:maturity
ofiof-av:Released
Once released, the ontology maturity MUST remain
released
and MUST NOT change back toprovisional
Released constructs MUST NOT be dependent on provisional constructs
For a new ontology, the following procedure MUST be followed:
A new ontology is created, and with
iof-av:maturity
ofiof-av:provisional
The maturity MUST be changed to
iof-av:released
after the working group votes to release the ontology
For an existing ontology, the following procedure MUST be followed:
A provisional ontology MUST be created in a
provisional
sub-directory relative to the target ontologyThe target ontology refers to the ontology into which the provisional ontology will be merged
In the
provisional
directory, the additions or changes MUST be in a separate file namedXxx,
whereXxx
is the target ontology being developedIf the provisional ontology is in a sub-topic, a subdirectory MUST be created as follows:
provisional/<sub-topic>/Xxx
from the base directory where<sub-topic>
is the sub-topic directory under the topic as outlined in the IRI structure and format.The IRI must match the target ontology
Provisional constructs in the
iof-av:provisional
ontology file MUST be moved to the released ontology after the working group votes to release the ontology
IF the working group wants to use a version IRI, the ontology in a development branch MUST use a version IRI formatted using
YYYYMMFLNN
whereF
is the first initial andL
is the last initial of the person making the change or chair if WG change andNN
is a monotonically increasing number for each change in that month.Each ontology MUST use the following vocabulary when specifying the maturity:
iof-av:Released
Will not be removed from the ontology for a reasonable length of time
Indicates an ontology that is considered to be stable and mature from a development perspective
Release notes will be provided for any changes concerning released content, and any revisions will be backward compatible with the prior version to the degree possible
iof-av:Provisional
Indicates an ontology that is considered to be under development
Provisional content is subject to change and may change substantially before release. IOF users should be aware that it is not dependable but could be used for reference and as the basis for further work
Activities
Examples:
A new ontology:
A new development branch is created.
A new ontology file is created with the ontology's name and a
provisional
maturity
.Constructs are added to the new ontology file.
When complete, the working group votes on the new ontology. Upon successful vote, the
maturity
changes toreleased,
and a pull request is created to merge into master.Two reviewers must approve the new ontology, and it must pass the CI/CD tests
Upon approval and tests are passed, the TOB votes on the release of the ontology
Once TOB approves, the changes are merged into the master branch
An existing ontology:
A new development branch is created
An ontology file is created in the
provisional
directory below the target ontology file with the same name as the target ontology file. Thematurity
isprovisional
.Changes and additions are made to the provisional ontology file.
The IRIs match the target ontology.
When complete, the working group votes on the new ontology. Upon successful vote, the changes are merged into the target ontology, and a pull request is created to merge into master.
Two reviewers must approve the new ontology, and it must pass the CI/CD tests
Upon approval and tests are passed, the TOB votes on the release of the ontology
Once TOB approves, the changes are merged into the master branch
Some changes are not approved in a new ontology:
Follow same process as a new ontology.
New constructs that are not approved are moved into a provisional ontology in the
provisional
sub-directory with the name of the target ontology.Remaining constructs follow the previous release procedure.
Some changes are not approved in an existing ontology.
Follow same process for an existing ontology.
Only merge approved constructs into the target ontology.
Continue on with the release process.
Ontology Annotations
The following annotations apply to an entire IOF ontology and not to individual constructs of the ontology
...
ISO 704
ISO 10241
ISO/IEC 21383-2:2020 (EN) Information Technology – Top-Level Ontology – Basic Formal Ontology
Link w/o paywall?
6.2.3.2 Upper case characters, mathematical symbols, typographical signs and syntactic signs (e.g. punctuation marks, hyphens, parentheses, square brackets and other connectors or delimiters) as well as their character styles (i.e. fonts and bold, italic, bold italic, or other style conventions) shall be used in a term only if they constitute part of the normal written form of the term as conventionally used in running text. Syntactic signs shall not be used to show alternative terms. For complex terms (e.g. compounds and multiword terms), the natural word order shall be retained.
...