~trs-80/ostrta-spec

7916ac4895db2fb026b87912be7f35307ecb56bc — TRS-80 9 months ago 75cabc7
Several improvements and changes

Add links to Karl Voit and sortphotos.

Change order of importance of some of General Concepts, and state that
there is, in fact, an order.  Flesh out F/LOSS and "Lowest Common
Denominator" examples.

Move Karl Voit article to footnote.

As always, some small wording tweaks here and there.
4 files changed, 73 insertions(+), 34 deletions(-)

M README.md
M README.org
M Specifications.md
M Specifications.org
M README.md => README.md +34 -16
@@ 3,8 3,8 @@
        1.  [Current Status](#current-status)
        2.  [Goals](#goals)
    2.  [General Concepts](#general-concepts)
        1.  [Timeline and ISO-like dates as Identifiers](#timeline-and-iso-like-dates-as-identifiers)
        2.  [Relying strictly on F/LOSS and Lowest Common Denominator formats](#relying-strictly-on-floss-and-lowest-common-denominator-formats)
        1.  [Relying strictly on F/LOSS and Lowest Common Denominator formats](#relying-strictly-on-floss-and-lowest-common-denominator-formats)
        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)


@@ 30,12 30,12 @@ If you are looking for the Emacs Lisp implementation of OSTRTA, it can (soon!<su

### 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 be useful to others.  So I decided to post them up publicly for discussion while I continue with further experimentation and development.
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.

### Goals

-   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 each 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 develop ideas.
-   To come up with some common set of useful, general, free and open 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 in a more useful, reliable, and/or convenient way.



@@ 43,19 43,35 @@ One of many inspirations would be something like Vannevar Bush's Memex, but let'

## General Concepts

### Timeline and ISO-like dates as Identifiers
Listed roughly in (descending) order of importance:

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.
### Relying strictly on F/LOSS and Lowest Common Denominator formats

For several years now, the very first step I take in when processing incoming photos<sup><a id="fnr.3" class="footref" href="#fn.3">3</a></sup> 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.
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).

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

### Relying strictly on F/LOSS and Lowest Common Denominator formats
-   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:

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](https://www.fsf.org/about/what-is-free-software).
-   plain text
-   standard file and folder based naming
-   email
-   free and open image and document formats
-   [Free Software](https://www.fsf.org/about/what-is-free-software) tools
-   etc.

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

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.

### Controlled Vocabulary



@@ 86,13 102,13 @@ Moved [here](Specifications.md).

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](https://www.gnu.org/philosophy/floss-and-foss.en.html).
-   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)

-   todo.txt

-   F/LOSS software generally, but GNU Emacs specifically.  And perhaps Orgmode most of all.<sup><a id="fnr.4" class="footref" href="#fn.4">4</a></sup>
-   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>


## Footnotes


@@ 101,6 117,8 @@ I have been a bit of a Personal Information Management (PIM) geek for about as l

<sup><a id="fn.2" href="#fnr.2">2</a></sup> Using that term quite loosely at the moment!  ;)

<sup><a id="fn.3" href="#fnr.3">3</a></sup> Similar (some times manual) methods apply to other forms of media which do not contain embedded creation dates.
<sup><a id="fn.3" href="#fnr.3">3</a></sup> [Managing Digital Files (e.g., Photographs) in Files and Folders](https://karl-voit.at/managing-digital-photographs/) by Karl Voit

<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.4" href="#fnr.4">4</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> 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 +35 -17
@@ 28,16 28,16 @@ If you are looking for the Emacs Lisp implementation of OSTRTA, it can (soon!^TM
    :CUSTOM_ID:            current-status
    :END:

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 be useful to others.  So I decided to post them up publicly for discussion while I continue with further experimentation and development.
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.

*** Goals
    :PROPERTIES:
    :CUSTOM_ID:            goals
    :END:

- 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 each by ourselves.
- To come up with some common set of useful, general, free and open 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 standard is all laid out (i.e., this page).  Or at least a place to focus discussion and further develop ideas.
  - 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 in a more useful, reliable, and/or convenient way.



@@ 48,25 48,41 @@ One of many inspirations would be something like Vannevar Bush's Memex, but let'
   :CUSTOM_ID:            general-concepts
   :END:

*** Timeline and ISO-like dates as Identifiers
Listed roughly in (descending) order of importance:

*** Relying strictly on F/LOSS and Lowest Common Denominator formats
    :PROPERTIES:
    :CUSTOM_ID:            timeline-and-iso-like-dates-as-identifiers
    :CUSTOM_ID:            relying-strictly-on-floss-and-lowest-common-denominator-formats
    :END:

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

For several years now, the very first step I take in when processing incoming photos[fn:3] 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.
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:

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.
- already existing
- widely available and standardized
  - ISO, IETF, and many other widely accepted standards
- but /most especially/, non-proprietary

*** Relying strictly on F/LOSS and Lowest Common Denominator formats
Examples of things meeting these criteria are:

- plain text
- standard file and folder based naming
- email
- free and open image and document formats
- [[https://www.fsf.org/about/what-is-free-software][Free Software]] tools
- etc.

*** Timeline and ISO-like dates as Identifiers
    :PROPERTIES:
    :CUSTOM_ID:            relying-strictly-on-floss-and-lowest-common-denominator-formats
    :CUSTOM_ID:            timeline-and-iso-like-dates-as-identifiers
    :END:

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 [[https://www.fsf.org/about/what-is-free-software][Free Software]].
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.

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

*** Controlled Vocabulary
    :PROPERTIES:


@@ 112,15 128,15 @@ Moved [[file:Specifications.org][here]].

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 [[https://www.gnu.org/philosophy/floss-and-foss.en.html][F/LOSS]].
- 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)

- todo.txt

- F/LOSS software generally, but GNU Emacs specifically.  And perhaps Orgmode most of all.[fn:4]
- F/LOSS software generally, but GNU Emacs specifically.  And perhaps Orgmode most of all.[fn:5]

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


@@ 129,6 145,8 @@ I have been a bit of a Personal Information Management (PIM) geek for about as l

[fn:2] Using that term quite loosely at the moment!  ;)

[fn:3] Similar (some times manual) methods apply to other forms of media which do not contain embedded creation dates.
[fn:3] [[https://karl-voit.at/managing-digital-photographs/][Managing Digital Files (e.g., Photographs) in Files and Folders]] by Karl Voit

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

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

M Specifications.md => Specifications.md +1 -1
@@ 1,7 1,7 @@
1.  [Specifications](#specifications)
    1.  [Controlled Vocabulary](#controlled-vocabulary)
        1.  [CV File Format](#cv-file-format)
    2.  [Data File](#orgc24304e)
    2.  [Data File](#data-file)
    3.  [Filename](#filename)
        1.  [Minimum](#minimum)
        2.  [Full Filename Specification](#full-filename-specification)

M Specifications.org => Specifications.org +3 -0
@@ 54,6 54,9 @@ Using common example of selecting tag(s), the plain text CV file implementation 
   1. Implementations SHOULD provide a user selectable option whether to limit selections strictly to the choices in CV file, or allow adding new items "on the fly."

** Data File
   :PROPERTIES:
   :CUSTOM_ID:            data-file
   :END:

For tabular data meeting the following criteria: