Over the last decade, enterprise knowledge graphs have been rising to the challenge, playing a transformational role in providing enterprise 360 views, content and product personalizations, improving data quality and governance, and providing organizational knowledge in a machine readable format. Graphs offer a more intuitive, connected view of organizational data entities as they shift the focus from the physical data itself to the context, meaning, and relationships between data – providing a connected representation of an organization’s knowledge and data domains without the need to make copies or incur expensive migrations – and most importantly today, delivering Knowledge Intelligence to enterprise AI. 

While this growing interest in graph solutions has been long anticipated and is certainly welcome, it is also yielding some stalled implementations, unmet expectations, and, in some cases, complete initiative abandonment. Understanding that every organization has its own unique priorities and challenges, there can be various reasons why an investment in graph solutions did not yield the desired results. As part of this article, I will draw upon my observation and experience from industry lessons learned to pinpoint the most common culprits that are topping the list. The signs are often subtle but can be identified if you know where to look. These indicators typically emerge as misalignments between technology, processes, and the organization’s understanding of data relationships. Below are the top tell-tale signs that suggest a trajectory of failure:

1. Treated as Traditional, Application-Focused Efforts (As Technology/Software-Centric Programs)

If I take one datapoint out of observation from the organizations that we work with, the biggest hurdle to adopting graph solutions isn’t about whether the approach itself works – many top companies have already shown it does. The real challenge lies in the mindset and historical approach that organizations have developed over many years when it comes to managing information and technology programs. The complex questions we are asking from our content and data today are no longer fulfilled by the mental models and legacy solutions organizations have been working with for the last four or five decades. 

Traditional applications and databases, like relational or flat file systems, are built to handle structured, tabular data, not the complex, interwoven relationships. The real power of graphs lies in their ability to define organizational entities and data objects (people, customers, products, places, etc. – independent of the technology they are stored in). Graphs are optimized to handle highly interconnected use cases (such as networks of related business entities, supply chains, and recommendation systems), which traditional systems cannot represent efficiently. Adopting such a framework requires a shift from legacy application/system-centric to a data-centric approach where data doesn’t lose its meaning and context when taken out of a spreadsheet, a document, or a SQL table. 

Sticking with such traditional models and relying on legacy systems and implementation approaches that don’t support relationship modeling to make graph models work results in an incomplete or superficial understanding of the data leading to isolated or incorrect decisions, performance bottlenecks, and ultimately lack of trust and to failed efforts. Organizations that do not recognize that graph solutions often represent a significant shift in how data is viewed and used within an organization are the ones that are first to abandon the solution or incur significant technical debt. 

Early Signs of Failure: 

• Implementation focuses excessively on selecting the best and latest graph database technologies without the required focus on data modeling standards. In such scenarios, the graph technology is deployed without a clear connection to key business goals or critical data outcomes. This ultimately results in misalignment between business objectives and graph implementation – often leading to vendor lock. 
• Graph initiatives are treated as isolated IT projects where only highly technical users get a lot out of the solution. This results in little cross-functional involvement from departments outside of the data or IT teams (e.g., marketing, customer service, product development); where stakeholders and subject matter experts (SME) are not engaged or cannot easily access or contribute to the solution throughout modeling/validation and analysis – leading to the intended end users abandoning the solution altogether.
• Lack of organizational ownership of data model quality and standards. Engineering teams often rely on traditional relational models, creating custom and complex relationships. However, no one is specifically responsible for ensuring the consistency, quality, or structure of these data models. This leads to problems such as inconsistent data formats, missing information, or incomplete relationships within the graph, which ultimately hinders the scalability and performance needed to effectively support the organization.

What Success Looks Like

Graph models rely on high-quality, well-structured business context and data to create meaningful relationships. As such, a data-centric approach requires a holistic view of organizational knowledge and data. If the initiative remains isolated, the organization will miss opportunities to fully leverage the relationships within its data across functions. To tackle this challenge, one of the largest global financial institutions is investing in a semantic layer and a connected graph model to enable comprehensive and complex risk management across the firm. As a heavily regulated financial services firm, their risk management processes necessitate accurate, timely, and detailed data and information to work. By shifting risk operations from application-centric to data-centric, they are investing in standardized terminology and relationship structures (taxonomies, ontologies, and graph analytics solutions) that foster consistency, accuracy and connected data usage across the organization’s 20+ legacy risk management systems. These consumer-grade semantic capabilities are in production environments aiding in business processes where the knowledge graph connects multiple applications providing a centralized, interconnected view of risk and related data such as policies, controls, regulations, etc. (without the need for data migration), facilitating better analysis and decision-making. These advancements are empowering the firm to proactively identify, assess, and mitigate risks, improve regulatory reporting, and foster a more data-driven culture across the firm.

2. Limited Understanding of the Cost-Benefit Equation 

The initial cost of discovering and implementing graph solutions to support early use cases can appear high due to the upfront work required – such as to the preliminary setup, data wrangling, aggregation, and fine tuning required to contextualize and connect what is otherwise siloed and disparate data. On top of this, the traditional mindset of ‘deploy a cutting-edge application once and you’re done’ can make these initial challenges feel even more cumbersome. This is especially true for executives who may not fully understand the shift from focusing on applications to investing in data-driven approaches, which can provide long-term, compounding benefits. This misunderstanding often leads to the premature abandonment of graph projects, causing organizations to miss out on their full potential far too early. Here’s a common scenario we often encounter when walking into stalled graph efforts:  

The leadership team or an executive champion leading the innovation arm of a large corporation makes a decision to experiment with building data-models and graph solutions to enhance product recommendations and improve data supply chain visibility. The data science team, excited by the possibilities, set up a pilot project, hoping to leverage graph’s ability to uncover non-obvious (inexplicit) relationships between products, customers, and inventory. Significant initial costs arise as they invest in graph databases, reallocate resources, and integrate data. Executives grow concerned over mounting costs and the lack of immediate, measurable results. The data science team struggles to show quick value as they uncover data quality issues, do not have access to stakeholders/domain experts or to the right type of knowledge needed to provide a holistic view, and likely lack the graph modeling expertise. Faced with escalating costs and no immediate payoff, some executives push to pull the plug on the initiative.

Early Signs of Failure:

• There are no business cases or KPIs tied to a graph initiative, or success measures are centered around short-term ROI expectations such as immediate performance improvements. Graph databases are typically more valuable over time as they uncover deep, complex relationships and generate insights that may not be immediately obvious.
• Graph development teams are not showing incremental value leading to misalignment between business goals – ultimately losing interest or becoming risk-averse toward the solution. 
• Overemphasis on up-front technical investment where initial focus is only on costs related to software, talent, and infrastructure – overlooking data complexity and stakeholder engagement challenges, and without recognizing the economies of scale that graph technologies provide once they are up and running.
• The application of graphs for non-optimal use cases (e.g., for single application, not interconnected data) – leading to the project and executives not seeing the impact and overarching business outcomes that are pertinent (e.g., providing AI with organizational knowledge) and impact the organization’s bottomline.

What Success Looks Like

A sizable number of large-scale graph transformation efforts have proven that once the foundational model is in place, the marginal cost of adding new data and making graph-based queries drops significantly. For example, for a multinational pharmaceutical company, this is measured in a six-digit increase in revenue gains within the first quarter of a production release as a result of the data quality and insights gained within their drug development process. In doing so, internal end-users are able to uncover the answers to critical business questions and the graph data model is poised to become a shareable industry standard. Such organizations who have invested early and are realizing the transformational value of graph solutions today understand this compounding nature of graph-powered insights and have invested in showing the short-term, incremental value as part of the success factors for their initial pilots to maintain buy-in and momentum.

