Version History

Contents

Terms from Standards Used in this Document

• construct: refers to an OWL class, object property, or data property

• entity (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 Reference

• primitive: expression for which no non-circular natural language definition can be provided

  • Note 1 to entry: construct lacking necessary or sufficient conditions

  • [ISO 21838-2:2021 (E)]

• universal: 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

Overview

The IOF AnnotationVocabulary (AV) OWL file (AnnotationVocabulary) is the normative source for IOF annotation properties. It includes a superset of the annotation properties discussed in this document along with the metadata about them. This document’s purpose is to provide the requirements and instructions for authors of IOF ontologies. The AV should be imported into IOF ontologies under development to make these annotation properties available; however, since the IOF Core imports IOF AV, using AV requires no explicit owl:imports statement.

All approved ontologies MUST adhere to the following annotation requirements for all constructs.

The following rules MUST be followed when using 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 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.

Summary of Annotation Requirements

The following MUST be provided for all IOF ontologies for every ontology file:

• 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 annotation

• MUST provide a versionInfo

• MUST provide changeNotes for each release.

For all constructs:

• MUST provide label

• MUST provide natural language definition

For classes:

• If the is primitive annotation is set to true:

  • MUST provide a primitiveRationale

  • MAY provide first-order language axioms and semi-formal natural language axioms

• If the is primitive annotation is set to false or not specified:

  • MUST provide first-order logic definition

  • MUST provide semi-formal natural language definition

For properties:

• MAY provide first-order language axioms and semi-formal natural language axioms

• SHOULD provide example

In cases where a text annotation is needed, an American English language version of that annotation is required and MUST use the American English language tag ( xml:lang="en-US"). Spelling in American English annotations MUST conform to an American dictionary, such as Merriam-Webster. Additional annotations covering the same material but expressed in a different natural language are allowed as long as they incorporate the proper language tag. Text annotations that include a language tag have a default datatype of rdf:langString. By definition from the RDFS 1.1 specification, one MUST NOT include an explicit datatype when adding an annotation.

Ontology Annotations

The following is an example of the Ontology annotations from Core. Annotations in the “Active Ontology” tab in Protégé.

Label

• label - rdfs:label

• Each construct MUST have at least one natural language label, as follows:

  • Exactly one American English language label MUST be provided and language tagged

  • Labels MUST be unique across all IOF ontologies and SHOULD be unique across all imported non-IOF ontologies in a given natural language

  • Labels for other natural languages MAY be provided, but if so they must be language tagged

  • Data property MUST be a verb phrase starting with is for boolean (true/false) or has for any other data type.

    • Example: is transferable

  • Data property SHOULD end with value

    • Example: has numeric value

  • label text MUST be given in lowercase with spaces between words

    • Exception: proper names MUST use initial upper-case

    • Exception: Words like DNA that are capitalized in the Oxford English Dictionary (Home: OED ) MUST remain in uppercase

  • Acronyms MUST NOT be used for label values

    • Exception: Words like RADAR and DNA with dictionary definitions MAY be used and will be considered by the architecture TG

    • Acronyms are shortened alternative labels that are composed of a letter from each word of a longer signifier for the notion

    • Acronyms that are not found in dictionaries may be provided as an alternative label for a resource using the acronym annotation property described below

• Note - The IOF annotation vocabulary does not include an annotation property for preferred label. Instead, an annotation directly asserted as an rdfs:label in IOF OWL content is treated as the preferred label.

• Alternative (non-preferred) labels MAY also be provided for a construct using the following annotations

  • iof-av:synonym annotation MUST be used for alternative labels that are not abbreviations

  • iof-av:abbreviation annotation MUST be used for shortened alternative labels other than acronyms

  • iof-av:acronym annotation MUST be used for shortened alternative labels that are composed of a letter from each word of the preferred label (aka acronyms) and that are not found in a dictionary

    • Acronyms that are found in the dictionary MAY be used as the rdfs:label (preferred label) for the notion (as noted in the exception above)

Natural Language

• 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. See dcterms: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

Primitive Term Annotations

• elucidation -- iof-av:elucidation

  • elucidation MUST NOT be used and is deprecated.

• is primitive – iof-av:isPrimitive

  • Definition: boolean flag indicating that necessary and sufficient conditions are not provided at this time

  • is primitive MUST be present if the term does not have necessary and sufficient conditions and the value of the annotation MUST be set to true (w3c boolean)

  • MUST only apply to classes

  • Otherwise, if necessary and sufficient conditions are present, then the annotation MAY be provided and the value MUST be set to false

  • is primitive MUST default to set to false

  • If possible, terms SHOULD have necessary and sufficient conditions

  • Note: the term may not always remain primitive if necessary and sufficient conditions can be defined in a later version

  • Example:

    • person: true

    • shipment preparation process: true

• primitive rationale – iof-av:primitiveRationale

  • Definition: reason why the necessary and sufficient conditions were not or could not be provided at this time

  • MUST only apply to classes

  • When is primitive is set to true , the primitive rationale MUST be provided

  • The primitive rationale MUST explain why necessary and sufficient conditions are not possible

  • The rationale SHOULD indicate what is missing if additional work is required to define necessary and sufficient conditions

  • Example:

    • person: insufficient constructs to create necessary and sufficient conditions

    • shipment preparation process: shipment preparation process often includes at least one picking, internal movement, packaging, marking, weighing, or loading process, but since those processes are not added to the ontology yet, it is not possible to generate necessary and sufficient conditions at this time for this entity

Logical Annotations

Definitions and axioms in first order logic must be kept separate from each other: The definition of a term x is designed to be the shortest and logically simplest specification of necessary and sufficient conditions for being and instance of x. The axioms specify additional characteristics which are seen as holding for all such instances. The advantages of this strategy are: 1. definitions are easy to understand and easy to apply, 2. definitions are more stable in the sense that new kinds of x might be discovered, or might evolve, which falsify one or other axiom, but still satisfy the definition.

• 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 construct

  • MUST 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 regions

  • MUST only the use of R, R', etc. for relations

  • MUST NOT use the character a or A

• 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 becomes MaterialEntity

      • has part at some time becomes hasPartAtSomeTime

    • 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

    • Well-formed formula

    • First-order logic

      • ISO/IEC PRF 21838‐1:2020

      • OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition)

  • 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 the following symbols:

• Examples:

  • product:

    • obo:Continuant(c) ∧ ¬(obo:SpecificallyDependentContinuant(c) ∨ Person(c) ∨ Organization(c)) ∧ ∃r (ProductRole(r) ∧ obo:hasRole(c, r))

• first-order logic definitionhttps://oagi.atlassian.net/browse/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 https://oagi.atlassian.net/browse/ARCH-66understandable by ontologically knowledgable domain practitioner without predicate logic semantics

  • 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 labels

    • The 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 https://oagi.atlassian.net/browse/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 at 1.

    • Examples:

      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 at 1.

  • Example:

    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:

Example Annotations

• example – skos:example

  • Definition: supplies an example of the use of a concept [skos]

    • ex:organizationsOfScienceAndCulture skos:example: "academies of science, general museums, world fairs" [skos]

  • example MUST provide a correct use of the construct in a domain context

  • constructs SHOULD include example

Source Annotations

• see also – rdfs:seeAlso

  • Definition: rdfs:seeAlso is an instance of rdf:Property that is used to indicate a resource that might provide additional information about the subject resource [rdfs]

    • see also: UsingSeeAlso - W3C Wiki

  • 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.

• direct source – iof-av:directSource

  • Definition: definitive source of the subject resource

• adapted from – iof-av:adaptedFrom

  • Definition: source for the resource that was modified to create the subject resource

Removed, Renamed, or Relocated Constructs Represented as IRI Changes

In cases where a construct is removed, renamed in the ontology, or moved to another ontology, it MUST also be marked as owl:deprecated. The following annotations MUST be used:

