The Solution

EK architected and developed a Sales Enablement Proof of Concept (POC) built in a CCMS with a front end in React. This POC broke the content in slide decks down into topical components that could then be efficiently assembled into customized microsites by representatives in the field. These highly configurable microsites allowed sellers to efficiently customize their sales collateral for the needs of buyers.

For example, content about a research study might have components for Overview, Methods, Design, and Results. When a representative wanted to discuss just the general details of the study, they had the option to only include the study Overview component in their microsite, so as not to bog down their conversation with unnecessary details. The content in the Dynamic Content POC was also much more conducive to being used on the go, by being available in a URL instead of a .ppt file that required downloading, and by being searchable both using keywords or via the site navigation. These features made it much easier for sales representatives to fluidly navigate from topic to topic during their conversations with medical professionals, customizing their presentation on the fly to respond to the lead qualifying information. The content model also accounted for regulatory and compliance rules by creating relationships between content segments that must be shown together, or in a certain order. This way, representatives faced less of a burden to recall and adhere to compliance themselves, and could count on the content itself to be compliantly ordered. 

Finally, the POC made multimedia assets like images, graphs, and charts more findable by leveraging a specific content component for media assets. This way each asset could be tagged and described with metadata, rendering it searchable by keywords. This created a much simpler interface for representatives seeking to find a specific data point or image within many media assets. Ultimately multimedia handling requirements at the enterprise level would require a DAM, but EK was able to deliver satisfactory functionality appropriate to the POC within the CCMS.

The EK Difference

EK’s Advanced Content Team was able to provide the healthcare company with a dynamic, innovative Sales Enablement POC that solved for multiple challenges medical sales representatives were facing. EK combined industry leading content engineering expertise to redefine the shape and structure of content with user experience design best practices to ensure the solution was intuitive to navigate so that Sellers could easily and efficiently find customized Go To Market content and sales collateral. EK’s technical consultants were also able to develop an extensible POC over a short amount of time and with little risk, so that the healthcare company could quickly realize business value from their investment. Rapid delivery of working software also provided an efficient tool for testing and providing feedback on features and functionality.

The Results

As a result of the Sales Enablement POC, the healthcare company has been able to populate and build out a larger Dynamic Content repository that extends the content model and includes even more configurable sales collateral. The company will be able to mature their solution over time using the extensible content model and Sales Enablement POC that EK built. Medical sales representatives will ultimately be armed with an ever-expanding selection of easily personalizable content, resulting in improved sales conversion and win rates.

 

Download Flyer

 

The post Dynamic Content POC for Sales Enablement in Healthcare appeared first on Enterprise Knowledge.

A Quick Note on CSVs

CSV files, or comma-separated values files, are widely used to store tabular data. If your company uses spreadsheet applications, such as Microsoft Excel or Google Sheets, or relational databases, then it is likely you have encountered CSV files before. This post will help you use the already existent, CSV-formatted data throughout your company, transform it into a usable knowledge graph, and resurface relevant pieces of information to users in a CCMS. Although this example uses CSV files as the tabular dataset format, the same principles apply to Excel sheets and SQL tables alike.

Aggregating Data

The diagram below is a visual model of the knowledge graph we will create from data in our example CSV files.

In order to populate this graph, just as in Quinn’s blog, we will begin with three sets of data about:

• Customers and the products they own
• Products and the parts they are composed of
• Parts and the actions that need to be taken on them

This information is stored in three CSV files, Customer_Data.csv, Product_Data.csv and Part_Data.csv:

Customers

Products

Parts

To create a knowledge graph from these tables, we will need to

• Read the data tables from our CSV files into DataFrames (an object representing a 2-D data structure, such as a spreadsheet or table)
• Transform the DataFrames into RDF triples and add them to the graph

In order to accomplish these two tasks, we will be utilizing two Python libraries. Pandas, a data analysis and manipulation library, will help us serialize our CSV files into DataFrames and rdflib, a library for working with RDF data, will allow us to create RDF triples from the data in our DataFrames.

Reading CSV Data

This first task is quite easy to accomplish using pandas. Pandas has a read_csv method for ingesting CSV data into a DataFrame. For this use case, we only need to provide two parameters: the CSV’s file path and the number of rows to read. To read the Customers table from our Customer_Data.csv file:

import pandas as pd

customer_table = pd.read_csv("Customer_Data.csv", nrows=2)

The value of customer_table is:

       Customer ID      Customer Name     Owns Product
0                1      Stephen Smith        Product A
1                2            Lisa Lu        Product A

We repeat this process for the Products and Parts files, altering the filepath_or_buffer and nrows parameters to reflect the respective file’s location and table size.

