Ontology-based Interoperability for Industrial Data¶
Lead authors: Melinda Hodkiewicz and Andreas Neumann¶
Development team: Pål Rylandsholm, Maja Milicic Brandt, Johan W Kluwer, Caitlin Woods, Dirk Walter, Inghild Kaarstad¶
Abstract¶
This document provides guidance to industry users and the semantic data modelling community on 1) the vision for the ISO 23726 Ontology-based Interoperability (OBI) series, and 2) a set of principles which resources will have to comply with in order to be considered compliant with IDO and the ISO 23726 series. The Industrial Data Ontology (IDO) is the upper ontology in the ISO 23726 series. IDO is currently inside the ISO process and due to be published as an ISO standard in 2026.
The contents of this document was submitted to ISO as part of ISO 23726-1 in October 2025. The committee draft (CD) was registered in January 2026. The standardisation process is expected to take 3 years. During this period the contents of this document will evolve as other organisations and national bodies work to shape the ideas presented in this initial version. Once inside the ISO process only members of the ISO TC184/SC4 WG26 committee and the liaison groups will have access to the draft standard and any associated digital artefacts until it is published in February 2028.
Countries in the ISO TC184 SC4 WG26 working to co-develop this standard are China, Denmark, Finland, France, Germany, Australia, Norway and the USA. Norway is the project manager.
Licence¶
Introduction¶
Machine-interpretable data are a key enabler of 1) industrial automation, and 2) the application of artificial intelligence to products, plants, processes, and services. However, organizational data are often stored in digital formats that use proprietary terms, definitions, and schemas. This lack of semantic interoperability means that data exchange frequently relies on manual interpretation or custom mappings. Documents such as engineering standards, procedures, spreadsheets, and reference data libraries are prone to misinterpretation when their semantics are not formally and explicitly defined.
A semantically explicit format is key to human and machine interoperability. An ontology is a structured set of terms, their interrelationships, and associated definitions, supported by formal logic to ensure that the intended meaning is unambiguous and machine-interpretable. The use of formal representation enables consistent preservation and exchange of meaning.
Ontologies are increasingly integrated into enterprise architecture, particularly within knowledge management layers. An example is shown in Figure 1. The Ontology-Based interoperability (OBI) ecosystem comprises artefacts managed by ISO 23726 WG26, external organizations, enterprises, as well as organizational stakeholders, processes, and capabilities.
Figure 1 — Example of enterprise architecture for OBI ontology-based interoperability
At the base of the Figure 1 is a level representing the data sources created by enterprises and stored in the data storage system layer. To organize, check, and integrate data from disparate source systems, organisations are incorporating a knowledge management layer into their enterprise architecture. An ontology-based knowledge management layer provides quality controlled, interoperable data for data products, analytics and AI used by data consumers within and across organisations. IDO is the upper ontology in the OBI ecosystem knowledge management layer. In addition to IDO the knowledge management layer includes enterprise ontologies and shared artefacts such as reference ontologies, ontology modelling patterns, templates, reference data libraries, data quality rules, SHACL shapes, and SPARQL queries. Above the knowledge management layer sits in an enterprise architecture for data products, data analytics and artificial intelligence models which are accessible to data consumers.
The W3C standards Web Ontology Language (OWL) and Resource Description Framework (RDF) are foundational standards for the Semantic Web and considered normative for ontologies in the Ontology based interoperability (OBI) standards. These standards enable machine -readable, semantically interoperable representations based on shared vocabularies and logical structures. The foundation for the OBI series is ISO 23726-3, the Industrial Data Ontology (IDO).
IDO specifies an abstract representation of the industrial data domain, including a high level of conceptual abstraction and associated modelling constraints. The semantic interpretation of a concept modelled according to an IDO-aligned artefact is explicitly defined. This enables consistent interpretation and automated reasoning by both humans and machines.
IDO is implemented as an OWL 2 upper ontology. OWL 2 DL ontologies are interpreted using the Direct Semantics. DL (description logics) are a family of languages used in artificial intelligence and Semantic Web technologies for logic-based knowledge representation and reasoning. Typical ontology reasoning tasks include: (1) consistency checking, (2) automated classification (i.e. inferring implicit subclass hierarchies), and (3) derivation of implicit facts. OWL DL reasoners are software systems that perform these reasoning tasks automatically. Such automated reasoning is essential for quality assurance, semantic consistency, and knowledge inference within ontologies.
1 Scope¶
This draft provides an overview and the fundamental principles of the multipart standard ISO 23726 series Industrial automation systems and integration – Ontology based interoperability (OBI).
This draft specifies the principles for ontologies and artefacts aligned with IDO upper ontology to be considered part of the OBI series.
This draft is applicable in the construction of ontologies and artefacts for the representation of engineering data associated with all phases of the life cycle of industrial products, plants and systems to enable semantic interoperability.
The following are outside the scope of this draft:
-
specification of ontology languages.
-
specification of Semantic Web standards such as Resource Description Framework (RDF), SHACL, SPARQL, and Internationalized Resource Identifiers (IRIs).
-
specification of methods for reasoning with ontologies.
-
Methods to build, maintain, align, and evaluate ontologies and artefacts to meet the principles in this draft. These will be covered in separate guideline drafts.
2 Normative references¶
There are no normative references.
3 Terms and definitions¶
3.1 Types of ontologies¶
3.1.1¶
application ontology
ontology developed for a particular task or use case (3.3.6) that contains only the concepts, relationships, and constraints necessary for the context
Note 1 to entry: Designed to be used in a specific context and are not always reusable.
3.1.2¶
enterprise ontology
ontology developed, owned, and maintained by an enterprise
Note 1 to entry: Enterprise ontologies include reference ontologies (3.1.3) and application ontologies (3.1.1).
Note 2 to entry: An enterprise ontology (3.1.2) conceptualizes enterprise vocabulary and knowledge.
Note 3 to entry: An enterprise ontology (3.1.2) is not an ontology for a specific software application or program.
3.1.3¶
reference ontology
ontology based on a shared understanding of the concepts and relationships within a specific domain or field of knowledge
Note 1 to entry: Reference ontologies provide a common vocabulary and structure. They are reusable across multiple applications.
Note 2 to entry: Reference ontologies are stable and actively maintained.
Note 3 to entry: There is no agreement in the literature as to a naming convention for ontologies that sit between the upper ontology (3.1.4)and an enterprise ontology (3.1.2). Various names such as Core, Domain, Domain-independent, Domain-dependent are used but not clearly defined. The term reference ontology (3.1.3) is used in this standard as a label for all of these terms. Application ontologies (3.1.1) will usually import a number of reference ontologies from both within the enterprise and from trusted external groups such as ISO.
3.1.4¶
upper ontology
top level ontology
ontology of abstract concepts and general relationships that are common across all domains
Note 1 to entry: Abstract concepts are things like Object, Event, Process, Role, Quality and Function and general relationships are relations such as lis:partOf, lis:participatesIn and lis:hasQuality
3.2 Ontology and RDF concepts¶
3.2.1¶
axiom
logical statement that is taken to be true, to serve as a premise for further reasoning
Note 1 to entry: Axioms may be formulated as natural language sentences or as formulae in a formal language. In the OWL community, `axiom (3.2.1)’ 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.
[SOURCE:ISO DIS 23726-3]
3.2.2¶
annotation property
RDF property included in the vocabulary of an OWL ontology, with no semantic significance
Note 1 to entry: Annotation properties allow for metadata (3.4.3) on entities in an ontology that is not subject to OWL reasoning.
Note 2 to entry: Annotation properties are used to add human-readable descriptions such as labels, definitions and notes.
Note 3 to entry: https://www.w3.org/TR/owl2-syntax/#Annotation_Properties
[SOURCE:ISO DIS 23726-3]
3.2.3¶
class restriction
OWL class restriction
logical axiom (3.2.1) that constrain the properties and relationships of individuals within a class
Note 1 to entry: The main types of class restrictions in OWL ontologies (owl:Restriction) are existential (some), universal (only), value restriction (have a specific value for a property) and cardinality restriction (have exactly, at least, or at most a certain number of relations).
3.2.4¶
description logics
family of languages used in artificial intelligence and Semantic Web (3.4.4) technologies for logic-based knowledge representation and reasoning
3.2.5¶
expressivity
level of expressivity
degree of complexity and richness in the types of knowledge an ontology can represent using its logical language
Note 1 to entry: Different aspects of expressivity (3.2.5) include:
1. Conceptual - ability to define complex class descriptions, such as reification, intersection, union, complement, restriction, and equivalence.
2. Property - ability to define object and data properties with characteristics such as transitivity, symmetry, inverse, and functionality.
3. Axioms and constraints - ability to represent general class axioms, disjointness, property hierarchies, and cardinality constraints.
Note 2 to entry: The use of axioms such as cardinality constraints or restrictions on makes implicit knowledge explicit and this explicit knowledge can be used by reasoners to infer missing information or to be used as data quality rule for the validation of instance data.
3.2.6¶
OBI design commitment
commitment to a specification of a conceptualization
Note 1 to entry: a commitment to an upper ontology (3.1.4) is a guarantee of consistency, but not completeness, with respect to queries and assertions using the vocabulary defined in the ontology.
Note 2 to entry: This commitment is akin to a contract to ensure that data are represented and exchanged in an agreed manner.
Note 3 to entry: An agreement to ensure ontology patterns are modelled in a way that is approved by, and consistent with, the OBI ecosystem.
3.2.7¶
ontology alignment
process of identifying relationships between concepts in two different ontologies
Note 1 to entry: There are three types of alignment:
1. equivalence - concepts are the same,
2. subsumption - one concept is more general than the other,
3. relatedness - concepts are related but not identical.
3.2.8¶
ontology reasoning
OWL DL reasoning
inference of implicit facts from knowledge expressed in an OWL 2 ontology using the direct model theoretic semantics of OWL 2 DL
3.2.9¶
semantic interoperability
interoperability so that the meaning of the data within the context of a subject area is understood by the participating systems
Note 1 to entry: Systems include pieces of equipment, software, human and computing systems.
Note 2 to entry: This is accomplished by linking data elements to a controlled, shared vocabulary.
Note 3 to entry: Ensures that data from current and legacy systems, sensors, software tools and databases can be integrated and used without manual reconciliation or misunderstanding.
Note 4 to entry: A foundation for Industry 4.0, Smart Factories and Digital Product passports.
[SOURCE:ISO/IEC 19941:2017]
3.2.10¶
shortcut property
object or datatype property in OWL intended as equivalent in meaning to a modelling pattern (3.3.3) that would involve additional entities or classifications if made explicit
[SOURCE:ISO DIS 23726-3 Annex B]
3.3 Ontology elements¶
3.3.1¶
competency question
question formulated in natural language that defines a formal requirement in the ontology engineering process
Note 1 to entry: Competency questions capture requirements from domain experts and check they can be addressed and guide developers in identifying what classes, properties, and constraints are needed.
Note 2 to entry: Competency questions are used to validate a reasoner or query engine can produce the answer to a question that the ontology was built to address.
3.3.2¶
ontology module
subset of an ontology containing only the concepts and axioms (3.2.1) needed for a specific purpose or context
Note 1 to entry: An ontology module (3.3.2) is imported into other ontologies as a building block.
Note 2 to entry: An ontology module (3.3.2) is like the chapter or page of a book where the ontology is the whole book
3.3.3¶
ontology pattern
pattern
reusable modelling solution in ontology development
Note 1 to entry: Used to streamline the design of an ontology or artefact by offering tried-and-tested solutions to recurring conceptualization challenges in a principled way to enable consistency, best practices, completeness, support of automation and simplification in communication.
3.3.4¶
ontology template
template
definition of a structure and its expansion that can translate a simplified representation of instance data into an OWL RDF serialization of the instance
Note 1 to entry: Best practice is to map templates to the modelling patterns that they contribute to instantiating (noting that several templates are involved in the instantiation of one modelling pattern (3.3.3)).
Note 2 to entry: Means by which ontology models and modelling patterns (3.3.3) can be instantiated transforming conceptual knowledge and instance data into an OWL/RDF serialization.
3.3.5¶
reference data library
RDL
vocabulary of industrial terms organized according to ontological categories
[SOURCE: ISO PWI 23726-2]
Note 1 to entry: IDO is intended to be a suitable basic vocabulary for Reference Data Libraries (RDL) represented as OWL 2 ontologies.
3.3.6¶
use case
description of a scenario to which an ontology is applied.
Note to entry: Use cases ground ontology development in a practical need, assist with the design of competency questsions and provide a way to evaluate the suitability of the ontology for a specific need.
3.4 General terms¶
3.4.1¶
data product
rational, managed, and governed collection of data, with purpose, value and ownership, meeting consumer needs over a planned life-cycle
[SOURCE:Data Product Ontology https://ekgf.github.io/dprod/]
3.4.2¶
internationalized resource identifier
IRI
unique sequence of characters from the Universal Character Set constructed according to the syntax rules provided in RFC 3987
Note 1 to entry: IRIs identify resources on the web in a way that supports a wide range of characters and languages enabling a more diverse representation of information, especially in languages other than English.
Note 2 to entry: IRIs are globally unique.
[SOURCE:ISO/IEC 10646:2020[1]]
3.4.3¶
metadata
data whose purpose is to describe and give information about other data
[SOURCE:Oxford English Dictionary]
3.4.4¶
Semantic Web
extension of the World Wide Web in which data are structured and tagged with metadata (3.4.3) that can be read directly by computers
3.4.5¶
uniform resource identifier
URI
unique sequence of characters that identifies an abstract or physical resource
3.5 Terms related to organisational groups¶
3.5.1¶
maintenance agency
body appointed by ISO (ISO-recognised) or an external (ISO-external) group responsible for the maintenance, application, and administration, and publication of ontology and artefacts
Note 1 to entry: A key responsibility for a maintenance agency (3.5.1) is the provision of a namespace for the IRIs (3.4.2) and a website on which ontology artefact (3.5.3) are made available.
3.5.2¶
OBI ecosystem
system of OBI artefacts (3.5.3) , stakeholders, and processes to develop, maintain and deploy solutions to deliver enterprise semantic interoperability (3.2.9)
3.5.3¶
OBI artefact
object created, documented, controlled, maintained and used in the OBI ecosystem (3.5.2)
Note 1 to entry: Examples include reference ontologies, ontology patterns, ontology templates, reference data libraries, and artefacts such as data quality rules and SHACL. Note 2 to entry: These artefacts are assured by a maintenance agency (3.5.1).
4 Parts in the OBI series¶
4.1 Overview and fundamental principles¶
This document presents a vision for the OBI ecosystem (3.5.2) and a set of principles (Clause 6) to ensure artefacts in the OBI series are compliant with a set of principles.
4.2 Vocabulary¶
Document describing the terms and definitions used in the ISO 23726 standard series.
4.3 Industrial Data Ontology¶
This document describes the Industrial Data Ontology (IDO), an upper ontology intended for industrial data and information, to build vocabularies and manage asset models which employ reference data libraries and exploit OWL DL.
The IDO standard described in ISO 23726-3 provides a foundation for all parts of the ISO 23726 standards.
The purpose of the IDO standard is to serve the representation and integration of industrial data and industry standards. This means, to build vocabularies and asset models, to manage asset models which employ reference data libraries, and to support automated machine reasoning and data quality. The IDO standard supports information models used in all life cycle phases of industrial systems, processes and products.
4.4 Schedule Data Ontology¶
The Schedule Data reference ontology specifies the vocabulary for schedule data and information. It is intended for industrial schedule data and information. The ontology provides definitions for terms related to schedules, schedule activity, work patterns for schedule execution, and the relationships between schedule activities and resources.
5 OBI ecosystem¶
5.1 General¶
This informative section provides an overview of the OBI ecosystem (3.5.2) and introduces ontology concepts relevant to the other sections in this Standard. The OBI ecosystem (3.5.2) includes ontologies, artefacts, stakeholders, and processes.
In order to achieve semantic data exchange and interoperability within and between organisations there has to be principles to which data modellers adhere and an infrastructure and mechanisms to find, assess and exchange artefacts . In the OBI ecosystem (3.5.2) these principles (see Clause 6) are informed by the upper ontology (3.1.4) (ISO 23726-3 Industrial Data Ontology) and its ontological commitments. The principles for an artefact being a trusted part of the OBI series are set out in Clause 6.
Figure 2 shows artefacts in the OBI ecosystem (3.5.2). These include 1) shared and proprietary artefacts, and 2) ISO 23726 managed and external group managed artefacts, as follows.
a) Industrial Data Ontology ISO 23726-3 (IDO) - this upper ontology (3.1.4) is shown at the core of the diagram.
b) ISO 23726 managed artefacts from the ISO 23726 series. These shared artefacts are shown as the grey circle around IDO. They are assured by ISO processes and available through ISO. They are governed by the ISO-recognised maintenance agency (3.5.1) for ISO 23726.
c) External group managed artefacts that meet the principles set out in this Standard. These are shown in the white circle. External groups include, for example, other standards bodies and industry organisations. These artefacts shall be managed and maintained with quality control processes equivalent to those of the ISO-recognized maintenance agency.
d) Shared OBI series managed artefacts (OBI artefacts and external group managed artefacts). These sit within the black dashed line in Figure 2. The creation and maintenance of these shared artefacts enables efficient construction of ontologies. Examples of common shared artefacts include reference ontology (3.1.3), and reference data libraries (3.3.5).
e) Enterprise managed artefacts such as enterprise ontologies (3.1.2), enterprise artefacts. Shown as the inner of the two outer grey circles.
f) The enterprise data layer is shown as the outer grey circle.
g) The outer two circles are managed by individual enterprises. These artefacts and data are proprietary and developed to address specific business needs and decisions.
Figure 2 — Artefacts in the OBI ecosystem. Artefacts inside the dashed line are trusted and shared between enterprises. Artefacts and data between the two outside dashed lines are proprietary and managed by an enterprise.
5.2 Stakeholders in the OBI ecosystem¶
Stakeholders in this ontology-centric ecosystem include (but are not limited to) asset owners and operators, engineering product and process plant designers, standards organisations, industry groups that manage reference data libraries, organisations involved knowledge representation and AI, and those providing ontology development and maintenance services, assurance and conformity assessment services.
The Maintenance Agencies are a vital component of the OBI ecosystem (3.5.2) because enterprises require quality control to build trust that artefacts are managed and maintained by an accountable body.
The diagram in Figure 3 shows an example of how an enterprise might use trusted artefacts from 1) ISO 23726, 2) its internal artefacts (shown in the upper box), and 3) artefacts provided by external groups compliant with this OBI standard (shown in the white box). Figure 3 also includes some examples of roles involved in each stage of the process. The same person may have a role as part of an enterprise's internal process as well as part of an external group's process.
Figure 3 — Illustrative example of processes and roles involved in managing an enterprise ontology ecosystem which uses both internal and externally-managed trusted OBI series ontologies
5.3 Reference ontologies¶
A reference ontology (3.1.3) is a domain-specific ontology that models key concepts in a domain so that other more specialized ontologies or applications can reuse or extend it. A trusted reference ontology (3.1.3) can be used across multiple applications. A reference ontology (3.1.3) does not necessarily aim to model everything in the domain. It requires an agreement on the level of expressivity required to represent concepts in the domain. There is no agreement in the community as to a naming convention for ontologies between the top-level and an application ontology (3.1.1). Various names such as Core, Domain, Domain-independent, Domain-dependent are used but not clearly defined. Reference ontologies is used here as a label for all of these. Many application ontologies (3.1.1) will import a number of reference ontologies (3.1.3). This information is presented in Figure 4.
Figure 4 — Illustration of the different terms used in ISO 23726 to describe different types of ontologies
A reference ontology (3.1.3) may be discoverable on the internet if they have an internationalized resource identifier (3.4.2) (IRI) which can be looked up ("dereferenced") over the web to retrieve its contents.
Reference ontologies developed and managed by external groups such as W3C do not align to any specific upper ontology (3.1.4). Modellers may use individual classes or import the entire ontology. In the latter case, care needs to be taken that ontological commitments for artefacts in the OBI series do not conflict with modelling class restrictions (3.2.3) in external reference ontologies.
Where reference ontologies are commonly used in OBI there will be IDO-aligned support documentation produced. Examples of this for OWL-Time, SSN and GeoSPARQL are provided in Annex C of the ISO 23726-3 document.
EXAMPLE 1
Examples of reference ontologies developed and maintained by the World Wide Web Consortium (W3C) include the following:
OWL-Time: an OWL-2 DL ontology of temporal concepts, for describing the temporal properties of resources in the world or described in Web pages https://www.w3.org/TR/owl-time/
PROV-O: an OWL-2 ontology to model provenance information for different applications and domains https://www.w3.org/TR/prov-o/
SSN/SOSA: the Semantic Sensor Network is an ontology for describing sensors and their observations, the involved procedures, the studied features of interest, the samples used to do so, and the observed properties, as well as actuators https://www.w3.org/TR/vocab-ssn/
EXAMPLE 2
Examples of reference ontologies developed and maintained by non-ISO, non-W3C organisations include the following:
GEOSPARQL: this spatial domain OWL ontology relating literal representations of geometries to with spatial features. It is maintained by the Open Geospatial Consortium (OGC) https://www.ogc.org/standards/geosparql/
FIBO: defines the sets of things that are of interest in financial business applications and the ways that those things can relate to one another. It is maintained by the EDM Council https://edmcouncil.org/frameworks/industry-models/fibo/
There is an evolving space developing ontologies for specific domains such as parts of the engineering life cycle, equipment classes, and the information in engineering standards.
EXAMPLE 3
Ontologies for business processes (e.g. scheduling, maintenance), for equipment (e.g. piping and valves), and for specific international standards (e.g. IEC 61360-1:2017[2]).
5.4 Ontology alignment¶
A shared ecosystem requires ontological alignment (3.2.7) to ensure new artefacts are aligned to IDO or to existing IDO-aligned reference ontologies (3.1.3) in the OBI series. The goal is to avoid adding classes and properties that are already represented in the OBI series.
Requirements for ontology alignment (3.2.7) are specified in 6.6
5.5 Reference data libraries¶
The engineering community has a history in developing reference data libraries (RDL (3.3.5)). These are intended as shared resources managed by standards bodies and industry associations. Examples include CFIHOS, ECLASS, ISO 15926-4 and IEC CDD although in their current forms these reference data libraries are not IDO compliant.
For use in the OBI series these reference data libraries (3.3.5) are be aligned to the IDO upper ontology (3.1.4), or 2) to an existing IDO compliant reference ontology, (3.1.3) or 3) to an existing OBI series ontology module (3.3.2).
These RDLs may be managed by different external groups. These groups sit outside of the control of the ISO 23726 committee. In these situations, the following are some suggestions.
a) Both groups align completely, and prefer to share a term and namespace
b) Both groups align (perhaps after one or both groups make some concessions modifications) and they get to create the term in each of their namespaces with an appropriate axiom between the two terms.
c) The groups cannot meet a common ground. They diverge, but note a "caveat" in their metadata (3.4.3), noting the misalignment with another term / concept in the OBI series.
5.6 Relationship to Semantic Web technologies¶
IDO is an OWL 2 upper ontology (3.1.4). It is formulated in OWL DL, a sublanguage of OWL 2 based on description logics (3.2.4) (DLs). DLs are a family of languages used in artificial intelligence and Semantic Web (3.4.4) technologies for logic-based knowledge representation and reasoning. Typical ontology reasoning (3.2.8) tasks include: (1) consistency checks; (2) generation of taxonomical classification, i.e. inference of implicit class hierarchies; (3) inference of new facts. OWL DL reasoners are software engines that perform automated OWL DL [ontology reasoning (3.2.8)]
(#90902_id-75768bd8-00ef-4c11-a67a-8e2dd8d9566e) tasks without human intervention. In addition to providing a high-level vocabulary for representing industrial assets and processes, IDO's modelling patterns are designed to enable efficient automated reasoning for IDO-aligned ontologies by OWL DL reasoners.
OWL 2 stands for Web Ontology Language, it is a W3C recommendation. The W3C (World Wide Web Consortium) is an international organization responsible for developing and maintaining open standards for the World Wide Web. IDO is an open standard for semantic exchange of industrial data between an organization's internal and external partners. IDO leverages the OWL formalisms and other Semantic Web (3.4.4) standards like RDF and SHACL developed by W3C. These are proven and widely used technologies.
5.7 RDF vocabularies¶
RDF-based vocabularies are a useful resource for modellers and to ensure standardization.
EXAMPLE
Dublin Core is an example of a widely used metadata (3.4.3) standard for documenting ontologies and their concepts. It is used for annotation in the OBI series, see Clause 9.
DCMI Metadata Terms: a list of classes and properties to describe metadata (3.4.3). Managed by the Dublin Core Metadata Initiative https://www.dublincore.org/specifications/.
5.8 Modelling templates, patterns and data quality rules¶
5.8.1 Example¶
In the OBI ecosystem (3.5.2) ontologies are knowledge-centric and application-independent but many enterprise data models are application-dependent and data centric. A typical example for a specific enterprise application is shown in Figure 5. Figure 5 represents physical properties of a motor using a modelling pattern.
Figure 5 —
Example based on a motor (ex:Motor71) and representation of its mass (20 kg) to illustrate how SHACL may be used in both the knowledge and application layers
The top two boxes of Figure 5 show the ontology (upper layer) and an example of an enterprise's instance data (middle layer). The ontology is application-independent and represents facts about an object and its properties (in this case a motor is used as an example). Different applications will have need specific data (application-dependent views). For example, electrical engineering-centric and safety professional-centric views are shown.
Two common uses of SHACL are shown. These are to 1) to apply general, application-independent constraints on enterprise ontology (SHACL shape in the top layer) or to apply application-dependent constraints in addition to those specified in the data (SHACL shapes in the lowest layer).
The modelling pattern for the OWL/RDF serialised instance data shown in Figure 5 can be used in multiple applications to ensure data in different enterprise applications has the same semantic meaning. This is a key goal for the OBI ecosystem.
5.8.2 Ontology templates¶
Ontology templates are used to produce ontologies and to populate existing ontologies with data. Ontology templates make these processes reproducible and testable. Data quality rules can be developed for templates.
5.8.3 Ontology (modelling) patterns¶
Ontology patterns (3.3.3) capturing common ontological modelling patterns and solutions are an integral part of the OBI ecosystem (3.5.2).
Ontology patterns (3.3.3) are reusable artefacts to represent structures commonly found in knowledge bases. Just like software design patterns, they are used by modellers to create reusable, maintainable and scalable ontologies. Use of existing ontology patterns (3.3.3) reduces modelling effort. The benefits include reducing mapping effort, reducing potential for errors, and facilitating integration. The resulting standardization enables tooling to be built.
The IDO ontology supports development of both fine and coarse grained modelling patterns. The selection of a particular level of detail is a modelling choice. High and low levels of detail in conceptual models refer to the granularity and specificity with which entities, relationships, and constraints are described.
Models with high levels of detail make use fine-grained modeling patterns. These provide a verbose representation of elements in the ontology. Models with low levels of detail make use of shortcut property (3.2.10) to provide a more compact representation.
5.8.4 Shortcut properties¶
Ontologies in the OBI series support modelling at different levels of detail. This is achieved with shortcut properties. A shortcut property (3.2.10) is an OWL object or datatype property intended as equivalent in meaning to a modelling pattern (3.3.3) that would involve additional entities or classifications if made fully explicit. The meaning of a shortcut property (3.2.10) can in general be partially captured by OWL property chains.
NOTE See examples in ISO 23726-3 Annex B, B.2.2. And B.4.2.
Rules should be in place on how to maintain shortcut properties and keep them synchronised as ontologies are updated.
5.8.5 Data and pattern quality rules¶
A data quality rule defines conditions that data should satisfy to be considered valid, complete, consistent or accurate in a given context.
Data quality rules for RDF data can be expressed using languages such as (but not limited to) SHACL, SPARQL, OWL and associated reasoners. SPARQL, SHACL, and OWL are W3C standards.
SPARQL (SPARQL Protocol and RDF Query Languge) is used to query RDF graphs, update RDF datasets and perform federated queries across multiple endpoints.
SHACL (Shapes Constraint Language) is a language for validating RDF graphs against a set of conditions. Validation is based on SHACL shapes. Each shape specifies a constraint on a class or property and identifies the class or node for which the constraint should be validated.
Reasoners (e.g. HermiT, Pellet, ELK), when applied to OWL ontologies, enforce data quality rules using logical axioms defined in the ontology.
5.8.6 Use of SHACL¶
OWL and SHACL are both part of the same linked data ecosystem. Both OWL and SHACL use graph‑shaped RDF data and are open standards, which allows them to be used across tools and vendors.
However there are differences.
1. OWL operates under the open world assumption (OWA), and SHACL under the closed world assumption (CWA).
2. OWL is descriptive, while SHACL is prescriptive.
3. OWL can be used for reasoning, and SHACL can be used for validation.
SHACL shapes are a closed world complement to OWL and are used to enforce constraints on modelling patterns and individuals in the ontology. These constraints for example 1) make relations and its cardinalities explicit and 2) can be used for automated validation of each RDF instance in the ontology. SHACL shapes developed for reference ontologies or modelling patterns may be shared artefacts.
SHACL shapes are also used by data modellers working with specific enterprise applications for quality assurance. Individual SHACL shapes can be created for different applications. SHACL shapes for application-dependent models are not usually shared outside of the enterprise.
These two levels (application-independent and application dependent) are illustrated in Figure 5.
The upper level of the figure shows a set of classes representing knowledge about a motor and one of its qualities (mass). In OBI a motor is a subClassOf lis:InanimatePhysicalObject and the concept of Mass is a subClassOf lis:PhysicalQuantity. These are facts and these facts are independent of a specific software application.
The middle layer shows one example of instance data. In this case for ex:Motor71 with a mass of 20kg. Other attributes could include power (KW), IP rating, Noise Level (dB), and Frequency (Hz). Each will have instance data and map to classes in the top layer (not shown).
A SHACL shape defined in the application-independent upper lay can be used to validate data at the instance level. For example the SHACL shape on the right hand side of the Figure 5 checks to see if 1) lis:datumUOM has exactly kilogram as unit of measurement that is a valid instance of lis:UnitOfMeasure, and 2) at least one datum value (lis:datumValue) where the datatype is xsd:float.
A SHACL shape can also be used to check if an ontology is following the defined guidelines. For example, it can be checked if the shapes in Figure 5 are in line with the patterns for such shapes defined in guidelines. SHACL shapes can also be converted to OWL restrictions.
The lowest level shows how data modellers building applications can use SHACL shapes to ensure that attributes of interest to a specific application are consistent with the instance data and admissible to the ontology. This is shown by the illustration of different views for a) safety engineer, and b) an electrical engineer. SHACL used in this way links the data modellers to the ontology.
6 Fundamental principles¶
6.1 Direct Semantics consistent¶
Any ontology contained in the OBI series shall be compliant with OWL 2 Direct Semantics.
NOTE See reference in https://www.w3.org/TR/owl2-direct-semantics and refer to Clause 7.
6.2 Resource description framework (RDF and RDFS)¶
Ontologies, ontology modules (3.3.2) and ontology patterns (3.3.3) in the OBI series shall conform to the W3C Linked Data standard and protocols.
6.3 Digital resource¶
Each standard describing an ontology in the OBI series shall be accompanied by a digital file containing a serialisation of all the classes and properties described in the standard document.
Each reference and application ontology in the OBI series shall be accompanied by a use case, competency questions, and digital file with instance data to demonstrate reasoning and compliance with the ontological commitments in IDO. Ontologies and use cases in the OBI series should be relevant for industry.
6.4 Axioms, rules and constraints¶
Resources in an OBI series ontology should be defined to constrain the meaning of that resource by specifying axioms, rules, properties and relationships necessary to make the resource semantically distinct from all the other resources. Constraints should define criteria for an individual's membership in classes, for being related by object or data property, and for the purpose of any individual.
The extent of axiom (3.2.1) used should consider the intended use of the ontology.
NOTE 1 Some axioms are used for consistency checking and to avoid duplication but over-use of axioms can impact reasoning performance and result in complex structures.
NOTE 2 Consideration of competency questions (3.3.1) can inform axiomisation choices.
Where rules in languages other than OWL are contained in an OBI series part, evidence that the application of the rules will yield results consistent with the IDO upper ontology (3.1.4) should be provided.
NOTE 3 Rules for checking correctness are considered complementary to OWL 2 consistency checking, not a replacement.
NOTE 4 As an example, the generation of rules in other languages (such as the SPARQL 'CONSTRUCT' statement).
6.5 Ontology alignment, review and documentation¶
6.5.1 Ontology alignment¶
Each class in an OWL ontology or reference data library (3.3.5) contained in the OBI series shall be a direct or indirect subclass of an IDO class.
This requirement can be fulfilled in one of the following ways: 1) By subclassing directly from the IDO upper ontology (3.1.4); 2) By subclassing from an existing IDO-compliant reference ontology, (3.1.3); or 3) By subclassing from an ontology module (3.3.2) within the OBI series.
Each property in an OWL ontology or reference data library (3.3.5) contained in the OBI series should extend as sub-properties whenever appropriate.
This can be achieved 1) directly from the IDO upper ontology (3.1.4), or 2) from an existing IDO compliant reference ontology, (3.1.3) or 3) from an existing OBI series ontology module (3.3.2), or if no term is suitable from 4) an external reference ontology (3.1.3) .
New OBI series classes and properties should not redefine, or duplicate classes and properties defined in other OBI series ontologies.
The highest level of detail (conceptual representation) should be used when assessing ontology alignment (3.2.7)
6.5.2 Review of ontology alignment decisions¶
All ontology alignment (3.2.7) decisions for artefacts in the ISO 23726 series shall be reviewed and approved by a maintenance agency (3.5.1).
All ontology alignment (3.2.7) decisions for artefacts created by external groups that seek to be recognised as part of the OBI series shall be reviewed and approved using processes equivalent to this of the ISO-recognised maintenance agency (3.5.1).
NOTE In certain cases a superproperty is created that is outside of the IDO, an IDO compliant reference ontology (3.1.3), or other existing OBI artefact (3.5.3) . This is a design choice as it is not practically possible or desirable to provide an exhaustive set of super-relations for all future needs.
Details to assist in consistent treatment of misalignment situations will be developed in guidance documents.
EXAMPLE
The following are some examples of outcomes from an ontology alignment (3.2.7) review.
a) There is complete alignment and the proposed ontology adopts the OBI term and namespace.
b) The proposed ontology creates the term in their own namespace and uses a rdfs:seeAlso property to create a link between their ontology and the relevantOBI artefact (3.5.3) .
c) The proposed ontology retains a concept with a different interpretation from OBI, documents this in their metadata (3.4.3) and follows the ontology conflict clause in 6.8.
6.5.3 Ontological conflicts¶
Ontological commitments (3.2.6) for ontologies in external reference ontologies should not conflict with modelling class restrictions (3.2.3) in existing OBI ontologies. Where such conflicts exist, solutions to map between the artefact in the external source to the existing OBI ontologies shall be proposed and documented as described in 6.6.3.
6.5.4 Documentation on ontology alignment¶
Each alignment should be expressed as an ontology that:
1. imports IDO, other relevant existing OBI modules and the external ontology,
2. asserts subclass or subproperty relationships and/or axioms, and
3. introduces new entities as needed.
Each alignment shall be documented as follows.
1. Version and availability - this describes which version of the external ontology has been selected for alignment, and where that version may be obtained. This can be achieved using versioned imports.
2. Namespaces - namespaces that are needed for the alignment.
3. Alignment diagrams - diagrams are provided to describe the details of each mapping.
4. Documentation of choices that may be controversial or in need of clarification or testing.
Documentation on alignment shall use annotation properties described in Clause 8 and Clause 9
6.6 Annotation¶
Ontology models should be documented with metadata (3.4.3) described in Clause 8.
Other annotations can be included but these are as an addition to the ones listed in Clause 8 and should be governed by a documented process.
Classes and properties in an ontology should be documented with metadata (3.4.3) listed in Clause 9.
Other annotations can be included but these are as an addition to the ones listed in Clause 9 and should be governed by a documented process.
6.7 Versioning and storage of artefacts¶
The ontologies that are part of the OBI series shall be version controlled.
Each versioned OBI series ontology should have stable IRIs (3.4.2) .
Annotations provided in 9.5 and 9.6 shall be used to document ontologies and their evolution.
NOTE Classes, properties, individuals and axioms in an ontology do not have version numbers. This is to ensure that the IRIs of the resources defined in an ontology are stable independent from the version of the ontology.
6.8 Ontology modularisation¶
Ontology developers should make modular ontologies designed for re-use for different applications and ease of ontology maintenance. Justification of the inclusions and exclusions in the module should be captured using annotation properties described in Clause 9.3. Import statements pointing to specific versions of re-used ontologies should be used to enure that the resolved IRIs are correctly referring to the versioned ontology. When ontologies are re-used there should be a clear hierarchy of imports to avoid circular imports.
6.9 Ontology evaluation¶
All ontologies in the OBI series shall have suitable ontology quality tests. These tests should provide evidence of ontology evaluation with, for example, model checking processes, syntax checkers, and reasoners.
Processes for ontology evaluation of ISO-managed artefacts shall be reviewed and approved by the ISO-recognised maintenance agency (3.5.1).
Processes for ontology evaluation of OBI artefacts (3.5.3) managed by external groups are the responsibility of the external group and the evaluation should be done to a standard equivalent to that of the maintenance agency (3.5.1).
Examples of issues examined by model checkers include but are not limited to those below.
EXAMPLE 1
The presence of polysemous elements - ontology elements whose name has different meaning and represents more than one conceptual idea.
EXAMPLE 2
Creation of synonyms when two or more classes that have the same meaning but different names. Such as common synonyms for foundation: base, footing and substructure.
6.10 Ontology maintenance agencies and process¶
6.10.1 Ontology maintenance agency¶
A maintenance agency (3.5.1) is responsible for maintaining the publishing updates to digital versions of artefacts that are part of the ISO 23726 series.
NOTE 1 ISO 23726 managed documents will have a regular maintenance process at a time interval prescribed by ISO.
External groups seeking to propose and manage OBI artefacts (3.5.3) shall have a documented and auditable quality management process to ensure conformance with the principles in Clause 6. OBI artefacts (3.5.3) created by external groups shall be managed using processes equivalent to those of a maintenance agency.
NOTE 2 Independent review by an external ontology expert is an option.
6.10.2 Maintenance process¶
A maintenance process shall be documented by a maintenance agency (3.5.1).
EXAMPLE
Examples of questions addressed in the maintenance process include the following.
a) How will digital versioning be managed?
b) How will a change in the meaning of a term on previous releases be managed?
c) Where and how will documentation on the purpose of an ontology, ontology module (3.3.2), or other artefact be captured and maintained?
d) How are issues identified and changes tracked?
e) What sort of testing is appropriate on the impact of the changes on existing ontologies in use in industry?
f) How will migration from the predecessor version to the current version be managed?
g) Under what circumstances will an artefact need an IRI (3.4.2) and annotation properties (3.2.2) ?
h) How will ontology alignment (3.2.7) be checked and assured?
i) How will updates to versions of imported ontologies be managed?
This process shall include mechanisms for feedback from users.
6.10.3 OBI artefact ownership¶
OBI artefacts issued by the ISO OBI standards (ISO 23726) community shall be managed by the maintenance agency (3.5.1) as shown in Figure 2.
OBI series artefacts issued by external group organisations shall have independent evaluation of their alignment using processes equivalent to those in the maintenance agency to ensure conformance with the principles in Clause 6.
7 Grounding in mathematical logic¶
This clause justifies why OWL 2 is chosen for use in ISO 23726 ontologies. OWL 2 is based on description logics (DL) which are fragments of First-order logic (FOL). FOL is a mathematical framework, specifically a formal system used in mathematical logic to express statements about structures as follows.
1. Formal Language: FOL provides a precise way to define mathematical statements using quantifiers (∀, ∃), logical connectives (∧, ∨, →, ¬), and predicates.
2. Inference System: It includes rules for reasoning (deduction), such as modus ponens and universal instantiation.
3. Model Theory: FOL expresses the meaning (semantics) of logical statements by defining structures that satisfy them.
Specifically, OWL 2 corresponds closely to SROIQ(D), a highly expressive (3.2.5), decidable DL. This enables automated reasoning in knowledge representation such as satisfiability checking and automated classification.
8 Ontology namespace, formatting and annotation guidelines¶
8.1 General¶
This section describes formatting and annotation guidelines for ontology constructs in the OBI ecosystem (3.5.2). These guidelines are intended to ensure a consistent approach to formatting across the enterprise ontology (3.1.2) user base.
8.2 Ontology Namespace¶
Ontologies created and managed by under the OBI standard should use a namespace provided by the maintenance agency (3.5.1) - as listed by ISO on https://www.iso.org/maintenance_agencies.html
The identifier structure for an ontology is made up of two parts a) a namespace and b) a local name.
http://xxx.hostorganisation.org/ontology/ontologyname/ont/core
As an example for the IDO Core ontology ‘http://rds.posccaesar.org/ontology/lis14/ont/core’ the namespace is ‘http://rds.poscaesar.org/ontology/lis14/ont/’ and the local name is ‘core’.
The namespace is decomposed into a scheme name (http), domain name (rds/poscaesar.org), ontology name (lis14), an ontology module identifier (ont).
The domain name component of the ontology identifier consists of:
-
Subdomain: A prefix to the domain name, which may be used (e.g., ‘xxx’ in xxx.hostorganisation.org).
-
Second-Level Domain (SLD ) : The primary domain name, which shall be present (e.g., ‘hostorganisation’ in hostorganisation.org).
-
Top-Level Domain (TLD): The suffix of the domain, which shall be present (e.g., ‘.org’ in hostorganisation.org).
Versioning of the ontology will be managed by a version extension at the end of the URI (3.4.5) , such as https://rds.posccaesar.org/ontology/lis14/ont/core/3.0/
Ontologies created and managed by external groups should use a suitable namespace. The namespace format should follow the following format.
http://xxx.hostorganisation.org/ontology/ontologyname/ont/core/versionnumber
8.3 Ontology sub-directory structure¶
For extension ontologies in a series some examples are given below. The local names in each of these examples are for illustrative purposes.
For ontology extensions:
Generic format http://xxx.hostorganisation.org/ontology/ontologyname/ont/ext
For rules http://xxx.hostorganisation.org/ontology/ontologyname/rules
For documentation http://xxx.hostorganisation.org/ontology/ontologyname/doc
8.4 Prefixes¶
Namespace prefixes for ontologies in OWL should be declared in each ontology artefact in the OBI series.
EXAMPLE
1. Prefix: rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns#
2. Prefix: ssn: http://www.w3.org/ns/ssn/
3. Prefix: qudt: http://qudt.org/schema/qudt/
8.5 Namespace for OBI resources¶
Resources such as class, relation, property or individual shall use a dedicated namespace. The goal is to provide a single, stable namespace for resource identifiers, independent of how ontology modules are organized over time and to supports adding, splitting, or reorganizing ontology modules under .../ont/… without changing resource identifiers.
The use of multiple namespaces in the OBI series is a deliberate design choice aligned with widely adopted Linked Data and ontology publication practices.
Different namespaces are used to make different kinds of things easy to identify, govern, publish, and evolve without disrupting established usage.
OBI resources should use a namespace with consistent formating defined by the ontology developer. The namespace for resources shall be different from the namespace for the ontology.
Example: 'http://xxx.hostorganisation.org/ontology/ontologyname/xxx/' where name/xxx/ is defined by the ontology developer. If following this format the xxx must not be ‘/ont/’ as the ‘ont/’ part is reserved for ontologies not for resources.
Note the IDO ontology uses ‘/rdl/’ for resources in the IDO ontology http://rds.posccaesar.org/ontology/lis14/rdl/.
8.6 Class names¶
Class names and labels in IDO should be human readable.
Class names in other OBI series ontologies should be uninformative but may be human readable.
If a class name is human readable it shall be a noun group in singular, given in PascalCase (also known as UpperCamelCase).
The rdfs:label without language tag shall be a noun group in singular, given in PascalCase (also known as UpperCamelCase).
No acronyms should be used except those in the dictionary, such as RADAR, which should be converted to Radar in PascalCase.
Annotation labels for class names with language tags (e.g. Japanese, Chinese, German) should be human readable.
EXAMPLE
The rdfs:label for the class "physical object" can be written as follows using a postscript to specify language variants.
1. rdfs:label "PhysicalObject"
2. rdfs:label "Physical object"@en
3. rdfs:label "Physikalisches Objekt"@de
8.6 Object property names¶
Object property names in IDO, the upper ontology, shall be human readable.
Object property names in other OBI series ontologies should be uninformative but may be human readable.
If an object property name is human readable it shall be verb phrases in third person singular in present tense, in lowerCamelCase.
The rdfs:label shall be verb phrases in third person singular in present tense, in lowerCamelCase.
Annotation labels for object property names with language tags (e.g. Japanese, Chinese, German) should be human readable.
One annotation label shall be in English.
EXAMPLE : The object property lis:hasArrangedPart in http://rds.posccaesar.org/ontology/lis14/rdl/hasArrangedPart
8.7 Data property names¶
Data property names in IDO, the upper ontology, shall be human readable.
Data property names in other OBI series ontologies should be uninformative but may be human readable.
If an data property name is human readable it shall be a noun group in singular, in lowerCamelCase, the first word lower case and each subsequent word capitalized with no separation or punctuation between words.
The rdfs:label shall be a noun group in singular, in lowerCamelCase, the first word lower case and each subsequent word capitalized with no separation or punctuation between words.
Annotation labels for data property names with language tags (e.g. Japanese, Chinese, German) should be human readable.
One annotation label shall be in English.
9 Annotation properties¶
9.1 General¶
Artefacts in the OBI series make use of existing annotation properties used for Semantic Web (3.4.4) data and applications. As indicated by the respective prefixes these are defined in the following vocabularies.
1. rdfs: RDF Schema, W3C Recommendation, 2014 [3]
2. skos: Simple Knowledge Organization System Reference, W3C Recommendation, 2009 [4]
3. cmns-av: Commons Annotation Vocabulary, Open Applications Group, 2022 [5]
4. iof‑av: Industrial Ontology Foundry Annotation Vocabulary, Open Applications Group, 2023 [6]
5. pav: Provenance, Authoring and Versioning, Ciccarese et al., J. Biomedical Semantics 4, 2013 [7]
6. dc:, dcterms: Dublin Core Metadata Initiative Recommendation, 2020 [8]
Annotation property definitions shall not start with an `a' or 'the'.
9.2 Required annotation properties¶
9.2.1 rdfs:label¶
definition instance of rdf:Property used to provide a human-readable version of a resource's name
usageNote every ontology class, object property, data property and SHACL shape in OBI shall have an rdfs:label
usageNote labels shall be unique across all OBI ontologies and should be unique across all imported non-OBI ontologies in a given natural language
usageNote lables for other languages may be provided, but if so they must be language tagged
seeAlso IOF Annotation Property Guide V2.3
isDefinedBy https://www.w3.org/2000/01/rdf-schema#
9.2.2 skos:definition¶
definition definition written in plain text for human understanding
usageNote exactly one natural language definition shall be given for each ontology class, object property, and data property
usageNote natural language definition should be consistent with any formal definition or elucidation
usageNote definition should be understandable by a practitioner in the industrial domain
usageNote definition should adhere to ISO 704 rules and requirements for terminology
seeAlso IOF Annotation Property Guide V2.3
isDefinedBy http://www.w3.org/2004/02/skos/core#definition
9.3 Annotation properties for additional metadata¶
9.3.1 dcterms:abstract¶
definition summary of the resource
usageNote describes an artifact such as a controlled vocabulary, ontology, or other similar resource
subPropertyOf dcterms:description
isDefinedBy http://purl.org/dc/terms/abstract
9.3.2 skos:example¶
definition supplies an example of the use of a concept
usageNote all classes in an ontology should have a skos:example
subPropertyOf skos:note
isDefinedBy http://www.w3.org/2004/02/skos/core#example
EXAMPLE
lis:Role
example The role an individual person takes in a work situation, such as a manager. A student role.
lis:Location
example An outdoor plant area, an opening in a wall, the space inside an enclosure
9.3.3 skos:prefLabel¶
definition preferred lexical label for the ontology resource, in a given language
usageNote a resource has no more than one value of skos:prefLabel per language tag. Disjoint with skos:altLabel
subPropertyOf rdfs:label
isDefinedBy http://www.w3.org/2004/02/skos/core#prefLabel
9.3.4 skos:altLabel¶
definition alternative lexical label for the ontology resource
usageNote used for acronyms, abbreviations, spelling variants, and irregular plural/singular forms. Disjoint with skos:prefLabel
subPropertyOf rdfs:label
isDefinedBy http://www.w3.org/2004/02/skos/core#altLabel
9.3.5 cmns-av:synonym¶
definition word that means exactly or nearly the same as another word in the same language
usageNote used to provide an alternate or multiple alternate words to the skos:label. For example, overhaul is a synonym of repair. ISO 1087:2019 provides the example `synonmy exists between deuterium and heavy hydrogen'
subPropertyOf skos:altLabel
adaptedFrom iof-av:synonym
isDefinedBy https://www.omg.org/spec/Commons/AnnotationVocabulary
9.3.6 cmns-av:abbreviation¶
definition designation formed by omitting parts from the full form of a term that denotes the same concept
subPropertyOf cmns-av:synonym
example chemical Symbols: H, O, Mg; units of Measure: Km, Kg, G
isDefinedBy https://www.omg.org/spec/Commons/AnnotationVocabulary
9.3.7 cmns-av:acronym¶
definition abbreviation that is made up of the initial letters of the components of the full form of a term or proper name or from syllables of the full form
example laser, ISO, GATT, UNESCO, UNICEF
subPropertyOf cmns-av:abbreviation
isDefinedBy https://www.omg.org/spec/Commons/AnnotationVocabulary
9.3.8 cmns-av:symbol¶
definition abbreviation that is a design or mark, or other non-alpha-numeric character(s) conventionally used to represent something, such as a currency or mathematical sign or operator
subPropertyOf cmns-av:synonym
isDefinedBy https://www.omg.org/spec/Commons/AnnotationVocabulary
9.3.9 rdfs:comment¶
definition textual comment to clarify the meaning of RDF properties and classes
usageNote this annotation should be avoided when documenting OBI ontologies. Instead authors should use skos:scopeNote 9.3.12, iof-av:explanatoryNote 9.3.13, iof-av:usageNote 9.3.14 when additional information about the OBI resource is needed
isDefinedBy http://www.w3.org/2000/01/rdf-schema#
9.3.10 rdfs:seeAlso¶
definition indicates a resource that might provide additional information about the subject resource
isDefinedBy http://www.w3.org/2000/01/rdf-schema#
9.3.11 rdfs:isDefinedBy¶
definition indicates a resource defining the subject resource
usageNote may be used to indicate an RDF vocabulary in which the resource is described
subPropertyOf rdfs:seeAlso
isDefinedBy http://www.w3.org/2000/01/rdf-schema#
9.3.12 skos:scopeNote¶
definition clarifies the meaning and/or use of a concept
usageNote clarifies the scope of use of an OBI artefact. It supplies some, possibly partial, information about the intended meaning of a concept, especially as an indication of how the use of a concept is limited in indexing practice
example ex:microwaveFrequencies skos:scopeNote used for frequencies between 1GHz to 300Ghz"@en
isDefinedBy http://www.w3.org/2004/02/skos/core#scopeNote
9.3.13 iof-av:explanatoryNote¶
definition provides additional explanatory information about a resource
isDefinedBy https://spec.industrialontologies.org/ontology/core/meta/AnnotationVocabulary/explanatoryNote
9.3.14 iof-av:usageNote¶
definition provides information about how a given OBI resource is used in context
seeAlso cmns-av:usageNote
isDefinedBy https://spec.industrialontologies.org/ontology/core/meta/AnnotationVocabulary/usageNote
9.4 Annotation properties for formal and semi-formal definitions¶
9.4.1 General¶
Formal and semi-formal definitions make definitions explicit. They should be provided for classes but are not a requirement.
9.4.2 cmns-av:logicalDefinition¶
definition form of a formal expression, such as the mathematical or logic representation, for the resource
subPropertyOf skos:definition
9.4.3 iof-av:isPrimitive¶
definition boolean flag indicating that necessary and sufficient conditions are not provided at this time
usageNote only applies to classes
seeAlso IOF Annotation Property Guide V2.3
isDefinedBy https://spec.industrialontologies.org/ontology/core/meta/AnnotationVocabulary/isPrimitive
9.4.4 iof-av:primitiveRationale¶
definition reason why the necessary and sufficient conditions were not or could not be provided at this time
subPropertyOf skos:note
usageNote only applies to classes
seeAlso IOF Annotation Property Guide V2.3
isDefinedBy https://spec.industrialontologies.org/ontology/core/meta/AnnotationVocabulary/primitiveRationale
9.4.5 iof-av:firstOrderLogicDefinition¶
definition formal definition of construct using predicate logic semantics
subPropertyOf skos:note
usageNote shall provide individually necessary and sufficient conditions
usageNote shall occur exactly once if the term is not primitive (isPrimitive is false)
seeAlso IOF Annotation Property Guide V2.3
isDefinedBy https://spec.industrialontologies.org/ontology/core/meta/AnnotationVocabulary/firstOrderLogicDefinition
9.4.6 iof-av:semiFormalNaturalLanguageDefinition¶
definition transitional definition expressing first-order logic definition using semantics definition understandable by ontologically knowledgable domain practitioner without predicate logic semantics
subPropertyOf skos:note
usageNote only applies to classes
seeAlso IOF Annotation Property Guide V2.3
isDefinedBy https://spec.industrialontologies.org/ontology/core/meta/AnnotationVocabulary/semiFormalNaturalLanguageDefinition
9.4.7 iof-av:firstOrderLogicAxiom¶
definition axiom of construct using predicate logic semantics
usageNote may have more that one first order logic axiom annotation
usageNote only applies to classes
seeAlso IOF Annotation Property Guide V2.3
9.4.8 iof-av:semiFormalNaturalLanguageAxiom¶
definition transitional definition expressing first-order logic axiom using semantics understandable by ontologically knowledgable domain practitioner without predicate logic semantics
usageNote may have more that one semi-formal natural language logic axiom annotation
usageNote only applies to classes
seeAlso IOF Annotation Property Guide V2.3
isDefinedBy https://spec.industrialontologies.org/ontology/core/meta/AnnotationVocabulary/semiFormalNaturalLanguageAxiom
9.5 Annotation properties for provenance and versioning¶
9.5.1 pav:previousVersion¶
isDefinedBy http://purl.org/pav/
9.5.2 pav:hasEarlierVersion¶
isDefinedBy http://purl.org/pav/
9.5.3 pav:derivedFrom¶
isDefinedBy http://purl.org/pav/
9.5.4 pav:lastUpdatedOn¶
isDefinedBy http://purl.org/pav/
9.5.5 dcterm:source¶
isDefinedBy http://purl.org/dc/terms
9.5.6 iof-adaptedFrom¶
definition definitive source of the subject resource
subPropertyOf dcterm:source
isDefinedBy https://spec.industrialontologies.org/ontology/core/meta/AnnotationVocabulary/adaptedFrom
9.5.7 iof:directSource¶
definition source for the resource that was modified to create the subject resource
subPropertyOf dcterm:source
isDefinedBy https://spec.industrialontologies.org/ontology/core/meta/AnnotationVocabulary/directSource
9.5.8 iof-av:counterExample¶
definition example that refutes or disproves a concept in some scenario and is intended to demonstrate how the concept might be misused
subPropertyOf skos:note
isDefinedBy https://spec.industrialontologies.org/ontology/core/meta/AnnotationVocabulary/counterExample
9.5.9 dcterms:title¶
isDefinedBy http://purl.org/dc/terms
9.5.10 dcterms:licence¶
isDefinedBy http://purl.org/dc/terms
9.5.11 dcterms:description¶
isDefinedBy http://purl.org/dc/terms
9.5.12 dcterms:issued¶
isDefinedBy http://purl.org/dc/terms
9.5.13 dcterms:contributor¶
isDefinedBy http://purl.org/dc/terms
9.5.14 dcterms:creator¶
isDefinedBy http://purl.org/dc/terms
9.5.15 pav:createdBy¶
isDefinedBy http://purl.org/pav/
9.5.16 pav:contributedBy¶
isDefinedBy http://purl.org/pav/
9.5.17 dcterms:modified¶
isDefinedBy http://purl.org/dc/terms
9.5.18 dcterms:publisher¶
isDefinedBy http://purl.org/dc/terms
9.5.19 dcterms:rights¶
isDefinedBy http://purl.org/dc/terms
9.5.20 cmns-av:copyright¶
definition exclusive legal right, given to an originator or an assignee to print, publish, perform, film, or record literary, artistic, or musical material, and to authorize others to do the same
subPropertyOf dcterms:rights
isDefinedBy https://www.omg.org/spec/Commons/AnnotationVocabulary
9.6 Annotation properties for representing resource evolution¶
9.6.1 lis:originatesFrom¶
definition associates a resource with the resource it originates from
isDefinedBy https://rds.posccaesar.org/ontology/lis14/rdl/originatesFrom/
9.6.2 lis:transformedFrom¶
definition the current resource originates from another resource by transformation
subpropertyOf lis:originatesFrom
isDefinedBy https://rds.posccaesar.org/ontology/lis14/rdl/transformedFrom/
9.6.3 lis:mergedFrom¶
definition the current resource originates from one or several other resources by merging.
subpropertyOf lis:originatesFrom
isDefinedBy https://rds.posccaesar.org/ontology/lis14/rdl/mergedFrom/
9.6.4 lis:splitFrom¶
definition the current resource originates from another ontology resource by splitting.
subpropertyOf lis:originatesFrom
isDefinedBy https://rds.posccaesar.org/ontology/lis14/rdl/splitFrom/