#Your ROCKDB data
25 messages in this thread
Hi Doug—
Yes, starting a formula with PO4 *did* come from a phosphate-oriented book. (As
usual, I'm late answering, and have lost the train of thought. Any day now
(actually, next week…) I'll be more free with my time.) Starting a formula
with PO4 is totally alien to me as a chemist. The anion goes last! ARGH! But
whatever…….
I looked through my books for a quickie refresher on IUPAC silicate standards.
No joy, I must have left them behind. I once considered joining IUPAC, but
they're really expensive, so I never did. Perhaps if one of us asked in the
chemistry section, we might get enlightened. I'll post the question later.
IUPAC tends towards the REAL name of things. No holds barred, length isn't a
requirement. And none of this "butyl" stuff, it's 1,1,1 trimethyl methane.
(IUPAC is a formal convention for naming things. You don't want to hear about
proteins! (G)) IUPAC isn't intended to dispel confusion, and they don't.
What I had in mind for the upcoming CO was a discussion about mineral database
specs. Like, conventions for naming things. Or their colors, etc…. I of
course personally think we should stick with the ones we're already using. But
whatever it takes, we need more minerals in the database. I dunno, *I'm*
willing to edit data to fit our requirements. And maybe I have extra time. I
think a mass effort, like the Stoneware people who did FRACTINT, might get us a
really nice result. At the moment, I'd be willing to spearhead such a
group…… It would be nice if we could do it as shareware, but that's of
course open to discussion…..JD
Hi, Jerry–
Whoof! No "butyl" or "butane"? That 1,1,1 trimethyl methane looks like
iso-butane to me (not 1,2,3 trimethyl methane?). What do they do with straight
butane? 1 methyl 1 methyl 1 methyl methane? If so, I refuse to contemplate
proteins, and fear I may have been rash in asking about silicates. I was more
just wondering if they recognized "nesosilicate", "tectosilicate" and other
such Dana group names. I have heard other names, like "orthosilicate" seems to
be the same as "nesosilicate", but some are not apparent from context; I am
still wondering what was meant by "subsilicate" in one article.
A discussion of the database project (standards and who will do what) might
best wait until we see what Lanny has – that may be close enough to make us
want to move on to the next project.
The earlier discussion on the difficulties of copyrighting a database may bode
ill for shareware mineral properties lists.
–Doug
Doug and all–
After reading my name in the same context as "database" twice in this group of
messages, perhaps I should respond.
With my excietment renewed after joining this forum, I have gone through it
again over the last couple of weeks and done some editing and correcting.
Actually it is in pretty good shape now, but I still need to go through the
last five years of Am. Min. for updates and new minerals. Presently, there are
nearly 3,300 recognized minerals. The database is currently maintained as a
simple database (in ClarisWorks on a Mac) and as a text file is nearly 1 meg in
length.
My thoughts are that this is a bit large for efficient retrieval from the
library (even compacted), thus it may be better to distribute it on a disk. All
the databases I have used in the last few years easily export and retrieve text
files for database in a format where each field is separated by a tab and
records by a return. ClarisWorks can also export in SYLK, dBase (I believer)
and a couple others.
Comments please on what may be most useful.
Doug, I sent you a couple sample records a week or two ago, what did you think
of the content, what data is missing that should be there (optical?)?
Copyright–a difficult subject, lawyers have loads of fun with this. Basically,
a copyright actually covers the form and manner something is in, not its actual
content. Mineral data is not compyrighted, but one can't just copy the data and
format of Encyclopedia of Minerals, but technically one could take all the data
from there. With something like this database, there is a problem–there aren't
many ways (format) that one can list name-formula-system-hardness-etc. If you
look at the three main "lists"–Encyclopedia of Minerals, Mineral Reference
Manyal and Glossary of Mineral Species, they are the same with basically the
same format (different amounts of data), and they all got their data from the
same sources–Am. Min., Min. Mag., Can. Min. etc.
So, what is truly copyrightable in a list/database of mineral data? It would be
difficult for any one of the above three to pursue a case of copyright when
they did not create the data, only copied it from the same sources available to
us all.
Another idea–I recently decided to add to my data (perhaps design a relational
database) crystal drawings, perhaps some from Goldschmidt, and some created in
Shape.
Lanny
Hi, Lanny–
Compressing a 1 meg text database might bring it down to 500K;
abbreviations as noted later may knock it down a bit further.
Considering how interested some of us are, this seems reasonable in a
library upload. At 2400 bps it would take under half an hour to
download (or upload), costing $2.40 or less connect time (standard
plan). At higher speeds, so much the better. Because of the size,
perhaps ZIP archiving would be better; it is smaller and almost as
widely usable as ARC format (I just reviewed COMPRS.DOC and found the
old 8-bit computers (Apple II, TRS-80, Pet, etc.) machines are the
only ones without software available to handle ZIP format).
As a diskette, it could be offered to rocks-and-fossils subscribers
and off-line people. How about both diskette and upload?
To allow others to follow along, the sample entries you sent follow: Mineral
Abhurite Formula Sn3(OH)2Cl2 System Trigonal Group Color Colorless Opacity
Transparent Luster Opalescent Streak White Hardness 2 SG 4.29
Cleavage None; fracture hackly Habit Platy, hexagonal; twinned
Info/Occurrence On tin ingots from shipwreck in Red Sea.
Mineral Acanthite Formula Ag2S System Monoclinic Group Color Iron-black
Opacity Opaque Luster Metallic Streak Hardness 2-2.5 SG 7.22
Cleavage Fracture uneven, sectile Habit Crystals short to long
prismatic Info/Occurrence Dimorphous with aragonite (stable only above 173 deg.
C). Found in zones of secondary enrichment and low-temperature sulfide vens.
The basic info most desirable for amateurs all seems to be here. More, like
indexes of refraction, fluorescence (I have the Henkel Glossary in electronic
form; perhaps this enterprise would help induce the FMS to grant permission to
release that info), and whatnot would be welcome, but not necessary to do a lot
of good. I would like to see you release it sooner and add such extras later.
System: abbreviation would help limit the size of the text form here. I
limited my options to one of these in my database: Iso (isometric=cubic), Hex
(hexagonal), Rho (rhombohedral=trigonal), Tet (tetragonal), Ort (orthorhombic),
Mon (monoclinic), Tri (triclinic), Non (amorphous).
Color: again abbreviations would help. I used only three letters and limited
the number of colors: Whi(te), Bla(ck), Gra(y), Gre(en), Blu(e), Vio(let), Red,
Ora(nge), Bro(wn), and Yel(low) – blanks separate alternative colors – no blank
between means a combination color – 'dark' is rendered as 'Bla', 'pale' or
'colorless' is rendered as 'Whi', etc. Thus pink is "WhiRed", purple is
"RedVio" – limiting to the necessary number of possibilities aids searches,
though I added Bro(wn) as many would not recognize "BlaOra" as the same thing.
All colors can be expressed using this list.
Note that a limited set of choices allows searches with more power and
confidence; it allows me for example if I have a pink rock to search for
entries (records) containing both Whi and Red without having to worry if I will
miss database entries with a color of "Salmon" or "Pale Red" or some such.
Also, the fewer the choices, the more the data can be compacted via tactics to
be employed in the future.
Luster: some abbreviations could be worked out here, though I have not thought
about this one since it is not in my database. "Met"allic, "Sub"metallic,
"Pea"rly, "Gla"ssy (or "Vit"reous? pick one and stick to it) come to mind
immediately – my policy of always the first three letters helps one remember
how to abbreviate something.
Habit: same comment as luster.
Hardness: a hardness like "2-2.5" makes it tough to make greater than/less
than comparisons as one often wants to do. I recommend separating high and low
numbers into separate fields. If that is tough on a Mac, send me a copy before
upload and I will fiddle up a filter to break those ranges up if they are
consistent (always number-dash-number, no blanks, for example, ideally the only
such formations found anywhere in the record).
Cleavage: I would be interested to know what you do when there are multiple
directions, as with calcite. Is there always a number in that field if there
is 1 or more cleavages? Is it always at the start of the field? It would help
in greater-than comparisons, though many database programs might prefer the
number be in a separate field for such.
Crystal drawings would of course be welcome, but would not fit into a text
database in any manner I can figure. A separate database would be needed
there, in some specific format. I do not know if the Xbase (dBase) standard
has any provision for embedded vector graphics (as bitmaps the drawings would
be far larger), nor what the widest-usability vector graphic format would be
(for photos, which more or less have to be bitmaps, GIF format should do).
What about it folks? Am I barking up any wrong trees here?
–Doug
Doug–
Great, thanks for the comments. Please–everyone else, your comments on what
your needs are will help too.
This database was created strictly for one purpose–my use. For that reason,
there are no abbreaviations or shortcuts, it was not created with the thought
of condensing it for quick/efficient electronic transmission. With such in
mind, several changes, such as Doug has offered here can be made. Certainly,
system can be abbreviated with no confusion to anyone. But I'm not so sure
about doing the color by Doug's method. Color is a problem anyway, because
mineralogy texts are terribly inconsistent in its use, thus "equal" coverage
for all minerals is lacking; some minerals have only one or two colors listed
in any source when I know there are several colors yet the next mineral has
every color in a box of crayons listed.
Lusters & habits could be abbreviated, most are "standard" terms.
Hardness is certainly one to think about. I have never liked making a database
with more than one field for any characteristic. It makes it more difficult to
do searches (my opinion) (which fields do I select for entering the search
criteria–all under the characteristic?).
Cleavage would take some work to make it simple/convenient for a search. The
data I have used is the data available for the direction/plane (i.e. {100}),
the number, also "partings", etc. What is available is not consistent. Some
minerals have none available, which doesn't always mean there is no cleavage.
Thus one mineral may have: "1 good, 1 poor" another will have "{100}, {101}
perfect, 1 parting".
As I worked on this database over the last few weeks (it needed editing) and
still more data to enter, I began to think of a couple more projects I have
been thinking about and decided that I would like to add crystal drawings and
even photos (I have this "project" of producing a color encyclopedia of
minerals to be used as an aid in identification.). That would not work well for
just a "simple" database, but would be done in both DOS (and Windows) and Mac
formats in a relational database. I have not been big on making crystal
drawings so figured they could be scanned out of Goldschmidt and out of Am.
Min. (and others, if they will give permission) and created with Shape. Playing
with what I have, I noted that a simple drawing of a dodecahedraon created in
Freehand (Mac) takes around 3k, thus this database could be big real fast!
All input (suggestions & criticisms) is welcome.
Lanny
Hi, Lanny–
Color is indeed a quantity hard to whip into shape. For most fields in my
ROCKDB.ARC, I tried to include all the variations I found in my several
sources, and indeed the list of colors for a given mineral would often be
different from one source to another; by the time all observations are
included, maybe color will always wind up a full list of the spectrum. Color
may be more powerful as an entry in a locality database (if it is purple from
Lovozero massif, maybe it must be ussingite or scapolite, but from unknown
locales, purple could be most anything).
If I see 2 cleavage/parting planes in an unknown, a database search will not
make good use of this observation if there are entries like "1 good, 1 poor" or
"{100}, {101} perfect, 1 parting". If there is a simple number of cleavage
planes in a separate field, it becomes more useful in tagging unknowns. That
may be too much work, so perhaps that is something to leave for a later
release.
Is querying both max and min fields, or just one, difficult with your database
manager? As Angus says, "2-2.5" must become either two fields or a single
number to be really useful. If all I know is that an unknown won't scratch
gypsum, I will check for min_hardness <= 2; I would catch that "2-2.5" entry if
it is two fields (min and max), but not if it had been replaced by a single
field with 2.25 or some such. If I have a lower limit on hardness, I will want
to compare it with max_hardness. Considering wide variations in hardness some
minerals have, as with kyanite, two fields seems necessary to me. The same
applies to density; some solid solution series have a wide range of densities,
which no single number can handle.
3K seems right for a vector (object) image of a crystal shape; it would be much
bigger as a bitmap. Xtal drawings should be particularly compressable, perhaps
down to 1K apiece. Make it relational – the main mineral database has entries
selecting drawings out of another database – since many minerals may share the
same drawing(s), it should be smaller. Mineral photos could likely be >100K
apiece, since they would naturally be bitmaps. Compression could cut that in
half, but not down to any 3K. A database containing thousands of photos would
be best on CD, not as an upload!
Note also my remarks to Angus in this thread.
–Doug
Doug, Angus, et al,
OK, lots of good input, but now I am lost. What to do, what to do. The database
as I createad it, was to have quick access to "all" information, not really
designed for the best/most efficient searches, especially to be used for
identification and determinative work. Fortunately, once you have "all" the
data, it can be changed or removed. One other item, the last field lists
addtional information such as dimorphs, occurrence (in basalts, in hydrothermal
deposits, etc.), and for minerals that are known from only one, or a few
localities, the localities are listed. Suggestions? Come to think of it, how
about some comments on the Habit field.
Lanny
Hi, Lanny–
Those best searches we have talked about are precisely those that make it more
valuable for identifications, the first and foremost use I at least have in
mind for it. It also can be related to catalogs for printing informative
labels and whatnot, but we have focused on ID.
I suggest you make the quick and easy abbreviations using global
search-and-replaces, make a text file, compress, and upload. Include a brief
description, especially a copyright notice and mention of any shareware fee and
where to send it. Bear in mind as it is passed around, it may turn up
someplace where they will not know who the author is unless that is built in.
Several of my uploads, notably ROCKDB.ARC could serve as checklists/examples.
Later we can tune it into a DBF relational database or whatever.
Mention of the habit field reminds me of the way the Audubon "Field Guide to
North American Minerals" key section is laid out. There is a group of pages of
photos indexed by color and by a very crude sense of habit. The same trick
might help in ID searches of your database if the habit field was split in two,
one with only one of the few crude choices, and the other free form like you
already have. The categories they use are Equant, Prismatic, Acicular,
Tabular, Globular (meaning botyroidal), Massive, Dendritic, and Gemstone
(gemmy, I guess). Naturally, I would abbreviate these; also naturally, you
likely cannot easily put all the minerals into one each of these classes; this
I would leave for later.
–Doug
DM> the size, perhaps ZIP archiving would be better; it is smaller and
DM> almost as widely usable as ARC format (I just reviewed COMPRS.DOC and
ZIP for sure, include a copy in ARC format but monitor the downloads; if there
are none (or only 1 or 2) in 6 months, discontinue it.
DM> What about it folks? Am I barking up any wrong trees here?
Well, I think with some good relational design we could knock the size of the
datafiles down significantly – even more than you think. If I had a good
dataset I could design and build a shareware (or freeware – haven't thought
this out enough yet) program to access it. I'd use dBASE IV since that's my
language of choice right now, but I have a C-code generator and need something
to justify playing with it; this might be the project I work on it for. I
recommend DBFs as the universal micro data format.
Regarding shrinking the data for download (and diskette) efficiency, this is
what relational databases are for.
DM> System: abbreviation would help limit the size of the text form
I would make XLSYSTEM a one-character field: I,H,R,4,O,M,T,N for the fields
you listed above. The only non-obvious one is 4 for Tetragonal.
DM> Color: again abbreviations would help. I used only three
DM> letters and limited the number of colors: Whi(te), Bla(ck),
I would use one-character abbreviations for COLORS and provide a lookup table
for the abbreviations. I might also provide a parent-child relationship with a
separate table just for colors so that you weren't limited in the number of
colors you could include for a given mineral. If you fix the colors field at
20 characters (say), then for an ASCII file or an Xbase DBF you must include
those 20 characters for every mineral regardless of whether or not it is
needed. This can add up in a hurry.
DM> Luster: some abbreviations could be worked out here, though I
In my teaching DBF program Mineral Key we make users select between M
(metallic) and non-metallic first, and then select a non-metallic luster. Again
we used 1-character abbreviations. In the first pass at the program I used
many abbreviations in a 5- or 6-char field for minerals with multiple lusters
but in a larger system I might use a child table.
DM> Hardness: a hardness like "2-2.5" makes it tough to make greater
Absolutely must be a pair of fields. Ditto for Specific Gravity. If there is
no range, then both numbers are the same.
DM> Cleavage: I would be interested to know what you do when there
In Mineral Key we just stored a number.
I have permission from my Mineral Key coauthor to make it shareware and upload
it, just haven't gotten a round tuit. Maybe having a much larger dataset would
make it happen <g>. We could maintain the DBFs and the program as two separate
files in the LIBs, too, so once you had the program you could just get updates
to the mineral files.
Yours in freedom,
-=< Angus Scott-Fleming >=-
GeoApplications
Tucson, Arizona
* Natural drill rig * Kansas geologist wearing cleats in a tornado. *
Hi, Angus–
I used 3 letters in my abbreviations because the text database does not have
built-in field definitions, and I wanted it readable in a word processor as
long as it was text. Also, 3 letters is enough so one will not confuse the
xtal-system field with the luster field while naming fields, a problem only for
a text database.
But as a database in Xbase (DBF) form, of course I agree with shrinking what is
stored for many of these fields down to one byte, especially if the Xbase file
can itself contain lookup tables for displaying that one character as a whole
word in reports. Can it? At least that can be done with a particular program,
say your Mineral Key. I look forward to seeing that.
Is the database Lanny describes enough to keep Mineral Key happy, with maybe a
few fiddles such as we have discussed?
How does this "parent-child" relationship for the colors field compare with
using a memo field for that purpose?
–Doug
DM> I used 3 letters in my abbreviations because the text database does
DM> not have built-in field definitions, and I wanted it readable in a
DM> word processor as long as it was text. Also, 3 letters is enough so
DM> one will not confuse the xtal-system field with the luster field
DM> while naming fields, a problem only for a text database.
Understood, and this is also the way you would have to do it if you were
storing the data in an old-fashioned spreadsheet (one that didn't do lookups
from other sheets or from other areas in the same sheet). But we were talking
about data efficiency as being important to those who need to D/L the system.
As part of this package we could certainly provide flat-file text export
capabilities (to ASCII files, for example).
DM> especially if the Xbase file can itself contain lookup tables for
DM> displaying that one character as a whole word in reports. Can it?
No, the lookup table is a separate file. In an SQL system like R:Base or in
something that's closer to a "true database" like Emerald Bay, all the lookup
tables are in the _database_ file. In Xbase, a "database" comprises many
separate tables, and each table takes two or more files – the DBF, one or more
index files, and zero or one memo-field files.
DM> At least that can be done with a particular program, say your Mineral
DM> Key. I look forward to seeing that.
DM> Is the database Lanny describes enough to keep Mineral Key happy,
DM> with maybe a few fiddles such as we have discussed?
Absolutely.
DM> How does this "parent-child" relationship for the colors field
DM> compare with using a memo field for that purpose?
Parent-child works like this: one parent, multiple children:
MINERALS (parent – 1 record) MINCOLOR (child – repeated records)
======== ========
00001 (key) 00001 B (matching key and color code)
SPHALERITE 00001 R (matching key and color code)
(other fields) 00001 Y (matching key and color code)
00001 G (matching key and color code)
This is what you would have to have for localities, for example. Your
LOCALITY.DBF would contain fields like continent, country, latitude, longitude,
etc. You could have one or more localities and you wouldn't waste space
allowing for the maximum number of locations in all the records in the main
DBF.
Yours in freedom,
-=< Angus Scott-Fleming >=-
GeoApplications
Tucson, Arizona
* TANSTAAFL * Geologists have rocks in their head!
Hi, Angus–
What I really had in mind when I spoke of including the lookup table in the
same file was the ability to use all the related component files in a simple
non-relational database program or spreadsheet, including the auxiliary lookup
tables.
Many spreadsheets can open a DBF file, but I am guessing if there is a
collection of related DBFs, the spreadsheet may have to open each DBF
individually, then require some manual setting up of VLOOKUP functions and the
like to expand the super-abbreviated fields. Is that right, or do spreadsheets
actually recognize relatedness and somehow adapt to it these days? All the
time I see spreadsheets, database managers, word processors, and desktop
publisher programs evolving to have more and more of each other's functions
built in.
Anyway, I guess a non-relational DBF file is widely useful, if not quite as
widely as text, but if we introduce the relational aspect, it gets compacted
further, but no longer very useful to any but relational database programs.
I'll have to make a separate table for localities for my collection catalog as
well as my minerals/localities database; there are so many entries for
Franklin, for example, that both databases would shrink dramatically.
–Doug
DM> What I really had in mind when I spoke of including the lookup table
DM> in the same file was the ability to use all the related component
DM> files in a simple non-relational database program or spreadsheet,
DM> including the auxiliary lookup tables.
Yes, I read that into your message, which is why I responded as I did. But
lookup tables imply relationality. Flat-file databases rely on one file to
have all the data, resulting in repeated info that is subject to corruption or
mangling (if you change the abbreviation for BLACK from BK to BA, you have to
make sure you get ALL the occurrences of K or you've mangled things).
DM> Many spreadsheets can open a DBF file, but I am guessing if there is
DM> a collection of related DBFs, the spreadsheet may have to open each
DM> DBF individually, then require some manual setting up of VLOOKUP
DM> functions and the like to expand the super-abbreviated fields. Is
DM> that right, or do spreadsheets actually recognize relatedness and
DM> somehow adapt to it these days?
No, that's right. With any Xbase system the relationality has to be programmed
in, it's not part of the table structure, and that drives the database purists
nuts. One important aspect of a "true database" is that the rules for data
access and validity are part of the database and not part of any program.
Xbase and flat ASCII files and most spreadsheets all fail that test. But the
data are usable <g> to the rest of the world, at the possible expense of
security and data integrity.
DM> All the time I see spreadsheets,
DM> database managers, word processors, and desktop publisher programs
DM> evolving to have more and more of each other's functions built in.
Part of the lure of "suites" is the linkage between the parts. The latest
versions of WordPerfect have significant spreadsheet capabilities, too, and the
mail-merge in WP is really a database in disguise. Shoot, they're all just
databases of some sort or other when you look under the hood, it's just the
sheet-metal that's different.
DM> Anyway, I guess a non-relational DBF file is widely useful, if not
DM> quite as widely as text, but if we introduce the relational aspect,
DM> it gets compacted further, but no longer very useful to any but
DM> relational database programs.
Yes. One thing I would like to build into the registered version of the
relational program is the ability to spit out the user's choice of fields into
another DBF so that the user could select fields, including lookup fields from
related tables, and generate a flat DBF or ASCII file for importing into
something else. Main reason for relationality in this forum is to minimize the
download size, isn't it?
DM> I'll have to make a separate table for localities for my collection
DM> catalog as well as my minerals/localities database; there are so many
DM> entries for Franklin, for example, that both databases would shrink
DM> dramatically.
I'll bet.
Yours in freedom,
-=< Angus Scott-Fleming >=-
GeoApplications
Tucson, Arizona
* TANSTAAFL * Database (n.) more information than you'll ever need.
Hi, Angus–
I wonder if making the mineral database relational shrinks the size of the
download. The redundancy that separate lookup tables can remove should also be
removed in compression of a flat ASCII database, if the compression algorithm
is good enough.
What I hope for from making a related set of databases out of the one is more
like keeping it smaller after decompression, and perhaps allowing more uses.
As we add more fields with more info for each of 3200+ minerals, the
uncompressed database could be quite demanding in disk space and RAM.
Separated lookup tables might become parts of other relational databases; the
example I have in mind is that a locales list from a relational version of a
minerals/localities database could be valuable in building a collection
catalog, allowing one to avoid typing in (and misspelling) listed localities
when cataloging a specimen.
–Doug
DM> I wonder if making the mineral database relational shrinks the size
DM> of the download.
Probably won't save much on the download, but only a real test would tell for
sure <g>.
DM> What I hope for from making a related set of databases out of the one
DM> is more like keeping it smaller after decompression, and perhaps
DM> allowing more uses. As we add more fields with more info for each of
DM> 3200+ minerals, the uncompressed database could be quite demanding in
DM> disk space and RAM.
Yes, that's for sure, and that's one reason I like related tables. Another is
integrity.
DM> typing in (and misspelling) listed localities when cataloging a
DM> specimen.
Yup. That's what I mean.
Live free and Golf!
-=< Angus S-F >=-
* TANSTAAFL * Geologists LOVE their faults!
Actually, with something as regular as a text database, PKzip might shrink it
by 70 percent. In a binary form of database as opposed to text, it would be
even tighter.
Hi, John–
Good call! LHArc shrank my MINERAL.CSV to 31% of its text size. I had
overlooked that there is greater redundancy with certain "words" occurring far
more commonly in such a database than in straight English text.
–Doug
Running behind as usual, I wanted to add something to this discussion earlier
— intended to look up a reference at work — started on that, when it didn't
find it all immediately, got distracted and never got back to it.
>> System: abbreviation would help limit the size of the text form here.
>> I limited my options to one of these in my database: Iso (isometric=cubic),
>> Hex (hexagonal), Rho (rhombohedral=trigonal), Tet (tetragonal),
>> Ort (orthorhombic), Mon (monoclinic), Tri (triclinic), Non (amorphous).
Wanted to point out that this can be reduced to a single letter if you use
'anorthic' for 'triclinic'. [i.e. I (or C), H, R, T, O, M, A, N…
remembering, of course, that an amorphous material is by definition not a
mineral — but allowing you to use it for the convenience of including those
few things that fall here, that collectors et al are sure to look for.] I
prefer to list T and O after I, followed by H and R, but I may be in the
minority here.
This is a similar suggestion to the one Angus made, but possibly nicer as these
are all alpha-characters, no "4" — allowing the field to reject anything but a
letter. (I forget what programmers call such exclusivity…)
P.S. I plagiarized this idea from somewhere (ICDD? ACA? AMS?) but honestly
could not find it easily!
Doug, Angus, Elizabeth,
Everytime I read these messages I get more ideas and want to do more with it. I
think I will upload it soon (couple weeks, if I don't get to go out and
collect) with the basic data you all need. Then keep working on it. I think the
space saving of condensing some things down the the bare minimum of one letter
probably is not really necessary and does tend to make one have to think a
little harder about what that symbol means. To me, "Tri" means triclinic more
readily than "T" does (or does it mean tetragonal, or "totally obscure",
(sorry, I'll keep my sarcasm contained).
Question: I have been playing with the idea of building into a large, more
useful relational database. In DOS/Windows, what database is out there that is
a good relational database and allows the creation of… (pause, it is late and
I've forgotten the term) … self running, free standing, you know what I mean.
Something where I could create it and produce it ready to run, not raw data to
be loaded into your database?
This is a heck of a time to get into this. We are suppoed to be getting spring
weather here and I expect to be out in the mountains a lot the next 6 mo., not
sitting at this computer creating a database! This is fall and winter work.
Lanny
Building a good database is definitely a winter project. It sounds like a good
project for multimedia and a CDROM. Instead of "T", you'd see a little picture
as well as the word. You could even digitize the sound of the pronounciation
of the mineral's name.
Hi, John and all–
I have heard some people fuss over proper pronunciation of mineral names, but
I have never seen a guide on how to pronounce them. A phonetic spelling would
be a good addition to the database, if only we could find a source.
–Doug
LR> In DOS/Windows, what database is out there that is a good relational
LR> database and allows the creation of… (pause, it is late and I've
LR> forgotten the term) … self running, free standing, you know what I
LR> mean. Something where I could create it and produce it ready to run,
LR> not raw data to be loaded into your database?
Standalone program. In DOS, for low-powered machines (<4MB RAM) I use dBASE IV
1.5 Runtime just because I have it and I'm quick with it, for bigger machines I
use dBASE IV 2.0, which produces .EXE standalones. I'm just starting to tinker
with Force, an Xbase variant which may produce some very small standalones if I
don't ask it to do too much. I don't do Windows yet.
Although Foxpro 2.5 will allow you to produce DOS and Windows programs from the
same base, you have to use Microsoft's internal design tools to do so, and I
can't stand 'em. Also it relies on binary objects as part of the program, so
version control's a problem.
Yours in freedom,
-=< Angus Scott-Fleming >=-
GeoApplications
Tucson, Arizona
Hi, Lanny–
One other dirty trick for the mineral databaser to watch: "Hexagonal" is
sometimes used for the hexagonal system, which includes the hexagonal division
and the rhombohedral=trigonal division. Whenever I see the word "hexagonal" I
get nervous about which hexagonal it is. I got surprised this way by good old
quartz, having thought of it as being in the hexagonal division for a long time
before learning it is really rhombohedral. For a database, we want to either
not distinguish between those divisions and call them all hexagonal, or use
hexagonal only for the division – as long as we are consistent one way or the
other, which the literature often is not (sigh!). Oh, well, at least we can
try.
–Doug
Doug
Hexagonal can be a problem, except I have checked mine against Fleischer, and
Nickel & Nichols and they (supposedly) were consistent in using trig
(Fleischer) and rho (N&N).
When I get done adding all the new minerals for the last 4-5 years, there will
probably be about 3,400 approved mineral names.
Lanny