Terminology and Concepts

General Discussion
, , , , , , ,
1

Update: an official list of terms has been shared by the Anytype team here: Document

I notice there are some misunderstandings and disagreements on certain terms used across many topics. I hope we can clarify some common terminology that might be ambiguous. What I’m writing here is not necessarily the right answer, this is just to get the conversation started. Feel free to suggest your own additions to this list as it is not complete.

Anytype specific

  • Object
    A container for Blocks. Not to be confused with a Block itself. All Blocks are (or should be) an Object. Not all Objects are a Block.
  • (Object) Type
    An Object Type defines what Objects (Relations and Blocks) are linked to your Object of that specific Type.
  • Template
    You can define how the contents (Blocks and Relations that should be visible on the Canvas by default and the Layout th should be presented in) of your Object should be presented for a specific Object type. You can define multiple Templates for a single Object type
  • Layout
    There are three Layouts that define a general look and feel of the Object and determine what actions can be taken for the Object. Could be referred to as Template Type.
  • Relation
    Not a relationship, but a Relation. Is an Object itself. All Relations are Objects, not all Objects are a Relation. There is a topic on renaming Relations to something else (Attribute, Property)
  • Block
    A container for actual content. All Blocks are (or should be) an Object. Not all Objects are a Block.
  • Block Type
    Defines the behavior of the Block. Can it be checked, toggled, number or list? To name a few.
  • Canvas
    The place or area where Blocks live together to be the content of an Object. Sometimes referred to as a Page, but right now a Page is an Object Type.
  • Page
    Often used interchangeably with Canvas, but a Page is one of the many built-in Object Type Anytype offers.
  • Set
    A filtered view of Objects that have the same Object type. Currently only an Object but will also be available as a Block soon. In this topic it is suggested to use the term “Search” or “Query” instead to better reflect the Object Type.
  • Collection
    Similar to a Set, but you manually link Object to a Collection, and unlink Objects from a Collection. An Object can be linked to more than one Collection, so it behaves NOT the same as a traditional folder.
  • View
    A predefined way to display Objects in a Set or Collection. There are different kind of views, like Grid, Gallery, List, and Kanban, each with a unique set of features.
  • Link
    This is a clickable text that leads to the linked Object or website in case the text links to a URL. Also known as a hyperlink. Not to be confused with a Bookmark. Indicated by a little icon if the link brings you outside Anytype.
  • Bookmark
    A Block Type that holds a title, a link (clickable URL), a description, and a favicon.
  • Delete
    Get rid of the selected Block(s) on a Canvas. This can only be undone with the Undo feature, but this is limited to the current “session”. After closing Anytype, the actions on a Canvas cannot be undone.
  • Remove
    Move an Object to the bin. Can be undone by restoring the Object from the bin. The Objects remain in the bin until you choose to permanently remove them.
  • Passphrase
    See “Recovery phrase”, conveniently placed right below :slight_smile:
  • Recovery phrase
    The phrase of words that acts as your password for your Anytype account. Use this phrase to login to Anytype on another device. :warning: Make sure to make a copy of this phrase OUTSIDE of Anytype, preferably in a password manager…
  • Space
    Workspace that is either personal or shared. Note: currently, only a personal Space is implemented. Sharing (or “multiplayer” Anytype) is planned for a later time.
  • Passphrase
    Your username and password to access your Anytype account. Note that this phrase is not saved anywhere for you, so you need to keep it somewhere safe. Anytype (the team) cannot access or recover your passphrase. Without your passphrase you are permanently locked out of your account.
  • Pin
    A 5-digit code to lock your Anytype Desktop application. By default the app locks after 10 minutes of inactivity. The pin does not protect a user from accessing the unencrypted data, but rather blocks easy access to the user interface of the application.

