Another Journal Ideas
yoshiki at vpri.org
Fri Oct 17 00:25:23 EDT 2008
As pointed out elsewhere, the NLS system had a data storing and
sharing mechanism called "Journal". It allowed full-text search,
versioning, hyperlinking/annotations and sharing among users.
The sharing and searching let people do interesting things; like
when somebody stored a document that includes "To: DCE" in the
document somewhere, and if DCE searches for "To: DCE", the resulting
list automatically became his message inbox, for example.
Anyway, that is a bit of historical background (so anybody who
thinks the OLPC's journal is a new idea, I have a bit of issue^^:)
And there are some requirements/desire for the new system:
+ Recent discussion goes that some people use full text searching
more, and tagging less. And, my observation is that kids are not
going to tag documents, if it has to be done in a separated window.
"Out of Sight, Out of Mind" is the proverb.
+ There is some desire to support legacy applications
+ And also, there is a need for running Sugar on the
other operating systems.
These things suggests that the whole concept of "metadata" may not
be a good one.
So, here is another simple Journal-like data organization idea.
- In the Activity/Application UI, the place for tags, document
title, etc. should be readily visible. For example, in a word
processor, an "empty" document contains something like:
Title: No Name
from the beginning. These "fields" are just text. The user may
"fill" them at any point, and when the document is saved, these
lines are also saved as a part of the same data. (By default.
More to come later.) When I was a school kid, that
was how I and all other students wrote essays. It is just a blank
paper with grids and, I just wrote the name and title in the same
way as the main body of the essay.
- For a JPEG picture created by Record, the data can be stored in a
comment in EXIF.
- For an application like Etoys, the data file is actually a zip containing
a few files. The "metadata" can be stored as another fixed named
file in the zip. The word processor example can do something like
- Optionally, the programmer of an activity writes a little program
that knows how to extract the data. (let us call it a "metadata extractor".)
- An activity simply stores the data file into a file system location.
So, unmodified X application can save data.
- The new "Journal" system calls the metadata accessor to extract
the data. Journal can certainly cache it.
- Let us say for every week, the Journal can create a new directory
for the activity. The data stored in the previous week or time
period stays in a directory. So that let you access the old data
in a time-indexed manner.
So, the advantage of this approach is:
- An unmodified application can save and load data from file system.
- Any platform can support this. We don't have to rely on the DBus,
but also it is not incompatible with the already Sugarized
acitivities that can save data via DBus; the backend of Journal
stores the file into the proper location.
- The application programmer can write a small program
and the Journal can extract the metadata for better views. But it
is optional; even without the extractor, the system runs fine.
- The time-based access can be made fast.
A downside is:
- It wouldn't be easy to get some kind of metadata like "who you
worked with". But there can be an API to query it from an
activity and the activity can store it in the data.
Alternatively, we can still recommend people to do DBus-based
access to Journal when possible, and Journal could add it for the
Just a thought. I shared this now and then with some people, but it
seems to be a good time to brain dump^^;
More information about the Devel