Is your feature request related to a problem? Please describe.
I understand that Relations can be used to define relationships between objects, and that this is a powerful thing. However, from what I understood, their main function is not that. They’re really attributes (or metadata).
For example, the Creation Date “Relation” in each Object is useful even if it isn’t used to describe a relationship. Some “Relations” don’t even allow for creating relationships, such as the Text ones.
Describe the solution you’d like
My suggestion would be to name them “Attributes”, “Properties”, “Metadata”, or something in these lines. This seems to be much more general, and less limiting.
I’m guessing “Relation” might be the technical term for this. This suggestion is purely from a user perspective. It took me a while to understand what Relations were because I kept thinking they only described relationships between objects, when really they are something much broader.
@lynxlove This might be because I still don’t fully understand AT, but I wonder if this distinction is necessary?
Aren’t these two structurally the same?
Object “Movie” having Attribute “Director” equal “Tarantino”
Object “Picture.jpg” having Attribute “Exposure” equal “2s”
PS:
Come to think of it, isn’t everything an object? So even the Attributes themselves are Objects.
“Director” above is an Attribute, but it’s also an Object (or at least a potential one).
Maybe “Director” is used as a boolean Attribute elsewhere, such as in an Object called “Roles I need to have for my next movie”.
So when you open the “Director” object, you might find some notes you took about this profession, maybe with some pictures etc, and you will also be able to see everywhere you use that object, and how.
Indeed, I strongly agree. I’ve laid out a whole case for changes to the database terminology internally with the team some time ago.
I think there is an understandable desire by the team to differentiate what they’re doing, and what Anytype is capable of, from other existing and often more limited approaches. For example in comparison to Notion, Anytype is more powerful in some respects. However I think you cannot communicate uniqueness + value simply by using new or alternative words. It is better to start with the familiar and then define differentiation from it, e.g. “Attributes for objects allow you to not only store data, as in traditional systems, but also to create meaningful relationships to other objects, such as “parent” or “author””. You start with a familiar term, “attribute”, then briefly describe how Anytype’s version is more powerful or otherwise different than other examples. But in doing so you benefit from all the context of understanding that many people have with some common terms in software as “attribute” or “property”, etc.
Anyway, I definitely agree. I’ll copy my comments over from Telegram as well, for what it’s worth (this is in response to @lynxlove ):
@Oshyan I just realized I missed this reply from you. I’m still struggling to understand how this forum works, I guess.
Good point about the “proliferation of things”. Though I think it would be less of a problem as it seems, since (1) suggested attributes would always be limited to the ones already set to a particular type and (2) there would be just one instance of each “thing”, even if it can be used in different ways (for example, a “thing” called “Director” can have its own content, but can also be used as an Attribute “thing” under a Movie “thing”).
Good to see that this is already a topic. And not only what Oshyan wrote, but especially that “relation” has the everyday meaning of “association”, describing the type of the connection between the objects. On the assumption that Anytype is for everyone (not for mathmetics or informatics only) I also say that the wording is not suitable.
I basically joined this community in order to look for this post and upvote it.
The distinction between objects and relations between objects is a useful one.
An object is more than its ID. It does have metadata, e.g. creation date, and properties (attributes, fields) of different types (e.g. text, number, and relation). This is not a loose collection of related simple objects, it is a rich object with a structure.
A property is a relation when the referenced objects belong to a set in AnyType.
A set of creation timestamps makes no sense. A creation timestamp has no meaning in isolation, it belongs to an object. Similarly I don’t think a set of all text fields makes sense.
The most valuable aspect of Notion (Coda, AnyType) is that of collections of related sets (or tables). I don’t think it’s helpful to blur the meaning of relation by using it for object properties. A relation is one type of property.
I agree, there are more suitable terms that could be used than ‘relation’, which confused me as a new user. “Relation” in English refers to how two or more things are connected. Different objects can be related, as in they can have some “relation” between them, but only if they share a common property. To call their properties ‘relations’ because of their potential to share a connection with other objects is a kind of abstraction I wager is not very intuitive to the average English speaker.
Though I could live with ‘attribute’, ‘property’ seems to me to be the most clear and immediately comprehensible term in English to describe the function ‘relation’ serves: it is a attribute, quality, or characteristic of an object.
Here’s an example in a different context to understand the distinction better: A nose is a property of a face – it is an ‘attribute’ or ‘feature’ of a face. It is not in any commonly understood way a ‘relation’ of a face. You could in some sense understand it as a feature or property of faces which many people have in common, and in that abstract way call it a ‘relation’ of the face. But again this is a narrow abstraction that is not intuitive, I suspect, for the average English speaker or user of Anytype.
Anytype devs: please once again consider this suggestion to use a different term to improve your product by making it more intuitive to understand and adopt.
Hi. As a novice I struggled a lot to understand the meaning of “relation”, also because in the world of SQL databases “relations” is a union between the same property of two different tables (here “objects”).
I therefore completely agree with what Jean and the others have said. Obviously the term to be used in replacement is not very relevant, “attribute” or “property” are two good alternatives.
I could not agree more. As a former DB and OOP (Object Oriented Programmer), seeing ‘relations’ whilst defining properties in a type (or in OOP a class really) just makes me wanna grit my teeth.
Even I, a programmer of 25 years find this incredibly confusing.
As others said aptly, using new language just to differentiate and confuse nearly everyone is not helpful. I love anyType, for many things and I vehemently despise the use of ‘relation’ for property.
And make note, once you make objects out of the classes and link them, yes, then you can talk about relationships.
But the anyType team uses them back and forth - sometimes the relationship is a property, sometimes it really is a link to another object…it is super confusing.
For example, when setting a ‘relation’ for a set, you are really setting a property or a class (type). When setting a filter, there you are setting actual objects and can talk of relationships.
There is also concepts that not everything is a ‘type’ really. in OOP we have ‘primitive types’ - enums, strings, chars, dates…and then we have more complex structures, which are classes.
I do however understand one cannot bring the jargon of programming to the UI because it could be overwhelming to users. But in the case of what ougt to be properties, it seems almost universal among users that the word ‘relation’ does not apply. Cheers
At least use the same term in one language. In German localization, for example, three different terms are used for relations (depending on platform and context menu).
I can only agree that naming properties relations is creating confusion. I get that Anytype wants to be its own thing, but I believe that renaming known concepts creates a barrier for new users. I myself still need to translate relations to properties in my head.
Oh dear… are team really planning to change the name of relation to something else? Seeing that we now have a planning tag with this post…
Although I know the community really have different opinions on this, I am a big fan of relation… if it wasn’t relation, I wouldn’t have even started and continued to use Anytype. Unless (1) the new name captures the essence of relation much better than relation itself, or (2) there are more to be implemented to the relation system and thus the current relation would be degraded to property, I might sadly need to consider dropping Anytype (but encryption is still a relatively enough reason for me to stay…)
I’m also a developer. A lot of programming terms like “Set” and “Relation” have roots in mathematics. I would argue that it would be good to keep the semantics of these terms consistent with those meanings, even if some would find that “jargony” or technical.
One issue I think is that we only got Date as an object recently. Also you have items like Status, which are connected to nothing more than a list. In most tools, that is treated as a Property 99% of the time. While it would be technically possible to make each status an object itself, that approach would only add unnecessary complexity in the name of correctness. You could argue that Status is shared across multiple objects (like a Relation), but even then, it functions more like a shared property.
Because of this, I feel “Relation” is only correct in a few cases. In most cases, these are better named as Properties. Imo they should consider renaming these to Properties, with Relation being one type of property among others.
Even if Relation is technically correct, if the term confuses most users (and a simple explanation like “they are like properties but across all objects” clarifies it) then renaming it to Properties may be worth considering just to make onboarding easier.
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.
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.
