About on Bas Ernst

4 - More SPARQL queries

Thu, 01 Oct 2026 21:32:33 +0200

This week I continue studying the basic concepts of RDF. According to my ChatGpt course, I will study other types of queries that allow to filter or aggregate results. Let’s see what that will mean.

I will again reference mainly this website for studying the concepts: https://sparql.dev/article/SPARQL_Query_Language_Basic_Concepts_and_Features.html

OPTIONAL

A user sometimes cannot be certain that the data they are looking for is present in the database. The Optional patterns allow to specify patterns that may or may not be present in the data. This is used to retrieve data that may be missing or incomplete, as it does not require the pattern to match. The syntax for an optional pattern is as follows:
```
OPTIONAL {
 query pattern
}
```
For example, if we wanted to retrieve all organisations in our dataset that have a name defined by schema:name and that may or may not have a ex:presents relation with a project , we would use the following query:
```
PREFIX ex: <https://example.org/kg/>
PREFIX schema: <https://schema.org/> 

SELECT ?organisation ?organisationName ?project
WHERE {
 ?organisation schema:name ?organisationName .
 OPTIONAL {
 ?organisation ex:presents ?project .
 }
}
```
can return something like:

organisation organisationName project

organisation1 Organisation One project1

organisation2 Organisation Two —
GROUP BY

organisation	organisationName	project
organisation1	Organisation One	project1
organisation2	Organisation Two	—

We now look at some of the aggregation clauses when working with SPARQL. The ORDER BY clause is used to create groups of solutions, normally with the intention to perform an aggregation on each group. In the example we return the number of projects per organisation.

PREFIX ex: <https://example.org/kg/>

SELECT ?organisation (COUNT(?project) AS ?numberOfProjects)
WHERE {
 ?organisation ex:presents ?project .
}
GROUP BY ?organisation

This can result in something like:

organisation	numberOfProjects
organisation1	4
organisation2	2
organisation3	7

COUNT

COUNT is another aggregation functions, that allows the user to count the number of occurrences or values of the specified variable. The COUNT funtion is used in the SELECT clause.

If the user intends to count the number of projects per organisation in the database, they can use the following query:

PREFIX ex: <https://example.org/kg/>

SELECT ?organisation (COUNT(?project) AS ?numProjects)
WHERE {
 ?organisation ex:presents ?project .
}
GROUP BY ?organisation

HAVING

Having is a related function to GROUP BY. The HAVING clause is used to filter the results produced by GROUP BY based on a specified condition. In the example that follows, the query returns organisations that have presented at least three projects.

PREFIX ex: <https://example.org/kg/>

SELECT ?organisation (COUNT(?project) AS ?numberOfProjects)
WHERE {
 ?organisation ex:presents ?project .
}
GROUP BY ?organisation
HAVING (COUNT(?project) >= 3)

FILTER

Filters allows the user to specify additional criteria for the data they want to retrieve. A filter is used to restrict the results of the query based on certain conditions. The syntax for a filter is as follows:

FILTER(condition)

For example, if we wanted to retrieve all the people in our dataset who have a foaf:name starting with the letter “J”, we would use the following query:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>

SELECT ?name
WHERE {
 ?person foaf:name ?name
 FILTER(STRSTARTS(?name, "J"))
}

It seems that HAVING and FILTER are fairly similar.

The W3C specification describes HAVING as analogous to FILTER, but operating over groups rather than individual solutions:

FILTER filters individual solutions/rows.
HAVING filters groups of solutions, usually after GROUP BY and aggregation such as COUNT, SUM, or AVG.

And finally we can combine the previous concepts (GROUP BY, HAVING, COUNT and ORDER BY) together:

SELECT ?organisation (COUNT(?project) AS ?numProjects)
WHERE {
?organisation ex:presents ?project .
}
GROUP BY ?organisation
HAVING (COUNT(?project) >= 3)
ORDER BY DESC(?numProjects)

3 - SPARQL queries

Thu, 24 Sep 2026 21:32:33 +0200

Learn to query RDF.

SPARQL (a recursive acronym for SPARQL Protocol and RDF Query Language) is the query language to retrieve and manipulate data in an RDF database. SPARQL combines elements from SQL queries with the RDF triple patterns. A SPARQL query applies triple patterns (subject, predicate, object) that can be used to match against the RDF data. SPARQL allows to read and to write to the database. It is primarily a query language, but it also supports operations for modifying RDF data through specific query forms and protocols.

In this article I try to discuss some of the basic search functions. I am using as a source SPARQL Query Language: Basic Concepts and Features sparql.dev.

Essential elements for queries are SELECT, WHERE, and FILTER clauses.

SELECT

The SELECT clause specifies which variables will returned by the query as results. The following query retrieves all the predicates and objects associated with the subject “Maria”:

SELECT ?predicate ?object
WHERE {
 <http://example.org/Maria> ?predicate ?object
}

Query elements that start with a question mark are the variables. So, in this case we have the variables ?predicate and ?object.