3. Skillset Misalignment and Resistance to Change

The success of any advanced solution heavily depends on the skills and training of the teams that will be asked to implement and operationalize it. The reality is that the majority of data and IT professionals today, including database administrators, data analysts, and data/software engineers, are often trained in relational databases, and many may have limited exposure to graph theory, graph databases, graph modeling techniques, and graph query languages. 

This challenge is compounded by the limited availability of effective training resources that are specifically tailored to organizational needs, particularly considering the complexity of enterprise infrastructure (as opposed to research or academia). As a result, graph technologies have gained a reputation for having a steep learning curve, particularly within the developer community. This is because many programming languages do not natively support graphs or graph algorithms in a way that seamlessly integrates with traditional engineering workflows. 

Moreover, organizations that adopt graph technologies and databases (such as RDF-based GraphDB, Stardog, Amazon Neptune, or property-graph technologies like Neo4j) often do so without ensuring their teams receive proper training on the specific tools and platforms needed for successful scaling. This lack of preparation frequently limits the team’s ability to design effective graph data models, engineer the necessary content or pipelines for graph consumption, and integrate graph solutions with existing systems. As a result, organizations face slow development cycles, inefficient or incorrect graph implementations, performance issues, and poor scalability – all of which can lead to resistance, pushback, and ultimately the abandonment of the solution.

Early Signs of Failure:

• Missing data schema or inappropriate data structures such as lack of ontology (especially a theme for property graphs), incorrect edge direction, missing connections where important relationships between nodes are not represented in the graph – leading to incomplete information, flawed analysis, and governance overhead. 
• The project team doesn’t have the right interdisciplinary team representation. The team tasked with supporting graph initiatives lacks the diversity in expertise, such as domain experts, knowledge engineers, content/system owners, product owners, etc.
• Inability to integrate graph solutions with existing systems as a result of inefficient query design. Queries that are not optimized to leverage the structure of the graph result in slow execution times and inefficient data retrieval where data is copied into graph resulting in redundant data storage – exacerbating the complexity and inefficiency in managing overall data quality and integrity. 
• Scalability limitations. As the size of the graph increases, the processing time and memory requirements become substantial, making it difficult to perform operations on large datasets efficiently.

What Success Looks Like

By addressing the skills gap early, planning for the right team composition, aligning teams around a shared understanding of the value of graph solutions, and investing in comprehensive training ecosystems, organizations can avoid common pitfalls that lead to missed opportunities, abandonment or failure of the graph initiative. A leading global retail chain for example, invested in graph solutions to aid their data and analytics teams in enhancing reporting. We worked with their data engineering teams to conduct a skills gap analysis and develop tailored training workshops and curriculum for their various workstreams. The approach took five-module intensive training that is taught by our ontology and graph experts and a learning ecosystem that supported various learning formats, persona/role based training, practice labs, use case based hands-on training, Ask Me Anything (AMA) Sessions, industry talks, and on demand job aids tutorials and train-the-trainer modules. 

Employees were further provided programmatic approaches to tag their knowledge and data more effectively with the creation of a standard set of metadata and tags and data cataloging processes, and were able to leverage training on proper data tagging for an easier search experience. As a result, the chain acquired knowledge on the best practices for organizing and creating knowledge and data models for their data and analytics transformation efforts, so that less time and productivity was wasted by employees when searching for solutions in siloed locations. This approach significantly minimized the overlapping steps and the time it took for data teams to develop a report from 6 weeks to a number of days.

Closing 

Graph implementations require both an upfront investment and a long-term vision. Leaders who recognize this are more likely to support the project through its early challenges, ensuring the organization eventually benefits fully. A key to success is having a champion who understands the entire value of the solution, can drive the shift to a data-centric mindset, and ensures that roles, systems, processes, and culture align with the power of connected data. With the right approach, graph technologies unlock the power of organizational knowledge and intelligence in the age of AI.

If your project has any of the early signs of failure listed in this article, it behooves you to pause the project and revisit your approach. Organizations embarking on a graph initiative, not understanding or planning for the foundations discussed here frequently end up with stalled or failed projects that never provide the true value a graph project can deliver. Are you looking to get started and learn more about how other organizations are approaching graphs at scale or are you seeking to unstick a stalled initiative? Read more from our case studies or contact us if you have specific questions.

The post Why Graph Implementations Fail (Early Signs & Successes) appeared first on Enterprise Knowledge.

The Solution

To determine the data discovery processes that stakeholders undergo when searching for data metrics and process information, EK engaged stakeholders from various different levels of the organization to gather a wide range of insights on data handling challenges and to create a solution that worked for all organization users. EK created four distinct use case journey maps representing stakeholders at various organizational levels, mapping out the state of the organizational data landscape at the beginning of EK’s engagement. These journey maps allowed for the documentation of current process opportunities and challenges. EK leveraged this process to help the organization prioritize and identify the most critical challenges/pain points to be addressed. 

Then, EK worked with the client to identify and standardize shared organizational metadata terms and develop an enterprise taxonomy and data labeling system in order to better organize data and ensure that data does not get lost outside of the taxonomy. This step was crucial for simplifying data discovery and ensuring that similar data products could be found using a standardized set of metadata tags. 

Additionally, EK created sets of training materials for data product discovery and the creation/maintenance of proper taxonomy use, as well as a business metadata glossary containing multiple definitions so that users could easily tag and search for data products. Finally, EK created a foundational ontology model linking data elements to one another and data products to their corresponding metadata, which improved data product searchability and reduced the amount of lost data. Overall, this ontology served as a backbone schema (explicitly making relationships between data assets machine readable) for the data architecture, enhancing the coherence and usability of information.

 

The EK Difference

Our team worked closely with the chain and dedicated extensive time and effort towards understanding the user experience when searching for information. EK’s semantic architects, metadata/taxonomy and ontology experts were able to then create a tailored solution to make the information search process easier and more accessible. By interviewing data product users on their search process and creating comprehensive user stories and journey maps, EK’s experienced semantic ecosystem professionals readily identified issues that could subsequently be rectified with solutions that EK has implemented repeatedly and successfully for other companies. 

Being at the forefront of the enterprise ontology field, EK’s ontologists used their extensive expertise, including semantic web standards, advanced data modeling techniques, and ontology design to lay the foundations of a domain ontology that provided the chain with a future pathway towards a wholly integrated enterprise semantic search and data discovery platform. With the creation of eight separate enterprise taxonomies, a comprehensive business glossary tailored to organizational-specific needs, and training materials on taxonomy and metadata standardization to guide the chain’s employees on the proper tagging and organization of data products, EK laid the groundwork for a well-organized foundational data landscape to facilitate scale and expansion to additional metrics and users. 

Finally, with EK being an industry leader in developing and implementing the Semantic Layer, the chain was able to implement multiple facets of the framework required to stand a Semantic Layer up, which include the domain ontology, taxonomies, and business glossary mentioned above. This laid the groundwork for further interconnectedness of the organization’s data and knowledge assets, as well as the users that rely on this information as part of their essential job duties.

 

The Results

