I Support this idea
Although mentioned above, I wrote a more detailed explainer of nested collections. Let me know if this solves your problem with sub tags. Although I used ‘projects’ as an example, you could swap that out to ‘tasks’, ‘woodworking’, etc.
Nested collections with extended properties
User Story: you’re in a company and are part of many different project teams with various responsibilities. You’re part of the iOS App Launch project, New Website project, and User Research project. On Anytype, how do you keep all related documents and tasks together, particularly in a team setting with many other collaborators?
If every project had its own type/collection at the same hierarchy as Bookmarks, Images, Tasks, etc. this would cause bloat very fast in teams running many projects. Additionally, the project collections all have much more in common to each other than Video, Files, and Chat collections. In fact, all project collections might all have very similar properties—if not the exact same.
Collection 2.0 Experience
-
You have a Projects collection with global properties: Owner, Project Team, Objective, and Description. This is a parent collection.
-
You then nest three collections within that parent Projects collection called App Launch, New Website, and User Research.
-
All nested collections will inherit the parent properties from the Projects collection, and then they can add their own unique collection properties. The iOS App Launch nested collection might include its unique properties such Design Assets and Marketing Assets. These properties are not necessary on all Projects, hence it’s applied only to this specific nested collection.
-
If you are on a page in the New Website collection and you create a new sub-page inline, it will automatically apply the New Website collection to it. This helps keep related objects in the same collection.
Benefit
-
It adds some organisational capabilities to collections in general (to the sidebar and general navigation). There could be an ‘all collection view’ where you view all collections in the space. Could also add ‘grouping’ or ‘labelling’ so that certain collections are known to be for specific teams or use cases.
-
Keeps related objects together and minimises orphaned files. E.g. If the project gets cancelled, it’s easy to delete the entire collection (and all its objects).
-
It maintains company standard operating practices by having the same properties (and maybe even templates) inherited from a parent collection enforces a defined benchmark. E.g. every project has an owner, objective, KPI, etc.
I hear you. I think there are multiple aspects to Collections 2.0 and they don’t need to merge or compete with each other—they’re additive to the whole. Have you seen that relations and rollups are on the Collections 2.0 outline? Giving more ‘power to properties’ is something we’re aligned on. However, doing that does not mean that we should not make types, queries, collections, and tags a better system overall—which is primarily what this architecture conversation focuses on. Relations/rollups are somewhat a known entity across most apps and implemented in very similar ways (like filters and sorts). But maybe I’m missing something still from what you’re thinking.
As a general point, I’d say our focus in the architecture conversation right now is not on building out advanced features—although we hope that it still can do that. Rather, our focus is to make the system simpler to get into—especially in multi-user spaces. Creating advanced systems for a single user space is a very different ball game to a understandable system that works across many different users sharing a space—which is our challenge today. People want to get others into Anytype, but they all say the same thing: it’s too complicated for their invitees to get into. Once we can get everybody to walk, hopefully many of them will eventually run.
I must be one of those rare people, haha. I search databases all the time in Notion, and I also have the pages in databases heavily filled out. The main difference I see between Notion’s system and Anytype’s is that pages are locked to the database and can’t live in multiple locations (tree/folder system), which is what you’ve mentioned. The databases/collections in themselves are quite similar to each other (at least for me).
You are resolving every issue I have had with every other application I’ve tried to use. Please keep on this path. We all need it!
That’s the case where I live too 
. The people I know (and myself) strongly use pages in databases, not just properties.
Whether it’s a computer knowledge base, a recipe collection, etc., properties are numerous and very useful for obtaining relevant views, but there is also content in the pages. In some cases, a richer property could avoid this, but that’s only sometimes when there is little content and it’s always the same (and since that doesn’t exist, the question doesn’t arise).
Sometimes, yes, only properties are used (e.g., list of furniture with dimensions, PDF document database, etc.). This is sometimes done to make full use of formulas (e.g., dosage calculation, cost calculation, etc., depending on other properties).
But really, this is not the majority of cases.
As for searching:
- via database search (e.g., I’m looking for recipes containing eggs)
- or very often global search (in which I can directly point to the database, date, etc… here, I miss a more powerful search on Anytype!)
That’s an absolutely valid point and I understand that this should be priority no.1 for the team 
.
Yeah, I’ve seen it and I’m really glad it’s on Team’s agenda; However, I’m not sure whether it would work like Notion or it would function differently. I was exploring Notion yesterday after a quite a while and man, they’ve just added so many features 
. Especially I wasn’t expecting their “layout” feature to get so much sophisticated, especially with their “tab” feature in Layout. I think it would be a great source of inspiration for Anytype for their “Applying Templates to existing objects” initiative. But if these “roll-up”/”relation” features work similar to Notion, then I guess, it would somewhat achieve what I was talking about with “multi-dimensional” properties, albeit in a reduced fashion.
But as it currently stands, it’s not possible to have a functioning ‘habit tracker’ in Anytype.
That’s interesting! Nearly every video I’ve watched of people using Notion, is that they use databases and its respective pages like a separate entity. Sure, there are some pages in their workspace which they heavily populate it, but mostly they use it as a placeholder in their databases. For example, when they create a Habit tracker, or Expanse tracker, they just use their entry in their database as a “date” placeholder. If they search globally in their database, they might find find several pages with and exact name, or similar naming scheme like “Day 1” or “February 24th” and at least at first glance you can’t differentiate whether it belongs to your habit tracker, or your daily journal, etc. I guess now with their improvement to search and the preview they can see what’s inside before opening it, but my point is that when you open these pages, it doesn’t have anything more than the properties which were assigned to them in the database. It’s mostly just blank.
You’re right but these are more of a “Wiki” use cases in Notion rather than the one I’m talking about which is more about having multiple queries of information based on the context.
Thank you @kaye for the writeup and the userstory this actually clarifies the intention of this change for me clearly. I don’t fully agree, but I understand 
Types are effectively renamed as ‘Collections’ in this new architecture
I feel this would be a step back in the improvements Anytype has made toward clearer terminology across the app.
Movie — Dune: Part Two (2024)
Book — Dune Messiah
Soundtrack — Dune (Original Motion Picture Soundtrack)
Toy — Dune Atreides Royal Ornithopter
Board Game — Arrakis: Dawn of the Fremen
Article — They Stopped The Moving Sands
In this proposal, all of these would gain an additional type (collection) called Dune. They would have two types, but that would / could create an issue of easily seeing which Dune am I looking at? Because Dune the Movie, Book and Soundtrack (if I just name them as such) would have multiple types and no clear identification on what this object is at its core.
For me, there is an inherent difference between what a Type is and what a Collection is in this case. A Collection is a bunch of different things collected into a single group. A Type is a bunch of similar things, not necessarily collected together (although for Movie we could create a Movies collection -even a smart Collection).
At the end of the day, I understand that you see this as a minimal change since properties can pretty much take over the role of types. I already did something similar because Collections were never really useful for my needs as they existed, so I just use a Project property for that instead.
If you know the app, this change is basically insignificant, but consider that this is a big change for new users or non-power users, both in terminology and in how they approach the app and whether this actually makes it easier for them to use.
Also from a branding perspective losing types would be an interesting choice too.
I want to clarify two points:
Primary Collection: every object inherently has a primary collection that it’s a part of. The reason is not for what you’ve outlined (that an object has inherently one main type, this is debatable), but because the UI needs the ability to surface a neutral/baseline collection for an object. If the ‘Dune: Part Two’ exists in multiple collections, then when you search for it, it should still only display once and have its primary collection labelled with it. Displaying all collections an object is a part of without any order is a UI issue.
Context-based Properties Header: The type/properties header provides the context for an object, while the content inside the object itself is the ‘core’ in a sense. In this Dune example, imagine you are browsing your Book collection. If you open ‘Dune Messiah’, then the properties header will show all your book properties—this makes sense. But imagine you wanted to put together a wedding registry of all the gifts you’d love to receive. You put many gift ideas in there, including ‘Dune Messiah’, organise them by price and desirability, then web-publish it so your guests can check it out. When browsing your Wedding Registry collection, when you open the ‘Dune Messiah’ object, why would you want all the book properties displayed? In this context, the publisher, publishing date, and award properties are all irrelevant context. By having the context of your object change (the properties header) depending on where you’re viewing it, it behaves more naturally to the way we think—in our opinion. 
We don’t see this as a minimal change, actually. And we are counting on it being significant shift on the mental interpretation of the system (even if the functionality is similar). If it turns out to not be significant, we have failed. Hopefully, this is a better way to interpret the system.
For collections, why would a bunch of different things be collected into the same group? By the act of putting them into the same group, they must have some attribute that makes them similar and related—just like types, different things coming together based on some shared relationship. When really breaking it down, we believe people will start to see the boundaries between Type and Collection is mostly based on app semantics and habit. Objects are much more fluid in reality than our current system allows them to be.
An important point I’d make: if you don’t want to put objects in multiple collections, you don’t have to. Just put them in one and call it a day.
I am not worried at all with the semantics or name, not that I know what most users will think, but I am sure if needed, Anytype will listen to the users and their community.
I just hope you can clarify something:
Say Dune book has the book properties, and the Dune wedding registry has a property “how much I would love you back” (I know, silly, but, just an example).
If the wedding registry property was not global and only in the scope of that collection, would that wedding registry property still be in the object? Or would it only be visible on that collection?
If I did a “Smart Collection”, would it be possible to show both the book properties and the wedding registry property ?
That is my main question: where do the property and its value stay? on the object or on the collection?
Great questions. In our view, all collection properties are applied ‘on the object’. Currently, if you use the ‘query’ function, a property is applied only ‘locally’ and therefore not actually part of the object. In this new setup, all collections are types, so they are all applied ‘on the object’.
As for displaying the properties in the object header, this is something we have not fully figured out yet. Should there be tabs that all you to cycle through different collection properties of the same object? Should all properties from all collections be displayed? How about the same global property used on multiple collections that the object belongs to, do they show up repeatedly or only once?
The distinction between a collection and smart collection isn’t much besides the query-ability to auto aggregate objects into the collection. So in this setting you have three collections: Book, Wedding Registry, and 3rd Collection. If you want to display the same book properties and wedding registry properties, they would have to be global properties so they can be applied again to this 3rd Collection—the property entries would auto-populate, of course.
If I understand correctly, this is great, they will be on the object.
If I delete the wedding registry or just remove Dune from that collection, does it delete the property, if it is filled with a value?
Preferably, it would keep the property if it has value, and remove it if it is empty.
I see! Thanks for correcting me.
My main worry, is to not have a system like SiYuan and I guess also like Notion, where the “data” are in the databases, not on the object (creating data silos).
Ah, I see. We might not be on the same page.
- Deleting a collection: this will remove all the collection’s properties from the object and delete the collection. If the object doesn’t exist in any other collection, it’s likely a prompt will show up asking if you also want to delete these orphaned objects.
- Removing object from collection: this will then remove that collection’s properties from the object, however it will archive the entries. If you were to re-add the object to the collection in the future, the previous entries on that object would also be restored to the properties.
- Keeping the property and its value when it’s no longer a part of any collection is a different story. In this case, I think we could make it a ‘local’ property, but it’d be difficult to do much with it.
Is there a reason why you’d want a property and its value to remain on an object even though that property technically doesn’t belong to any collection/type?
–
I’d like to caveat that many of the discussions today are our intentions, but we still haven’t fully figured out the implementation yet. It might be that some ideas are implemented only partially in the beginning. And some might not work at all (hopefully not), but we at least want to gauge the community to see if this is what y’all would like and that we don’t have any blindspots in our thinking.
I see. I think we are mostly in the same page, just some details in a different page 
I apologize and either wait for you to create another topic, where you ask for opinions and use cases for these details, or, well, always feel free to DM me on the Anytype chat.
All good to continue the conversation here! Please.
I’m curious as to why you’d like to see properties and values remain on an object even without any collection attached to it. @sturdily
Other systems that allow this (that I know and use/used), all keep the properties: Emacs Org Roam, Obsidian and Logseq.
Systems like SiYuan do not (I do not know if Notion does, I suspect it does not). I have opened bug reports on SiYuan some years ago, where one would cut the link between block and database (even so accidently, which is unfortunately very common there), and all the curated information on the database fields would just blink out of existence. Maybe this traumatized me too much
This example is not a good one for the case, but the principle is of no data loss. I had many cases (which unfortunately I have not documented, did not imagine we would have this conversation ), where I removed a tag (as in Tana Supertags), but did not want to lose the data that it contained.
We are always assuming that a note/object has the properties one specifies in the Types, but in reality (currently), it does not always work like this, and an outlier property/properties make sense.
(Example, in Anytype, I am using templates to add properties, and using queries, similar to that reddit post, to add group of properties dynamically to existing objects. I am hoping the “add templates to existing objects” can solve this, specially if templates can carry properties)
Until I can find a good example/use case for this, the principle of avoiding “I added this value or this information to this property and now its gone” (data loss), is important.
(The use case is kinda hard now on Anytype, but it is easy on systems that work like the proposed Collections 2.0. I am talking of my experience on those systems)
Sorry if I am focusing too much on details.
That’s interesting!
I’d like to take advantage of this: can you integrate the undo function into ALL actions? This is already a problem at the moment, as it’s often impossible to go back.
With Collection 2.0, it seems even more important to me. There will be mistakes at first, so we don’t want to discourage people. On the contrary, we should encourage them to test things, knowing that they can go back (I’m the first to avoid touching certain things because there’s no going back, which is a shame because I would have liked to test things…).
Thanks.
This clarifies it a lot more for me, thank you.
Objects are much more fluid in reality than our current system allows them to be.
I think this is probably where my difference comes from. The proposed change would 100% achieve this. My approach is that objects are fluid until I give them a Type. Then they can belong to any collection (or project) but they inherently are of that one type (Soundtrack, Movie, Book etc).
Coming from Notion and the databases discussed above, the whole type definition for me was a huge step forward. Instead of everything being just a page in a database (where page would be one of many types and database is an analog to collections), a type could be its own database while being a very clear definition of what this thing is at its base. Then I can categorize it further.
A primary collection is a great idea to have, but in this case I do want to stress my point on terminology so you make sure it makes sense (I am way out of my depth here, naming things is difficult :D). To me, it would still make sense to keep the name type for primary collection and then have a collection of each type be automatically generated. For example, a primary collection of movies would inherently mean that the objects in it would be of type movie.
tldr: I probably won’t really complain about Collections 2.0 further, until they are released Functionality wise I would not lose anything and I do see the benefit of it being a bit more flexible, so if it makes sense to others, my usecase is not really hurt by this, thanks for clarifying.
Reading this, along with the previous post clarifying that types will remain, I feel confident that I will be able to continue using Anytype. Great!
However, what we call things is not unimportant. I have been trying to explain collections in a Pythonic context to journalists for more than five years now, and for people who are not used to this kind of abstract object, it is difficult to understand what we put into those collections. What Anytype did was allow us to replicate the world around us, mirroring the people we interact with as a People type, and the books we read as a Books type. Then it becomes much easier to imagine collecting those persons and books into collections.
With Collections 2.0, one would create… an object? And that object is part of a collection that somehow takes that object and gives it properties, and those collections can be bundled together in other collections (but not collections in the same sense as the object collection). This is not how we organize things in our daily lives, and I can only imagine how difficult it will be to explain this technically very smart system.
Ok, so the main point is that you don’t want data loss from entries in properties. From what I’ve outlined above, I think we’re aligned here. Our view is that the entries should be archived, even if the collection/properties are no longer connected to the type. That way, if it’s re-attached to the type, the entries will come back automatically.
Yes, undo/redo is on the Collections 2.0 outline and will be implemented.
It’s actually simpler than this. Every object belongs in a collection. Once added to a collection, an object will gain that collection’s properties. You can add objects to as many collections as you want. Depending on the context of how you view that object, the relevant collection’s properties will display.
It’s really interesting to see everyones perspective on collections 2.0. From my side I have quite mixed feelings about the the new approach, but I trust Anytype team to choose carefully. And if it will really help new users to stick, then let it be.. it will also benefit the rest of us Most of my questions have been answered in the discussion above. But there are still some open things from my point of view:
How about block based properties? Will they still exist in the future? I’m asking because I have several templates and workflows where the properties are distributed amongst the content of page. And I absolutely love them… it’s a huge advantage compared to notion or other tools, where they only live at the top of the page. And will they still appear if the objects are opened within a collection where those properties are not assigned? Is there something like global properties? Or how will this work? Or will they be treated like “local properties” at the moment? The same would be for inline properties … if they will ever come 
Another question: I’m a heavy raycast user. I access nearly every object through Raycast or through search in Anytype. Will there be a way to choose within which context we can open objects? or will it open the object within the master colletion?
Last question: Will deeplinks change? At the moment they point to an object directly. But when an object has to be seen within a context of a collection, it somehow needs to know which context, right? That would be quite a disaster… my deeplinks are on QR codes, on other tools… everywhere 