Merideth Naomi is now 15 months old No new pictures posted. Yet.

- Fritz. (Aug. 6th, 1998)

Envisioning UMDL

by F.E. Freiheit IV

ILS 888

Thursday, December 7th, 1995

Introduction

The initial idea of this project was to describe and design an interface for the future of the University of Michigan's Digital Library{1} (UMDL). The UMDL is a significant effort sponsored by NSF, NASA and ARPA and shared among six different universities (see Birmingham [1994]) extending over a five year period with the intention of providing a wide variety of users an understandable easy to use interface into a large number very heterogeneous sets data, varying greatly in size, scope and support. This is not to say that it provides a monolithic interface, the same for all users, but rather it is intended to provide an architecture that makes available any number of a variety of user interfaces and other services.

One of the original design intents of the UMDL and its sister projects is to provide an intelligent search engine and schemes for storing and accessing information about data (i.e. metadata). Given the popularity and rising availability of the Web{2} today, it is not surprising that most incarnations of the DL{3} projects, including UMDL, have been implemented as Web servers and Web browser user interfaces{4} that are Web. This may seem like an aside when considering the process of designing a new interface, but it is introduced to illustrate one of the key architectural considerations of the UMDL design philosophy, and thus it is something that should be taken into consideration when designing a new user interface for UMDL. So what is the point? Is it just that the Web is a "sexy technology" that everyone is using, or is there some inherent feature to the Web, and more generally to the Internet, that makes it an ideal environment to implement the UMDL architecture and design philosophy? The answer is that, yes, there is such a feature or set of features of the Web. These features are the diversity of data, both in format and content; the diversity of process, i.e. what you can do and how you do it, the diversity of the audience or user, and the rapid changes that are taking place on the Web, affecting almost everything else about the Web. All these things map very nicely into the design philosophy of the UMDL architecture. The architecture's goal is to provide a way to describe this diversity at as many levels as possible and provide a means to define search across the heterogeneous system UMDL system{5}.

Using the UMDL will not be simply a question of "how do I find some piece of data X?"{6}, but rather "how do I get my job done?". Once a job or task has been defined, it is very likely that search will be a component of it, but this is by no means a given, nor is it immediately obvious how and when search should be conducted.

After starting out with the question "What will the UMDL user interface look like?" and then considering the variety of the potential user base, data, and software that might be available it became a question of "Where do we even start in defining the user interface?" So instead of sitting down and saying that we will use multi-tree's to represent search results and a data wall to display the user options and configuration interface we took a step back and began to think in terms of trying to define, even in a general way, how the UMDL system would be used. Thus 'The Scenario' was born.

The Scenario Setup

The goal of 'The Scenario' was to exercise and focus our thought processes to form an idea of what it is that the UMDL user interface needs to do and how it might do it. In addition, we wanted to ground it by using one of the current UMDL user groups with a topic area already available in UMDL collections{7}. This would lead us to naturally consider a user interface that might be actually implemented during the lifetime of the project. With that in mind the following class room scenario was selected. A teacher assigns a number of group projects to a class to research topics in astronomy where each group is to produce a presentation and artifact{8}. The particular group project (i.e. scenario) that we selected was given the title "Beyond the Sun" with the additional clarification that it is intended to be a report about something outside of our solar system. Finally, the presentation that the student groups each give must be geared to getting the other students involved, either during the presentation or with the artifact that is produced.

Scenario Assumptions

The following assumptions were made during the construction of the scenario for the purposes of this paper{9}.

· The class room is geographically distributed. So instead of calling it a class room, it will be called a learning forum.

· A new school system has just been brought online. That is to say that there are several students joining the teaching forum who have never used the UMDL while the rest of the students are at least comfortable with it, if not adept.

· To a large extent economic{10} issues will be ignored. That is to say that the sources that the students will be investigating have already come to some agreement with the governing body that is providing the infrastructure for the learning environment.

The Scenario

After all the students have logged in the Advanced Natural Sciences{11} forum mentor {12} Mr. Clarke introduces several new students to the forum and asks for volunteers to help them become comfortable with the new working environment that their UMDL interface provides them. Mr. Clarke then proceeds to review the events of the last week and, as he promised, introduces the students to the "big project" that he has been planning.

