First on general understanding between properties and relation, I have previously written posts on the discussion of terminology, especially in post 35 which explain some scenarios which might erode the boundaries between the concepts of property and relation. To quickly recap, property is a static and/or definitive component and Relation is a dynamic and/or situational component.
- In data structure, if we are to limit a data field to be functioning as property only, we wouldn’t be able to extract only certain part of all fields. However, if we address the data as dynamic first, we could be able to label the field as “must have”, logic/hierarchy = subordinate, and elasticity/movement = 0 to indicate the data to be property.
- In comparison to this complex approach, saying that it is a property is probably the most straightforward approach, and it would be great if we could ignore the complexity when it is not needed. However, rather than constraining the function, smoothing UI/UX in Creation of Relations from scratch (e.g. by assuming simplicity) would empower both use case.
As for users’ confusion, I agree the current relation performs more like relation, yet I believe this is caused by the yet-to-be actualised components of relational data model. Hence I have written a post on Reason why is hard to understand relations and how to improve, with relational data model.
- Status is an interesting field to discuss. Under relational data model, we could be referencing (thus relating) a foreign list of status data. At this point, we would still be utilising status as property (just a different retrieval mechanism). However, there are a lot more we can do, if we expand the potential of relations.
- For example, using graph for action plan, we could allocate connection force to the different statuses. Most urgent task can be displayed with the shortest connection force to the actionee. So if we see a lot of task rushing towards or clustering around a person, we could divert the workload to another colleague.
- Also, if we have richer functions of relation, we would then be able to address both Ability to reorder tag / status options, and sorting not working with object-supported relation together, as have a place to manage all properties of relations.
- Following this approach, if we must replace the name of relation, “field” or something similar, would be the way to go.
I will be honest, this approach is complicated and probably hard to implement under a codeless design, and I don’t expect Anytype to have everything soon. However, if the potential of relation is to be castrated (sorry for the strong language), a lot of my note taking needs would not be achievable.
Side Note: Thanks @damaru for mentioning mathematics. Remembering the concept of Set in mathematics, I could finally understand Anytype’s set and collection.