SUBSCRIBE NOW!

Vol. 12 No. 1 — January 2004

This installment focuses on Richard (Dick) Giering, who was instrumental in developing, from 1967­1978, the "underlying basic technology" that ultimately enabled Lexis and Nexis. On September 10, 2003, Susanne Bjørner met with Mr. Giering at his summer home in Libertyville, Illinois, for an in-depth interview. Part 1 of Mr. Giering's story follows.

An Interview with Richard Giering

Bjørner: How did you get started in the field? You said you were a high school dropout and went back and got a degree.

Giering: Long before I became involved with full-text work, the Army sent me to college at the University of Arizona. One of my professors was James Perry, who was well versed in librarianship. I believe he came from Western Reserve, and was at the University of Arizona when I was in the systems engineering department, where I got my degree.

Dr. Perry started to inform me about information technology, but not in classroom work. We'd take bottles of water and go out to the desert and sit and talk about edge-punched cards — big, 14-inch-square cards in tubs with the pins that go through. Hard cards, before computer paper cards. People would put a long 14- or 16-inch needle through and pull the cards out, and with those that were left, they'd put the needle through again to narrow the search. That's how they extracted information. The edge-punched cards were the predecessor to index terms. Then Dr. Perry got into card catalogs, Dewey Decimal, and things I had never even heard of.

This was my introduction to information technology.

I had been in the Army. I was old for going to college, in my early 30s. I was absorbing information. I knew information technology was something I needed to know, but I didn't know why. After I got my degree, information technology stayed in the back of my mind, but I had no real use for it when I went back into Army service. It didn't come to the fore until many years later, when I got involved in full-text activities. It wasn't until the late 1970s (15 years after I received my degree) that all those things really jelled.

Defense Intelligence Agency Work

I had been stationed in Europe with my family, and in 1965, I was recalled back to the States and assigned to the Defense Intelligence Agency. My assignment while there was to design and publish (not to implement — the implementation was to take place further out in the field) the Defense Intelligence Ground Order of Battle (DIGOB).

An Order of Battle is a capability — a process, or a system — that attempts to enlighten a military commander — not necessarily a ground commander, but in this particular case it was ground — about his opponent. Not only the opponent commander, but the opponent forces, the opponent equipment, etc. — everything that could possibly be known — so that the military commander can make the best decision about how to employ his forces and do what is necessary to fight the battle. There's a term in ground force operation called "Enemy, Terrain, and Situation." You have to know what the enemy knows and is doing, what the situation is, and what the terrain is. The Defense Intelligence Ground Order of Battle was a system that gave the ground force commanders, top to bottom, the information and intelligence necessary about the enemy.

The parameters presented to me in making this design were that we were to use FFS, the "formatted file system." This was critical. FFS was a highly structured, functional capability. Everything in it had to be codified. I spent a little over a year — this was 1965 and into the beginning of 1966 — designing and getting DIGOB ready for publication, including a 3-inch loose-leaf binder of codes.

Bjørner: Were some of those codes already established and you had to build onto them?

Giering: Yes, but for the most part, if they were ground-oriented codes, they were new. If it was an aircraft, I could build from an air order battle code that was already established, or I could build on a naval force code, but for most of the ground force, such as an artillery piece, the code was new.

I spent a little over a year designing this system, using the formatted file system, writing it all up, and getting it ready for publication.

I guess it was in the middle of 1966 that I presented this package to my superiors. They scanned it and said, "It looks like what you were supposed to do." It was then ready to be proofed and edited, which would take another 2 months. My work was relaxed.

From Formatted Files to Text Processing

Bjørner: Where were you geographically at this time?

Giering: I was at Arlington Hall Station, outside of Washington.

Bjørner: You completed as much as you could....

Giering: It wasn't completed, but my work was less intense. Shortly thereafter, within a couple weeks, one weekend — this is a very significant point — I was at home. While the specific details of what I was doing were classified, the concept — the Defense Intelligence Ground Order of Battle — was not. That's standard practice. So my wife knew what I was doing. A couple weeks after I had presented this to my superiors....

One weekend, in the middle of the night, I woke up and couldn't sleep, so I went to the kitchen and made a pot of coffee. I was sitting at the kitchen table. My wife got up and asked me what was wrong.

I said, "I've just wasted over a year and a half of my time. What I've put together cannot work. It's doomed to fail. The formatted file system cannot work." I had spent a lot of my early military days in combat arms. A tank commander cannot use a 3-inch binder of codes to report what he sees. An infantry squad leader cannot use a 3-inch binder of codes. He's got to report in full text what he sees. Somewhere back in the line, they were going to need a whole new contingent of people to translate what those textual reports contained. By the time they translated them into this formatted file system, the data was going to be so damn old, it wouldn't be useful. It was bound to fail.

