RT @FisFraga@twitter.com
The secret behind @tana_inc@twitter.com:
Software Engineering principles applied to Note-taking.
↓ Such as the Class Diagram ↓
Don't worry if you're not a Tech person...
I've got a Master's in AI – I got you covered.
What is a Class Diagram: 🧵
(+ How it helps you understand Tana)
Your notetaking app is an end-user database.
Which means:
Picking a notetaking app is like picking a database. Different ones have different paradigms and box you into modeling the world in different ways.
Taking notes is like modeling data
For instance:
Tana is like a document database with graph-like relations, and optional schemas, similar to MongoDB.
Notion is like a traditional relational DB, where relations are modeled as foreign keys.
Roam is like a schema-free triple-store.
Instead of starting with classes and then define their relations, start with relations and model them as "protocols", then objects play roles defined in those protocols.
Instead of building a complex structure of classes, let them freely implement protocols. You can, for example, extend protocols, so you structure protocols instead of classes. This is supposed to be a more flexible approach.
In Tana you would have for example the superclass Person and the subclass Author, the latter can be used as value for the Author key of Books, Quotes etc.
All authors are persons but things like this can get complicated, what if later you want an organization to be an author too?
In POP you would have Person that implement the role of Author in the relation of authorship.
Later you let Organization implements authorship on its own.
I know but that was not the point.
The relation Authorship could be defined as a protocol implemented by two instances that play the role of author and work respectively.
For example a Theorem could have a Name, a Book could have a Title and to implement the role of work you need something with a Name or a Title.
A convenient way to do so is Theorem/Book both implement Authorship protocol (as work) by passing their Name/Title as the name of the work.
This is just an example but as the schema grows situations like this could become a mess to manage.
I prefer Logseq, Free and Open Source Software, open formats and protocols, local files and offline-first, especially when it comes to personal data.
I consider Tana Inc. as an unofficial R&D department and Tana as a nice experiment but nothing too serious :-)
Of course Logseq is not supposed to be used only with Datalog by design: that is just an additional feature for more advanced users (and indeed they are called "Advanced Queries").
There are already Simple Queries but they plan to ship a graphical Query Builder.
There is a huge difference in laying solid foundations for a highly flexible *tool* and build a *product* around a good intuition or two.
I definitely see Logseq shipping a Query Builder and other features by Tana in some months, while I can't say the same with Tana becoming FOSS and local or even just supporting Markdown, PDF annotations, whiteboards, plugins etc.
@post @andric I understand your advocating.
I consider Logseq, especially the #Datalog language for queries, a tool not designed for the masses that are not programmers like me. I would call that also an experiment for a niche target.
Time will tell us.