When you signed up on Substack, you joined a small but growing community of people who care about how we organize our digital thoughts — semantically, locally, and on our own terms. That trust means a lot.

Now it’s time to take things to the next level.

SEN is moving to its own self-hosted platform — a new /home where the blog, forum, docs, and community all live under one roof at sen-labs.org (still under construction but getting there). No more third-party silos. Your data stays on a server we control, fully GDPR compliant, encrypted, and transparent. This makes it easier to link all the aspects of SEN in one place.

To continue receiving updates and be part of this exciting next stage where SEN gets real, I need you to confirm your subscription on the new platform:

Yes, keep me in the loop

While you’re at it, please consider supporting the project, which is completely funded by my own personal time and money.

No action needed if you’d rather not move — you’ll simply stop receiving emails from the new source (just manage your Substack subscription here).

What’s coming next:

• Fresh articles on the new SEN blog

• The OnSEN forum — a place to discuss, ask, and share

• Deep dives into SEN’s semantic architecture

• News from the PKM and Haiku communities

Thank you for being part of this from the early days. See you at the new /home.

Gregor from sen-labs.org

PKM Summit 2025 in Utrecht was a blast - SEN, my semantic desktop dream, hit the stage for the 2nd time. It’s local and private, but on demand also global and connected, and lets you build simple custom applications. Read on for an overview and some insights into what made people excited - and stay tuned for the slides and a video recording of the talk!

Short Intro on PKM Summit 2025

PKM Summit 2025 was a blast, vibing with my tribe, getting a lot of positive feedback and meeting extraordinary nice and knowledgeable people, having fun and being nerdy - refreshing, exhausting (including late-night coding to get my demo finished…) and inspiring. Ticket for 2026 is already booked. There are and will be much better write-ups about the conference, so let me just focus on why you are here: SEN :)

I have been given the wonderful opportunity to present my project SEN again this year, this time with a prototype under my arms, and a nice friend helped me with setup and recording a video of the presentation.

Being a professional software developer (with over 20 years of industry experience in different settings, sizes, environments and domains) and mingling with non-developers from various domains, using tools to actually get things done ;-) is always a refreshing reality check.

This keeps me grounded and brings me back into a healthy balance between my vision, aims and curiosity, playing with cool and nerdy stuff, and some real world use cases and needs by actual people that want to use software for professional needs.

Mingling with mortals (just for the pun;-) also shows some insights and potential misconceptions that I strive to correct or at least uncover, in this case: the never-ending fetishization of tools and methods at the expense of interoperability and flexibility.

Nicole van der Hoeven also pointed this out in the closing panel discussion, and I couldn’t agree more.

The (current) Tool-Centric Approach

The love for Tool X (let’s call it Obsidian) reminds me of the age-old debates in software engineering, with heated discussions over what editor to use, Emacs or vim (I love nano;-), or now Atom/Zed vs. VScode vs…

The file/document format issue was fortunately settled early in software engineering, concluding that TEXT was a universal format that could be enriched as needed but still be readable and writable in any tool. This is also why versioning and merging changes between developers of all kind works so well. It does not matter if you work on Mac, Windows (now that it finally supports Unicode…) or Linux. Neither your editor of choice makes any difference. In the end, it’s all text.

That revelation has also made it into the knowledge management world with the discovery that a (mostly Markdown based) text files-approach is the most flexible and open solution to manage notes. This was also made popular by Obsidian’s “file over app” approach - but this is only “half the rent”, as we say in Austria, meaning it’s only half way through towards the finish line of a real solution. To put it more bluntly, it’s not enough to really call it an open solution, and here is why:

All your precious notes may be stored as text (using Markdown and some magic metadata), but they are still bound to a specific tool: mixing metadata with the actual data is never a really good idea, and all the less if it contains SQL like queries or “data views”. The format may be open, but the logic is strictly tool-centric and - even worse - you rely on external plugins that only work with the tool you currently favor.

