Build Knowledge Graphs With ApertureDB
In our daily life, we very often create associations in our mind among objects we see, events we are part of, people we meet, workplaces. Imagine if all of those entities or concepts were represented as dots, nodes, or vertices with labels and potentially attributes that we know about those (e.g. name of a Person, company headquarter, brand of a Product). The associations that we are aware of, would be directed connections or edges among those dots or nodes, with their own labels and attributes (e.g. Person-WorksAt->Organization with an attribute since 2020), forming a directed, labeled graph. This is essentially a knowledge graph.
Knowledge graphs can be represented in software using triple stores or property graphs and the schema provides insights into the type of nodes and edges, their attributes, types, indexes, and so on, like any other database does. ApertureDB offers a property graph database for users to create the nodes, edges, labels, and attributes required to build a knowledge graph. Creating knowledge graph is typically an ongoing process since the information (knowledge base) in an organization is always evolving. It is possibles now to take a lot of existing data and generate entities and their relationships (e.g. named entity recognition) with large language models, but that can be expensive to execute all the time and would leave some existing metadata out of the graph.
Below we share some application-based examples of creating schema in a graph database which eventually can be used to analyze and filter over any knowledge base.
You can also create your own graph with our cookbook dataset
Graph Metadata Schema
The ApertureDB Query Language provides a way to add application-specific and ApertureDB recognized entities or more generally, Objects, along with their relationship (or Connections) with each other. It is important to remark that no schema declaration is needed upfront.
The schema in ApertureDB is:
- Application-dependent,
- Can evolve over time,
- Has representations for native objects like Images, Videos, and others,
- Can contain as many Connections with their own names and properties among these objects.
For example, if we are building a visual pipeline for a retail store that will analyze customer behavior, one could imagine entities like Customer, Object or Item to purchase, Department, and Employee. In addition, there could also be more conceptual entities like a Visit to indicate a customer's visit to the store, a feature vector representing a customer's features to enable in person reID, the actual video snippets captured by cameras, and so on. Each of these entities could, in turn, have their own properties, either known at the start of the application or added over time. For example, a department could have a name, information about its physical location in the store, camera(s) installed overhead, and other things like description. An object could have an RFID tag associated with it, a type indicating whether it is a ketchup bottle or towel and so on.
ApertureDB implements a property graph data model. As explained in this article, think of entities like tables in a relational database world and relationships among them as tables with foreign key associations. The key-value properties in each entity or relationship are similar to column names and their values in a relational table. However, the graph model makes it very easy to evolve the schema as the application evolves and allows us to support complex keyword based as well as graph traversal based searches.
By default, we already introduce entities in the graph representing all the native objects like images and videos (all objects). We also create some default connections such as a connection between a Descriptor and DescriptorSet.
Here is an example of what a schema would conceptually look like in a "Analytics for Retail" use case:
As the application evolves, we could introduce new information in this metadata like color of a product, or the number of times it was picked up.
Here is another example of a schema in case of a visual or industrial inspection application.
Typically we work with our users to get them started with a schema based on the queries and data that will be supported by ApertureDB.
Like a lot of other databases, ApertureDB uses indexes (learn more) to speed up query execution. Indexes should be defined on any key-value properties for objects or connections that will be used for querying.