Let’s say we have two databases, a drilling operations database and a HES incident database. These two databases have been used for years in our company, but we want to understand something that requires data from both of them to answer a question. The question we will use in this thought experiment is “Are there certain types of incidents that occur more often on complex wells than on simple wells and if so, what do we know about preventing them from happening”?
In the traditional database world answering this question would be very difficult and would require help from the IT department data management team. Traditional databases store data and have hard coded ways to store relationships between data; changing what is stored and how these relationships work is no easy task and there are often many dependencies that preclude these changes from happening. These traditional systems generally focus on data entry for field staff and simple reporting. They were designed to do a very specific job and they do that job really well. However, when you want to ask a question of the data that is new, especially if it requires data from multiple datasets the result is often a new shadow system that is created with duplicated information from both systems. These shadow systems quickly become outdated and are difficult to maintain because changes in the data models in the base systems will cause cascading failures for the shadow systems. Often, businesses resort to spreadsheets and manually re-enter the data for each system so they can continue to get what they need. Our question is not easy to answer using traditional approaches.
In a traditional drilling database there is a table that stores all of the Well Headers and “children” tables that include information about casings, directional surveys, perforations, and job information. In an Enterprise Knowledge Graph we can read all of these relationships; they still exist in the graph but we can change and enrich what data is stored about a well and how this well is connected to other information in other databases and documents.
So how would an enterprise knowledge graph facilitate answering the question “Are there certain types of incidents that occur more often on complex wells than on simple wells and if so, what do we know about preventing them from happening?”
First let’s look at how the Maana Knowledge Graph can enrich the data we store about the well and store it back in the knowledge graph. First we need to know which wells were “complex wells” and have this complex well concept stored back in our Knowledge Graph. For simplicity (no pun intended) let’s say a complex well is defined as a well that has more than 4 casing strings, has a depth greater than 25,000 feet, and has a high tortuosity index. Our Knowledge Graph can store this definition of complexity and compute a new piece of knowledge (complex well or not) from the underlying drilling data and relate it back to the well. This new information is stored in the graph and related to all the other data that the well is associated with. We can even define a new “Kind” of well from this new knowledge, a Complex Well. When a user wants to look at the Complex Well kind we can define what data is appropriate to be displayed when looking at a complex well, things like TVD, Casing Strings, pictures of well path, along with other basic well header information. The important thing here is we are enriching our base data with new concepts and connecting these concepts back to the original data. The Maana Knowledge Graph now contains the concept of complex well, how do we bring in the HES data?
We want to add the data silo “HES drilling incidents database” to our Knowledge Graph. Maana first reads the new dataset, all of the tables and internal relationships, then begins the discovery processes to determine if there is a way to connect this new dataset to the existing data in the Knowledge Graph. The discovery process may determine that there are Well Names in the HES dataset that match Well Names in the Drilling dataset, or there are well names in incident documents that match data in the drilling dataset. How does it do this?
Maana Knowledge Graph knows that Well is an important concept in the drilling database, so we can search for these well names in the HES dataset and when we find matches, our algorithms can create relationships between the two datasets for those records that seem to match or be related. Maana Knowledge Graph will make these connections between the two different datasets. Now that this connection has been made in the enterprise knowledge graph we can look at the incidents related to complex wells because all of the data is connected. Maana can run natural language processing algorithms on the text in the incident reports and extract out the solutions or recommended actions to the incidents and enrich the incident data to store this information. These solutions or recommended actions are connected to the HES incidents, the incidents are connected to wells, the wells are connected to the concept complex well and so on.
As the graph grows more questions can be asked about the data; as the graph ingests new information about the oil wells like production, lease information etc. the questions that can be asked and the types of data enrichment that are possible grow as well.
Stay in the know with the latest information about Maana services, events, news and best practices by email.