While reviewing the previous forum events, Mr. Clarke suggests that the students take the time to e-mail a note to one or two of their favorite guest experts who so graciously took time out of their busy schedules to meet with the students in their virtual lecture and discussion room{13}. In addition, he continues, they should keep in mind that these very same guest experts might very well provide one of the starting points for their specific group projects. At this point, Mr. Clarke launches into his presentation of the various projects, first by briefly presenting pointers to other forum project digital artifacts{14} that have been produced by previous forums mentored by Mr. Clarke as well as to other DAs that he is aware of. Mr. Clarke then presents the specifics of each group project and the class breaks down into working groups.

During the process of breaking down into working groups each group creates a work space{15} using the forum's current work space, Mr. Clarke's work space {16} and each group member's work space as source templates{17}. Once a work space is established, actual group work can begin.

The four students that make up the group that will be the focus of the remainder of this scenario has three experienced UMDL users and one of the new students. The new student, Xavier, has a "vanilla"{18} version of the UMDL user interface already available to him, but has not interacted with it enough to establish a significant level of customization{19}. The rest of the group decides to give him a leg up on customizing his personal work space so that he will be a more effective member of the group{20}. To this end they quiz Xavier about what he likes to do, what books he likes, what media he likes, and etc. and show him user interfaces that reflect his answers. One of the important things that the more experienced members of the group show Xavier is how to search for interface metaphors{21} and acquire components of these metaphors for his own user interface, something that is not immediately obvious how to do from the "vanilla" interface that Xavier starts out with. Another thing that allows Xavier to quickly increase his productivity is that other members of the group give him copies of tools and algorithms{22} that they have found useful.

After Xavier is feeling a little bit more comfortable with UMDL, the group proceeds to apply themselves to the question of what is "Beyond the Sun". A great deal of the initial discussion focuses on what they are suppose to do. A number of the group members complain that it is to open ended of an assignment, and what are we suppose to do? Another member suggests that they just start looking around for stuff in outer space and what is to close to the sun they can throw out. This is still to big, they think, and they are about to ask Mr. Clarke for some guidance when one of them remembers that one of the experts they had in the discussion forum last week was a scientist from JPL{23} and that the scientist mentioned something about a thesaurus of space oriented terms that NASA maintains. They quickly pull in a reference to these NASA resources and they link them into the group work space{24}. In addition, they locate a term authority{25} maintained by NASA. This provides a set of search terms and search term validation which they then use to start exploring space related information.

At this point the group decides that since they have a common foundation of search terms they can now pursue searches individually with reasonable confidence that what they find will have basic elements in common.

During the initial search phase, each group member works out of the group space. As data sources{26} are found, queried and the results returned the work space begins to accumulate a complex set of data. This data is heterogeneous and represents the following sorts of data: automatic logs{27} of group members activities, references or links{28} to data sources {29}, partial data{30}, queries{31} combined with their results {32}, tools, macros and other types of programs{33}, and meta-data such as ontologies{34}. As the data collects it is integrated by the group work space collection integration agent{35} and becomes one of the data sets that the group members search across{36}.

As the work progresses, Mr. Clarke periodically checks up on the group, talking with the various group members, observing them in the process of their search and the results of their search (see Figure 1). Mr. Clarke makes use of a number of filters and indexing agents{37} to judge the cohesiveness of the data residing in the groups work space. He feels that the group would benefit from taking a closer look at what they have actually found up to this point. So he calls a meeting of the group and introduces them to some the of the tools that he has been using to observe their work space. With these tools in hand, the group takes the time to observe the data in their work space and begin to construct some inter-relationships that are not immediately obvious. With a better understanding of the possible gaps in their research as well as a better idea of what fits thematically with what they have found the group continues their search.

· Several live telescope data feeds. This includes a satellite based telescope similar to the Hubble space telescope. The one that the group members find the most interesting is the time shared remotely controlled telescope that allows users to control what it is pointed at through the Web. · Photo and spectrum database of interstellar objects. · The SETI{38} project Web site, with both live access to radio signals from outer space and a massive data base of previously observed radio signals. · A number of SF{39} oriented fictionalizations including movies, books, docudramas, and edutainment. of prior work dealing with events beyond the solar system. Which lead to a number of experts, both real and "fictional"... · Experts. This included both fictionalized and real (including AI or NI versions) of Captain Kirk , Spock, Carl Sagan, as well as the expert from JPL. (The group intends to see if some of these experts might volunteer to be part of their final project. This would be more likely for the AIs than the NIs.) · Simulations of solar systems. Based on observed solar systems and speculative models of solar system formation. · Alien contact speculations. · Colonization of space. · Articles about Von Neuman colonizers{40}

