ostrta-spec: "One System To Rule Them All" Specification

ostrta-spec

#ostrta-spec

"One System To Rule Them All"¹ Specification

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.

#Introduction

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

#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 they have worked well enough that I thought they may also be useful to others. So I decided to post them up publicly for discussion while I continue with further experimentation and development.

Although I have certainly implemented many of the things discussed here (which hopefully should be published soon), I would not suggest for others to commit too much to building on top of the "specifications" discussed here until they reach wider adoption and consensus (i.e., get hammered out a bit better). Mainly at this stage I am looking for other adventurous, experimental users (and people who care about the issues at hand) to essentially try some of these ideas, in order to see what works and what doesn't and why. And to share those experiences with one another.

This is also why, for now, there are no version numbers. I will start posting version numbers once I feel that either or both the following are starting to happen:

Some consensus is coalescing.
Some number of implementations are beginning to appear.

#Goals

To come up with some common set of useful, general, free and open, and easy to implement standards, guidelines, and/or best practices 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 each time all by ourselves.
- To have a single, easy to point to place on the Internet where said information is all laid out (i.e., this page). Or at least a place to focus discussion and further develop ideas.
The end goal being able to improve the ability to store and recall various sorts of information / data 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

Listed roughly in (descending) order of importance:

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

Karl Voit makes an important observation³, which I 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" (longer?)) sort of archival system upon is one composed 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. In other words, those which are (generally):

already existing
widely available and standardized
- ISO, IETF, and many other widely accepted standards
but most especially, non-proprietary

Examples of things meeting these criteria are:

plain text
- todo.txt
- Orgmode
standard file and folder based naming
email
free and open image and document formats
F/LOSS tools
Sourcehut ;)
Gemini and similar "small web" protocols
etc.

#Timeline and ISO-like dates as Identifiers

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 when processing incoming photos⁴ 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 see that several of these recently popular Zettlekasten implementations seem to have noticed the same thing. One of them even made the point that there is some research supporting the notion that something relatable (like a date based ID) gives much more context to a human than something like a long random UUID. This idea resonated as being true with me, and that influenced the (IMO, easier on the eyes than some of Zettelkasten ones) format I chose for the Timestamp-ID spec.⁵

#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.

Disambiguation notes SHOULD 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.

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.
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.

#Specifications

Moved here.

#Projects Implementing OSTRTA Specification

The only one I am currently aware of:

My own Emacs Lisp (reference?) implementation of OSTRTA, which I hope to publish soon(^TM). When I do, I will link it here.

Kindly announce on our mailing list if you are working on anything!

#Underlying Ideas and Additional Resources

Karl Voit, already mentioned a couple times in the General Concepts as his ideas were quite influential.³
Getting Things Done (GTD)
todo.txt
F/LOSS software generally, but GNU Emacs specifically. And perhaps Orgmode most of all.⁶

#Footnotes

¹ 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.

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

³ Managing Digital Files (e.g., Photographs) in Files and Folders by Karl Voit

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

⁵ Not only that, but an email I sent to the Orgmode mailing list asking about allowing customizing format of date based IDs as another option for org-id generation actually ended up making it in to Orgmode!

⁶ 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! :)

~trs-80/ostrta-spec