Derived Relations ( Formulas )

Feature Requests
, ,
1

Is your feature request related to a problem? Please describe.

An option to create derived relations based on the value of another relation of the same object

Describe the solution you’d like

Derived relations are basically formulas from notion. A simple derived relation editor with built-in functions to perform operations on the other relations assigned to the object. This enables the relations to be more dynamic and brings more flexibility to anytype. To improve on it, an option to add custom functions can also be provided. The syntax need not be complex and custom functions can be restricted to be made only using the built-in functions. It can also be possibly made to provide functions through plugins as well. A simple example for a derived relation is a Days left till deadline relation for a task type which computes the difference between the current date and the end date and displays it.

This request goes in hand with another request i made:

Since derived relations are specific to an objects state and is based on other relations which may or may not be available in other type of objects, a derived relation should be coupled with a specific object type and should not be listed in the add relation list in the create task view

Additional context

106 Likes
2

Yes to this! :slight_smile:

3 Likes
3

This will be useful for me as well. Good to have some basic arithmetic functions out as maybe an initial version

3 Likes
4

It would also be great to have a native progress function which takes two input - the current value and the maximum value and all it needs to do is to calculate the percentage and display it with a semi filled bar or something like that

2 Likes
5

I had a related idea today, which would I think be an extension of or additional function for a “Formula Relation”. Basically have some formula functions to operate on page contents (blocks) in some way, not just Relations. So for example you could count how many blocks there were in a page, or count how many characters were in a certain type of block, or count how many checkbox blocks are in “unchecked” state. Something like: countif(page.contents,block.checkbox,0) in psuedo-Excel language. :smile:

I am not sure how many other uses this might have, but I suspect it might be the kind of thing where many uses emerge once the functionality becomes available and all the creative alpha users get access to it. :grin: I hope that makes it worth adding!

9 Likes
6

A question I have about this is what the scope that Anytype plans to implement is?

Simple formulas are probably sufficient if the goal is to have a note-taking and light data analysis tool (similar to Notion).

However, suppose the goal is to eventually create an “operating system” (as in a platform for making apps). In that case, it seems necessary to allow arbitrarily (ideally, version-controlled) code to be attachable to relations.

Imagine, for example, someone wants to store a photo library in Anytype. They would likely have a “Photo” type containing, e.g., a RAW file and some metadata. To implement photo editing, Photo objects might also refer to another object implementing the “Photo Adjustments” protocol (I say protocol because different apps might implement photo adjustments differently).

Now, to display a photo, a JPEG file needs to be generated. Of course, it could be generated manually and stored as another relation, but wouldn’t it be a lot better if it was generated as a (cached) computed relation (e.g., formula) from the RAW file and “Photo Adjustments”? This, however, would require fairly complex code (likely using external libraries) to be attached to that relation.

Other applications could include, e.g., visualizing data from sets (including complex things like maps), anomaly detection on sets, etc.

Even more, if one makes a special formula to draw views and windows (based on the object’s contents), it could even become a desktop environment, a distributed object-oriented operating system, where each window would correspond to a (shareable) object.

5 Likes
7

Yes, this is interesting to think about. Given Anytype will be open source and have an open API/SDK as well, I feel like the most sensible way to address your ideas in the short-term would be via code contributions and plugins. Look to the Obsidian community for proof of how flexible that can be, even without access to the source!

I look at this as the solution for now because solving the coding-at-the-user-level problem is tremendously difficult, and I think it might place a perhaps unnecessary barrier on further progress for Anytype at some point. While it would be nice to do everything within the Anytype app itself (even coding new types, relations, plugins, etc.), the practical benefit of that is questionable, at least in the short-term. Long-term, well, the vision may indeed encompass the more full realization of “operating system” that you’re speculating about, though it seems there would still be some “layer” below it, the current OS’s. I don’t expect to see them go away or be replaced by Anytype within ~10 years. :smile:

You may find the writings of Alexander Obenauer to be interesting:

4 Likes
8

I would like to add that it would be great if the relations can be derived from objects linked to the current object as well. So let’s say there is a object of type team and has a relation called members which takes human typed objects. It would be great to be able to do the following scenario:

  • Create a new derived relation named - Senior members
  • Type accepted - Human
  • Formula / Derivation - (Today - Members.Date of joining) > 6 years

And thereby filtering all objects linked in the members relation and only add those that satisfy the formula in the new Senior members relation.This should also update if new members are added / removed from the original relation.

This one is a longshot but it would also be great if the same can be extended to any level of objects as long as the relation is type scoped*
For example: Let’s say there is an object of type called Manager containing a relation named teams managed which contains the list of teams being managed by the manager. It would be great to create a derived relation such as:

  • Derived relation Name - Manages
  • Type Accepted - Human
  • Formula - Teams.Members

What this should do is to collect members from all the linked teams and add it to the relation called Manages under the manager object.

