Add support for collection-specific relations

Feature Requests
,
1

WHAT DO YOU RECOMMEND

At the moment, relations can only be space-wide. This means that every relation, even if it’s only used in a single collection, will appear in the relation library.

It would be a huge quality of life improvement to have relations that are collection-specific and do not appear in the relation library.

HOW COULD IT BE DONE

When creating a relation from inside a collection, have a checkbox that says “add to library”. If the checkbox is unchecked, the relation is only visible and usable inside that specific collection. If the checkbox is checked, the relation gets added to the relation library and can be used across the space.

REAL WORLD USE CASES

When creating a Collection with relations that will only be used for that one collection, these relations will be added to the relations library. This means that as the number of collections grow, the relation library will become crowded (or rather hugely crowded) with relations that will never be used outside of the original collections.

One example for my “workouts” database in Notion, which I would like to bring to Anytype: I use “type” tags to categorize workouts (“strength”, “cardio”, “balance”, etc). But I also use generic tags like “all standing”, “need mat”, “upper body”, “legs”, etc. These are really important because they help with filtering in views, but they will never used outside of that particular collections.

There are other tags that I will use across many collections (like the “priority” relation) that I want to have in the library, but there are many, many collections (quotes and excerpts, books, products, contacts, projects, bookmarks, etc), with many many relations that are only relevant to one collection.

RECOMMENDED ALTERNATIVES

We discussed workarounds here but they did not resolve the issue, and will not scale when we have dozens of collections.

ADDITIONAL CONTEXT

This is something that Asana does pretty well (one of the only things it does pretty well): when creating a property, we can decide to add to the library so it can be used across all projects, or not adding it, in which case it is only findable and usable within that specific project.

image
image526×376 5.67 KB

2

I doubt that something like this is going to be implemented any time soon if ever. How I understood it from your posts in the other topic, is that you want type specific relation options?
So, for the default tag relation, you would want options for the recipe type to only show up for the recipe type, etc.

3

Not type-specific, collection-specific. I would like the option, when I’m in Collection A, to create relations that aren’t displayed when I’m in Collection B or C. So that each Collection can have its own “tag” relation, with its own set of options.

It’s no different from what Notion does with database “properties”, Asana with “fields”, or Coda with “columns”. All of those are specific to the collection/database where they are created, with sometimes the option to add them to a library to make them available to the whole workspace.

4

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.

5

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)

6

Instead of making all of these pages, you should probably make them into types instead. A recipe type, a quote type etc.

7

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?

8

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.

9

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

10

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.

11

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.

12

The same issue, want to see the function that can limit tag or option relation inside collection or set.

13

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.

14

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

15

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.

Workaround
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.

Conclusion
I really hope this request goes through because it would really add the usability of AnyType.

Thank you

16

This is getting out of hands :sweat_smile:

image
image
image

17

I have the same :rofl:

18

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

19

My last free vote on it :slight_smile:

20

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.