Paul Wilton

Data Language are trusted experts delivering knowledge graph products and services to global brands since 2010.

Knowledge Graph Engineering experts - Data Language

Data Language has exceptional experience in the design, implementation and
deployment of knowledge graphs, linked data, and semantic web technologies. We
have been working with graph databases since our inception, when our founders
worked on possibly the UK’s first enterprise scale knowledge graph for BBC News
and Sport. Since then we have helped global organisations such as Cochrane,
Wellcome, and Euromoney implement them too. Our typical approach to implementing
a knowledge graph solution is:

Domain Driven Design
Through collaborative domain modelling exercises, we work with stakeholders to
gain a broad understanding of the target domain, iteratively refining and
validating ontology models to achieve the ideal level of detail to deliver the
best outcomes, business value and utility.

Technical and Data Architecture
Not all graph databases are equal. We are wholly vendor-agnostic, and our deep
experience in designing scalable, maintainable, and evolvable knowledge graph
solutions, means we will always select the right graph technology to deliver
your use-cases. We understand the difference between label-property graphs and
RDF based graph databases. We have a total grasp on the practical and pragmatic
use of semantics and inference to ensure your solution is not over-engineered
but delivers just the right level of complexity to optimise your total cost of
ownership, and ensure your solution can evolve as your business evolves.

Integration - Data and Software Engineering
We can help you integrate the knowledge graph with your business systems and
workflows, either by helping your own software engineering team with querying
the graph using query languages such as SPARQL or Gremlin, through to developing
microservices and web interfaces that encapsulate your target use-cases. We are
skilled at data engineering, and can help you populate your knowledge graph,
transforming and loading your own business data, and linking to or ingesting
open-data as required.

Automation and Deployment
We can work with and guide your own infrastructure team, or take on the task of
engineering, integration and deployment entirely ourselves. We are skilled at
contemporary best practices for deployment of infrastructure in the cloud or
on-prem. Our devops engineers are skilled in the use of infrastructure-as-code
for fully automating the deployment and maintenance of the entire knowledge
graph solution.

Graph databases

Knowledge Graph Engineering

Alexi Buckingham

When we help global brands deliver a new knowledge graph platform, we often
offer comprehensive training courses during and after MVP delivery in order to
help teams better understand the technologies involved.

Our Knowledge Graph practical courses include:
 1. An Introduction to Knowledge Graphs and Graph Databases 
 2. Designing and Building Domain Models and Ontologies for Knowledge Graphs.
 3. Data Structures for Knowledge Graphs
 4. What is Linked Data?
 5. What is a graph database?
 6. An introduction to RDF
 7. Ontologies vs Instance Data
 8. Reasoning and inference

... and many other areas.

A sound Knowledge Graph foundation for Technical and Non-Technical Staff
While our training does include fairly in-depth technical exercises for the data
teams, many foundational areas are great for employees with less knowledge graph
experience, helping them build a basic understanding of the fundamental
principles.

We also like to make sure that the training we offer is totally tailored to the
domain of the project we are working on. While using generic data during our
courses can help, if it has little relevance to your own domain, it becomes very
difficult to visualise the context and practical applications of the principles
we are teaching. Building the course around the client's own domain allows us to
provide specific examples that then resonate with the teams, leading to them
gaining a greater understanding of the key principles of knowledge graph
creation.

There is more than "one way" to do it
It’s also important to remember that the training we have been giving clients on
knowledge graph management is just one way of doing it. Our training is bespoke
to the patterns and solutions that we have put in place and therefore change and
evolve with each new project and partner. Knowledge graphs are not a
one-size-fits-all endeavour, each are specifically tailored to a company’s
objectives and so the training must also follow that specificity. Our patterns
have been developed over more than 10 years of delivering robust, pragmatic
solutions to knowledge graph engineering.

Teams also learn about the SPARQL query language.  A technical module aimed at
developers that is again tailored entirely around your own domain, learning how
to query your data starting from basic principles, and building up to a
comprehensive understanding of complex query patterns.

