As a conventional energy industry, the petroleum industry is responsible for supplying over half of the world's energy. Facilitating sustainable development for petroleum energy production remains crucial. Data methods have emerged as powerful tools to advance sustainability by enabling eficient resource management and risk mitigation. However, the reliable implementation of data-driven methods relies on high-quality data, necessitating the verification of data integrity on substantial data volumes. To this end, this poster paper presents our ongoing research, leveraging ontologies and knowledge graphs as shared knowledge representation, and provides preliminary results on data integrity verification. Based on the ontologies, we formulate domain knowledge integrity constraints and test three technologies of integrity verification: Python, PySpark, and SPARQL, for exploring future potential industrial adoption.
1. Introduction O3PO: choke valve subClass
Of
O3PO:
S1 V3 !$ choke valve 3
to suistainability by improving energy production eficiency, and reducing accidents with severe environmental damage, such as oil leaks.
Challenge. The performance of data-driven approaches heavily relies on the data quality. Thereby, it presents an important challenge in ensuring the integrity of the data, which is crucial for data-driven solutions to deliver reliable predictions. In petroleum production, the purpose of collecting data from various sensors is to allow domain experts to analyse and make informed decisions based on their knowledge and experience. In this context, we discuss one of the issues of data integrity: the data should follow certain constraints of physical laws. This is in addition to other issues, such as missing values, sensor precision errors, etc. For verifying the constraints of physical laws, domain knowledge plays an important role, and should be incorporated in the integrity checking. Semantic technology is suited here due to its transparency, which the domain experts tend to have a high chance to trust because they can observe that their domain knowledge is used and how it is used.
Our approach. In this poster paper, we present our ongoing research on a semantic solution
for data integrity verification for petroleum industry. We develop a draft of a petrolum ontology
aligned with upper ontologies as shared representation for data integration and knowledge
representation; we construct knowledge graphs for transparent and unified human
understanding; we experiment technologies for data integrity verification, including Python, PySpark and
SPARQL. We provide preliminary experiment results and discussion of adoption.
2. Data and Knowledge Representation
Ontology for petroleum production. In the petroleum domain, ontologies for petroleum
exploration [
Data from petroleum production wells. The data collected from the sensors in the production wells are typically presented in relational tables, including various sensor measurements on the range of well sections from the bottom-hole to the wellhead. These measurements include parameters such as pressure, temperature, and flow rate of each well section. Additionally, the collected data can contain other important equipment information, such as the ratio between the choke opening rate and flow coeficients. These relational tables provide a structured format for data-driven approaches to make predictions.
Knowledge graphs for petroleum wells. Based on the proposed ontology, we construct knowledge graphs (KG) (Fig. 2) with domain experts to illustrate the production wells, well sections, well sensors, and their relations. These KGs serve as a flexible foundation to formalise the domain knowledge , and to support a transparent shared understanding between the domain experts, semantic experts, data scientists, etc. The KGs can also have the potential for sophisticated reasoning, for example, using domain-knowledge-based constraints to detect subtle anomalies, identify potential erroneous data, and ensure the consistency of the delivered data. 3. Integrity Verification with Preliminary Evaluation Integrity constraints. The integrity constraints play a crucial role in ensuring the quality of petroleum data. After renaming the features, we can formulate these constraints based on domain knowledge for verifying the data integrity. This allows validation of the sensor measurements, ensuring that they align with physical laws and empirical expectations. Here we give three examples (Fig. 2b): Example 1: the flow rate at any position within a well must consistently equal the flow rate of its upstream or downstream locations.
Example 2: the total flow rate of the main well should precisely match the sum of the flow rates of all merged (or split) wells.
Example 3: for each well, both the flow rate and pressure consistently adhere to the principles outlined in the Bernoulli function. BFO: hasRole
Well A t an e inu iTm tn e oC oSm sa t
A :hFO traP B
o T d li u F s d e e :f O S F BFO: hasRole
few violations) based on real production data, provided by two world-leading energy companies. In total, we generated five such tables with sizes ranging from 145MB to 1.45GB, containing from 1 million to 10 million records. In addition, we generate corresponding KGs (Fig. 2a) following our ontology. These KGs are saved as Turtle files ranging in size from 440MB to 4.4GB. Implementation. We implement the constraints in Example 1-3 with (a) Python, because it is relatively easy to learn and it is popular among the petroleum domain experts; (b) PySpark, for its similarity to Python and that it unlocks the potential of parallelizable computation; (c) and SPARQL, for its popularity in the semantic community. The Python implementation uses common libraries such as Pandas, Numpy. PySpark is the Python API for Apache Spark, which is a distributed computing framework that enables parallel computation for dealing with large-scale datasets. The SPARQL is implemented with Jena and Fuseki. Jena is an open-source Java framework for semantic applications, while Fuseki is for setting SPARQL endpoint. Results and discussion. From the results (Fig. 3) we can see that the Python running time increases significantly when the data size grows, while the running time for PySpark and SPARQL changes insignificantly. We postulate that the reason is that the data size is under a certain threshold so that the most consumed time for PySpark and SPARQL is used for loading the environment, not for querying. The results indicate that both PySpark and SPARQL have the potential for verifying large datasets. Yet, note that for generating the ttl files for SPARQL to query, it takes a large amount of time (some minutes to some hours). Besides, many domain experts are familiar with Python, but unfamiliar with Jena Fuseki and SPARQL. We expect they tend to learn writing constraint queries in PySpark than in SPARQL. All these factors need to be taken into account in considering industrial adoption.
Acknowledgements This work is supported by the Norwegian Research Council via PeTWIN (294600), DigiWell(308817) and SIRIUS (237898).