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 …
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!
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!