I've actually been shifting personal files (less Excel if I can, as an example) to more text-based, or at least much simpler file formats when I can because I worry about this sort of thing. I'm a little different that way, perhaps I shouldn't be, and I should be fine not being able to read a file I created over a decade ago.
Perhaps the newer cloud-based apps will always "auto-upgrade" your files/documents for you now (MS Office is pretty good at backwards-compatible files, and reading older versions, but Microsoft seems an outlier in this regard, to me anyway)? I guess we'll find out.
A single punched card?[1] That's only 80 chars, very low density, not much room for any nuance in any given thought.
As to information retrieval, punched cards are very easily decoded by hand, without a reader. I used punched cards IRL as a student, and I had to decode occasionally when there was a problem with the printing on the card. Not a big deal.
The real "nightmares" came about when you punched a program, trudged down to the computer center, read it in, and then waited anywhere between 5 minutes and 24 hours before the computer operator took a bunch of output from the line printer, separated the individual jobs, and placed the output in racks for you to retrieve. And then you found out you had a syntax error.
One plus side was that, since this took so much time, you learned to take a little care in writing your program and in checking it for typos before submitting it. That sort of discipline turns out to be quite useful in many activities in later life.
On another plus side, the cards were made of relatively thick paper, and there was only printing on one side. So the flip side of an unpunched card was absolutely great for writing little notes.
Those, sadly, are just about the only "plus sides" I can think of for punched cards. Fortunately I've never ever had any nightmares about those days. :)
https://msdn.microsoft.com/en-us/library/dd924743(v=office.1...
We have also been down this road before. Projects like LibreOffice/OpenOffice and pandoc have tried in earnest to match the specifications published by Microsoft, but it is always an imperfect implementation of either the reader or the writer.
Because it seems to be virtually impossible, in practice, to implement Microsoft's document format specifications, I do not think the publication of the specifications alone makes a file format suitable for archival purposes.
1. An organic/"rapidly" changing format does indeed make it harder to "keep up" if you are building a contemporary "competitor" application.
2. However, for archival purposes it shouldn't matter how rapidly/organically the specification changed in the lifetime of the document, so long as you have an adequate specification snapshot from somewhere around the last modified state of the document. (Or presuming, as you should be able to even with Microsoft's standards, a standard that maintains a heavy bias towards backwards compatibility in document reading, only the final specification.)
Admittedly, we can't entirely anticipate the headaches of future cryptarchs, but an open specification I do feel is sufficient for archival purposes.
First off, I love the term "cryptarch". :) That's basically the user we're talking about here.
My concern is that archival media may become skewed from the media reader such that the media cannot be rendered with high fidelity (i.e. lossless).
> so long as you have an adequate specification snapshot
If the reader implementation itself has been lost to the ages, or perhaps the implementation is not runnable on contemporary hardware, then I worry that the specs alone may not be sufficient to reimplement the reader.
> a standard that maintains a heavy bias towards backwards compatibility
On the topic of archival, I'm concerned that ASCII will be a readable data format in 50 years. With that perspective, I am pretty skeptical that a spec as complex as the OneNote spec will maintain backward-compatible coherence across the same time span.
For archival on an apocalyptic scale, I don't expect future readers to read nor care at a high fidelity/"lossless" form of some of my documents. Certainly for my own notes to myself, I hope it is sufficient that future readers may get the gist of my scribblings from what they can scrounge out of a document based on specification snapshots (or even just scrounging for readable strings that seem vaguely Unicode like). I suppose there's an off chance I might do or say something that makes me a remarkable specimen to future histories and they may be interested in a deeper study of my works to the point of attempting high fidelity recreations, but I am alright with leaving that as an exercise to them. (Why spoil all their fun? :)
«I'm concerned that ASCII will be a readable data format in 50 years.»
A) I am amused and also not entirely surprised at such a pessimistic timescale. I'm not quite that pessimistic most days, but I can certainly see that perspective.
B) I'd certainly like to hope that the efforts we've paid into Unicode will prevent future string data encoding wars and that ASCII will be seen as the degenerate form of Unicode that it is these days. I would hope that specification snapshots of Unicode should be sufficient to future programmers for millennia to come.
C) In the event of such an apocalypse that even decoding ASCII (much less Unicode) is a huge endeavor, I fear that most hope is already lost, regardless of file format or media type...
«First off, I love the term "cryptarch".»
Indeed. One of the few things the videogame Destiny has managed to beneficially provide to our society is this little bit of useful jargon.
I never thought it was important. Now I'm screenshotting a lot.
1. use hotkey to capture screen or portion of screen
2. screenshot is automatically stored as PNG on Desktop
3. click-drag PNG onto gthnk attachments target
4. done. now it is stored with that day's entries
Updated to add: the PNG itself is stored in a SQLite3 database. However, each night gthnk exports the database to the filesystem because, for future retrieval purposes, I think it will be easier to retrieve items from a filesystem than an obscure database format.
In 20 years, how do I know which binary blob goes with which text file, and also with what point in each text file?
I want add: It's so wonderful to hear a developer concerned with these issues. Almost always, future-proofed data is an accident or afterthought, which means I can't depend on it being implemented well or being supported in the long term. It puts gthnk on my shortlist.
- All attachments are named using the datestamp, so the first attachment today would be called 2016-01-19-0.pdf or whatever.
- The entries are also named using the datestamp, so we end up with a text file like 2016-01-19.md.
- The markdown itself contains an explicit link to the attachment; it is automatically inserted during export.
- However, datestamp acts as a primary key so that entries and attachments can be paired using another technique.
Finally, attachments are linked to days. It is not currently supported to associate an attachment with a specific entry on any given day.
"""handwritten notes
Bridge the physical divide.
With gthnk, your timeline
can directly import
handwritten notes,
whiteboard sketchers, and
other physical media."""
Also not mocking or anything, but how 'gthnk' should be pronounced?
I say it like "G. Think". gthnk is shortened from "greenthink," which was a computer system in Vernor Vinge's "Marooned in Realtime" that acted like a personal archive/assistant.
Thanks!