Alexi Buckingham

Our knowledge graph product Data Graphs [https://datagraphs.com/] has a brand
new feature. You can now view your entire knowledge graph in the 'Domain Model'
view. This allows you to see your data presented as a spider diagram and explore
it interactively by moving each data point to wherever you like. 

Being able to present your data visually is an essential facet in your company's
digitisation journey and this new Data Graphs feature makes this simple.

Find out more about Data Graphs and Data Visualisation here
[https://datagraphs.com/].

Domain Modelling

New Data Graphs Feature: 'Domain Model' View

Silver Oliver

An introductory guide to tagging: part 4

In the previous post I talked about the challenges of tagging
[https://datalanguage.com/features/why-tagging-tends-to-be-bad-on-websites].
Here I will start to look at some approaches that can help.

One technique that I will always come back to is domain-driven design (DDD). The
principles behind domain-driven design go back to Eric Evans and his book 
Domain-Driven Design: Tackling Complexity in the Heart of Software
[https://www.oreilly.com/library/view/domain-driven-design-tackling/0321125215/]
.  The starting point for domain-driven design has similarities to domain
analysis in Library Science. 

In domain analysis Albrechtsen and Hjørland make the case for domain knowledge
being given greater importance in the role it plays in Information Science.

> Many approaches to information science and Knowledge Organisation may be
understood as attempts to pass over subject knowledge (or at least not make
subject knowledge explicit in their methodologies). Domain analysis, on the
other hand, makes subject knowledge an explicit and important part of the
methodologies of information science and knowledge organization.
Towards a new horizon in Information Science
[https://www.researchgate.net/publication/220434297_Toward_a_New_Horizon_in_Information_Science_Domain-Analysis]

DDD, though aimed at software developers, comes to a similar conclusion.  This
is that many software projects fail due to passing over subject knowledge and
not making understanding the domain a central part of the process. The problem
being that everyone on a team goes away and builds according to their private
view of the domain. Then when it comes to putting the design pieces together
they don't fit.

DDD ensures a team spend time together at the outset of a project to align their
understanding.  This is before they design or build anything.  The success of
this approach is that it supplements existing expertise with a strong and shared
knowledge of the domain.

The aligning of language during these sessions is crucial.  Participants talk to
each other, draw for each other and do everything they can to understand where
differences of understanding or terminology are lurking. 

Diagrams and word documents have the habit of hiding our differences as opposed
to surfacing them. True shared understanding is something that can only really
be achieved by talking about the domain from as many angles as possible. 

It is as simple as that. 

When starting on a project to design and build anything, I would suggest the
following principles:

 * Recognise that caring about and understanding the subject domain is
   important.
 * Domain experts are a critical part of the team.
 * Everyone will have different views, preconceptions, simplifications they
   bring to a domain and this manifests itself in the language they use.
 * Learning where these differences are will be expensive if learnt through
   writing code,  building a taxonomy or designing a user interface. Better to
   learn this cheaply in front of a whiteboard.
 * The best way to surface these differences and align language is in talking, a
   lot, together as a team.
 * Simple domain model diagrams are a great way to share and challenge
   understanding of the domain.
   

The main outcome of all this is the shared language during conversations and in
design decisions.  There will likely also be some domain model diagrams.  An
example of this is the classic Polar Bear presentation
[https://www.slideshare.net/reduxd/beyond-the-polar-bear/22-stadiumbr_competitionbr_teambr_matchbr_roundbr] 
by Mike Atherton of a sports website. 


Credit Mike Atherton [https://twitter.com/mikeatherton] and Paul Rissen
[https://twitter.com/r4isstatic] (model design)This represents the project
team's shared understanding of the domain and consensus regarding how to talk
about it. In this model are all the types of tags we might need. As we
understand more about the website's goals and the plan for which pages are to be
built first we can ensure tagging will support them.

For example we might decide we want to capture tags for teams and matches. Why
not stadiums? If we tag with a match we already have the stadium from the model.
 So we can reduce the burden on taggers to that which is absolutely necessary.
We can also see we get competition round from the model as well. Each tag is
part of a larger model and we adjust our tagging strategy based on our
understanding of the model.

Why not tag with player?  Analysis may show that there is little value in
including players. For example we have seen little use of player pages in other
parts of the site. Then there is no justification in tagging them. Some might
argue that we need to preempt any possible use of the system in the future, so
we should tag players even though this doesn't add value now.  In my experience
this is where we get into trouble.  Keeping a tight focus on the value and the
tagging needed to create that value is crucial. The domain model will help us
map out possibilities but an understanding of our goals helps up pick the right
path through that map.

To continue this example, if we identify that tagging with teams and matches
will  support the objectives of the site then we have an idea of what good looks
like. This informs how we develop the tools, vocabularies and guidelines to
support this goal. An understanding of the domain, the websites goals and its
evolving scope have defined how we design our tagging.

That is a simple example but there are a whole range of more complex case
studies to support this from Wellcome
[https://stacks.wellcomecollection.org/building-a-free-and-unrestricted-digital-museum-and-library-6cdf28784068] 
, BBC [https://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml] 
and Parliament
[https://pds.blog.parliament.uk/2016/09/09/modelling-parliaments/].

I often get asked if this goes against user-centred design philosophies? Yes and
no. 

When working at its best DDD is complementary and works hand in hand with user
centred approaches.  At its core is the idea that the domain as a key organising
principle.  This can still sit within a user-first approach.  However, on the
whole I feel a team aligning its understanding and language within a domain
before engaging with users can only be a good thing.

In summary, one part of the solution to better tagging is to design with a
collective understanding of your systems domain. 

Part 1: Why the web turned its back on the librarians. And why we need them
back.
[https://datalanguage.com/features/why-the-web-turned-its-back-on-the-librarians]

Part 2: The importance of tagging when publishing on the web
[https://datalanguage.com/features/the-importance-of-tagging-when-publishing-to-the-web]

Part 3: Why good subject tagging is hard
[https://datalanguage.com/features/why-tagging-tends-to-be-bad-on-websites]

We use Domain-Driven Design (DDD) as our fundamental foundation for most projects. The skilled facilitation of domain modelling workshops is used to reach a domain model. This helps teams understand core business entities, relationships, and to target areas of crucial strategic value and corresponding pain points.

Domain-Driven Design is a collaborative process that leads to a Domain Model – a point of reference to inform all strategic data and technology decisions.

Domain Modelling

Domain Modelling Blog Posts

News about Domain Modelling