Another Journal Ideas

[Yoshiki Ohshima]

  Hello,

  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.

http://www.bootstrap.org/augdocs/augment-33076.htm

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

  + 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:
    
    Creator: yoshiki
    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
    this, too.

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

  Just a thought.  I shared this now and then with some people, but it
seems to be a good time to brain dump^^;

-- Yoshiki