Here follow (in alphabetical order) some more detailed notes on implementing some of the general concepts.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
For a conceptual overview, see the Controlled Vocabulary section in General Concepts.
By contiguous, we mean that spaces MUST NOT be used.
Underscores, camelCase, PascalCase, etc. MAY be used instead within CV items.
An implementation of the concept of including additional disambiguation notes directly in the same place you are choosing the CV item from, in a simple plain text file format.
Using common example of selecting tag(s), the plain text CV file implementation we propose looks like:
tag1 tag2 <- tag3 tag3 use tag2 instead
Each CV item (i.e., "tag") MUST appear at the beginning of each line.
CV items MUST be separated by newlines.
CV item MAY be followed by OPTIONAL disambiguation notes. If notes follow, they MUST be separated from CV item by at least one space character.
Redirection from one CV item to another MAY be accomplished by way of simple arrow glyph of "less than and hyphen" (
Other than above extremely simple requirements, you are not only free but actually encouraged to use whatever terms, glyphs, etc. make sense to you personally.
In addition to the above:
For storage of tabular data meeting the following criteria:
…we propose a simple yet dramatic improvement to the common CSV file, a return to using basic ASCII control codes which were expressly designed for the purpose, and have none of the parsing and escaping issues of CSV files.1
Can be used as delimiters to mark fields of data structures. If used for hierarchical levels, US is the lowest level (dividing plain-text data items), while RS, GS, and FS are of increasing level to divide groups made up of items of the level beneath it.
Therefore we propose:
^_) instead of the comma delimiter of CSV, and therefore that is what you SHOULD do.
The filename spec is based upon (and closely related to) the timestamp-ID spec.
A simple example (in this case, a photo filename):
The minimum file name considered to be following the spec would be a simple ostrta-id-4 with no extension:
In the Elisp implementation, this simple check is performed by the function
ostrta-filename-p, which in turn uses the variable
A much more detailed definition:
timestamp-id [_description...] [--[tag...]-another_tag...] [.ext]
timestamp-id is the only strictly required part and therefore MUST follow ostrta-id-4 (at minimum) but MAY achieve higher resolution by following ostrta-id-6, etc. See the timestamp-ID specification for further detail.
description is OPTIONAL but if present MUST start with an underscore (
_) delimiter to clearly mark its separation from the timestamp.
The initial delimiter (
_) is not considered a part of the description. It is a delimiter.
Illegal characters throughout the file name depend on the file system. Having said that, I think the project SHOULD endeavour to develop a short list which any implementation SHOULD check against when implementing any sort of (re-)naming function(s).
Besides the above, I think we SHOULD NOT use spaces (personally I use underscores instead) but I guess that does not have to be part of spec.
Note that periods (
.) MAY be present in description. N.B. how we define filename extension (.ext) below!
tags are also OPTIONAL but if present must start with double hyphen (
--) delimiter to clearly separate them from the description.
The initial delimiter (
--) SHALL NOT be considered a part of any tags. It is a delimiter.
Within tags, there MAY be spaces, but again, underscores SHOULD be used instead.
Different tags MUST be separated by a hyphen (
-) as delimiter.
Note that periods (
.) MAY be present in tags. N.B. how we define filename extension (.ext) below!
We define filename extension (.ext) as the last group of legal characters (including letters, numbers, symbols) at the end of the file name after the last period (
This means that extensions MAY be arbitrary length. I get a headache just thinking about the potential implications here, so I would welcome feedback from anyone who has more experience dealing with something like this. In particular I wonder if we should limit it to some number of characters.
At the moment nothing really relies on this anyway, but some day it might, hence me trying to come up with a good definition here.
Editing filename after initial creation or processing:
The optional parts of file name (description, tags, etc.) MAY (and should) change!
The timestamp-id portion MUST never change (after initial assignment / processing).
The intention of this rule is to insure the timestamp-id portion of the filename remains a reliable identifier.
Alternatively, you MAY leave the base timestamp-id there by itself (perhaps only along with the extension) and implement your metadata in a separate data file or even a database (although plain text files are always preferred.3
I have a lot of ideas about how to organize my home dir. I am sure other people do, too, and therefore I am not sure how many of these ideas are appropriate for this project.
Having said that, at a minimum I think we need to have one or more of the all important timeline structures defined therein. Consider the following as an example to spur discussion, rather than any sort of "standard", certainly for the time being.
One thing in particular I noticed so far is that having the intermediate month folders seemed to be more trouble than it was worth in the
~/tmp directory. So I did away with them there. However in
~/timeline, items are much more numerous, so it's useful to have folders for months because each of those could contain hundreds (or more) of files and additional directories.
~ ├── timeline │ ├── 2016 │ │ ├── 01-Jan │ │ ├── 02-Feb │ │ ├── 03-Mar │ │ ├── 04-Apr │ │ ├── 05-May │ │ ├── 06-Jun │ │ ├── 07-Jul │ │ ├── 08-Aug │ │ ├── 09-Sep │ │ ├── 10-Oct │ │ ├── 11-Nov │ │ └── 12-Dec │ ├── 2017 │ │ └── [...] │ └── 2018 │ └── [...] └── tmp ├── 2019 │ ├── 2019-06-08_software_download │ └── 2019-12-31_experimental_project └── 2020 ├── 2020-04-04_another_temp_dir └── 2020-12-18_you_get_the_idea
Related closely to the base filename spec, and vice-versa.
The Timestamp-ID specification is a very simple "ISO-like" timestamp:
|YYYY||the year||4 digit||MUST|
|MM||the month||zero padded||MUST|
|DD||the day||zero padded||MUST|
|HH||the hour||24 hour||MUST|
|MM||the minute||zero padded||MUST|
|SS||the second||zero padded||OPTIONAL|
Time resolution smaller than one second MAY be defined, but so far there has been no need and thus no discussion what that might look like.
The notion of
-6 comes from the size of the last group of digits in the timestamp:
Therefore it is an expression of the level of time resolution (minute and second, respectively).
3 In fact this is the approach I took in the (as yet unreleased) Meme Manager as some memes have far too much metadata to comfortably store in the filename.