Find out more
To find out more about Knowledge Graphs and Graph Databases and how we can help
your company implement them, click the link below.

Knowledge Graph Engineering with Data Language
[https://datalanguage.com/knowledge-graph-engineering]

Knowledge Graph Education

Ear of bat, blood of frog, rabbit’s tail. Stir them all up in your graph
database, utter the magic words, and lo, with a sprinkling of sparql dust, gold
speweth forth.

After working with graph databases for 10 years now, it troubles me that this is
still how many implementers expect things to work. Graph databases are not magic
cauldrons. They really are not.

A graph database is no different from any other database. If you put in data
mess, do not expect order to be created from chaos. If you then combine this
with over constrained and over-engineered inference and reasoning you end up
with an even bigger mess. A popcorn machine.

You will not be able to build robust practical business or enterprise grade
applications by treating your graph as some dirty place where ontologists (who?)
 can dip their fingers in, mess around ad-hoc, and make magic happen. “let’s
just add another inference rule, that will sort it..”

Just like any other practical, robust data architecture, data governance is
essential. Just like any other database you would not expect end users to
interface directly with it via a SQL endpoint, or a JDBC connector? No, you
would build robust, well tested APIs and Services to interface with your
database, and let your application builders interface with these services. End
users would then interact with these applications. These API services are the
gatekeepers of good data governance.  No mess should pass this point. In
production, no human hands should *ever* pass this point. 

Any changes to models should only be done to meet some business need or
requirements. Any changes to models should be tested.

Inference and reasoning should be included in your models *only* to meet some
practical value-deriving business need.  If the inference does not deliver any
meaningful or practical value to your end users, it should not be there. 

If you can deliver a business requirement effectively and easily without
inference, do it without inference.

Your models should be as simple as possible to deliver your business
requirements. A SQL data architect would not just add additional random tables
into their SQL model to deliver their requirements, so when you develop a
practical ontology model for your domain, only model what you need to deliver
those requirements. You do not need to model extra stuff. 

While your domain model may extend well beyond the bounds of your business
requirements (in order to better inform requirements and business landscape),
your detailed ontology models should not. By only engineering the very minimum
of the model needed to deliver your current requirements, your platform is
easier to evolve, easier to maintain, and at a much lower total cost of
ownership.

Finally - end users should not have access to your production graph database
sparql or cypher endpoint. Never. 

Stop pretending you are witches. Start thinking like traditional data
architects.

Graph Databases are not Magic Cauldrons

A discussion on the synergies between GraphQL and Graph Databases, data architecture and how ontology models provide the special ingredients.

The synergies between GraphQL and Graph Databases

5 latin characters
Until recently, my understanding was that apart from 5 latin characters GraphQL
has got little or nothing to do with Graph Databases. But things are changing,
Graph Database vendors have started bringing these two technologies together. A
recent project has given me some insights.

For some background, GraphQL is a contemporary API interface standard used as an
alternative to REST. GraphQL was originally developed by Facebook. It provides a
structured query language for querying (and mutating) data, along with a runtime
implementation to invoke those queries upon your data. In pretty much all
implementations it uses JSON as its serialization format.

REST (I suspect most readers know this) is a lightweight low-level API standard
for performing uniform and a predefined set of stateless operations on data
aligned with the HTTP verbs. With REST you have to design and  build your API
interface contract for that set of operations - and while of course there are
common patterns in REST APIs, this is very much arbitrary. REST makes no
assumptions about the high level API contract or the underlying data model. The
developer defines both. With GraphQL you only define the data model (the GraphQL
schema), exposing to the GraphQL runtime and your consumers what the shape of
the data is.

With a GraphQL query you can request only the minimum data required to fulfil
your current need. Of course you can do this with a REST API too - in fact it is
a common pattern with JSON REST APIs to filter response data by JSON fields
using dot notation. But of course you need to build this yourself.

GraphQL does a lot more for you to boot, as well as out of the box query
patterns for mutating data, it also supports subscriptions (pub/sub style) - so
your GraphQL client can subscribe to server side events, and have data pushed to
it.

The developer ecosystem around GraphQL is superb now - The Apollo GraphQL
[https://www.apollographql.com] implementation works beautifully with React -
integrating with React Hooks for query and subscriptions. Apollo also has
in-browser developer tools akin to the redux-devtools for GraphQL debugging, and
you can manage local app state via Apollo using the GraphQL schemas / queries
etc.

Caching and performance
Requests to GraphQL are typically all POST requests - not great for caching you
ask ? Indeed, this is where REST has excelled for years. But the GraphQL server
implementations have come to the rescue. The Apollo GraphQL server has an
internal caching layer that supports full response caching, and fine grained
field-level caching (read more here
[https://www.apollographql.com/docs/apollo-server/performance/caching/] )

Amazon’s AWS AppSync is a fully managed GraphQL service built upon the Apollo
technologies - and can source data out of the box from other services such as
DynamoDB, ElasticSearch, REST APIs etc. With fully managed caching and real-time
data subscriptions, it really does make your developer life easy.

On the surface it still appears GraphQL has little to do with Graph Databases.
Yet increasingly we are hearing about how they should go together like bread and
butter, sausage and mash.

Not all graph databases are equal
I won't go into depth about what a Graph Database is, but am going to explore
some of the options available, and the relationship between Graph Databases and
GraphQL.

Graph databases come in several flavour combinations. First up you have RDF
graphs vs Labelled-Property graphs. The first big choice. Both are very
different [https://en.wikipedia.org/wiki/Graph_database#Graph_models]. Your
primary use case is important here. Essentially if you primarily need to walk,
query and analyse paths through your graph, then Labelled-Property graphs are
probably the way to go. If you are more interested in the nature of the
relationships between things, and creating rich semantic representations of
things, then RDF graphs hit the spot. Both types have their own well-developed
query language. Labelled-Property graphs are typically queried with Cypher or
Gremlin (eg Neo4J), RDF graphs are queried with SPARQL.

While most mainstream RDF based graph databases are fully compliant to the RDF
and SPARQL W3C standards, not all RDF graph databases are equal. Each has its
own implementation nuances and come with their own added extras (decisions,
decisions!):

 * An RDF graph database may or may not support reasoning (to some degree of the
   RDFS and OWL standards).
 * Reasoning may be at query time (backward chaining) or at write-time
   (forward-chaining).
 * The way reasoning is implemented can dramatically impact performance.
 * Add-ons and extensions for GeoSPARQL, Path analysis, Full text search,
   connections to other datastores etc.

To give some examples (DISCLAIMER - apols to those vendors not mentioned, I am
only referencing those I have worked with properly hands-on, and this is not an
exhaustive features list - it’s just a flavour) :

GraphDB [https://www.ontotext.com/products/graphdb/] (Ontotext)

 * Fully compliant with RDF/SPARQL standard;
 * Highly compliant and configurable OWL / RDFS forward-chaining reasoning
   (materialises inferred knowledge at write time);
 * Unparallelled full-text-search capability using lucene, or via bi-drectional
   connectors to external SOLR or ElasticSearch clusters.
 *  Ability to materialise post-inference fully structured JSON or JSON-LD
   objects into ElasticSearch indices or MongoDB
 * Geospatial querying and other extensions..
 * Rich visual query and management workbench UI
 * UPDATED May 2022 - Path query capability is now avaialble using a SPARQL
   extension plugin

Neptune [https://aws.amazon.com/neptune/] (Amazon AWS)

 * Fully compliant with RDF/SPARQL standards;
 * No reasoning capability
 * Fully managed cloud service
 * Highly, highly horizontally scalable (primarily due to lack of reasoning)
 * Full text search capability via connector to ElasticSearch - materialisation
   into elastic is constrained (you cannot materialise user-modelled JSON
   objects into an elastic index), but delivers good full-text search utility.
 * You use this either as a Labelled-Property graph (using Gremlin) or an RDF
   graph (with SPARQL)
 * No query workbench/admin UI - you need to install your own 

Stardog [https://stardog.com]

 * Fully compliant with RDF/SPARQL standards;
 * Highly compliant and configurable OWL / RDFS backward-chaining reasoning
   (materialises inferred knowledge at query time);
 * Extremely fast online write times (due to backward-chaining model)
 * Adequate full-text-search capability using internal indexing
 * An outstanding SPARQL extension for PATH analysis (Pathfinder) - you can
   query for paths, shortest paths with weighted edges, normally only possible
   with labelled-property graphs
 * Geospatial querying and other extensions..
 * Rich visual query and management workbench UI

So you can see that each of these three are fully W3C compliant RDF / SPARQL
graph databases. But each has one or more killer features, that the others do
not. 

GraphDB - the post-inference connectors to ElasticSearch and MongoDB unlock some
outstanding technical and data architecture patterns out of the box -UPDATED May
2022 - GraphDB now also has comprehensive Path query capability using sparql
extension plugin

Stardog - combines the semantics of RDF with sophisticated Path querying and
analysis.

Neptune - fully managed cloud service with unparalleled horizontal scalability,
but no reasoning.

The upshot - choose wisely based on your requirements now, and what is likely to
matter most in the medium term.

..and then enter stage right, GraphQL

Sausage and Mash or Pineapple on Pizza ?
How do GraphQL and Graph Databases fit together? As we learned earlier, GraphQL
is a REST API alternative with a structured query language combined with a
runtime for query processing and serving data to GraphQL clients (and it is
almost always implemented with JSON in mind).

So why are Graph Database vendors getting involved and what do you get for your
money?

The cynical marketer in me says those 5 latin characters definitely count for
something. Which sales manager wouldn’t love the potential energy pressure in
the ready-to-explode singularity of Graph Databases and GraphQL (while humming
‘Don’t stop me now’).

However, GraphQL does only provide another query mechanism for your graph
database alongside SPARQL or Gremlin.  Moreover it is much less expressive, and
most definitely not designed for exploiting the rich semantics of RDF and OWL. 

In fact if you go all in on a michelin-starred Graph Database, and only use
GraphQL to query it, I would argue you really probably don’t need a Graph
Database - a NOSQL JSON store would probably suffice. Of course, if you have
forward-chaining inference in your graph database (as with GraphDB), then your
GraphQL queries will benefit from the RDFS/OWL semantics you have modelled your
data with, which does add weight to the value-proposition.

Still hungry ?
Ontologies are an important part of the picture. In the RDF world an ontology
semantically describes the model and nature of your domain, and ultimately the
data structures stored in your knowledge graphs, and if inference-aware, they
describe the meaning of the data, and how we reason upon it. Typically these
models are communicated up and down our tech stack (and the responsible
developers), and often all the way out to consumers of your APIs (public or
enterprise-internal).  While we typically move data around using JSON the
linked-data aficionados will know well that if we do this using JSON-LD, we can
use the same ontology models from the knowledge graph (or a subset) for
describing the JSON-LD payloads we ship around outside of our graph database.

So do we need GraphQL to take advantage of these ontological graph models ?.  No
we don’t, we can do it with normal REST APIs (querying our graph with SPARQL)
and using JSON-LD payloads - but of course we have to build more API code to do
this.

With GraphQL though we can (we must) formally describe our data structures as
GraphQL schemas, and so we have a great opportunity here to align our GraphQL
schemas with those same ontology models that describe the data in our knowledge
graph -  this could be either a subset of our ontology landscape, or possibly
the superset, if we are using other GraphQL (served) data sources aside from the
data in the graph database. This is starting to look like very nice decoupled
data architecture with well structured cohesive data models, with possibly the
most efficient mechanism for consuming data in our web/mobile applications (a
GraphQL client).

It is looking more tasty
Adding GraphQL client interfaces to a Graph Database does make life easier - if
you are rapidly prototyping straight from the graph, or federating data into an
external GraphQL server there is a nice pattern for making a common set of well
described data models.

The Graph Database vendors have indeed jumped on-board the GraphQL sushi train
(and it’s not all about those 5 latin characters). Stardog and GraphDB (from
Ontotext) both offer GraphQL clients now.

At this point I was going to show an example of how GraphQL might be used to
query a Graph Database, but Jem Rayfield at Ontotext has already done the job in
his superb Star Wars blog post
[https://www.ontotext.com/blog/the-rise-of-the-knowledge-graph/] (if you have
got this far, then this is a must read).

Ontotext has taken the next logical step and created a ‘Semantic Object Service’
 that automatically generates GraphQL schemas bound to the underlying RDF data
model  in GraphDB, moving us towards the ontology ubiquity I described above,
where your domain ontologies are expressed in the knowledge graph, and across
your wider data-estate, including your GraphQL schemas. Nice work.

Jem concludes by saying :

> GraphQL is a very popular graph query language, well used, known and liked by
developers. The Ontotext Platform uses GraphQL to lower the barrier of entry to
knowledge graph data, whilst still providing the full expressivity and power of
SPARQL.
and this is a key message, which equally applies to Stardog and any other graph
database that may yet offer a GraphQL client. While GraphQL lowers the barrier
to entry, GraphQL gives you only as much as it is able to with respect to
querying and graph traversal;  to really unlock the power of the graph database,
you will need to use SPARQL.

But if you never plan to, and you are not interested in reasoning either, then
possibly you should ask yourself if you really need a graph database ?

What if you want to use GraphQL as the primary API technology in your stack, but
want to use SPARQL too to access the graph database (amongst other tech)?

A mixed data technology case study
In a very recent engagement, the Data Language team have been working on a Smart
Cities IoT project. The nature of the domain meant the type of data we needed to
deal with was very ‘graphy’ in nature, and the ability to describe our data
semantically and traverse a graph with SPARQL was of high utility. Inference was
less of a concern. The proof of concept for the project was brought together in
AWS with :

 * AWS MSK - a high performance Kafka message bus to consume, orchestrate, and
   distribute IoT sensor events
 * AWS Neptune to give us our scalable RDF based smart city knowledge graph
 * A set of JSON-LD REST API endpoints invoking SPARQL queries on the graph
   running in Kubernetes (EKS)
 * A suite of Kafka event processor consumers and producers deployed into
   Kubernetes mutating the graph, and emitting new events based on our business
   logic rules.
 * AWS AppSync - the GraphQL engine sourcing events and the JSON-LD REST APIs
   from Neptune, providing the primary developer interface to our client
   applications
 * A ReactJS built UI using GraphQL react-hooks to subscribe to real time events
   data, and to query data from the sensors and our knowledge graph (ultimately
   via expressive SPARQL queries).

A simplified view of the architecture looks essentially like this :


The kicker was modeling data across the entire stack using a suite of
ontologies. These ontology models describe our knowledge graph data, our IoT
message payloads in JSON-LD and were all federated in the primary application
API expressed as GraphQL schemas in AppSync. Building the ReactJS front end
using the Apollo GraphQL client and react-hooks was a very nice developer
experience.

Dessert
While GraphQL technically has little to do with Graph Databases, they are not a
perfect match like sausages and mash, GraphQL is just another API / query
technology, and not as expressive as the native graph database query languages
like SPARQL, but in itself is a high-utlity, very sweet technology.

There are some clear synergies, and do provide some of that warm comfort food
feeling when used together. GraphQL does give you an easily understood and very
developer friendly way into a graph database. Once you add the secret sauce of
domain ontologies describing both your knowledge graph and possibly even your
entire data-estate, expressed through your GraphQL schemas, then you have a very
nice pattern for a decoupled data architecture with well structured, nicely
communicated data models across your technology stack, and out to your consumers
too - making for efficient application development using the GraphQL ecosystem.
Get stuck in.

Graph databases

Our Graph databases work

Graph databases Blog Posts