Layer one knowledge-as-a-service: graph database management systems<\/li>

Layer two knowledge-as-a-service: graph analytics and extraction; query languages and processing engines<\/li>

Layer three knowledge-as-a-service: visualization and analysis tools; integrations with BI tools<\/li><\/ul>\n\n\n\n
Utilize an existing knowledge graph: <\/p>\n\n\n\n
Full service knowledge-as-a-service: knowledge graph APIs, visual search and integrations<\/li><\/ul>\n\n\n\n
It\u2019s also worth noting that these two categories aren\u2019t mutually exclusive. Plenty of companies seed, enrich, or update knowledge graphs they\u2019ve built with existing external knowledge graphs. Additionally, existing knowledge graphs are a particularly well suited format for giving machine learning models context; machine learning models that can in turn help augment or populate internal knowledge graphs with additional (custom) fields. <\/p>\n\n\n\n
Whether building, utilizing an external service or pursuing a hybrid approach, there are two high-level issues that most knowledge projects must wrangle with. The first involves the fact that meaningful knowledge graphs are often of considerable scale. This is the issue of price (and correspondingly process) for fact accumulation. The next involves the actionable output: how do we get existing knowledge in front of the right person at the right time (knowledge workflows)?\u00a0<\/p>\n\n\n\n
The Cost of Fact Accumulation<\/h2>\n\n\n\n
As mentioned previously, knowledge graphs have been utilized in academic and research settings for a number of decades (beginning in the 1970\u2019s<\/a>). While this has been useful for sketching out the theoretical strengths and weaknesses of this form of data modeling, few academic knowledge graphs were of any size to be useful in commercial settings. <\/p>\n\n\n\n
As our ability to quickly store and retrieve data increased exponentially, several enterprise knowledge base companies attempted to build databases of a size useful for a wide range of enterprise applications. In the early 1980\u2019s, a long term project called Cyc was compiled. The aim: create a knowledge base large enough to remedy the issue of AI systems with an initial promise that falters due to a lack of ongoing data sources. Cyc was able to compile around 21M fields manually (and at a great cost).\u00a0<\/p>\n\n\n\n
In the 1990s and with the proliferation of the internet, (unstructured) data was no longer an issue, with exponential data growth each and every year. But unstructured web data doesn\u2019t equate to useful information (let alone \u201cknowledge\u201d \u2013 particularly on topics of enterprise interest). Metaweb attempted to remedy this through crowdsourcing knowledge. Building off of Wikipedia, they were able to increase Cyc\u2019s field count 100x before being acquired and folded into Google.\u00a0<\/p>\n\n\n\n
Together these two enterprise-focused projects exemplified both the promise of enterprise knowledge graphs, and the shortcoming of manual fact accumulation. Because there\u2019s a relatively hard cap on how quickly humans can curate answers, there\u2019s a hard floor on how low you can drop the price of manual fact accumulation. You need more people or more time, both of which mean more money.

