Everything is a Node in FactEngine, bar Edges

In defense of graphs within graphs — and/or hypergraphs

For those of you familiar with FactEngine Query Language (FEQL), you may have noticed that every piece of data is considered as if it were a node in a graph database. Take the following FEQL query for instance:

The FEQL query is asking to show a list of employees that are based in the country, UK, from the underlying database.

But do we know whether ‘Country’ is a table in a relational database, or a node type in a graph database or a column in a relational database or a property in a graph database?

We don’t, and for the large part we do not really care, other than that it pays to be aware of the underlying data model in the database, unless we query some sort of vector database or neural database devoid of an underlying schema.

I.e. FactEngine Query Language is, in some respects, schema/database agnostic, until such time that a query must be written in the underlying database query language (SQL, Cypher, TypeQL, other).

The realities are though, that unless working with a vector or neural database over unstructured data it pays to be aware of the underlying schema.

Let us take the Northwind database from Microsoft. Here is the property graph schema for Northwind:

Property Graph Scema for the Northwind database. Image by author.

NB It becomes a Property Graph Schema in a real sense, when we show the Properties for a Node Type. E.g. The Employee node type:

Note that there is no ‘Country’ node type in the property graph schema, but there is a property, ‘Country’, against the Employee node type.

We get a feel for how FactEngine and the FactEngine query language work, when we consider the following FEQL query and the corresponding Object-Role Model (ORM) that defines the properties, FirstName, LastName, and Country on the Entity node type:

NB We want to know if the employee, Nancy Davolio, is based in the USA:

Object-Role Model. Image by author.