In the engagement with EK, the chain overall improved the searchability and reusability of their data products, as well as the ease with which key decision makers and data analysts can create, modify, and reuse data products. This approach significantly minimized the overlapping steps and the time it took for data teams to develop a report from 6 weeks to a number of days. The chain was also able to gain a better understanding of their users’ data search behaviors, including how various personas in their organization search for knowledge and data, especially across multiple sources in their data landscape, giving the organization the flexibility to identify key store trends and act on them more swiftly. Employees were provided programmatic approaches to tag their knowledge and data more effectively with the creation of a standard set of metadata and tags and data cataloging processes, and were able to leverage training on proper data tagging for an easier search experience. Through this Semantic Layer, the chain acquired knowledge on the best practices for organizing and creating knowledge and data products for their data and analytics transformation efforts, so that less time and productivity was wasted by employees when searching for solutions in siloed locations. The result was a more efficient, better-informed, and highly responsive business environment, setting a new organizational data management standard. 

Want to improve the way your organization manages data/information? Are your employees stuck searching for analytics data, slowing down the decision-making process? Contact us at info@enterprise-knowledge.com to get started!

 

Download Flyer

 

The post Enhancing Retail Performance with Semantic Layer As an Enabler for Data and Analytics Teams appeared first on Enterprise Knowledge.

Companies that sell products, however, can further improve product management and sales if they implement customer-facing taxonomies along with other semantic structures, such as metadata sourced from other systems and ontologies, as a part of a larger information/data management strategy. The best way to do this is to take a semantic layer approach, in which the semantic components (taxonomies, metadata, glossaries, ontology, etc.) connect to each other and connect across different systems and data repositories. 

Uses of Product Taxonomies and Metadata

Product taxonomies have multiple uses beyond browsing through product categories on an e-commerce website. Both customers and product managers may benefit from taxonomies in a variety of ways.

Sometimes, users want to browse and explore types of products, and that is when a hierarchical taxonomy of product categories is most useful. Other times, users know the product they want and would like to see if the e-commerce vendor has the specifications they desire. In such cases, the users enter a description in the search box and then refine their search results by selecting among various attributes, which are managed as product metadata and are presented to the user as a faceted form of taxonomy. Attributes may include size, color, material, and category-specific features. 

Taxonomies also support user discovery of new or related products. Users search when they know what they want, and browse when they have an idea or want to better understand the overall offerings available. “Discovery,” alternatively, refers to when users find things that they did not initially look for but are still of interest. Retailers can sell more products when they support discovery. This can be done in different ways: 

• By properly displaying taxonomy category names and allowing users to navigate up and down the hierarchy;
• By including and enabling “related category” relationships in the user interface to let users navigate laterally across the taxonomy to find related products;
• By implementing a supplemental taxonomy, such as for product function and not just for product type, users can discover different products for the same purpose.

Taxonomies and metadata for products are not just for the customers. Product vendors need to manage products by means of their metadata for various purposes: purchasing from suppliers or wholesalers, controlling inventory, fulfilling orders, or updating images of products. While detailed metadata is key, category taxonomies are also useful, such as for identifying closely related substitute products or vendors for the same product line.

Uses of Ontologies for E-Commerce

An ontology extends a taxonomy by providing greater semantic enrichment in the forms of custom relationships and custom properties. Custom relationships between taxonomy terms or categories go beyond “broader/narrower” and generic “related,” and may include relationships for products such as “goes with,” “compliments,” “has parts,” “has add-ons,” or “has optional services.” Custom properties can be used as attributes for terms or categories, comprising metadata and controlled values, such as size, which can be applied to filter product search results. 

Custom relationships between product categories support more options for discovery than a basic taxonomy can do. Not everyone agrees on what “related” means, and users may not agree with what someone else suggests is related. Defined relationships based on an ontology, such as “compliments,” or “has add-ons,” lets the user discover the types of related products of interest. Custom relationships may also link product categories to related services offered, such as product installation and product support, and to different types of content about products.

For custom attributes, each search filter/refinement is a metadata property with controlled values, and the metadata properties and values available depend on the product category. For example, “material” is an attribute for clothing, accessories, and furniture, but it is not for consumer electronics. Furthermore, the types of material available for clothing are not the same as for furniture, and they are not even the same for all types of clothing. Leather, for example, may be available for jackets but not for shirts. This can become quite complex to manage, but an ontology, which systematically links properties with categories, manages this task well.

Related to discovery is recommendation, which directly presents the recommended related products to the user. There are different kinds of recommendation methods. Common methods that base recommendations on past searches by the customer or other customers are not as beneficial if the customer has already purchased the searched product and does not need more. Recommendations based on the custom relationships of an ontology, however, such as “goes with,” are more useful. Recommendations may also be based on certain attributes, such as products with the same style or pattern.  

Connecting Product Systems

Multiple different systems within an organization may deal with product data, metadata, and taxonomies. The most common are web content management systems (CMSs) for the e-commerce website, product information management (PIM) systems for the backend management of all product data, and digital asset management (DAM) systems for product images and videos. Some organizations also have data catalogs, master data management systems, media asset management systems, and product data may also be stored in a customer relationships management system used by sales and marketing people. Meanwhile, any product technical documentation is likely stored in another CMS. If an ontology is in use to model product data, then it is likely to be managed, along with a taxonomy in a dedicated taxonomy/ontology management system. 

The problem is that each of these different systems tends to be siloed, so their data and metadata is separate and thus not the same nor in sync. Products may have slightly different names in different systems, and they may have slightly different metadata property names and even varying metadata values. For example, one system could have category sizes of small, medium, and large, while another uses numerical sizes for the same product category. Taxonomies could vary even more greatly than the metadata. One system may have a flat list of product categories, whereas another system has a 2-level hierarchy of categories and subcategories. It is typical to have different taxonomies and metadata in different systems because they support different users and use cases. 

If the same data in these different systems is not described consistently and not connected, problems could arise from incomplete and missing data about product supplies and sales, such as poor decisions and missed opportunities. Trying to execute consecutive searches in multiple systems is very inefficient and is also prone to overlooking information. Finally, incomplete or inaccurate product information can result in a poor user experience for the customers. 

A semantic layer framework provides a method to link data in different systems with a shared common metadata set and taxonomy.

Semantic Layer Benefits

A semantic layer is a standardized framework that organizes and abstracts organizational knowledge and data (structured, unstructured, and semi-structured) and serves as a data connector for all organizational knowledge assets. A semantic layer enables data federation and virtualization of semantic labels or rules to capture and connect data based on business or domain meaning and value. It’s a method to bridge content and data silos through a structured and consistent approach to connecting, instead of consolidating, data. It is called a “layer” because in the larger framework, it is a middle layer between the content/data repositories and one or more front-end applications for users to search, browse, analyze, or receive recommendations of information.

There are different approaches to implementing a semantic layer but the most common is a “metadata-first” logical architecture, which creates a logical layer that abstracts the underlying data sources by focusing on the metadata. Since product information is rich in metadata, this approach is most suitable for linking product systems and their data. 

Systems connected through a semantic layer offer various benefits. For managing products and e-commerce, these include the following:

• When PIM or fulfillment systems are connected to the e-commerce platform, new products and product updates can be added more quickly, and specific product availability can be indicated in real time, rather than later; 
• When a DAM is connected to the e-commerce platform, product images can easily and quickly be refreshed with the latest versions, which is especially beneficial for seasonal items and promotions;
• When a CRM and an e-commerce platform are connected, sales people know all the product details including the customer-facing product name and can better facilitate sales to prospects;
• When technical documentation CMS and an e-commerce platform are connected, customers have access to product data sheets, and customer support representatives can better serve customers. 