General

  • Inline
    Could either mean “as a Block” or “within a Block”. I don’t think there is any consensus at the moment, but the distinction is important.
  • Styling
    The presentation of text within a Block. The styling can be on Block level (applies to all the text within the Block) or on text level (only applies to selected text).
  • Zoom
    All visible content on the Canvas is enlarged and the distance between the contents grows together with the content so the relative distance remains the same. Usually allows the user to start scrolling horizontally in addition to vertically.
  • Scale
    All visible content on the Canvas is enlarged, but the distance between the contents does not grow together with the contents, shrinking the relative distance between the contents. Usually combined with wrapping text and increasing Canvas height (width remains the same).
  • Transclusion
    A live reference or view into another (part of an) Object.
  • Nest
    Make one Object child of another (parent) Object. Can be reflected by indenting the child relative to the parent.
  • Indent
    Start the (contents of a) Block further away from the margin than the main text in the same direction as the text is written (left to right written language means indentation goes to the right). Often used to reflect hierarchy, but sometimes used to just make some text jump out or give emphasis.
  • Shortcut/Hotkey/Key binding
    A key combination to have quick access to a feature or action.
  • Deeplink
    Instead of linking to an Object, you point to a specific location within the Object, so to a specific location or Block on the Canvas.
30 Likes
2

When I explain Anytype to people who don’t use it or know what it does I always use the following terminology;

Object = Page
Like a notion page, a onenote page, etc.

Block = Block
The content you add to your page (object). Like a notion block, a coda.io block, etc.

Set = Database
A collection of pages (objects) of with the same propertie(s) or types.

Relation = Database properties
These are what can be shown in databases (sets) and views, can be sorted, filtered, etc.

Layout = Page Layout
The way your page is shown on the outside (titel, icon, etc). Not to be confused by template

Template
A design of your page and it’s blocks (titles, relations, etc)

Type = Page Type
A way to diverentiate your page or to give your page a main topic.

From my experience Object, Set and Layout are the most confusing for people. Where page is often more clear then object, set is often understand when I compare it to a database and layout is often confuse with template/design of a page.

Just my 2 cents.

11 Likes
10

Thank you @Jeroen, that is incredibly helpful!

I’m a techie: I work in tech, build tech, train people on tools, and try out new tech all the time. And I’m going to be honest, terminology has been the biggest hurdle in transitioning over to Anytype. I love the idea, the values, and the vision for the product, and anytime I try out a new innovative tool, I’m more than happy to wait for features and UX improvements.

But in this case, I simply haven’t been able to transition (from Standard Notes, Notion, Slite) over. The terminology is too confusing (as a side note, this was a big lesson for me: I never thought that terminology could be such a big hurdle in tool adoption–I always thought that strong features + good UX was enough).

I know we’re still in alpha, but my question is this: are there plans to simplify terminology, to make it more in line with what people know and understand?

Just a few changes would go a long way:

  • replace Object with Page, File, or Doc
  • replace Set with Database
  • replace Relation with Property or Field
4 Likes
11

I think Set = Database is introducing more room for confusion. A database is a structure that contains data, like the Anytype application as a whole. Sets don’t contain the data, they behave as Views on the Anytype database. Though given the way they can be used, and the way Anytype is not set up to feel like a database, I don’t think Views is a good name for them either. I think Sets is a perfectly reasonable name.

3 Likes
12

You are right, some things just take time to fully comprehend. I think database was mentioned as an initial point of reference, and are only similar in the sense that they are kind of containers for housing and organizing content. Even though Objects don’t actually reside there, a Set is just gathering them together from all over your Anytype in a single field of view. Functionally, Sets are enduring advanced search queries, which you can customize and dress up.

Collections, which will come in the next version, are much more akin to traditional databases.

1 Like
13

Oh thank you for the clarification, this is helpful. Then I would still suggest renaming Sets, to something like “Views”. Views is a pretty descriptive, self-explanatory word for this concept!

14

So sets are more like queries while collections will be more like databases?

1 Like
15

Views are already used for views inside the sets.

2 Likes
16

Although some of the current relations are indeed property e.g. Intensity, relations are relations, not property though… A inspired by B doesn’t mean A is a property of B nor the other way round…

I think Anytype is quite severely based on the concept of relations linking different ideas together. If relations are no longer relations, graph view would just be gone… Really like the word relations - this is a big reason why I am using Anytype

