Our experimental initiative to prototype a bot-ready information solution using Google’s Dialogflow
This post is part of a series. For more information and links to other posts in the series, see the “Building bot-ready knowledge bases” home page.
Our original DITA-based knowledge package
We provided an overview of our DITA-based grocery shopping project in “Building bot-ready knowledge bases” post #2. Here is some additional information about that project.
“Back in the day” (about 2008), when we were actively working on DITA/XML projects, we typically published knowledge bases as both linked HTML sets and also as single or multiple PDF files. The PDF version of grocery shopping was originally processed using a single DITA map that linked the seven DITA source files and published them as a single “mini-book.” The “book” featured:
- Metadata containing a topic overview (short descriptions) and administrative information about authoring and publishing
- Metadata containing keywords and indexterms
- Relationship tables linking the three produce files and the three canned goods files to one another.
- A two-level index



Without additional programming, which we had decided to forgo, these organizational and usability features would be lost in a transformation to GROCERYbot.
At this point in the project we crossed our fingers and hoped that we could re-create some of the DITA-based features using Dialogflow, and that the efficiency and general “coolness” of the chatbot production environment would make up for the rest.
Our GROCERYbot knowledge package
Initial Dialogflow Knowledge component
Dialogflow Knowledge documents can be in various formats: FAQs as HTML or CSV, and extractive question answering in text or PDF.
We were aware that connecting our DITA topics would NOT be appropriate, so we processed them with oXygen as separate PDF files.
For good measure, we added to our original grocery shopping knowledge base a set of questions and answers related to our grocery shopping domain. These FAQs were in CSV format.

In the beginning we put these eight files (seven DITA-based topics and the CSV-based FAQs) into a single Dialogflow Knowledge connector document.
We weren’t happy with our initial results and we decided to make some changes.
Revised Dialogflow Knowledge component
In the revised version of our Ditaflow Knowledge component we separated out our eight files so they could perform independently in the chatbot environment.

Note the slider bar at the bottom of the image above, which controls how strongly we prefer Knowledge results. We have it set at -0.5 at the moment, and it can be moved around in response to the bot’s behavior during training and debugging.
Expected GROCERYbot behavior
In general, our intention was for the chatbot to behave as follows:
- If a user query exactly or very closely matches an FAQ question or a defined intent, answer the query.
- If a user query can’t be answered with an FAQ answer but is in the scope of a KB article, answer the question based on article text, or suggest the article. (Actually linking the user to the article is outside the scope of this project.)
- If the user query is outside the scope of the grocery shopping domain (which is limited to information about produce and canned goods), defer. (This behavior is controlled by our negative fallback intents.)
We were pleased by the bot’s performance in this area.
Here is the bot providing an answer to a user query from the FAQ Knowledge connector.

In the image above, note that we have made debugging easier by identifying the source of the bot’s answer to the user query.
Here is the bot providing an answer to a user query from one of the PDF Knowledge documents.

Note that the text is labeled as coming from the file/connector “cannedgoods_overview.”
Below the bot defers on an answer to the user query because the topic (yogurt) is outside the produce or canned goods domain.

Note that the intent referenced is “Default Fallback Intent”, which handles negative responses.
What’s next?
In post #6 in this series we talk about GROCERYbot training and debugging (called “Validation” in Dialogflow).