Seeing how many users have difficulties understanding relations, I would like to put forth an explanation and propose some components that could assist the actualisation of relations.
Relational data model
Relation captures and manifest the essence of Relation Data Model. Relation is about how everything is connecting to one thing or everything, unlike property which is assigned to be fixed to an object.
- For example, if Date is only the property to JournalObject, we won’t be able to say the EmotionObject marked on JournalObject is the Emotion of the Date.
Currently, this advantage of relations is most obvious in Sets. Users can decide which relations they would like to call out, e.g. to show descriptions or not, tags or not. And with views, users can use different display different combinations of relations. This might be one reason why many users work with tables.
The benefits of relation data model for note-taking:
- Data integrity: if we change the name of Apple to its Spanish word Manzana, it could reflect in all objects displaying apple
- Structural consistency: wherever we put ‘last modified by’ relation, we would be able to go to the same place to find this relation, instead of searching every time.
- Single source of truth architecture: we won’t have a client name in ClientList but a different client name of the same client in ReceiptObject, because client name is controlled by only one key; even if we change client name at Receipt, it is modifying the original ClientList.
What is not actualised
Some functions are currently constraining how relation can shine in Anytype, and these makes users hard to understand relations.
- Due to how template currently work, Sequence of relation is different across objects: e.g. In the current relation pane, the same relation can display at different section because some are pinned and some are added but not used, it takes some efforts to find the required relation from all relations
- Name relation in set cannot be hide: Being the necessary data, Name relation feels like the identifier of objects, despite a hidden ObjectID being the actual Primary Key.
- Changes made on canvas and blocks are specific to that object’s canvas, thus data of canvas feelings like reaching an end and could not be reused, unless bulkily convert blocks to objects.
- All relations are permanently connected to the Object as Primary element. It is not possible to assign or display foreign elements
– For example, on ApplePie recipe object, apple might be the Ingredient (relation), and to see if buying apple is needed, stock of apple is required from the Storage data (foreign to recipe). For housekeeping, price of purchasing apple is required from Shopping list (foreign to recipe and storage).
– Being able to link foreign key will should resolve collection-specific relations and part of the need for multi-type e.g. Grape for both RecipeType and TaskType.
– Apple is primary key; date and apple together are composite key to purchased price. ← composite key works hand-in-hand with build title from relation. - Sorting doesn’t always work with consistency, and definitely doesn’t work with object-supported relation: because except ObjectID which is meaningless, there is no assigned sequence except in foreign tables.
How to improve
Although using relational data model for everything might be too processing heavy, if we already use such model, we might as well actualise it.
- Create a relation for canvas or blocks, just like content preview, so flexible allocation of blocks are possible.
- Make template into a modular retrieval mechanism and relation, instead of application mechanism (which should act an alternative way to resolve re-application of template)
– In other words, allow structuring of canvas without actual data. Simply use Relation as key/element to predetermine the display location of future-data. - Convert library to schema/element library where users
– Create the above mentioned (point 2)'s new “template”
— Determine sequences of displaying relations across the whole Anytype
– Figure out relation’s Normalisation, dependencies (which is also good for multi-dimensional relation)
– “Template” could also be where users determine if they need to address foreign keys
– Might need to be addressed with renaming library. - We might need be able to see the keys to each group of data fields.
- We would need to assign field as identifier for keys, like NameRelation as identifier or disambugator or unique object.
- (Optional) Indicator of element being an exceptional case. e.g. This Book object doesn’t respect the Book ‘template’ rule.
Relation and Graph
Another benefit or relation is that they can be used in different manners when they are retrieved differently. Taking Excalibrain plugin in Obsidian as an example:
- When given logic of relations, it is possible to ask graph to display the relation in a certain way.
- We can infer or assign nature of relation/link as parent/child to display the object in a lower position. This way users can create their own tree hierarchy if they need so.
– Anytype could explore more connection logic or even allow users to self-define connection manner by allowing users to allocate objects by direction, axes, middle object (for via logic) and missing relation.
– Sidebar would be a good place to change graph setting to see how relations changes dynamically when relation changes its display format.
In short, relation as a modular element that can be reused and if we can demonstrate its functions within the Anytype system itself, Anytype will be become even better.
Remarks
- Thank you for reading. Hopefully, I didn’t misunderstand anything and I explained these well
- This might be complex to implement on local computer and still maintain a codeless design.
- This might require structural change in Anytype, sorry that I am probably making things difficult again
- I won’t be making separate feature requests of above ideas because separating them would not create a comprehensive approach and I couldn’t visualise how all these could be implemented with above mentioned existing feature requests.
