Graphs in Law Enforcement #4 - Facts in graphs

In the series Graphs in Law Enforcement, we discussed data sources and modelling, data quality and credibility with source ratings, and we spoke about fusing entities.

In the previous blog post about fusing entities, we learned the main takeaway is to consider use cases before creating fused entities and create workflows to ensure all possible issues remain in sync. Once you consider this and create a high-functioning graph, pathfinding in the graph with fused entities becomes seamless. The video showcases a compact path - the shortest possible - between Richard and John, the suspects in question.

If you expand the fused entity node, the vehicle, you will find all the information including relationships. These are extremely valuable pieces of information and the question is; What to do with these nodes and information that formed the fused entity?

How to deal with the facts in a fused entity?

The best way to handle the nodes and their information in a fused entity is to create ‘fact’ relationships from the fused entity to the underlying information, the original node.

In this graph, there are FACT relationships created between the two vehicles and the fused entity. This allows intelligence analysts to traverse the fused entity and drill down to investigate the real facts, as this is critical information.

As the information is crucial, these facts should not disappear from the graph. However, the problem with having the facts in the graph is that they will have an impact on node expansion and pathfinding. There is a high probability that your path will go through the fact, instead of through the fused entity, adding an extra hop. Additionally, visualisations will become more complex which could result in clutter in graphs which contain significantly more data.

However, we do not want to lose the facts, as they contain critical information. Let’s have a look at different solutions where we place them in a new graph to maintain the original while staying neat, organised, and with the preservation of all relevant facts.

Solution for facts

The best way to do this is to offload the facts to another graph. In this way, you will not lose information, but it also does not compromise your visualisation and pathfinding.

This first and main graph shows the two facts in green (the vehicles), that are related to different entities. Next, there is a fused entity created and linked to all the entities that the fact relationships link to. The final graph is the graph where we will offload the facts to.

How to offload facts to another graph

Let’s have a look at how to create a fact graph.

Step 1: The fact graph can consist of a shell node, where we do not copy any properties, except the primary key or strong identifier that we will use to link that node from. The strong identifier could be the registration number of the vehicle(s).

Step 2: Recreate or copy each fact to a different graph, the so-called fact graph, and create the relationships to the fused shell entity. Now there is a fact relation between the fused shell entity and the facts.

Step 3: As we don’t want to lose any information from the original entities, we need to make sure all properties are copied to the fact graph. Therefore, you should copy each shell entity that the fact in the main graph is linked to and link them to the facts in the fact graph.

Step 4: The last step is to remove the facts completely from the main graph, so only the fused entity is left. The main graph is now neater, there is no clutter and you can easily find paths. All the information about the fused entity can be found in the other graph, the fact graph.

Loading facts on demand

The fact graph would look like this. The fused shell entity of the vehicle is there and you can load the facts on demand. When choosing the action to ‘Show facts’, the two original nodes and their properties are shown.

By creating an additional graph and offloading the facts to it, the valuable information is not disposed of, but it is also not cluttering the main graph either and interfering with pathfinding. This approach has its advantages, however, one should keep in mind that there are more aspects to consider when creating such graphs, e.g. data ingestion, updates, systems, and so on.

This blog post concludes the last part of the series “Graphs in Law Enforcement”, based on the talk, Tracking Data Sources of Fused Entities in Law Enforcement Graphs by Luanne Misquitta (VP of Engineering) from GraphConnect 2022. Watch the video or check out the previous blog posts in the series for more information.

Connect with us and stay updated on more information about knowledge graphs in criminal intelligence, or if you are interested to see what GraphAware and Hume can do for your enterprise, request a demo.