Online Before the Internet, Part 5:
Early Pioneers Tell Their Stories: Richard Giering
by Susanne Bjørner • Bjørner &
& Stephanie C. Ardito • Ardito Information &
Previous installments in this series featured interviews
with Roger Summit and Carlos Cuadra, the founders of Dialog
and Orbit. Both of these online services first appeared
on the market as bibliographic retrieval systems, later
adding abstracts, full text, and linking capabilities.
In contrast, the service known today as LexisNexis began
as a full-text retrieval system, offered by Mead Data
This installment focuses on Richard (Dick) Giering,
who was instrumental in developing, from 19671978,
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
An Interview with
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
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
Giering: I was at Arlington Hall Station, outside
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
Bjørner: You had this realization, but you
had also been specifically directed to use the formatted
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
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
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
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
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
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
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
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
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
Bjørner: He knew it was going to be a tough
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
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
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
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
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
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
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
Perry, James Whitney With Allen
Kent, founded and co-directed the Center for Documentation
Communication Research at Case Western Reserve
University, 19551960; 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,
What's What: Names, Acronyms,
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
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
Boolean Query system devised by
George Boole that combines words with logical
operators, the most common being AND, OR, and
CIRC Centralized Information
Reference and Control System, a
document-handling system implemented by System
Development Corporation in 1965.
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.
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
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
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,
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,"
"LexisNexis: Celebrating Innovation, 19732003,"
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
Stephanie C. Ardito is the Principal of Ardito
Information & Research, Inc., a full-service information
firm based in Wilmington, Delaware. Her e-mail address