Procedural Knowledge Ontology (PKO)

• PKO is a formal, modular ontology that distinguishes between procedure specifications and executions, ensuring traceability and effective version control.
• It integrates established standards like PROV-O, P-Plan, and OWL-Time to model industrial workflows, safety checklists, and process mining with precision.
• PKO is engineered via the Linked Open Terms methodology, promoting high interoperability and seamless integration into AI- and data-driven industrial systems.

The Procedural Knowledge Ontology (PKO) is a formal, extensible framework designed to enable the explicit, machine-interpretable representation of procedural knowledge—such as industrial processes, workflows, safety checklists, and operational routines—across heterogeneous domains. PKO addresses the pressing industrial need to make tacit or unstructured “how-to” knowledge (previously confined to operator experience, text documents, or disparate legacy IT) accessible to AI- and data-driven systems, by defining a modular ontology that sharply distinguishes between procedure specifications and procedure executions, and aligns with established standards for interoperability, traceability, and lifecycle governance (Carriero et al., 26 Mar 2025).

1. Ontological Structure and Core Vocabulary

PKO is modular, comprising a “core” and an “industry” extension, and reuses established ontologies: PROV-O (provenance), P-Plan (plans and steps), DCAT/DCMI (resource metadata), OWL-Time (temporal modeling), ADMS (asset metadata), Metadata4Ing (resources), and PRO (time-bounded roles). Its design is informed by ~54 competency questions and >60 fact patterns from diverse industrial use cases (notably in manufacturing, automation, and safety–critical operations).

The principal classes and object properties in PKO are:

Class	Definition	Axiomatic Formulation
pko:Procedure	Abstract, versionable plan comprising steps to achieve an outcome	$pko:Procedure \sqsubseteq pplan:Plan$, $$pko:Procedure \sqsubseteq \exists\, pko:hasStep.\,pplan:Step$$
pplan:Step	Atom or composite unit of work within a procedure	$pplan:Step \sqsubseteq prov:Activity$
pko:ProcedureExecution	An enacted instance of a procedure	$pko:ProcedureExecution \sqsubseteq prov:Activity$
pko:StepExecution	Enacted instance of a pplan:Step within a procedure execution	$pko:StepExecution \sqsubseteq prov:Activity$
dcat:Resource	Referenced asset (document, image, manual, tool, PPE)	Reused verbatim
pro:RoleInTime	Agent's role/affiliation during a specified interval	$pro:RoleInTime \sqsubseteq prov:AgentRole$
pko:ExpertiseLevel	Level of skill or qualification applicable to an agent or step	$pko:ExpertiseLevel \sqsubseteq rdfs:Class$

Key object properties structuring procedural knowledge include pko:hasStep (procedure/specification decomposition), nextStep (sequencing), requiresAction, requiresTool, requiresPPE/Padlock (resource and constraint links), hasVersion/nextVersion/previousVersion (versioning), hasStepExecution/hasProcedureExecutionStatus (execution and monitoring), and feedback-related links (askedQuestion, reportedIssue) (Carriero et al., 26 Mar 2025).

2. Specification–Execution Separation and Traceability

A defining feature of PKO is its explicit separation of “procedure specification” (the abstract, potentially versioned recipe of steps and structure) from “procedure execution” (the concrete realization, with documented agents, timestamps, deviations, and outcomes). This separation supports full traceability, versioning, and analytics over both prescribed and enacted processes.

For example, a procedure may be versioned and linked to prior editions, steps annotated with expected duration, resource dependencies, and role assignments. Each execution instance (pko:ProcedureExecution) is connected to the specification version it realizes, and records the full sequence of pko:StepExecutions with associated temporal properties, executing agents, errors, questions, and corrective actions. Such structure enables queries regarding “who performed which step, when, and with what deviations,” and supports analytics over compliance, efficiency, and incident response (Carriero et al., 26 Mar 2025).

3. Alignment with Related Ontologies and Comparison

Unlike BPMN-based ontologies (which are criticized for conflating specification and enactment, lacking version control, and having weak resource annotation), PKO leverages P-Plan for plan/step decomposition, PROV-O for provenance, and OWL-Time for temporal annotation. Its reliance on persistent URIs, reuse of DCAT and DCMI for resource description, and PRO for roles yields immediate interoperability with linked-data systems and company-internal KGs.

