Core Ontology for Petroleum Installations · INF-UFRGS-Ontologies · CNPq INF-UFRGS-ENERGIA inf.ufrgs.br/ontologies/copi dee69df
ISA 5.1 symbol for three way valve
validated necessary
three way valve
IRI: http://www.inf.ufrgs.br/ontologies/copi#Threewayvalve
Generated on 2026-09-08
Natural Language Definition
EN
A three way valve is a valve with three flow-path ports instead of the usual two, used to divert one inlet stream to either of two outlets or to mix two inlet streams into one outlet.
PT-BR
Uma valvula de tres vias e uma valvula com tres portas de passagem de fluxo em vez das duas usuais, usada para desviar um fluxo de entrada para uma de duas saidas ou para misturar dois fluxos de entrada em uma saida.
Formal Axioms
Semi-formal (Aristotelian)
Every three way valve is a valve that bears a flow control function and has a port as a component part, distinguished from a generic valve by an additional flow-path participant in its process signature.
First-Order Logic Theory
Loading…
▸ Stored override ∀x (ThreeWayValve(x) → Valve(x) ∧ ∃f (FlowControlFunction(f) ∧ bearerOf(x,f)) ∧ ∃p (Port(p) ∧ hasComponentPartAtAllTimes(x,p)))
OWL 2 / Turtle
@prefix copi: <https://www.inf.ufrgs.br/ontologies/copi/> . @prefix : <https://www.inf.ufrgs.br/ontologies/copi/> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix bfo: <http://purl.obolibrary.org/obo/> . @prefix iof-core: <https://spec.industrialontologies.org/ontology/construct/> . @prefix iof-av: <https://spec.industrialontologies.org/ontology/annotation/> . @prefix skos: <http://www.w3.org/2004/02/skos/core#> . @prefix qudt: <http://qudt.org/schema/qudt/> . @prefix dcterms: <http://purl.org/dc/terms/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix apv: <http://inf.ufrgs.br/ontologies/apv#> . ### COPI — Core Ontology for Petroleum Installations ### Class module: ThreeWayValve <https://www.inf.ufrgs.br/ontologies/copi> rdf:type owl:Ontology ; dcterms:title "Core Ontology for Petroleum Installations (COPI)"@en ; dcterms:title "Ontologia Core para Instalações de Petróleo (COPI)"@pt-br ; dcterms:description "BFO/IOF-Core conformant ontology of equipment classes for petroleum production plants, developed using the five-step RDL enrichment method."@en ; skos:scopeNote "Material artifacts (bfo:material_entity) that (i) are part of a petroleum production plant, and (ii) bear at least one function whose realization involves the transport (e.g. production and injection), processing (separation and other processes), control, monitoring, measurement, containment or offloading of material or energy."@en ; skos:scopeNote "Artefatos materiais (bfo:material_entity) que (i) fazem parte de uma planta de produção de petróleo, e (ii) possuem ao menos uma função cuja realização envolve o transporte (p. ex. produção e injeção), processamento (separação e outros processos), controle, monitoramento, medição, contenção ou escoamento de material ou energia."@pt-br ; skos:scopeNote "COPI provides high-level equipment categories defined by function to demonstrate the defined-class mechanism. Equipment subtypes are annotated with references to CFIHOS and PCA RDL terms. COPI is not a reference data library; organizations should use CFIHOS, PCA RDL, or ISO 14224 for comprehensive equipment classification."@en ; skos:scopeNote "COPI fornece categorias de alto nível de equipamentos definidas por função para demonstrar o mecanismo de classe definida. Os subtipos de equipamentos são anotados com referências aos termos do CFIHOS e do PCA RDL. COPI não é uma biblioteca de dados de referência; organizações devem utilizar o CFIHOS, o PCA RDL ou a ISO 14224 para classificação abrangente de equipamentos."@pt-br ; owl:versionInfo "1.1.0" ; owl:imports <https://spec.industrialontologies.org/ontology/core/Core/> ; owl:imports <http://purl.obolibrary.org/obo/bfo/2020/bfo.owl> ; dcterms:creator "Nicolau Oyhenard dos Santos"@en ; dcterms:contributor "Cauã Antunes" ; dcterms:contributor "Haroldo Rojas" ; dcterms:contributor "Rafael Petry" ; dcterms:contributor "Régis Romeu" ; dcterms:contributor "Mara Abel" ; dcterms:isPartOf <https://inf.ufrgs.br/projetos/OntoKG> ; dcterms:publisher "Universidade Federal do Rio Grande do Sul (UFRGS)"@en ; dcterms:license <https://creativecommons.org/licenses/by/4.0/> ; dcterms:created "2026-04-08"^^xsd:date ; dcterms:modified "2026-10-08"^^xsd:date ; apv:GlobalMinLanguageCoverage "en pt-br" ; apv:ClassURIFormationRule "https://www[.]inf[.]ufrgs[.]br/ontologies/copi/(COPI_[0-9]{7}|[A-Z][A-Za-z0-9]*)" ; apv:ClassMinAnnotationCoverage "rdfs:label https://spec.industrialontologies.org/ontology/annotation/naturalLanguageDefinition" . iof-av:naturalLanguageDefinition rdf:type owl:AnnotationProperty ; apv:MinAnnotationLength 20 . ### Identity-giving function :COPI_0000026 rdf:type owl:Class ; # FlowControlFunction rdfs:subClassOf iof-core:DesignedFunction ; rdfs:subClassOf [ rdf:type owl:Restriction ; owl:onProperty bfo:BFO_0000054 ; # realizedIn owl:allValuesFrom :COPI_0000520 # FlowControlProcess ] ; rdfs:subClassOf [ rdf:type owl:Restriction ; owl:onProperty bfo:BFO_0000054 ; # realizedIn owl:someValuesFrom :COPI_0000520 # FlowControlProcess ] ; rdfs:label "flow control function"@en ; rdfs:label "função de controle de fluxo"@pt-br ; iof-av:naturalLanguageDefinition "A DesignedFunction that is realized in a FlowControlProcess and that consists in permitting, obstructing, regulating, or routing the passage of a fluid."@en ; skos:definition "A DesignedFunction that is realized in a FlowControlProcess and that consists in permitting, obstructing, regulating, or routing the passage of a fluid."@en . ### Process type :COPI_0000520 rdf:type owl:Class ; # FlowControlProcess rdfs:subClassOf :COPI_0000010 ; # FlowControl rdfs:label "flow control process"@en ; rdfs:label "processo de controle de fluxo"@pt-br ; iof-av:naturalLanguageDefinition "A PlannedProcess in which a valve permits, obstructs, regulates, or routes fluid flow between its ports."@en ; skos:definition "A PlannedProcess in which a valve permits, obstructs, regulates, or routes fluid flow between its ports."@en . :COPI_0000010 rdf:type owl:Class . # FlowControl :COPI_0000520 # FlowControlProcess rdfs:subClassOf [ rdf:type owl:Restriction ; owl:onProperty iof-core:hasInput ; owl:someValuesFrom :COPI_0000037 # PortionOfFluid ] ; rdfs:subClassOf [ rdf:type owl:Restriction ; owl:onProperty iof-core:hasSpecifiedOutput ; owl:someValuesFrom :COPI_0000037 # PortionOfFluid ] . ### Equipment universal: ThreeWayValve :COPI_0000788 rdf:type owl:Class ; # ThreeWayValve rdfs:subClassOf :COPI_0000077 ; # Valve rdfs:subClassOf [ rdf:type owl:Restriction ; owl:onProperty iof-core:hasFunction ; # Object branch (MaterialArtifact/Assembly/Object/FiatObjectPart) owl:someValuesFrom :COPI_0000026 # FlowControlFunction ] ; rdfs:label "three way valve"@en ; iof-av:naturalLanguageDefinition "A three way valve is a valve with three flow-path ports instead of the usual two, used to divert one inlet stream to either of two outlets or to mix two inlet streams into one outlet."@en ; skos:definition "A three way valve is a valve with three flow-path ports instead of the usual two, used to divert one inlet stream to either of two outlets or to mix two inlet streams into one outlet."@en ; iof-av:naturalLanguageDefinition "Uma valvula de tres vias e uma valvula com tres portas de passagem de fluxo em vez das duas usuais, usada para desviar um fluxo de entrada para uma de duas saidas ou para misturar dois fluxos de entrada em uma saida."@pt-br ; iof-av:semiFormalNaturalLanguageAxiom "Every three way valve is a valve that bears a flow control function and has a port as a component part, distinguished from a generic valve by an additional flow-path participant in its process signature."@en ; iof-av:firstOrderLogicAxiom "∀x (ThreeWayValve(x) → Valve(x) ∧ ∃f (FlowControlFunction(f) ∧ bearerOf(x,f)) ∧ ∃p (Port(p) ∧ hasComponentPartAtAllTimes(x,p)))"@en ; iof-av:isPrimitive "true"^^xsd:boolean ; iof-av:primitiveRationale "Constructive type: under OWA, asserting sufficiency (equivalence) from a Port-existence differentia would risk misclassifying any valve that happens to assert a Port component (or any multi-port manifold-like fitting) as a ThreeWayValve. Necessary conditions only, pending expert review of whether the port-count distinction should ever be made sufficient."@en ; skos:definition "[ISO 15926-4] A <THREE WAY VALVE> is a <MULTI WAY VALVE> that is made with three separate paths of flow"@en .
Axiomatization Decision Log
1 Identity-Giving Function
Function class
FlowControlFunction ⊑ DesignedFunction
Realized in
FlowControlProcess ⊑ FlowControl
Constructive-basis type: per the method, Step 1 reuses the generic function of the broader genus (Valve bears FlowControlFunction) rather than inventing a distinguishing function, since the identity-giving trait here is structural (port count), not functional.
2 Genus Determination
Valve
Primary source: 'A THREE WAY VALVE is a MULTI WAY VALVE that is made with three separate paths of flow'. MULTI WAY VALVE is the literal parent_candidate but is not itself enriched in the ontology; rather than introduce an unenriched intermediate genus for a single member, Valve (already enriched, exported) is used directly as genus, with the multi-way/three-way distinction carried entirely in the differentia. A future 'multi way valve' cluster could be enriched later as an intermediate genus if more multi-port subtypes are added.
3 Necessary Parts