Figure 1 - Sample Results

Eventually, as the deadline for their presentation begins to loom large in their minds, the group decides that it must change its focus from finding things to producing something. This engenders an lively discussion, which grows heated at times, among the group as each member tries to show the others what sort of artifact that they should produce. Some rely on other similar artifacts that they have found during the course of their investigation, while Yolanda shows a mockup of an interactive movie of a spaceship flying among the stars near Sol, which she proudly says, is entirely based on real data drawn from NASA data bases.

· Spaceship museum, constructed with interfaces to live data feeds and to historical data bases. · History of observation beyond the Sun (i.e. SETI, Cosmos (by Carl Sagan) and other docudramas) · Interactive "movie" of a spaceship flying among the near by stars built from real data. · "First Contact" game or scenario including a VR version of the planet and environs and simple AIs for various characters and aliens. · Collection of "near by" stars that might have life on them and an analysis of why or why not this would be the case. · A simulation of sub-light colonization or migrations in the galaxy with parameters controllable by a user.

Figure 2 - Suggested final artifacts

Eventually, after much discussion, the group decides to go with Yolanda's mockup as a basis for the group artifact{41}. This leads the group to refine the data that they have in the space, isolating{42} the data that they think does not fit with Yolanda's Spaceship (as they start to call it). In addition they seek new data sources and construct specialized indexes into the their work space and to outside data sources to support the simulation that they are constructing{43}. The majority of the data that the group links into Yolanda's Spaceship resides somewhere else{44}.

The final form that the groups artifact, Yolanda's Spaceship, takes on is a VR simulation of a SF spaceship control console surround by a transparent crystal dome and deep black floor. Beyond the dome is outer space and the user can manipulate the controls to cause the space ship to travel (faster than light) to various stars within fifty light years of Sol. Each star is based on astronomical data pulled, in real time, from various data bases. In addition a number of the stars have planetary systems (supplemented by some of the solar system modeling that the group found) that can also be explored. Any object, including the stars and planets simulated, may be queried for additional information (such as size, mass, solar spectrum, etc.) from the data bases that are used to create the simulation. The presentation that the group gives uses the Yolanda's Spaceship to visit a number of interesting stars and explain (and demonstrate) interesting facts about them{45}.

The scenario does not end with the group producing its artifact but with the question "How did the work space change? " The work space did not just accumulate data, it also learned "the process" that each group member applied to the task at hand as well as how the group worked together. As more and more searches were made the quality of the results of the search go up as the context of the work space built. That means that the work space, as already mentioned, used what it already contained to influence the construction of queries and later the actual construction of the artifact. For example, by understanding that the word "star" meant a large ball of hot plasma rather than a famous person the work space provided a (more or less) intelligent context for the project. Ultimately the work space became a user interface in and of itself as the metaphor of that Yolanda's Spaceship represented became a useful tool for exploring data and speculations about interstellar objects. The fact that what once was a pile of data evolved in turn into a collection of data supporting search and then into a user interface, both as a metaphor and as an actual tool, represents the power, scalability and reusability of the UMDL architecture.

Conclusions and Analysis

What initially had seemed like a straight forward mapping of current visualization technologies to an experimental UMDL user interface turned out to be a much harder process. This process became one of finding a metaphor to visualize. As noted earlier this manifested itself in the form of envisioning and exploring a (more or less) concrete scenario. The fact that we had to come to grips with what UMDL is and where is it going was a blow{46}. None the less we did learn several things{47}. First, and most importantly, UMDL is not just an interface to search engines{48}. It involves the construction of digital artifacts (i.e. authoring) and the building of searchable collections of data. Secondly, and perhaps more subtly, the task was not just a visualization task (either in what UMDL does or in figuring out how to represent what UMDL does). The fact that it isn't just a visualization task is linked to trying to figure out what sorts of tasks might be undertaken, as well as the actual processes involved with these tasks. Without having a better grasp of the nature of the problem it is nearly impossible to solve the question what the UMDL should look like. All of which lead rather naturally to the scenario scenario, since there was no way that we could actually construct a user interface to UMDL.