What was needed in this process was the ability to use some kind of text processing. I just knew that what was coming from the front lines was text. What the commanders were giving in the way of orders was text. They weren't speaking in codes. They were saying, "Send three battalions on this route, in this manner." They weren't saying "3-X-Y-2-B-28." They weren't sending codes; they were sending text.

Bjørner: You had this realization, but you had also been specifically directed to use the formatted file system....

Giering: I was in the middle of a dilemma. I went back to work and talked to my superiors. They were, to say the least, enamored with this formatted file structure. They had built their careers for 8 years on this system. The Navy and Air Force had a myriad of systems based on it.

Now I was saying, "It's a house of cards." I'm a lowly Army captain in the middle of admirals, navy captains, colonels, and generals. Who's this upstart? The more I talked ...

Bjørner: ...They wanted you to go away. They didn't want you to talk about this.

Giering: Amen. The more they didn't want me to talk, the more I wanted to talk. I'm an obstinate person. I was obstinate because I knew what I had built was doomed to fail.

All this time, I'm getting feedback from the editors about what I had written, so I'm rewriting and editing what I had been told to do. But I'm still fighting for what I knew we had to do. I had to do something, but I didn't know what. I knew that the formatted file would not work. I didn't know what would work.

Some weeks later, I was sitting in the snack bar lamenting to a co-worker about the need for text processing. My standard lament! Not only were my bosses getting perturbed about listening to this, so were my co-workers. Someone at the next table overheard and came over, and said, "I couldn't help but overhear. Tell me what it is you're talking about."

I would talk to anybody! Turns out, he was an intelligence analyst with DIA. I'm in the data processing department. He's in the analytic department. He listened to me and asked, "What's your level of security clearance?" I told him. He said, "I can't talk to you. Who's your boss?" I gave him my boss's name, and he said, "OK. Thank you," and left.

That afternoon, I got a telephone call, not from my boss but from my boss's boss. He asked, "Did you talk with so-and-so this morning?" I said, "Yes." My boss asked, "What did you tell him?" "I told him my standard story about needing full-text processing."

It turns out that they had a need. My boss couldn't tell me what it was. My boss's boss said, "OK, they said they have a need. You think there's a requirement. If you can find something, go ahead and find it."

The Discovery of BIDAP

Giering: Now I had a mission, a "go-ahead." I didn't have much else to do because the work I had been doing was off being edited. I picked up the telephone and started making some calls. I don't remember whether the organizations I called were NTIS (National Technical Information Service) or DDC (Defense Documentation Center), but it was those types of organizations. I started getting catalogs of abstracts. I ran across something called BIDAP: Bibliographic Data Processor.

I read this abstract. It sounded like something that could solve the problem of processing text. I was still thinking text in a combat arms environment. The abstract identified a principal investigator from Northwestern University and indicated this was an old research project that was dead and buried. I picked up the phone and called this man at Northwestern University; he confirmed that the research was long since gone. I started questioning him about what the abstract said, and he sent me a big write-up, maybe eight or 10 pages, including some FORTRAN program listings. It came in the mail about 4-5 days later.

This looked just like what I was looking for — a FORTRAN subroutine that would take individual words, ANDed and ORed together. The words were used to scan text, and they would extract from the string of text material based upon the existence of those words in the text. It would take a string of 1,000 messages, and if these words appeared, only those messages would be extracted. I called the Northwestern man back and asked where I could get a copy. I felt that if I could convince my superiors, I could reorient the Ground Order of Battle process outside of the formatted file system...to augment the formatted file system. This was a way we could really make headway.

This fellow at Northwestern gave me the name of the warehouse at Wright-Patterson Air Force Base where the FORTRAN project program was archived. I wrote up the equivalent of a purchase order and took it to my boss, who didn't want anything to do with it. It bucked up to my boss's boss — it went about four levels up. By this time, the analyst at the snack bar had been coming back asking where we were.

They signed the purchase order to get this analyst off their back, and I sent it off to Wright-Pat. About a week or so later, I got a magnetic tape that was a copy of the whole project. And my gosh, it did exactly what the project said it would! But how was I going to prove it?

