Wearing different hats and speaking the same language. Interview with Lukas Jetzig, knowledge engineer and technical communicator at parson

by Lukas Jetzig , Uta Lange on November 20, 2024

What is knowledge engineering and what does a knowledge engineer do in technical communication? We asked our colleague Lukas Jetzig. He has been working as a technical communicator and knowledge engineer at parson since 2022.

Lukas Jetzig, technical communicator and knowledge engineer at parson

Lukas, one of your tasks at parson is knowledge engineering. What exactly is knowledge engineering and how would you describe your role?

In knowledge engineering, we make sure that technical information is not only documented, but that it is also organized in a meaningful way and made available continuously. The first step is to capture implicit and explicit knowledge.

The company's experts, such as developers, product owners, technical communicators, and engineers, have implicit knowledge. We conduct interviews with these people because implicit knowledge often exists only in the minds of these experts. For example, we ask them what configurations, features, and variants exist for a particular product, and what topics in the documentation describe them.

To capture explicit knowledge, we identify content that may be scattered across different systems (silos). We also observe internal company processes.

We then organize the collected knowledge in a structured format and transfer it into models such as ontologies, knowledge graphs, or metadata models. These models help us to logically link information, discover relationships, and make knowledge available in systems.

The knowledge described in a knowledge graph can relate to many different areas. One example is product data, including product variants, product characteristics, components, and features. From the graph, this data can then be made available for various application scenarios, including the automated assignment of metadata to the content of technical documentation.

Example of a knowledge graph used to categorize. Here, vehicles and fuels.

Is knowledge engineering a new discipline in technical documentation?

Knowledge engineering is not new, but has evolved over decades. Its original goal was to transfer human knowledge into computer models to automate problem solving in specific domains.

Today, knowledge engineering is a versatile approach that is used in many areas, especially in the systematic management and use of knowledge. Thanks to modern applications and technologies, knowledge engineering has evolved to play a central role in areas such as knowledge management and technical documentation.

How do you become a knowledge engineer and what knowledge and skills are required?

I don't know if there is a degree program in knowledge engineering. I am a certified translator and interpreter. I also have a degree in Technical Information Design and Technical Communication from the University of Applied Sciences and Arts Hannover.

As a technical communication knowledge engineer, you need a basic understanding of technical writing and practical experience in your day-to-day work with technical documentation.

In addition, targeted training in metadata modeling or knowledge graph development can be useful, for example, by studying common formal languages that are used to define ontologies. I am thinking in particular of the RDF and OWL standards. It can also be worthwhile to become familiar with modeling tools for knowledge networks. Some tools I have worked with are Empolis Knowledge Express, PoolParty and klar:suite. Which one you choose depends on the use case and the project.

It is also important to have a sense of where to find information and how to talk to people to get the important information.

Like a technical communicator, a knowledge engineer must have strong communication skills and the ability to gather, identify, organize, and correlate information through interviews and analysis.

What is the difference between the work of a knowledge engineer and a technical communicator?

The work of knowledge engineers is more abstract and less content-oriented. Technical communicators create, structure and maintain comprehensible and precise documentation such as operating instructions and online help that make complex technical information accessible to different target groups.

A knowledge engineer describes concepts and categories and their relationships. A knowledge engineer is not limited to technical documentation, but can also model knowledge about products or other areas. When modeling knowledge for technical communication, a knowledge engineer determines, among other things, how the information in the documentation is divided into modules and categorized so that it can be found and delivered in a meaningful way.

As a knowledge engineer, do you write documentation?

Not in the role of a knowledge engineer. But most of us at parson are also technical communicators. That's why we sometimes have both roles in a project and write as well. This means that I am first a knowledge engineer and then a technical communicator in a project. So having the knowledge of a technical communicators helps a lot.

Who do you often work with on projects and how do you work together?

On the customer side, I work with the people who know the products. There are the product owners, who hold the threads together and are responsible for product changes and product documentation. Then there are the product developers and technical communicators, but also the information architects who are familiar with the content management system, and the IT departments: They often know a lot about managing product data and the format in which certain data is available.

We also work with other service providers on customer projects, such as content delivery portals and component content management systems (CCMS).

The parson team consists of information architects, technical communicators, and other experienced colleagues who have worked on similar projects. We exchange best practices with them and discuss which approaches work best for a project. As with all parson projects, we apply the principle of dual control, and not only when creating technical documentation.

What do you keep in mind when working with different experts? Are there any problems?

