Traditional Approach vs. Semantic Approach

There are two mainstream frameworks for developing a recommendation engine: traditional recommendation engines and semantic recommendation engines. It is important to select the right framework based on your use case, scale and availability of data, and internal resources.

Traditional recommender approaches involve leveraging user analytics to establish statistical associations between content and user interests. However, these approaches come with challenges such as the “cold start” problem, arising from a lack of historical user data when a recommender is initialized, making it challenging to provide accurate and tailored recommendations from the outset. Additionally, these approaches rely heavily on machine learning resources and subject matter expertise, further adding to the complexity and investment required in building and maintaining such systems.

In contrast, the semantic recommender approach focuses on constructing a finite-scale semantic model and leveraging its capabilities to recommend desired content. This approach has several advantages, including the ability to work with better scoped data sets and to utilize an organization’s existing taxonomies and metadata as contextual information for machine learning algorithms. With less emphasis on machine learning expertise and a faster development time, the semantic recommender approach provides a practical and efficient solution to building recommenders that meet immediate business needs.

Establishing a Semantic Recommendation Engine

When using a semantic approach, the process of building the recommendation engine should be specifically tailored to capitalize on the advantages of these solutions. EK has been successful using the following 5 iterative steps to launch production grade semantic recommendation engines and applications to help businesses make targeted recommendations and improve their content personalization journey.

1. Define the Use Cases

When building a semantic recommendation engine, clearly defining the use cases is crucial for successful implementation. This involves identifying the corresponding personas, problem statement, and the necessary inputs and outputs. To initiate recommendations, the system requires trigger inputs, typically consisting of 1-3 user-provided inputs that serve as the basis for generating recommendations. Having known information about the trigger inputs provides a starting place and can facilitate the recommendation process by narrowing down the scope and improving the relevance of the suggestions. 

For example, one of our healthcare provider clients had a semantic recommendation engine use case for enabling clinicians to search for content related to illnesses based on patient information, so that they can pass on that content to patients and assist them in treatment and recovery. The inputs in this case would be the patient information and diagnosis, and the outputs would be content related to those inputs.

The main output of the recommendation engine should provide the minimum information required for users to understand what the recommender offers and to make an informed decision based on the presented information. Alongside the main output, having known information about the recommendations can provide additional context and details to enhance the user experience or help to validate the results. By carefully defining the use case and considering these elements, businesses will effectively plan to generate meaningful and relevant recommendations for users.

2. Create Supporting Data Models

Once the use case has been defined, the next step in building a semantic recommendation engine is to create supporting data models, including taxonomies and ontologies. Taxonomies establish hierarchical structures and relationships between various content items, enabling efficient content classification based on shared characteristics. On the other hand, ontologies define the complex relationships and dependencies between different entities, attributes, and concepts, fostering a deeper understanding of the data. By leveraging these relationship-based structures, the semantic recommendation engine can provide more contextually relevant and personalized suggestions.

To effectively design ontologies and supporting taxonomies for the selected use case, an iterative approach is crucial. This involves strategically designing the models to capture the shared characteristics between different content types. During the design process, the models are refined to ensure accurate representation of the relationships and connections between different data elements. Shared metadata can then be incorporated into the ontologies, enriching the content with valuable context and enabling the engine to make more informed recommendations based on those shared metadata. In our healthcare provider example, shared metadata such as content type, content keywords, publication date, and author information could be used to provide context to medical content and improve the relevancy of content recommendations. 

3. Construct the Graph

After creating the supporting data models, the next step in building a semantic recommendation engine is to construct the graph. The graph acts as a database of nodes and connections between nodes (called edges) that houses all of the content relationships defined in the ontology model.

Building the graph involves both ingesting and enriching source data. Ingestion maps raw data to nodes and edges in the graph. Enrichment appends additional attributes, tags, and metadata to enhance the data. This enriched data is then be transformed into semantic triples, which are subject-predicate-object structures that capture relationships. In our example, the healthcare provider could transform their enriched data into triples that capture the relationships between diagnoses and medical subjects, and medical subjects and content. 

