Implementation of revision rule
ref. : Strict chronological order
The revision rule of Noguchi filing system sounds quite useful to keep system “alive”. I think there is another way to implement it into the PoI system.
For example, when you pick up an indexcard from the dock, mark the top edge with a color pen, say red, then return to it’s original position the dock. The order is unchanged. When you use the indexcard again, you put one more mark. Like a star for soldiers. Consequently, there are many mark for indexcard that you use frequently. Then you’ll clearly see which card you used before.
November 9th, 2006 at 1:48 pm
I do this on pages in books that I read, and re-read. I like the stars for soldiers analogy.
November 10th, 2006 at 5:22 pm
>>Jamie
For book, that’s nice idea. I have done similar, but with post-it. It looks not good if there is many post-its. I should try your way. :)
November 26th, 2006 at 2:47 am
An alternative that might be worth considering, borrowed from computer filesystems, would be to record both a creation timestamp and a modification timestamp for each card. Filing a modified card at the front of the stack rather than having to go back and find its position by original creation date would make up a “modified Sugano filing system”. This would give you the advantage of having recently-modified cards (although not those just referenced but not modified) close at hand near the front of the stack. It would still differ from the Noguchi system, which is effectively based on a “last referenced” timestamp.
November 26th, 2006 at 9:09 am
I’m interested in the similarity of your system to a blog. We wouldn’t normally change the posting date of an old post in order to change its location in the blog archives. But we might well refer to it in a newer post by linking to it. This is how we keep a blog “alive” as a personal archive.
It’s worth noting that, at least on a blog, this, while effective, does take some effort. And I would suggest that few of us actually remember the dates we posted specific entries. So it might be worth discussing what purposes the current style of blog archives serves.
November 27th, 2006 at 3:19 pm
>>MiGrand
Creation and Modification date. That’s sounds quite natural for me. It fits a way of human thinking.
Human thinking is always changing, like a version up of a certain software A 1.0, 1.1, 1.2… They possess same root, but slightly different. In present system (only with creation date), I have to write 3 cards for each. If I introduce modification date, only 1 card would be enough. Plus there is no need to find and return to original position.
Your idea will increase chance to review cards. Because it is fun to make such version up one’s card. Most important thing is that it keep system “alive”.
November 27th, 2006 at 3:43 pm
>>Rick
As you point out, there is similarity between blog and indexcard system. I found it soon after I start my blog, such as tag, link, chronological order.
“How to keep system alive” is always important issue. I don’t think current revision rule in my system is totally perfect. MiGrant’s idea above will be a solution for this problem. What happen if we introduce modification date to the blog :)
December 17th, 2006 at 10:08 am
I understand your concern with the Noguchi system because it destroys your system of referring to a card by its unique date-time identifier (because the card is no longer in the place it always was when you made the ‘link’ to it).
I, personally, really value the way that Noguchi’s filing system organizes itself automatically through normal use .
(you take the card out to read/write to it and then drop it on top of the pile, rather than finding its old place and effectively sneaking it back into its past temporal location).
→ I think, perhaps, you should consider embracing the Noguchi system for this reason, but you can still maintain the fundamental unique-timestamping(URL) by creating an ‘alias-card’ where you found it, after you replace it to the top of the pile.
for example: you take a card out from some past point in time. before you drop the rest of the stack down, losing its place, you replace the card with a new card which is time stamped with the present moment’s URL and the original card’s URL. (.. also, perhaps, if necessary, a brief note explaining why the card was accessed/edited or what was changed/added. this should only be done if this note actually adds value to the alias or if the changes made to the card have temporal significance : not out of practice but rather out of necessity only). Then you do whatever you will (read and/or edit) the card, add the new URL for this moment underneath the original URL (maybe strike out the old URL for clarity’s sake, but leave it read-able for the sake of records), the same new URL as noted on the alias card that was put in its original place.
just my two cents
… on how you can adapt Noguchi’s system (which I think is very organic and for that reason self-organizing) to work with your system which relies on the order of chronology/time to maintain structure, which I can respect.
by the way, here is where I first learnt of the Noguchi Filing System.
cheers