Add support for collection-specific relations

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

1 Like

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.

1 Like

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.

1 Like

Indeed, the request here
Ability to Limit the Scope of a Relation
seems to be the general need being expressed.

1 Like

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
  • Database
  • Testing
  • Framework B

DevTools collection I created under the same relations “Topic Type”

  • IDE
  • Docker
  • BuildTools
  • GIT

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.

Thank you

1 Like

This is getting out of hands :sweat_smile:



I have the same :rofl:


Same, although type specific relations might work better for me. Or relation options specific to certain types.

1 Like

My last free vote on it :slight_smile:


I have an idea for this, that may solve the problem if the team implements it:
Nested Tags.

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.

1 Like

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) :exploding_head: Cause each ‘buying task’ could also be reused/repurposed for bookkeeping / expenditure tracking.

And I don’t imagine anyone would use tag with date :laughing: #Christmas is fine though :christmas_tree:

And as a non-tag users :sweat_smile:, 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.

Btw.: you can have more than only one Taglist.
Wouldn’t it solve the problem to make some of such lists?
Go to Library/Relations and create some new lists!

and so on.

If you are in the Philosophy-Collection, then use the list “Philosophy-Tags”.

This concept has a limit: if you use a global Set that catches all Objects from all over the place, then you’ll have a bit hassle with the filter. Because there is no longer one big list of all Tags, but some (shorter) lists.
But I think this little hassle shouldn’t be a big deal.

@Code-Jack To be on the same wavelength: this post is about better relation management, not tags :slight_smile: .

Tag hierarchy has its own FR here :

@raph talks about the problem of having too many tags (tag relationships). I’ve got the same one, I’ve got different “tag” relationships depending on the subject / project… and I’ll soon have tons of relationships with the same name. The same goes for dates, etc.
This makes the search list very cumbersome. And the titles of my tag relationships can’t just be tags, but something ugly…


Ah, yes in deed … the discussion drifted a bit away from the topic after I answered to @raph who complained about the overloaded and growing Tag-list.
Thanks for bringing me back from my dreamland to reality! :wink:

OK, back to the main topic:
I would suggest folders in the Library where we can move the Relations in, for grouping them, simply by moving them with the mouse.
Same way like files in the windows desktop

If we later want to add a relation to an Object, there should a list appear in which we first see the folders. Then we open one of them to pick the desired Relation.
I think this way it would be very easy to implement for the team.