Converting data into a web of semantic triples and loading it into the graph enables efficient querying. The knowledge graph’s flexibility also enables continuous integration of new data to keep recommendations relevant. This means the healthcare provider can query their graph to find medical content that relates to specific diagnoses, and they can continue to add content to their graph database without affecting the existing content, or changing the schema by which they have to run queries.

4. Define and Apply Recommendation Logic

Once the graph is constructed, the next step in building a semantic recommendation engine is to define and apply the logic for generating recommendations. This involves selecting an appropriate approach – either deterministic or statistical – and implementing the corresponding recommendation logic. 

In the deterministic approach, various techniques such as path finding, matching, and scoring logic are used to leverage the metadata embedded within the graph to generate recommendations. An example of this approach is content-based recommendation, where recommendations are generated based on the similarity of content attributes. 

On the other hand, the statistical approach utilizes graph neural networks or classifiers. These models leverage the power of graph-based machine learning algorithms to determine the probability of matches through weighting algorithms. An example of this approach is link prediction recommendation, where the likelihood of connections between items is predicted based on their graph structure. 

By defining and implementing the appropriate logic, the semantic recommendation engine can effectively generate recommendations that align with user preferences and maximize their relevance and utility. Our example healthcare provider may choose a deterministic recommendation approach if they decide they want to provide the content recommendations based on how similar content metadata is to the clinician-provided inputs.

5. Integrate with Enterprise Systems/Applications

Integration with enterprise systems enables users to interact with the graph through various channels such as a custom web application, an analytics tool, or a machine learning pipeline, through use cases including semantic search and chatbots. By integrating the semantic recommendation engine into enterprise systems, businesses can scale existing data models to multiple use cases and provide users with enhanced experiences, facilitate knowledge discovery, and promote streamlined knowledge management processes.

For example, the healthcare provider is able to integrate the recommendation engine on the backend with their internal database of content and on the frontend with their clinician portal to let clinicians search for and receive content recommendations in their browser, without having to manually look through their database.

Conclusion

Ultimately, semantic recommendation engines have emerged as essential tools in the digital era, offering personalized content discovery and driving user engagement. Leveraging relationship-based data models, these engines provide contextual suggestions without relying on large volumes of usage data.

To implement an impactful semantic recommendation engine with these 5 steps, key factors include:

• Building the case for the importance of graph-based recommendations
• Acquiring the necessary tooling and architecture
• Establishing and training key roles like data engineers, semantic engineers, and architects

By considering these elements, businesses can efficiently build semantic recommenders that empower them to reap the benefits in navigating today’s data-saturated landscape. 

Does your organization need support building your recommender toolkit for success? Contact us at info@enterprise-knowledge.com.

The post 5 Steps For Building Your Enterprise Semantic Recommendation Engine appeared first on Enterprise Knowledge.

But let’s back up…before we talk about RDF*, let’s cover the basics — what is RDF, and how is RDF* different from RDF?

What is RDF?

The Resource Description Framework (RDF) is a semantic web standard used to describe and model information for web resources or knowledge management systems. RDF consists of “triples,” or statements, with a subject, predicate, and object that resemble an English sentence. 

For example, take the English sentence: “Bess Schrader is employed by Enterprise Knowledge.” This sentence has:

• A subject: Bess Schrader
• A predicate: is employed by 
• An object: Enterprise Knowledge

Bess Schrader and Enterprise Knowledge are two entities that are linked by the relationship is employed by. An RDF triple representing this information would look like this:

(There are many ways, or serializations, to represent RDF. In this blog, I’ll be using the Turtle syntax because it’s easy to read, but this information could also be shown in RDF/XML, JSON for Linking Data, and other formats.)