PKO inherits its architectural lineage and some key relation names from earlier minimalistic “Process Ontologies” such as prohow#has_step/has_method/requires (as in (Pareti et al., 2016) and (Pareti et al., 2014)), but augments these with richer execution modeling and validation-ready semantics. In creative domains (e.g., web design), ontologies such as the CPK model (Yang et al., 2019) emphasize five classes (Goal, Workflow, Action, Command, Usage) and focus on decomposing and annotating the mapping from intention to command invocation, which PKO generalizes to broader industrial contexts.

4. Engineering Methodology and Quality Assurance

PKO was engineered via the Linked Open Terms (LOT) methodology: eliciting requirements from industrial partners, formalizing conceptual diagrams (Chowlk notation), translating into OWL/Turtle, and systematically documenting all elements via rdfs:label, skos:scopeNote, and rdfs:comment. Namespace management, permanent URIs (via w3id.org/pko), semantic versioning, and open governance (GitHub, Zenodo DOIs, Widoco documentation) are implemented to ensure long-term maintainability and transparency (Carriero et al., 26 Mar 2025).

Ontology quality is validated using the OOPS! Pitfall Scanner (no critical pitfalls detected; minor issues such as missing rdfs:label on some external terms addressed via documentation), and assessed against Vrandečić’s eight criteria (accuracy, clarity, completeness, adaptability, conciseness, efficiency, consistency, organizational fitness), all yielding positive scores.

5. Extraction, Instantiation, and Example Modeling Patterns

Procedures are instantiated into PKO by either manual entry of specification data, semi-automated form tools, or automated extraction from textual/legacy documents. For demonstration, a Lock-Out Tag-Out (LOTO) safety procedure is represented as:

• :LOTO-condenser-v2 a pko:Procedure ; pko:previousVersion :LOTO-condenser-v1 ; pko:hasProcedureStatus pko:Approved ; pko:hasStep :Step1,...,:Step4.
• :Step4 a pplan:Step ; pko:requiresPadlock padlock:StandardPadlock ; pko:expectedDuration "PT120S"^^time:Duration ; pko:nextStep :Step5.
• :Exec1-S4 a pko:StepExecution ; prov:wasAssociatedWith :Step4 ; prov:startedAtTime "2024-10-11T12:33:00Z" ; prov:endedAtTime "2024-10-11T12:36:00Z" ; pko:executedBy :JohnDoe ; pko:askedQuestion :Q1.

This instantiation pattern supports queries over sequences, dependencies, agent activity, deviations (issues, questions), and time-based analytics. A plausible implication is that such patterning facilitates KPI dashboards, process mining, and automatic FAQ extraction from procedure execution logs (Carriero et al., 26 Mar 2025).

6. Applications, Tooling, and Industrial Impact

PKO undergirds multiple industrial deployments:

• Rapid Triples Elicitation: A web tool directly authoring PKO-compliant RDF from form inputs, enabling domain-expert-driven population of procedure KGs without ontology expertise.
• Conversational Execution Assistant: A Retrieval-Augmented Generation (RAG) pipeline uses PKO-modeled procedures to deliver context-aware, stepwise guidance with full traceability to source triples, mitigating LLM hallucination.
• Governance and Analytics: Tools perform version-diff analysis, KPI monitoring (e.g., flagging steps where observed duration ≫ expected duration), FAQ mining from execution feedback, and enable digital twins by linking procedural steps to asset models and service catalogs.

This architecture demonstrably increases coverage, traceability, and operational insight, effectively transforming “how-to” knowledge into actionable, high-reliability knowledge graphs (Carriero et al., 26 Mar 2025).

7. Outlook and Evolution

PKO is positioned for further extension, with provision for SHACL-based validation rules, alignment with ISO 18629 PSL, and expansion into domains such as chemical processes and logistics. Its lightweight semantics support straightforward SPARQL querying and federated use, while modular alignment with external standards ensures substantial adaptability and long-term organizational fitness. The decoupling of specification and execution models, extensive reuse, and evidence of coverage and precision across use cases mark PKO as state-of-the-art for industrial procedural knowledge representation (Carriero et al., 26 Mar 2025).