KnowledgeGraphs and Graph Databases
Extracting Context from Graph Databases
When we use something like ConnectedPapers, we can almost sort of start to get an idea of what is meant by concept of knowledgeGraphs which use a graph-structured data model or topology to represent data. KnowledgeGraphs are often used to store interlinked descriptions of entities, objects, events, situations or abstract concepts while also encoding the semantics or relationships underlying these entities.
A graph database is used knowledge engineering because we want all of the internetworked computing systems available for us to use to be ready to more efficiently, more rapidly perform operations on that graph data model. We want process groups of different datasets into what may be useful information and then further on to furnishing a larger sense of context so that the information can be utilized as actionable knowledge or a plan for attacking some sort of problem on its terrain.
> We can think of a data point as being a single measurement or even several observations of single variable, such as body temperature or blood glucose readings. Information is a collection of data points that change our understanding of a situation or a process, eg it's not really information to know that a typical human's expected body temperature is 98.6F -- it IS information to know that a specific human's body temperature over the last several years has ranged between 98.0 and 99.0 F, with an average of 98.5 and NOW her temperature is 100.3. Knowledge is information that has been contextualized and is actionable -- if we interview our patient and find that she was late to her appointment, even though the AC in her car wasn't working, she still ran through the parking lot so she wouldn't miss her appointment, the ***knowledgeable*** action might be to *just chill out and relax while the* ***knowledgeable*** doctor sees another patient, but we'll take another reading in 30 minutes and see if it's approaching a normal reading. In our modern lives, it's not just that we are drowning in data points; we are also constantly bombarded by information which is probably correct, but we don't really understand its full context ... information overload and impertinent [but probably true] information is what information wars and disruptive tactics used by *active measures* campaigns are all about. Thus, ***knowledge*** is really about understanding what to information to focus on, what information to underweight or tune out and why we adjust our focus, whereas information that repeats what we already know is not really information [unless we really had a solid reason to doubt what we knew], but rather ***information*** is about a change from our prior belief.
Graph databases are commonly referred to as a NOSQL approach to database design, which should correctly be thought of as “NOT ONLY SQL” to emphasize that these databases often support SQL-like query languages and operate alongside many other reused, upcycled or even repurposed SQL databases in polyglot-persistent architectures. Therefore, although in theory we could think of starting from scratch and using a graph database to store all of our data … in actual practice, a graph database is often used to aid in the data wrangling or [data re-engineering](https://en.wikipedia.org/wiki/Data_engineering] process to better enable subsequent data analysis, data science and knowledge engineering to advance the development and maintenance, ie implementing code to realize changes in the initial development vision, of knowledge-based systems and inference engines.