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