Tabular to RDF

Now that we have our tabular data stored in DataFrame variables, we are going to use rdflib to create subject-predicate-object triples for each column/row entry in the three DataFrames. I would recommend reading Quinn’s blog prior to this one as I am following the methods and conventions that he explains in his post. 

Utilizing the Namespace module will provide us a shorthand for creating URIs, and the create_eg_uri method will url-encode our data values.

from rdflib import Namespace
from urllib.parse import quote

EG = Namespace("http://example.com/")

def create_eg_uri(name: str) -> URIRef:
    """Take a string and return a valid example.com URI"""
    quoted = quote(name.replace(" ", "_"))
    return EG[quoted]

The columns in our data tables will need to be mapped to predicates in our graph. For example, the Owns Product column in the Customers table will map to the http://example.com/owns predicate in our graph. We must define the column to predicate mappings for each of our tables before diving into the DataFrame transformations. Additionally, each mapping object contains a “uri” field which indicates the column to use when creating the unique identifier for an object.

customer_mapping = {
    "uri": "Customer Name",
    "Customer ID": create_eg_uri("customerId"),
    "Customer Name": create_eg_uri("customerName"),
    "Owns Product": create_eg_uri("owns"),
}

product_mapping = {

    "uri": "Product Name",
    "Product ID": create_eg_uri("productId"),
    "Product Name": create_eg_uri("productName"),
    "Composed of": create_eg_uri("isComposedOf"),
}

part_mapping = {

    "uri": "Part Name",
    "Part ID": create_eg_uri("partId"),
    "Part Name": create_eg_uri("partName"),
    "Action": create_eg_uri("needs"),
}

uri_objects = ["Owns Product", "Composed of", "Action"]

The uri_objects variable created above indicates which columns from the three data tables should have their values parsed as URI References, rather than Literals. For example, Composed of maps to a Part object. We want to make the <Part> object in the triple EG:Product_A EG:isComposedOf <Part> a URI pointing to/referencing a particular Part, not just the string name of the Part. Whereas the Product Name column creates triples such as EG:Product_A EG:productName “name” and “name” is simply a string, i.e. a Literal, and not a reference to another object.

Now, using all of the variables and methods declared above, we can begin the translation from DataFrame to RDF. For the purposes of this example, we create a global graph variable and a reusable translate_df_to_rdf function which we will call for each of the three DataFrames. With each call to the translate function, all triples for that particular table are added to the graph.

from rdflib import URIRef, Graph, Literal
import pandas as pd

graph = Graph()

def translate_df_to_rdf(customer_data, customer_mapping):
    # Counter variable representing current row in the table
    i = 0
    num_rows = len(customer_data.index)

    # For each row in the table
    while i < num_rows:
        # Create URI subject for triples in this row using ‘Name’ column
        name = customer_data.loc[i, customer_mapping["uri"]]
        row_uri = create_eg_uri(name)

        # For each column/predicate mapping in mapping dictionary
        for column_name, predicate in customer_mapping.items():

            # Grab the value at this specific row/column entry
            value = customer_data.loc[i, column_name]

            # Strip extra characters from value
            if isinstance(value, str):
                value = value.strip()

            # Check if the value exists
            if not pd.isnull((value)):
                # Determine if object should be a URI or Literal
                if column_name in uri_objects:
                    # Create URI object and add triple to graph
                    uri_value = create_eg_uri(value)
                    graph.add((row_uri, predicate, uri_value))
                else:
                    # Create Literal object and add triple to graph
                    graph.add((row_uri, predicate, Literal(value)))
        i = i + 1

Querying the Graph

In this case, we make three calls to translate_df_to_rdf:

translate_df_to_rdf(customer_data, customer_mapping)
translate_df_to_rdf(product_data, product_mapping)
translate_df_to_rdf(part_data, part_mapping)

Now that our graph is populated with the Customers, Products, and Parts data, we can query it for personalized content of our choosing. So, if we want to find all customers who own products that are composed of parts that need a recall, we can create and use the same query from Quinn’s previous blog:

sparql_query = """SELECT ?customer ?product
WHERE {
  ?customer eg:owns ?product .
  ?product eg:isComposedOf ?part .
  ?part eg:needs eg:Recall .
}"""

results = graph.query(sparql_query, initNs={"eg": EG})
for row in results:
    print(row)

As you would expect, the results printed in the console are two ?customer ?product pairings:

(rdflib.term.URIRef('http://example.com/Stephen_Smith'), rdflib.term.URIRef('http://example.com/Product_A'))
(rdflib.term.URIRef('http://example.com/Lisa_Lu'), rdflib.term.URIRef('http://example.com/Product_A'))