A semantic layer allows an organization to build applications for users to access and interact with various sets of connected data and content better. For product information, such applications include search interfaces that seamlessly integrate product categories and attributes along with add-on services, recommendation systems for customers to discover products, chatbots for customers to get support, and data dashboards for product managers to track product data.

The post How Semantic Layers Support Product Search and Discovery appeared first on Enterprise Knowledge.

First, let’s describe what an orchestra is. An orchestra is an ensemble of instruments that includes woodwind, brass, string, and percussion sections. A group of musicians performs various pieces of music with these instruments, creating a captivating experience for an audience. Under the direction of the conductor, everyone needs to play music in harmony to ensure that the audience enjoys the music performance. An orchestra performance is an example of leadership, collaboration, coordination, learning, and exemplary execution, a lot like the characteristics needed to successfully manage knowledge in any organization. 

For the purpose of this blog, organizational content is the equivalent of the music that is delivered by an orchestra to the target audience. Let’s take a look at how similar content management is to an orchestra performance.

Orchestra Performance
Content Management
Music
Organizational Content
Conductor	Instruments	Musicians	Music Sheet	Audience
Content Lead	Content Types	Content Authors and Content Owners	Business Taxonomy	End Users (internal or external)

The Conductor (Content Lead)

An orchestra conductor has a vision of how the orchestra should sound when playing each piece of music. The conductor keeps an orchestra in time and together, lets each musician know their time of entry, and is able to give each musician direction about what they should be doing at any given moment during the performance. One of the main responsibilities of a conductor is to fully understand each piece of music and effectively communicate to the musicians so that they understand it completely, which is mostly done with gestures and the aid of a baton. Additionally, by being readily available to the musicians prior to the performance as well as visible from a podium during the performance, the conductor ensures that the communication channels with all orchestra members are effective at any given time (e.g. during rehearsal, on stage, etc.).

Similarly to an orchestra conductor, a Content Lead needs to have not only a clear vision of all key content areas in the organization, but also the ability to effectively communicate with content authors and content owners, so that they can create, tag, and maintain quality content. Defining a content governance plan, a taxonomy governance plan, and identifying effective communication channels and tools (what would be the gestures and the baton for the orchestra conductor) are essential to transfer that content management vision to content authors and content owners successfully. Examples of communication channels and tools may include recurring group meetings, one-on-one discussions, centralized content repositories, portals, and any other tools that can help govern content and taxonomies consistently. 

The Instruments (Content Types)

From the lively and sparkling sounds of violins to the dry and rattling sounds of percussion instruments, the graceful and clear sounds of a flute to the vibrant brass sections, listening to all the instruments playing together and in harmony in an orchestra is an impressive musical spectacle. Each instrument has a different appearance, a different purpose, and requires a specific technique to be played. They all produce different sounds that when put together, produce a magnificent piece of music. 

Even though content types are not as graceful as musical instruments, in content management, content types represent types of instruments, each with a purpose to create and manage a specific type of content. Content types are like templates for categories of content with corresponding taxonomies that allow managing information in a centralized, reusable way. Some content types are designed to create announcements, others to create corporate policies, but together, all content types help communicate key organizational content to the end users in a standard and consistent way. 

The Musicians (Content Authors and Content Owners)

Without exception, successful orchestras around the world have clearly defined roles and responsibilities. If the conductor has done a good job communicating the expectations of the musical performance to the musicians, and the musicians have mastered playing their own instruments, then they can play their instruments accordingly and transmit a unified vision of the music to the audience. Every musician must not only follow the same set of music sheets, but also understand their own role, the roles of their fellow musicians, and when the handoffs need to take place during the performance. 

Similarly, in content management, the content authors and content owners are like the musicians. They are tasked with very specific roles, in this case to create, tag, manage, and disseminate organizational content. If they have a good understanding of the organization’s content management objectives and have the knowledge management skills needed to perform their roles, they can effectively create and maintain organizational content, communicating a clear and unified vision of the content to the end users. In the same way that musicians spend time practicing and learning the skills to master their instruments, content authors and content managers need to clearly understand how to leverage content types and taxonomy to create and manage content and master the skills needed to meet their content management responsibilities.

The Music Sheet (Business Taxonomy)

In an orchestra, even though every instrument gets their own music sheet, the conductor gets a full score, or in other words, a music sheet that contains the musical notation for all instruments, so that the whole orchestra starts playing together at the same time and performs at the same tempo throughout the performance. 

An enterprise taxonomy represents that standard point of reference that can help orchestrate organizational content, so that content authors and content managers can ultimately leverage content types and taxonomy together to collaborate and produce consistently tagged, high-quality content.

The Audience (End Users)

Focusing on a particular target audience when planning and rehearsing for a performance helps musicians connect with their audience during the actual performance. Who is the audience? What is the music really trying to convey to the audience? From behind their music stands, the musicians sitting nearest the audience typically sit at a diagonal facing partly toward the conductor and partly toward the audience, so that the audience can be more engaged. Those in the front rows can look at the musicians closely, see them smile at the end of each musical piece, and more naturally react to the music with joy.  

In content management, learning about your audience is indispensable to serve end users with the content they need, when they need it. Depending on the type of organizational content and where it will be displayed (e.g. Intranet, portal, dashboard, etc.), your audience may be internal, such as employees, or external, including customers, partners, and even prospective groups. Understanding your audience means gaining a clear understanding of their motivations, needs, goals, and challenges, so that the content is delivered in a manner that meets their content needs, resonates with them, and appeals to them. The use of personas and user stories help organizations move from knowing their audience to most importantly, understanding their audience and delivering timely, targeted content. In the same way that a venue may solicit feedback from the attendees to identify how well received the orchestra performance was, there are multiple approaches that organizations can take to measure the effectiveness of their content and identify whether the content is performing as expected. Only if content is measured, it can be managed and improved.   

Conclusion

By helping your organization focus on these five elements, you could find yourself delivering an exemplary knowledge management performance alongside a content management team that earns a standing ovation. Next time you go to an orchestra performance, and while you enjoy the music, try closing your eyes and think about all that was required to make that performance happen. 

Need help with orchestrating your organization’s content management journey? Contact us.  

The post Five things that Content Management and an Orchestra Performance Have in Common appeared first on Enterprise Knowledge.

Vilenio’s presentation will share common use cases for pursuing a recommender system and discuss how to leverage and enrich business taxonomies to calculate relevancy and derive knowledge graphs driven by Semantic Web based  standard technologies like ontology management and graph database platforms. Further, Vilenio will explore how organizations can derive and expand the meaningful features supported by knowledge graphs.    

The webinar will be held on Thursday, November 19, at 11am EST. Register for the webinar here.

The post Vilenio to Speak at an Upcoming Webinar on Turning a Taxonomy into a Recommendation Engine appeared first on Enterprise Knowledge.

In this two-part blog series, I’ll share some common mistakes we see when it comes to taxonomy design and offer guidance around how to ensure your organization’s business taxonomy can avoid these pitfalls and be best positioned for success. More specifically, this first installment will share some of the most common taxonomy design mistakes that stem from organizations failing to design their taxonomy with a user-centric approach, with part two focusing on identifying and involving the most critical systems and users throughout the design process. By starting your taxonomy design efforts on the right track, you can ensure that your taxonomy design meets the wants and needs of your end-users, gains adoption, and is immediately intuitive to those who engage with it.

What is a Business Taxonomy?