So what is that we learned from The Scenario? A number of things stand out. Both the heterogeneous nature of the data and the wide variety of users are extremely important. In the face of these to points constructing a cohesive interface becomes very difficult. Constructing a monolithic interface{49} becomes nearly impossible. Even a single user would potentially interact with UMDL in significantly different ways depending on context, both in terms of the information that they might be seeking, and in terms of other goals, such as constructing digital artifacts. In light of this and the fact that more than one user might want to work together on some project, it becomes important that the UMDL user interface support the definition of work spaces that allow inheritance, embedding and transfer of properties and/or control. Since a single interface does not seem to be reasonable, the design of the default interface is crucial. A good default interface allows new users to do enough so that they can find things that they are looking for, has an intuitive method for doing this searching and provides intuitive access to help. Since it is unreasonable to expect that such an interface will be entirely suitable for all users, there must be mechanism for either customizing the default interface or for finding other interfaces and making them available to the user. Finally, it is important that the default interface (or any UMDL interface, for that matter) also be capable of learning about and from the user. In the long run UMDL interfaces must adapt and change both the user's needs and to what will certainly be a information environment in flux.

It is unfortunate that so many of the visualization techniques that we have studied and discussed in Information Visualization turned out to less than directly applicable to envisioning UMDL. This is not to say that these techniques have been a waste of time. Far from it, they provided many exciting starting points for envisioning UMDL in the minds eye, allowing one to predict possible processes and methodologies that will one day find embodiment in UMDL. But until then, the UMDL interface of Mr. Clarke and his students are a sparkle in our eyes.

---

Notes

[BACK] [1] The name of UMDL is somewhat misleading with respect to "Digital Library". The nature of this mislabeling should become clear with the exploration of what users could expect to do with the system. But at this time there is no real consensus that it should be changed, the term UMDL will continue to be used in this paper.

[BACK] [2] In general references to the Web are references to the Internet as well.

[BACK] [3] Digital Library.

[BACK] [4] This has presented a number of problems, of which the most glaring has been the inherent limitations in extending the Web browsers, to date.

[BACK] [5] Search in the UMDL takes advantage of an agent that consolidates information about all the other agents in the system. This agent keeps track of what services other agents in the system provide, whether an agent represents a collection and what sort of collection it is (including such things as general topic, search services, economics costs, terms and conditions, etc.).

[BACK] [6] This was precisely the way that we approached the problem of what UMDL was suppose to do at the inception of UMDL, but there has been a growing sense that this is not quite the right question.

[BACK] [7] A 'collection' is UMDL terminology for a set of data, i.e. a data base. It may or may not have an associated search engine.

[BACK] [8] Or 'digital artifact' (DA). An artifact is some authored object which may include (but is not limited to) one or more of: written words, spoken words, graphic art, video, animation, virtual reality modeling, simulation, or some other computer program, tool or utility.

[BACK] [9] These are in addition to the scenario as the project group defined it.

[BACK] [10] Economics would provide a whole other dimension of analysis. It is assumed that the users of the UMDL are made aware of the economic costs of the searches, construction, etc. that they undertake.

[BACK] [11] The Advanced Natural Sciences or ANS forum is a twelfth grade level high school course being taught entirely through the Web.

[BACK] [12] I.e. teacher.

[BACK] [13] I.e. a virtual reality (VR) version of video conferencing.

[BACK] [14] These digital artifacts are, of course, different in topic matter,

[BACK] [15] A "work space" plays an important role in dividing up the UMDL space into more manageable pieces and to allow access ("read", "write", "update" and "delete") permissions to be defined and maintained. A "work space" allows a space or project specific profile to develop, a place for tools, data resources, ontologies, and other artifacts to accumulate, as well as a place for definition and/or accretion of relationships between these artifacts to be established. As an example, a work space for an astronomy would give preference to the meaning of 'nebula' over 'atmospheric' when talking about or searching for the term 'cloud'.

