[ezst]

I wouldn't put Trilium and Logseq in the same bucket, I spent quite some time with Logseq (and Obsidian, and SiYuan, and Joplin, and Anytype and some commercial offerings like Notion) before settling with Trilium, so I can pretend having quite the comprehensive view round the topic.

How I would describe Logseq is that it's an outliner (it relinquishes the concept of folders in favour of pages containing nested blocks inheriting form their parent's block/page properties). It's possible to structure information hierarchically using (hierarchical) tags/page prefixes, and it's possible to use templates to instantiates new pages with predefined attributes, but Logseq metadata model is manually managed and potentially (probably) inconsistent: changing a template definition won't change its page instances, defining a parent block/page attribute without a value doesn't imply/suggests that its children will override/provide a value for it… Maintaining libraries of "things" (people, locations, events, …) is a manual job, and it didn't take me long to realize that the tool was giving me more work to do than was helping with it.

Contrast that with Trilium, which has even simpler and more effective principles: everything is a note, and notes can be nested. Notes can carry (optionally inheritable) attributes, in such a way that all metadata within a subtree are guaranteed to have attributes and properties from their parents (e.g. all notes within "People" can have "Name" and "Date of Birth" attributes), and, as expected, adding after the fact new properties to the parent automatically propagates to the children. Polymorphism (notes specialization) can be achieved following the same principle by placing notes under dedicated hierarchies (e.g. "Colleague" can be a subnote of "Persons" with specific properties like "Department" and a constant value for "Company"). Notes can co-exist (like symlinks) in multiple hierarchies at the same time (so you are not bound to a "top-down" or "linear" organizational model). And on top of that you can create new notes (and notes hierarchies) by composition instead of by inheritance (like "traits composition") by defining a note as having multiple templates. Trilium makes all that spontaneous (doesn't get in the way), explicit (you can easily explain why things are the way they are) and flexible in case you later find a more suitable structure for your notes.

[t235a]

Thank you for sharing. My thoughts on Trilium are similar to yours, would like to know your views on Anytype.

[ezst]

Sure! I wrote some about it recently: https://news.ycombinator.com/item?id=38793540

tl;dr: the sync/live editing is very impressive, and that's encouraging if it ever wants to become a collaborative tool (would I ever have the need for one), but the way attributes are managed is manual and inconsistent. A reply to my comment says that they are putting some thought into the problem, so I'll definitely keep an eye on them and see what they come up with.

At their place, I would:

- do away with the current templates implementation, it lets you define attributes at template (=representation) level and at type (=model) level simultaneously. I'm also unconvinced that a type needs multiple competing ways to be represented

- consider organizing types as hierarchies with attributes inheritance as a core principle. Done right, it could address one of notion's biggest shortcomings and be a more approachable Tana's "supertag"

- consider letting template blocks be annotated as to prevent type instances/objects to change their layout too much (that's something Trilium doesn't have due to its rudimentary editor and which I sometimes miss), this could also be used to configure how inheriting types could alter (or not) the base type's layout

- imposing all new objects to be typed or at least suggesting a type to derive from. Changing the type of an object isn't easy (I don't remember if even possible), so it's probably good to encourage the user thinking about it upfront