WHERE

The Where clause allows to add constraints to the query in order to return data the meets certain criteria. SPARQL uses a SELECT … WHERE { … } structure. Variables start with ?.

The WHERE clause is used to specify the triple patterns to match against the RDF data. For example, the following query retrieves all triples where the subject is “Maria” and the object is “project3”:

SELECT ?predicate
WHERE {
 <http://example.org/Maria> ?predicate <http://example.org/project3>
}

In this query, the triple pattern http://example.org/Maria ?predicate <http://example.org/project3 > matches against all triples where the subject is “Maria” and the object is “project3”.

FILTER

The Filter clause ensures that only data is returned that meets the filter criteria. It works as a filter on the amount data to be returned. The FILTER clause is used to apply additional constraints to the query results. For example, the following query retrieves all predicates where the subject is “Maria” and the object is a string that contains the word “Community Voices”:

SELECT ?predicate
WHERE {
 <http://example.org/Maria> ?predicate ?object
 FILTER (CONTAINS(str(?object), "Community Voices"))
}

In this query, the FILTER clause applies a constraint to the ?object variable, ensuring that it contains the words “Community Voices”.

ORDER BY

The ORDER BY clause is used to sort the query results based on a specific variable. For example, the following query retrieves all predicates where the subject is “Maria” and orders the results by the predicate:

SELECT ?predicate
WHERE {
 <http://example.org/Maria> ?predicate ?object
}
ORDER BY ?predicate

In this query, the ORDER BY clause sorts the results by the ?predicate variable in ascending order.

Run SPARQL

To run SPARQL queries I use Apache Fuseki. This runs as a server on my local machine while accessing the database I am workng on.

First step is to install Fuseki. I run a Debian based Linux distribution, and I downloaded the latest Fuseki distribution from Apache.

wget https://downloads.apache.org/jena/binaries/apache-jena-fuseki-6.2.0.tar.gz

Then:

tar -xzf apache-jena-fuseki-*.tar.gz
cd apache-jena-fuseki-*

Suppose my Turtle file is:

~/Development/rdf-course/cultural-graph.ttl

You can start Fuseki with a dataset called cultural:

./fuseki-server --file ~/Development/rdf-course/cultural-graph.ttl /cultural

Now Fuseki is running locally.

Practical work

I use an RDF/SPARQL environment to query the graph I made during previous lessons. Here are some examples of basic queries:

Which organisations exist?

PREFIX ex: <https://example.org/kg/>
PREFIX schema: <https://schema.org/> 

SELECT ?organisation 
WHERE { ?organisation a schema:Organisation .}

Which projects exist?

PREFIX ex: <https://example.org/kg/>
PREFIX schema: <https://schema.org/> 

SELECT ?project 
WHERE { ?project a ex:Project .}

Which organisations participate in which projects?

PREFIX ex: <https://example.org/kg/>
PREFIX schema: <https://schema.org/> 

SELECT ?organisation ?project 
WHERE { ?project ex:hasPartner ?organisation .}

Which people work for which organisations?

PREFIX ex: <https://example.org/kg/>
PREFIX schema: <https://schema.org/> 

SELECT ?person ?name ?organisation 
WHERE { ?person ex:worksAt ?organisation ;
 schema:name ?name .}

Which projects belong to which organisation - just return the names?

PREFIX ex: <https://example.org/kg/>
PREFIX schema: <https://schema.org/> 
PREFIX dcterms: <http://purl.org/dc/terms/> 

SELECT ?projectName ?organisationName 
WHERE { ?project ex:hasPartner ?organisation ;
 dcterms:title ?projectName.
		 ?organisation schema:name ?organisationName .}

Which projects started after a particular date?

Example:

PREFIX ex: <https://example.org/kg/>

SELECT ?project ?organisation
WHERE { ?project ex:hasPartner ?organisation .}

2 - RDF Modelling and Vocabulary Reuse

Mon, 07 Sep 2026 06:32:33 +0200

Objectives

This week I continue to improve my understanding of RDF. I use the previous mentioned sources, as well as 3WC and online material.

Learn about:

Vocabulary reuse
Namespaces
Interoperability
Domain vocabularies

RDF is a W3C standard for representing and exchanging structured, machine-readable data on the web, using a graph-based model to describe resources and their relationships.

What is RDF modelling:

A way to represent and organise data in a structured manner. As we discussed last week, RDF uses statements consisting of triples. RDF modelling is the process of representing entities, their properties, and relationships as RDF triples, thereby creating a graph describing some domain of interest.

It can also consist of meta data that describes how data is organised in the RDF model. The purpose is to organise and encode data in such a way that computers can understand them. There are several standards in use to ensure a that rdf data is handled and modelled in a consistent way.

Vocabularies and ontologies provide terms and semantics.

For example:

ex:maria a foaf:Person ;
 foaf:name "Maria Rossi" ;
 ex:worksAt ex:organisation3 .

