Re: META: how-to ruin a perfectly good FGS




JYoung6180@xxxxxxx wrote:

It is hardly a standard that no one uses if you count the number of
time it is used in WorldConnect

I'm not sure I've *ever* noticed it being used in WorldConnect. I
guess I don't read the right databases.

I just did a global search on ancestry, and there are over 4.8
*million* surnames "Unknown" in the Ancestry/Rootsweb trees.
(Ancestry's other three tree systems have another half million).
There are only 67,000 in Rootsweb with just "Unk" and 43000 "LNU".
Adding all forms starting with Unk together gives over 5 million
(suggesting lots of alternatives similar to "Unk" and "Unknown", or
maybe lots of typos). [I don't think there is an easy way to even
search for the number of times the standard or any alternative based
on special characters is used, or I'd give the numbers]

I went to worldconnect.rootsweb.com (which is the same data) and its
search engine is friendlier to special characters. It lists the
same 4.8 million "Unknown", 15000 "-----", 75000 with any string
starting with "---", and 87000 with "[--?--] and 88000 with any
string starting with "[--". "Unknown" wins, hands-down.

I then did a google site search on all of rootsweb.com
4.2 million hits on "unknown"
665,000 hits on "unk"
It is again impossible to search for the "standard". You get the same
answer for "-----" as for "[--?--]" (which may be the total number of
pages on rootsweb), so Google can't even tell the difference. Google
cannot even do a global search on either string, nor can ancestry.com,
nor can familysearch.org (which in a way argues against ANY special
character string as a standard, but not enough for me to change).

That's a lot of votes-by-usage against the "standard" being all that
"standard". Indeed, it comes darn close to suggesting that "Unknown"
is the much-preferred standard, even though neither you nor I prefer
it.

and other databases/articles/ webpages.

They must not be the ones I read, since I almost never see it.

Those who don't use this standard format might be
submitting a database to a destination where they have been given
specific instructions in showing names

I have no interest in submitting my database to such destinations.
I also can't imagine writing an article for formal publication
either; I don't read them, so I see little point in writing them.

(and where it is clearly
explained the proper method of display for THAT particular
database). That's all well and good but otherwise, showing LNU,
MNU, UNK, ?, -----, ________, only indicates that the person doesn't
know the preferred method of display.

Preferred by WHOM? By professionals and writers of a certain
in-crowd that I never aspire to join (and I suspect most others
don't either).

I think highly of standards that advance the quality of information
available. "[--?--]" provides no more information that "-----", and
it is harder to type and more likely to run afoul of a search engine
since it uses a standard wild card character in the text.

What isn't clearly understood
by everyone reading the names doesn't work. I seriously doubt that
anyone seeing [--?--] would confuse the meaning--and that's the
point.

You might argue that showing _____ or ------ or even ? would also be
clearly understood by all.

I can't imagine how "[--?--]" could be in the least bit clearer than
the first two, and its complexity using three different special
characters lends itself to typos.

A single character is a little more risky.

Possibly, but you would be amazed how
many people find LNU, MNU, UNK, etc. in someone's database and
assume that is an actual surname and sometimes spend years looking
for Mary LNU..or even Mary UNK.

Yep. I did myself make that error with LNU and MNU. Of course, the
fact that my daughter once had a teacher surnamed "Ng" made it
easier to accept such a strange looking name as plausible. Anything
using English words or abbreviations is especially risky in an
international setting.

I would disagree with you that Mrs. John SMITH is a title;

The dictionary disagrees with you %^)

m-w.com:
<Main Entry: Mrs.
<1 a -- used as a conventional title of courtesy except when usage
< requires the substitution of a title of rank or an honorific or
< professional title before a married woman's surname <spoke to Mrs.
< Doe>

Mrs is a title *by definition*. Since "John Smith", without the
"Mrs" title, is not her name in any sense, it is part of the
descriptive title "Mrs John Smith" which might be applied to someone
named "Mary Doe" for whom the title is appropriately descriptive.

it would
more appropriately be an AKA (also known as) or Alternate Name entry
in a database.

I avoid using those, since I don't see them when working, and they
wouldn't appear in most reports, and I do not necessarily have
evidence that they were ever known by that name (which makes AKA
simply incorrect).

A married name IS a "title", not a title of nobility or a title of
honor granted by someone higher. (But then, in this country, there
is no one "higher" than Mary Doe, not even a professional
genealogist %^)

I use the format that >I< want to see in a report, which is one
conveying as much information as possible, and which makes my work
easier while I am doing it, by putting the information I need where
I can see it when searching and comparing names.

Since I do genealogy for me and my friends and relatives, we are the
people who I aim to please. I try to make what I do useful to
others, should I ever put it online, which is the highest level of
publication I would ever aspire to, and providing more information
is potentially more useful.

What I have done is far clearer than "Unknown" which is the defacto
standard, and it provides information about what IS known, thereby
solving John Evans problem (post of 24 Apr which originally prompted
my post) of easily distinguishing between two people who are Mary
LNU/Unknown/-----/[--?--] in the database.

It also isn't hidden away in notes that I probably cannot easily
publish online since I don't accumulate my notes in any sort of
publishable form.

Bob LeChevalier

Bob LeChevalier <lojbab@xxxxxxxxxx>
.



Relevant Pages

  • Re: GEDOM as a database format
    ... Tony Proctor wrote: ... isn't complicated Peter, but that doesn't make it impossible, and it doesn't ... It also includes the operating system crashing for no apparent reason and also the disk on which your database resides going up the swanee. ... The standard I want to see is something not constrained by application program, operating system, or hardware and even at a pinch be implementatble as a paper-based manual system. ...
    (soc.genealogy.computing)
  • Re: Some free utilities for Java, with Hebrew support.
    ... a third-party MySQL client library that I know of. ... market at large. ... The JDBC and ODBC models are such that the database vendor ... provides exactly that adapter to fill in a standard API. ...
    (comp.lang.java.programmer)
  • Re: Databases, Typed Datasets, and Flat Files oh my!
    ... file, get the right characters, and then manually add the rows to the ... This standard consists of a fixed ... dataset gets shoved into database (or vicea ... All of the stuff I see for typed datasets is "XML! ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Loading a data file containing character fields with different encodings
    ... The data is coming from one database that contains UTF-8 characters and it appears that he's attempting to load ... UTF-8 characters along with Latin-1 characters. ... it would be just as easy to write the loader script that converts the encoding to a "unicode" intermediate format and then load with the correct database encoding. ...
    (comp.databases.informix)
  • Re: Loading a data file containing character fields with different encodings
    ... The data is coming from one database that contains UTF-8 characters and it appears that he's attempting to load ... UTF-8 characters along with Latin-1 characters. ... it would be just as easy to write the loader script that converts the encoding to a "unicode" intermediate format and then load with the correct database encoding. ...
    (comp.databases.informix)