Using Domain-Driven Design and conceptual modelling to support knowledge graph development

At Semantic Data 2024, we delivered a presentation on how to streamline and optimise Knowledge Graph development using Domain Driven Design. In particular we discussed the layers for consideration when developing a knowledge graph.

In the talk we tried to make the point that often data formats (like RDF) are brought in too soon to the process. This has the effect of excluding certain contributors to model development and stands in the way of the goal of working towards a ubiquitous language for the collective team.

• Using Domain-driven design to build out a well understood and tested conceptual model.
• A documented set of guidelines for the identifier and model patterns of how to turn conceptual model consistently into your data format of choice (things like naming conventions and then to specialise classes).
• The documentation of the model.
• Then starting to test the model with data. Doing this as soon as possible as it will often lead you back to revisiting your model at the whiteboard.

The point here was to say that those information professionals wanting to work more closely with knowledge graphs often look at developing a familiarity with the technology of graph databases and data formats. We think there is a case to be made for understanding the role that working in complex domain areas with very simple tools and the right set of people plays in the process.

Along with Anya and Michael at Parliament we created a diagram mapping out how we go about exploring a problem space and the keys to success. 

• The importance of finding the right people. You will find most people enjoy the opportunity to talk about what they do in a context other than their day to day.
• Its not for everyone but through running short sessions, we try to stay under an hour, you get to learn who shares the same curiosity to document the domain. These are the people you will likely return to.
• We tend to avoid more than two to three people in a session. You don't want one person dominating the conversation. Though you do want the interaction between them and the interaction through anecdotes is usually where the domain language lies.
• Probably the thing that only comes with practice is knowing where to probe and ask for elaboration.
• For example if something thing is hard to pin down or define it can be useful to describe its properties. How does it differ? If at all from this other thing?
• How things relate to each other is as important as the things themselves.
• The final point on the emphasis of whiteboard and pens comes from the insight (by Eric Evans) that we often hide our differences in understanding behind documents.

A lot of the value in working with knowledge graphs is the opportunity to make the implicit knowledge of an organisation explicit to its users (people and machines). Graph technology helps us leverage this but it is no short cut to an organisation growing its awareness of itself.

For those wanting to experiment with domain modeling a great starting point is Data Graphs. it provides a visual modeling tool for running domain model sessions. With a model in place it then allows you to immediately start populating data to see the impact on your model choices. A free trial is available as well as workbench pricing tiers for practitioners.