5 ms·

Taking these concepts and trying to tie them back into what programmers do, so that the experience of building a knowledge graph database is not alien is essent

by LukeEF 5y ago

Taking these concepts and trying to tie them back into what programmers do, so that the experience of building a knowledge graph database is not alien is essential if this is going to become mainstream tech. We[1] started building with OWL, the web ontology language, to represent the shape of the graph. This made sense because OWL is a very rich language for describing graphs. However it also has drawbacks. It is very hard - and alien to common experience - for developers to read OWL. It was not built to describe schemata but rather ontologies (to describe what could be represented, rather than what must be represented). It also had no concept of a document, and as we were trying to build a document-oriented knowledge graph, we had to graft one onto it, which became a source of confusion for our users. Eventually - with much pain and time - we decided to simplify the interface, make the concept of the document more central, make the primary interaction method be through json documents and create a schema language that looks like the JSON you hope to build (and feels more like one you might write in a programming language). It is early days for the relaunched version (and we had to swallow the frustration of such a deep breaking change), but it certainly feels like regular programmers are now able to quickly build knowledge graphs. The combination of graph, schema, and document is powerful. [1] https://github.com/terminusdb/terminusdb https://github.com/terminusdb/terminusdb

musingsole 5y ago
> tie them back into what programmers do While the technology is built on the back of what programmers do, there is nothing inherent to knowledge graphs that imply that building them is a programmer's task. It's very possible that that task and responsibility falls to someone else and programmers are left building the interface and access portal to a tool used by a different specialization. Why do programmers want to do everything?
- PaulHoule 5y ago
  Because other people don't want to. Like Barbie said in the 1980s, "Math is Hard".
  - musingsole 5y ago
    Agreed. Programmers don't like math either. And because of that, this task that is specialized business domain system building is likely to be given to specialists -- not programmers. It lives in the data science/business/logistics analysts space. The whole point of this type of systems analysis is to be able to lift and shift the task from a group of people who can but also don't want to do it to a smaller group of people who have chosen and specialized to do it.
    - katsi111 5y ago
      My experience is that programmers (if you can generalise them like this) breath a sigh of relief when I as an ontologist (someone who builds knowledge graphs and makes sure that they are logically sound) tell them that I will work with domain experts to get their knowledge into a structured form that the programmers then may consume programmatically.
- LukeEF 5y ago
  Mostly the ability to think in abstractions and imagine what might be technically possible! Certainly not exclusive to programmers but more density there.
PaulHoule 5y ago
It's a tough operational problem for knowledge graphs to know where updating starts and ends. For instance you might put a "record" into a knowledge graph that describes some topic like https://www.wikidata.org/wiki/Q108937326 https://www.wikidata.org/wiki/Q108937326 and then later decide to delete it. The "record" consists of not just the ?s ?p ?o patterns such that ?s == https://www.wikidata.org/wiki/Q108937326 but also other patterns that involve "blank nodes" that are necessary to make statements that go beyond what a single triple can express. You can reconstitute the relational database without "rows" (e.g. turn a relational database into a graph and do OWL inference on that graph, or run SQL queries against a database with a columnar organization) but the row concept, like the document concept in document-oriented databases provides a boundary for updating records that (mostly) works even in the absence of transactional semantics. Many of the older approaches to implementing transactions were row-centric, although newer MVCC approaches apply just fine to graph systems.
- LukeEF 5y ago
  We have a immutable chain structure in TerminusDB which allows for straightforward uncoordinated multi-read access or multi-version concurrency control. This approach also makes branching simple to implement. Any number of new layers can point to the same former parent layer. You might like this white paper (but for reasons above you will have to overlook some of the OWL information): https://github.com/terminusdb/terminusdb/blob/dev/docs/whitepaper/terminusdb.pdf https://github.com/terminusdb/terminusdb/blob/dev/docs/white...

by LukeEF 5y ago

musingsole 5y ago

> tie them back into what programmers do While the technology is built on the back of what programmers do, there is nothing inherent to knowledge graphs that imply that building them is a programmer's task. It's very possible that that task and responsibility falls to someone else and programmers are left building the interface and access portal to a tool used by a different specialization. Why do programmers want to do everything?

PaulHoule 5y ago
Because other people don't want to. Like Barbie said in the 1980s, "Math is Hard".
- musingsole 5y ago
  Agreed. Programmers don't like math either. And because of that, this task that is specialized business domain system building is likely to be given to specialists -- not programmers. It lives in the data science/business/logistics analysts space. The whole point of this type of systems analysis is to be able to lift and shift the task from a group of people who can but also don't want to do it to a smaller group of people who have chosen and specialized to do it.
  - katsi111 5y ago
    My experience is that programmers (if you can generalise them like this) breath a sigh of relief when I as an ontologist (someone who builds knowledge graphs and makes sure that they are logically sound) tell them that I will work with domain experts to get their knowledge into a structured form that the programmers then may consume programmatically.
LukeEF 5y ago
Mostly the ability to think in abstractions and imagine what might be technically possible! Certainly not exclusive to programmers but more density there.

PaulHoule 5y ago

It's a tough operational problem for knowledge graphs to know where updating starts and ends. For instance you might put a "record" into a knowledge graph that describes some topic like https://www.wikidata.org/wiki/Q108937326 https://www.wikidata.org/wiki/Q108937326 and then later decide to delete it. The "record" consists of not just the ?s ?p ?o patterns such that ?s == https://www.wikidata.org/wiki/Q108937326 but also other patterns that involve "blank nodes" that are necessary to make statements that go beyond what a single triple can express. You can reconstitute the relational database without "rows" (e.g. turn a relational database into a graph and do OWL inference on that graph, or run SQL queries against a database with a columnar organization) but the row concept, like the document concept in document-oriented databases provides a boundary for updating records that (mostly) works even in the absence of transactional semantics. Many of the older approaches to implementing transactions were row-centric, although newer MVCC approaches apply just fine to graph systems.

LukeEF 5y ago
We have a immutable chain structure in TerminusDB which allows for straightforward uncoordinated multi-read access or multi-version concurrency control. This approach also makes branching simple to implement. Any number of new layers can point to the same former parent layer. You might like this white paper (but for reasons above you will have to overlook some of the OWL information): https://github.com/terminusdb/terminusdb/blob/dev/docs/whitepaper/terminusdb.pdf https://github.com/terminusdb/terminusdb/blob/dev/docs/white...