Anytype’s idea of having types, objects, relations metaphor to model data is certainly new in Note taking apps. Since types are used to model real world entity, it would be great to have subtypes which would help Anytypers to model and group real world data in a much more understandable manner.
Here is an example of where such feature would help the user to better structure their data:
Say a user has a type named Animal. The animal type would contain common relations belonging to all animals such as a relation to specify whether it is Marine / Land animal, another to specify Carnivore, Herbivore, Lifespan, etc. Now if a user wants to create a set of dogs, he would need to create another type named Dog and duplicate the same relations again and add additional relations specific to a dog. Having a subtype feature would reduce this redundency since the Dog would be a subtype of Animal. The dog could have additional relations which are not part of the animal type. Creating a set of Animal would include dogs and other animals subtypes as well, but only displaying the relations common to all animals and not subtype specific relations. However, creating a set of Dog would not display other animals.
To those who have programming experience, what I’m suggesting is basically Inheritence from Object Oriented Programming.
There are these two feature requests I know of which requests the ability to specify the scope of a relation and type. So a relation which takes only Humans would display only objects of humans. if that gets implemented, a relation could then be specified to take an Animal and then it could take any Animals such as a Dog or a cat however if it is specified to take only a Dog, it would not take other animals for its value
It would be a great idea to populate the Relation Type page with functionality to make a hierarchical structure so that it will be easier to manage related aspects of certain fields in a certain relation type (like Tag and Status relation type, that can be populated with a text, word, or phrase)
Say, I want to populate the ‘Tag’ Relation Type with some fields/area of subjects under:
Knowledge/Discipline that contains subtypes of Biology, Geography, Physics, Chemistry, History, etc. Under History I also want it to contain subtypes of Ancient history, Modern history, National history, etc.
Life Activities that contains subtypes of Personal, Social, Professional
Or maybe I am a Biology innuendo that wants to apply Taxonomic rank system, from Kingdom, down to Subspecies for animals, plants, fungi, bacterias, and viruses.
I am myself as a PARA Method user will find this function helpful to organize Tags for the Area of Responsibility that has a lot of, you’ve guessed it… Areas.
Agree very much, although as a note I wouldn’t want types to be restricted to a single parent; multiple inheritance or a mixin approach would be the way to go. As you say, this also solves the problem of relation type scope nicely (that all relation types are global seems very wrong to me).
It would probably be better to just merge templates with subtypes and give the user an option to choose default templates for types/subtypes if they want to. That way you get the best of both worlds.
And templates are already mostly used for subtypes.
It might be worked after the release, it’s not a priority.
I recommend you watch the last Townhall. In 34:34 there is a question about “extendable objects”.
i’d love this feature… having to create a seperate type for everything and putting all the properties one by one is too tedious. adding options for inheritance in this menu would be my recommeded way of doing it
It will be absolutely great to have this feature! For now AnyType objects looks limited without Inheritence, for me personally it is a lot of user cases:
it will be absolutely nice to view all child objects with same Parent in Query.
EpicTask → Task → SubTask
Human → Colleague; Human → Friend; Human → Person
…
IMHO, sooner or later Anytype will have to adopt a system like Tana, Logseq, Obsidian (when bases are released), Trilium, SiYuan, and maybe more that I don’t know.
The great irony of it all, as others use weird nomenclature to achieve their workflows (supertags, newtags, bases, etc…), Anytype can use… Types!
An object can have “Any Types” it needs.
For reference, the Tana/Logseq/etc system, means that a Type can inherit from another Type (Logseq can even have multiple inheritance), but more importantly, and Object could be of multiple types at the same time.
My 3D printers are computers. They have CPU and are on the network. So, I documented them as Computer objects. Thus they have fields like hostname and show up in the list of all computers.
I have started logging 3D Prints, to keep a record of troubleshooting and quality, so that I can observe patterns. Patterns of issues are naturally relevant to one printer or another, so it’s important for the 3D Print object to have a property that records which printer it was printed on. This would also be important if I were to start tracking RoI, or amortize maintenance cost across print product.
I am faced with a poor choice without type inheritance. I must either
Create a “Printer” or “Printed By” property that is of type Computer, resulting in a less helpful dropdown and the possibility of invalid values.
Change the printer to be a Printer instead of a Computer
Now it won’t show up in the list of computers. I can get by with a query on things with a Hostname property, and be sure to add that property to both types (and change the “Host” property of the “Service” object to allow both Computer and Printer!).
Is that an acceptable compromise? It’s really not! A system that allows me to avoid having to do this sort of compromise engineering saves time and is accessible to a wider variety of users who might not have thought up such an idea on their own. This is a much more complicated thing to think of vs “printer is a computer, so say that printer is-a™ computer” + “list the computers”, and it requires me to refactor things I had put in place before anticipating this use case.
Take a relational database approach: Printer (type) has a Motherboard (property) which is a Computer (type). Printer is sort of a join record.
This sucks because now I don’t have a single entity under which I associate all of the maintenance logs and prints and other dated entries that define the history of this piece of hardware.
This is an interesting case of: having more ways of doing things actually reduces decision fatigue. I’ve discovered this by using Logseq recently — the ease of “X is Y, so make X a subtype of Y” means I just do that and proceed instead of sitting back and weighing the pros & cons of different architectural approaches, even though all of the three approaches listed above are technically possibilities in that system as well. I just wouldn’t even consider them, as they’re non-obvious, or obviously inferior.
