Temporal Linked Data® (TLD) and TigerGraph’s Labeled Property Graph third-generation graph database have different purposes and so the schemas have slightly different structures.  In this TigerGraph schema image you can see that all aggregate vertices have a corresponding change vertex.  The attributes in the debit_credit_change vertex are also shown for example sake.

 

Temporal Linked Data® Agile Gamification example in TigerGraph (Image credit: TigerGraph Graph Studio)

 

Where TLD keeps changes sparse (only what has changed) as an ordered collection with the aggregate (vertex) to which it belongs, we have modeled our TigerGraph schema to have a “changes” edge between the aggregate vertex and its’ changes vertices.  Each change that is published to TigerGraph results in a new edge and change vertex associated with the aggregate, where the aggregate simply reflects the current state.

 

TigerGraph is built to perform deep analysis across many “hops” (physical edges between vertices).  Writing graph queries against this schema with ten aggregate vertices and their corresponding 10 change vertices is light work for TigerGraph.  Example analytic queries might include:

 

For a game, which individual has the highest score?  This query does not require any temporal data as the debit_credit aggregate keeps a running tally.  There are five hops between: game, gameledger, debit_credit, account, and individual.  

 

For a game, which individual has received the most positive comments from one’s colleagues?  This query requires the temporal data in debit_credit_change but is easily satisfied.  There are six hops to answer this query.  

 

For a game, which individual has been the most helpful to their colleagues?  Given the autogenerated events and specific collegial input, this query is easily satisfied with the same six hops.  

 

There are nearly two dozen analytic queries that could be discussed here and all but two of them require temporal data.  Something to think about. 

 

All two dozen analytic queries are available for realtime display on an operational dashboard as they perform efficiently and execute in a few milliseconds (many-hop analytic queries executed as often as you like for full participation in your operational system—that’s HTAP by way of TLD).

 

 

The Earth’s state as planet Theia collides to form our moon—temporal data tells a very interesting story. (Image credit: NASA)

 

Next we will look at the value of temporal data, both transactionally and analytically.

 

Comments

Share on activity feed

Powered by WP LinkPress

The creation of something meaningful requires understanding.  The building blocks of understanding is a vocabulary.  Rigorous vocabularies can be parsed and “understood” by a computer.  Programming languages represent this kind of rigor.  The W3C’s Resource Description Framework and related specifications also represents this kind of rigor.  

 

Hybrid Transactional / Analytic Processing (HTAP) backend by way of Temporal Linked Data® (TLD) is generated from vocabularies defined by RDF that are created using a very straightforward, approachable, and discrete technique.

 

In the same way that Tim Berners-Lee’s Semantic Web is able to leverage daemons and agents to “understand” and modify the public “data web” based on RDF and web architecture, we are able to generate:

 

  • REST API with JSON payloads;
  • BEAM modules for high-throughput, low-latency, reliable, concurrent, supervised transactional data processing;
  • Discrete, localized capture of who changed what and when associated with all TLD aggregates;
  • Automated, configured projections to scale-out to third-generation graph databases, such as TigerGraph, for realtime and longitudinal analytics;
  • As well as projections to RDF-based, Enterprise Knowledge Graph platforms, such as ReactiveCore’s rule-based inferencing and analytics.

 

The purpose of our auto-generated backend is to provide: 1) a domain-specific reference implementation, 2) written in Elixir, 3) packaged in docker containers for container orchestration, 4) deployable as an elastic, reactive compute grid, 5) executed in clustered BEAM VMs, 6) backed by BEAM ecosystem for dynamic temporal data structure persistence, and 7) projection to a world class graph analytics platform.

 

If you are new to Elixir or Phoenix Framework applications, TLD can serve as your working example from which to extrapolate and grow.  

 

If you are “the business” and simply interested in time to value, TLD can serve as: 1) your spike to flesh out a business concept, 2) your proof-of-concept to win mindshare among colleagues, 3) your pilot to demonstrate short time with high quality to production, and 4) your strategy for coherent business-driven continuous deployment.

 

If you are an old hand at Elixir and the established BEAM ecosystem, TLD can be your collaborator that allows you to focus on business concerns and modeling rather than software development.

 

A perfect solar eclipse. Patterns in nature allow us to study creation, make observations, validate hypothesis, develop models and the vocabulary that describes them.

 

The next post will provide an example of Temporal Linked Data® as TigerGraph schema for our Agile Gamification example.

Comments

Share on activity feed

Powered by WP LinkPress