The real world, and therefore real world data and associated relationships, are inherently “graphy”. By “graphy” I mean that in addition to having attributes and associated values, various data elements are interrelated in complex webs of relationships based on various contexts. For example, a person may have attributes like name, age, address, etc. and may be part of multiple, potentially overlapping sets of relationships in different contexts such as family, work, hobby, sports team, neighborhood, etc. Indeed, it is the very diverse and complex nature of the relationships between different data entities that lends credibility to my assertion.
While traditionally we may have thought of data in tabular form (relational database style), the reality is that even then we were also often concerned not only with rows and columns of the tables but relationships between tables and between rows and columns of different tables. The graph of relationships is there whether we explicitly recognize it or not.
If the questions being asked match the table structure (or schema) then the analysis effort can be relatively straightforward. More typically, to draw insights data analysts must join the tabular data from disparate sources and perform quite complicated maneuvers to be able to arrive at the answers they seek. Their ability to easily answer questions based on the data is adversely impacted by the, necessarily up-front, table design. My point is not that one cannot get the answer without graphs but rather about the extent to which one must go from a query design (not to mention debugging) perspective, about the ease of adaptation to new queries, and about computational efficiency. An approach that is flexible, can readily incorporate new data and new relationships, and easily support a wider range of questions is desirable. The use of knowledge graphs to model the relationships is such an approach. Its properties and attractions are well documented and I will not go into them here. Suffice to say, knowledge graphs mimic real world data relationships and support advanced analytics requirements.
We see this new graphy reality showing up in vendors’ approach to analytics, including digital twins, with the adoption of graph databases like Neo4j and the adoption of knowledge graphs. For example, AWS and Microsoft both incorporate a graph-based approach in their digital twin offerings (I added the emphasis):
While it’s great to see graph approaches becoming more mainstream, building (and maintaining) effective digital twin data models, like many worthwhile endeavors, is no walk in the park. Enterprise data is complicated, industrial enterprise data even more so. The dynamic nature (as a result of evolutions in the deployed plant and in corporate structure (due to mergers and acquisitions, etc.)) requires considerable effort to be spent in keeping the data world in order. Two of the three key challenges faced in building digital twins (the third one being visualization) relate to establishing and maintaining the underlying knowledge graphs:
Unify Graph brings a knowledge graph approach to bear for mapping the complex data environments typical at most enterprises that data teams must operate across. It allows flexible data modeling spanning arbitrary dimensions such as processes, assets, organizations, etc. necessary for quickly building effective digital twins. With Unify Graph Element customers can more easily adopt a “think big, start small, scale fast” approach by starting small and flexibly and incrementally adding more as their needs call for, building upon existing work. The graphs can be queried and explored within Unify or exported for consumption by graph database products such as AWS Neptune or Neo4j. I cover Unify Graph in a little more detail in a separate post.
Already curious about Element Unify’s graph chops to help you with building digital twins? Reach out for a discussion.
Questions? Please contact us.