6 ms·

still many bridges too far to make it clear what connection these data models have to with what the rest of programmers do. i continue to believe theres a huge

still many bridges too far to make it clear what connection these data models have to with what the rest of programmers do. i continue to believe theres a huge amount of overlap, that these are not really different topics, but that there's some large gulf we have yet to see ourselves across. nice to see a survey, a broad examination, but still no real ground gained that i can see in doing the core thing: explaining how these semantic systems are just a re-expression of already familiar programming language systems (or otherwise unified).

dlahoda 5y ago
looks well written. may be good brain training.
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.
- 5y ago
mumblemumble 5y ago
There's a part of me that wonders if this was roughly how people originally responded to EF Codd's 1970 paper. You read it, and it all seems very abstract, and it's hard to understand why any of it would matter much to a programmer. But look at things the other way around: assume you're a late 20th or early 21st century developer who grew up with the relational model, and now you have to work with some 1960s-era data modeling technology such as COBOL. You'd probably find that certain things that were easy in a relational database are suddenly really, really hard with this other tech stack. And probably, when you try to explain this to colleagues who'd never worked in anything but COBOL, they would respond with something like, "It's not hard, all you have to do is [really fiddly, error-prone, and difficult-to-maintain design pattern]." It can be difficult to distinguish between difficulty that's inherent to the problem, and difficulty that's only due to limitations of the tools that you know. This is not by way of trying to imply that knowledge graphs are like the relational model in that they're definitely better than previous tech. But, assuming for the sake of argument that they do do some things better, perhaps they are like the relational model in that you need to spend a certain amount of hands-on time with them before their value becomes readily apparent.
- a1369209993 5y ago
  > perhaps they are like the relational model in that you need to spend a certain amount of hands-on time with them before their value becomes readily apparent. ... except they cannot possibly be like the relational model in that way, because the relational model isn't like that. The value of relational databases becomes readily apparent when you spend five minutes fiddling with a appropropiate small-but-nontrivial relational database; you do not need to spend a [nontrivial] amount of hands-on time with them before their value becomes readily apparent.
  - jackpirate 5y ago
    As someone who teaches python+sqlite in an intro to cs course, I can't disagree with this statement more.
  - sjg007 5y ago
    SQL is amazing but the mental model beyond inner joins is not at all obvious. Things like outer joins (and when you need them), aggregation, partitioning etc... I am sure I've missed a few things. But SQL is absolutely amazing. You have to understand the data and the relations, what's not in the data that you'd expect to be etc...

dlahoda 5y ago

looks well written. may be good brain training.

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.
5y ago

mumblemumble 5y ago

There's a part of me that wonders if this was roughly how people originally responded to EF Codd's 1970 paper. You read it, and it all seems very abstract, and it's hard to understand why any of it would matter much to a programmer. But look at things the other way around: assume you're a late 20th or early 21st century developer who grew up with the relational model, and now you have to work with some 1960s-era data modeling technology such as COBOL. You'd probably find that certain things that were easy in a relational database are suddenly really, really hard with this other tech stack. And probably, when you try to explain this to colleagues who'd never worked in anything but COBOL, they would respond with something like, "It's not hard, all you have to do is [really fiddly, error-prone, and difficult-to-maintain design pattern]." It can be difficult to distinguish between difficulty that's inherent to the problem, and difficulty that's only due to limitations of the tools that you know. This is not by way of trying to imply that knowledge graphs are like the relational model in that they're definitely better than previous tech. But, assuming for the sake of argument that they do do some things better, perhaps they are like the relational model in that you need to spend a certain amount of hands-on time with them before their value becomes readily apparent.

a1369209993 5y ago
> perhaps they are like the relational model in that you need to spend a certain amount of hands-on time with them before their value becomes readily apparent. ... except they cannot possibly be like the relational model in that way, because the relational model isn't like that. The value of relational databases becomes readily apparent when you spend five minutes fiddling with a appropropiate small-but-nontrivial relational database; you do not need to spend a [nontrivial] amount of hands-on time with them before their value becomes readily apparent.
- jackpirate 5y ago
  As someone who teaches python+sqlite in an intro to cs course, I can't disagree with this statement more.
- sjg007 5y ago
  SQL is amazing but the mental model beyond inner joins is not at all obvious. Things like outer joins (and when you need them), aggregation, partitioning etc... I am sure I've missed a few things. But SQL is absolutely amazing. You have to understand the data and the relations, what's not in the data that you'd expect to be etc...