I called the analyst who had the text problem. He made some arrangements for me to get a temporary clearance. There was an organization in Washington called the National Photo Intelligence Center (NPIC). NPIC was staffed by a group of photo analysts. They would sit with photographic images from various sources, most of which were from satellites. With stereoscopic things and with microphones, they would dictate what they saw on these images. Every image represented a document that they would dictate. Literally thousands of images a day. The documents were transcribed onto 12-inch computer tapes, which were then duplicated and sent out to the individual intelligence agencies: DIA, CIA, NSA, etc. All text. Document after document after document of nothing but text. The agencies printed them and sent copies to the intelligence analysts. A stack of 18-20 inches of paper a day! Analysts would get the printouts on their desk and be expected to extract and understand what was in there — day after day after day. They were inundated. The data they needed to do their job was there, but there was no way to get it out. This is what the analyst who heard me talking about text was thinking of.

We made a test. Because it was satellite imagery, I was not cleared for it, but my clearance was enough for the ground analyst to tell me the words he was looking for on the imagery. He and I sat down, and he said that he was looking for this OR this AND this OR this AND this, but NOT this. He and I worked out the word-oriented logic. I wrote the word-oriented logic in the structure of this program called BIDAP. We set up a run during the middle of the night. I sat outside the computer room because I wasn't cleared to go in. We had a cup of coffee. When it was over, I sat outside while he went in to look. Instead of 18 or 20 inches of printout, there were 18 sheets. He said, "This is great!"

I went home to bed. When I came to work the next day, I had eight messages on my desk from my boss and my boss's boss and from a number of intelligence analysts who wanted in on the project. This was BIDAP. It was late 1966, and we went into early 1967. They immediately increased my security clearance so I could become more involved. We took a copy to CIA and NSA and they started using it. I had to train some of their data processing people. It was used by other intelligence agencies.

But, that's only part of the story.

Data Corporation and Recon Central

Giering: About that same time, one of the Air Force analysts who was working with BIDAP mentioned that he was aware of something similar with full-text technology going on at Wright-Patterson Air Force Base. He said maybe I should take a look at it. I was enthused. My boss was letting me run and staying out of my way. My Ground Order of Battle system was fully edited and ready for press. They were happy that it was a formatted file system. They were going to let it out the door the way it was. "Don't mess up a good thing." I was happy.

The Air Force analyst told me about Recon Central. I did some additional research and found that there was something called Recon Central and they were doing some full-text work. I got hold of the Recon Central contractor, called Data Corporation. That's how I got involved. It was now 1967.

Bjørner: Was Data Corporation at Wright-Patterson?

Giering: At that time, Data Corporation was in Dayton, Ohio. My memory says that Recon Central was not a direct result of BIDAP. What I was doing at BIDAP at DIA was a separate function. Whether BIDAP at Wright-Patterson — separately, initially, earlier — had influenced Recon Central, I don't know. It may have, but I'm not aware of that. My work with BIDAP had nothing to do with Recon Central. My work with BIDAP only led me to find Recon Central.

Recon Central was a classified operation in a vault in the basement of a building in the Reconnaissance Laboratory at Wright-Patterson AFB in Dayton, Ohio. Recon Central and NASA Recon were two different things. NASA Recon, as I understand it, was a forerunner to Dialog; it had nothing to do with Recon Central. Recon Central is associated with the Reconnaissance Laboratory at Wright-Patterson Air Force Base.

A feasibility study was completed early on, probably around 1963, long before I was involved, that dealt with the need within the reconnaissance community for handling management information. In the mid-1960s, MIS was the "buzzword." There was a lot of work going on toward the need for management information systems. Everybody was moving toward MIS. The feasibility work/study had to do with the question of whether highly structured data using formatted file systems, DBMS, etc., was the only way to go, or whether there was another way to handle text. The theory was that, yes, we could do it. A contract was let about 1965 by the Reconnaissance Laboratory with a think tank called Data Corporation. At that time Data Corporation was heavily involved with various reconnaissance activities, not necessarily computers — target acquisition, cameras, various types of hardware. It wasn't until later that they got heavily involved with computers. But they got a contract to do some feasibility work on the use of text in management information.

Are you familiar with DD Form 1498? Department of Defense Form 1498 is a project resume. It includes fixed field information at the top, like the dates, the project numbers, the project titles, who it is, where it is, why it's being done. Then there are some fields of text, like the objectives, the status, etc. These text fields go on and on for pages and pages of information. This is one of the key files of documents/material that was being considered for the management information process. This is what led to Recon Central, in 1965 and into 1966. They decided, "By God, it will work. Yes, you can extract words, not only from those big fields of text, but also from the name of the project manager, from the title, and even from the project number."

Lots of things started falling into place. Recon Central became a test bed. If it could do that with DD Form 1498, why couldn't it do that with other things?