Summary

By transforming our CSV files into RDF triples, we created a centralized, connected graph of information, enabling the simple retrieval of very granular and case-specific data. In this case, we simply traversed the relationships in our graph between Customers, Products, Parts, and Actions to determine which Customers needed to be notified of a recall. In practice, these concepts can be expanded to meet any personalization needs for your organization.

Knowledge Graphs are an integral part of serving up targeted, useful information via a Componentized Content Management System, and your organization doesn’t need to start from scratch. CSVs and tabular data can easily be transformed into RDF and aggregated as the foundation for your organization’s Knowledge Graph. If you are interested in transforming your data into RDF and want help planning or implementing a transformation effort, contact us here.

The post Transforming Tabular Data into Personalized, Componentized Content using Knowledge Graphs in Python appeared first on Enterprise Knowledge.

To follow along, a basic understanding of Python programming is required.

Aggregating Data

Hilger’s article shows the following visualization of a knowledge graph to illustrate how the graph connects data from many different sources and encodes the relationship between them.

To show this system in action, we will start out with a few sets of data about:

• Customers and the products they own
• Products and the parts they are composed of
• Parts and the actions that need to be taken on them

In practice, this information would be pulled from the sales tracking, product support, and other systems it lives in via APIs or database queries, as described by Hilger.

customers_products = [
    {"customer": "Stephen Smith", "product": "Product A"},
    {"customer": "Lisa Lu", "product": "Product A"},
]

products_parts = [
    {"product": "Product A", "part": "Part X"},
    {"product": "Product A", "part": "Part Y"},
    {"product": "Product A", "part": "Part Z"},
]
parts_actions = [{"part": "Part Z", "action": "Recall"}]

We will enter this data into a graph as a series of subject-predicate-object triples, each of which represents a node (the subject) and its relationship (the predicate) to another node (the object). RDF graphs use uniform resource identifiers (URIs) to provide a unique identifier for both nodes and relationships, though an object can also be a literal value.