The World Wide Web Consortium (W3C) maintains the RDF Specification, making it easy for applications and organizations to develop RDF data in an interoperable way. This means if you create RDF data in one tool and share it with someone else using a different RDF tool, they will still be able to easily use your data. This interoperability allows you to build on what’s already been done — you can combine your enterprise knowledge graph with established, open RDF datasets like Wikidata, jump starting your analytic capabilities. This also makes data sharing and migration between internal RDF systems simple, enabling you to unify data and reducing your dependency on a single tool or vendor.

For more information on RDF and how it can be used, check out Why a Taxonomist Should Know SPARQL.

What are the limitations of RDF (Why is RDF* necessary)?

Standard RDF has many strengths:

• Like most graph models, it more intuitively captures the way we think about the world as humans (as networks, not as tables), making it easier to design, capture, and query data.
• As a standard supported by the W3C, it allows us to create interoperable data and systems, all using the same standard to represent and encode data.

However, it has one key weakness: because RDF is based on triples, standard RDF can only connect two objects at a time. For many use cases, this limitation isn’t a problem. Consider my example from above, where I want to represent the relationship between me and my employer:

Simple! However, what if I want to capture the role or position that I hold at this organization? I could add a triple denoting my position:

Great! But what if I decide to add in my (fictional) employment history?

Now it’s unclear whether I was a consultant at Enterprise Knowledge or at Hogwarts. 

There are a variety of ways to address this problem in RDF. One of the most popular is reification or n-ary relations, in which you create an intermediary node that allows you to group more than two entities together. For example:

Using this technique allows you to clear up confusion and model the complexity of the world. However, adding these intermediary nodes takes away some of the simplicity of graph data — the idea of an “employment event” isn’t exactly intuitive.

There are many other methods that have been developed to handle this kind of complexity in RDF, including singleton properties and named graphs/quads. Additionally, an entirely different type of non-RDF graph model, labeled property graphs, allows users to attach properties directly to relationships. However, labeled property graphs don’t allow for interoperability at the same scale as RDF — it’s much harder to share and combine different data sets, and moving data from tool to tool isn’t as simple.

None of these solutions retain both of the strengths of RDF: the interoperable standards and the intuitive data model. This crucial limitation of RDF has limited its effectiveness in certain applications, particularly those involving temporal or transactional data.

What is RDF*?

RDF* (pronounced RDF-star) is an extension to RDF that proposes a solution to the weaknesses of RDF mentioned above. As an extension, RDF* supplements RDF but doesn’t replace it. 

The main idea behind RDF* is to treat a triple as a single entity. By “nesting” or “embedding” triples, an entire triple can become the subject of a second triple. This allows you to add metadata to triples, assigning attributes to a triple, or creating relationships not just between two entities in your knowledge graph, but between triples and entities, or triples and triples. Take our example from above. In standard RDF, if I want to express past employers and positions, I need to use reification: 

In RDF*, I can use nested triples to simply denote the same information:

This eliminates the need for intermediary entities and makes the model easier to understand and implement. 

Just as standard RDF can be queried via the SPARQL query language, RDF* can be queried using SPARQL*, allowing users to query both standard and nested triples.

Currently, RDF* is under consideration by the W3C and has not yet been officially accepted as a standard. However, the specification has been formally defined in Foundations of an Alternative Approach to Reification in RDF, and many enterprise tools supporting RDF have added support for RDF* (including BlazeGraph, AnzoGraph, Stardog, and GraphDB ). Hopefully this standard will be formally adopted by the W3C, allowing it to retain and build on the original strengths of RDF: its intuitive model/simplicity and interoperability.

What are the benefits of RDF*?

As you can see above, RDF* can be used to represent relationships that involve more than one entity (e.g. person, role, and organization) in a more intuitive manner than standard RDF. However, RDF* has additional use cases, including:

• Adding metadata to a relationship (For example: start dates and end dates for jobs, marriages, events, etc.)

• Adding provenance information for triples: I have a triple that indicates Bess Schrader works for Enterprise Knowledge. When did I add this triple to my graph? What was the source of this information? Who added the information to the graph?

Conclusion

