Message sent to Kathryn and Ralf describing the latest work on
the uviz database, adding support for descriptors.


---------- Forwarded message ----------
From: Chris Dent <cdent@burningchrome.com>
To: Kathryn and Ralf
Date: Tue, 6 Aug 2002 03:20:37 -0500 (EST)
Subject: penultimate database indepedent study task


Oi.

Longish message, some questions and comments about what's next at
the end.

I have added support, in prototype form, for the use of
descriptive keyword annotations in the database and inteface for
the unrev-ii archive.

I have not announced this to the Bootstrap people yet for a
couple of reasons:

- We have not received much feedback from the first announcement
  (but there has been some, and people have been looking)
- Without messages being seeded with descriptive keywords it is
  hard to grok the system, so I think we need to do some seeding,
  both with descriptors and evaluative scores before making another
  announcement. That's outside the immediate scope.

In the following I refer to the descriptive keywords that are
applied to messages simply as descriptors. A single message may
have zero or more descriptors.

There are two database tables associated with descriptors:

- basicdescriptors: associates text with a unique numeric id. For
  example: 9 -> Engelbart
- basicdescassoc: associates a messageid with a descriptor id:
  3120 -> 9 means message 3120 is related to Engelbart in some
  fashion, according to at least one reviewer.
  - At this time the system does not concern itself with multiple
    associations of the same keyword with one message, but it
    does record that information.

Starting from the first page of the database interface:

  http://www.burningchrome.com/~cdent/uviz/cgi/index.cgi

there are several changes:

- A bit more documentation to explain the new interface features.
- A "Search descriptors form"
  - From this you can select one or more descriptors and retrieve
    a matching set.

(At this time the only keywords in use are "Engelbart" and
"references", so test with those.)

On the set page, you get the same stuff as before. I chose not to
allow a person to apply a descriptor to a set of messages because
it seemed likely that that would be unclear. Consider an example:

- I post a request to the list for references on Engelbart
- Someone responds with a bibliography
- A later search returns those two messages
- Only one (the latter) should be assigned the "references" keyword

On the individual message display there are two changes:

- The list of descriptors on this particular message are listed
  as links. Choosing the links will return all the messages that
  match that descriptor (only).
- A form is present to apply any of the available descriptors to
  the message.

A simple tool is available to add more descriptors from the
command line. It is called addDescriptor. Use is as follows:

- To see a list of the existing descriptors:

cdent@hot:~/src/uviz/input $ ./addDescriptor
1       social
2       collaboration
3       OHS
4       DKR
5       spam
6       references
7       announcements
8       complex problems
9       Engelbart
10      Bootstrap Inst/All

- To add a new descriptor:

cdent@hot:~/src/uviz/input $ ./addDescriptor multimedia

- If you wish to add a descriptor with more than one word
  (containing spaces) you _must_ surround the descriptor with
  double quote marks (")

Bugs:

- The SQL required for retrieving a set of documents that match
  more than one descriptor is inelegant in the extreme. It is the
  result of hasty thinking about the table design. Thus far it
  appears to work, but more testing is required.
- Related: the dance required to get around that bad SQL makes
  for some complicated Perl.

-=-=-
Getting this feature to work, even to this rudimentary (this is
_far_ less complicated and robust than the original design)
level, was tough. The web doesn't lend itself to this sort of
inteface. I can't be sure of its correctness without some other
people doing some testing.

I believe, with this, that I've satisfied the technical
implementation requirements for the independent study. I assume
there should be some kind of summarizing something. What should
that something be? I'd like to have it done this week so I can
call things done with the end of Summer session II.

I assume that we'll be continuing with this interface and
associated research when the Fall semester starts up. At some
point we should have a sit, figure out what we need to do to move
on as well as what needs to be done to get more testing out of
the bootstrap folk.