Multi-dimensional relations

Ever since the introduction of “relations as objects” and also “inline sets” into Anytype, I was toying with the idea of incorporating more and more aspects of my life into Anytype but in doing so as I mentioned in my other posts, I felt some limitations and lack of features can get in the way of that. Browsing through the community, I came across some interesting and brilliant ideas (multi-type and inheritance) of what could be the next step for the “object, relations, sets” philosophy of Anytype and how it can possibly brought to whole other level; even more capable of what the competitors like Notion can offer. One of the concerns I saw people had for Anytype was the issue of competing and sustaining in this competitive scene of productivity space and how others can simply copy Anytype’s unique features. Personally I think the offline first, Anysync protocol with E2E encryption coupled with self-hosting can’t be replicated that easily with the likes of Notion, Coda, Capacities because they are first and foremost an online service. That being said, if Anytype can double down on its philosophy of “objects, relations, set” and develop it even further, I believe copying it would become much harder and Anytype can enjoy a couple of year of its uniqueness before others catch up. In the spirit of this, I thought creating a separate feature request for a proposed way forward for “relations as object” and can be at least a topic of discussion for the community to brainstorm and give the devs as much ideas as possible to mature this idea before implementation. Also, I wasn’t sure to put it in the General Discussion section or feature request, but for now I’m going to put it in the General Discussion section.

The idea of multi-dimensional relations is all about expanding the functionality of relations and moving past the idea of just treating “relations as objects”. Right now, we are able to create as many objects as we want and we cant choose or create new types of objects to categorize them. For bringing all of these objects together, sets and collections come into play. Meanwhile relations are limited to either adding aspects to the existing objects such as “date”, “email”, “text”, “phone number”, etc or they can be used to connect objects together. In a way, there is no limitation on connecting various objects together via the “object” type of relations and it can be nicely displayed in the graph view. But other than looking really interesting, the graph view implementation in Anytype ( and in most other products as well) is just a nice way to present the objects we have and the relations between them and not much more. As I will explain later, with the implementation of “multi-dimensional” relations, the graph view will become much more useful.

What I had in mind was to give more power to relations in a way that they can achieve so much more. For example, one of the issues with PKM apps after a while is performance because of the cluttering of all the objects and relations (pages, databases and properties in Notion for example). The other issue is to design or implement a system to leverage all the information that you have added instead of them getting buried deep in the void. But what if we could link relations together, like we do with objects, rather that creating new ones every time we need one for a specific purpose. Also, what if the graph view can be filtered/displayed in a way that these relations can be the center of attention, like showing all the related objects for a specific date? I understand if all of this is a little vague, so let me give you a couple of real world scenarios. I included the tasks, fitness tracker and movie/series databases because as I can see from the internet, these 3 coupled with finance manager are the most popular use-cases of these PKM app at the moment.

Scenario 1

One of the more popular concept to be done in the PKM space is to design a comprehensive journal/daily entry. One that contain but not limited to the following aspects:

  • tracking the day to day mood and feeling
  • showing the specific tasks and goals for the day
  • tracking the fitness and health of the day coupled with the specific workouts
  • tracking the habit you set for yourself to achieve
  • logging the activities that you have done for the day
  • review your day
  • journaling and gratification

Most of the items above contain texts so I’m not gonna spend too much time on them. But let’s consider the task, habits and fitness aspect of this daily entry. The difference between a “task” object and “habit” and “fitness/workout” objects is that the former is different most of the time, so the names differ in the set and also the graph view. However, the later is more of a repetitive kind of objects so if we were to treat it like tasks, we would end up with a lot of duplicate entries in our space which by the way is how most people use Notion; They don’t care about duplicate entries since they create databases left and right without considering the overlap issue. For instance, imagine I want to track these habits and fitness items respectively:

  1. push-ups
  2. pull-ups
  3. lumber jacks
  4. lunges

As you can see, these are repetitive items and especially in the case of workouts, I want to track further information on all of them like no. of reps, no. of sets, duration, weight of lifts, etc. and even though I could create one for each daily entry, it’s not very practical and I would end up with a lot of useless entries in my space. I could achieve tracking each of these items using simple tables in my daily entries but that would cause two more issues:

  1. Since I want to monitor the number of days in a week and month that I do these items and track my progress, I have to manually create simple table for each of the items and enter the data manually which again is achievable but not very convenient.

  1. Simple tables doesn’t have the power and functionalities of sets namely the ability to filter based on relations and further down the line with the introduction of formulas, being able to calculate the average, progress rate and percentage, etc.

Alternatively, one more tedious way of achieving this goal right now is to create separate relations for each of these such as “number of sets for push-ups”, etc which will cause a lot of cluttering in our space.

Multi-dimensional relations

