This paper describes a preliminary design of an information location model for the webtop. To help users locate information they have previously encountered, we propose a uniform mechanism for characterizing, filtering and ranking information, independent of source (i.e. whether in a personal repository, a workgroup repository, or out on the network), independent of how it became known (notification, search, or browsing) and independent of type (e.g. files/objects, e-mail/notifications/net-news).
There are three ways that electronic information becomes available to us:
When information becomes available to us, we may simply want to use it immediately and then discard it, but often, we want to make sure that we will be able to locate the information again, and generally, we'd like to do so more easily and/or more quickly than we did so in the first place.
We suggest that the right way to do this is to provide a uniform mechanism for tagging information, and then for locating information based on its tags. The remainder of this paper describes the proposed tagging architecture in some detail, and then describes how it can be integrated with the 3 existing classes of access mechanisms discussed above.
A tagging architecture assigns tags to named pieces of information. There are three ways a named piece of information becomes known to a system
A tagging architecture is not a storage architecture, which is responsible for storing objects. Tags are associated with objects (or parts of objects) stored elsewhere, either locally or across the network.
The relationship between a tagging architecture and a naming architecture is a bit more complicated. Initially, we can expect to integrate tagging with existing naming mechanisms. These will be used to name objects or parts thereof, and the tagging mechanism will be used to associate tags with these names.
However, it is also true that we expect tagging to eventually replace standard hierarchical file naming systems -- there is no point in associating a newly created object with a standard hierarchical pathname if the object's name and tags are adequate for locating it. With a suitable syntax, a tagging architecture becomes a naming architecture.
In general, a tag associated with some information characterizes the information in some way. It could be an intrinsic property of the information (e.g. whether it contains any objectionable words from a given word list), but more likely represents at least some degree of judgement on behalf of the person doing the tagging (e.g. is the information objectionable)
Thus, there are two kinds of tags:
We have no requirements about who generates the names of tags. We imagine that communities of users will agree on some common tags (the utility of this will be described later); at the same time, we expect that each user will define their own sets of tags.
Consequently, the properties and structure of tags need to represent the same rich semantic structure of characterizations we find in everyday life. This means that
Now, we need some terminology. We'll say that a piece of information satisfies a tag if it assocaited with that tag or with any descendant of that tag (remembering that tags form a heterarchy).
An explicit tag may be exclusive with respect to a particular parent. This means that if a piece of information has that tag, it cannot be tagged with any of its sibling tags (or their descendants).
Having defined tags, we need to discuss how they will be used. We will outline the uses here; the remainder of the paper will describe these in more detail.
The existing browsing, searching, and navigation applications -- file managers, web browsers, search engines, mail and news programs, all present groups of objects to the user, and generally allow the user to select some subgroup of the objects presented.
Now optimally, each of these applications would be integrated with the tagging architecture by allowing the user to assign tags and/or add annotations to the selected subgroup. For example, some shortcut key (e.g. Alt+T) might display a standard Tag Dialogue box through which the user could assign tags and annotations to the selected subgroup. (We leave the design of the dialogue box, and especially the means of rapidly selecting tags from a heterarchy, perhaps with tag name search and completion, as an exercise for the reader).
Tagging an object would contact a Tagger (perhaps via RPC or a dynamically loaded Tag library) which would associate the objects and their names (and perhaps some typing information known only to the application and passed along by it) with the tags and/or annotations.
Objects are generally known by a simple name within some contextual name that uniquely identifies it -- for example, a filename within the context of some directory pathname. The Tagger retains the context name (to return the full name of an object that the Tagger locates), however, lookups are based only on the simple name plus an object's tags. The standard Tag Dialogue box allows the user change or prefix the simple name used by the Tagger for lookups.
In the short term, we can support object tagging through drag and drop directly onto the Tagger, if the existing browsing, searching, or notification application supports drag and drop adequately:
In X-based environments, there are standard selection targets corresponding to the needed information; the only issue is whether drag and drop is supported, and whether the needed information is available.
If so, then when the selected objects are dropped onto the Tagger, it can display the dialogue box, so the user can tag and annotate the objects accordingly.
Many document viewers allow users to select portions of the document. Document viewers may allow these selections to be named and retained even after the document is closed; this capability is generally (though no necessarily) implemented through an underlying linking/embedding architecture such as OLE.
In any case, if a document viewer supports this capability, then it is certainly useful to allow selected portions of documents to be named and tagged. This can be done through the document viewer itself, or by dragging and dropping the selection onto the Tagger, if adequately supported.
In some cases, documents themselves already come with pre-named
segments, either through some compound document architecture, or via
markup included in the document content (e.g. HTML's named anchors).
In such cases, there is often already a standard way to name the
segment in the context of the document (e.g. URL's with a # In the discussion above, we have assumed that pieces of
information are made known to the Tagger explicitly based on user
action. But objects or parts of objects can also be discovered and
made known to the Tagger automatically. There are two kinds
of automatic discovery:
In both cases, discovered information is made known to the Tagger.
And of course, once discovered, other software agents can
automatically explore the contents or attributes of the discovered
information and automatically assign new tags.
We also need to ask how long information remains known to the
Tagger:
The Tagger effectively manages all the information a user becomes
aware of electronically. It is natural then, for the Tagger to be the
focus of control for helping the user ensure that important remotely
stored information remains accessible.
When remote information is deleted, moved, or revved, data
maintained by the Tagger becomes out-of-date. In some cases, this is
fine, and the user will simply discover problems when trying to later
access documents that tagging helps locate. However, the Tagger can
be used to automatically manage software agents that can notice
changes, and either make changes automatically, or send notifications
to the user.
In addition, with appropriate standardized protocol support,
agents can be notified before changes occur, so that versions of
important remote documents can be automatically downloaded to the
user's machine or some other server.
User settings can specify which tags are used to denote important
objects, as well as denoting, on a per-tag basis, the action to be
taken when changes occur.
Now that we've described how pieces of information (i.e. objects
or parts of objects) get tagged, we can discuss how tags can be used
to browse that information. We'll do this by roughly describing some
aspects of the user interface of a Tag Browser application/applet.
Figure 1
The Tag Browser (figure 1) is divided into two panes. The top
pane holds columns of tags. When the SHOW SELECTION pushbutton is
clicked, the bottom pane displays a list of the names of pieces of
information corresponding to the tags selected in the top pane.
Each column in the top pane displays the child tags of some
composite tag. Initially, the top pane holds a column (labelled
TAGS) of the top level tags, ordered alphabetically (though this can
be changed).
The tags in each column may either be simple or composite tags,
and they are highlighted differently. Either may be selected (or once
selected, deselected) by clicking on it. If the user clicks on a
composite tag to select it, then its child tags are shown in a new
column. Any number of tags in any number of columns may be selected
at a time.
Next to each tag in each column is a count -- the number of
pieces of information that satisfy that tag as well as all the other
tags currently selected. Initially, figure 1 shows the number of
pieces of information which satisfy all the first level tags.
If a tag in a column is a composite tag, then we also show the
number of its child tags that have non-zero counts.
Each column has two special tags added: *ANY and *OTHER. *ANY
corresponds to the union of the other child tags, and *OTHER is what's
left; that is, *OTHER corresponds to all known pieces of information
which are labelled by the tag in the column heading, but which are not
satisfied by any of the other tags in the column. The count next to
the *OTHER tag correspond to the number of pieces of information that
satisfy all the other tags currently selected, and that aren't
satisfied by any of the tags in the column. Obviously, the count next
to an *OTHER tag will be 0 if any other tags are selected in its
column.
In figure 1, the *OTHER tag in column 1 refers to all known
pieces of information that have no tags at all (i.e. they still have a
name, and may have an annotation as well; either they were
incorporated initially without a tag, or their tags were all
explicitly removed).
Figure 2
Suppose we click on the Computing tag. We now see (figure 2) a second
column of tags. It is labelled Computing, and contains the list of tags
which are child tags to the Computing tag.
Along with each tag in the Computing column are the count of known
pieces of information that satisfy that tag.. The *OTHER tag in
this column of course refers to all pieces of information which have
the Computing tag, but which do not satisfy any of its child tags.
If we now turn our attention back to column 1, we note that it has
changed from figure 1:
Figure 3
In figure 3, we've selected Plug-Ins from column 2 (which became
the heading of Column 3), then also selected Multimedia from column 1
(which became the heading of Column 4).
In each column, the count next to each tag reflects the number of
pieces of information that satisfy that tag as well as all 3 tags
selected.
Columns 3 and 4 have non-zero *OTHER tags. Column 3's *OTHER
tag reflects the pieces of information that satisfy Multimedia,
Computing and Plug-Ins, but do not satisfy any children of Plug-Ins.
Column 4's *OTHER tag reflects the pieces of information that satisfy
Multimedia, Computing and Plug-Ins, but do not satisfy any children of
Multimedia.
So, we can continue to refine our browsing by selecting composite
tags, using the counts (and number of counting children) associated
with each tag to help decide what to select. At any point, we can
click on the SHOW SELECTION pushbutton which will show, in the bottom
pane, a list of all pieces of information that satisfy all the
selected tags. Note: A useful shortcut might be that clicking on a
tag with the SHIFT key depressed is equivalent to both selecting that
tag and then clicking SHOW SELECTION.
Other useful features of the Tag Browser include the following
(not shown in the figures)
(Of course all columns also contain *ANY and *OTHER). We can
control multi-level expansion/hierarachy compression for any tag or
set of tags, and optionally control it by the value of other user
settings. and the list can be ordered in various ways based on this
information
Of course, like any other browser, the Tag Browser allows any
subgroups listed in the bottom pane to be selected, and the standard Tag
Dialogue box can be opened allowing tags to be added or removed to the
selected subgroup, or annotations to be added or edited
An important concern is that not all of these attributes listed
above may be available (or even relevant) depending upon how the
information became accessible. We need to rethink the attributes that
are generally important and think about how to capture them.
For objects found out on the web, the discovery time may be quite
useful as a way of locating some information -- it can be very helpful
to use the discovery time as a way of ordering a list of possible
candidates (shown in the bottom pane). For objects created by the
user, we probably can treat creation time as the discovery time. In
other cases, creation time probably is not that important, which is
lucky, since it often will not be available.
Discovery, even explicit discovery, does not mean that the user
viewed (or in the case of audio, listened to) its contents. A search
engine may have delivered a list of URL's which the user tagged without
opening. Knowing that information was actually viewed, and when it was
viewed, can be even more helpful in locating information.
Unforunately, obtaining the view time requires integration with
other software, or requires new operating system support. We might
think that we can use last access time, at least for objects stored in
an accessible file system. However, if the user is browsing a shared
object, then there must be a way of distinguising a user's last view
from accesses by other users. In fact, even if the object is not
shared, it probably is important to distinguish accesses in which the
user actually views the information, from accesses by programs that
autonomously process the contents. Similarly, if the object is not
stored in a file system at all -- for example, mail messages in many
mail systems -- file system access time cannot be used. In all of these
cases we need to integrate the Tagger with the naming mechanism
responsible for an object, so that the Tagger can be notified when an
object is being viewed by a user.
Also, we note that mail browsers generally are hip to the
following situation -- the user begins to read a piece of mail, but
then realizes that there's no time to do and has to go on to something
else. Mail browsers generally have a way of allowing the user to
re-mark the mail message as "unread". This is an important feature
for other types of objects as well. Either the Tagger must allow the
last view time to be reset, or more browsing applications should
include this capability, in which case they need to be able to
communicate the change of state back to the Tagger.
Last update time is also interesting. For files stored in an
accessible file system, we actually can use last modification time.
For objects out on the network, and available via http, we can use
http to find out the last modification time of the object when needed.
However, for performance, the architecture really requires its own
software agent, or integration with agents at other sites, to keep
this information up-to-date.
Useful as it is to display names and attributes in the bottom pane
of the Tag Browser, it can be even more useful to use names and
attributes to limit the number of candidate pieces of information.
Figure 4
Figure 4 shows a revised user interface for the Tag Browser, with
a number of new features
With adequate integration, these applications can either be
eliminated, significantly reduced in size, or subordinated to the Tag
Browser. That is, the Tag Browser can become the single interface for
locating and accessing local and locally-known information.
First of all, integration requires automatic discovery.
That is, there must be mechanisms to make pieces of information known
automatically to the Tagger, without requiring that they be explicitly
tagged.
Heavy use of discovery could mean that when we look under the TAGS
column in the browser, the largest number will be found next to *OTHER
(i.e. since lots of information is being made known without being
tagged). However, we expect that in many cases, automatically invoked
software agents will analyze the information and associate tags with it.
For example, the software agent attached to the MAIL tag
(invoked when a piece of information has the MAIL tag added -- that
is, when a new mail message arrives, and through eager discovery
is made known to the Tagger as MAIL) will likely perform the kind of
analysis used in the Information Lens system. However, unlike
Information Lens, this mechanism will not be specific to the mail
system, but will use tags which are part of the generic tagging
architecture.
Second of all, we treat other naming mechanisms (hierarchical or
non-hierarchical) in the Tag Browser just as we treat tag
heterarchies. We've already seen an example of this in the way we
treat MIME types and subtypes.
Putting this all together, here's how we handle automatic
discovery and naming for each of the various kinds of sources:
If the user changes the folder of a mail message using the mail
application, it notifies the Tagger. Tag access controls prevent
users from adding or removing MAIL subtags from anything but mail
messages But if subtags of MAIL are assigned or removed from a mail
message object, the mail application is notified (accomplished using
software agents automatically associated with those tags) to refile
the message as appropriate. When the user clicks on NEWS under the SOURCE column, a new column
labelled NEWS will be displayed with tags corresponding to each
newsgroup. If the user asks (in the Tag Browser) to see all
newsgroups, they can be progressively organized based on the newsgroup
hierarchy -- i.e. the NEWS column contains alt, comp, etc., which then
expands as necessary. This is based on that standard hierarchy
compression and visibility control of the Tag Browser.
Note that there are two forms of automated discovery in use here:
Eager discovery is used for news articles in subscribed newsgroups.
These will show up in the Tag Browser (though as unseen) shortly after
they arrive. On-demand discovery is used for viewing unsubscribed
newsgroups. Not until we open a particular column, do we try to
discover how to populate it.
When news articles are being viewed, we want to specialize the
view in the bottom pane to reflect the thread structure of news
articles (we will want to do this with mail automatically tagged as
belonging to specific mailing lists as well). This can either be done
by allowing specialized viewers to be plugged into the bottom pane, or
better, by defining hooks for threading in a type-specific way, so
that all types of objects can be threaded where appropriate. Eager discovery may or may not be useful for particular databases.
We leave it to the database manager to implement eager discovery as
appropriate using database triggers. Retagging an FS object can be treated as a way of moving or
linking the object within the file system.
Distributed file systems should probably be handled by one or more
separate top-level sources -- e.g. DFS). Clicking on the root of a
distibuted file system would display a column of names or addresses of
hosts or cells (depending upon the distributed file system)
It is probably unwise to use on-demand discovery for the
distributed file-system root, since when we select it, we don't want
to wait for the system to find all the cells/hosts which are available
on the network. Instead, the new column displayed should only contain
the host/cell names/addresses that are the source of information
already know to the Tagger.
Once past the distributed file system root, on-demand discovery
can and should be used for remote subdirectories. Eager discovery
should be used for one's own file system so that files created by
other applications would automatically be known to the Tagger even
without selecting FS. Eager discovery is also probably useful for
public subdirectories on some remote hosts.
The approach used here for hierarchical directory naming can also
be extended to nicely support version management, especially when
combined with aspects of database integration, although we won't
burden this paper with the details.
In general, we expect that when we select a
<protocol,domain,port> triple, we will get a single column of all
the pages tagged from that site. In general, we do not expect that it
makes much sense to explore remote web sites based upon its
hierarchical structure. On the other hand, whena large number of
objects are known from a site, it might be helpful to organize them by
hierarchy. We expect the Tag Browser (with the appropriate user
settings) to be able to automatically determine thew appropriate level
of hierarchy compression to best be applied. In the discussion above, we have implied that a column in the Tag
Browser corresponding to a name in some other naming mechanism only is
displayed by selecting that name in a previous column. So, we remind
the reader that columns to be displayed can be specified via a dialogue
box. Further, integration with other naming mechanisms means that the
Tag Browser needs to be able to let a user arrange a display a column
based on any of the supported naming mechanisms. One can also imagine
a user interface that allows the user to click on some other
application and the appropriate current "container" (e.g. directory,
newsgroup, mail folder, etc.) being used in that application is used to
head a new column in the browser.
Suppose another user on a local or remote system, also uses a tag
architecture, and is willing to allow access to information through it
(albeit limited via access control) via the web or a distributed
filing system. We want to briefly describe how such information
could be made available, both via a naming mechanism, and through
integration with a user's local Tag Browser.
Let's consider the case of access through the web (the distributed
file system case is left as an exercise for the reader). As an
example, suppose the user provides an entry point for web access at
http://<some-domain>/, with the Tagger repository
available at
http://<some-domain>/<tagger-repository>
Every tagged piece of information tagged by the user has a unique
id, and can be named via
http://<some-domain>/<tagger-repository>/#<unique-id>.
If the object is actually stored in the repository (or elsewhere on
the user's machine), this URL can be used to obtain the requested
information. If not, then the request will be redirected to the name
under which the information was tagged.
Of course, we also want to use tags as a way of looking up
objects, so
http://<some-domain>/<tagger-repository>/<tag1>+<tag2>+...+<tagn>
could return a list of names (with associated info, including URL's) of all the
objects in the repository which match the specified tags, and
http://<some-domain>/<tagger-repository>/<tag1>+<tag2>+...+<tagn>/<name>
returns the object with the specified name (if there is just one), or
else returns the list of objects and associated info with that name
that satisfy the specified tags.
By the way, all siblings of a parent tag must have different
names, but tag names, in general, do need need to be unique. If two
tags do have the same name, then they are disambiguated using as many
ancestors as necessary -- e.g.
<grandparent-tag>.<parent-tag>.<child-tag>
When the local user is using a Tag Browser, then arranging for a
column to be displayed in the corresponding to
http://<some-domain>/<tagger-repository> should
do on-demand discovery, so that all the accessible top-level tags
and/or types and/or sources of the remote repository are displayed.
Of course, rather than showing the remote user's types separately,
we may want to simply merge that column with the local TYPE column.
We may want to do similar things if some subset of the remote user's
tags are taken from the same community taag set as a subset of the
local user's tags (determined through some TBD mechanism).
Following along this line, it would be particularly interesting to
use a Community Tagger. Imagine a community of individuals, sharing a
common tag set. Whenever a member of this community tags something
with one of the community tags, the tagged information is sent to the
Community Tagger, which is expected to intelligently deal with the fact
that same piece of informaton may be tagged differently by different
members of the community. Collaborative Filtering is but one example
of how community tagging could be used.
Suppose that every textual piece of information known to the
Tagger was also analyzed so that it could be located by text-based
searching similar to the way documents are located by web search
engines like Lycos, InfoSeek, and AltaVista. In fact, tools like
egrep are already available to implement local text-based searching.
The combination of tagging (probably even very limited tagging)
along with local searching would allows users to very rapidly and
easily locate information.
One way to integrate searching with the Tag Browser is to add a
Match button to the browser, from which the user could pull down a
menu of various search engines. The actual engines available would
likely depend upon context. If the user selected an audio type tag,
then text-based search engines would hardly be appropriate (though, in
the future, audio searchers could be a real possibility). Similarly,
if the user had selected "tags" that corresponded to navigationg
within some remote system, then the browsers should be ones known to
be available (through some TBD mechanism) on the remote system.
The search engines themselves would not need to understand tags --
whatever objects (or parts of objects) are returned by the search
engines would be filtered against the objects (or parts of objects)
satisfying the tags selected in the Tag Browser.
The essential integration issue is to determine what subset of the
textual information known to the Tagger should automatically be
textually analyzed. A reasonable answer is -- all the infomation
"owned" by the user, as well as all information viewed by the user.
In general, user settings can determine which information hould be
automatically analyzed, based on tags, on whether the information was
viewed, and on whether and how it was discovered,
Unfortunately, this paper is already too long to spend very much
time on tag properties other than explicit tags. We'll just very
briefly sketch out some additional tag properties, and leave it to the
reader to evaluate their use and value.
Implicit tags are tags which can be automatically
associated with a named piece of information. There are two kinds of
implicit tags:
An implicit tag may not be a composite tag, but it may be included
as the child of any composite tag. Interesting placements have some
interesting uses. However, the uses are based on two important
aspects of an implicit tag with respect to a particular parent of the
tag.
First of all, we have to consider which possible pieces of
information are tested to see if they should be tagged.
Second of all, we have to specify when a particular implicit tag
is to be tested. For each parent (independently), an implicit tag
can either be tested on request or automatically.
Implicit tags are essentially one mechanism for automatically
specifying and controlling software agents.
Also, an explicit tag may be specified to be a covering tag
for its parent. If some parent tag P has a child C which is a
covering tag for P, then a piece of information is automatically
assigned tag C whenever it satisfies tag P.
Finally, an explicit tag X can be tied to (or based on) some
other tag A, either implicit or explicit. If X is tied to A, then if
a named piece of information has tag A, then it automatically will be
assigned tag X as well. Later, if the information loses tag A, then
it will lose tag X as well, unless some user or software agent
explicitly tagged the information with X (or a descendent of X).
More discussion of these tag properties, as well the user
interface designs for supporting them, is deferred to another time.
The paper describes an architecture for associating tags with
pieces of information, and for using a Tab Browser to locate
information that has been tagged, or that through on-demand discovery,
could be tagged. The Tag Browser can be thought of as generalizing
models like the NeXT directory browser to deal with arbitrary
heterarchies of tags in a coherent and useful manner.
Moreover, we show how the Tag Browser can be integrated with
existing hierarchical browsers (e.g. mail systems, newsgroup readers,
file managers), and take over much of their functionality.
Discovery and Lifetimes
Ensuring Accessibility
Locating Information Using Tags
Browsing Using Tags
Other Features
Viewing Information Attributes
The bottom pane is used to list, upon request, names of all the known
pieces of information which satisfy the tags selected in the top pane.
For each piece of information, in addition to the name, the bottom pane
can include such things as
Using Names & Attributes for Filtering
Integrated Browsing
The Tag Browser can be used to locate pieces of information which are
already known to the Tagger, and which are adequately tagged, but we
still need to use existing applications to deal with
Source-Specific Integration
Access to Remote Tagging
Integration with Searching
Additional Tag Properties
Conclusions