Vocabulary reuse

Let’s first try to understand what vocabularies are in the context of RDF. A vocabulary describes the use of properties and classes in RDF data (3WC). This collection of terms can be used to describe resources in an RDF graph.

The reason for reusing existing vocabularies is that developers, data scientists, or others who have worked with RDF before are more likely to understand and work with the data. The terms already have a shared meaning, which makes it easier to exchange and combine data. The disadvantage is that popular shared vocabularies are often quite generic by design and may not cover the specific needs of a particular domain. Therefore, it makes sense to reuse existing terms when they accurately describe what you mean, and extend them when necessary instead of creating everything from scratch. (https://medium.com/the-national-archives-digital/reusing-standard-rdf-vocabularies-part-1-5a9bbfa58b85)

Imagine two cultural organisations:

museum1 ex:hasName "Louvre" .
museum2 ex:hasName "Rijksmuseum" .

versus:

museum1 schema:name "Louvre" .
museum2 schema:name "Rijksmuseum" .

If both use schema:name, another dataset can much more easily understand and query both datasets.

FOAF, Schema.org, Dublin Core and SKOS are all RDF vocabularies used to describe things on the web, but they focus on different domains and overlap in complementary ways.

Schema.org: Used across the web to describe everyday things like products, events, and organisations.
FOAF (Friend of a Friend): Used to describe people, their profiles, and how they relate to other people.
Dublin Core: Used to describe digital and physical documents, books, and media files.
SKOS: Provides terms for describing concepts and knowledge organisation systems such as thesauri, taxonomies and controlled vocabularies.

Namespaces

The IRIs in an RDF vocabulary often begin with a common substring known as a namespace IRI. Some namespace IRIs are associated by convention with a short name known as a namespace prefix.

A namespace IRI is commonly used as the base for the IRIs of terms belonging to a vocabulary. A namespace prefix is a convenient abbreviation for that IRI in RDF serialisations such as Turtle.

Some examples:

@prefix schema: <https://schema.org/> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix ex: <https://example.org/> .

Interoperability

Interoperability is a characteristic of a product or system to work with other products or systems.

In the case of RDF Interoperability is the ability of different systems and datasets to exchange and interpret data consistently. RDF supports interoperability by providing a common data model and allowing datasets to use shared, globally identifiable vocabulary terms.

As RDF has developed over time, variations in syntax, processing assumptions, and supported features have the potential to create inconsistencies between implementations. W3C aims to mitigate these risks by outlining shared practices for maintaining consistent behaviour.

RDF
↓
common graph/data model
↓
shared vocabularies
↓
shared terms and meanings
↓
interoperability

Domain vocabularies

Domain vocabularies in RDF (Resource Description Framework) are specialised sets of predefined classes and properties used to describe data and relationships for a specific subject area or industry. The important idea is specialisation.

Domain vocabulary describes a vocabulary whose terms are specifically concerned with a particular subject/domain. A domain vocabulary can also be a shared vocabulary.

A general vocabulary like Schema.org won’t necessarily capture all the semantics you need. A domain vocabulary such as CIDOC CRM provides much richer concepts for cultural heritage.

And you can combine them:

ex:exhibition1 a crm:E7_Activity ;
 schema:name "Italian Renaissance" ;
 dcterms:description "..." .

Here you’re reusing multiple shared vocabularies, including a domain-specific shared vocabulary.

Let’s have a closer look at four shared vocabularies:

SKOS

Simple Knowledge Organization System (SKOS) provides a standard way to represent knowledge organisation systems using the Resource Description Framework (RDF). Encoding this information in RDF allows it to be passed between computer applications in an interoperable way.

SKOS is a data model for representation of thesauri, classification schemes, taxonomies, subject-heading systems, or any other type of structured controlled vocabulary. SKOS is part of the Semantic Web family of standards built upon RDF and RDFS, and its main objective is to enable easy publication and use of such vocabularies as linked data.

Dublin Core Terms

Dublin Core is an RDFS Schema (RDFS) ontology for metadata management for electronic resources. It is commonly used in the digital and printed publication domain for creative works. It contains concepts like BibliographicResource and Dataset and properties like author, license, language, audience. (Serles)

DCT is a vocabulary that has been around since 2008 and its use is ubiquitous. Even if somehow the user was not aware of Dublin Core, the naming of the terms is straight-forward. One can likely infer the meaning of dct:identifier as holding an identifier for the resource, and dct:description as holding a description of the resource.

Schema.org

Schema.org is a reference website that publishes documentation and guidelines for using structured data mark-up on web-pages (in the form of microdata, RDFa or JSON-LD). Its main objective is to standardise HTML tags to be used by webmasters for creating rich results (displayed as visual data or infographic tables on search engine results) about a certain topic of interest. It is a part of the semantic web project, which aims to make document mark-up codes more readable and meaningful to both humans and machines.

Schema.org is a collaborative, community activity with a mission to create, maintain, and promote schemas for structured data on the Internet, on web pages, in email messages, and beyond.

FOAF

The FOAF (“Friend of a Friend”) project is a community driven effort to define an RDF vocabulary for expressing metadata about people, and their interests, relationships and activities.

FOAF is a machine-readable ontology describing persons, their activities and their relations to other people and objects. Anyone can use FOAF to describe themselves. FOAF allows groups of people to describe social networks without the need for a centralised database.

FOAF is a descriptive vocabulary expressed using the Resource Description Framework (RDF) and the Web Ontology Language (OWL).

Reflection using ChatGpt

During my final project at the Open University, I worked with RDF before, although my experience is still quite limited. I came across some of the four vocabularies that I have now studied. The additional context provided in this lesson is definitely helpful. However, I still do not have a clear understanding of which concepts are best handled by one of these vocabularies, or perhaps by other vocabularies. I suppose I will have to find that out by working more with RDF and building up my experience.

1 - Understanding RDF

Sat, 29 Aug 2026 06:32:33 +0200

Image taken from: Deeppavlov.ai

When studying towards my undergraduate in IT I got interested in graph databases. In the graph data model, things are related to other things. These things and relationships can be further detailed by adding properties. In the background, the data of the graph data is abstracted away from the user and stored in appropriated data structures. Graph databases depend on graph theory stemming from mathematics, where the things are called vertices or nodes and connected with edges. The mathematical concepts from graph theory can be used for working with graphs in computer science, for instance for calculating shortest distances between nodes via edges.

I am learning RDF, Resource Description Framework, as a model for expressing statements. This will become useful as I aim studying knowlegde graphs that can use RDF. I am currently using these two resources:

Hogan, Aidan, Claudio Gutierrez, Michael Cochez, et al. Knowledge Graphs. Synthesis Lectures on Data, Semantics, and Knowledge. Springer International Publishing, 2022. https://doi.org/10.1007/978-3-031-01918-0.

Serles, Umutcan, and Dieter Fensel. An Introduction to Knowledge Graphs. Springer Nature Switzerland, 2024. https://doi.org/10.1007/978-3-031-45256-7.

RDF is used as a data model for an RDF graph database. RDF is the framework to organise and represent data as triples.

More formally, the things I mentioned earlier can be represented as triples consisting of subjects and objects connected by predicates. A subject is related to something else, an object, through a predicate (the relationship). The reasoning goes from subject via the predicate to the object: an RDF triple is directed.

One of the fundamental ideas of using RDF, is that a subject is represented by some unique identifier, related to something else represented by a unique identifier or a literal value (something with a datatype, such as strings, integers, dates), or a blank node (a node without an IRI or literal value).

The unique nodes are identified with an IRI (Internationalised Resource Identifier) which denotes a resource. This is key in RDF, which is based on working with resources. IRIs are similar to URIs. An IRI is essentially an internationalised form of a URI, allowing a much broader range of Unicode characters. Nodes and edges can have human readable labels.

Namespaces are used to avoid naming collisions and to provide a way of grouping and identifying terms. A prefix provides a short name for an IRI namespace, allowing long IRIs to be written in a more compact form. They make RDF more readable and manageable. In short In RDF, a namespace is a base IRI (like http://xmlns.com/foaf/0.1/), and a prefix is a short label (like foaf) used to make long IRIs short and easy to read.

Blank nodes are different from IRIs and literals. They are typically used for unnamed objects or describing complex constructs.

In synthesis (Serles)

The subject of a triple can be an IRI or a blank node.
The predicate of a triple must be an IRI.
The object of a triple can be any of the three types of terms.

To wrap it all up as: A set of RDF triples comprise an RDF graph. Therefore, they are often presented as graphs. An RDF graph is a labelled, directed graph where nodes represent resources (IRI or literal) and blank nodes and edges represent predicates that connect two resources denoted by the subjects and objects of triples. (Serles)

Asking Chatgpt to come up with a RDF course

Sat, 15 Aug 2026 06:32:33 +0200

Learning RDF: a hands-on approach

While writing my BSc thesis, I learned the basics of labelled property graphs, working mainly with Neo4j, and I also experimented a little with RDF-based graph querying using Wikidata.

I decided that, at some point, I wanted to spend more time understanding RDF properly. The reason is that I want to learn more about Knowledge Graphs and, in particular, explore the RDF world in more depth.

One of the things I want to find out is whether RDF and its related technologies allow me to describe a specific domain of my research in a richer and more precise way than I could with a labelled graph. I have some ideas about this, but I want to test them through practical examples rather than simply assuming that RDF is the better approach.

I have been reading two textbooks on the subject. However, I have found myself feeling a little like I am reading dictionaries: they describe a huge number of possibilities, but often without giving me a clear path through the concepts or enough hands-on examples to build up a proper understanding.

That is why I decided to ask ChatGPT to develop a tailor-made course for me. The idea is to learn RDF and related technologies step by step, apply them to examples from the cultural and NGO sectors, and gradually build something more substantial.

So I asked ChatGPT to design a 14-week course. This is what it came up with:

Week 1 – RDF fundamentals Understanding triples, IRIs, literals, blank nodes, Turtle and the RDF data model.
Week 2 – Reusing vocabularies Working with existing vocabularies such as Schema.org and understanding when and why to reuse them.
Week 3 – SPARQL fundamentals Querying RDF graphs and learning the basic structure of SPARQL queries.
Week 4 – Advanced SPARQL Exploring more complex queries, filtering, aggregation, optional patterns and federated queries.
Week 5 – Setting up a local triplestore Moving beyond examples and working with a local RDF database, using Apache Jena/Fuseki.
Week 6 – RDFS and inference Understanding classes, subclasses, properties and how RDF Schema can be used to derive new information.
Week 7 – Introduction to OWL Moving from basic RDF/RDFS towards ontologies and understanding what OWL adds.
Week 8 – OWL restrictions and modelling Working with restrictions, classes, properties and more expressive ways of describing a domain.
Week 9 – The Open World Assumption Understanding one of the important differences between RDF/OWL reasoning and the assumptions we often make when working with conventional databases.
Week 10 – OWL, SPARQL, SHACL and application logic Exploring what each technology is good at and, importantly, what it is not designed to do.
Week 11 – SKOS Learning how controlled vocabularies, thesauri and classification schemes can be represented as RDF.
Week 12 – SHACL validation Using shapes to define constraints and validate RDF data.
Week 13 – Working with RDF programmatically Using Python and Java to create, query and manipulate RDF data.
Week 14 – A cultural/NGO Knowledge Graph Bringing everything together in a small practical project based on a realistic cultural or NGO domain.

The course itself is only the starting point. For each topic, I study the subject using books, academic articles, documentation and discussions in relevant online forums. I then bring what I have found back to ChatGPT, discuss and challenge the results, and use that process to clarify my understanding and identify gaps or inconsistencies. Finally, I write my own version of the material. In this way, ChatGPT is not simply providing the course content; it acts more as a tutor and discussion partner while I use other sources to build and verify my understanding. Let’s see if this aproacj will work out well.

Graduation Open University - BSc in Computing and IT

Sun, 29 Mar 2026 11:32:33 +0200

On Saturday 28 March 2026 I attended the graduation ceremony of the Open University at the Barbican Centre in London, an absolutely brilliant event and a memorable way to celebrate with my biggest supporters the conclusion of an eight-year journey studying part-time towards a BSc in Computing and IT. I have always enjoyed learning, ever since I was a child, and that curiosity helped me through the many assignments, deadlines, and eventually a thesis on data analysis in diplomacy and gender. What I learned during these years is already proving useful in my work. And who knows, perhaps computational cultural diplomacy might one day become a discipline in its own right. For now, I am simply grateful for the journey… and already thinking about the next study objective for the coming years.

Evaluating Cultural Diplomacy projects with Neo4j

Sat, 21 Mar 2026 11:32:33 +0200

I will once again work with the small dataset I used for my previous post. However, this time I will not use Calc or Excel, but a graph database. Of course, for this tiny dataset, using this tool could be considered overkill. However, as I plan to add more projects and countries to the analysis in future iterations, the advantages of a graph-based database will become clearer. Since it is well suited for analysing networks, it will allow us, in future versions of this project, to analyse cultural relations by examining them as a network.

For now, I will partially repeat the same analysis as in my previous post, but I will also add some new analyses that are not easily possible with a tabular spreadsheet. For more info on the data, see evaluating_cultural_diplomacy_made_easy

Beyond that, I find graph databases more intuitive than relational databases. In cultural diplomacy, missions and their teams either manage cultural projects directly (engaging artists directly) or collaborate with external partners. This is far easier to visualise as a network than as a table of columns and rows.

Graph databases are built on the idea that things in real life are connected to each other. These things are called nodes, and they can have relationships. Graph databases are highly flexible and easy to work with, supporting a wide range of data types. For example, Wikipedia is based on a graph database. For my project, I’ll be using Neo4j, one of the market leaders in this space. Its query language is called Cypher, and Neo4j offers excellent learning resources on its website, making it quick to pick up. I use both their Community Server Edition, which runs locally on my system, and their cloud solution, Aura, which adds useful tools like Bloom for exploration and dashboards. Of course, if you’re working with sensitive data, it’s worth while considering other solutions than corporate clouds. Since I’m using fake data for this project, there’s no issue.

Let’s start by considering how to manage our data and constructing a simple data model. Conceptually, I find the Theory of Change useful (it has of course it limits, not in the last place it implies presumes causality between inputs and outputs which is not easy to demonstrate). It analyses how policy implementation can achieve meaningful impact. Using this framework, we can:

Identify a challenge to address,
Deploy specific instruments,
Generate results,
Analyse the outcomes, and
Measure how these contribute to broader policy goals.

The Theory of Change helps structure the thought process into a model that supports cultural diplomacy, focusing on instruments most likely to generate positive outcomes. You can read more about it on Wikipedia Theory of Change

For this use case, I opted for the following data model. In Cypher a datamodel can be called with the following query:

CALL db.schema.visualization()

Starting on the left, each team member is linked to one or more organizations they follow. Each organization manages one or more projects, which in turn contribute to specific goals. Additionally, each project is associated with a date, a region, and a discipline.

One feature I particularly appreciate is the ability to generate a graph visualisation of team members and their partners. While this is a small example, it effectively illustrates the team’s dynamics: who is working on what, and what the team is collectively focused on. For this example, I’ve included two team members, Eve and Mike, along with their local cultural partners. To visuelise their relations, I used the following query:

(t:TeamMember)-[f:FOLLOWS]->(p:Partner) RETURN t,f,p;

Which returns:

As in my previous post, Neo4j allows you to calculate aggregations such as the average, maximum, and minimum grant amounts. Using its built-in dashboard functionality, you can easily generate visualisations, such as a bar graph showing the total and average grants awarded to different cultural disciplines.

MATCH (p:Project)-[:HAS_DISCIPLINE]->(d:Discipline)
RETURN d.name AS discipline, COUNT(p.naam) AS projects, SUM(p.grant) AS totalGrants, SUM(p.grant)/COUNT(p.naam) AS `average grant`
ORDER BY projects DESC;

Neo4j Aura generates an interactive graph that allows the user to indicate what variables to include. The user can switch between properties. In this case, the totals and averages are displayed.

Finally, Cypher queries can be integrated into a Jupyter notebook. This combination is very powerful, merging the flexibility of a graph database with the robust data analysis and visualisation tools offered by Pandas. In a future update, I’ll share examples of how this approach can enhance the analysis of cultural diplomacy projects. Before that, I will write a post in which I will illustrate setting up the graph database combining this small dateset and Neo4j.

Setting up a graph database

Fri, 06 Mar 2026 11:32:33 +0200

In my previous post I mentioned using a graph database to store data from a small cultural diplomacy database. This would be most useful considering partners and projects as a network. The example data that I am using here is rather small, but eventually I can add more data and this type of database will become more usefull. Intuitively a graph database is easier to visualise mentally than a traditional relational database. Basically it boils down to ’things’ that are related to other ’things'.

In this post I will show how to set up the nodes and relationships that model the reality of my simple cultural diplomacy dataset. I will start with the datamodel that visualises how the data elements relate to each other. Using the data in my previous post, it consist of the nodes and relationships that I will build now.

Let’s start working from left to righ. I will first create the nodes of the two team members. Cypher can read csv files. In this case fields are separated by a semi-colon, which we should indicate. Cypher reads the csv file form row to row.

LOAD CSV WITH HEADERS
FROM 'file:///randomProjectList2.csv' AS row
FIELDTERMINATOR ';'
WITH row
MERGE (p:`TeamMember` {naam: row.`TeamMember`})

When I run this code, Neo4j will return a graphical representation of the team member nodes. As some of the projects are followed by more then one team member, we get three nodes of which one with the list containing both member. We can limit the representation to the only two staff members by separating the names that are present in a list of names.

LOAD CSV WITH HEADERS
FROM 'file:///randomProjectList2.csv' AS row
FIELDTERMINATOR ';'
WITH row,
 split(row.TeamMember, ',') AS members
UNWIND members AS staff
WITH row, trim(staff) AS TeamMember

MERGE (p:`TeamMember` {naam: row.`TeamMember`})

The creation of the other nodes is pretty much following a similar pattern. Except for projects, where I have added a various properties that describe projects.

FROM 'file:///randomProjectList.csv' AS row
FIELDTERMINATOR ';'
WITH row,

MERGE (p:Project {name: row.`Project Name`})
SET p.id = row.`Project ID`
SET p.grant = toFloat(row.Grant)
SET p.budget = toFloat(row.`Project budget`)
SET p.disciplines = row.Discipline
SET p.regios = row.Region
SET p.months = row.Month
SET p.participants = toInteger(row.`Number national participants`)

The nodes are related with each other through relationships. The relationships express how and in what way the nodes are connected. Team members follow cultural partner organisations. Cultural organisations organise cultural projects. In Cypher this can be define with the following expression. In this example the two nodes TeamMember and Partner are connected with the relationship FOLLOWS. The same procedure can be followd for a Partner that ORGANISES a Project In cypher these triplets are formed as follows.

(t:TeamMember)-[f:FOLLOWS]->(p:Partner)
(p:Partner)-[o:ORGANISES]->(a:Project)

And just as an example, this is how you can create a relationship:

LOAD CSV WITH HEADERS
FROM 'file:///randomProjectList.csv' AS row
FIELDTERMINATOR ';'
WITH row,
 split(row.Discipline, ',') AS disciplines
UNWIND disciplines AS sector
WITH row, trim(sector) AS discipline

MERGE (d:Discipline {name: discipline})
MERGE (p:Project {naam: row.`Project Name`})

MERGE (p)-[:HAS_DISCIPLINE]->(d)

These were some examples and code snippets how to set up the graph database. Neo4j’s website contains some great documentation as well as online course that will teach you effectively how to create cypher queries to set up up your database and return data from it. Neo4j Docs.

Why Evaluation and Monitoring Matter in Cultural Diplomacy

Sun, 22 Feb 2026 11:32:33 +0200

There are many definitions about cultural diplomacy. I profer to consider my work as a pracitce through which states and/or international organisations pursue foreign policy objectives. There exists many approaches how to implement cultural diplomacy. In this field measuring results and impacts is often considered problematic. There is still a common perception that cultural projects cannot be measured. Some argue that quantitative analysis fails to capture the complexity and nuance of artistic work. Others point out a more practical challenge: in cultural diplomacy there is often limited time, and evaluation activities are the first to be postponed or neglected. I understand the difficulties of measuring impact of artistic work, but in this field of work we are not merely artistic directors. Cultural diplomats collaborate with organisations and practitioners who create and deliver artistic content. Therefore, cultural diplomacy is less about making artistic choices and more about building networks, facilitating partnerships, and identifying strategic opportunities. Our role is often one of connection, coordination and positioning rather than curation. So, despite the difficulties, why is it important to try to measure results in cultural diplomacy?

Without data, it becomes difficult to tell the story of what has been achieved. Careful analysis can reveal patterns and insights that would otherwise remain hidden. Numbers do not replace narratives, but they support them.
Cultural teams in diplomatic missions should also see themselves as learning teams. Reflection requires input. Structured monitoring helps teams understand what worked well, what did not, and why. This is not about control; it is about continuous improvement.
There is also an important dimension of accountability. In diplomacy, we work with taxpayers’ money. The public has a right to know how cultural budgets are used and what impact they generate.
Finally, from an internal perspective, having reliable data strengthens a team’s position. Evidence-based reporting allows you to defend your work and demonstrate performance using your own data.

Another common obstacle is the perceived lack of technical knowledge. How should projects be tracked? How should data be structured? In reality, one can start very simply. Tools such as LibreOffice Calc, Excel, or Google Sheets are entirely sufficient to build a basic monitoring system. If you are interested, you can find the tutorial here: evaluating_cultural_diplomacy_made_easy

Evaluation of cultural projects made easy

Sun, 15 Feb 2026 11:32:33 +0200

Making evaluations of cultural projects easy

In general, those working in cultural diplomacy tend to focus on making projects happen. Collecting and analysing data for monitoring and evaluation purposes is often seen as a challenge. A lack of time, limited expertise, or simply a lack of priority can all stand in the way. However, with relatively little effort, it is possible to gather basic project data, carry out straightforward analysis, calculate key indicators and produce meaningful visualisations. Even setting up a simple document in Excel, Calc, or any other readily available spreadsheet programme can be an effective first step towards visualising the results of your work.

This tutorial provides some easy steps to evaluate projects. For this purpose I made a simple Excel sheet that can be a starting point. Click here to download.

This will enable us to answer questions such as:

How many projects did we support?
In which regions did we support projects?
How many projects took place per month?
How many projects were there per discipline?
What is the average, minimum and maximum grant amount?
How many euros did our partners invest for each euro from our side?
Which projects scored best against our policy goals?

What do you need?

A list of projects
Grants per project
Project budget (Dutch part of the budget)
Starting date
Month (enter the month as a number; Excel will convert this to the correct month).
Number of our national participants (artists, makers, …) per project
Disciplines per project

A score per policy goal, depending on how you measure a project’s contribution to policy goals.

Step 1: Define the column names. For example

Project ID
Project Name
Subsidy
Project budget
Partner organisation
Region
Start date
Month
Number of national participant
Goal 1
Goal 2
Goal 3
Weighted average
Discipline

Then comes the more tedious part: populating your Excel spreadsheet with data. Ensure that numbers are recognised as numbers and dates as dates. You can do this by selecting the relevant cells and checking ‘Format cells’. Numbers should not be treated as text; otherwise, calculations will not be possible.

All the data in this example has been generated randomly. The scores for the three imaginary policy goals could be the scores that you and your team gave to projects, or the results of a questionnaire. It depends on what is available.

The weighted average of the scores for the policy goals is calculated so that a final score between 0 and 1 is returned.

Goal 1 contains scores from 1 to 5; therefore, the results are divided by 5.

Goal 2 contains scores from 0 to 2; therefore, the results are divided by 3.

Since there are three policy goals in this example, the sum of the three scores is divided by 3.

The whole table is ordered so that the weighted average column goes from highest to lowest score. This will be needed for a visualisation later.

Step 2 Aggregate results

In order to create visualisations, we need to prepare the data by grouping the required variables. Excel wants us to calculate totals by discipline, month, and so on before we can use the data for charts.

We are going to count how many times a project takes place in a certain region. I created a new list of regions in column T and used Excel’s built-in COUNTIF function to count how many times a region appears in that column. If you click on one of the cells, you can see the formula: =COUNTIF($G6:$G23;T6). This counts how many times the word in cell T6 (which refers to ‘Region 1’) is present in the column from G6 to G23. You can use this format for other aggregations, of course.

For disciplines, I changed the formula slightly to ensure that cells containing multiple disciplines separated by commas are counted individually. This formula is similar to that used to count the number of regions, except that it separates words divided by commas: =COUNTIF($P$6:$P$23;"\*" & W6 & "\*"). Here, “W6” refers to “Design”, and Excel looks in the P6–P23 column. Enclosing the W6 cell between stars and ampersands lets us count occurrences in cells with multiple results.

The procedure for the months is the same as for the regions. Again, make sure that the months in column I are stored as dates (you can do this by changing the cells’ format).

Step 3: Perform some basic calculations

Excel has all the basic functionality required to calculate averages, minimums and maximums. We will use this for grants. For example, the average grant is calculated using the formula =AVERAGE(D6:D23) in the “Subsidy” column.

Step 4: Visualise the results

Visualisations such as bar and pie charts are powerful tools for revealing the stories hidden in data. The Insert pane in Excel offers plenty of charting solutions. I have included some examples. The procedure is essentially the same for all of them.

First, select the data you want to use; for example, the disciplines and their scores.
Then click on the type of chart that you want in the ‘Insert’ pane, for example ‘bar chart’.
Excel will then generate the visualisation.

There are many options for fine-tuning the presentation of a chart. You can change colours, headings, and so on, depending on your use case. Excel also has a built-in feature “Recommended Charts” that assists the user selecting the most suitable chart.

Step 5: Conclusions

Even this short data sheet demonstrates that meaningful visualisations can be generated to show the results of the work carried out. By examining the responses gathered through the sheet, we were able to address all of the questions.

How many projects did we support?

18 Projects

In which regions did we support projects?

How many projects took place per month?

How many projects per discipline?

What is the average grant amount, the minimum, and maximum

Average grant per project € 5.650,00
Min grant € 1.400,00
Max grant € 9.200,00

How many euros did our partners invest for each euro from our side?

€ 6.11

Which projects scored best against our policy goals?

I hope this worksheet has served as a helpful example of how, with minimal effort and only a basic understanding of data analysis, you can begin collecting meaningful information about a cultural diplomacy programme. The data itself is not an end in its own right; rather, it provides a starting point from which you can tell the story of your work and demonstrate how your particular programme of projects has contributed to your wider objectives.

Gender and Diplomacy

Tue, 30 Dec 2025 21:32:33 +0200

Analysing Gender and Diplomacy using Neo4j and Pandas

In December 2025, I completed my BSc in Computing and IT at the Open University in the UK. For my final project, I deliberately chose a topic that connects my interest in data analysis with my professional field, diplomacy.

My final research project focused on gender and diplomacy. In summer 2024, I discovered the GenDip dataset developed by the University of Gothenburg. This dataset maps all diplomatic relations by gender for the period 1968–2021 and was published with an explicit invitation for scholars to analyse the data and enrich it with additional sources. One of the central questions posed by the project was whether states use the appointment of female ambassadors as an instrument of diplomacy in its own right.

I used a range of data analysis tools to address this and related questions, with particular attention to how the structure of international relations networks influences the behaviour of the diplomatic network. My research is based on graph analysis and offers alternative perspectives on explaining the persistent under-representation of women in diplomacy.

This report is an elaboration of the final research project. It presents the data analysis on gender and diplomacy and documents both the research process and its results. Much of the required reflections by the Open University on the learning process, references to previous OU modules and explanations of how the research builds upon them have been omitted here.

Despite some statistical limitations, my research confirms the GenDip findings on the systematic under-representation of women in diplomacy. By integrating additional datasets, I also propose alternative explanations. Here are some of the main findings:

The project demonstrates the potential of graph data science for research on diplomacy and international relations.
Women are under-represented in senior diplomatic positions, and states appear to make strategic decisions about where to post female ambassadors.
Countries with women holding influential positions in key foreign policy areas tend to attract a relatively higher share of female ambassadors.
Living conditions and levels of gender inequality in host countries are significant indicators: women are more frequently posted to countries with better overall conditions.
Despite its limitations, the additional religion dataset suggests that Buddhist and Muslim countries send a higher proportion of their female ambassadors to countries that promote gender equality, indicating that religion may be a factor worthy of further investigation.
The project started with the question of whether countries use female ambassadorial appointments as a political signal. By combining relevant variables with network centrality measures, I identified countries, beyond the frequently cited case of Saudi Arabia, that deviate from the dominant patterns within the diplomatic network. In this way, the analysis aims to provide useful input for future research.

To read the study, click Open PDF