Now there was a new requirement. Photographic equipment has some unique requirements: units of measure, film size, focal length of lenses, sizes of lenses. If you are going to put cameras into an aircraft, you need to know the size of the camera, you need to know the focal length of the depth of field, and all kinds of arithmetic information, in addition to the engineer's specifications that come out in text. You have a lot of structured information — like a lens size between 3 mm and 6 mm. That sounds like management information, doesn't it? Now they were back to the feasibility study that had been talked about a number of years earlier.

I got involved in 1967; Recon Central was still in the feasibility breadboard. There was a computer in a basement vault of a building at Wright-Pat with a lot of classified information. Cameras, classified; target acquisition information, classified; project information, classified. Some of it was unclassified, but a lot was classified. If an engineer wanted some information, he went to the counter manned by "Pappy" (Al Fleury). Pappy would take the requirement, run downstairs, and sit at the console typewriter — it wasn't really online — and he'd type in the requirement, AND and OR, not very much Boolean, but AND and OR. If there was a lot of material, he'd print it out on a printer, rip it off, run back upstairs, and hand it to the engineer.

But it was running! From their standpoint, it was a production operation. I can't emphasize that too much. But if you stood outside their box, it was nothing more than a breadboard ["a blank, perforated board used to support prototype electronic circuits"]. A breadboard that proved the feasibility of text processing in an MIS environment, but it was one of a kind. You couldn't use it for anything other than what it was doing. From their standpoint, it was a production operation. Outside of their box, it was a beautiful breadboard, still experimental, but working.

Comparing Data Central with CIRC

Giering: Data Corporation was the contractor. They had written the software, and their unclassified version of the software was called Data Central. I was at DIA, working with the Data Corporation salesman at the Washington sales hub. I learned there was something else at Wright-Patterson, called CIRC [Carlos Cuadra mentioned it in one of the previous installments in this series — SDC was involved], and the online version, CIRCOL. CIRC was not full text; CIRC was bibliographic. I've used that term before; let me make sure I define it so there's no misunderstanding. As I use the term bibliographic access, I'm referring to the search access use of manually assigned index terms. Extracts and abstracts may be present and displayable for retrieval purposes, but search access to the record is by manually assigned index terms. There may be controlled thesauri, there may be uncontrolled terms, etc., but they are manually assigned. There is an intermediary person who stands between the author of the material and the person asking the question. That is my definition of bibliographic. That's how I've been using the term. CIRC and CIRCOL were at that point bibliographic.

There was a project — and I would like to think I was instrumental in getting the project moving — to compare Data Central, which was the nonclassified version of Recon Central, with CIRC and CIRCOL at DIA. We had two terminals set up to operate online, both of them to Dayton: one to the CIRC people and one to Data Central. I think the comparison went very well. But the project report never surfaced. The report died. Data Central and CIRC both did what they were supposed to do. One was full text; one was index terms. The report never surfaced.

I was about ready to retire from the military. I had spent my 20 years. My use of BIDAP had proven its worth to DIA and the other intelligence places, and I found Recon Central. At that point I found a mentor.

Data Corporation and Bill Gorog

Giering: I'd like to go on record about a man, Bill Gorog. He was the chairman of Data Corporation. He believed in the technology. Long before I was hired by Data Corp., Bill Gorog saw the advantage to moving the concept of Data Central into MIS — he understood. It was his foresight, his forbearance, his drive, his belief in the future of full-text capabilities, that was the driving force! Without him, without his sales force, without his push, I wouldn't be here. He went out at one point and literally sold debentures and put Data Corp. into hock to get money, when the Air Force money dried up. It was his salesmanship, his drive, it was him.... Without Bill Gorog, Lexis wouldn't be here.

Bjørner: How old was Gorog around this time?

Giering: He was a graduate of West Point; my guess is that he graduated about 1947. He would have been about 24-25 when he graduated, so he was in his late 40s or 50s when I met him. He's the one who went out and brought in OBAR. He's the one who got the money. He's the one who brought in the Arthur D. Little people. He's the one who convinced the Recon Central people. When you look at it, his name is every place. Without him, none of it would have happened. Bill Gorog really is "the man."

Bjørner: It's because he had the vision? He recognized the value of technology and found the business means to finance it?

Giering: He was the businessman. He understood the business, he understood the need, and he recognized what I could contribute. In many ways, he mentored me. He knew I was getting ready to leave the military, and he offered me a job. When the Air Force money dried up, he turned around and challenged me to make this Data Central thing into a commercial product. That's where I became a "father." This breadboard was sitting in the vault. Since a government contract had generated the software, it was in the public domain. Anybody could get a copy of it. In fact, when the government money dried up, a copy of the software was sent to DDC or NTIS, or whatever it was called then; anyone could have gotten a copy. Data Corporation, of course, had a copy because we were the contractor. I got the job of taking this breadboard and moving it into a commercial product.