On its own, RDF provides an excellent way to create, combine, and share semantic information. Extending this framework with RDF* gives knowledge engineers more flexibility to model complex interactions between multiple entities, attach attributes to relationships, and store metadata about triples, helping us more accurately model the real world while improving our ability to understand and verify where data origins. 

Looking for more information on RDF* and how you can leverage it to solve your data challenges? Contact Enterprise Knowledge.

The post RDF*: What is it and Why do I Need it? appeared first on Enterprise Knowledge.

With our focus and expertise in knowledge, data, and information management, Enterprise Knowledge (EK) developed this proprietary Enterprise Artificial Intelligence (AI) Readiness Assessment in order to enable organizations to understand where they are and where they need to be in order to begin leveraging today’s technologies and AI capabilities for knowledge and data management. 

Based on our experience conducting strategic assessments as well as designing and implementing Enterprise AI solutions, we have identified four key factors as the most common indicators and foundations for many organizations in order to evaluate their current capabilities and understand what it takes to invest in advanced capabilities. 

This assessment leverages over thirty measurements across these four Enterprise AI Maturity factors as categorized under the following aspects. 

1. Organizational Readiness

The foundational requirement for any organization to undergo an Enterprise AI transformation stems from alignment on vision and the business applications and justifications for launching successful initiatives. The Organizational Readiness Factor includes the assessment of appropriate organizational designs, leadership willingness, and mandates that are necessary for success. This factor evaluates topics including:

• The need for vision and strategy for AI and its clear application across the organization.
• If AI is a strategic priority with leadership support.
• If the scope of AI is clearly defined with measurable success criteria.
• If there is a sense of urgency to implement AI.

With a clear picture of what your organizational needs are, your Organizational Readiness assessment factor will allow you to determine if your organization meets the requirements to consider AI related initiatives while surfacing and preparing you for potential risks to better mitigate failure.

2. The State of Organizational Data and Content

The volume and dynamism of data and content (structured and/or unstructured) is growing exponentially, and organizations need to be able to securely manage and integrate that information. Enterprise AI requires quality of, and access to, this information. This assessment factor focuses on the extent to which existing structured and unstructured data is in a machine consumable format and the level to which it supports business operations within the enterprise. This factor consider topics including:

• The extent to which the organization’s information ecosystems allow for quick access to data from multiple sources.
• The scope of organizational content that is structured and in a machine-readable format.
• The state of standardized organization of content/data such as business taxonomy and metadata schemes and if it is accurately applied to content.
• The existence of metadata for unstructured content. 
• Access considerations including compliance or technical barriers.

AI needs to learn the human way of thinking and how an organization operates in order to provide the right solutions. Understanding the full state of your current data and content will enable you to focus on the right content/data with the highest business impact and help you develop a strategy to get your data in an organized and accessible format. Without high quality, well organized and tagged data, AI applications will not deliver high-value results for your organization.

3. Skills Sets and Technical Capabilities

With the increased focus on AI, the demand for individuals who have the technical skills to engineer advanced machine learning and intelligent solutions, as well as business knowledge experts who can transform data to a paradigm that aligns with how users and customers communicate knowledge, have both increased. Further, over the years, cloud computing capabilities, web standards, open source training models, and linked open data for a number of industries have emerged to help organizations craft customized Enterprise AI solutions for their business. This means an organization that is looking to start leveraging AI for their business no longer has to start from scratch. This assessment factor evaluates the organization’s existing capabilities to design, management, operate, and maintain an Enterprise AI Solution. Some of the factors we consider include:

• The state of existing enterprise ontology solutions and enterprise knowledge graph capabilities that optimize information aggregation and governance. 
• The existence of auto-classification and automation tools within the organization.
• Whether roles and skill sets for advanced data modeling or knowledge engineering are present within the organization.
• The availability and capacity to commit business and technical SMEs for AI efforts.

