This is the second blog post in the Knowledge Graph Best Practices series. The series is aimed to arm you with information to be successful with your first knowledge graph project.
Educating Others About Knowledge Graph and Getting Support for the Project
As a software company with decades of experience in knowledge graph technology and applications, we are sharing our knowledge and experience to others because we understand the need is great and will affect positive outcomes for data management and decision making.
Just as we are creating awareness and educating readers about knowledge graph technology, a person seeking to promote adoption in his or her organization should do likewise. But a prerequisite is to understand the concepts yourself. A great resource for this is the ebook we mentioned in the first post of this series. After you arm yourself with a good grasp of the concepts, their capabilities and how knowledge graph changes the data management paradigm, you are in a better position to educate and inform others.
When you develop your message, perhaps start by focusing on why knowledge graph technology is important. There is a dynamic in virtually every data rich organization that features a use case driven approach to data collection and preparation and consumption. If you understand knowledge graph technology, you know the movement seeks to shift from an application-centric (i.e., use case-driven) approach to treating data as a product (i.e., data centricity).
In the application-centric approach so dominant today, we apply (too much) human capital to transactional workflows. Meaning users, and certainly developers, spend a lot of time wrangling data to “fit” applications. This is a waste. If you communicate to users, solution architects and developers how life will be different using the knowledge graph approach, they should want it. For example, executives want to “know what they know,” and they want it from a single “pane of glass.”
Since the knowledge graph integrates potentially all your data sources, you now have a way to deliver information in one “place.” You also have a way to allow users to pivot around all content and ask ad hoc questions. Perhaps subtle, you also can deliver information that is based on the concepts they care about (i.e., how users think), as opposed to delivering data based on schemas and data types.
If Digital Transformation is a key objective of your organization, knowledge graph will play a vital role. While we commonly discuss consumption of knowledge graphs from a human perspective, this technology is ultimately intended to serve automated clients and processes. Specifically, W3C RDF and OWL are envisioned to create a means to enable sophisticated machine-to-machine interactions; and that is where this is going.
After you develop your message for “why knowledge graph,” you want to explain clearly and accurately what knowledge graph technology is. Arguably, a knowledge graph consists of “knowledge” and “graph.” The graph part is RDF, and it represents the way to structure and convey data. The knowledge part is OWL, and it provides the mechanism to represent meaning; that is, what things are and how the things relate to each other.
The combination results in schema-less and self-describing data that is easily consumable and understandable by humans and machines. After all, we are largely in the current predicament because we didn’t factor such ideas into our early database systems or our file formats. We didn’t necessarily consider that others would want to use “our” data or that our data was related to others’ data. The knowledge graph explicitly assumes that data from different sources is related and that others may want to consume it.
To go deeper into the ins and outs of knowledge graph, read this ebook recently published by 3 knowledge graph thought-leaders.
How does your organization keep up with the latest technology?
Knowledge Graph Best Practice Series
- Building Momentum | Educating others about knowledge graph and getting support for the project
- Selecting Your Fist Use Case | Set up for success
- Assembling the Team | Required roles and skills
- Preparation | What to do before you begin to avoid delays