[BACK] [16] One important component of Mr. Clarke's work space (with respect to the ADS forum) is a "virtual person" (VP) that is to say a "virtual version" (VV) of himself. This virtual Mr. Clarke has been constructed through the process of Mr. Clarke interacting with a virtual personality construction agent and through Mr. Clarke fielding frequently asked questions (FAQs). As Mr. Clarke answers questions from the forum, the virtual Mr. Clarke learns the real Mr. Clarke's responses (perhaps helped along by pointers given to it from Mr. Clarke) and becomes more and more capable of fielding the questions itself. Thus the virtual Mr. Clarke answers the questions that it can, and when it can't it attempts to swap the real Mr. Clarke in (in real time), and failing this, it forwards the question to Mr. Clarke's personal work space.

[BACK] [17] When a work space is constructed an intelligent software agent is used that attempts to blend together the appropriate characteristic of each member of the group derived from their specific work spaces. It would also be expected that the work space construction agent would also be able to interact with the new work space owner(s) to resolve conflicts and ambiguities.

[BACK] [18] The basic, or "vanilla" version of the UMDL is intended to provide the most effective, i.e. usable, interface into UMDL as possible. This user interface is designed with the lowest common denominator of an expected user in mind. This means that it provides immediate and as obvious access as is possible to a sophisticated help agent as well as a basic search agent. The environment is "cartoon" like and tools and other objects will be presented in as obvious and non-threatening a manner as possible. This means, of course, that a great deal of functionality is sacrificed to minimize the chances of confusing the user.

[BACK] [19] As noted previously, a work space becomes customized through use.

[BACK] [20] Not unexpectedly, the more experienced users of UMDL know that by seeing (i.e. interacting with) another person's work space one can develop some good ideas about who that person is. So by helping the new student customize his work space, they get to know him.

[BACK] [21] An interface metaphor can be anything from a simple metaphor such as the Window's or Macintosh desktops to a very sophisticated simulation/metaphorical embodiment of some environment, such as a wizards laboratory with magic wands and staffs which iconify tools (i.e. a crystal ball for searching, a wand for selecting items, magical spectacles for "magic lenses", etc.). Another important feature of user interfaces are interface mentor agents. These are agents that provide a help and suggestion facility based around some historical or fictional character and might be an artificial intelligence (AI) or a VV of a natural intelligence (NI, i.e. real person) who might be taking on some historical or fictional role, or might, like Mr. Clarke, have other reasons for having a permanent Web presence. In fact, entire user interfaces could be constructed around such agents. For instance, if a VV of Albert Einstein was selected as a user interface mentor, the interface metaphor might be a small college classroom from the 1920s including blackboards for writing and displaying information and, of course, the VV of Albert to guide and answer questions.

[BACK] [22] It is assumed that some tools are constructed directly in the traditional way (i.e. by programmers) and that other tools are essentially learned by the work space (i.e. the work space agents bundle up, and hopefully generalize, some set of actions that the owner of the work space performed). A strong distinction between tool and algorithm should not be made.

[BACK] [23] Jet Propulsion Laboratory in Pasadena California.

[BACK] [24] With this the group has established a common working ontology, or context.