Without the tool and its magic plugins, all your links and queries, reports and drawings will be useless and hard to export. The Tool still has control over your data, not you. All the work you put in to connect, label and organize your data is still bound to a specific tool, and you have to use plugins to make that tool work for every use case you need (drawing, writing, planning,…).

Just look at these cute little tools here - all keeping the information (not the text data) to themselves, never really sharing in a usable way, and leaving out the poor guy to the right:

Lastly, due to limits in current systems, these tools force you - at best - to keep all your data in TEXT format, but not all data is TEXT. In the excellent talk, PKM Across the Semantic Spectrum, on the PKM Summit 2025, Larry Swanson brought up an important core mantra of the semantic web, which also applies to the domain of Personal Knowledge Management:

Things, not Strings.

Initially coined by Google when introducing the first known enterprise knowledge graph, this means that you should add semantics to your data, not just keep everything as untyped, generic text. This makes search much more powerful and flexible, and keeps the meaning of the data that is valuable to you.

The Data-Centric Approach

Contrast this with a truly data-centric approach, which is a central design decision by SEN and its underlying OS, Haiku:

There is a common infrastructure that extracts, enriches and connects your data on your behalf, stores that metadata separately but still attached to your files in the filesystem.

Now, all this work has to be done only once and be accessible to the entire environment, including *all* your tools. You will never loose, it, since it’s stored as part of your files and any application can access the open metadata format (filesystem attributes, like key/value maps)

Now you have something like this:

Native File Types to Represent your Data

Now, consider a system that is not only data-centric but also natively supports semantic file types, so you can easily map objects of your domain directly into your PKM system, without complicated tool-specific type systems or plugins - just good old file types provided by the system, which you can even modify and adapt with the default filetypes system settings?

Files are not simple technical containers for documents or media files but can represent anything and have custom properties: not just text, but drawings, calendar events, all kinds of media, even abstract types like Books or Places. Even classification is done with files that act as placeholders and connect data you label with them. You can navigate relations right from the file browser, like from an Author to Books in your library:

Imagine managing your book notes as linked text notes which reference real Book files that have an ISBN attribute, subjects, genre, page count and publisher, and a link to its Author(s).?

Now imagine, going further, that you can freely search for these custom attributes, e.g. searching for Books of a certain genre, matching given subjects or directly check if you own a Book with a specific ISBN?

SEN is the first PKM system that supports all this right from the desktop, interacting with existing data and tools, but not locking you into any method, tool(set) or plugin-configuration. SEN is an infrastructure, not a tool, thus providing a horizontal, integrative and data-centric approach as opposed to a vertical, tool-centric approach with increasing complexity growing with every plugin you add. And even better, it supports automatic lookup of metadata, e.g. Book information from OpenLibrary.org (which is part of the Internet Archive).

Take your tools into the Future

No need to throw away your tool set, it’s hopefully just Markdown text files with some magic sprinkle dust to overcome limitations of outdated current systems and act as a bridge to something better: SEN with native support for Entities and Relations.

If there is enough interest and support, I will prioritize Markdown support in SEN, allowing you to navigate your relations right from the file browser, searching for notes based on metadata, and even perform the queries hidden in magic YAML Markdown metadata right from the system’s Find panel.

In the coming weeks and months, I will integrate support for other use cases like managing and navigating research papers via DOI or ISSN, or managing your local movie or music library. The wonderful thing of a data-centric and powerful but easy-to-use system like Haiku+SEN is that you can build your personal ontologies for your own needs and use them from within any tool, even just your everyday file browser, and navigate local linked data in your filesystem with SEN.

The coming summer will be the SOS - Summer Of SEN, where you will finally be able to try out a Tech Preview and get your hands dirty with the semantic desktop of the future.

If you are willing to try out an environment that is actually designed for knowledge work and which is simple, elegant and fun to use, performant and open source, then you are welcome to join the ride… who knows, maybe SEN would even run on your current OS at a later time, but first the vision needs to materialize on fertile ground…

How can I support SEN?

Glad you asked - the first and easiest would be to upgrade to a paid membership plan via this handy button:

Subscribe now