Terminology is different because it derives a totally different approach. We can’t blame high level thinking for being complex…

2 Likes
17

For this reason, I try to use View in tandem with the relevant source to convey the concept being discussed, ie. Set View, Graph View. So that View options within a Set (Gallery View, Kanban View, List View) don’t conflate with each other, as long as they include the proper qualifier.

Exactly, there’s an inherent curve that people will advance upon at their own pace, kind of like learning a new language. Anytype isn’t a one trick pony, and I often describe it as a workstation of which there are numerous tiers of skill, similar to Photoshop, or a musical DAW.

We’re doing our best to simplify the process and making it more intuitive, and also providing the proper learning materials. I suspect that the Community itself will contribute their own tutorials and guides, as it gains traction among the wild frontier of streamers and youtubers. It’s already starting to happen a bit!

3 Likes
18

While I agree with much being said here I would like to add that Anytype is not complex (yet) but it does require a different way of thinking and that combined with different (or confusing?) terminology makes it feel more complex.

Why I say confusing is that, let’s be honest, Sets are most simular to the traditional databases as seen in currenrt note taking space (like Notion, Coda or Airtable). Eventhough their fundamentals are different.

Same with objects which are simular to the traditional pages or notes in other apps.

Then having (object) types, which are becoming more common btw, give the confusion since there is a page and a note type hehe.

2 Likes
19

I’m finally wrapping my head around some of these concepts. I understand that Anytype is a somewhat different way of thinking (though not that different, the only real difference that I see so far is that there is one global database of all objects and that those can be filtered into sets) and that it requires new concepts, but I do think a simpler terminology would make the app more accessible.

For example, why are Relations called Relations and not Properties? Some don’t even feel like relations between objects (like “creation date” or “last opened date” or “description”). Those are just object properties that are unrelated to a particular database/collection, and definitely not related to other objects.

2 Likes
20

Technically, those properties are relations between the objects themselves and the specific date. So if in the future we get the ability to show dates on a graph, those relations would show up.

1 Like
23

This is one of the biggest things that confused me trying to understand what I’d gotten myself into with Anytype and how I would find my way around. I expect the term “relation” to be the same as a relational database where attributes are only relations if they form a relationship between 2 or more database tables, and they are intentionally set up by the person devising the database schema. In Anytype, I guess just any attribute is a relation. That really warped my mind. I also see what you mean about all the objects being global, but maybe that will be a good thing if it allows more flexibility.

2 Likes
24

From my observations so far, relations and sets seem to be the most confusing ones for newcomers. Maybe the team should really consider renaming them to something like fields/attributes for relations, and queries/ live searches for sets.

3 Likes
25

Yep, I agree, we need a bit more structure here.

2 Likes
26

Hey there! I agree that the terminology is a bit confusing.

Could I just give my understanding and various opinions on it? I’m reformulating things that have already been said but I think there is value in that, and you could correct me if I misunderstood something. :sweat_smile:

One-liner:
AnyType is a complex database with various tools for the user to see and modify their data in the way that fits them.

Core concepts:

  • Object: A wrapper that holds 1. A number of Blocks and 2. Relations.
  • Object Type: An interface that tells the shape of an Object, what properties, blocks, etc.
  • Block: A piece of data inside an Object. I see this as some kind of built-in data type in a programming language. Here those are Title, Link, Heading, etc.
  • Relation: A relation between two objects or one object and some arbitrary data. I have trouble defining it more than this.
  • Set: A view of Objects based on a query on the database.
  • Collection: A view of manually linked Objects.
  • Graph View: Another kind of view on the database, this one displaying links between Objects.