At Enterprise Knowledge, we define a business taxonomy as a controlled vocabulary that is used to describe or characterize explicit concepts for the purpose of capturing, managing, and presenting information. In other words, taxonomy design can be thought of as a way to categorize your organization’s current and future content items in a consistent and intuitive way so that employees, stakeholders, and/or customers can quickly and easily store, manage, and retrieve the information that they need. Designing an effective taxonomy is all about collecting the information that is already available, then organizing it to help your end users find and use the correct information efficiently and effectively. The end product—a taxonomy— is a standardized list of terms that can be applied to product categorization, web site structure, and faceted navigation.

Mistake #1: Purchasing an Off-the-Shelf Taxonomy

One of the primary reasons we have seen taxonomy designs not provide their optimal value to an organization is because that organization has opted to purchase an “Off-the-Shelf” taxonomy design rather than develop a taxonomy exclusively for their unique end users. An “Off-the-Shelf Taxonomy” is marketed as a “one size fits all” taxonomy that is designed and sold by a vendor for a particular industry, domain, or type of organization. For example, an automobile manufacturing organization may purchase an off-the-shelf taxonomy designed for organizations within the manufacturing industry, thinking “If this taxonomy is based around industry language, it must work for my organization.” 

The primary problem with an off-the-shelf taxonomy design is that it relies on generic industry terms or means of categorizing information rather than the content, language, and knowledge that is leveraged every day to make your unique organization successful. Ultimately, an off-the-shelf taxonomy design, because it is likely too broad or unnecessarily detailed for your organization, will cause your end users to suffer from an inability to find or discover the information that they need to do their job, make a purchase, or complete a task. In some cases, your end users might not even recognize terms in the taxonomy at all, leading to confusion and/or abandonment of the system or site in which the taxonomy is leveraged. This can lead to the following impacts on taxonomy end user groups: 

Mistake #2: Designing a “Do It Yourself” Taxonomy or Not Using a Third Party

Many of our clients partner with us at Enterprise Knowledge to tackle their taxonomy design after they have worked to design a taxonomy using internal resources. Oftentimes, this previously designed taxonomy did not provide adequate value to the organization because an individual or small group within the organization acted as the primary designer(s). By designing a taxonomy largely in isolation, with only the input and purview of a small group being taken into account, it is more likely that the taxonomy design will not work for a more diverse end user group and contains unintentional biases or motives held by those employees. For example, we worked with a client whose cross-departmental taxonomy was developed solely by two members of the IT department. While the entirety of the organization’s IT department found the taxonomy to be extremely valuable in facilitating the tagging and findability of the content items that they needed, other departments who were utilizing the taxonomy found it to be too granular for certain types of content and too generic or confusing for others. This led to a taxonomy design that only worked well for one of the multiple departments that relied on it to find the content they needed to do their jobs. 

Similarly, while taxonomy research and literature is abundant, having an expert taxonomist be involved in or lead your organization’s taxonomy design efforts will enable you to yield better results post-implementation, as you will guarantee that their experience and knowledge will be brought to bear during the development phase. In our experience, while some organizations are able to accurately capture the language of their users, many lack dedicated taxonomy experience, leading to a taxonomy design that does not adhere to best practices, is not structured in a way that lends to machine readability, or cannot be properly implemented into the intended system or repository. In some cases, it is best for the taxonomy expert to be an individual outside of your organization, as they can be completely removed from company biases or relationships and serve as a mediator and primary decision-maker when necessary. 

Mistake #3: Avoiding a Taxonomy Design Altogether

With artificial intelligence and semantic technologies becoming increasingly popular across a host of industries, many of our clients come to EK to determine the right place to start for their organization. All too often, however, organizations want to start at the cutting-edge and neglect the foundational role that a business taxonomy plays in enabling these technologies, and their business, to be successful.

Arguably, the biggest taxonomy design mistake that an organization can make is to not design a taxonomy at all, particularly if that organization is seeking to increase its maturity in knowledge management and semantic technologies. A business taxonomy not only drives the classification and findability of information, information architecture, and search filtering/faceting, but paves the way for artificial intelligence and semantic technologies by creating standardization and alignment across an organization. As outlined in the EK blogs “From Taxonomy to Ontology,” and “Natural Language Processing and Taxonomy Design”, taxonomies serve as the building blocks for ontologies, knowledge graphs, and other semantic technologies by identifying basic similarities and hierarchical relationships between concepts and content within the organization that can be leveraged to develop more complex, flexible relationships between entities and knowledge assets. By developing a successful business taxonomy, you can ensure that your organization’s semantic technology efforts align with the actual content or domain you are working in and accurately model your organization’s knowledge and information.

Avoiding Common Pitfalls Through a User-Centric Taxonomy

The best way to avoid the common taxonomy mistakes described above is to design a user-centric taxonomy, in which representatives from primary end users groups are involved in the process from the very beginning. By engaging end users in workshops, interviews, focus groups, system demos, and validation activities, you can ensure that your organization’s business taxonomy design is usable, intuitive, and valuable to a majority of user groups. Further, by identifying and involving the most critical end users and system considerations into your taxonomy design, as I will discuss in part II of this blog series, you can ensure that your business taxonomy is designed with the right needs, motivations, and system capabilities in mind. Using our proven Business Taxonomy Design Methodology, EK can help you design and implement a business taxonomy that works for your organization and its goals. 

Interested in learning more? Contact us at info@enterprise-knowledge.com to speak with our team of taxonomy experts.

The post Common Taxonomy Design Mistakes, Part I: Failing to Include Your End Users appeared first on Enterprise Knowledge.

Human knowledge can often be unclear and contradictory. As taxonomists, we deal with information that can be incomplete, implicit, or ambiguous, and it is our goal to make this knowledge not only useful and intuitive for large groups of people, but to make it explicit and machine-readable. Before we can get there, however, we typically confront some very practical dilemmas: How do we get this ‘right’? How do we deal with ambiguity or complex domains? How do we gain alignment across an organization? 

In this blog, I will share the common taxonomy design challenges that arise due to the nature of information and knowledge and how to overcome them – getting a taxonomy design just right for an organization, confronting ambiguity and domain complexity, and overcoming bias. 

How to Get a Taxonomy Design Right

Every taxonomy design is different and unique to an organization, and thus requires multiple iterations to get it ‘right.’ Although some initial taxonomies are passable by industry standards for an organization’s domain, the first iteration doesn’t always quite connect the dots for how a specific organization delivers its services and organizes their business processes. 

The simple fact is, it’s quite possible you’re going to get it wrong the first time. There’s no easy way around this. The best option is to accept and embrace iteration. Design Thinking, the human centered approach to solving problems at the intersection of people and technology, is an important aspect of taxonomy and ontology development for a reason; it is a necessarily iterative process because human knowledge is imperfect, it’s always changing, and we can’t always have the full picture. This is why we embed frequent design and validation sessions when designing taxonomies for our clients in order to fail-fast, learn early, and test our design hypothesis, ultimately presenting the taxonomy in ways that are meaningful to the users. 

This approach allows us to question and release any attachments to existing designs or ways of thinking that no longer serve the project, especially as Agile methodologies are becoming more and more integral to the taxonomy and ontology process. Design Thinking approaches also allow us to consider all the touch points that are related to taxonomy – business processes, use cases, and personas that, while not a part of a taxonomy structure, provide the necessary context that will add value and ensure the design is user-centric. As designers, EK is adept at providing the right balance between effective industry practices for your organization’s domain while focusing on what should be adjusted in order to design a model that works for the people who will be using it. This is what EK refers to as a Business Taxonomy approach, which allows for more flexible adherence to traditional taxonomy rules in order to ensure that business values remain centered.

Complexity and Ambiguity: Is Domain Knowledge Required?