Understanding the current gaps and weaknesses in existing capabilities and defining your targets are crucial elements to developing a practical AI Roadmap. This factor also plays a foundational role in giving your organization the key considerations to ensure AI efforts kick off on the right track, such as leveraging web standards that enable interoperability, and starting with available existing/open-source semantic models and ecosystems to avoid short-term delays while establishing long-term governance and strategy. 

4. Change Threshold 

The success of Enterprise AI relies heavily on the adoption of new technologies and ways of doing business. Organizations who fail to succeed with AI often struggle to understand the full scope of the change that AI will bring to their business and organizational norms. This usually manifests itself in the form of fear (either of change in job roles or creating wrong or unethical AI results that expose the organization to higher risks). Most organizations also struggle with the understanding that AI requires a few iterations to get it “right”. As such, this assessment factor focuses on the organization’s appetite, willingness, and threshold to understand and tackle the cultural, technical, and business challenges in order to achieve the full benefits of AI. This factor evaluates topics including:

• Business and IT interest and desire for AI.
• Existence of resource planning for the individuals whose roles will be impacted. 
• Education and clear communication to facilitate adoption. 

The success of any technical solution is highly dependent on the human and culture factor in an organization and each organization has a threshold for dealing with change. Understanding and planning for this factor will enable your organization to integrate change management that addresses the negative implications, avoids unnecessary resistance or weak AI results, and provides the proper navigation through issues that arise.

How it Works

This Enterprise AI readiness assessment and benchmarking leverages the four factors that have over 30 different points upon which each organization can be evaluated and scored. We apply this proprietary maturity model to help assess your Enterprise AI readiness and clearly define success criteria for your target AI initiatives. Our steps include: 

• Knowledge Gathering and Current State Assessment: We leverage a hybrid model that includes interviews and focus groups, supported by content/data and technology analysis to understand where you are and where you need to be.This gives us a complete understanding of your current strengths and weaknesses across the four factors, allowing us to provide the right recommendations and guidance to drive success, business value, and long-term adoption.
• Strategy Development and Roadmapping: Building on the established focus on the assessment factors, we work with you to develop a strategy and roadmap that outlines the necessary work streams and activities needed to achieve your AI goals. It combines our understanding of your organization with proven best practices and methodologies into an iterative work plan that ensures you can achieve the target state while quickly and consistently showing interim business value.
• Business Case Development and Alignment Support: we further compile our assessment of potential project ROI based on increased revenues, cost avoidance, risk and compliance management. We then balance those against the perceived business needs and wants by determining the areas that would have the biggest business impact with lowest costs. We further focus our discussions and explorations on these areas with the greatest need and higher interest.

Keys to Our Assessment  

Over the past several years, we have worked with diverse organizations to enable them to strategize, design, pilot, and implement scaled Enterprise AI solutions. What makes our priority assessment unique is that it is developed based on years of real-world experience supporting organizations in their knowledge and data management. As such, our assessment offers the following key differentiators and values for the enterprise: 

• Recognition of Unique Organizational Factors: This assessment recognizes that no Enterprise AI initiative is exactly the same. It is designed in such a way that it recognizes the unique aspects of every organization, including priorities and challenges to then help develop a tailored strategy to address those unique needs.
• Emphasis on Business Outcomes: Successful AI efforts result in tangible business applications and outcomes. Every assessment factor is tied to specific business outcomes with corresponding steps on how the organization can use it to better achieve practical business impact.
• A Tangible Communication and Education Tool: Because this assessment provides measurable scores and over 30 tangible criteria for assessment and success factors, it serves as an effective tool to allow your organization to communicate up to leadership and quickly garner leadership buy-in, helping organizations understand the cost and the tangible value for AI efforts. 

Results

As a result of this effort, you will have a complete view of your AI readiness, gaps and required ecosystem and an accompanying understanding of the potential business value that could be realized once the target state is achieved. Taken as a whole, the assessment allows an organization to:

