[Thoughts on what to do if there is an ontological mismatch between one’s thinking and a tool]
When I saw Jacob present a version of the OP in person, the discussion focused on cases where the correct response is to use a different tool, ideally one that matches the natural ontology of ones thinking. E.g. when using a whiteboard rather than a Google doc to express thoughts most naturally expressed as a mind map.
But I think it’s important that there are other cases where it can actually beneficial to ‘learn how to think in a different ontology’. I think this is quite common in pure maths, but also shows up in more everyday situations: e.g. initially I found it quite counterintuitive to use, say, Emacs org mode or LaTeX, but after I had payed the fixed cost of adapting to the ontologies imposed by them I actually think that it made me more efficient at some tasks.
Similarly, I think it’s useful to be able to translate between different ontologies. To learn this, it can be useful to deliberately expose oneself to ontologies that seem unnatural/bad/cumbersome initially.
I think it’s useful to be able to translate between different ontologies
This is one thing that is done very well by apps like Airtable and Notion, in terms of allowing you to show the same content in different ontologies (table / kanban board / list / calendar / pinterest-style mood board).
Similarly, when you’re using Roam for documents, you don’t have to decide upfront “Do I want to have high-level bullet-points for team members, or for projects?“. The ability to embed text blocks in different places means you can change to another ontology quite seamlessly later, while preserving the same content.
Ozzie Gooen pointed out to me that this is perhaps an abuse of terminology, since “the semantic data is the same, and that typically when ‘ontology’ is used for code environments, it describes what the data means, not how it’s displayed.”
I think in response, the thing I’m pointing at that seems interesting is that there is a bit of a continuum between different displays and different semantic data — two “displays” which are easily interchangeable in Roam will not be in Docs or Workflowy, as they lack the “embed bullet-point” functionality. Even though superficially they’re both just bullet-point lists.
[Thoughts on what to do if there is an ontological mismatch between one’s thinking and a tool]
When I saw Jacob present a version of the OP in person, the discussion focused on cases where the correct response is to use a different tool, ideally one that matches the natural ontology of ones thinking. E.g. when using a whiteboard rather than a Google doc to express thoughts most naturally expressed as a mind map.
But I think it’s important that there are other cases where it can actually beneficial to ‘learn how to think in a different ontology’. I think this is quite common in pure maths, but also shows up in more everyday situations: e.g. initially I found it quite counterintuitive to use, say, Emacs org mode or LaTeX, but after I had payed the fixed cost of adapting to the ontologies imposed by them I actually think that it made me more efficient at some tasks.
Similarly, I think it’s useful to be able to translate between different ontologies. To learn this, it can be useful to deliberately expose oneself to ontologies that seem unnatural/bad/cumbersome initially.
This is one thing that is done very well by apps like Airtable and Notion, in terms of allowing you to show the same content in different ontologies (table / kanban board / list / calendar / pinterest-style mood board).
Similarly, when you’re using Roam for documents, you don’t have to decide upfront “Do I want to have high-level bullet-points for team members, or for projects?“. The ability to embed text blocks in different places means you can change to another ontology quite seamlessly later, while preserving the same content.
Ozzie Gooen pointed out to me that this is perhaps an abuse of terminology, since “the semantic data is the same, and that typically when ‘ontology’ is used for code environments, it describes what the data means, not how it’s displayed.”
I think in response, the thing I’m pointing at that seems interesting is that there is a bit of a continuum between different displays and different semantic data — two “displays” which are easily interchangeable in Roam will not be in Docs or Workflowy, as they lack the “embed bullet-point” functionality. Even though superficially they’re both just bullet-point lists.