{"id":14200,"date":"2022-01-14T09:04:32","date_gmt":"2022-01-14T14:04:32","guid":{"rendered":"https:\/\/enterprise-knowledge.com\/?p=14200"},"modified":"2025-09-15T14:08:38","modified_gmt":"2025-09-15T18:08:38","slug":"sandbox-expert-analysis-formatting","status":"publish","type":"post","link":"https:\/\/enterprise-knowledge.com\/sandbox-expert-analysis-formatting\/","title":{"rendered":"Sandbox: Expert Analysis Formatting"},"content":{"rendered":"

As EK works with our clients to integrate knowledge graphs into their technical ecosystems, client stakeholders often ask, \u201cWhy should we leverage knowledge graphs?\u201d and more specifically, \u201cDo we need a graph database?\u201d Our consultants then collaborate with stakeholders to weigh the pros and cons of using a knowledge graph and graph database to solve their <\/span>findability and discoverability<\/a><\/strong> use cases. In this blog, two of our senior technical consultants, <\/span>Bess Schrader<\/a><\/strong> and <\/span>James Midkiff<\/a><\/strong>, answer common questions about knowledge graphs and graph databases, focusing on how to best fit them into your organization\u2019s ecosystem without overengineering the solution.<\/span><\/p>\n

\"Portraits<\/p>\n

Why should I leverage knowledge graphs?<\/h2>\n\n\n\n
\"\"<\/a><\/span><\/td>\n\n

Bess Schrader<\/span><\/h4>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Knowledge graphs model information in the same way human beings think about information, making it easier to <\/span>organize, store, and logically find data<\/a><\/strong>. This reduces the silos between technical users and business users, reduces the ambiguity about what data and information mean, and makes knowledge more sustainable and accessible. <\/span>Knowledge graphs are the implementation of an ontology<\/a><\/strong>, a critical design component for understanding your organization.\u00a0<\/span><\/p>\n

Many graph databases also support inference, allowing you to explore previously uncaptured relationships in your data, based on logic developed in your ontology. This reasoning capability can be an incredibly powerful tool, helping you gain insights from your business logic.<\/span><\/p>\n\n\n\n
\n

\"\"<\/a><\/span><\/h4>\n<\/td>\n

\n

James Midkiff<\/span><\/h4>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Knowledge graphs are a concept, a way of thinking, and they aren’t always necessarily tied to a graph database. Even if you are against adopting a graph database, you should <\/span>design an ontology<\/a><\/strong> for your organization\u2019s data to visualize and align with how you and your colleagues think. Modeling your organization gives you the complete view and vision for <\/span>how to best leverage your organization\u2019s content<\/a><\/strong>. This vision is your knowledge graph, an innovative way for your organization to tackle the latest data problems. However, this ontology doesn\u2019t have to be implemented in a graph database. The technical implementation should be built using technologies that efficiently support the use cases and are easy to maintain.<\/span><\/p>\n

Does my use case require a graph database?<\/h2>\n\n\n\n\n\n\n
\n

\"\"<\/a><\/span><\/h4>\n

<\/h4>\n

<\/h4>\n<\/td>\n

\n

Bess Schrader<\/span><\/h4>\n

Any organization that wants to map its internal data to external data would benefit from a graph. If your use case includes publishing your data and connecting to other data sets, a knowledge graph and graph database (particularly one that uses the Resource Description Framework, or RDF) are the way to go to ensure the data is flexible and interoperable. Even if you do not intend to connect and\/or publish data, storing robust definitions alongside data in a graph is one of the best ways to ensure that the meaning behind fields is not lost. With the <\/span>addition of RDF*<\/a><\/strong>, the expressivity of a graph to describe organizational data is unmatched by other data formats.<\/span><\/p>\n

When your ontology and instance data are all in the same place (a graph database), technical and non-technical users alike can always determine what a given field is supposed to mean. This ensures that your data is sustainable and maintainable. For example, many organizations use acronyms or abbreviations when setting up relational databases or nested data structures like JSON or XML. However, the definition and usage notes for these fields are often <\/span>not <\/span><\/i>included alongside the data itself. This leads to situations where data consumers and developers may find, for example, a field called “pqf” in a SQL table or JSON file created several years ago by a former employee. If no one at the organization knows what “pqf” means or what downstream systems might be using this field, this data becomes an unusable maintenance burden.<\/span><\/p>\n

However, using well-formed ontologies and RDF knowledge graphs, this property \u201cpqf\u201d would be a \u201cfirst-class citizen\u201d with its own properties, including a label (\u201cPrequalified for Funding\u201d) and definition (\u201cThis field indicates whether a customer has been prequalified for a financial product. A value of \u2018true\u2019 indicates that the customer <\/span>has <\/span><\/i>been preapproved\u201d), explaining what the property means and how it should be used. This reduces ambiguity and confusion for both developers and data consumers.<\/span><\/td>\n<\/tr>\n

\n

\"\"<\/a><\/span><\/h4>\n

<\/h4>\n

<\/h4>\n<\/td>\n

\n

James Midkiff<\/span><\/h4>\n

A majority of knowledge graph use cases involve <\/span>information discovery and search<\/strong><\/span><\/a>. Graph databases are flexible, allowing you to easily adapt the model as new data and use cases are considered. Additionally, graphs make it painless to aggregate data from separate data sources and combine the data to create a <\/span>single view of an employee<\/strong><\/span><\/a>, topic, or other important entity at your organization. Below are some questions to ask when faced with this question.<\/span><\/p>\n

<\/td>\n<\/td>\n<\/tr>\n
<\/td>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

I\u2019m nervous about migrating to a new data format. Why should my team learn about and invest in graph database technologies?<\/h2>\n

In addition to the advantages described above, one major benefit of using RDF-compliant graph databases is that they\u2019re based on standards that have been maintained by the W3C for over two decades. These standards, including RDF and SPARQL, were developed over 20 years ago to promote long-term growth for the web. In other words, RDF is not a trendy new format that may disappear in five years, and you can be confident when investing in learning about this technology. The use of standards provides freedom from proprietary vendor tools, enabling you to effortlessly create, move, integrate, and share your data between different standards-compliant software. Using semantic web standards also enables you to seamlessly connect your content and data to a taxonomy (whether internal or external), as most taxonomies are created and stored in an RDF format.<\/span><\/p>\n

Similarly, SPARQL, the RDF query language, is based on pattern matching and can be easier to learn for non-technical users than more complex programming languages. SPARQL also allows for federated queries, which enable a user to query across multiple knowledge graphs stored in different graph databases, as long as the databases are RDF-compliant. Using federated queries, you could query your own data (e.g. a dataset of articles discussing the stock market and finances) in combination knowledge graphs like with <\/span>Wikidata<\/a><\/strong>,<\/strong> a free and openly accessible RDF knowledge graph used by Wikipedia. This would allow you to take any article that mentions a stock ticker symbol, follow that symbol to the Wikidata entry, and pull back the size and industry of the organization to which the ticker refers. You could then leverage this information to filter your articles by industry or company size, without needing to gather that information yourself. In other words, federated queries allow you to query beyond the bounds of your own organization\u2019s knowledge.<\/span><\/p>\n

\"\"<\/a><\/span><\/h4>\n

James Midkiff<\/span><\/h4>\n

Many organizations do not need to externally share the knowledge graph data they create. The data may support externally-facing use cases, like chatbots, search, and knowledge panels, and this is usually more than sufficient to meet an organization’s knowledge graph needs. Taxonomies can be transformed and imported into any relational or NoSQL database in a similar manner that we use to translate all other data formats into RDF when building a graph. While graph databases can make this connection more seamless, they are by no means the only way to implement a taxonomy. Relational and NoSQL databases are more commonly used, making it easier to find the necessary skill sets to implement and maintain them. With so many developers used to query languages like SQL, the <\/span>pattern-based nature of SPARQL<\/strong><\/span><\/a> can be difficult for developers to learn and adopt.<\/span><\/p>\n

To be clear, graph databases <\/span>are<\/span><\/i> an investment. They\u2019re a shift in how we approach and integrate data, which can lead to some adoption costs. However, they can also bring advantages to an organization in addition to what Bess mentioned above.\u00a0<\/span><\/p>\n