Unlike the traditional identifiers you may be used to in a relational database, URIs in RDF always use a URL format (meaning they begin with http://), although a URI is not required to point to an existing website. The base part of this URI is referred to as a namespace, and it’s common to use your organization’s domain as part of this. For this tutorial we will use http://example.com as our namespace.

We also need a way to represent these relationship predicates. For most enterprise RDF knowledge graphs, we start with an ontology, which is a data model that defines the types of things in our graph, their attributes, and the relationships between them. For this example, we will use the following relationships:

Note the use of camelCase in the name – for more best practices in ontology design, including how to incorporate open standard vocabularies like SKOS and OWL into your graph, see here.

The triple representing Stephen Smith’s ownership of Product A in rdflib would then look like this, using the URIRef class to encode each URI:

from rdflib import URIRef

triple = (
    URIRef("http://example.com/Stephen_Smith"),
    URIRef("http://example.com/owns"),
    URIRef("http://example.com/Product_A"),
)

Because typing out full URLs every time you want to add or reference a component of a graph can be cumbersome, most RDF-compliant tools and development resources provide some shorthand way to refer to these URIs. In rdflib that’s the Namespace module. Here we create our own namespace for example.com, and use it to more concisely create that triple:

from rdflib import Namespace

EG = Namespace("http://example.com/")

triple = (EG["Stephen_Smith"], EG["owns"], EG["Product_A"])

We can further simplify this process by defining a function to transform these strings into valid URIs using the quote function from the urlparse module:

from urllib.parse import quote

def create_eg_uri(name: str) -> URIRef:
    """Take a string and return a valid example.com URI"""
    quoted = quote(name.replace(" ", "_"))
    return EG[quoted]

Now, let’s create a new Graph object and add these relationships to it:

from rdflib import Graph

graph = Graph()

owns = create_eg_uri("owns")
for item in customers_products:
    customer = create_eg_uri(item["customer"])
    product = create_eg_uri(item["product"])
    graph.add((customer, owns, product))

is_composed_of = create_eg_uri("isComposedOf")
for item in products_parts:
    product = create_eg_uri(item["product"])
    part = create_eg_uri(item["part"])
    graph.add((product, is_composed_of, part))

needs = create_eg_uri("needs")
for item in parts_actions:
    part = create_eg_uri(item["part"])
    action = create_eg_uri(item["action"])
    graph.add((part, needs, action))

Querying the Graph

Now we are able to query the graph, in order to find all of the customers that own a product containing a part that requires a recall. To do this, we’ll construct a query in SPARQL, the query language for RDF graphs.

SPARQL has some features in common with SQL, but works quite differently. Instead of selecting from a table and joining others, we will describe a path through the graph based on the relationships each kind of node has to another:

sparql_query = """SELECT ?customer ?product
WHERE {
  ?customer eg:owns ?product .
  ?product eg:isComposedOf ?part .
  ?part eg:needs eg:Recall .
}"""

The WHERE clause asks for:

1. Any node that has an owns relationship to another – the subject is bound to the variable ?customer and the object to ?product
2. Any node that has an isComposedOf relationship to the ?product from the previous line, the subject of which is then bound to ?part
3. Any node where the object has a needs relationship to an object which is a Recall.

Note that we did not at any point tell the graph which of the URIs in our graph referred to a customer. By simply looking for any node that owns something, we were able to find the customers automatically. If we had a requirement to be more explicit about typing, we could add triples to our graph describing the type of each entity using the RDF type relationship, then refer to these in the query.

We can then execute this query against the graph, using the initNs argument to map the “eg:” prefixes in the query string to our example.com namespace, and print the results:

results = graph.query(sparql_query, initNs={"eg": EG})
 
for row in results:
    print(row)

This shows us the URIs for the affected customers and the products they own:

(rdflib.term.URIRef('http://example.com/Stephen_Smith'), rdflib.term.URIRef('http://example.com/Product_A'))
(rdflib.term.URIRef('http://example.com/Lisa_Lu'), rdflib.term.URIRef('http://example.com/Product_A'))

These fields could then be sent back to our componentized content management system, allowing it to send the appropriate recall messages to those customers!

Summary

The concepts and steps described in this post are generally applicable to setting up a knowledge graph in any environment, whether in-memory using Python or Java, or with a commercial graph database product. By breaking your organization’s content down into chunks inside a componentized content management system and using the graph to aggregate this data with your other systems, you can ensure that the exact content each customer needs to see gets delivered to them at the right time. You can also use your graph to create effective enterprise search systems, among many other applications.

Interested in best in class personalization using a CCMS plus a knowledge graph? Contact us.

The post Content Personalization with Knowledge Graphs in Python appeared first on Enterprise Knowledge.

Join the webinar “From Docs to Components” on January 27 from 3:00 PM – 4:00 PM EST to learn more about how to enable full flexibility for a tailored user experience.

Register for the event here: Online event registration | Drupal4Gov 

The post EK’s Ivanov and Taylor to Speak At Upcoming Webinar On Content Management: “From Docs to Components” appeared first on Enterprise Knowledge.

The Solution

EK collaborated with the financial provider to better leverage a componentized content management system (CCMS), enabling the organization to consistently model, create, and reuse content previously curated and authored by siloed business units. The “componentized” feature was critical to allow the organization to produce reusable product documentation segments. EK integrated an auto-tagging system to more accurately and efficiently apply consistent vocabularies to each of these segments so that the organization could assemble and reassemble content components, aligning them with customer profiles to create personalized customer experiences. Once product documentation content was more meaningfully structured and tagged with consistent vocabularies, EK developed a series of APIs to deliver the content for display in various omnichannel front-end delivery platforms and experiences.

Additionally, EK worked with organizational subject matter experts to design and implement a taxonomy that enables authors to associate content segments with financial topics, solutions, and user-facing views. These associations help drive the personalization of content for each user and organization. On top of the CCMS, EK architected and implemented a knowledge graph to store the content segments and their metadata for quick reference when building content and front-end views. Segments are stored separately and pulled together from the graph to create a seamless search and documentation experience for users.

The EK Difference

The EK team leveraged our experience with taxonomy design, content management, ontology design, knowledge graphs, and enterprise search to strategize and implement the CCMS solution for the organization. Our taxonomists and ontologists collaborated with the organization’s subject matter experts to capture and translate existing metadata and authoring processes into taxonomies and content models that could be leveraged by the CCMS and knowledge graph. Our technical expertise guided the organization to build a flexible, knowledge graph foundation that could be leveraged through a bespoke API layer to power their vision of content curation, delivery, and search through their user-facing platforms.

The Results

The combination of a CCMS platform and a knowledge graph allows for dynamic assembly of content components and data elements to produce a flexible, adaptive, and customized client experience for the financial solutions provider. The new solution connects clients to the content and data they need to perform their work in a vastly more efficient manner that saves time for both the financial solutions provider as well as their clients. The CCMS platform is providing the organization with the ability to create individual content segments, tag them with a consistent taxonomy, and produce personalized views for end-users. With personalized content and connected data, users are provided only the documentation relevant to the version and tier of service they have purchased. Additionally, we can ensure that product information is described with a consistent vocabulary across all documentation. This removes the previous need to comb through irrelevant and inconsistent information to find the relevant documentation. Leveraging a knowledge graph allows us to connect content with relevant data elements to produce richer and more detailed documentation.

Improving Product Documentation With a CCMS and a Knowledge GraphDownload

The post Improving Product Documentation With a CCMS and a Knowledge Graph appeared first on Enterprise Knowledge.

• Componentized Content Management Systems (CCMS) and 
• Knowledge Graphs (Graph).

A CCMS allows organizations to create and manage content so that people receive only the information they need. A Graph allows organizations to better target what information should be delivered. In the rest of this blog post, I am going to explain how these two tools work to provide the best possible content personalization experience. To keep things simple, I am going to refer to the receiver of this personalized information as a customer, although these concepts could easily apply to personalization for partners and employees as well.

Tool 1:  Bite-Sized Content Components

A CCMS supports the content side of the personalization equation. It allows organizations to author and manage content in components or sections rather than long documents. Componentized content is structured content that represents a portion of a larger document (typically a chapter or section) that can be combined to build documents dynamically. A great example of this is your car’s owners manual. This manual has instructions for changing a tire, filling the wiper fluid, and jump starting the car. Dividing the content of the owners manual into components allows the manufacturer to send only the jump starting instructions when that is what the customer needs.

Truly effective personalization requires this division of content so that the customer gets only the information they need and not extraneous information. Imagine you are a product manufacturer and you sell multiple products, many of which use the same or similar parts. As you interact with customers, it is important that the information that you provide to them is limited to products that they own or related products that would be of interest. A CCMS allows organizations to deliver individual components to directly answer questions or to dynamically assemble larger manuals that include only information relevant to the products the customer owns. This level of personalization reminds the customer that you understand who they are and that you value their time. A common phrase in Knowledge Management is “Deliver people the right information at the right time!”. A CCMS helps ensure that the right information can be delivered in a way that is specific and relevant to the user.

Tool 2:  Knowledge Graphs

Once the information is componentized the personalization platform needs a way to decide what information is the right information to share with the customer. This is where Knowledge Graphs provide a level of control over personalization that is new and much more powerful than prior technologies. Knowledge graphs deliver on personalization through two key features: aggregation and inference.

Graphs are very good at aggregating information from multiple sources. This is the use case that Google shows with their famous knowledge panels (the information about people, places, and things that show on the right side of the search results). A graph can pull information about customers from multiple sources such as the CRM system, product support tickets, and sales information. This aggregated view means that the graph can be used to determine which content chunks should be assembled together to best align with the purchases and concerns of the customer. The CCMS produces the chunked content and the graph assembles the “right” chunks of content and delivers them to the customer based on what the graph knows about the customer.

A graph can aggregate more than just information about a customer. Graphs are also used to aggregate information about the products and services of an organization. This information can come from the product information management system, the product catalog, and ticketing systems. With this information, the graph can look at the products a customer owns and the latest information about those products so that highly targeted and almost predictive information can be delivered to customers. For example, a customer may own a product that has had a recent recall. The CCMS stores information about how to get the recall and how to install the solution. The graph is able to proactively see that the customer owns this product from the customer portion of the graph and then identify that the product has a recall from the product portion of the graph. The organization can then send a highly personalized and targeted message that explains what the recall is and how to install the solution. This type of proactive personalization can turn a potentially negative situation into a more positive engagement. A simplified example of how the graph provides this information can be seen in the image below.

Additional personalization can be offered through a feature in graphs called inference. Inference occurs when two entities in the graph are seen as related because they have relationships in common. For example, two products that a company offers might use a part that lowers noise. A third product might use a different part, but one that also offers noise canceling features. Even though these products are not directly related we can infer that they are similar because the parts that they use have a similar characteristic (see the image below).

Inference allows organizations to personalize recommendations in a way that could not easily be done with older technologies. This opens a new path for personalization that allows for even more proactive content interactions with both customers and prospects.

Summary

Componentized Content Management Systems and Knowledge Graphs are foundational elements that are key to providing content personalization. Organizations that personalize customer, employee, and partner experiences with these tools can create compelling digital experiences that surprise and delight. Our content management and graph specialists can help your organization build a true cutting edge personalization platform. If you are interested in learning more about our services in this area, you can reach us at info@enterprise-knowledge.com.

The post Taking Content Personalization to the Next Level: Graphs and Componentized Content Management appeared first on Enterprise Knowledge.