With all these preliminaries, let me introduce you to multi-dimensional relations. Imagine you create a object-type relation such as “workout” for your daily entry object. And of course you have other number-type relations for your workout objects such as “no. of reps”, “no. of sets”, etc. With Multi-dimensional relations, you can couple any two or more arbitrary relations together. For example, we can have an “advanced section” in the relations menu where you can couple/link two relations together. This way you can select as many “workout” objects that you have done in a specific day in your daily entry like “push-ups” and “pull-ups” and then assign further properties for each of these “workouts” such as “duration”, “no. of sets”, etc.

Group 1

This way, not only we can track far more information of each objects and relations for our objects, but also we can do a “pull-back” map and in this specific example, track the days we have done each of these with additional information. Now, I can create a inline set inside my “push-up” object, listing all the days I have done it with all the additional information.

Imagine creating a “workout” relations and with the advanced section, you linked/coupled this relation with other relations. Now, every time you add a work out in the relation, a prompt would pop up asking you whether you want to add more information for each item.

How it could be displayed in sets

Before moving on to my second scenario, I would like to discuss how this multi-dimensional would affect the current set and graph UI/UX. Bear in mind that this is only my rough idea of its implementation and design expert can further refine/modify/change it. In sets, this additional information is hidden by default because essentially I’m describing a 3 by 3 matrix wheras we can only diaply a 2 by 2 matrix at a time. So, one of achieving it would be to show this additional information only when the user has clicked on it. Upon clicking, all the other relations and entries would fade and we would be greeted with a new 2 by 2 table where now the row items are the entries in that specific relations, and the columns are the relations which have been coupled with our “workout” relations.

How it could be displayed in the graph view

Similar to the set view, normally we only see the objects and their relations with other object; for example, I see my daily entry with its “workout”, “tasks”, etc. relations to other objects. Again, upon clicking on of the items of these relations, other nodes and items in the graph would fade away only for those additional linked/coupled relations and their items to be shown.

It’s worth noting that this way, we could display far more information at a given time using the graph view such as “tags”, “status”, etc.

Scenario 2:

Next, I’m going to talk about my other showcase of this multi-dimensional relations: movie/series database. This can easily extend to other usecases such scientific awards in the academic community, or accomplishments for history purposes but right now I’m just gonna focus on the simpler yet more fun version of it in the entertainment space. As I’ve already showcased it, I have build my own movie/series databases leveraging the power of inline sets. But I wanted to take it a step further by showing the achievements of each of the cast & crew as well as the movie/tv series. Again, like the workout example, there a couple of limitations:

  1. As of right now, I’m forced to use simple tables to achieve this and but it’s not at all convinient since I have to enter it compeletly manually. But again, I can’t perform any filtering or using formulas to gather information.

  1. Alternatively, I can create a relation for each one of them, like “2023 academy award winner for best picture” and “2023 academy award nominees for best picture” but you could imagine how much clutter it would cause.

Having the multi-dimensional relations could solve this issue easily. Consider create a new type called “academy awards” and among its objects can be “best picture”, “best actor”, etc. Now, again for a specific actor/actress I can define a relation called “awards” and under its advanced section, I can link this relation to others like “year”, “category”. This way, If I add “oscars” under awards, then I would be prompted to further add information for the year of the award and its category.

This enable me to display all the winners and nominees for academy award and all its categories for a specific year or I can design it to display all the winner and nominees of “best actress” category of oscars throghout the years.

Final Thoughts

I’m not sure if the devs agree with me on whether this is a good idea or is it worth investing the time and energy to implement it, but as a passionate fan of Anytype and of course a power user, I wanted to share my thoughts with the community. Sorry if it got a bit long, but I wanted to lay out all the details as much as possible. I wish I had more time and talent :sweat_smile: to sketch something for its display in the sets and graph but maybe this will remain for another day :blush:. Cheers :partying_face:


Thanks for writing up your thought process on this big topic. It does take stimulations to dig deeper into the operations and concepts.

Would the following work for you? Not through the multi-dimensional relation way.
For Workout

  1. Grouping relations with fixed vertical hierarchy (at Library for organisation) ← Like FR Object/attribute collection - use hierarchies and semantic versioning
  2. Store relation content “5” to the relation (no. of sets) at journal object
    This way you can query 5 as part of workout.
  3. Relations to act as information control/storage centre for layers of contents for an object (also set/collection), to control what information to be displayed or queried. ← Like FR highlighting tag colour for femininity, masculinity for language learning (don’t remember the exact FR)

For movie
Similar to workout, but there is no fixed hierarchy on relation types. Make a relation with preset linking to another relation with something like FR embedded templates to pre-input relation structure. Then query usage of that embedded template.
Or use FR object’s Title with relations so naming convention pushes year and reward together. This way we treat it as multi-dimensional object, not multi-dimensional relation.