• The following MUST be provided when retired/removed or moved in the source ontology annotations:

  • owl:deprecated annotation MUST have the value true.

  • All construct annotations MUST be removed.

  • All axioms MUST be removed, except the subclass axiom SHOULD be preserved.

  • The iof-av:replacedBy annotation MUST be added to the owl:deprecated annotation and MUST contain the IRI of the new location.

  • skos:changeNote: Rational for the deprecation–keeps the history of the rational in the header.

    • Version: Version IRI in which we deprecated the term.

    • Rationale: Change note associated with the deprecated element because protege can associate with the destination term.

      • Example content of the skos:changeNote:

• The user MUST have the ability to choose if the constructs are equivalent to the previous terms:

  • The user MAY add the owl:equivalentClass or owl:equivalentProperty: IRI of the destination construct for the moved term.

  • OWL owl:sameAs MAY be used for nominals as appropriate.

• The user SHOULD change their ontology to use the new constructs.

• To be considered for future releases: Deprecated constructs MUST be moved into a separate ontology file with the deprecated terms after a specified waiting period.

Notes

• comment – rdfs:comment

  • comment 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

  • One SHOULD use 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 is 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. All constructs, axioms, and annotations in that ontology file have the same maturity.

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

  • Each ontology MUST use the following vocabulary when specifying the maturity:

    • iof-av:Released

      • Once in the Releasedstate, an ontology’s non-versioned IRI MUST refer to an ontology with a maturity of Released

      • Indicates an ontology that is considered to be stable and mature

      • A released ontology MUST NOT depend on any provisional ontology

      • Release notes MUST 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 ontologies are 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

Ontology Annotations

The following annotations apply to an entire IOF ontology and not to individual constructs of the ontology

• copyright – iof-av:copyright

  • Definition: originator’s and authorized entity’s exclusive legal right to print, distribute, and publish material

  • Ontologies MUST have a copyright annotation

• license – dcterms:license

  • Defintion: legal document giving official permission to do something with the resource [dcterms]

  • Ontologies MUST have a license annotation

• abstract - dcterms:abstract

  • Definition: A summary of the resource [dcterms]

  • Ontologies MUST have an abstract annotation

• maturity – iof-av:maturity

  • Definition: default maturity level of the ontology

  • Ontologies MUST have a maturity annotation

  • See maturity level above

• versionInfo – owl:versionInfo

  • Definition: owl:versionInfo provides the release version number of the ontology

  • Ontologies MUST have an owl:versionInfo annotation

  • The versionInfo MUST have the numeric version component (YYYYNN) of the release version IRI as the value

    • See Public Release Version IRI in the IRI Structure and Format V2.2 document.

Prefixes and Namespaces

This document identifies each annotation property using an abbreviated form of its full IRI with the structure <prefix>:<local name>, where the prefix represents the namespace IRI, and the local name is the identifier for the resource within the namespace. The full IRI is the concatenation of the local name to the namespace IRI; for example, skos:scopeNote represents http://www.w3.org/2004/02/skos/core#scopeNote. An ontology author may never use this expanded form directly. However, for completeness, a table below is provided that enumerates all the prefixes used in the document along with the namespaces that they represent.

Appendix

A. Reference Documents

• ISO 704

  • https://oagiscore.atlassian.net/wiki/pages/viewpageattachments.action?pageId=4399431681&preview=%2F4399431681%2F4399267856%2FISO704_2009.pdf

• ISO 10241

  • https://oagiscore.atlassian.net/wiki/download/attachments/3664838679/ISO_IEC_21838-1.pdf?api=v2

• ISO/IEC 21383-2:2020 (EN) Information Technology – Top-Level Ontology – Basic Formal Ontology

  • Link w/o paywall?

• Link to provers for first-order logic: http://hets.eu

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.

informative content will be removed as soon as all dependencies have been eliminated; thus IOF users should not depend on it going forward

C. Voting