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