Ellis S. Cohen
Open Software Foundation
11 Cambridge Center
Cambridge MA 02142
ellis@osf.org
The Boston Restaurant List provides access to information and reviews (including those of professional reviewers) of ~1000 restaurants in the greater Boston area. New and updated reviews are based primarily on about 100-200 contributions a month by internet users. This paper discusses some of the lessons learned from maintaining the list, and some of the resulting technical, social, and economic issues that need to be addressed.
The BRL (Boston Restaurant List) has been available on the internet (via usenet newsgroups) for about 2 years. Since March 1994, it has been available via the Web, and is currently accessed by about 300-500 users a week. It provides access to information and reviews (including those of professional reviewers) of ~1000 restaurants in the greater Boston area. New and updated reviews are based primarily on about 100-200 contributions a month by internet users.
The core of the restaurant list is a database of relatively concise main reviews of ~400 recommended restaurants in Boston and its immediate vicinity (e.g. Cambridge, etc.), distilled from user contributions. Original user contributions that are particularly interesting are maintained separately and are available on-line cross-linked with the main reviews.
Restaurants are only included on the recommended list when 2 or more positive reviews of the restaurant have been received, and only remain on the list as long as the positive reviews outweigh the negative reviews. Another database holds ~150 concise reviews of recommended restaurants farther afield -- Cape Cod, Eastern Massachusetts, and the nearby regions of Rhode Island, New Hampshire and Maine.
An additional ~500 reviews are available for restaurants that have only received a single positive review, or where the reviews do not sufficiently recommend the restaurant.
This paper discusses some of the lessons learned from maintaining the list, and some of the resulting technical, social, and economic issues that need to be addressed.
The first two sections address presentation and implementation issues common to all providers of databases -- how to implement the presentation of information to the end user. Presentation Issues for Databases discusses how bandwidth and latency considerations as well as user preferences need to affect the organization of infromation presented. The following section, Dynamic Queries, describes why downloading data and code is essential for providing rapid feedback during searches.
The section on Links to External Information and Services discusses the concerns raised by commercial service providers about links into and out of their information repositories, and suggests some technical approaches to addressing these concerns.
The Boston Restaurant List is a non-commercial service that depends heavily on contributions by readers. The Contributions section describes how contributions are encouraged, and how problem contributions are dealt with. The 100-200 contributions received every month are able to be dealt with manually, but the section on Issues of Scale addresses the problem of structuring and processing significantly larger numbers of contributions.
Many of us who are active in the area of information services envision an environment which encourages a rich network of links among information services, and in which information and information services can readily be reused by other services. The section on Issues of Reuse discusses some of the technical challenges that face us in making this a reality.
There are two ways that users locate information when they gain access to a database. They either want to browse through the information, or they want to search for items that satisfy some criteria (though they may then want to browse through the items found in a search). The main BRL database supports both paradigms. This section focuses on browsing; the next one addresses queries.
In organizing any information repository for browsing, a provider has to decide how to "chunk" the information, and what kinds of paths are provided for navigation.
For a database, consisting, for the most part of relatively homogeneous records (e.g. restaurant descriptions), the major navigation decision is based on the major ways of categorizing the information (i.e. the key fields).
For restaurants, this is pretty straightforward -- you want to organize access alphabetically, by location, and by cuisine -- a model supported by the BRL, and independently "discovered" by most of the restaurant database providers on the net.
The chunking of information, however, is another matter. While the best way to chunk information depends, in large measure, on personal preference, differences in network connections play a very large role:
For example, suppose a user wants to browse through restaurants organized by cuisine:
Optimally, though, an information service should be able to adjust its presentation to support any of these models based on user preferences. Presentation preferences should be able to be set in forms provided by the service. The values of some preferences will have defaults based on (automatically collected information about) bandwidth and latency.
The service could retain the values per-user (assuming a standard for global unique user naming), or better, when set or updated by the service, would be returned to the user's system. On subsequent access to the service, the service would attempt to query the requestor for the user preferences. Even better, the local viewer, should automatically remember to pass the preferences along with the request (but arranging dynamic recalculation of those based on bandwidth and latency).
Some presentation differences based on latency and bandwidth boil down to whether material is accessible in-line or through links. To some degree (and with some HTML and http extensions), this could be completely handled by user preferences, some of which control the delayed loading of text.
When dealing with a list of records, like restaurants, the choice is presentation is not simply between displaying the entire contents of the record in-line, vs. just a link to it. When a link is used, how many attributes of the record are displayed along with the link?
In the BRL, in addition to the name of the restaurant, links to restaurant descriptions include the type of cuisine, the area in which the restaurant is located, and an indication of the typical total cost of a meal. These are the important first-cut attributes for many users, but other attributes are even more important for some users (e.g. whether smoking is allowed, the ease of wheelchair access, vegetarian options, etc.), or for some situations (takes reservations, has outdoor dining, etc.). Optimally, user preferences are the way to address this presentation issue as well.
In summary, we are arguing that different styles need to be supported in presenting information from databases, both because users want this, and because differences in network connections require it.
There are about ~400 recommended restaurants in Boston and its immediate vicinity. Many users will want to narrow down that list based on various criteria, and then browse through the descriptions of the selected restaurants to decide where to eat.
The BRL currently supports queries based on location, cuisine, and price range. (Other attributes would be useful as well as search criteria, but these are the only ones reliably entered at present for all of the restaurants in the core recommended list. Also, maps would be a better technique for selecting neighborhoods than a list.) HTML+ forms are used to specify these queries. The user fills in a form, presses the "submit" button, and a list restaurants satisfying the query (with links to complete descriptions) are displayed. If necessary, the user can go back the query, modify it, and resubmit it. (Note that some intelligent assistance would be useful here, for example, in suggesting a slightly larger or narrower area, or suggesting additional cuisines related to the ones selected.)
Today's Web technology allows the HTML+ form defining the search criteria to be defined by the back end information service in a toolkit-independent manner. The form is displayed, however, by a front-end browser using a GUI (Graphical User Interface) specific to the front end. On Unix workstations, the form is presented using Motif or some other X-based toolkit. Character-based terminals use a character-based interface (e.g. Lynx). On Macs, the Mac toolbox is used, and on Windows PC's, Windows is used.
This separation between the front and back ends means that users can fill in forms interacting with the front-end process only; interaction with the back-end service is not needed until the form is completely filled in, and the user presses the "submit" button on the form.
This separation of functionality forces an iterative interaction style -- the user specifies the query, submits it, sees the results, decides that too few or too many entries have been chosen, modifies the query, submits it again, etc. Even with a reasonable-latency connection, this interaction style is not as desirable as we might like.
Ben Shneiderman has been arguing lately for dynamic queries [Shn94]. That is, users must be able to change search parameters on-the-fly (preferably using sliders or other incremental controls), and as the search parameters are changed, the user must be able to get immediate visual feedback.
In other words, in our interface, at a minimum, the list of restaurants should be shown side-by-side with the form, and as we made any change to the form, the list of restaurants should immediately change to reflect it.
Schneiderman would argue further for a more visually compelling interface -- for example, rather than (or in addition to) the list of restaurants satisfying the query, a map should be displayed with points (perhaps color-, size- or texture-coded to indicate various attributes) indicating the location of each restaurant found.
This kind of dynamic query interface cannot be based on the same front-end/back-end separation as forms. To provide reasonable dynamic feedback, all of the query functionality must reside on the front end.
When the user chooses the search link, the information service needs to download code to support dynamic queries, as well as the subset of the database necessary to support querying -- in our case -- the name, location, cuisine, and price of each restaurant.
Of course, allowing execution of downloaded programs is a potential security hole, but this concern can be addresses either by executing the code in a restricted environment, and/or requiring that the code be interpreted by a safe interpreter such as safe-tcl. Properly designed safe interpreters, of course, have the advantage that they can run on any front end, so that the interpreted code developed by the provider can be independent of the front-end platform.
Safe interpreters need to provide access to a front-end-independent GUI to display forms as well as more complex graphics such as the map of restaurants described above. For compatibility with other applications on the front-end platform, the interpreter (like Mosaic's interpretation of HTML, but unlike Tcl's [Tcl94]) interpretation of Tk, should map its GUI model to the dominant toolkit on the front-end platform.
By the way, once front ends ubiquitously support safe interpreters, and back-ends download code to support dynamic queries, back-ends will still need to provide direct access to subsets of data in their databases for delivery to front end programs.
That is because we are likely to see the evolution of separate front-end programs which want to reuse information available from back-end services, as part of their own more sophisticated services or interfaces (we'll provide some examples in the section on reuse). These front-end programs will most definitely not want to access the information through downloaded interpreted user interfaces -- they just will want access to the raw data available. Today, this access is likely to use the http protocol, but there is good reason to believe that will change,
As distributed computing environments like DCE [DCE93], CORBA [CORBA93], and OLE [OLE94] become more widespread, the distinction between the Web and these distributed computing environments will blur, and the two will become tightly integrated, possibly through protocol gateways, or migration from http to the distributed computing protocols.
These developments will be driven more quickly by the proliferation of back-end interpreted code as well as front-end programs that access back-end services. One factor that may speed development are the increasing availability of UIMS's that support the interactive design of interfaces to back end services (e.g. db-UIM/X, or SynchroWorks)
The BRL contains links to a large variety of external URLs, including a number of links from individual restaurant descriptions, including
In the future, it would be nice to provide direct access to additional information and services provided directly by (or on behalf of) the restaurants themselves including notices of menu changes, images and videos of the food and the restaurant, reservations (e.g. DisneyWorld), and automated take-out and delivery services (e.g. PizzaHut) with payment using either encrypted credit card numbers, or a scheme like DigiCash [Chaum92].
Over the last few months, I've talked to the major print media providers in the Boston area about putting their restaurant reviews directly on line, and allowing me to link my reviews to theirs. I didn't think they'd necessarily be willing and enthusiastic (and they weren't), but it seemed worth a try. Reading between the lines of the conversation I had, they seemed to have two concerns:
At present, they see this as requiring access to their information through a restricted front door, such as provided by CompuServe or America On Line, which provides both identification and financial packaging at the same time.
Those of us who prefer to see rich interconnections between information repositories rather than information islands need to convince commercial providers that there are other possibilities -- but this will require advances in both protocols and viewers:
In addition, we would like to see commercial services link to other information sources as well -- in particular, we'd like to see restaurant reviews placed on-line by other providers point to the BRL.
Of course, there may be some reluctance to point to providers seen as direct competitors, but ultimately, the providers seen as most valuable are likely to be those who have access to the widest collection of information (with good organization, path, and filtering mechanisms, of course). Encouraging use of external links by commercial providers also requires some technical advances:
There are other issues relating to external links, which primarily affect reuse; we'll discuss them later in Issues of Reuse.
Most of the information in the BRL comes from contributors, in one of three way:
Reviews sent via the on-line form are by far the easiest to process. The form itself encourages reviewers to include information that they might not otherwise think of (e.g. child-friendliness, non-smoking areas, wheelchair access, availability of low fat or vegetarian food). It also encourages information to be provided in a way that's most useful for comparison purposes -- i.e. it asks separately for the range in cost of entrees and also asks for the average price of a complete dinner including tax and tip. Unfortunately only about 10-15% of the material in the restaurant list currently comes from them.
E-mail sent directly to me is the source of about 30-35% of the restaurant list material, and tends to be the hardest to process. The material sent by e-mail doesn't always include some of the important restaurant factoids (e.g. hours of operation), but (although there certainly are exceptions), they tend to be far more interesting and literate than the reviews sent via the on-line forms.
Many of the e-mail contributors have access to the on-line form. Perhaps when they decide to send a review they are not viewing the list or don't want to navigate to the form. Perhaps they just hate filling out forms, or perhaps they simply prefer to use mail because of its relative informality and flexibility. A survey of contributors is in progress to provide some of these answers.
Finally, posts to the ne.food newsgroup are the source of about 50-60% of the material eventually included in the reviews, although they comprise close to 80-90% of the actual contributions. In part that's because most newsgroup posts are not complete reviews, but are snippets of information sent in response to the post of a query or another response. Moreover, many of the posts simply reiterate points already made in the discussion, or contain information already included in the restaurant list.
Still, some users prefer to post their reviews directly to the newsgroup, and even brief responses can contain new information. In addition, material I post to the newsgroup encourages many, perhaps most, of the reviews sent via e-mail and the on-line form.
The ne.food newsgroup is a crucial adjunct to the on-line list, and is probably responsible, in one way or another, for the vast majority of the material in it. It's hard for me to imagine any kind of large-scale dynamically-changing user-focussed structured information repository that is successful without an associated newsgroup, unless economic incentives are provided for reviews.
Because the restaurant list is free, I haven't tried to offer monetary incentives for reviews. Zagat, for example, offers free copies of their Boston restaurant guide to anyone who sends them a completed review form.
I've thought about offering prizes, perhaps free dinners for two at some restaurant (hopefully provided free to me as well by a participating restaurant) to randomly chosen contributors, or even better, those contributors responsible for the most new material in the course of some interval (say every 3 months). My own limited time has prevented me from exploring this further.
So, at present, reviewers, especially those who use e-mail or the on-line form, send a review strictly as a way of contributing something back to a service they've found useful. Luckily, there are a number of people who tend to send in reviews regularly, but many of the longer reviews come from people who are excited about their recent discovery of the list, but who are rarely heard from again.
My focus, thus far, has been to encourage one-time or infrequent contributors to contribute reviews more regularly. Here are the various things I've done:
Acknowledgements would also let people know that I've received their contribution, although at present, I place all new contributions in a file accessible through the restaurant list home page, until they've been processed.
Starting next month, I will be publishing the names of those who
have contributed reviews during the previous month in order to
publicly acknowledge them.
Separately retained reviews of a restaurant (each with the author
and the date received) are appended together
and are cross-linked to the corresponding
main review. A file containing all the interesting reviews
are a link away from the restaurant list home page. Once
a month, I post the interesting reviews
I've received during the previous month to ne.food.
Typically, these appeals produce a flurry of reviews, though
unfortunately, the reviews are rarely of recently opened restaurants.
In fact, one of the great weaknesses of the core list is the amount
of time it can take for newly opened restaurants to get the requisite
positive reviews to be included on it. I sometimes post a query
about a specific restaurant on the newsgroup to help deal with this
problem.
In the early days of the BRL, when a review of a new restaurant came in, I distilled its contents, and based on the review, immediately put the restaurant on either a recommended list or an avoid list. This approach had a number of problems, which were corrected when I switched to the method described previously.
First of all, some lengthy and interesting reviews nonetheless rated a restaurant as mediocre. I certainly didn't want to put the restaurant on either the recommended or avoid list, but still wanted readers to be able to access the review, and see what was said about the place.
Some reviews of new restaurants thought a place was great, but the overall tone of the review left me questioning the contributor's ability to fairly evaluate the place (especially if I suspected the place was an uninteresting dump). On the basis of the review, I certainly didn't want to place the restaurant on the recommended list, but I didn't want to entirely toss out the review either, especially if it was one of those rare undiscovered gems. Requiring two positive reviews to graduate to the recommended list (and sometimes more, if I have some doubts about the reviews) solved this problem.
At various times, I've gotten reviews that seem to excessively denigrate the quality of the food or service of a restaurant. These tend to come with a long fascinating story about a horrible dining experience. I keep these long reviews available on-line, but if there are other positive reviews of the restuarant, I tend to treat these as the result of exceptionally bad nights for the patron and/or the restaurant, unless there are other confirming reviews. Other than noting the review and the possibility of serious problems, these do not substantially affect either the contents or the inclusion of the main review in the recommended list.
Remarks about sanitation are a real problem. There are a number of restaurants which have very positive reviews in general, but where I've also received comments about problems with rodents, insects, or food poisoning. In the past, I've included these comments in the main reviews, but I'm about to revise this policy.
First of all, there are possible legal ramifications. But, there's also the simple matter of fairness. If someone has to choose between two restaurants, and one sounds a tad better, but there is a hint of apossible sanitation problem, they are likely to choose the other one. So, from now on, before I include these kind of comments in a main review, I plan to query the ne.foods mailing list, and wait for additional confirmation.
One problem that does not seem to have arisen is that of intentionally misleading positive reviews of mediocre restaurants by restaurant owners, or their friends or relatives. Friends and relatives have sent in a number of reviews (sometimes excessively positive), but they've been careful to identify their affiliations, and the normal mechanism of requiring two positive reviews has been an adequate check thus far.
The 100-200 contributions I process a month are still within the bounds of my ability to handle them manually, and even if the number of contributions doubled, I'm hopeful I could find someone to share the work with. But what if the list evolved so that the number of form-based contributions increased significantlylly? How could the provider of any low-cost information respository service deal with an increasing number of contributions?
An obvious possibility is to replace text-based fields by collections of ordered multiple-choice fields -- e.g. replace the field that asks for a description of the food by multiple choice fields for quality, quantity, richness, flavoring, presentation, etc, and then use running averages of these ratings. Even assuming that contributors will have the patience to fill out such a form, and that readers will have the built-in multidimensional analytical skills to make sense of the results, there are still serious problems with this kind of approach.
Both the concise reviews and especially the longer reviews convey a sense of the experience of being at the restaurant and eating the food that simply cannot be captured by multiple choice fields, even if we could all agree on the meanings of the field values. Perhaps reviews of appliances could use this approach, but in areas in which subjectivity and user preference play a large role, this technique becomes less useful. This is why, in my opinion, Consumer Reports ratings of food products tend to be much less useful and valuable than rating of lawnmowers.
Notions, for example, of presentation, flavor, and richness have entirely different meanings to the typical 45 year old contributor and the 20 year old contributor. So much so, that running averages are likely to be useless without knowing some average profile values of the contributors, or using them to weight (how?) the field values. Well, perhaps this is possible, and even a valuable tack to explore, but I am sceptical. Longer text-based reviews instead provide lots of cues which can be used to characterize the contributor. One of the most important jobs I have as maintainer is to use these intuitions to emphasize or downplay reviewer comments when distilling them into the main reviews.
Perhaps the most important, and yet most problematic ratings field is the overall rating. I've received a fair number of requests to publish overall ratings of the restaurants, or at least to publish lists of the top few restaurants of each type. But I've been incredibly reluctant to do so, based on my own strong disagreements with the best restaurant picks of Zagat's and Boston Magazine. Recently, I've had, what I think, is a much better idea, and eminently suited to the technology of the web.
I've asked people to create a file containing a list of their own favorite restaurants, and to send me a paragraph, containing a link to their file, along with a description of their constraints in going to restaurants, and their biases in rating them. I now have a page (accessible from the restaurant list home page) which contains a compilation of these paragraphs. Interested readers can look for someone whose constraints and biases mirror their own, and then check out that person's favorites.
So, let's return to the issue: if form-based contributions increased significantly, how could we deal with an increasing number of contributions?
First, we could use a structured notesfile model per-field. That is, we could arrange the interface so that, for any field, users could see previous comments, could provide a fresh comment, or could respond to or even annotate an existing comment. The hope is that users who wanted to add new comments would check out the comments already made and try not to be repetitive. Unfortunately, existing notes traffic is not very supportive of this conclusion. Still, with structured notes, a listing of base-level comments plus their refutations (but not refutations of them, etc.) might possibly provide a reasonable amount and quality of information.
A second possibility is to allow contributors to propose edits to the main review. The maintainers job becomes somewhat simpler -- at simplest, the edits could either be accepted or refused (with a multiple choice reason), and authors of refused edits could try again. But even maintainers who were willing to revise edits would find their job simpler than revisions starting from raw reviews.
A third possibility would use a note-based system, but allow any user to post chargable reviews. That is, a reader who wanted to read the note would be charged a certain amount (using some scheme like DigiCash). Not only would this encourage professional reviewers to include reviews, but it would allow the role of the information repository provider to be decoupled from the role of the review distiller. Anyone could become a distiller by reading through all the posted notes and creating (or updating) a distilled review. If particular distillers gained a good reputation, users could set a filter to see notes just from them and from professional reviewers. Or more likely, the filter would be set up by a broker or repackager through whom the user arranged access to the information in the first place.
The information available through the BRL is valuable beyond its use through the interface that I, as its maintainer, have made available. The essential question is: how easy is it to reuse the information for other purposes?
Reuse at is simplest allows other services to link directly to the information provided. Other services already use the restaurant database in this way, including The New England Folk Concert Calendar, which keeps track of local folk music performances; descriptions of performances in area restaurants include a link to the restaurant entry in my database.
As we alluded to earlier, this form of reuse has the problem of invalid links. If I decide to reorganize the BRL database, the URL used to identify the restaurant may no longer be valid. In part, this can be addressed by automatic naming and forwarding services. However, this is also a reflection that authoring tools are not available which allow construction of the kind of higher-level interfaces and information hiding well understood in software engineering.
The core BRL database is currently spread out over 40 files which divide the restaurants by cuisine, with name anchors on each restaurant. So, for example, an external access to, say Dali, a Spanish restaurant uses the URL http://www.osf.org:8001/boston-food/spanish.html#dali. A much better access technique would use a specialized interface, e.g. with URL http://www.osf.org:8001/boston-food/core-lookup?dali.
In other words, the BRL would advertise (in various ways, including through public interface repositories) the existence of the core-lookup interface (and other interfaces). Developers wanting a reliable access method would use that interface; others could take their chances.
And various examples of reuse provide plenty of reasons for taking chances. Consider information providers who wanted to provide the following services:
The BRL's search interface supports searches by town, and Watertown is within the core area. So provider 1 (i.e. Things to do in Watertown) could use the BRL's existing search interface to get a list of recommended restuarants in Watertown, and could even make the request dynamically, for example, when a user of provider 1's service clicked on a "Recommended Restaurants" link.
However, Lexington is outside the core BRL area, but the file western.html does include a section on recommended Lexington restaurants. Provider 2 would have to request this file, and then process it, to get the list of recommended restaurants. A reorganization involving this file could well be a problem.
Similarly, the BRL's search interface allows searches for Cuisine (eq to Vegetarian), but there are a much larger number of restaurants that have lots of vegetarian options. Searches on the attribute VegOptions (eq to lots) are not currently supported, so it would be necessary for Provider 3 to access all the core files and search for VegOptions as needed.
In general, providers that use external links have expectations about the structure of the other providers' information. To the extent that these expectations can be captured as pattern descriptions, servers can relatively easily check whether the expectations remain satisfied after an edit, and can automatically send notifications to providers whose expectations have become violated. These can then trigger code which can at best automatically adjust for the reported changes, and at worst, remove the external links and send mail to the responsible developer.
When a user accesses information from service B through service A, service A may want to add annotation and links (perhaps back to entries provided by A) to the information presented by B. A could provide these extras by dynamically mirroring B's information and presenting it with the added annotations and links, but it may be worth considering protocols and architectures that would allow B to specify the additions up-front or through call-backs.
An even more intertwined form of reuse concerns providers who want to extend the information provided by another service in a seamless way. Consider the following example. Suppose someone tells me that they like my restaurant list, but they really wish I'd keep track of which restaurants have an outdoor dining area, or which one have lots of vegetarian options. In fact, in the last year, I've added both of these attributes to the database, as a result of reader requests, but I haven't been very good at assigning values to them for all the restaurants in the list -- I do so when its convenient. Or, suppose someone asks me to keep track of restaurants that serve hard cider, or that offer Baked Alaska. There are people interested in both of these (evidenced by discussions on ne.food), but I'm not very likely to add these attributes to the database.
If I'm not interested in adding or scrupulously maintaining an attribute to my database, can someone reuse the BRL service and maintain the attribute themselves. They could certainly wrap their service around mine. For example, they could provide their own restaurant review form, which would add a field to my form, extract their attribute, and then send along the rest of the data to the BRL service. This works for one attribute, but not very well if there are lots of people who want to add attributes. If we are serious about letting anyone be a provider, then we may want to consider provider architectures that allow third party providers to add arbitrary fields, and allow users (or their brokers) to select the fields they actually care about.
The point to be made here is that there there may be patterns of reuse which can be be addressed by extending protocols or viewers, though additional exploration is needed to evaluate cost/benefit tradeoffs.
Reuse also raises substantial legal and economic issues. Some of these can be addressed technologically, while others will need to be addressed by traditional contract negotiation, with technical enforcement limited to traditional authorization schemes. For example, if service B has an agreement to allow service A to reuse its information or services in a particular way, then service B can allow A (using a standardized authentication mechanism) access to agreed upon information or services, but not others. Still, some out-of-band monitoring would potentially be needed to ensure that A's use of the information and services did not exceed the terms of the contract between A and B.
Ellis Cohen is the Principal Architect for User Interface Technology and a member of the Core Architect Team at the Open Software Foundation. He initially came to OSF as a member of the industry review team that selected the technology base for OSF/Motif.
Prior to joining OSF, Ellis developed "rtl", a tiled window manager for X11(tm) at Siemens Research and Technologies Laboratories, where he also was an architect for GYPSY, a CASE project for an object-based architecture.
He has also been a professor, a V.D. counselor, and a restaurateur. Dr. Cohen received a Ph.D. in Computer Science from Carnegie Mellon University in 1976, where he was one of the developers of Hydra, a pioneering object-oriented multiprocessor operating system.
ellis@osf.org