(maybe even get a full-featured founders membership that will give you some perks like personal thanks in the About dialog or early builds for local testing…)

Then, the project is open source and I am building in public, so you can star and sponsor the project right from within Github:

SEN Labs on Github

That’s all for now, still need to rebuild myself after an intense time (preparation and the conference itself), stay tuned as the future of the semantic desktop for personal knowledge management unfolds!

So at the last day of the year, it is time for a recap and a quick update on what happened with my passion project SEN in the meantime… considering the previous (first and only) blog post was in January, you could be deceived to think the project stalled, but quite the contrary…!

This is just a quick overview and write-up about my year with SEN, more detailed insights will follow as I work on the individual parts in the coming weeks and months. Please don’t hesitate to ask questions, give me feedback and - at this stage, most important - consider upgrading to a paid subscription to keep the SEN momentum going!

Getting Serious

After a slow start (recovering from a burnout that got me in the 2nd half of 2023), things got in full swing with my admission to the first summit on personal knowledge management, the PKM Summit 2024 in Utrecht that was held in last March.

Preparation for the talk got me really motivated to finally start coding, so after a successful and very inspiring 2 days in Utrecht (see below), I was really eager to start coding… this has sadly led to a lack of updates in the blog, only the occasional note made it through. I promise improvements on that matter in 2025 as a new year’s resolution.

With fresh energy and motivation, I was finally starting to make quite some progress on all components of SEN. I was focusing on various parts of the infrastructure in an agile manner, prototyping ideas, concepts and validating designs. I can now proudly say that the design holds and a tech preview is not far off.

Let’s look at some activity graphs from SEN Labs Github repository - yes, all components are now open source, but not final. Everthing is still heavily work-in-progress, but I decided to go all in and #buildinpublic (yes I’m also active on Bluesky now and enjoy the friendly and open, science-friendly geeky community there:-).

Looking at the code frequency graphs of individual SEN components prototyped so far and arranging them in a stacked manner, I can really provide an excuse for my lack of progress updates here - except for a much needed summer break, I was busy coding, not writing (see abovce):

The activity started in April, right after the conference in March. Spikes indicate my focus on various components of the SEN infrastructure, which can be summarized under the acronym SENSEI:

• Structure-

• Extraction,

• Navigation,

• Semantic

• Enrichment and

• Identification

I had some profound revelations during the prototyping phase (see “Re(ve)lations” section below) and adapted the technical design accordingly. Since I was moving fast, I could adapt quickly and did not have to care about compatibility, documentation, testing and all that other pesky stuff (that makes a usable product…;-).

I could also confirm that it was the right decision to build SEN on the foundation of Haiku, a very lightweight, fast, modern (filesystem wise but also considering various usability features that are still as innovative today as it was 25 years ago with Haiku’s origin, BeOS). While it is a niche OS, it provides everything needed to build a local, semantic desktop infrastructure for linked-data handling and personal knowledge management. Time, funding and your support will tell if I can ever port this to a more common OS, but for now I’m happy with Haiku, which is now almost ready for everyday use with the arrival of a promising IceWeasel port (basically Firefox sans telemetry).

Building in the Open

Recently, as mentioned above, I’ve gone all in (or rather out) and decided to release all code I am actively working on, which includes - as of yesterday - also the actual sauce which is sen-core, on the official SEN-Labs Github repository. This makes it easier to share code with the interested community for feedback or questions, e.g. when I’m not sure if it’s a bug in SEN or in Haiku, or a driver. It’s also more serious to put skin in the game and be completely transparent on the progress, which gives the project more credibility, hopefully, for funding and also makes some of you consider upgrading to a paid subscription… (my only paying subscriber was scared off by the lack of updates, so I really need your support now, every paid subscription counts!).

SEN at PKM Summit 2024

After a much needed hiatus in the second half of 2023, I kickstarted the year with going all out and speaking in public (for the first time:-). I took the chance and got the wonderful opportunity to speak at the first PKM summit in Europe, the PKM Summit 2024 in Utrecht, NL.
You can find the abstract in the archived timetable on the PKM website.