I retired from the Army in late 1967. Remember Pappy? One of the things he could do was, if the material were unclassified, he could run down and turn the switch on the machine. The IBM 1050 typewriter terminal upstairs could emulate the console typewriter. The console typewriter was just an emulation; it was still not online. We had this unit, this set of programs (I won't call it a system). When I left the Army, I had several dinners with Bill Gorog, and we commiserated about what to do with this product. At first, we thought the Air Force would fund it into a full-blown MIS. Then of course, it didn't happen.

Bjørner: Did you come out to Dayton when you got out of the service?

Giering: Not initially. I came out on a visit to interview, but I stayed in Arlington. We didn't actually move to Dayton until December 1969.

Immediately after the funding dried up, it was up to Data Corporation to pick up the pieces and start moving. They could have let it drop, but here is the drive, the foresight, that Bill Gorog had. He came to Washington and we had dinner; he dropped the funding bombshell. He said, "Do you still believe in it?" I said, "Absolutely, this is the wave of the future." He asked, "What do we have to do to make this thing a product?"

I'd been thinking about all this for quite some time, so I had some answers. "The very first thing is that we have to have a teleprocessor front end so we can have multiple terminals. We can't operate with a console typewriter. No way."

Remember, there was no Internet. This is 1967! We could use modems. First step: We had to have a multiple terminal capability. We had to have better Boolean capability, better front end. ... I started listing things. But the first priority was multiple terminal capability.

I'll never forget. He said, "You just named your own poison."

Bjørner: He knew it was going to be a tough job.

Giering: He said, "What is it going to take to do it?" I said, "I need some help. I need some training. The programs are not reiterative. They are not capable of supporting multiple terminals themselves. We need to roll them in and out and do some technical gyrations. In addition, we need the teleprocessing access that IBM has available." These was the early days of disk operating systems. Disk support was minimal, to say the least. "We're going to have to write our own teleprocessing." Bill Gorog was technical enough to understand the things that I said we were going to have to do.

I said, "We need a lot of support from IBM and a lot of support from our technical people in Dayton, where our computer is. I'll do the coding here, but when I come to Dayton, I'll have to have lots of keypunch help to get the stuff coded, lots of computer time, and lots of other programmers to work with me to make sure that everything is running. I'm going to need a hell of a lot of support. It's going to take not only my work but much support from Dayton. That can't happen without you telling them to give it to me."

Bjørner: You knew what it would take.

Giering: I didn't know exactly, but I had an idea. I'd been in the business long enough to have an idea of the scope. It was not a small task. Bill Gorog said, "OK, how long is it going to take?" I said, "I don't know. A lot depends on how fast I can get the training. When I start getting training, I can give you some progress reports and give you an idea."

Things progressed. I got some training in Arlington and then went to Dayton. Some very good people at IBM gave me a lot of support. A lot of information. I came back home and spent days coding. Went to Dayton and they started keypunching. Spent lots of nights and weekends. In the spring of '68, we started debugging. We were running multiple terminals ... multiple 1050 terminals and 2741 terminals.

Full Text Goes Commercial

Giering: About that time, something else occurred. Bob Landau contacted us and suggested that we consider implementing a CRT as part of this work. So we did. We implemented a hardcopy terminal and a teletype, so we had four types of terminals: the 1050, the teletype, the 2741, and the CRT. In the spring of 1968, we were running multiple terminals.

Relatively speaking, we were fully debugged. Almost debugged. Fully enough that we thought we could tell Bill Gorog. We made arrangements to have Bill come down to the computer center. A bunch of people were sitting at terminals. We didn't tell him what was going to happen; we just told him we wanted to show him something. He stood there and I said, "Are you ready, Bill?" "OK, start up." They all started typing.

He said, "What's going on? They're all searching? All at the same time? We're running multiple terminals? We got TP? We've got a prototype!" I said, "No Bill, we don't have a prototype yet." He said, "We've got a prototype." I said, "Yes, sir. You're the boss."

That was late spring 1968. We started work on additional capabilities. We considered parenthetical notation — the ability for a searcher to use parentheses to group concepts. We concluded that the people who were going to be using this — we're not talking about experts, we're looking to the end user — would not understand parenthetical notation. So we added a third level AND, an ampersand that was subordinate to an OR. And we added something called Modify. We called it recursive search. The searcher could say, "Oh, that's too many, modify it," so he could say, "AND such and such" to reduce the volume of answers, rather than forcing him to pre-think into a parenthetical phraseology.

[There was] another thing we did and I'm not sure when. Recon Central had a very limited sort. You could take the set of material retrieved and sort it by date or by person. But you could only sort by one key at a time. You couldn't sort ascending, descending. You couldn't sort by multiple keys. We added multiple sort functionality.

There were additional capabilities for taking data from various sources, which we didn't have before. Recon Central was very limited. If you had new data, you had to essentially reprogram the whole front end. So we rewrote the front end to make hooks so you could add subroutines, so you could bring in data from multiple sources without having to reprogram the whole thing. We did the same thing on the output side, so that people could generate formats of reports without having to reprogram the whole back end.

We also went to work on what I call the back office. The whole update process — I'll call it a kludge and I'm being very nice. If an update process would run through six times before it was successful, we were lucky. It was that flaky. It wasn't a production model.

That even went into the Lexis days. The back office work continued for years because, like everything else, what's up front gets attention. After we did the multiple terminal capability, we started technical advances — distance searching, A.K.A. proximity searching, that Roger Summit mentioned. Once Data Central went into full text, Lockheed felt they had to put in proximity searching because we had it. That was one of the finest compliments I've gotten in many years.

Bjørner: At an ASIS meeting in 1997, Trudy Ballard Hahn gave Data Central credit for proximity operations and word phrases in 1969...

Giering: 1968, really.

Bjørner: ...numeric and date ranging in 1967, and highlighting words in retrieved records that matched the search terms in 1970. She gives that to Data Central, too.

Giering: What we call Keyword in Context became Keyword in Color. I'll get to that later.

OBAR, Predecessor to Lexis

Giering: Coming back to 1968, two things happened after we added multiple terminals and as we were proceeding with additional technical advances. About that time, the situation started up that culminated toward OBAR. Also at that time, October 1968, we demonstrated the first commercial full-text system at the ASIS convention in Columbus, Ohio. As far as we know, this was the first demonstration of a commercial full-text system. We had a bunch of material, from things like Recon Central, personnel files, legal material. We had quite a number of terminals running, all with modems, from Columbus back to Dayton. All full text. We had staff there to run the terminals, but we also wanted people off the floor to come and sit and run the terminals. We believed it to be a success.

Let's go back and talk about the lead-in to OBAR, which happened before. Earlier that year, at the University of Pittsburgh, Professor John Horty had developed or implemented a capability for some type of legal research. If a lawyer wanted research done, he would call Horty's lawyers, who would do the research. Whether they used the West key number system or another type of system, Professor Horty's lawyers would act as intermediaries between the people who wanted the information and the information itself.

In 1968, this was supposedly the state of the art in legal research. The Ohio Bar Association heard about it and sent James Preston and Bill Harrington, both lawyers — I believe Jim Preston was president of the Ohio Bar Association then — to John Horty to look into what he was doing. They also looked into some organization in New York that was doing something similar. The Ohio Bar Association was about ready to sign a contract with one or both of these organizations. This information became the subject of an article in The Wall Street Journal, which Bill Gorog saw.

Being the salesman he was, Bill decided, "Hey! I'm in Dayton, Ohio. That's right up the road from Columbus. I'll call Bill Harrington and Preston and see what I can find out." He called and invited them to our Dayton facility to take a look at Data Central. We demonstrated general full-text retrieval capabilities. We had no legal material; we just had personnel records, 1498s, camera material, etc. Harrington and Preston were obviously and duly impressed. I guess they came back three or four times.

The upshot was that they cancelled their negotiation with the other two organizations and formed OBAR — the Ohio Bar Automated Research, which was a wholly owned subsidiary of the Ohio Bar Association. They formed a separate corporation. As I understand it, they sold bonds or debentures because they decided that they were going to pay for or otherwise generate the data. They were going to own the data. They owned rights to all of the data of the Ohio legal material. It was their intent to never give up the rights to data.

So they gave us content. It's significant, I might add, that if you search parts of Lexis today — the Ohio Supreme Court portion of Lexis, for example — you will find some cases that are all uppercase. Those are the early cases that were originally keypunched in 1968 as the original OBAR experiment. As far as I know, they have never been re-keyed.

Bjørner: In 1968, we only had uppercase.

Giering: That's right. OBAR paid for keypunching services and put a sample of the Ohio Bar-owned Supreme Court data up on the Data Central system for experimental purposes. It was that sample material that was available at the ASIS convention in October 1968, if my memory serves me correctly. That is how legal material came into Data Central.

The Business Models

Giering: There were now three data centers running. Data Corporation had one in Dayton, and we had Recon Central in the basement. As part of the deal, we organized and set up a Washington service center in Arlington, Virginia. By this time — I don't remember exactly when — I had been promoted to the director of the Information Systems Division in Data Corporation. Peter Vann was head of sales and became the co-director of the Information Systems Division. I was the technical director, with three service centers that I was charged with running. It was quite a time. I would leave home on Sunday evening (we were living in Springfield, Virginia), fly to Dayton, spend 3 or 4 days in Dayton, come back and spend a couple days in Washington, spend a weekend at home, and fly back to Dayton. During those formative years, my wife raised our children. Even when we moved to Dayton, I was doing a lot of traveling.

We had three service centers and quite a number of government contracts — epilepsy research, the American Psychological Association for Psych Abstracts, ERIC, and HEW for an inventory of audiovisual material...

Bjørner: Is that what became NICEM?

Giering: Yes, we started that. EARS was epilepsy, and we started what was called at that time BEER (Biological Effects of Electromagnetic Radiation), somewhere in one of the National Institutes of Health; for EPA, we did some work on Environ...

Bjørner: Which became Environing, I believe.

Giering: ...among a lot of other things. Our Dayton service center had a lot of contracts, some government, some commercial. We had an installation. ... When Bill Gorog saw that we had a prototype, he said, "We have to go out and sell one." He went to Oak Ridge and wasn't very successful, so he went to Union Carbide, which was a contractor at Oak Ridge; they bought one and we installed it at Union Carbide in Charleston, West Virginia. They were using it for their inventory of chemical compounds.

This was around 1967, '68, '69. Now we had four installations. We didn't have to do much support. They were running it and not complaining. We'd get a phone call every once in awhile asking, "What does this mean?" We'd answer, and they would say, "Oh, thanks!" and hang up. Union Carbide was an installation. This was all part of our business.

We will get further into the discussion of the differentiation between the types of businesses in 1971 that caused a split. ... We really had three different businesses that we were involved in: selling of data, installations (Union Carbide and Recon Central), and data services (service centers). We were already into those three businesses.

Bjørner: Did you see them at that point as being three separate businesses?

Giering: I did. But like a lot of other things, I was still pretty naive in business. In the same way that I was not able to convince my compatriots at DIA about full text, I was not very capable at convincing business compatriots about business activities. In 1963, '64, '65, '66, and '67, Bill Gorog understood about MIS and I understood about MIS, but I couldn't convince anyone else about MIS. In October '67, one of the first things I did after I retired from the service, when I was at Data Corporation, was write a document that compared data handling systems, which included various things that purported to go toward MIS. There's a list of them. These were not library systems; these were systems directed toward management information systems. I didn't include Dialog, Library of Congress MARC, and those kinds of systems.

Bjørner: In this list, for Data Central, you use Data in parentheses.

Giering: That's the way we were thinking about registering the name: (Data) Central.

Data Corporation was a research company. One of the things research companies do is they publish. That hurt, because in 1971, when we were at Mead Data Central, we wanted to patent the inverted file structure. We couldn't, because in late 1967, I had written a technical note in which I had defined the inverted file structure. Because Data Corporation was a research company, we published and "threw it out the window." The patent attorneys said "public domain." So it hurt, but that's the way the cookie crumbles.

In the next installment of this series, Mr. Giering tells about the "invasion" of Data Corporation by Mead Corporation; how legal and newspaper divisions were formed as separate businesses; how the first color terminals were demonstrated and rejected by online users; how the Boston Globe became the first electronic newspaper database; and why he left Mead Data Central at the dawn of Nexis. . . .

 

Who's Who: Key People Gorog, William — Executive Vice President, Data Corporation, 1956-1963. Chairman, Chief Executive Officer, Data Corporation, 1963-1975. Vice President, Mead Corporation, 1972-1975. Advisor to Gerald Ford, 1975-1976. Died in 2002. Harrington, William — Research counsel to James Preston at the time OBAR was developed. Horty, John Francis — Director, University of Pittsburgh Health Law Center; Adjunct Professor, University of Pittsburgh School of Law, 1956-1968. Founder and President, Aspen Systems Corporation, 1968-1971. In 1959, using punch cards, started a project to computerize Pennsylvania health law statutes. Landau, Robert M. — Directed the COSATI Information Science and Technology Inventory, mid-1960s. Perry, James Whitney — With Allen Kent, founded and co-directed the Center for Documentation Communication Research at Case Western Reserve University, 1955­1960; Was also a Professor, Systems Engineering, University of Arizona; and Professor, Modern Language Department, MIT. Considered a major influence in automatic indexing and information retrieval systems using punched card machines. Editor, with Allen Kent, of Punched Cards: Their Applications to Science and Industry, 1958. Died in 1971. Preston, James — Ohio State Bar Association President, 1965. With William Harrington, developed OBAR. What's What: Names, Acronyms, and Abbreviations ASIS — American Society for Information Science. Founded in 1937 as the American Documentation Institute (ADI). Name changed to ASIS in 1968 and to the American Society for Information Science and Technology (ASIST) in 2000. BIDAP — Bibliographic Data Processor. Computer programs developed at Northwestern University and used by Wright-Patterson Air Force Base and the Defense Intelligence Agency to produce KWIC indexes. Boolean — Query system devised by George Boole that combines words with logical operators, the most common being AND, OR, and NOT. CIRC — Centralized Information Reference and Control System, a document-handling system implemented by System Development Corporation in 1965. CIRCOL — CIRC-On-Line. COSATI — Committee on Scientific and Technical Information. Formed in 1963 by the Office of Science and Technology. Sponsor of a 1968 demonstration to the U.S. government of interactive data-handling systems. Eliminated in 1972. DBMS — Database Management System. Software programs that manage large structured sets of data. FFS — Formatted File System. Data storage system, developed by IBM, that stored its own format along with the data. FORTRAN — FORmula TRANslation (originally called IBM Mathematical Formula Translation System). Developed by a team of IBM programmers in 1954. Considered the first programming language used for numerical and scientific applications. KWIC — Keyword-in-Context. Method that displays the occurrences of search terms within the context of the documents retrieved. NICEM — National Information Center for Educational Media. Database originally developed by the University of Southern California using punch cards. In 1984, the database was purchased by Access Innovations and now includes over 640,000 curriculum materials and non-print media. NSA — National Security Agency. U.S. cryptologic organization, established in 1952. NTIS — National Technical Information Service. Part of the U.S. Department of Commerce, Technology Administration. Database developed more than 50 years ago as a centralized resource for government-funded scientific, technical, engineering, and business-related information. Currently maintains over 3 million titles. OBAR — Ohio Bar Automated Research. Database of Ohio statutes and case law, developed by the Ohio State Bar Association in 1965. Proximity Searching — The ability to specify how close multiple search terms should be to each other within a text document. Punch Cards — Early storage medium made of thin cardboard holding data as patterns of punched holes. Herman Hollerith invented the first electric tabulating machine to read, count, and sort punch cards, which was used to compile the 1890 census. In 1896, Hollerith founded the Tabulating Machine Company, later renamed the Computer Tabulating Recording Company, which became IBM. FURTHER READING American Society for Information Science & Technology (ASIST), "James Whitney Perry," http://www.asis.org/Features/Pioneers/perry.htm. Bourne, Charles P. and Trudi Bellardo Hahn, "Computer Searching for the Legal Profession: Data Corporation, OBAR, Mead Data Central, 1964-1972," in A History of Online Information Services, 1963-1976, Cambridge, MA: The MIT Press, 2003, pages 229-257. Halvorson, T. R. and Margi Heinen, "Casemaker: Ohio Incubates Another Legal Information Service," Law Library Resource Xchange, http://www.llrx.com/features/casemaker.htm. "History of IBM," http://www-1.ibm.com/ibm/history/history/history_intro.html. Kadec, Sarah T., "Chronology/Bibliography of Events Relative to NTIS' Position in Commerce," January 26, 2000, http://www.nclis.gov/govt/ntis/kadec.html. Jones, Douglas W., "Punched Cards: A Brief Illustrated Technical History," http://www.cs.uiowa.edu/~jones/cards/history.html. "Last Writes? Reassessing the Law Review in the Age of Cyberspace: Spotlight on...John Horty," http://www.law.pitt.edu/hibbitts/horspot.htm. "LexisNexis: Celebrating Innovation, 1973­2003," http://www.lexisnexis.com/anniversary/. McCabe, Diana Fitch, "Automated Legal Research," Law and Computer Technology, vol. 4, no. 2, March-April 1971, pp. 30-37. National Information Center for Educational Media, "History of the NICEM Database," http://www.nicem.com/history.htm. Poynder, Richard, "LEXIS-NEXIS: Past and Future," Online & CD-ROM Review, vol. 22, no. 2, April 1998, pp. 73-80.

Susanne Bjørner is an independent consultant to publishers, authors, and librarians and writes about the information professions and industry. Contact her at bjørner@earthlink.net.