• Understand strengths and weaknesses, and overall readiness to move forward with Enterprise AI compared to other organizations and the industry as a whole;
• Judge where foundational gaps may exist in the organization in order to improve Enterprise AI readiness and likelihood of success; and
• Identify and prioritize next steps in order to make immediate progress based on the organization’s current state and defined goals for AI and Machine Learning.

The post Enterprise AI Readiness Assessment appeared first on Enterprise Knowledge.

In this blog, I’ll walk you through both ontologies and knowledge graphs, describing how they’re different and how they work together to organize large amounts of data and information. 

What is an ontology?

Ontologies are semantic data models that define the types of things that exist in our domain and the properties that can be used to describe them. Ontologies are generalized data models, meaning that they only model general types of things that share certain properties, but don’t include information about specific individuals in our domain. For example, instead of describing your dog, Spot, and all of his individual characteristics, an ontology should focus on the general concept of dogs, trying to capture characteristics that most/many dogs might have. Doing this allows us to reuse the ontology to describe additional dogs in the future.

There are three main components to an ontology, which are usually described as follows:

• Classes: the distinct types of things that exist in our data.
• Relationships: properties that connect two classes.
• Attributes: properties that describe an individual class. 

For example, imagine we have the following information on books, authors, and publishers:

First we want to identify our classes (the unique types of things that are in the data). This sample data appears to capture information about books, so that’s a good candidate for a class. Specifically, the sample data captures certain types of things about books, such as authors and publishers. Digging a little deeper, we can see our data also captures information about publishers and authors, such as their locations. This leaves us with four classes for this example:

• Books
• Authors
• Publishers
• Locations

Next, we need to identify relationships and attributes (for simplicity, we can consider both relationships and attributes as properties). Using the classes that we identified above, we can look at the data and start to list all of the properties we see for each class. For example, looking at the book class, some properties might be:

• Books have authors
• Books have publishers
• Books are published on a date
• Books are followed by sequels (other books)

Some of these properties are relationships that connect two of our classes. For example, the property “books have authors” is a relationship that connects our book class and our author class. Other properties, such as “books are published on a date,” are attributes, describing only one class, instead of connecting two classes together. 

It’s important to note that these properties might apply to any given book, but they don’t necessarily have to apply to every book. For example, many books don’t have sequels. That’s fine in our ontology, because we just want to make sure we capture possible properties that could apply to many, but not necessarily all, books. 

While the above list of properties is easy to read, it can be helpful to rewrite these properties to more clearly identify our classes and properties. For example, “books have authors” can be written as:

Book → has author → Author 

Although there are many more properties that you could include, depending on your use case, for this blog, I’ve identified the following properties:

• Book → has author → Author
• Book → has publisher→ Publisher
• Book → published on → Publication date
• Book → is followed by → Book
• Author → works with → Publisher
• Publisher → located in → Location 
• Location → located in → Location

Remember that our ontology is a general data model, meaning that we don’t want to include information about specific books in our ontology. Instead, we want to create a reusable framework we could use to describe additional books in the future.

When we combine our classes and relationships, we can view our ontology in a graph format:

What is a knowledge graph?

Using our ontology as a framework, we can add in real data about individual books, authors, publishers, and locations to create a knowledge graph. With the information in our tables above, as well as our ontology, we can create specific instances of each of our ontological relationships. For example, if we have the relationship Book → has author → Author in our ontology, an individual instance of this relationship looks like:

If we add in all of the individual information that we have about one of our books, To Kill a Mockingbird, we can start to see the beginnings of our knowledge graph:

If we do this with all of our data, we will eventually wind up with a graph that has our data encoded using our ontology. Using this knowledge graph, we can view our data as a web of relationships, instead of as separate tables, drawing new connections between data points that we would otherwise be unable to understand. Specifically, using SPARQL, we can query this data, using inferencing, letting our knowledge graph make connections for us that weren’t previously defined. 

So how are ontologies and knowledge graphs different?

As you can see from the example above, a knowledge graph is created when you apply an ontology (our data model) to a set of individual data points (our book, author, and publisher data). In other words:

