~trs-80/ostrta-spec

918c350fc19425157fd50098eac0d6a95d860b06 — TRS-80 9 months ago 56be7a9
Several more incremental changes

README.org: Add experimental disclaimer to Current Status and try and
paint some sort of picture.  And why no version numbers for now.

README.org: Add link to Wikipedia Memex article.

README.org: Change title 'Underlying Philosophy / Ideas' to
'Underlying Ideas and Additional Resources.'  Add links for list items
in this section.

README.org: Create new heading 'Related Projects' and move
'Underlying...' under it, along with new heading 'Projects
Implementing OSTRTA Specification.'

Some other small changes.
2 files changed, 81 insertions(+), 29 deletions(-)

M README.md
M README.org
M README.md => README.md +37 -13
@@ 7,7 7,9 @@
        2.  [Timeline and ISO-like dates as Identifiers](#timeline-and-iso-like-dates-as-identifiers)
        3.  [Controlled Vocabulary](#controlled-vocabulary)
    3.  [Specifications](#specifications)
    4.  [Underlying Philosophy / Ideas](#underlying-philosophy--ideas)
    4.  [Related Topics](#related-topics)
        1.  [Projects Implementing OSTRTA Specification](#projects-implementing-ostrta-specification)
        2.  [Underlying Ideas and Additional Resources](#underlying-ideas-and-additional-resources)

[![img](assets/gfdl-logo-small.png)](https://www.fsf.org/about/what-is-free-software)



@@ 26,12 28,18 @@ file [COPYING](COPYING).

This project contains the OSTRTA "Specification"<sup><a id="fnr.2" class="footref" href="#fn.2">2</a></sup> 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!<sup>TM</sup>) 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 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.


@@ 39,7 47,7 @@ I have been developing and using many of these concepts (and additional ones bes

-   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
One of many inspirations would be something like Vannevar Bush's [Memex](https://en.wikipedia.org/wiki/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



@@ 49,7 57,7 @@ Listed roughly in (descending) order of importance:

Karl Voit makes an important observation<sup><a id="fnr.3" class="footref" href="#fn.3">3</a></sup>, 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](https://www.fsf.org/about/what-is-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:
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


@@ 59,19 67,25 @@ In addition to the above (and for same reasons), we should also *only* use what 
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](https://www.gnu.org/philosophy/floss-and-foss.en.html) tools
-   Sourcehut  ;)
-   [Gemini](https://gemini.circumlunar.space/) 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.<sup><a id="fnr.3.100" class="footref" href="#fn.3">3</a></sup>

For several years now, the very first step I take in when processing incoming photos<sup><a id="fnr.4" class="footref" href="#fn.4">4</a></sup> is to use the [sortphotos Python script](https://github.com/andrewning/sortphotos) 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.
For several years now, the very first step I take when processing incoming photos<sup><a id="fnr.4" class="footref" href="#fn.4">4</a></sup> is to use the [sortphotos Python script](https://github.com/andrewning/sortphotos) 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.

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.
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](Specifications.org#timestamp-id) spec.<sup><a id="fnr.5" class="footref" href="#fn.5">5</a></sup>

### Controlled Vocabulary



@@ 98,17 112,25 @@ The essential notion of Controlled Vocabulary (CV) is to select items from some 

Moved [here](Specifications.md).

## Underlying Philosophy / Ideas
## Related Topics

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.
### 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(<sup>TM</sup>).  When I do, I will link it here.

Kindly announce on our [mailing list](https://sr.ht/~trs-80/ostrta-spec/lists) if you have are working on anything!

### Underlying Ideas and Additional Resources

-   Karl Voit, already mentioned a couple times in the [General Concepts](#general-concepts) as his ideas were quite influential.<sup><a id="fnr.3.100" class="footref" href="#fn.3">3</a></sup>

-   Getting Things Done (GTD)
-   [Getting Things Done (GTD)](https://en.wikipedia.org/wiki/Getting_Things_Done)

-   todo.txt
-   [todo.txt](http://todotxt.org/)

-   F/LOSS software generally, but GNU Emacs specifically.  And perhaps Orgmode most of all.<sup><a id="fnr.5" class="footref" href="#fn.5">5</a></sup>
-   F/LOSS software generally, but [GNU Emacs](https://www.gnu.org/software/emacs/) specifically.  And perhaps [Orgmode](https://orgmode.org/) most of all.<sup><a id="fnr.6" class="footref" href="#fn.6">6</a></sup>


## Footnotes


@@ 121,4 143,6 @@ I have been a bit of a Personal Information Management (PIM) geek for about as l

<sup><a id="fn.4" href="#fnr.4">4</a></sup> Similar (some times manual) methods apply to other forms of media which do not contain embedded creation dates.

<sup><a id="fn.5" href="#fnr.5">5</a></sup> 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!  :)
<sup><a id="fn.5" href="#fnr.5">5</a></sup> Not only that, but an email I sent to the Orgmode mailing list asking about allowing date based IDs as another option for UUID generation actually ended up making it in to Orgmode!

<sup><a id="fn.6" href="#fnr.6">6</a></sup> 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!  :)

M README.org => README.org +44 -16
@@ 21,8 21,6 @@ file [[file:COPYING][COPYING]].

This project contains the OSTRTA "Specification"[fn: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
    :PROPERTIES:
    :CUSTOM_ID:            current-status


@@ 30,6 28,14 @@ If you are looking for the Emacs Lisp implementation of OSTRTA, it can (soon!^TM

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
    :PROPERTIES:
    :CUSTOM_ID:            goals


@@ 41,7 47,7 @@ I have been developing and using many of these concepts (and additional ones bes

- 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
One of many inspirations would be something like Vannevar Bush's [[https://en.wikipedia.org/wiki/Memex][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
   :PROPERTIES:


@@ 57,7 63,7 @@ Listed roughly in (descending) order of importance:

Karl Voit makes an important observation[fn:3], 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 [[https://www.fsf.org/about/what-is-free-software][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:
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


@@ 67,10 73,14 @@ In addition to the above (and for same reasons), we should also /only/ use what 
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
- [[https://www.gnu.org/philosophy/floss-and-foss.en.html][F/LOSS]] tools
- Sourcehut  ;)
- [[https://gemini.circumlunar.space/][Gemini]] and similar "small web" protocols
- etc.

*** Timeline and ISO-like dates as Identifiers


@@ 80,9 90,11 @@ Examples of things meeting these criteria are:

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.[fn:3]

For several years now, the very first step I take in when processing incoming photos[fn:4] is to use the [[https://github.com/andrewning/sortphotos][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.
For several years now, the very first step I take when processing incoming photos[fn:4] is to use the [[https://github.com/andrewning/sortphotos][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.
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 [[file:Specifications.org#timestamp-id][Timestamp-ID]] spec.[fn:5]

*** Controlled Vocabulary
    :PROPERTIES:


@@ 121,25 133,39 @@ Tools should support gardening workflows like:

Moved [[file:Specifications.org][here]].

** Underlying Philosophy / Ideas
** Related Topics
   :PROPERTIES:
   :CUSTOM_ID:            underlying-philosophy--ideas
   :CUSTOM_ID:            related-topics
   :END:

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.
*** Projects Implementing OSTRTA Specification
    :PROPERTIES:
    :CUSTOM_ID:            projects-implementing-ostrta-specification
    :END:

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 [[https://sr.ht/~trs-80/ostrta-spec/lists][mailing list]] if you have are working on anything!

*** Underlying Ideas and Additional Resources
    :PROPERTIES:
    :CUSTOM_ID:            underlying-ideas-and-additional-resources
    :END:

- Karl Voit, already mentioned a couple times in the [[#general-concepts][General Concepts]] as his ideas were quite influential.[fn:3] 

- Getting Things Done (GTD)
- [[https://en.wikipedia.org/wiki/Getting_Things_Done][Getting Things Done (GTD)]]

- todo.txt
- [[http://todotxt.org/][todo.txt]]

- F/LOSS software generally, but GNU Emacs specifically.  And perhaps Orgmode most of all.[fn:5]
- F/LOSS software generally, but [[https://www.gnu.org/software/emacs/][GNU Emacs]] specifically.  And perhaps [[https://orgmode.org/][Orgmode]] most of all.[fn:6]

* Footnotes
   :PROPERTIES:
   :CUSTOM_ID:            footnotes
   :END:
  :PROPERTIES:
  :CUSTOM_ID:            footnotes
  :END:

[fn: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.



@@ 149,4 175,6 @@ I have been a bit of a Personal Information Management (PIM) geek for about as l

[fn:4] Similar (some times manual) methods apply to other forms of media which do not contain embedded creation dates.

[fn:5] 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!  :)
[fn:5] Not only that, but an email I sent to the Orgmode mailing list asking about allowing date based IDs as another option for UUID generation actually ended up making it in to Orgmode!

[fn:6] 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!  :)