Doing this would make it possible to roll-up and drill-down objects without explicitly implementing one such feature for sets. And to me, this type of drilling down and rolling up feels intuitive than linked databases since I can now create a new derived relation called

  • Derived relation name - Number of people manged
  • Type - Number
  • Formula - count(Manages)
    Thereby making it possible to create derived relations from existing derived relations and essentially, performing rollup operations

Since the derived relation is also a relation, it can be displayed in sets

*The type scoped condition for chaining derived relations is important because only then anytype could ascertain that all the objects in the relation will contain the same relation

7 Likes
9

Sounds interesting but I’m having trouble visualizing it…

Could you give an example, starting from scratch?

2 Likes
10

Someone on Reddit brought up Coda’s approach to formulas, and I think it nicely encapsulates some ideal (or at least very good) guidelines on how to approach this feature in any good PKM/TfT system:

In particular, they reference this video from Coda:

And they outline the following key points (quoted from Reddit):

  1. You can produce a formula from EVERYWHERE (just add “=” and this prompts formula entry).
  2. Everything/object has a NAME (not cell values, as in Excel)
  3. Chains in formulas and not brackets/wrapping like Excel or Notion. Almost makes it like writing a story and is much more user-friendly and extremely powerful
  4. You can name the formulas themselves for easy duplication in other parts of your Anytype system
  5. Each object referenced inside a formula is separately colour-coded and features a small icon to identify the object being referenced to distinguish it from other similarly-named items (e.g., referring to a table looks like a green chip with the table name and a small grid icon beside the table name)

I think this approach would, if I understand correctly, also encompass my previous feature request based on another app called Patera:

15 Likes
11

Wow, this looks really awesome! This should be the way how formulas work.

4 Likes
12

I’ve never used Coda before but from the video it looks like Coda works with blocks and not objects which makes it possible for them to be able to use formulas within a document and as a column of the table as well.

Anytype revolves around objects and objects are related to others through relations. So the best way to handle formulas is to implement them as relations but with an option to inline relations as requested here

Then, It would be possible to inline formulas inside a document to make the document dynamic. This would also keep the formulas created for a particular type to be closely coupled to that type

If formulas are getting implemented as a block rather than a relation, then it should be possible for them to be referenced in a relation so that they can be displayed as columns in a set as well or to feature a value of the formula in a page. For this, a formula has to be named and as the number of formula used by a user grows, the number of named formulas grows as well. Either ways, a relation type named Formula has to be created

One problem that is to be addressed is when dealing with Sets as sets are not a separate entity and are a container for related objects, there must be a way for users to reference the set from formulas such that the formula is limited to the elements of that set. One way to address this is to treat a set as any other objects and make it possible to create relations to a set as well. Therefore, one can create a formula relation for a set and populate it based on the set elements.

Either ways, I strongly feel that formulas should be able to access not only the relations of that object but also the relations of objects linked to that page thereby making them powerful and flexible enough for most use cases

6 Likes
13

Related problem
Easy way to demonstrate the need: create a friend list (similar to a Notion template), which helps you staying in touch.
So we have these relations: Name (Text), Last contact (Date), Last contact type (Tag)
I want this table to have different views. I want to show people, that haven’t been contacted in three months if the last contact type was personal OR people that haven’t been contacted in 3 weeks if the last contact was chat.

Another: I have a list of flims with the relations: Title, IMDB score, Rotten score, etc. I want a relation that shows the average score for that film.

The solution I’d like
Add the possibility to create relations based on expressions (like value = AVG(relation1;relation2)).
Add the possibility to use expressions in filters. (like today-last contact < 3 months)

Describe alternatives you’ve considered
No other way found yet.
Sligthly relevant: More robust system for Relations

If this gets a GO, I’m more than happy to help with the ideation from UX perspective.
This expression engine could be utilised for conditional formatting as well.

4 Likes
14

I would be very interested to know where this sits (generally) in the roadmap. To me it seems like one of the biggest feature gaps between Anytype and Notion, but I haven’t heard about anything about prioritizing it.

7 Likes
15

Seriously the only thing im waiting for right now is this

2 Likes
16

Based on the notes from the latest town hall, it doesn’t appear that this will be prioritized anytime soon.

2 Likes
17

They are finding it difficult to implement becoz of architectural issues, this is my priority feature too, but well they cant do anything about it ig

3 Likes
18

Hello everyone :nerd_face:. We are really looking forward this feature.
But the amount of effort is too huge to prioritise this feature now. We think it will be for the common good to address more painful parts of the app such as navigation, lack of databases and ux of working with relations themselves before starting this one.

16 Likes
19

Fair enough, and thank you for responding. It’s good to know that it will be addressed at some point.

4 Likes
20

Just adding my +1 here. Not a deal-breaker for me personally (I could live with Anytype as a “repository” rather than a “brain”) but understand it is critical for others and adds a massive new dimension of functionality.

A further 3 leaps to take this down the intelligent organiser route might be: displaying charts > ability to interface with / run programming code > button blocks that perform actions. This would take Anytype past Notion into Coda territory, and be pretty unbeatable tbh.

11 Likes