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:
workouts:
- push-ups
- pull-ups
- lumber jacks
- 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:
- 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.
- 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.
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:
- 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.
- 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 
to sketch something for its display in the sets and graph but maybe this will remain for another day 
. Cheers 
. Thank you for spending time reading 
can you clarify it a little bit? or maybe send me a PM?
. 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… 
. There will be times where I want to use matrix table to layout my contents as well.
). 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.