ontology + data = knowledge graph

Ready to get started? Check our ontology design and knowledge graph design best practices, and contact us if you need help beginning your journey with advanced semantic data models. 

The post What’s the Difference Between an Ontology and a Knowledge Graph? appeared first on Enterprise Knowledge.

An Enterprise Knowledge Graph allows organizations to connect and show meaningful relationships between data regardless of type, format, size, or where it is located. This allows us to view and analyze an organization’s knowledge and data assets in a format that is understood by both humans and machines.

While most organizations have been built to organize and manage data by department and type, a Knowledge Graph allows us to view and connect data the way our brain relates and infers information to answer specific business questions, without making another copy of the data from its original sources.

How much of your data and information is currently dispersed across business units, departments, systems, and knowledge domains? How many clicks or reports do you currently navigate to find an answer to a single business problem or get relevant results to your search? Below, I will share a selection of real business problems that we are able to tackle more efficiently by using knowledge graph data models, as well as examples of how we have used knowledge graphs to better serve our clients.

Aggregate Disparate Data in Order to Spot Trends and Make Better Investment Decisions

A vast amount of the data we create and work with is unstructured, in the form of emails, webpages, video files, financial reports, images, etc. Our own wide assessment of organizations finds that as much as 85% of an organization’s information exists in an unstructured form.  Organizing all of these data proves to be a necessary undertaking for many large and small institutions in order to extract meaning and value from their organization’s information. One way we have found to make this manageable is through leveraging semantic models and technologies to automatically extract and classify unstructured text to make it machine readable/processable. This allows us to further relate this classified content with other data sources to be able to define relationships, understand patterns, and quickly obtain holistic insights on a given topic from varied sources, despite where the data and content lives (business units, departments, systems, and locations).

One of the largest supply chain clients we work with needed to provide its business users a way to obtain quick answers based on very large and varied data sets. The goal was to bring meaningful information and facts closer to the business to make funding and investment decisions. By extracting topics, places, people, etc. from a given file, we were able to develop  an ontology to describe the key types of things business users were interested in and how they relate to each other. We mapped the various data sets to the ontology and leveraged semantic Natural Language Processing (NLP) capabilities to recognize user intent, link concepts, and dynamically generate the data queries that provide the response. This enabled non-technical users to uncover the answers to critical business questions such as:

• Which of your products or services are most profitable and perform better?
• What investments are successful, and when are they successful?
• How much of a given product did we deliver in a given timeframe?
• Who were my most profitable customers last year?
• How can we align products and services with the right experts, locations, delivery method, and timing?

Discover Hidden Facts in Data to Predict and Reduce Operational Risks

By allowing organizations to collect, integrate, and identify user interest and intent, ontologies and knowledge graphs build the foundations for Artificial Intelligence (AI) to allow organizations to analyze different paths jointly, describe their connectivity from various angles, and discover hidden facts and relationships through inferences in related content that would have otherwise gone unnoticed.

What this means for our large engineering and manufacturing partner is that, by connecting internal data to analyze relationships and further mining external data sources (e.g. social media, news, help-desk, forums, etc.), they were able to gain a holistic view of products and services to influence operational decisions. Examples include the ability to:

• Predict breakdown and detect service failures in early stages to schedule preventive maintenance, minimize downtime or maximize service life;
• Maintain right level of operator, experts and inventory;
• Find remaining life of an asset or determine right warranty period; and
• Prevent risk of negative brand image and impacts to lifetime loyalty of customers.

Facilitate Employee Engagement, Knowledge Discovery, and Retention

