‘Compiler’ is a real word 
Although, isn’t using a verb, rather than a noun, placing emphasis on the transient action of the feature, rather than the result of that action, which is the enduring Object?
To give more weight to @Code-Jack 's concerns about search term confusion, I will give an example of searching for “Anytype Experiences”. Google assumes I want to read about user reviews vs workspace templates. Meanwhile a search for “Anytype Templates” results in object template vs a workspace starting point.
I personally would say with “Sets” as it is not claiming to be a database and it keeps the search history of the community forum.
It’s definitely hard to find a simple metaphor that world across global languages!
@Angelo, don’t mix up “Compiler” and “Compilator”.
The word “Compiler” is too much connected with programming, so we shouldn’t use it; it would cause misunderstandings.
“Compilator” on the other hand, comes from the Latin and means “plunderer”. A compilator is someone whose work essentially consists of collecting already existing works or quotations (from other authors).
The result of such work is called a compilation.
In my opinion it describes the function of the new combined Object good.
Same as with “Collector”. Both are good names, I think.
.
I don’t see the result in the Grid, List, Kanban etc. as “enduring”.
There are changings every day. Mostly the list grows, but we also reorganise items, we create new Views with new filters and so on.
So, for me, the new Object is the tool to do something.
It can also do things on it own, when it collects Objects like we know it from a Set.
So it is an active tool.
A printer shouldn’t be called “print”.
A plotter shouldn’t be called “plot”.
“Lister” would be OK, but definitely not “List”!
“Compilator” would also be OK, but not “Compilat” or “Compilation” (which is the result).
“Compiler” is already occupied by computer languages as the tool for compiling source codes, that’s why we shouldn’t use it.
“Compilator” hasn’t this disadvantage, we could use it.
Whatever will be chosen in the end – I strictly vote against “List”!
This would be the most bad choice imaginable!
This topic has been turned to the name of the ‘List’. Instead of being about a missing feature related to ‘Lists’, I suggest that the moderator move these replies to a new topic.
To be honest, I’m a big fan of ‘List’ or the reuse of the ‘Set’ name, as @ThatGuy mentioned.
‘List’ could be problematic, as @Code-Jack mentioned, and because there might already exist an object type by the name ‘List’. However, for other issues, ‘List’ can grow within the community. When you search for anytype list tutorial, it will be associated with Collections/Sets not for other things. the rest of names I’m not fan of it because it feels very technical.
Using terms like ‘Project set’, ‘Journal set’, or ‘Goal set’ feels very natural to me, even when using the word ‘list’.
But imagine words like “Project Compilator” , “Journal Compilator” it just feels off
All the previous words provided either don’t sound best, or misconstrue what this new object actually will do/will be. I think using the name “Collection” would do. The point of the merge is to allow any present sets to become collections, after all, so I think just renaming them to be the name of the more ‘powerful’/usable/flexible object out of the two makes the most sense, and is the simplest solution. Occam’s razor.
Although I prefer “sets” (because it implies structure), I agree with the general principle. It would IMO be a mistake to try and invent a new term, which would have no context for newcomers. Better to use an existing term whose meaning is generally understood and which could, in itself, be something of a guide for new users.
Given the proliferation of suggested terms, perhaps it’s not Occam’s Razor that we need, but Occam’s Lawnmower 
You could make a solid case for sets, too. Adding to the fact that it implies structure, it’s also shorter and more therefore more catchy. I’m fine with either, really 
(though I do lean ‘Collection’.) But so long as it’s not a new and potentially more complicated term.
And yeah, his razor won’t do 
maybe a scythe!
“Lister” is not a noun that is easy to understand. It may technically mean “something/someone that lists”, but in practice English speakers will be “huh? what is a lister?”
List is great because anyone, techy or not, can understand what it means. The main drawback, which some have already mentioned, is that there are already to object types called “bulleted lists” and “numbered lists”. So this may add confusion.
I actually really disagree with this.
Both sets and collections are databases: they are both organized bodies of objects. The fact that “sets are saved searches” doesn’t make it less of a database; and the fact that “collections are groups of items that are linked” doesn’t make it less of a database.
Both are databases, grouping and organizing objects. The difference between these two is only about how we arrive at these databases: one is by searching and saving the search (sets) and the other is by linking the objects (collections).
So “database” would be a fine name for this feature because:
- It is technically accurate
- It is relatively easy to understand for non-techy users
- People who come from popular tools like Notion will understand it immediately.
That being said, my personal favorite is “collection”. This is what Slite use, and I find it even better than “database”:
- It is technically accurate: the new collection/set will collect objects
- it is the easiest of all (other than “list”, which is less technically accurate and more confusing) to understand for non techy people
- Because it’s so easy to understand, people who are used to “database” will be able to immediately understand it (I had my team transition from Notion to Slite a few years back and the transition from “database” to “collection” was extremely smooth)
By contrast, “sets” has been one of the most challenging concept to internalize for new Anytype users, so I would definitely steer away from that.
But this is true only for the first time someone hears or reads it.
Same as with “Set” and “Collection” and “Space” and “Relation” and so on.
One needs to learn all these terms.
In case of “Set” and “Collection” and “Space” and “Relation” … it is even worse (then with “Lister”), because these terms are all a bit misleading and they have multiple meanings.
We all know about the never ending confusion about Set and Collection. And our “Relations” aren’t really true relations (yet) – they are more input fields for storing parameters then anything else.
And on top of that: all these non precise words have multiple meanings, what causes a lot confusion.
Explicit and exclusive names with no second meaning could save us from all these confusions.
As a newbie I was scratching my head all the time about the wird imprecise naming scheme.
A newbie must learn a term like “Collector” only once. From then on there will be no confusion with other things and no irrelevant results in the forum’s search.
.
Now about “Database”:
In my understanding would this word fit for the whole Space.
What here is called a “Space” is in fact a whole database.
A Set or Collection on the other hand, contains and shows only a part of that database.
It makes for me no sense to call a part of the data a “database”.
If you disagree with me, you could also call a Relation for Tags “database”, because it stores some data (the list of Tags). Seen in this light, it’s the same as with a Set or Collection. It makes no sense to call them a “database”.
A database is the whole thing which contains ALL data.
A backup of “the database” should contain ALL data, not only a part.
Off course one can have more then one database (respectively “Space”). But each of them is a separate “universe” on it’s own.
I respectfully disagree with you, @Code-Jack. Now, if you are suggesting a better word to replace Space with Databases , I believe that would be even worse. In my opinion, Space is not misleading; it simply refers to a continuous area and aligns well with the concept of a Graph view.
And as for ‘lister,’ it reminds me of the name of a person. Just imagine calling your elements things like ‘Project Lister,’ ‘Goal Lister,’ ‘Journal Lister,’ or ‘Page Lister’. It’s not necessarily bad, but personally, I would prefer not to use that term.
Thanks for your kind words, @GrayArc . But I also respectfully disagree with you.
You know, I have no big problem with Space vs. Database. Both is OK for me although I think that Database would’ve been the better fitting word. But no big deal.
Set, Collection and Relation are better examples for not well chosen words. But also not a very big deal.
What I vote hard against is “List”!
For me this word is obviously so wrong that it seems totally goofy!
Again: you wold a printer never call a “print”.
You would a singer never call a “sing”.
You would a player not call a “play”.
More then that: in the Collections and Sets Layout Views we already have a List View (beside Grid, Kanbas and so on). How to deal with that fact? Should they have the same name?
What we see in the List View is in deed a list.
But the complete Collection/Set is not a list. The Collection/Set is the thing which shows us gathered data in its Views as lists.
.
I find it totally OK.
A Collection/Set for journals could be called a “Journal Lister” instead of a “Journal Collection”.
What’s not OK with it?
.
As a non native English speaker I’m not in the position to argue so much with all of you native speakers.
But the fact is also, that my mother language German is much more precise than English. We “Krauts” have more and longer words for all the stuff, because we must have everything as clear as possible.
Maybe that’s the reason why I have a stronger view on all the terms then English guys.
My impression is that I notice small inconsistencies more and that I’m also more bothered by them.
You’re all used to English terms being ambiguous.
But for me “Kraut” it’s downright sacrilege when ambiguous words are used as names for certain things.
I think I have enough explained my points of view.
It was good that we discussed it in a respectful and constructive way.
Now it’s on the native speakers to decide wisely.
What about “CompAny”? 
Space - “AnyVerse”
I’m not native English speaker either. But I’m already Said I’m fan of reusing Sets too. in my previous reply. and I feel this topic take a turn to change every term in Anytype. /:
That’s a great point. Between that and “numbered list” on the canvas, “List” would end up adding confusion.
I disagree. A database is the structure that holds the data; there are rules that define what data is held, how it is held and how the individual items are connected.
A set is a view of the content of the structure.
A collection (in Anytype terms) is simply a (potentially random) group of linked objects - there are no rules that define what’s in or not in a collection, other than the whim of the user.
I disagree with this as well.
- It’s not technically accurate
- It’s misleading for users (because it implies that there’s a real thing as opposed to an artefact of searching/linking)
- It’s a “false friend” for ex Notion users, because it suggest that it operates like a Notion Database and, as Notion users have found in the past, it doesn’t.
All that said, this is a matter of opinion and I doubt we’ll aver arrive a term that we all agree on.
Just to understand.
This “futur object”
- can be used in the same way as the current set (i.e. to “search” for elements without associating them with this object, basically a view or a saved search)
- and can be used as the actual collection (to store objects that will be linked to this object)
- and views (current displays) will always be declensions of this new object, as at present
?
This is true. A Space is the closest analog to a database/container/folder in the Anyverse
Correct. Accept with much more adaptability than they currently exhibit.