TL;DR: Functionally, there should be little-or-no difference between top-level containers1 ("groups") and lower-level ones. However, it may be useful to allow users to give semantic labels2 to different containers, and – ultimately – to use those labels to affect how the UI displays containers and their contents.
I think part of the problem is that notebook can be used in two similar – but to my mind distinct – ways. One potential use is as part of the functional description of how your program should behave; the other use is to do with the semantic2 meanings a user may assign to different levels of information.
Functionally, your program should3 be able to arrange notes, and collections of notes in hierarchies of the user's choosing (together with
#hashtaging for linking without regard to the hierarchy).
Above, I said "one potential use [of notebook] is as part of the functional description". The reason for the qualification is that – at a functional level – there essentially are only two "things": containers1 and notes. Notes are the "leaf nodes" of the hierarchy (where information is stored); containers make up the rest of the hierarchy and can hold both containers and notes.
As you rightly suggest, having a "different type of thing" for top-level containers (with a different name, e.g. notebook) is almost certainly the wrong thing to do™.
There should be little-or-no difference between a container at the top-level of the hierarchy and one that's seven levels deep. Any container, whether at the top level or not, could be moved into another container, and any container (within an existing container) could be promoted to the top level.
Semantically, though, I think things are different. A user may find it useful to "categorise" containers at different levels of the hierarchy. As such, they could (should?) be given the option of both labeling certain types of containers4, as well as naming specific instances of a container. For example:
In a physical filing systems, documents (=notes) may be organised into folders5, wallets or pockets; these in turn may be held inside suspension files, lever-arch files or box-files. Suspension files may be stored in filing cabinets.
A large document (whether physical or electronic) may be organised into chapters, sections, sub-sections etc.
You might collect a number of thematically-similar documents together to form a volume, a workbook or a notebook.
You might gather a collection of notebooks onto a bookshelf.
Such groupings, especially for an evolving collection of knowledge (as a user might attempt to capture in a note-taking application) will tend to change over time. A user might initially create a notebook called "User Experience", in which there are just a small number of individual notes on various aspects of UX (usability, accessibility, responsive design etc.). As the body of knowledge grows, notes may be grouped into their own sections. As sections grow, they may be "broken out" into individual top-level notebooks. If the collection of "notebooks about UX" starts to get lost among other notebooks, you might move them all to a new top-level container(labelled bookshelf), called "Books on UX".
It probably goes without saying that containers, at any level of the hierarchy, should have a user-specified name/title. Whether you also allow containers to "have a type", and exactly what "having a type" means, depends on how complicated you want to get:
The "type" could just be a semantic label that a user can apply to a container to help them better understand the hierarchy of information. Functionally, a "notebook" would behave no differently than a "bookshelf" or a "chapter", but consistent use by the user of the different types may allow them to navigate more easily.
- This option would have almost zero overhead, other than storing a "type" against each container.
- While there may be predefined types, user could freely add their own type-names.
- You probably don't need to worry if a user chooses to have a container they've labelled "bookshelf", inside a something they've labelled "chapter", inside a "book".
The type could be used as part of an enhanced user-interface: certain container types (e.g. bookshelf, (note)book) could be displayed as such. Functionally, there would still be no essential difference, but the enhanced UI would emphasise the semantic differences.
- There would be a much larger overhead to implement the enhanced UI.
- Users could still be allowed to add their own type-names, but only predefined ones could be displayed differently.
- You may want to store extra "meta-data" against certain container-types. Books might have a colour setting, and/or a front-cover image; bookshelves might have colour or "style" settings.
- You would have to decide whether to allow "silly" nesting or not (e.g. a "bookshelf" being moved inside a "book"). I'd probably allow it (the user may be about to change the container-type), but you would need to make sure the UI doesn't do "odd" things if they do.
Of course, all this may be too much if you're aiming for a simple note-taking app. If so, decide on a single name for your containers and stick with it. "Group" or "folder" are probably as good as it gets.
1 I'll be using containers for "the things that can contain other things". Obviously this pretty much corresponds with your term groups, but – I hope – reduces any functional/semantic blurring that "groups" might carry.
2 I'm not 100% sure semantics is the right term. As (hopefully) can be seen from the main text, I'm using it to cover the potential user-assigned meanings to different levels of the "information hierarchy". If there is a better term for this, I'll happily edit it in.
3 I'm taking it more-or-less "as read" that there should be a hierarchical structure. While it is not the only way of arranging information, the fact that hierarchies are so ubiquitous in both computer and manual filing systems is a strong argument for such a system within your note-taking application.
4 Here, "types of container" is purely semantic. At a functional level, all containers are the same; at the semantic level, some of those functional containers will be "acting as" a notebook, some will be acting as a document, some as chapters etc.
5 All links are for illustrative purposes only: I have no affiliation with, nor do I endorse, any specific product or Amazon.