Most organizations have accumulated vast amounts of structured and unstructured data that are not easy to share, use, or reuse among staff. This difficulty leads to diminished retention of  institutional knowledge and rework. Our work with a global development bank, for instance, was driven by the need to find a better way to disseminate information and expertise to all of their staff so that projects would be more efficient and successful and employees would have a simple knowledge sharing tool to solve complex project challenges without rework and knowledge loss. We developed a semantic hub, leveraging a knowledge graph, that collects organizational content, user context, and project activities. This information then powers a recommendation engine that suggests relevant articles and information when an email or a calendar invite is sent on a given topic or during searches on that topic. This will eventually power a chatbot as part of a larger AI Strategy. These outputs were then published on the bank’s website to help improve knowledge retention and to showcase  expertise via Google recognition and search optimization for future reference. Using knowledge graphs based on this linked data strategy enables the organization to connect all of their knowledge assets in a meaningful way to:

• Increase the relevancy and personalization of search;
• Enable employees to discover content across unstructured content types, such as webinars, classes, or other learning materials based on factors like location, interest, role, seniority level, etc.; and
• Further facilitate connections between people who share similar interests, expertise, or location.

Implement Scalable Data Management and Governance Models

The size, variety, and complexity by which businesses are integrating data is making it difficult for IT and data management teams to keep up with a traditional data management structure. Currently, most organizations are facing challenges to efficiently and properly map ownership and usage of various data sources, to track changes, and to determine the right level of access and security. For example, we worked with a large US Federal Agency that needed a better way to manage the thousands of data sets that they use to develop economic models that drive US policy. We developed a semantic data model that captures data sets, metadata, how they relate to one another, and information about how they are used. This information is stored in a triple store that sits behind a custom web application. Through this ontology, a front-end semantic search application, and an administrative dashboard, the model provided Economists and the Agency:

• A single unified data view that clearly represents the knowledge domains of the organization without copying or duplicating data from the authoritative and managed sources;
• A machine-processable metadata from documents, images, and other unstructured content as well as from relational databases, data lakes, and NoSQL sources to see relationships across data sets; and
• An automated log of usage so that the Agency can better evaluate the internal value of a data set which then allows it to better negotiate deals with data vendors.

Lay the Foundations for AI Strategy

Considered to be the primary catalyst for what is now being termed the 4th industrial revolution, Artificial Intelligence (AI) is expected to drive half of our world’s economic gains within a decade. Where KM and AI meet, we discuss Knowledge Artificial Intelligence, a key element of this forthcoming revolution. For organizations looking to dabble in a pragmatic and scalable AI strategy, their enterprise needs to have a solid data practice that lays down the infrastructure necessary to sow and reap the advantages of data across disparate sources, as well as drive scale and efficient governance through graph-based machine learning.

The key approach that the business problems above share is that the knowledge graph modeling is enabling the application of some form of AI to transform the productivity and growth of these organizations with“hard” and “soft” business returns. These range from improvements to processes through staff augmentation and task automation, employee and customer satisfaction through personalized sales and marketing, risk avoidance through anomaly detection and predictive analytics, and facilitating staff intelligence through the enablement of natural ways to ask the toughest business questions.

Closing

Data lakes and data warehouses have gotten us this far by allowing organizations to integrate and analyze large data to drive business decisions, but the practicality of data consolidation will always be a limiting factor for the enterprise implementation of these technologies. As business agility and high volumes of data are becoming the ingredients for success, the need for speed, exploration, scalability, and optimization of data is becoming an undertaking that traditional and relational data models are struggling to keep up.

Backed by operational convenience, semantic data models provide organizations the power to synthesize real-time decisions, make relevant recommendations and facilitate knowledge sharing with limited administrative burden and a proven potential for scale. What further sets graph models apart is that they rely on context from human knowledge, structure, and reasoning that are necessary to relate knowledge to language in a natural way. Graph data models are able to leverage machine learning to apply this knowledge by collecting and automatically classifying  knowledge from various sources into machine readable formats, and allowing the organization to benefit from the deeper layers of AI, such as natural language processing, image recognition, predictive analytics, and so much more.

If your organization, like many, is facing challenges in surfacing, exploring, and managing data in an understandable and actionable manner, learn more on ways to get started or contact us directly.

The post Using Knowledge Graph Data Models to Solve Real Business Problems appeared first on Enterprise Knowledge.