Imagine you’re the taxonomist for the legal team in a large retail organization. You’ve been tasked with building a taxonomy that will help the legal team organize and retrieve their contract templates. Obviously, the legal domain is a complex and highly varied field that requires years of study and practice to master. While you can, and should, rely heavily on the expertise of the legal team to understand the type of content you need to organize, in the end, it’s not your goal to master all the intricacies of legal documents, their clauses, jurisdiction, and Latin nomenclature. Your goal is to understand the team’s needs and the ways a taxonomy can meet those needs.

It’s not feasible for taxonomists to know everything about the domains we model. In fact, I would argue it is important for taxonomists to resist knowing everything, though we may feel obligated to learn everything about a domain. While taxonomists must take time to research and quickly know the basic concepts, it is all too easy to lose sight of the ultimate goal: to provide a usable taxonomy that delivers the intended business outcomes for the organization. This is why the best taxonomies and ontologies involve input from subject matter experts and end-users, and should never be constructed in isolation by one individual. The users and subject matter experts know the nature of the content and can help ensure the taxonomy is complete, while taxonomists focus on building the structures that will make that content usable, discoverable, and even more valuable.

How to Gain Alignment in Taxonomy Design

Involving these key audiences brings me to the next point: overcoming bias and gaining alignment. Knowledge is inherently collective and relational. You’ve gathered end users and subject matter experts, and you’re committed to gathering their input for the taxonomy. Great! But, who isn’t seeing your design? Whose perspective is missing? This is more than having a diverse representation in your meetings and focus groups; it is about minimizing unconscious bias and democratizing the ownership of the design.

Bias often appears in taxonomies when they are constructed in a silo with a specific purpose or use case in mind. This becomes a problem when those taxonomies are considered for use across an enterprise. Typically, this situation often takes the shape of a region’s dominant vocabulary (say, North America) becoming the standard for the global business, supplanting the language and terminologies of smaller teams across the world. Forcing these teams to adopt certain vocabularies could potentially isolate them and widen the information gap. Alternatively, when done ‘right,’ taxonomies can be used as an opportunity to accommodate varying terminologies and find alignment across teams in order to achieve a common goal.

A core component of EK’s taxonomy design strategy is a bottom-up and top-down analysis, which can help navigate the potential pitfall of bias. The bottom-up approach allows you to become familiar with the systems and content that will be impacted by a taxonomy, and may include information that may not be directly accessible by the project managers of a taxonomy project. The top-down analysis, such as conducting extensive focus groups and interviews across an organization’s business units or geographical locations, captures a holistic picture of the pain points different types of users face when interacting with their information. Further, once an initial design is completed, activities such as card sorting and test tagging can be used to validate the taxonomy, ensuring that the design is intuitive and usable for as many people as possible. These validation activities then inform the next iteration of the design, which can drive consensus as more perspectives are incorporated. The resulting taxonomy is ready to be deployed and can enable the organization to advance into ontologies and knowledge graphs, which are a key pillar for Enterprise Artificial Intelligence.

Conclusion

Overall, these design challenges are best overcome by utilizing Design Thinking processes and understanding the pains and frustrations that users are facing, and the specific tasks they are trying to accomplish. By staying close to the users, the path forward often becomes clearer by shifting the focus from how you are designing, to why you are designing. If you experience frequent disagreements on a design, think of it as an opportunity to reframe the discussion and find alignment. Recall, failure is inevitable and it is best to embrace it, iterate, and take advantage of Design Thinking strategies to overcome challenges and deliver a user-centric design. 

Are you dealing with these specific challenges in creating a taxonomy or knowledge management strategy for your own organization? Contact Enterprise Knowledge to see how our expert team of taxonomy designers and knowledge management strategists can create a custom solution to meet your goals.

The post Overcoming Enterprise Taxonomy and Ontology Design Challenges appeared first on Enterprise Knowledge.

Mary Little, EK Knowledge Management Practice Lead, and Megan Salerno, Senior Content and Taxonomy Analyst, will lead the conference attendees through their presentation: Designing a User-Centric Taxonomy for Your Omni-Channel Strategy. Little and Salerno will provide an overview of what a taxonomy is and how it can enable an organization’s omnichannel strategy. Further, they will discuss recent case studies that demonstrate how taxonomies can be leveraged for a variety of targeted user groups to enhance omnichannel content orchestration and personalization initiatives. Attendees will leave their presentation with the necessary knowledge to develop user-centric business taxonomies, identify key user groups, and utilize proven practices to ensure an organization’s taxonomy is scalable and flexible.

In addition to providing thought leadership, Enterprise Knowledge is a Gold Sponsor for this year’s conference. “As part of our ongoing commitment to global thought leadership, we’re happy to serve as a sponsor for this important conference. The alignments with our core knowledge and information management efforts make this conference a great place for us to be,” said Zach Wahl, CEO of Enterprise Knowledge.

Do you have a passion for content, communication, and UX and want to use your talents even more effectively? Then join EK thought leaders Mary Little and Megan Salerno, along with other industry leaders this June. Register here. 

The post EK Sponsoring and Speaking at OmniChannelX 2020 appeared first on Enterprise Knowledge.

What does a modern taxonomy do?

Taxonomies are a proven means of describing content using a controlled vocabulary. A modern taxonomy improves findability by being flexible and allowing faceting. Users can cross-cut information during search and browse facets to narrow down huge amounts of information to what they are specifically looking for. Giant e-commerce sites like Amazon have made taxonomies familiar to everyday online shoppers in their product search, even if not by name. However, the value and use of taxonomies is not limited to faceted searching or browsing. Taxonomies also serve as the foundations of autotagging, ontology design, and the implementation of knowledge graphs and AI capabilities. At its core, a taxonomy describes the domain of information through a standardized vocabulary, capturing synonyms and alternative ways of describing the same concept, as well as basic relationships between concepts (broader, narrower, and related terms). This initial structuring of an information domain can then be leveraged by knowledge graphs and AI, making taxonomies an essential building block for advanced semantic solutions. Organizations who understand the value of taxonomies and how they enable future technologies will be better poised to take advantage of AI and semantic tools.

Limitations of a taxonomy that are opportunities for a knowledge graph

Strict Hierarchies can be limiting

A taxonomy is a controlled vocabulary structured in a hierarchy where narrower or child terms are grouped under broader terms, or parent terms, making a tree structure. A common example of a taxonomy tree structure is a geographical hierarchy. On the first level of this model, we may have countries, then within each country, we can break down the geographical categories into smaller groups, such as states or provinces, and within each state, cities. However, consider if we also wanted to include continents in this model. Some countries, for example, Egypt, are transcontinental and span more than one continent (Africa & Asia). If we added continents as broader terms in our taxonomy, we would end up with polyhierarchy, or the same country appearing in more than one location in the taxonomy. Because the relationships in a taxonomy are limited to “broader than”, “narrower than”, and “related to”, it’s often difficult to understand what a polyhierarchy means. In our geographic taxonomy, we might guess that a narrower term is located within a broader term, but how do we interpret a term, like Egypt, that would have two broader terms in this design? Does the model mean that Egypt as a whole is located in both Africa and Asia, or, that Egypt is partially in one continent and partially in the other? The problem is we only have the “broader than” and “narrower than” relationships to handle this nuance in meaning. Instead, if we can take a different approach and design a more flexible ontology with specific relationships like “is partially in”, the ambiguity presented by taxonomy polyhierarchies can be avoided entirely.

Taxonomies lack attributes that describe the taxonomy terms themselves