To put it short, the conference was a blast, lots of open, curious and friendly people. Conversations flowed naturally and reached from international small-talk (it was quite a mixed group) to deep and serious knowledge-management topics.

I am glad my presentation was well received (only some 25 people in a small room, but I was competing with - the - David Allen of GTD fame, so I’m happy:). It’s not a mainstream project, after all, and requires some unlearning and rewiring, but with great rewards…

Re(ve)lations

Revisiting SEN and starting implementation for real, I realized - much too late, but better late than never - something important about relations in SEN:

Previously, this was still a bit magic and I only had a concept of linking - like symbolic links, but SEN provides semantic links - using a separate configuration and the (message-based) SEN API to handle filesystem attributes for managing and resolving relations using native filesystem queries. I had not really thought this through all the way and was not looking forward to all the work needed to adapt the file browser Tracker as needed to support relations.

Turns out, I was again thinking too complicated, and the solution was so easy - since everthing on Haiku (in good old UNIX fashion) is a file with a MIME-based file type, why not make Relations also a special file type? This would automatically ensure Tracker displays them transparently, including relation properties in the details columns, like so:

This would have another nice side-effect: plugins to handle (and resolve) relations, including support for deep linking and target navigation (i.e. navigating to the relation target and doing highlighting or other useful actions for relation navigation, like jumping to a quotation in a referenced document) would be as easy as defining the plugin as default application for that relation file type!

Relation Configuration

To configure relations, users can resort to the standard Haiku FileTypes preferences like so (using the custom super type “relation”, which is just a convention and perfectly legal in this context):

A plugin is then just a simple native application (could even be a Python script with some wrapper code) that supports the relation file type and intercepts the call to the actual supporting application to resolve relation properties accordingly. In the document referencing use case, some note might reference page 42 in the PDF document my-paper.pdf. Tracker detects the reference relation and resolves its target through the SEN API. The relation is either resolved via context menu (“Open related…” → RelationType → Targets) or through the Tracker relation targets window (as seen above).

A Note on Relation Views and Folders

At first glance, it may seem quite a stretch to show relations as files in a separate “folder”, but if you think about the actual concept of a folder, it seems more consistent and intuitive:

Traditional folders also model a relation - a very simple one that is commonly misunderstood and consequently misused, causing all the trouble involved like duplicate files, crowded folders and the symptomatic “cure” of desktop search clients, nowadays even AI enhanced…

Folders model a Parent→Child relationship. This is true from the desktop UI down to the technical level, where you navigate to the pseudo directory .. to reach the parent directory. This was a simple and elegant solution that worked just fine when we had diskettes with 1.7Mb or hard drives below 4Gb and not many files lying around (even then it was already getting confusing).

With the arrival of cheap hard drives (and now even SSDs) in Tb sizes, this concept began to show cracks. Users tried to “organize” their files into folders, but that honorable effort was soon doomed because it breaks the original semantics of a Parent→Child relation that folder still hold. What users actually want to do is Categorization and Labelling, not technically moving files under a specific directory.

This creates all the issues we see in current desktop usage, and the time has come to end this misery, because even the best desktop search or AI assistant is not a cure-all for bad organization and design deficiencies of the underlying system.

With SEN, you can have truly dynamic classification and organisation in virtual “folders”, which contain relation targets for a specific source. This in addition to the already powerful file system based fast Queries available in Haiku by default - which act the same way and are used for showing new mail messages (also file based), contacts with specific properties, or other user defined reports. SEN transparently blends in and just adds some semantic spice to the already powerful desktop environment.

As a more advanced feature, SEN also supports self relations (pointing back into the source, like a “Contains” relationship). Here you can see PDF bookmarks being extracted dynamically in realtime and shown as contained relations that can be viewed and navigated just like other relations:

Now the file system really becomes a database, or rather a knowledge graph, and the UI consequently acts as a dynamic query tool and information space. Relation views and Query results are just like database results, and persistent Queries act like database Views.

Using Relations

