ref: 36ae36caee7df529c2a8182ca3cb605550d34238 ostrta-spec/README.md -rw-r--r-- 7.3 KiB
36ae36caTRS-80 Remove stupid gigantic ToC heading 1 year, 18 days ago
  1. ostrta-spec
    1. Introduction
      1. Current Status
      2. Goals
    2. General Concepts
      1. Timeline and ISO-like dates as Identifiers
      2. Relying strictly on F/LOSS and Lowest Common Denominator formats
      3. Controlled Vocabulary
    3. Specifications
    4. Underlying Philosophy / Ideas



"One System To Rule Them All"1 Specification

Copyright 2021 TRS-80

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the file COPYING.


This project contains the OSTRTA "Specification"2 which aims to be a generally applicable (implementation agnostic) set of specifications (and/or some best practices) pertaining to organization and information management.

If you are looking for the Emacs Lisp implementation of OSTRTA, it can (soon!TM) be found in the (as yet unpublished) emacs-ostrta project (working title).

#Current Status

I have been developing and using many of these concepts (and additional ones besides) for quite some time on a personal basis and I think there is something worth sharing here. So I decided to post it up publicly for feedback while I continue with further experimentation and development.


  • To come up with some common set of useful, general, free and open standards that many different people can implement in whatever language(s) they prefer, such that we don't all have to keep re-inventing the same wheels over and over again all by ourselves.

    • To have a single, easy to point to place on the Internet where said standard is all laid out (i.e., this page) or at least a place to focus discussion and further the development of ideas.
  • The end goal being able to improve the ability to store and recall various sorts of information in a more useful, reliable, and/or convenient way.

One of many inspirations would be something like Vannevar Bush's Memex, but let's not get ahead of ourselves here. Currently we are just trying to agree on some simple file naming conventions. :D

#General Concepts

#Timeline and ISO-like dates as Identifiers

This is one of the central concepts. I had struggled for years to find some suitable organization method for certain types of files (mainly photos, but there are some others) until I came across Karl Voit brilliant concept of using a timeline and "ISO-like" IDs.

For several years now, the very first step I take in when processing incoming photos3 is to use the sortphotos Python script on them, moving and renaming them into a consistent format (because too many phones and cameras have inconsistent naming schemes). I can then add tags, descriptions or whatever on top of that stable base.

Eventually I realized this is a really good way to generate meaningfull IDs for lots of different things, and now I use it all over the place. In the meantime, I noticed several of these recently popular Zettlekasten implementations seem to have noticed the same thing.

#Relying strictly on F/LOSS and Lowest Common Denominator formats

Karl made another important observation, which I also agree strongly with. In both our views (and many others, too) the only sane way to base any sort of long-term (i.e., "the rest of your life" (or longer?)) sort of archival system upon is one comprised strictly of Free Software.

In addition to the above (and for same reasons), we should also only use what I have come to refer to as "Lowest Common Denominator" formats and protocols: those which are already existing, widely available and standardized (but most especially, non-proprietary). Things like plain text, standard file and folder based naming, email, etc.

#Controlled Vocabulary

The essential notion of Controlled Vocabulary (CV) is to select items from some list rather than entering them free form, in order to eliminate typographical and other errors. This mostly applies to things like tags but the concept could be extended to many others.

  1. Disambiguation notes live directly with CV items

    Disambiguation notes are simple reminders to yourself like "use tag1 for X" or "no tag2 is for Y, for Z use tag3 instead" etc. It is a simple form of metadata management.

    Additional disambiguation notes should be contained directly in the same place you are choosing the CV item from. This can be implemented in a language-specific data structure, or, preferably in a "CV file" which we propose as a (very simple text file) specification.

  2. Gardening

    CV items (as well as their intended meanings) will inevitably change over time. We refer to doing maintenance on these items as gardening.

    Tools should support gardening workflows like:

    • easy mass renaming of all instances of an individual CV item
    • searching for orphaned (no longer used) CV items
    • generating statistics (counts, etc.) on CV item usage
    • etc.


Moved here.

#Underlying Philosophy / Ideas

I have been a bit of a Personal Information Management (PIM) geek for about as long as I can remember. Therefore I could probably write quite a lot here. But I will try and just point out the main highlights.

  • Karl Voit for many PIM concepts around tagging (like "gardening", and others) but probably most of all for the "timeline and ISO-like timestamps as IDs" concept. He also shares with me the notion that the only sane way to base one's long term archival methods upon should be based strictly in F/LOSS.

  • Getting Things Done (GTD)

  • todo.txt

  • F/LOSS software generally, but GNU Emacs specifically. And perhaps Orgmode most of all.4


1 Unlike Sauron, I don't actually want to rule over anything. It's just what I started calling my own PIM system privately since a long time now. And it seems reasonably unique (last I checked) and catchy enough to be referred to and found on the Internet.

2 Using that term quite loosely at the moment! ;)

3 Similar (some times manual) methods apply to other forms of media which do not contain embedded creation dates.

4 In fact almost all the tools I implemented so far (and mostly not even released yet) which are following these specs have been extensions to Emacs and/or Orgmode. Stay tuned! :)