[BACK] [25] An "authority" is some agent or data repository that is recognized to have data that is used to measure the validity of other similar data (i.e. the Patent Office is considered to have authority over what is and isn't patented or patentable and has final say about how a patent number maps to an actual patent).

[BACK] [26] Data sources are also called collections in UMDL.

[BACK] [27] The level of detail of automatically logging is controlled by the various users and is a function of the work space.

[BACK] [28] Reference or link is used interchangeably. Sometimes these may also be referred to as 'bookmarks' or a 'hot list' in Web parlance.

[BACK] [29] A data source may be static (i.e. it doesn't change, no additions are made to it) or it might be dynamic (i.e. the underlying data might change, additions of new data might be made to the data source) or it might be live (i.e. the data is based on some real time input, such as satellite photos, weather radar, or a remote camera or other "live" data input device).

[BACK] [30] Partial data is very similar to a link. It is not always possible or necessary to bring into the work space all the data that a query returns. In these cases a partial data item is created in the work space that "knows how to get at the full data item", for example, it may only be desirable to bring in a copy of the abstract of an article rather then the whole article, and if the whole article is required, then the source is queried for it (it is also possible to just tell a tool where the data resides and have it do whatever processing that the tool does at some other computational location and only return the results, for example, a translation program that converts some article from German into English).

[BACK] [31] Queries in general are not made to single data sources but rather are made to a set of data sources. The actual set of data sources depends on the topic and nature of the query, the profile of the user and work space, associations that the user may have, economic considerations, etc.

[BACK] [32] A result of query could effectively be any of the things that is mentioned in list.

[BACK] [33] Programs include machine dependent (such as C or FORTRAN) as well as machine independent (such as Java) code. Programs would also include machine code executables.

[BACK] [34] I.e. a context. This includes syntax, semantics and functional descriptions necessary to understand and talk about a context (such as physics, naive physics, mechanical engineering, library science, etc.).

[BACK] [35] The services that the work space collection integration agent provides is critical in making the sheer quantity of the data tractable that is now in the group work space. The strength of this agent comes from the fact that it mirrors in miniature the overall UMDL system at level of the group. That is to say that it provides a registration process similar to what that provide by the general UMDL Registry agent. This agent also provides indexing and duplication elimination services over the data in the group work space, and also allows the group to publish the contents of the work space to the greater UMDL.

[BACK] [36] This is useful for a number of reasons. First the group work space data set can be used as a comparison or filter for search, and also because each member is searching independently, it is useful to know what other members have found, and finally because it is impossible for any one member of the group to fully appreciate the inter-relationships that exist in the growing work space collection.

[BACK] [37] Analysis of word counts and context in conjunction with space ontologies produces a semantic map of the group work space. This is filtered for specific connections, tuned for significance, observed for when and by whom data was brought into the space, historical sequences of searches and feedback, compared to other existing data bases, etc.

[BACK] [38] Search for Extraterrestrial Life, a long running government sponsored project.

[BACK] [39] Science Fiction, or the more current politically correct and fashionable Speculative Fiction.

[BACK] [40] Robotic space ships capable of self reproduction which can colonize the galaxy without faster than light (FTL) star drives.

[BACK] [41] Probably because Yolanda had already put the work into producing something.

[BACK] [42] The isolation process is method whereby a set of data can be removed from consideration as search modification criteria, yet it is not removed from the space entirely. This has the advantage that the data remains "immediately" available, but does not cause the query construction agents to use it as basis for refining a query.

[BACK] [43] For the most part the construction of the simulation is automated by agents that specialize in the construction of VR simulations. The group still needs to specify how to map the data that it draws from various data bases into the simulation, but the nitty gritty of manipulating pixels is unnecessary.

[BACK] [44] I.e. only pointers and the specializations on the simulation code are maintained in the work space itself. This allows the simulation of Yolanda's Spaceship to have a minimal (possibly even non-existent) maintenance cost as well as always having up to date data and, as the simulation program evolves, Yolanda's Spaceship will evolve and support most, if not all, new features.

[BACK] [45] After the group release Yolanda's Spaceship to the class for use as well as publishing it in the UMDL Registry for public use it is discovered that a number of users are somewhat frustrated by the fact that they don't know how to identify which stars have planetary systems from a distance. But how the group fixes this is another story.

[BACK] [46] Hope springs eternal that one is not in the process of biting off more than one can chew, if you even think about it at all. This was a case where we felt like we were choking from quite early on.

[BACK] [47] Which should have been obvious.

[BACK] [48] That wasn't exactly a surprise, but the fact that UMDL is not just for searching wasn't really internalized. That is to say, what does it mean when you say it isn't just a search engine? What else do you do with it?

[BACK] [49] That is to say a one size fits all, does all interface.

References

Birmingham, W.P.; Durfee, E.H.; Mullen, T.; and Wellman, M.P. [1995] The Distributed Agent Architecture of the University of Michigan Digital Library (Extended Abstract), http://www.isi.edu/sims/knoblock/sss95/proceedings.html

Birmingham, W.P.; Drabenstott, K.M.; Frost, C.O.; Warner, A.J.; and Willis, K. [1994] The University of Michigan Digital Library: This is not your father's library. In Proceedings of Digital Libraries '94, 53-60.

Blair, D.C. [1993] The Challenge of Document Retrieval: Major Issues, and a Framework Based on Search Exhaustivity and Data Base Size.

UMDL System Architecture Specification, Version 1.0, [1994]

Fritz's Home page

Contents

Feedback and comments

http://www-personal.umich.edu/~fritx/envisioningumdl.html