No necessary parts recorded (concept may be primitive at this level).

No subtype-specific necessary part beyond the generic 'Port' referenced in the differentia is grounded verbatim for this term; asserting a specific closure mechanism would overreach, since three-way valves are built with multiple different closure types (ball, plug) per the gathered evidence.
4 Process Participation Signature ⟨I, O, T⟩
Inputs (I)
PortionOfFluid — at least one of the three ports functions as an inlet
Outputs (O)
PortionOfFluid — the remaining two ports function as outlets in diverting service (one inlet routed to one of two outlets); in mixing service the roles invert -- two ports serve as inlets converging into one outlet
Transformation (T)
fluid routed among three ports, either splitting one inlet stream into two outlets (diverting) or merging two inlet streams into one outlet (mixing), depending on plumbing and service
Same fluid-control signature family as generic Valve; the extra participant (second inlet or second outlet, depending on service) is what formally distinguishes this class from a two-port valve, mirroring how block and bleed valve's extra bleed output is modeled at this level rather than via a part.
5 Axiom Mode Decision

Necessary conditions only — modelled as a primitive universal (⊑, SubClassOf). Identity is grounded in designed function and cannot be reduced to a property checklist.

Constructive type: under OWA, asserting sufficiency (equivalence) from a Port-existence differentia would risk misclassifying any valve that happens to assert a Port component (or any multi-port manifold-like fitting) as a ThreeWayValve. Necessary conditions only, pending expert review of whether the port-count distinction should ever be made sufficient.
Cross-Standard Observations
Only ISO 15926-4 defines this exact term in terms.db (no cross-source corroboration). No free normative standard (NIST/DNV/NORSOK/ISO preview) was found defining 3-way valves specifically; two independent tertiary web sources (instrumentationtools.com, engineerfix.com) triangulate the mixing/diverting duality and the three-port structure, used as interpretive/NL grounding only.
Reviewer Notes
Step 2b/2c (enrich-term skill): no free normative standard found defining 3-way valves specifically (a targeted search for NIST/DNV/NORSOK/ISO coverage came up empty). Triangulated 2 independent tertiary web sources (instrumentationtools.com, engineerfix.com) for the mixing/diverting duality and three-port structure. Necessary_parts left empty (KNOWN EXPRESSIVE LIMITATION: cardinality ('exactly three ports') is not expressible in this pipeline's existential-restriction pattern -- see docs/findings/expressive-limitation.md); the real differentiation from a two-port Valve is carried by the process signature (extra input/output participant), matching the precedent set by block and bleed valve's extra bleed-output modeling.

Suggest a change

Opens a pre-filled GitHub issue on the COPI repo — nothing is sent until you submit it there.