A taxonomy model includes only the terms and their synonyms, not additional attributes about the terms, or metadata about the metadata. It is important to capture additional details about the terms in a taxonomy such as how/where they can be used, what systems consume them, or when they were last reviewed/approved, etc. Many taxonomy management systems utilize SKOS, the Simple Knowledge Organization System, which is a simple ontology commonly used to model a taxonomy by adding a few additional attributes such as Scope Notes, Definition, and Hidden Labels, as well as a generic Related To relationship. However, even with SKOS, it is not possible to define explicit or custom attributes for the taxonomy terms. Just as in the previous example, we are limited by the constraints the structure of a taxonomy gives us.

Taxonomies cannot infer or recommend

Taxonomies mainly describe information and do not have the structures required to provide meaningful inferences to further find relationships between different pieces of information. The only way you might infer information with a taxonomy is by following hierarchical relationships — for example, if two concepts share the same parent concept, you might infer that they are  similar or related in nature, but without domain expertise, you can’t understand exactly how they are related. Using a more complex ontology, you can create and specify many non-hierarchical relationships that you could use to infer, increasing the flexibility of your data and removing the ambiguity and limitations created by the strictly hierarchical relationships possible in a taxonomy. Advanced semantic applications like natural language processing and recommendation engines based on explicit or inferred relations between terms are not possible without enhancing your taxonomy with an ontology that describes an organization’s information domain, otherwise known as a knowledge graph.

How taxonomies can be used with a knowledge graph

Knowledge graphs are semantically meaningful ontologies that describe and relate sets of information entities relevant to an organization’s information domain. For example, a very simple knowledge graph could include people, publications, and offices as entities. Some relationships between the entities could be: people “author” publications and “work at” offices. The main challenge of designing an effective knowledge graph is developing its model, which identifies the different types, or classes, of entities, what relationships they have, and how they should be described. Taxonomies are especially helpful as input to the development of a knowledge graph. Here are a couple of ways taxonomies are used to develop and improve knowledge graphs:

Sources of Controlled Lists

The greatest advantage of having a taxonomy or set of taxonomies is the establishment and curation of controlled lists of business terms. The effectiveness and relevance of a knowledge graph will depend on what metadata is available to arrange in the graph. By having taxonomies ready for use in other applications, the knowledge graph can tap into these lists to add rich context to an organization’s data. In addition, because the taxonomies are already structured and developed for business use, knowledge graph development will not have to begin from scratch. For example, popular taxonomies include topics, organization structure, and skills. Topic taxonomies are excellent sources of terms to describe almost any type of content including both unstructured or written content as well as data sets. One can imagine a knowledge graph that has entities like publications that can be associated with the topics they are about from a topic taxonomy. Also, org. structure and skills terms can be applied to people entities in the knowledge graph by allowing the knowledge graph to capture where they work and what they can do. The knowledge graphs in these cases are using the information contained in the taxonomy and relating it to the actual people, places, and things that taxonomy terms can describe. These relationships in the graph become a rich fabric of meaning surrounding data, content, and information that can capture complex business concepts.

Taxonomies often have their own governance processes to ensure the lists are correct and standardized for the organization. This means the knowledge graph will not need its own governance process for the same sets of terms. Since the taxonomies will already be properly arranged and verified during the taxonomy governance process, the knowledge graph will simply “read in” the information defined by the taxonomy, as this information will already be correct and ready for use.

Initial Domain Design

Taxonomies can also provide input to the overall design of the ontology for a knowledge graph. Knowledge graphs are structured to capture the knowledge domain of an organization. Therefore, to design the best knowledge graph, a data modeler, or ontologist, will need to understand what types of information are available at the organization and how they are related. Taxonomies often provide clues as to what the key types of information are that a knowledge graph needs to cover. This idea is similar to how taxonomies can be used to supply metadata for the graph. Instead of focusing on the exact values from the taxonomy to use in the knowledge graph, the ontologist analyzes the taxonomy to understand what entities the lists describe. From the earlier example, a skills taxonomy might describe a person that has the skill or an org. department that specializes in the skills. The entities “person” and “org. department” could be key entities in the knowledge graph design that should be related together and to other entities such as skills and given descriptive properties by the ontologist. Using the topic taxonomy example, topics typically describes different types of things that are topical in nature. For instance, the topics could describe books, the subject of an instructional course, or other types of content. In this case, the books, publications, or instructional courses could be additional entities the ontologists adds to the knowledge graph.  

Relating Content for Recommendations

Another way that taxonomies can impact knowledge graphs is as tags that relate to other entities. A common example of this use case is in the development of content recommendation systems. Taxonomy terms can be used to autotag content such as articles or other documents. Then, these pieces of content can be represented in the knowledge graph with relationships to their tags. The knowledge graph can be used to identify content that shares these tags. This is precisely the set up you need for a content-filtering use case for generating recommendations for content. Content can be grouped according to similar tags and recommendations are generated from these groupings. If people and their interactions with content are also features of the knowledge graph then collaborative filtering can be used to generate recommendations. In this case, the relationships between people and content are key to determining relevant content. For instance, a coworker can share an interest in geography that is demonstrated by multiple interactions with content that are about geography. Your coworker also may like astronomy in addition to geography, but you currently have not interacted with content on astronomy yet. Astronomy can be suggested as a recommended topic for you to explore based on the shared interest in geography with your coworker. Again, using the knowledge graph, once astronomy is recommended, it is easy to identify all the content tagged with astronomy and to then recommend those to the user.

How do a taxonomy and a knowledge graph fit together from an enterprise data architecture perspective?

Taxonomies and knowledge graphs are complementary components of an enterprise data ecosystem. While a knowledge graph provides an overall structure to an enterprise data domain, the taxonomy supplies a hierarchical structure to key lists and terms that are relevant to the business. Taxonomy Management Systems (TMS) are used to manage taxonomies and give organizations the structure and governance features needed to focus on taxonomy development. On the other hand, knowledge graphs are managed using a graph database and integrate additional types of information. The compatibility of taxonomies with knowledge graphs are often reflected in their similar data models. Many of the leading TMS products utilize graph databases as their backend. If a taxonomy is stored in RDF format in a graph database and the knowledge graph is also represented using RDF, the ETL process to integrate the two models is very simple. Some TMS products will even allow storing taxonomy data in a separate graph database, meaning a taxonomy and knowledge graph data could be stored alongside each other in the same storage solution. Even when taxonomies are not modeled using graph data models, the flexibility of the knowledge graph allows the taxonomy to be quickly integrated into its data model with some basic transformations.

The bottom line

Building a knowledge graph is the best next step for developing the structure and meaningfulness of your organization’s information management model. If there are opportunities to capture more complex ideas and business logic, as well as more intuitive ways to structure information than what a taxonomy provides, it is time to consider a knowledge graph that builds on the taxonomy and can power new use cases such as semantic search, recommendation engines, and AI. Once you’ve identified the need for a knowledge graph, look for any existing taxonomies or vocabularies to leverage in the design and implementation of the enterprise knowledge graph. Reach out to EK for help. With both strategic expertise and the in-house technical skills needed to design a taxonomy/ontology or implement a knowledge graph, we’d love to partner with you to tackle your unique use cases.

The post Why a Knowledge Graph is the Best Way to Upgrade Your Taxonomy appeared first on Enterprise Knowledge.

