The Knowledge Engineer job title is very new and primarily involves working with knowledge graphs. Knowledge graphs are a form of database which stores data as semantic relations and uses reasoning to infer new relations. Legislate is bringing knowledge graphs to legal documents to streamline contract creation for the unlawyered. You can read our write up on knowledge graphs to find out more about them and how Legislate uses them. They aren’t a “new technology”, but they are a type of data storage that not many companies use or are familiar with, which is why the role of a Knowledge Engineer is so important. In this article Vaishali Raghvani explains what it means to be a Knowledge Engineer and provides examples of some knowledge graph applications
What are some of the key skills needed for a Knowledge Engineer?
The most important skill of a knowledge engineer is to be a good problem-solver. Similar to software developers, knowledge engineers are trying to solve problems by finding more efficient ways of modeling, storing and querying data. Sometimes, you hit a wall and don’t know how to progress; and that’s when the ability to multi-task or switch between tasks becomes important, as well as having the patience to see the problem through until the end. Switching to another task helps your brain relax, and might even help you come up with a solution while you’re working on something different. Lastly, innovative thinking is an important skill. Since Knowledge Graphs are not yet the standard way of storing data, there may not be a lot of use cases to have a look at when trialling things out, hence innovative thinking is a great skill to have.
What are the day-to-day tasks of a Knowledge Engineer at Legislate?
A lot of my daily tasks at Legislate involve trialling and testing using dummy contracts and dummy data. It’s a way of exploring how to use Knowledge Graphs and figuring out the best way to store and manipulate data, as well as learning how to use datalog rules in order to organise the data. Thinking about the big picture helps, especially when figuring out what you would like to achieve with the data as you can then break down the data manipulation into smaller chunks to help you achieve your goal. It comes with a lot of trial and error and iteration, to see what works and what doesn’t, and helps when thinking of new ideas to implement Knowledge Graphs into the Legislate platform.
What are your favourite aspects of being a Knowledge Engineer?
One of the biggest projects I’ve been involved in so far has been to extract key real-time insights from contracts which would otherwise take a long time to compute with alternative approaches. On the Legislate platform, a user can access metrics about their contracts which are updated each time a contract’s state changes. Some of the insights they give are the time taken to complete a contract and time taken to get a signature on a contract. They are also able to provide contract specific insights such as totals and distributions of values for that specific contract type. Using knowledge graphs to store the data required for these metrics was one of the first actual applications of Knowledge Graphs I worked on and being able to log onto Legislate and see the metrics, and know that my work is being used to calculate the metrics is great, as I know I had a real input into making them work!
What are some applications of knowledge graphs you are looking forward to implementing?
I’m currently working on a visualisation project, for users to focus on the most important aspects of their contracts. In the current prototype, I have used Knowledge Graphs to extract contract terms and sort them into rights and obligations for the parties involved. This essentially means that for a contract such as an Employment Agreement, the parties involved would be the Employer and the Employee. Employer’s obligations include providing the Employee with a holiday and a salary, whereas, employee restrictions would be having a notice period once they are hired and having a post employment confidentiality period, where they must not share confidential information with their new employer. The aim of this feature is to allow users to have a digestible way of understanding their contract, and provides an alternative way to view it rather than just looking at the contract itself and picking out terms.
The opinions on this page are for general information purposes only and do not constitute legal advice on which you should rely.