Today the internet has grown significantly. And we do have examples of massive knowledge bases compiled by humans (IMDB, Yelp). But they tend to need to be about topics that are of widespread interest and shared knowledge. Another dead end for large-scale manual knowledge graphs of enterprise use. So how do we go about structuring enterprise knowledge efficiently today? <\/p>\n\n\n\n
Powerful web crawlers, natural language processing, and machine vision with machine learning computations on top have managed to massively increase the size of enterprise-use knowledge bases for a fraction of the price. A huge range of useful enterprise data is available online as well as in the news. It simply needs to be structured. <\/p>\n\n\n\n
Among general use knowledge graphs, GDELT<\/a> and Diffbot<\/a> provide the largest coverage areas. Where GDELT automates the organization of facts from worldwide newspapers, Diffbot crawls the entire web and pulls out entities and facts. <\/p>\n\n\n\n
Natural language processing pushed to layers one through three listed earlier in this article also enable enterprises to pick and choose where to source their knowledge graphs from. The following sources are commonly parsed into enterprise knowledge graphs: <\/p>\n\n\n\n
Firmographic data<\/li>
Technographic data<\/li>
Internal documents<\/li>
News or social media mentions<\/li>
Product catalogs<\/li>
Review data<\/li>
Real world events<\/li>
Customer data<\/li>
Prospect data<\/li>
Investigative data<\/li>
Supply chain data<\/li>
Among others<\/li><\/ul>\n\n\n\n
$\"\"\/$
Image Source<\/a><\/figcaption><\/figure><\/div>\n\n\n\n
While a work-in-progress in many hard problem areas, AI has proven to be the first step change in the cost per fact accumulation in modern times. For example, looking at Diffbot \u2013 largest commercial Knowledge Graph provider \u2013 cost per fact accumulation<\/a> compared to<\/a> Cyc or Freebase shows an improvement of roughly x2500.<\/p>\n\n\n\n
From Knowledge Graphs to Knowledge Workflows<\/h2>\n\n\n\n
One of the main issues that persists even after organizations have well populated and topical knowledge graphs is that of not thinking in terms of knowledge workflows. Similarly to some of the often touted downsides<\/a> of data lakes, knowledge graphs can fall prey to accumulating huge amounts of information that doesn\u2019t get in front of the right team members at the right time. <\/p>\n\n\n\n
Like any other data store, the accumulation of a \u201clarger\u201d knowledge graph can be more of a liability than an asset. <\/p>\n\n\n\n
Data becomes stale<\/li>
Data \u201cislands\u201d emerge<\/li>
No understanding of overall data structure<\/li>
Messy data provenance<\/li><\/ul>\n\n\n\n
The real benefits of knowledge graphs surface when high volume and velocity data can be structured in an automated way to solve data gathering issues for discrete teams.

While many unique use cases have not been explored by major knowledge graph providers, strengths of present knowledge graph architectures include the following:<\/p>\n\n\n\n
Graph databases are flexible, containing many different entity types<\/li>
Graph databases are centered around relationships between entities (linked data providing context) <\/li>
Unlike relational databases which may require complex joins to retrieve linked data, graphs offer performance benefits<\/li>
New fact types can be added \u201con the fly\u201d as the world they\u2019re representing changes<\/li>
Each entity has a universal identifier (disambiguation)<\/li>
Data provenance providing explainability to each constituent fact<\/li>
High expressivity for modeling complex domains<\/li><\/ul>\n\n\n\n
While knowledge graphs power major services we depend on (Netflix, Spotify, Google search, etc.), for most organizations successful implementations of knowledge-as-a-service involves pairing specific KG strengths with specific needs. The largest portion of future knowledge-as-a-service promise involves freeing workers from specific drudgeries related to fact accumulation and trend spotting in their role. And that\u2019s a win that\u2019s well underway!<\/p>\n","protected":false},"excerpt":{"rendered":"
Knowledge graphs hit the peak of their Gartner hype cycle in 2020. And much as KG teams celebrated the rise to prominence, \u201chype\u201d carries an implicit risk. What if the …<\/p>\n","protected":false},"author":299,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_eb_attr":"","_glsr_average":0,"_glsr_ranking":0,"_glsr_reviews":0,"footnotes":""},"categories":[1307,181],"tags":[],"class_list":["post-65810","post","type-post","status-publish","format-standard","hentry","category-education","category-future-of-ai"],"_links":{"self":[{"href":"https:\/\/aijourn.com\/wp-json\/wp\/v2\/posts\/65810","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/aijourn.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/aijourn.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/aijourn.com\/wp-json\/wp\/v2\/users\/299"}],"replies":[{"embeddable":true,"href":"https:\/\/aijourn.com\/wp-json\/wp\/v2\/comments?post=65810"}],"version-history":[{"count":1,"href":"https:\/\/aijourn.com\/wp-json\/wp\/v2\/posts\/65810\/revisions"}],"predecessor-version":[{"id":65812,"href":"https:\/\/aijourn.com\/wp-json\/wp\/v2\/posts\/65810\/revisions\/65812"}],"wp:attachment":[{"href":"https:\/\/aijourn.com\/wp-json\/wp\/v2\/media?parent=65810"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/aijourn.com\/wp-json\/wp\/v2\/categories?post=65810"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/aijourn.com\/wp-json\/wp\/v2\/tags?post=65810"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}