It's important for us to be in a constant dialog. On the customer side, we always ask: Does what we've identified truly reflect your reality? Product worlds are often so complex that they cannot be represented in two dimensions.

We try to wear different "company hats". For example, we always talk to the IT department and ask: Is our data structure compatible with your systems? We also put ourselves in the shoes of the product development and technical writing departments. The most important thing is to find a common language!

What are the requirements for a knowledge engineer to do their job?

In general, it is important to get the right people on board. This means system managers for the various source systems as well as specialists who have the necessary knowledge of the concepts to be modeled. Together, we can determine what metadata needs to be remodeled or what data from other systems (source of truth) can be reused. Depending on the number of source systems that need to be connected, interfaces to these systems will also need to be set up.

To answer these questions correctly, there must also be clarity about the goals of the knowledge engineering project. Why are we making the effort? Should data be harmonized across the organization? Are we trying to create a digital twin? Or is the initial goal to reuse product data for technical communication? The approach and complexity of the task will vary accordingly. It helps if the data is already modeled consistently, at least within the individual information silos. The more consistent the data, the easier it is to implement automated processes. This is often much easier if the organization has developed a well-thought-out content strategy for clear and consistent messages. This means that the organization understands the needs of its audiences and provides them with high-quality, understandable, and consistent information. A company should speak the same language across all channels.

What problems do organizations often have at the beginning of a knowledge engineering project?

Rarely do we start with a blank sheet of paper. Many organizations have thought about how to present their products and processes in a consistent way. But often, each team has its own way of thinking and focuses on different main tasks.

In addition, different teams create different information: Technical writing creates product documentation, product development provides technical data, and marketing writes content for the web site. This data and information is often maintained in different systems that are not necessarily connected, creating data silos. Linking this information across teams is a challenge.

In most cases, knowledge engineering also has to take place alongside the teams' primary work. We get different input from the teams describing the problem in their own ways. Our task and challenge is to summarize this information in a consistent way and to clean up inconsistent data. After all, to make content discoverable and usable in a consistent way, you have to speak the same language. Teams must work together to make the project a success. The knowledge engineer is the interface.

What methods and tools do you use?

We use knowledge graphs to aggregate information and make it available to different audiences or applications.

We often implement our metadata models in CCMS and content delivery platforms. Sometimes, we coordinate the creation of interfaces with existing systems such as product information management (PIM) systems.

However, we also like to use Excel sheets, mind maps, or concept maps to create an initial concept.

What current trends in technical documentation and knowledge engineering are you most excited about?

I find the development of knowledge graphs very exciting. Or when companies try to build a digital twin. The opportunities that generative AI offer are also interesting. The actual use cases are not yet clear to me, but there is potential, for example in homogenizing data.

I once had a project where product features were modeled in very different ways. In some cases, a simple yes/no was assigned to the object, while in other places the text "is available" or "is not available" was used. An AI application could potentially standardize these variations more efficiently. However, we would have to thoroughly test the reliability of such an approach.

What projects are you currently working on as a knowledge engineer at parson?

For one of our customers, we modeled metadata for enriching self-help content based on iiRDS. One of the data sources was metadata from the CCMS used for variant management. Another source was product data, which was actually created for marketing purposes. The knowledge graph enabled us to combine both data sets, making it easier for customers to filter content in the documentation portal. The real challenge was merging and standardizing these vastly different metadata using the knowledge graph.

We successfully aligned two metadata models to speak the same language using the iiRDS model. With iiRDS, we turned chaos into order.

More project references 

What would you like in future projects?

I think it would be exciting to start with a blank sheet of paper, from scratch. For example, to completely rebuild the metadata concept for a CCMS, bring together different teams, and develop a standardized information concept. That way, I wouldn't be constrained from the start, but could focus on the best solution.

Where can you find a knowledge engineer job?

Knowledge engineers are needed in any organization that recognizes the need to get knowledge out of silos and out of people's heads and into a common language. An organization that recognizes the importance of structuring its knowledge needs the expertise of a knowledge engineer. There are more and more service providers offering consulting services for this, including parson.

Learn more about this topic

More interview with the parson team

Add new comment

Your email address will not be published.

You might also be interested in

Ten questions about iiRDS

by on November 20, 2024

Two founding members of the iiRDS Consortium explain the importance and potential of iiRDS and its integration at Endress+Hauser. An interview with Thomas Ziesing from Endress+Hauser and iiRDS consultant Ulrike Parson from parson. Interview: Susanne Lohmüller  more...