Re: N American Registery, Databases 101

[Glenn Merrell <gmerrel@domain.elided>]

(Richard Welty, are you interested in hosting something like this?
Please give us the benefit of your previous net-legal experiences in
building this type of project)

Hello All,

    While you guys are running around reinventing the wheel, it is time
for some Stag...ering Database 101, not meant to demean this great idea,
one that has been circulating the Stag Digest now for more than a year
or two.  After all, the intent here is commonality, right?  Lets start
with "database", one word.
DATABASE vs SPREADSHEET 101
    A Database is simply a collection of...that is right...data, usually
collected to suit some purpose like, say, listing the names, addresses
and car specific information for Stag owners, to name one use.  A
Spreadsheet is an electronic sheet of paper that allows you to do neat
things with data, like add two data together or average a column of
data, or sort a bunch or data into a neat format.  A spreadsheet can be
a database, but usually uses the information from a database.  A
spreadsheet can be used to put data into a database.  Some spreadsheet
programs allow you to create "forms" to enter data into a database in
the format of "fields and records".  A Database PROGRAM will give you
abilities more suited to inputting and sorting data.
   First let me interject that John Ramerman in Australia has put
together a "database" in connection with his exceptional, and I repeat,
exceptional Stag Global Information System (GIS) Demographic work.  John
has put many an hour getting this idea brought together and tested on a
local server, which is year 2000 ideas brought to reality today.  A good
majority of that work is already done, that being defining the data
fields for each record and getting them placed neatly on the screen with
an interactive graphic HTML format.  The data for my stag and at least
15-25 other US, Aussie, UK and European Stags exists NOW in that
project.  The only things missing are more data representing more Stag
Owners, and a final home for John's great work.
Microsoft and various Database Manipulating Programs
    Second, if you are running Microsoft Windows, just about any
database or spreadsheet program that is written for Windows will read
the common "naitive" formats for Lotus, Excel, Access, Works, Foxpro,
Quattro Pro, even TinyCalc, unless you are still in DOS 3.2 lalaland and
accessing the internet by typing UNIX commands on a text screen (if this
is you, then you have already compiled the database for us and need to
let us use it!!).  The problem is as new versions of these programs come
out, they can not exchange their "native" format with older versions of
other programs, which is why the database needs to be a common format
called a "flat file" described below.
The Size of a Database
    What is also important is the number of characters defined in each
field, the relative positions of each field, the number of fields to
contain data, and the record length (all the data fields combined), of
which define the size of the database (number of characters in a record
times the number of records = total bytes of the database).  If a data
field is not long enough, data will be truncated.  If too long, space in
the record and database is wasted.  Wasted space is not a problem until
you get several hundreds of thousands of records and run out of disk
space...or try to exchange the data with someone else over the Internet
or load it onto a 1.44 meg floppy.  This saving of record space is the
root cause of "Y2K" (year 2000) catastrophes, eliminating the "19" from
the record and having the program written to assume that the last two
digits of the year were always to mean 1900...a defenciency that I
brought up to IBM in 1977 while captive there.
The Transportable Database
A proper transportable database does not have imbedded commands specific
to a particular software manufacturer, and should be a "flat file".  A
flat file is purely a text file with the data separated by a
"delimiter", usually a comma or semicolon.  A flat file is best because
it can be viewed, manipulated, and saved by even the most basic computer
word processors to the most expensive database or spreadsheet program on
any operating system.  This is because the data in a flat file is the
base format of just about every computer, ASCII characters, which is
what the computer translates to put the text on the screen you are now
reading.

Lets jump ahead...

SECURITY and DATA PRIVACY
A proper database of this type will contain information that only the
OWNER of the information wishes placed into the record.  Therefore, it
is desirable that the person supplying the information  BE the OWNER of
the information, and be completetly and properly informed as to HOW the
information is to be used and WHO may access the information for
viewing.  This complies with the intent all of the existing Data Privacy
Laws in the various treaties like GATT, EU legislation, various specific
country laws.  This said, the database then needs to be updated by the
OWNER of the information, accessible, updated and redacted by the OWNER,
or with the OWNERS specific permission.  Is this point CLEAR enough?  If
not, I hope you have a good lawyer.
    This approach gives at least an initial guarantee that the
information is most likely to be supplied by the owner, and frees the
person maintaining the database from some of the basic liabilities and
headaches of maintaining a constantly changing database.  When allowing
input/update/deletions, a simple check is made as to the owners username
and password before allowing any data to be changed.

SUMMARY

I have proven by my interaction with John Ramerman and Thomas Jell that
a "virtual project" can be managed over the internet.  With input and
feedback from as many as two dozen sources, the project was concieved,
developed, debugged, and placed on a server to test run.  It just needs
a server home, and a "Stag Database" with all the features described
above,  is ready to be updated to by the owner of the information.
Provisions for "Stolen Stags", "I Saw a Stag Here", other Triumph
models, Vendors and Service locations, Club locations, event locations,
links to personal pages, "I need this Part" on adnausium have already
been thought of and are ready to be built.  As opposed to generating
"yet another" database, lets look at what has already been accomplished.

The first step may be just assembling the data, but without the OWNERS
express permission and disclosure to them on how the information is to
be used, it will be an uphill battle.  With the ability of the owner to
"logon" to an information screen showing the usage disclosure, allowing
the owner to add/update/delete the information, all bases are covered.

Regards,
Glenn Merrell