But, aren’t all of these collections going to be collections of the same types? Those were the examples you mentioned. In this case, and quite often as well, an equivalent of a Notion database in Anytype is a type. In Notion, you would create a database for all of your tasks, in Anytype you would create a type for a task instead. Usually you would then use a set to find all of your tasks in the database, and now you could also use a collection for this, but you would need to manually link them.
I see what you mean, and yes, collections will be of the same types. However, even with the same types, there will be many collections with different relations.
For example, many of the collections will be collections of pages. But they shouldn’t have the same relations because these pages will be very different (quotes, recipes, workouts, etc)
Instead of making all of these pages, you should probably make them into types instead. A recipe type, a quote type etc.
Maybe that’s the piece that I haven’t yet internalized in Anytype… but I feel like this is going to lead me to a library of hundreds of types. Is that sustainable?
I really like your suggestion with the Asana example, but I can’t help but think that you should be using Sets and filters for this.
Like @Filip said, a custom type to differentiate the pages, and then relations to categorize and filter your workouts.
But yeah, it can still get crowded, so a property/relation local to the set or collection would be nice. Or inheritance in types.
Fair enough. I’ll try my hand at working with types more.
The issue with relations remains though. I also notice this feature request which may be what I’m looking for: Ability to limit the scope of a relation
I doubt that you’ll end up with that many unless you are creating types for literally everything, an even if you did, it shouldn’t really be that big of a deal either.
Following up here, as I’ve migrated a lot of data to Anytype and have also become a lot more comfortable with types and sets.
I still find an important need for collection-specific relations. I find myself creating A LOT of collections of pages that have nothing to do with each other (“activities in LA”, “travel itinerary”, etc). I could use sets instead of collection (using a “type” relation, tags, or another relation to group the pages together, though this honestly seems more cumbersome than just using Collections) but even if I did, I would still face the same issue: having massively long lists of tags that I have to navigate or browse each time I add a new page to a Collection or Set, even though most of these tags would have no relevance to the Collection/Set in question.
I really believe that the ability to create relations (and relation values) that aren’t available space-wide would make the library a lot more usable and would help make Collections a lot more useful too.
The same issue, want to see the function that can limit tag or option relation inside collection or set.
The more comfortable I get with sets, and the more I grasp the difference between sets and collection and use both in my workflows, the more I feel the need for collection-specific relations.
Indeed, the request here
Ability to Limit the Scope of a Relation
seems to be the general need being expressed.
Would title “The value of relations should be collection-specific” be an accurat description of what you are looking for? I stumbled upon your request as I was writing mine… seems very simular.
I have 2 collections, CodeStack & DevTools. Both have a general relations name of “Topic Type”
CodeStack collection I created the following values under “Topic Type”
- Framework A
- Framework B
DevTools collection I created under the same relations “Topic Type”
Now… it doesn’t matter which collection I am on, whenever I am tryiing to fill in “Topic Type” I am getting all 8 values.
Now consider this, I am in Workout collections and as I am filling my “Topic Type” I see… Framework A, IDE, Docker…etc. which does not make sense. If I have a lot more collection that uses “Topic Type”, things can get bloated really quick and unusable in the long run.
We could be split “Topic Type” in to 2: “Dev Topic” & “Code Topic”.
But again what happens when you have a lot of collection? Everytime you create a new collection you have to also create “XXX Topic”, which gets your Library bloated.
I really hope this request goes through because it would really add the usability of AnyType.
This is getting out of hands
I have the same
Same, although type specific relations might work better for me. Or relation options specific to certain types.
My last free vote on it
I have an idea for this, that may solve the problem if the team implements it:
What do I mean?
At the moment, the Tag list becomes massively long over time.
But if there where a way to group the Tags inside the list in “folders” the problem would be solved.
A list is only one-dimensional. So the list must become loooong.
But with folders (or Tabs), it would be like two-dimensional.
We would have a way to group related Tags and then choose a specific Tag out of that group (no matter if it’s called a “group”, or “folder” or “tab”).
No need for the team to implement Collection specific Tags.
Simply implement a way for the user to move related Tags in a folder-like stucture inside the taglist.
I think it’s more complicate and it need two things :
- a solution to filter and display tags by “folder” in the search menu
- a solution to attach relation to something
Attach/label relation to a collection can be relatively “simple”.
But if you want to manage this link to make it more open (link to a collection but also to a project or personalized category), you need to plan all the management around it.
For the display and filter in the search menu, no matter if the “folder” is the name of a collection, of an object type or whatever.
It can display all relation unattached or attached to current collection/object type + folders for storing relations.
A simpler solution would be to display “classification name - relation name” each time.
We don’t need to invent new names for our “Tags” relationships, we just need to be able to label them, whatever the label.
I made a picture of my idea how the “list” for choosing a Tag could look like:
At first glance good. The list becomes much shorter because it’s two-dimensional if there are folders or groups or tabs.
But thinking further, we’ll find out, that some Tags belong into more than one category.
The Tag “Matrix” could not only belong to “films”, but also to “philosophie”.
“Education” fits not only in “finance” (because it causes costs), but also in “books”.
I wouldn’t go so far to suggest “Relations” for Tags to solve that little problem.
No, I think such a simple 2-D structure would help a lot if used with sense.
Maybe most Tags belong only in one single category.
The user could put the rest of them in a category “universal Tags”.
For the programmers noting would change, everything can stay as it it. Only the list for choosing Tags must be extended the way the picture shows.
Make each item in the list movable with the mouse.
And add a button “New Tag Category”. All done!
I also agree with @Shampra that collection-specific relation serves different levels of functions from tags.
Collection-specific and Object Context are identicators for situational use of relations. For example, with a collection for the shopping list of a date, I wouldn’t want to create buy apple task for each purchase to track spending/prices across the whole year (that would mean 52 objects per year for apple alone if buying once per week) Cause each ‘buying task’ could also be reused/repurposed for bookkeeping / expenditure tracking.
And I don’t imagine anyone would use tag with date #Christmas is fine though
And as a non-tag users , I would prefer to create objects and MOC, and then use object type relation for themes, categories and concepts… There are lots of contents and descrptions within each topic and they could continue to grow, for example ethics and metaphysics with Kant, London eye and boroughs for London.