I reckon the meaning of multi-dimensional relations can be sometimes unclear. And perhaps we need to ask ourselves if we are talking about multi-dimensional object or multi-dimensional relation.

To me, multi-dimension is something that exists on different fields/axes at the same time. Each dimension can contain different levels or layers, which could also be linking to other things. The interaction quantity (matrix) can accumulate up to the no. of dimensions^ no. of dimensions. Each single point of either object or relation can interact with another point.

If there is fixed hierarchy, it is possible to treat the component as single dimension, as we can trace information from above to below, following the same axis. You can tell by context that push-up is a sport; it won’t suddenly become a machine that push things up. It is possible pre-determine the structure of information.

However, in my use case (between art and science), adding to fixed hierarchy, there are times when there is no definitive structure and no fix hierarchy, unless at the point of reference, aka loose hierarchy, correlation, and/or dynamics. Or in the middle of forming structure, e.g. factor analysis.

For example, Person A has abc characteristics. When A interacts with people, it demonstrates 123 reactions. Then abc depends on personality theories xyz, introducing another dimension of multiple layers and structures.

Let’s say z,1,c: we have c1z from person perspective; 1cz from incident perspective; zc1 from z theory perspective. Each combination is a single multi-dimensional object of its attributes - that is 3 links to 3 objects as 1 structure/framework. Each object becomes 1 dimension in terms of referencing/relation.


Since y understand 123 differently, there are also 1’2’3’. I might be addressing (Azc1 ≡ Ay2a) ∵ (c1 pathway with 2a pathway) ⇒ (z1’≈y2)).

All ()s are single relation. () within () is sub-relation.
If () has more than one sub-relation within, it can be split, hence making multi-dimensional relation.
“≡”, “≈”, “with/+”, “∵”, as well as “via” or “in the means of”, are all relation types, or nature of relations, or logical representation. (See a list of Logic symbol and logic representation)

I would be querying z expecting to see Azc1 and z1’ along with (Azc1 ≡ Ay2a), (z1’≈y2), (c1 pathway with 2a pathway) ⇒ (z1’≈y2)), but not Ay2a, c1 and 2a, unless specified elsewhere.

To add, 123 might contains vector (e.g. emotions) or scalar (e.g. mood) and number, aka directions of relation and quantifier ← Like FR Nested Relation / Treat Relations as any other objects / Sub-Relations)

So my use case would depends a lot more on relations as object. That way multi-dimensional relation can simply be interpreted as relations containing different multi-dimensional objects.

What I would need for this to work is:

Multiple inputs of objects/contents ‘abc’; not just the current ‘b links/relates to c’.
Relation types or nature (indicating hierarchy and logic)
and Relation name?

I believe in most cases, considering all of the above would slow down the note-taking process. It is not necessary to go over the board if we are only talking about A’s sister is B (display name is sister; hierarchy is sibling; umbrella/grouping of relation is relative).


Dimensional data model: structure
Relational data model: one to one; one to many; many to many.

P.S. I learned a lot through thinking about this too, so I might not be right at times. Hope readers can understand :face_with_peeking_eye:. Thank you for spending time reading :wink:
P.S.2. I hope I am not making it too difficult for Anytype team. :muscle:

1 Like

Thanks for spending the time and read it :blush:

I’m sorry but I didn’t understand the solution you provided :thinking: can you clarify it a little bit? or maybe send me a PM?

You are probably right. To me the word “multi-dimension” means that you can have additional information at your disposal for each and every relation if you choose to do so. That’s why I put it in the advanced section so that people can choose to ignore it and work with their 2by2 matrices. However, they can choose to add another level of information to each relation so that now we basically are working with a 3by3 matrix.

I wouldn’t say understand differently :thinking:. I consider having such structure of adding more information in a matrix style as having more option in queries, a.k.a sets. For example, if there was a 22 matrix, then each matrix element has strings attach to two items, one row and one column. But if we had a 33 matrix, then that same element could pull information from 3 objects!

Consider that workout example of mine. The daily entry has a column called workout. But each element in this column is in itself a row in another 2*2 matrix. So, right now, each entry in the workout relation, other than its usual relations such as no. of sets, etc now have another but of information in the form of the daily entry. The same can be said for the daily entry. Now, other than all its original relations such as mood and workouts, it has by extension access to specific relations/data such as no. of sets.

Maybe the term nested tables helps to clarify (if you agree that properly describes your idea). That term is also used in one of the FRs you linked.

1 Like

I think they are similar, but wouldn’t it be confusing to use it in Sets which are essentially databases ( at least most people are familiar with it) and with simple tables? :thinking:

Nested Sets? :wink:

1 Like

That’s more like it :sweat_smile:. But to be honest I prefer a term describing the additional functionalities of the relations because after all sets are just a way to display objects… :thinking:

Never mind then… it is probably not as straightforward as the table solution. What I focused on was the data processing in the background, creating the basic for other data to process at the point of note taking. What’s a single element? How do we reach and where do we store that single element? If it is necessary to add another data dimension or add another data relation.

But I will try to portray the possiblity again.
Hierarchy defining for relations at library - Workout>Push-up>Set>No. Workout>pull-up>set>no. We can trace the hierarchy, regardless the location of fixed hierarchy. Push-up is always part of workout. It doesn’t require multi-dimension.

If we have a place to create structure (as template or table or at library), it can be considered as one frame/dimension of a group of data (no of push-up set or pull-up set), then we can pull structure information and one set of data within it. We can reuse the structure and make another layer of data. So that we can make it display another set of data if the structure is the same - making it embedded/reusable template or nested table.

The limitation to consider table as the solution to multi-dimensional relation is that it already defined the structure of multi-dimension, rather than letting user define the structure/hierarchy at the point of interest.

Like FR multi-layer text annotation (finally found the FR I was referring to), the structure is the text, the layered/dimensional annotation, gender and declination, is the data stored based on the text structure. Language learning will have multiple texts or essay (structure).

Or as the process of making forms, there are structure part where people filling in the form would not need to edit, and the input section they fill in ← Like FR form objects. Structure differs at contexts.

I definitely agree that matrix structure is a way to understand multi-dimension and table is the easiest way to understand matrix :muscle:. There will be times where I want to use matrix table to layout my contents as well.

But it is not possible to use tables in the above use case of mine (Recalling ancient memories of learning about matrix :exploding_head:). It is more than a single matrix. I would be doing at least matrix multiplication and managing non-commutative properties. All calculated element will become secondary part of a new matrix to make reference. The basic unit for me contains a combination of some kind, aka basic unit is one element in a one matrix.

Even if it works, it is not effective anyway. I might be only using one element of the matrix/table leaving the rest out as empty until they are useful. Of course having such table still concretises and visualise the used, missing, unneeded information. But can you imagine creating or adding a new dimension or a new matrix or row/column for every person you meet, every emotion you and the person have, every theory you know, at every moment in time? That’s already a 5x5 if we count one unit per dimension. The length and width of a set will not be easily navigable. Let alone the logic representation/argument that link each combination together and the non-linearity and non-structure of art (compared with taxonomy of science).

That’s why relation as object is more like the thing I will be using. This enables the greatest flexibility but allowing the making of linkage to show structure, and thus the ability to have a combination object within the matrix table.

I think I better understand what you are saying :thinking: But I think it requires a whole restructuring of Anytype to achieve it :thinking: But if we can link relations together like we can with the objects, then we can achieve your hierarchy structure as well. Basically with multi-dimensional relations you can build any heirachy you want becasue you can link any two or more relations together; for instance you can link No. of sets with push up and also with pull up. meanwhile you can link push up with with workout so you now have your structure of Workout>Push-up>Set>No. or something like that.

I don’t think there would be a limitation :thinking: As I stated earlier, if you can link/group (or whatever we want to call it) two relations together, then we can create infinite hierarchy structure, right? or maybe I’m missing something.

If we are talking about infinite hierarchy structure, we would be talking about infinite matrices - that’s not explicitly possible to write such thing down; thus a table can’t represent it. Of course, we wouldn’t expect a software to handle infinite amount at this stage anyway, unless we are talking about infinite contents, large language models and machine learning. However, people are already thinking about scalability and performance of Anytype. It is not practical to populate (ten) thousands of notes into a table for the software to call one out one single combination.

It will be processing heavy. We only need to address some elements in most cases. Not all notes are related. Person A and Z will probably never meet each other. It is a waste of time to create such combination. Also, some information are meant to be kept isolated. If users are to input what’s relevant or not, then might as well create the relevant linkage or hierarchy.

To add, table and matrix treat each element equally. It is not so in real life. We have power, direction, weight, reliability etc. That’s also why we have graph view to present knowledge using vertices and edges (graph theory), as well as treatments to areas of nodes in knowledge graph data model.

I think so too… :sweat_smile: That’s why I hope I am not making it too difficult for the team.
Let’s see what will happen with the concept of relations as object.

P.S. If you are interested in knowledge processing models and their loads, take a look at this conference recording.

Oh, I get it now. Yeah, I imagine having infinite matrices is not a good idea :sweat_smile: But I reckon in most case scenarios, you will have multiple relations for the most part and possible a couple of multi-dimensional relations here and there​:thinking:

Thanks for referring. I will take a look at it

I would also find this to be very useful. There are quite a few areas where I want to have the same sort of categorization but they are not connected. Right now I can apply multiple tags to the same item but then it starts making those dissimilar items look like they share a relation, In some since they do generally but there is also a important distinction in which I wouldn’t want that misleading association.

1 Like