Thank you so much for this article. You make very persuasive arguments firstly for developing one’s PKB around an ontology and secondly for leveraging external ontologies like Wikidata. I have been using Roam for a while now and what you have demonstrated looks very effective. I also went on to read some articles by Ivo Velitchkov and no…
Thank you so much for this article. You make very persuasive arguments firstly for developing one’s PKB around an ontology and secondly for leveraging external ontologies like Wikidata. I have been using Roam for a while now and what you have demonstrated looks very effective. I also went on to read some articles by Ivo Velitchkov and now I am wondering how deep to go with all of this.
I wondered if you had any thoughts about:
Whether it is useful (and feasible) to maintain a personal ontology which could be used across multiple PKB (either in different platforms, or even the same platform but as different databases - as Roam has no or limited ability to share links across graphs for the same user).
Whether your method is doable with Heptabase (I read your review of that and consequently am trying it out long term).
I am a big fan of using ontologies. It's always a balancing act, how complex you make them, and the danger of doing it as a science of its own. That was one of the reasons for choosing Wikidata as the basis. Intelligent people have already put a lot of thought into it. I use a sub-set that suits me and expand it as required (also individually). I use fallbacks so that no chaos breaks out if I still need to fill attributes (e.g., a default #draft tag).
The ontology principle is particularly effective with Heptabase, surpassing even Roam, as Heptabase now supports relations based on tags. This means that the author of a book is defined as a relation to the tag 'person,' and when filled in, only those links created as 'person' are displayed. Tana and Remnote are also excellent apps for ontology-based approaches, but I will delve into this in more detail in future articles, sparking your curiosity and interest.
I hope this has helped you a little; otherwise, feel free to ask. I am very happy to exchange ideas with my readers.
Thanks for the reply, I’m encouraged by your view on Heptabase. I noticed that approach to tags. My only concern is that the more I make use of these advanced features, the more locked in I am. Just got to have a bit of faith and go for it rather than be paralysed with designing the perfect structure from the start.
Heptabase exports its properties in yaml frontmatter to markdown. This is a clear text format that is also understood by other apps (e.g., Obsidian) and that could be easily transformed using simple scripts if switching to another app.
The best advice I can give you is start small but start and do it with examples of your real day to day need (e.g., a #meeting note needs attendees, a project it belongs to and date). So you have started with three classes (tags). For #meeting you have defined to relations to other tags (attendees to #person, and project to #project) as well as one date property.
I have around 30 classes and rarely more than a handful of properties per class. Additionally I love to think of process chains to define my ontology. #humans organized in #teams do #work to get #results, #question leads to #hypothesis and #evidence to #insight...
When setting up a tag (to be a class in my ontology for HB), it does not seem possible to document directly against that tag, any ontology-related information such as "subclass" and same as". This is because tags do not exist as a page in their own right as in Roam.
I think the way to maintain the ontology along your lines is to create a card for each class and property (as per the Roam method), which I then tag with #ontology and add the properties.
One such property would be a link to the tag as implemented in HB. Ideally it would be the actual tag rather than just its name, but unless I am missing something, in tag tables there does not seem to be access to other tags or cards, in contrast to Roam where the square brackets bring up any page in the graph. You can only enter a value for a property or select from previously entered values. Maybe this is a design choice because cards can be so easily deleted. Or maybe it is on the roadmap, or could be added to the roadmap.
This last point has me wondering whether tags are really the way to support an ontology in HB, because the properties cannot be linked to what you have already mapped out.
Alternatively you could still use inline @mentions of the ontology cards, which looks more like the Roam approach (although you wouldn't get the benefits from setting up as Roam attributes) and keep tags only for major classification and tracking purposes.
I might ask the HB team about this on their Discord. Perhaps I am overthinking the issue, especially if there are not that many classes and properties. What are your thoughts?
EDIT: I now see that in the tag table, you can create a new property with type "relation" in which you can specify another tag. I will see whether this addresses some of the issue.
I was just starting to write about the new relation property but you already found it. I really think that this is a big help in implementing a useful ontology. I also collect all instances of classes of my ontology under the tag #instance. That allows me to additionally have on big table of all "classified documents" in one big filterable and sortable table showing all common used properties (like description, keywords, ...). So if I search for something like science fiction I get to that list, filter for keyword science fiction and get books, films, papers and games for it.
Ha! Yes I also had thought of using a generic instance tag where you could say what is the class (or even multiple classes). Good idea to include properties also.
I decided in the end to create a Heptabase tag for each class, with initial properties in its tag table (which can be shared between tags). I then tick off my "has tag" property for that class's card in Heptabase. The "relation" type of property would allow me to access all cards having a particular tag, but not the list of tags. My convention is that the tag will have the same name as the class anyway.
If the volume of classes and tags grows too much, I will try the tag groupings.
Maybe this is overkill but I will see how I get on with it. Let's just say I was persuaded by your structured approach!
Thank you so much for this article. You make very persuasive arguments firstly for developing one’s PKB around an ontology and secondly for leveraging external ontologies like Wikidata. I have been using Roam for a while now and what you have demonstrated looks very effective. I also went on to read some articles by Ivo Velitchkov and now I am wondering how deep to go with all of this.
I wondered if you had any thoughts about:
Whether it is useful (and feasible) to maintain a personal ontology which could be used across multiple PKB (either in different platforms, or even the same platform but as different databases - as Roam has no or limited ability to share links across graphs for the same user).
Whether your method is doable with Heptabase (I read your review of that and consequently am trying it out long term).
I am a big fan of using ontologies. It's always a balancing act, how complex you make them, and the danger of doing it as a science of its own. That was one of the reasons for choosing Wikidata as the basis. Intelligent people have already put a lot of thought into it. I use a sub-set that suits me and expand it as required (also individually). I use fallbacks so that no chaos breaks out if I still need to fill attributes (e.g., a default #draft tag).
The ontology principle is particularly effective with Heptabase, surpassing even Roam, as Heptabase now supports relations based on tags. This means that the author of a book is defined as a relation to the tag 'person,' and when filled in, only those links created as 'person' are displayed. Tana and Remnote are also excellent apps for ontology-based approaches, but I will delve into this in more detail in future articles, sparking your curiosity and interest.
I hope this has helped you a little; otherwise, feel free to ask. I am very happy to exchange ideas with my readers.
Thanks for the reply, I’m encouraged by your view on Heptabase. I noticed that approach to tags. My only concern is that the more I make use of these advanced features, the more locked in I am. Just got to have a bit of faith and go for it rather than be paralysed with designing the perfect structure from the start.
Heptabase exports its properties in yaml frontmatter to markdown. This is a clear text format that is also understood by other apps (e.g., Obsidian) and that could be easily transformed using simple scripts if switching to another app.
The best advice I can give you is start small but start and do it with examples of your real day to day need (e.g., a #meeting note needs attendees, a project it belongs to and date). So you have started with three classes (tags). For #meeting you have defined to relations to other tags (attendees to #person, and project to #project) as well as one date property.
I have around 30 classes and rarely more than a handful of properties per class. Additionally I love to think of process chains to define my ontology. #humans organized in #teams do #work to get #results, #question leads to #hypothesis and #evidence to #insight...
Technical queries on Heptabase:
When setting up a tag (to be a class in my ontology for HB), it does not seem possible to document directly against that tag, any ontology-related information such as "subclass" and same as". This is because tags do not exist as a page in their own right as in Roam.
I think the way to maintain the ontology along your lines is to create a card for each class and property (as per the Roam method), which I then tag with #ontology and add the properties.
One such property would be a link to the tag as implemented in HB. Ideally it would be the actual tag rather than just its name, but unless I am missing something, in tag tables there does not seem to be access to other tags or cards, in contrast to Roam where the square brackets bring up any page in the graph. You can only enter a value for a property or select from previously entered values. Maybe this is a design choice because cards can be so easily deleted. Or maybe it is on the roadmap, or could be added to the roadmap.
This last point has me wondering whether tags are really the way to support an ontology in HB, because the properties cannot be linked to what you have already mapped out.
Alternatively you could still use inline @mentions of the ontology cards, which looks more like the Roam approach (although you wouldn't get the benefits from setting up as Roam attributes) and keep tags only for major classification and tracking purposes.
I might ask the HB team about this on their Discord. Perhaps I am overthinking the issue, especially if there are not that many classes and properties. What are your thoughts?
EDIT: I now see that in the tag table, you can create a new property with type "relation" in which you can specify another tag. I will see whether this addresses some of the issue.
I was just starting to write about the new relation property but you already found it. I really think that this is a big help in implementing a useful ontology. I also collect all instances of classes of my ontology under the tag #instance. That allows me to additionally have on big table of all "classified documents" in one big filterable and sortable table showing all common used properties (like description, keywords, ...). So if I search for something like science fiction I get to that list, filter for keyword science fiction and get books, films, papers and games for it.
Ha! Yes I also had thought of using a generic instance tag where you could say what is the class (or even multiple classes). Good idea to include properties also.
I decided in the end to create a Heptabase tag for each class, with initial properties in its tag table (which can be shared between tags). I then tick off my "has tag" property for that class's card in Heptabase. The "relation" type of property would allow me to access all cards having a particular tag, but not the list of tags. My convention is that the tag will have the same name as the class anyway.
If the volume of classes and tags grows too much, I will try the tag groupings.
Maybe this is overkill but I will see how I get on with it. Let's just say I was persuaded by your structured approach!