# Sub-Types **URL:** \ **Category:** Feature Requests\ **Created:** [October 2, 2021, 3:34pm UTC](https://community.anytype.io/t/sub-types/2271 "2021-10-02T15:34:32Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![lynxlove](https://community.anytype.io/user_avatar/community.anytype.io/lynxlove/32/1139_2.png) [@lynxlove](https://community.anytype.io/u/lynxlove)\ **Post date:** [October 2, 2021, 3:34pm UTC](https://community.anytype.io/t/sub-types/2271/1 "2021-10-02T15:34:32Z")
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. [https://community.anytype.io/t/-/1553](https://community.anytype.io/t/-/1553) [https://community.anytype.io/t/-/1622](https://community.anytype.io/t/-/1622) 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 ---
**Author:** ![Kandanu](https://community.anytype.io/letter_avatar_proxy/v4/letter/k/8e7dd6/32.png) [@Kandanu](https://community.anytype.io/u/Kandanu)\ **Post date:** [October 3, 2021, 6:00pm UTC](https://community.anytype.io/t/sub-types/2271/2 "2021-10-03T18:00:54Z")
I just found that actually the **options** (that we populate) of the **Relation type** are not indexed on the **Relation page**. ![](https://community.anytype.io/uploads/default/original/1X/a6454add5aa8a62574cc9e50856bb91489cc95bd.png) 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) ![](https://community.anytype.io/uploads/default/original/1X/f73419a236f4ef1e54396bd3aa020a2f4e4b94ed.png) 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. I’ll put this as a possible reference [[Notion Tag Database](https://www.notion.so/boundscraps/Notion-Global-Tag-Database-Step-by-Step-303626bf3f654fc6a53b3d0654353dc3)]([Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.](https://www.notion.so/boundscraps/Notion-Global-Tag-Database-Step-by-Step-303626bf3f654fc6a53b3d0654353dc3)) [[Notion Tag Database Example](https://www.notion.so/3f0ac59bf20d40619367c1c062d8a049?v=e2e18411bd144b81b1b265d798aa2013&p=ad0477d33230471ea612c817afdb0e49)]([Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.](https://www.notion.so/3f0ac59bf20d40619367c1c062d8a049?v=e2e18411bd144b81b1b265d798aa2013&p=ad0477d33230471ea612c817afdb0e49)) ---
**Author:** ![steve\_baker](https://community.anytype.io/letter_avatar_proxy/v4/letter/s/d07c76/32.png) [@steve\_baker](https://community.anytype.io/u/steve_baker)\ **Post date:** [October 15, 2021, 4:29pm UTC](https://community.anytype.io/t/sub-types/2271/3 "2021-10-15T16:29:45Z")
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). ---
**Author:** ![Srinath](https://community.anytype.io/letter_avatar_proxy/v4/letter/s/aca169/32.png) [@Srinath](https://community.anytype.io/u/Srinath)\ **Post date:** [November 16, 2021, 6:21pm UTC](https://community.anytype.io/t/sub-types/2271/4 "2021-11-16T18:21:41Z")
In addition, ability to make a pre existing type a sub type of another type gives users more potential use cases. ---
**Author:** ![BlablaTalker](https://community.anytype.io/user_avatar/community.anytype.io/blablatalker/32/10313_2.png) [@BlablaTalker](https://community.anytype.io/u/BlablaTalker)\ **Post date:** [November 16, 2021, 9:17pm UTC](https://community.anytype.io/t/sub-types/2271/5 "2021-11-16T21:17:38Z")
From my point of view, the current Anytype Objects Templates could be used for this purpose. ---
**Author:** ![BlablaTalker](https://community.anytype.io/user_avatar/community.anytype.io/blablatalker/32/10313_2.png) [@BlablaTalker](https://community.anytype.io/u/BlablaTalker)\ **Post date:** [November 16, 2021, 9:19pm UTC](https://community.anytype.io/t/sub-types/2271/6 "2021-11-16T21:19:24Z")
> [@Kandanu](#): > > 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) That would be very, very useful indeed. I hope you will propose this feature request! ---
**Author:** ![sambouwer](https://community.anytype.io/user_avatar/community.anytype.io/sambouwer/32/12157_2.png) [@sambouwer](https://community.anytype.io/u/sambouwer)\ **Post date:** [April 21, 2022, 7:40pm UTC](https://community.anytype.io/t/sub-types/2271/7 "2022-04-21T19:40:33Z")
@lynxlove do you still want to merge this topic with this one? [https://community.anytype.io/t/type-composition-objects-of-multiple-types/34](https://community.anytype.io/t/type-composition-objects-of-multiple-types/34) Or have the requests diverged too much over time? ---
**Author:** ![Filip](https://community.anytype.io/user_avatar/community.anytype.io/filip/32/22248_2.png) [@Filip](https://community.anytype.io/u/Filip)\ **Post date:** [January 15, 2023, 3:17pm UTC](https://community.anytype.io/t/sub-types/2271/10 "2023-01-15T15:17:01Z")
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. ---
**Author:** ![psyf4ctor](https://community.anytype.io/letter_avatar_proxy/v4/letter/p/dc4da7/32.png) [@psyf4ctor](https://community.anytype.io/u/psyf4ctor)\ **Post date:** [May 31, 2023, 8:55pm UTC](https://community.anytype.io/t/sub-types/2271/11 "2023-05-31T20:55:21Z")
Hi team, do you have any update on inheritance topic after 2 years? ---
**Author:** ![Alejandro](https://community.anytype.io/letter_avatar_proxy/v4/letter/a/ee7513/32.png) [@Alejandro](https://community.anytype.io/u/Alejandro)\ **Post date:** [May 31, 2023, 9:55pm UTC](https://community.anytype.io/t/sub-types/2271/12 "2023-05-31T21:55:12Z")
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”. > [@Anytype Spring Town-hall: A First Look at Our New Beta Software](https://community.anytype.io/t/anytype-spring-town-hall-a-first-look-at-our-new-beta-software/8741/15): > > Hey! Thank you x1000 to every one of you who came with questions, ideas, early feedback, and a curious mind today. There’s really no better boost in motivation than your support, and we can’t wait for you to start playing with the next release. Please stay tuned for updates in the coming weeks as we progress with testing the new Anysync infra, account migration, and spaces. Sending lots of hugs from the Anyteam! sunflower Passcode: 8?n%KDRh Recording link: ---
**Author:** ![caramel\_chopsticks](https://community.anytype.io/letter_avatar_proxy/v4/letter/c/e47774/32.png) [@caramel\_chopsticks](https://community.anytype.io/u/caramel_chopsticks)\ **Post date:** [July 5, 2025, 10:25am UTC](https://community.anytype.io/t/sub-types/2271/13 "2025-07-05T10:25:43Z")
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 ![image](https://community-static.anytype.io/original/3X/8/f/8f65edd1934c83228c9a0c3c76d64c6489f1420f.png) ---
**Author:** ![mishachepi](https://community.anytype.io/letter_avatar_proxy/v4/letter/m/ecd19e/32.png) [@mishachepi](https://community.anytype.io/u/mishachepi)\ **Post date:** [July 23, 2025, 5:18pm UTC](https://community.anytype.io/t/sub-types/2271/14 "2025-07-23T17:18:54Z")
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 … I just link one good post to this Feature Request [Multi-Type Vs. Inheritance](https://community.anytype.io/t/multi-type-vs-inheritance/9122) ---
**Author:** ![sturdily](https://community.anytype.io/user_avatar/community.anytype.io/sturdily/32/14790_2.png) [@sturdily](https://community.anytype.io/u/sturdily)\ **Post date:** [July 23, 2025, 8:52pm UTC](https://community.anytype.io/t/sub-types/2271/15 "2025-07-23T20:52:05Z")
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. ---
**Author:** ![Granule](https://community.anytype.io/letter_avatar_proxy/v4/letter/g/eb8c5e/32.png) [@Granule](https://community.anytype.io/u/Granule)\ **Post date:** [January 17, 2026, 1:42am UTC](https://community.anytype.io/t/sub-types/2271/16 "2026-01-17T01:42:25Z")
Use-case I just ran into: 3D Printer vs Computer. 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.