To understand the interface, it will be helpful to recognize that different kinds of people will be using the archive:
Users (people looking for packages that match their requirements to download) are presented with a search/browse form on the Web. The search/browse form allows them to enter search terms (discriminators). The keywords may be selected with buttons from a controlled vocabulary defined by site policy, or entered as `roll-your-owns' in a text field for free-text searching of package descriptions.
Searches would yield all targets that are in the the intersection set of the controlled-keyword hits, intersected with all hits from a search for roll-your-own keywords in package text descriptions. We'll give below a more detailed description of the handling of controlled-vocabulary keywords.
The result of a search/browse operation is a generated HTML catalog listing. The body of a catalog listing consists of a series of one-line entries each beginning with a package-name hotlink and including a one-line package summary. The catalog has section headers indicating which lines are controlled-keyword hits and which are free-text hits.
Users looking at a catalog listing may either refine the search or look at individual entries that interest them (by chasing the package-name hotlinks). An individual entry displays all package metadata contained in the Trove database, possibly including resource links to a local cache of package resource files.
When an individual entry is selected, a user may take one of several actions:
Contributors have three tasks: (1) creating and updating resources, (2) creating and updating package records, and (3) creating and updating person records. All three of these things are done in the same way; by submitting TRL requests to a Trove site.
A contributor can either mail a TRL request to a Trove mail robot, or use a TRL request to register a URL where update requests for a given package can be found. Periodically a Trove crawler will go to the registered URL to pick up a new copy of the metadata. The crawler keeps internal track of the last-upload time and will only actually copy the metadata if the file has since been altered.
In either case, if the request is authenticated (PGP-signed) it will be executed immediately and a report emailed to the contributor. If the request is not authenticated, it will be emailed back to the contributor's home address for confirmation; the confirmation message will include a request ticket. Replying to the confirmation email will ship it back to Trove for execution of the request.
TRL requests may also be generated by a browser session with Trove (in fact, this will be normal for initial package creation, and assist the contributor in aditing controlled-vocabulary fields like discriminators). When the request is committed, a TRL copy will be made and emailed to the contributor. including a request ticket.
When a Trove server finally executes a request, it makes local copies of any attached and replica resources. It then makes whatever modifications are permitted by the request's privilege level and the locked/unlocked state of the items the request wants to modify. Finally, an email report of all changes made (and any updates refused) is sent to everyone on the package notification list.
Trove site administrators get email notification of all package creations (so they can watch for site-policy violations).
Trove site administrators can use a web form to view a catalog of recently added entries, and delete or modify them if there appears to be some problem.
Administrators are also responsible for watching logs of roll-your-own keyword entries and noticing when keywords should be migrated into the core keyword set described in site policy.
Mirror makers include both CD-ROM distribution makers and people running load-sharing mirrors of a Trove site. Both have the same requirement, which is to be able to snapshot the library to another medium. The CD-ROM distributor's happens to be read-only, but he has every good reason to simply ship an instance of Trove as his organizer for the archive.
To flesh out the user interface, we also need to specify how users will find packages. We have developed a unified searching/browsing model for the Trove project. This model was motivated by a desire to structure the controlled-keyword set so the user doesn't have to see all of it while specifying a package (that is, some keywords become `visible' only after given other keywords have been chosen).
The general model is that the set of controlled keywords is structured like the nodes of a tree (or more generally like a directed acyclic graph). A keyword is selectable only when a predecessor node has been selected. A discriminator is a rooted path in the tree (e.g. a sequence of keywords going from root to most specific).
Each package has a list of discriminators associated with it. A package matches a given discriminator if the package has some discriminator of which the given discriminator is a prefix. Thus, if a package has the discriminator /a/b/c/d, any of the given discriminators /a, /a/b, /a/b/c, or /a/b/c/d will match it. The discriminators a, b, c, d, or a/b, or c/d will also match it (but a/d would not).
A search is a set of discriminators created by the user, plus uncontrolled keywords to match against package descroption fields. The result of the search is the intersection set of all packages that match every discriminator in the search, plus the set of all packages whose descriptions matched the uncontrolled keywords.
As an example for this model, consider a user wishing to explore what graphics viewers are available in a Trove catalog. The user would like to be able to specify both (a) graphics formats of interest, and (b) a display toolkit (SVGA, Xlib, Motif, etc.). Let us suppose that the user is looking for a Motif GIF viewer.
The user's search might be performed by building the following pair of discriminators: /topic/graphics/viewers/gif and /interface/toolkit/motif.
A search defines a catalog, a subset of the global catalog that is the entire set of metadata. This model unifies searching and browsing; one browses the set of Trove packages by editing a collection of selections, and viewing the catalog resulting after each edit.
(Note: this sketch deliberately avoids specifying a detailed UI.)
The user is initially presented with a menu consisting of all keywords that appear in the leftmost slot of any spec. (This is a subset of the keytree nodes adjacent to root.)
On choosing one of these, the user is presented with all keywords which appear in slot 2 of a spec containing the chosen keyword in slot 1. This is browsing down the specs. In addition, any package tagged by a spec consisting solely of the chosen keyword is also displayed. There is also the further option Narrow Search.
Further choices of keywords walk down the spec path, displaying any packages that have been tagged by the currently chosen spec, along with the keywords for the next level. Eventually one reaches a level where there are only packages and no further keywords.
Choosing ``Narrow Search'' returns one to the top level, but now only those keywords and packages that can be located in the catalog consisting of the result of the previous browsing operation are selectable. Packages outside the catalog are ignored; excluded keywords are indicated in a non-selectable mode.
The purpose of `graying out' keywords is to allow the user to see instantly that what is wanted is inconsistent with the currently narrowed search. Narrowing can be iterated, or it can be backed out of (by throwing away rightmost segments of the current spec). At all times the current narrowing list and the current spec are displayed, so that the user doesn't get lost.
In this style, the user can hardly tell the difference between browsing and searching: ideally the delay is always the same, so one does not assemble a ``search string'' and then hit ``Search''; instead, one simply browses and, if the current catalog seems to be too large, narrows. Depending on external considerations, a too-large catalog might elicit a warning such as ``There are 3500 packages available. You can |display| the full list or |narrow| your search.'' (where pipe bars bracket hotlinks).
Let's say the top-level screen provides keywords Topic, Interface, Audience, Status, etc. (I will use This Style or THIS STYLE for keywords, and all-lower-case-nn.nn for packages.)
Choosing Topic, the user is presented with Compilers, Browsers, Graphics, etc. and Narrow Search (henceforth N.S.).
Choosing Graphics, the user is presented with Painters, Drawers, Viewers, etc. and N.S.
Choosing Viewers, the user is presented with GIF, JPEG, PNG, etc. the packages barfoo-2.2, zambaz-3.3 (these are packages that are not specialized as to format), and N.S.
Choosing GIF, the user gets packages foobar-1.2, bazzam-3.4, etc., etc., etc. and N.S. There are too many to investigate in detail, so the user chooses N.S. and is returned to the top level.
Choosing Interface, the user is presented with Dumb, Curses, Toolkit, etc.
Choosing Toolkit, the user is presented with razbaz-9.99 (which uses a standardly available toolkit), Motif, KDE, etc.
Choosing Motif, the user sees only foobar-1.2, the intersection of /Topic/Graphics/Viewers/GIF and /Interface/Toolkit/Motif.
And chooses it.
All of this could be done HTML-style, or using one or more choice boxes, or in any number of other ways - this is an abstract UI.