Users just invoke relations like any other file, and Tracker resolves the default application for that relation via the standard OS file system API. The DocumentReference handler receives the actual target document, invokes the document’s default viewer and - through some integration code, preferably native Haiku messaging - jumps to the referenced page by inspecting the relation properties provided in the relations attributes.

This was way too much detail for a yearly review, but I didn’t want to make you wait longer for this corner stone of SEN’s technical design, and you read too many standard yearlies already:)

Once this blocker (in my mind) was removed, I could continue with the broader topic of how to configure entities (like Books, Movies or Papers) and their relations.

Ontologies in the Filesystem

An integral part of any linked data / knowledge management system - and even more for a semantic infrastructure like SEN which is integrated with native file types and the file system - is on how to set up a consistent way to handle entity and relation definitions.

I have thought long and hard about how to strike a balance between a simple, easy to use system that is still true to semantic principles like consistency and well formedness but can still be configured and extended flexibly so users can tune it to their needs.

The solution was again in using already existing native tools and formats, in the case of Haiku, Resource definitions, which are text based and easy to write and version, and which can be converted to native file types via the system tool rc, a native resource compiler.

Resulting resources can be converted to file type meta definitions (again using custom metadata storec in filesystem attributes), and installed as file types, which show up in the system’s FileTypes preferences and can be configured if so desired.

Now the only remaining issues were:

• how to install file types from resource files without requiring a reboot

• how to include plugins

• how to keep track of installed entities and relations

For a short-time solution, I developed a shell script to keep track of installed entity and relation types by using the power of SEN relations and a custom Ontology file type. Eventually, ontologies will be packaged as native Haiku packages per entity and per relation, which allows me to use the existing infrastructure for dependency declaration and installation management.

The issue with having to reboot was solved by developing a little tool to access the MIME type API, so the file type can be installed directly. This will be integrated with the final solution later.

A bigger issue to deal with is on how to grow the system in a consistent and interchangable way, so that SEN ontologies can be exchanged and evolve without breaking stuff. Package management helps to clearly define dependencies (Relations need to define which Types and Attributes they support). But Attributes need to stay compatible and use standardized names and types. At the same time, users should be able to adapt the configuration in some way. Most of the time, they won’t need to and this is left to developers taking care of defining a consistent set of file types.

I intend to apply well established API design principles like backwards compatibility through never deleting or restricting properties and only add new ones. Since ontology packages are versioned by design, compatibility can be guaranteed by defining version dependencies between components. With some sane guidelines and common practices, developers can then easily build ontology packages and distribute them separately from SEN via standard Haiku software repositories.

Using the native package and software distribution infrastructure has the added benefit of keeping dependencies and complexity of SEN core minimal, while providing maximum flexibility to ontology designers. People are free to include AI libraries and models of different sizes for relation and entity extraction, for example.

First use cases

Since SEN is still hard to explain but easy to show - there is always this “a-ha”-effect when people see it in action, no matter how well you explain it in words - and also to validate my design decisions, I developed some use cases which I think would make SEN useful to interested people.

Book Notes

My personal favorite and one of the triggers to develop SEN in the first place (over 20 years ago, mind you) was to allow easy and consistent tracking of notes on books I have read, want to read or have read/heard about.

When you work with a data-centric desktop system like Haiku, it becomes natural wanting to manage your stuff as abstract files and define file types for your real world (or virtual) entities as you work with them in the digital world, like digital twins (but this has now become more of a manufacturing term).

Taking a step further with SEN, you can even define useful relations like Quotation, Authorship, Publishers or other notes on the same book, related work etc. You could even reference Topics, Projects or other categorization with SEN Meta handling coming soon.

A nice touch is that you don’t have to enter all the book metadata yourself, just an ISBN is enough and a suitable SEN plugin will do the Enrichment (one of the E’s in SENSEI mentioned above). For now, I did some prototyping with a simple Python script that takes an ISBN and looks up all the book metadata in a free online service, then creates a Book file with the book’s metadata stored in the file’s custom attributes, including the cover image, which is then used as icon - and voilà, you have a simple personal library management system!

You can use the standard system wide Find dialog to search for a book via ISBN, Title or Author:

Other use cases to follow in the next update…

SENity: a simple semantic notepad

From the beginning, a long time goal of this project was to build a universal notebook on top of SEN that shows the power of truly semantic filesystem powered linked object notes beyond Markdown links between text files (desktop wikis existed in the early 2000s already).

So in November, I have finally started to take an open source Markdown parser, put it into a customized TextView and add some magic. The result is SENity, an editor for your thoughts:)

This is not yet another plugin-ridden text editor with a browser inside (I don’t really like Electron and other web technologies for desktop apps that are supposed to be small and fast), but a fully native C++ hand crafted beast of an editor that loads and renders a usual Markdown text file in an instant.

The editor is also developed in the open but heavily work-in-progress (it does not yet support actually editing the text, for example, so it’s more of a viewer now, but all the underlying preparations are almost done and the editor understands the various parts of the markup. Here is a first look (highlights and annotations will be supported first):

A nice AI generated logo will soon be unleashed when the basic feature set is done:)

Milestones Achieved

So to wrap up 2024 finally, SEN has seen a lot of progress and love, including:

• Tracker (file browser) integration

• Semantic navigation (deep links) via plugins including self references

• simple ontologies based on native FileTypes

• book notes use case with a simple Library using enrichment and relations

• a simple Markdown based text editor with semantic linking (highlights, soon entity links)

• some PR: Presentation and Feedback, a fresh web site!

• devs rejoice: fully open source all code on Github!

Short Outlook into 2025

As of tomorrow, I will tackle these:

• funding (need your support!)

• finish SEN core and Tracker integration

• finish first preview of SENity editor

• prepare a first tech preview (VM + live USB)

• more use cases, including AI based entity extraction

• documentation!

• open source it all (core missing, rest is already built in the open)
  already done! see SEN Labs@Github

That was much more than a recap but you deserved it - see you in 2025 and please support my work as you can! Prosit Neujahr :=)

This is the first in a series of posts about my personal vision to implement a semantic desktop for everyday use, building on a modern, (meta-)data-centric open source OS, Haiku. There are many reasons for targeting this nic(h)e OS (outlined below), and many unique use cases for such a solution, but the primary focus is on personal knowledge management (PKM), because I think the “personal” part gets lost in the myriad of online and commercial services that popped up in recent years.
Most of these are controlled by single companies that often charge steep subscription fees1 and may “pivot” or disappear at some point (yes, I’m looking at you, Evernote). Exporting your data when migrating services often looses information (metadata, cross-linking, formatting) - leaving a glaring gap for a true local-first, desktop based solution for organizing and working with all the stuff that gobbles up your laptop’s disk space and use the vast array of tools already available there...

Before you shout “niche”, “desktop is dead” or “there is already a tool for that”2, let me explain what is so special about SEN, which stands for Semantic Extensions and is more of an infrastructure (with many implicit use cases that don’t need specialized apps) than a yet another tool(box/suite).

A Very Short History and Comparison

Semantic Desktop on Linux: KDE NEPOMUK and Baloo

Since my initial thoughts on such a semantic desktop 20 years ago in June 20033, some progress has been made in the form of preview/detail panes in file browsers, and the open source desktop KDE went as far as integrating the full breadth and weight of semantic web standards in a EU funded project (NEPOMUK). This resulted in a promising solution but ultimately failed because of the sheer complexity of using a full-blown search index (Lucene) and database (semantic triple-store Virtuoso), which introduced a heavy performance impact (all the more painful with the hardware at that time). UI wise, it was also was too complicated to use and seemed more targeted at people familiar with the underlying semantic web standards used (RDF, XML,…).

Eventually, NEPOMUK was replaced with a more light-weight and stripped-down approach, Baloo, which focuses on file indexing and search but otherwise does not provide any semantic functionality like relations or deep links into applications (more on that below). Baloo allows extracting metadata from supported file types and indexes them along with file names in a database like storage file4.
Unlike BeOS/Haiku (see next section) and therefore SEN, Baloo cannot utilize extended filesystem attributes (often called “xattrs”) for storage, as this would face several problems caused by the otherwise desirable and powerful pluggable nature of systems like Linux5, and the way metadata is treated in different abstraction layers:

In some ways using xattrs is 'the right place' to put this tagging info, but Linux doesn't have a 'core API' that would allow a 'xattrs preserved by default, and interpreted consistently' policy. Therefore there are a lot of ways to lose your tags. KDE has been trying to make this work for many years, but it is difficult given the way UNIX/POSIX has evolved.

source: https://userbase.kde.org/Baloo#Baloo_and_extended_attributes

Since you cannot guarantee the consistent treatment of filesystem metadata across all the available desktop environments and tools, they might be overwritten or removed at any time (e.g. GNOME’s gedit will silently remove them upon save, and most other tools will too, since metadata is often “forgotten” when copying files). Even in KDE alone, applications use different ways to handle metadata, e.g., the standard file manager Dolphin embraces xattrs, while the (excellent!) photo management app digikam uses its own index (but can at least synchronize with metadata contained in the header of photo files using IPTC or EXIF standards).

This results in a limited and very heterogeneous solution that falls short of a unified, efficient and data-centric approach for consistent, transparent and unobtrusive personal information management, as needed for a semantic desktop of today.

MacOS: Spot on or Spotlight?

MacOS was always special in handling files and metadata, not only regarding resource handling of Apps, but also in providing color labels (which can be renamed to more semantic and useful names instead of just the color name), which allow a simple categorization of files but cannot be extended since they are hard-coded into the OS.

Later, it gained one of the best desktop search engines with Spotlight (which was developed by Dominic Giampaolo, who originally engineered the exceptional BeOS filesystem, see below). Much like NEPOMUK and Baloo on KDE, this mechanism indexes files for easy search and preview, but doesn’t go beyond that. It does not know of any inherent relations between files and does not allow users to add them manually.

Finally, MacOS is not really data-centric since even the stock Notes application uses a database instead of keeping notes in files. This makes backup unnecessarily complicated and users cannot access their notes without the app, which can be a bit sluggy at times (I really had issues with it once as it wouldn’t come up and I kept my work notes there, so no personal backup in place).

MacOS does provide the best integration possibilities in a mainstream OS though, e.g. the Services infrastructure that apps can use to provide functionality that can also be accessed via scripting. One example that utilizes inter-application scripting is Hookmark, which provides a streamlined commercial extension to provide deep linking between applications and certain supported file types.
On the downside, it is Mac-only, commercial and closed source (with the drawbacks outlined above), and stores links in a separate folder, which needs to be carefully handled upon backup, restore and migration. It does not (and to my limited technical MacOS knowledge cannot) transparently extend the system with native file relations stored in file system attributes. In summary, the system feels a bit tacked on as an afterthought, e.g. also file templates are managed separately instead of being natively provided (like in KDE or BeOS/Haiku).

To sum up and circle back to the creative punny headline, MacOS is great for everyday use and light knowledge work, but does still not provide a data-centric, transparent and open platform for personal knowledge management.

Conclusion