• Limited understanding of the business application and use cases to define a clear vision and strategy.
• Not knowing where to start, in terms of selecting the most relevant and cost-effective business use case(s) as well as supportive business or functional teams to support rapid validations.
• There are multiple initiatives across the organization that are not streamlined or optimized for the enterprise.
• Enterprise data and information is disparate, redundant, and not readily available for use.
• Lack of the required skill sets and training.

Our experience at Enterprise Knowledge demonstrates that most organizations are already either developing or leveraging some form of Artificial Intelligence (AI) capabilities to enhance their knowledge, data, and information management. Commonly, these capabilities fall under existing functions or titles within the organization, such as data science or engineering, business analytics, information management, or data operations. However, given the technological advancements and the increasing values of organizational knowledge and data in our work and the marketplace today, organizational leaders that treat their information and data as an asset and invest strategically to augment and optimize the same have already started reaping the benefits and having their staff focus on more value add tasks and contributing to complex analytical work to build the business. The most pragmatic approaches for developing a tailored strategy and roadmap toward AI begin by looking at existing capabilities and foundational strengths in your data and information management practices, such as metadata, taxonomies, ontologies, and knowledge graphs, as these will serve as foundational pillars for AI. Below, I share in detail a series of steps and successful approaches that will serve as key considerations for turning your information and data into foundational assets for the future of technology.

What is AI?

At EK, we see AI in the context of leveraging machines to imitate human behaviors and deliver organizational knowledge and information in real and actionable ways that closely align with the way we look for and process knowledge, data, and information.

What is a Knowledge Graph?

An Enterprise Knowledge Graph provides a representation of an organization’s knowledge, domain, and artifacts that is understood by both humans and machines. To this end, Knowledge Graphs serve as a foundational pillar for AI, and AI provides organizations with optimized solutions and approaches to achieve overarching business objectives, either through automation or through enhanced cognitive capabilities.

Getting Started…

Step 1: Identify Your Use Cases for Knowledge Graphs and AI?

As an enterprise considers undergoing critical transformations, it becomes evident that most of their efforts are usually competing for the same resources, priorities, and funds. Identifying a solid business case for knowledge graphs and AI efforts becomes the foundational starting point to gain support and buy-in. Effective business applications and use cases are those that are driven by strategic goals, have defined business value either for a particular function or cross-functional team, and make processes or services more efficient and intelligent for the enterprise. Prioritization and selection of use cases should be driven by the foundational value proposition of the use-case for future implementations, technical and infrastructure complexity, stakeholder interest, and availability to support implementation. The most relevant use cases for implementing knowledge graphs and AI include:

• Intuitive search using natural language;
• Discovering related content and information, structured or unstructured;
• Reliable content and data governance;
• Compliance and operational risk prediction; etc.

For more information regarding the business case for AI and knowledge graphs, you can download our whitepaper that outlines the real-world business problems that we are able to tackle more efficiently by using knowledge graph data models.

Once your most relevant business question(s) or use cases have been prioritized and selected, you are now ready to move into the selection and organization of relevant data or content sources that are pertinent to provide an answer or solution to the business case.

Step 2: Inventory and Organize Relevant Data

The majority of the content that organizations work with is unstructured in the form of emails, articles, text files, presentations, etc. Taxonomy, metadata, and data catalogs allow for effective classification and categorization of both structured and unstructured information for the purposes of findability and discoverability. Specifically, developing a business taxonomy provides structure to unstructured information and ensures that an organization can effectively capture, manage, and derive meaning from large amounts of content and information.

There are a few approaches for inventorying and organizing enterprise content and data. If you are faced with the challenging task of inventorying millions of content items, consider using tools to automate the process. A great starting place we recommend here would be to conduct user or Subject Matter Expert (SME) focused design sessions, coupled with bottom-up analysis of selected content, to determine which facets of content are important to your use case. Taxonomies and metadata that are the most intuitive and close to business process and culture tend to facilitate faster and more useful terms to structure your content. Organizing your content and data in such a way gives your organization the stepping stone towards having information in machine readable format, laying the foundation for semantic models, such as ontologies, to understand and use the organizations vocabulary, and start mapping relationships to add context and meaning to disparate data.

Step 3: Map Relationships Across Your Data

Ontologies leverage taxonomies and metadata to provide the knowledge for how relationships and connections are to be made between information and data components (entities) across multiple data sources. Ontology data models further enable us to map relationships in a single location at varying levels of detail and layers. This, in turn, sets the groundwork for more intelligent and efficient AI capabilities, such as text mining and identifying context-based recommendations. These relationship models further allow for:

• Increasing reuse of “hidden” and unknown information;
• Managing content more effectively;
• Optimizing search; and
• Creating relationships between disparate and distributed information items.

Tapping the power of ontologies to define the types of relationships and connections for your data provides the template to map your knowledge into your data and the blueprint needed to create a knowledge graph.

Step 4: Conduct a Proof of Concept – Add Knowledge to your Data Using a Graph Database

Because of their structure, knowledge graphs allow us to capture related data the way the human brain processes information through the lens of people, places, processes, and things. Knowledge graphs, backed by a graph database and a linked data store, provide the platform required for storing, reasoning, inferring, and using data with structure and context. This plays a fundamental role in providing the architecture and data models that enable machine learning (ML) and other AI capabilities such as making inferences to generate new insights and to drive more efficient and intelligent data and information management solutions.

Start small. Conduct a proof of concept or a rapid prototype in a test environment based on the use cases selected/prioritized and the dataset or content source selected. This will give you the flexibility needed to iteratively validate the ontology model against real data/content, fine tune for tagging of internal & external sources to enhance your knowledge graph, deliver a working proof of concept, and continue to demonstrate the benefits while showing progress quickly. Testing a knowledge graph model and a graph database within such a confined scope will enable your organization to gain perspective on value and complexity before investing big.

This approach will position you to adjust and incrementally add more use cases to reach a larger audience across functions. As you continue to enhance and expand your knowledge across your content and data, you are layering the flexibility to add on more advanced features and intuitive solutions such as semantic search including natural language processing (NLP), chatbots, and voice assistants getting your enterprise closer to a Google and Amazon-like experience.

Ready for AI? Automate, Optimize, and Scale.

Core AI features, such as ML, NLP, predictive analytics, inference, etc., lend themselves to robust information and data management capabilities. There is a mutual relationship between having quality content/data and AI. The cleaner and more optimized that our data, is the easier it is for AI to leverage that data and, in turn, help the organization get the most value out of it. Within the context of information and data management, AI provides the organization with the most efficient and intelligent business applications and values that include:

• Semantic search that provides flexible and faster access to your data through the ability to use natural language to query massive amounts of both unstructured and structured content. Leveraging auto-tagging, categorization, and clustering capabilities further enables continuous enhancement and governance of taxonomies/ontologies and knowledge graphs.
• Discover hidden facts and relationships based on patterns and inferences that allow for large scale analysis and identification of related topics and things.
• Optimize data management and governance through machine-trained workflows, data quality checks, security, and tracking.

Organizations that approach large initiatives toward AI with small (one or two) use cases, and iteratively prototype to make adjustments, tend to deliver value incrementally and continue to garner support throughout. The components that go into achieving this organizational maturity also require sustainable efficiency and show continuous value to scale. As your organization is looking to invest in a new and robust set of tools, the most fundamental evaluation question now becomes ensuring the tool will be able to make extensive use of AI.

If you are exploring pragmatic ways to benefit from knowledge graphs and AI within your organization, we can help you bring proven experience and tested approaches to realize and embrace their values.

The post How to Build a Knowledge Graph in Four Steps: The Roadmap From Metadata to AI appeared first on Enterprise Knowledge.