My opinions:

  1. Object Type is trying to do 2 jobs at the same time, being syntactical and semantical as I tried to explain here. I think Object Type should be purely to tell the shape of an Object, and the Tag system should not be nested as a Relation but a first class citizen as Objects and Relations are.

  2. Objects and Blocks should be the same thing. Either an original piece of data, or a view on an existing Object (through transclusion, or a query). That Object can have Tags and Relations. An Object should exist once in the database and we could visualise and edit it anywhere we want with transclusion.

  3. Relation has a strange name. It does not carry much meaning. Anything can relate to anything. I think Property is a better term, even after reading the comments that were against it.
    @C.c says:
    I think Anytype is quite severely based on the concept of relations linking different ideas together. If relations are no longer relations, graph view would just be gone… Really like the word relations - this is a big reason why I am using Anytype.
    I can see that a Set has relations, even though it is not shown in the Graph view. I think that Relations are just properties of an Object and one of these property is the link between 2 objects. When the property link is present, we can see the relation in the Graph View. Otherwise it’s not there. And that property would be set by default for some things, manually for others (like a Collection). I think AnyType already behaves like this anyway.

  4. I don’t think Set is a good term. It doesn’t really convey what it is. I think View or Query are better terms. The term view used within the set (Gallery View, Kanban View, etc) could be replaced by either Display Format or View Type or even simply

Conclusion:

An Object Type would be an interface to create an Object that holds a number of Objects, Tags and Properties.
Each Object in its turn would be characterised by a number of Objects, Tags and Properties. All the way down until we reach the built-in Objects such as Text, Image, Link, etc.

This would allow for the same capabilities that AnyType has today and facilitate transclusion.

What are your opinion on this? Did I misunderstand something, or miss anything?
Thank you for your patience! :heart:

2 Likes
27

+1

28

RELATION

Perhaps property is indeed currently the closest term for anything that relate, but the potential of relation is way higher; and in many case property is not the appropriate word. For example, can you imagine describing your relative being a property of you…:sweat_smile:?

Property is a static component; Relation is a dynamic component.
Feature requests like collection specific relation and limiting scope of relation rely on the concept of relation being a changeable, situational, contextual unit.

Property has a definitive hierarchy to one single object; relation enables multi-dimension and many-to-many usage. This also provides the bases for reusability.

SET AND COLLECTION

Agree on set problem. After reading, explaining on the forums, and using them, I still can’t grab hold onto the meaning of these two words, even though I understand the functions.

TAG

I don’t use tag much because it always confused me what I am precisely doing. But there are probably different approaches to tag:

Understanding 1:
In the language of graph, area of nodes, instead of property and relation. It collects items together as nearby addressing matters. e.g. #work ← This is probably why people expect collection to work like query.
However, this understanding could interrupt the concept of spaces.

Understanding 2:
As theme of contents, e.g. #PKM. If it is a context of fixed hierarchy / taxonomy, this tag should pull out all contents below. ← This adds the difficulties to implementation of richer relation.

Understanding 3:
As related / similar contents, e.g. #anytype #notion, This is an indication of sibling hierarchy / relation. ← this is an example to why relation aren’t property.

I don’t know: author is a tag; object type (e.g. book) is a tag; keyword is a tag; topic is a tag… perhaps that’s why tana called it supertag :exploding_head:. For those of you who uses tag a lot, please add your usage and clarify what you need for it to work :wink:.

P.S. I will also find terminology and concepts difficult if I am to translate Anytype :sweat_smile:
P.S.2 May Anytype pass through the terminology struggles soon and develop something outstanding :muscle:

3 Likes
29

Though I love your example as it made me laugh, I think you misunderstand what I mean. In your example, my relative would not be my property. But I would have a property, which is to be related to my relative. The relation here is reciprocal and in that case my relative would have a property of being related to me. The relation could also be unilateral, let’s say… Unrequited love? My Human Object Catherine has a property of having a love relation to Human Object Heathcliff. But Human Object Heathcliff does not have that relation. A tripartite relation could easily be described the same way with A having two properties of relation to B and C, B having two properties of relation to A and C, etc. This makes it very easy to understand and is scalable, can very easily represent any kind of relation (unilateral, bilateral, multilateral, asymetrical, etc.)

That is what I mean when I think Property is a better term than Relation. I feel that Property has the advantage of representing anything related to a single Object, without dependencies. Whereas Relation can only exist through the existence of a second thing to relate to. Sometimes an Object in a simple case, otherwise that can be a… Date, Text, Status? That sounds pretty murky and confusing to me.

2 Likes