In this first post, I could only briefly cover existing solutions to provide some context and a starting point for the main actor of this Substack, SEN. If you are interested in more detail and want to dive into the full breath and depth of SEN right now, including a technical description of its internal architecture and realization, and also want to support me with this project even more, go ahead and grab a copy of the generally interesting first book on personal knowledge graphs (PKM(, aptly named Personal Knowledge Graphs, at the official book website or from any major online shop (epub for now, print to come soon). SEN is covered in a separate chapter and is just one of the many insightful and interesting pieces on the topic of PKM.

What I really miss in today’s landscape is a native, data-centric desktop system that treats entities and their relations as native files and naturally forms my personal knowledge space, without breaking the flow, introducing a schism between different systems or tools, and does not force me into yet another closed shop with is own data silo, visualisation and Ux paradigms.

Instead, a transparent and open personal information infrastructure should integrate seamlessly into a user-first existing desktop system, adding just what is necessary to provide the missing (semantic) links, and keeping everything in the file system, treating entities and relations as first-class citizens, rather than as an afterthought.

Embrace Change: Enter BeOS & Haiku

A Short History and Overview of BeOS

In the 2nd half of the 1990s, BeOS came out of nowhere and was in many ways 15-20 years ahead of the competition (just look at the official demo video and compare that to other desktop OS’s of that time…). It was a completely fresh approach with a new kernel, a modern metadata-driven filesystem featuring indexed custom attributes for fast and dynamic queries (sounds familiar? see the note on Spotlight above), a message-based API also used for inter-application-communication, pervasive multi-threading, and all that in a slick and very responsive UI that made Windows 95 look like GEOS on the Commodore C64, which was already available in 1986. Even MacOS looked quite old in comparison (actually, as you might already know, before Steve Jobs returned to Apple and brought his creation NeXT with him to become MacOS X, there was a serious chance that Apple would acquire Be and make BeOS the basis for its next-gen OS).

From a knowledge worker’s perspective, the highlight of the young and excitingly fresh take on a desktop OS that really dared to think different, was its data-centric approach, with a completely new filesystem that natively supported custom metadata stored as extended attrbutes attached to files, and in the way it treated data as individual entities that could be handled and manipulated without specialized applications. This means that data was free and open to user manipulation (e.g. through the flexible file browser Tracker. Data could be exchangable between applications through the OS filesystem API and was not tied to a specific application, and even scripts could access them easily via Shell commands.

The real power was in the easy customizability and the direct, user-friendly visualization and interaction design, esp. regarding the special features around custom file types (to represent any kind of entities like Books, Media, Mail or Contacts). For example, you could quite easily build a simple DVD library without having to resort to a special application, just by using the system’s FileTypes settings and the stock file browser, as detailed in this workshop.

Keeping your information this way is very intuitive and straight-forward, but that is only half the battle, as you know - the real power of knowledge management lies in finding the right information at the right time. Now, the power of native, filesystem based custom queries comes into play, which is illustrated in the screenshot below:

In a similar way, managing personal contacts is as easy as creating a file of type Person and filling in the relevant information, which is kept as standard metadata in the file’s custom attributes:

Phoenix reborn: Haiku

Although Be, Inc., and BeOS went the way of many things too good to be true (they even had convinced an OEM to ship PCs with BeOS pre-installed), it was also too good to die, and a group of open source developers and BeOS lovers got together to build Haiku (as also repeatedly covered in the news). This is a clean-room implementation of BeOS, based on publicly and legally available information (including the legendary nerdy newsletters, API docs,…).

Haiku not only recreates the experience of BeOS but also brings it to the current state-of-the-art in terms of hardware support (including new architectures like ARM or RISC-V), and software management (it has its own package manager, inspired from the best but adding its own twist using filesystem-based overlays, similar to ZFS/btrfs snapshots), as well as bugfixes, optimisations and extensions of the API (faster messaging, new functionality) and user interface (SVG like icons, modern font rendering etc.).

Not reinventing the wheel, developers work closely with projects like FreeBSD (for driver support), also actively contributing back, e.g. to GCC, or Webkit for the native browser NetPositive (think Safari but there is some room for improvement still).

Finally, with a native port of Qt, KDE applications like KOffice and standard apps like LibreOffice are also available, massively extending software support for everyday use.

Gravitating towards Minimalism

Alltogether, this provides a very attractive platform for knowledge management, albeit targeting a niche OS. However, this can be a blessing, esp. for knowledge workers, keeping free of distractions and the noise of ad-loaden mainstream systems.
Just look at the trend towards minimalism in software, like NothingOS, which is monochrome and strives to be low-noise and distraction-free.
This trend is even happening in hardware, check out this deliberately restricted hardware project.

Given the sleak minimalism of Haiku and its native approach to information management, it makes a very compelling prototyping environment, and possibly beyond that.

In my next post, I will finally introduce you to SEN and how it integrates with the modern filesystem and API of Haiku to realize a modern semantic desktop with native semantic links on an infrastructure level.