Search for content in message boards

Wish I had signed up for the beta

Wish I had signed up for the beta

Posted: 1376968501000
Classification: Query
I just started to read some of the beta testing content. Yikes!!!!

Some of the conversations are really making me crazy. I just read one about asking for AKA to be expanded to include a surname field.. This is so wrong, AKA should be removed and everyone should start using NAME, this is what it was ment for. Someone in the thread said they use it for married name... NO NO NO! Add another NAME for the married name.

If the development staff of FTM take this suggestion I'll know for sure that they don't have a clue. AKA was a workaround added by software companies that only had one name field and did not want to redesign their software to have a 1-M relationship in the database.

Saw a couple of other crazy requests but this one really got me mad. Sorry for the outburst!

Re: Wish I had signed up for the beta

Posted: 1376978772000
Classification: Query

WHY should AKA be removed?

Oh, yea, YOU don't have to use it.

I use AKA as is should, that is, Also Known As. I use it for myself, as an example. I have Russ in the AKA field, because that is what I go by.


Re: Wish I had signed up for the beta

Posted: 1376980624000
Classification: Query
I have a number people in my database who had aliases which I would regard as requiring AKA to be used, which arguably requires a full forename(s)/surname structure.
Generally, I find that when it is used it is to record a nickname or a diminutive, which to my British mind is not AKA, but K(nown)A(s).
Probably a cultural thing.

Re: Wish I had signed up for the beta

Posted: 1377000250000
Classification: Query
Edited: 1377001930000

As a member of better GEDCOM and FHISO you of all people should know why it should not be used.


I don't know your background, but I agree with you that nickname is not the same as AKA it does mean also know as, but we should begin to use consistant fields for the same concept NOT continue a bad implementation.

The NAME tag has a standard place to indicate if the name is a married name, AKA, birth, etc name, FTM chooses like so many other times not to use a standard form.

So instead of asking to expand the AKA field to include surname, ask to add "type" value of AKA, married, birth, or other to the NAME field.

This is the GEDCOM standard, and would support proper GEDCOM transfer from my program, a GEDCOM compliant program, to FTM a program that is not at all compliant.

Russ I do use AKA, I use it in a GEDCOM compliant way.

Re: Wish I had signed up for the beta

Posted: 1377000324000
Classification: Query
kj_norway comment and thread

"Wish I had signed up for the beta"

I wish you had too. I practically begged [I begged on every thread that had significant slowness, crashing, memory leak, etc that I could find] for people to sign up for the Beta-------------especially those who had large data bases with lots of names, lots of fields, lots of places, lots of images, lots of linkages etc etc etc

I just hope that some of them did sign up for the Beta

Re: Wish I had signed up for the beta

Posted: 1377000605000
Classification: Query
AKA, but K(nown)A(s).

AKA is an acronym for Also Known As

Re: Wish I had signed up for the beta

Posted: 1377001849000
Classification: Query
Edited: 1377002050000

The good thing is I think they are working on speed. They will be having a 64 bit version of the program, which will really help out with Win7/8 people in both speed and crashes. This alone may be enough for casual users to upgrade. Although have been a system programmer, designer and database designer for most of my life, I would say I hope the beta testers really push all functions hard to see if all code was upgraded to 64bit.

Tony and Russ,
To advance my point a little more about AKA it is not that I don't like the concept it is that I don't like the use of an additional construct when one already exists. As a database designer NAME is the construct, AKA or married, or birth are subset of that construct. This is the way the database should be designed and data entry should follow. Technically you could have a separate data entry point that just adds the AKA to the name construct with a type (or attribute) of AKA. This is what a good database designer would do!

Re: Wish I had signed up for the beta

Posted: 1377002730000
Classification: Query

The problem with what you are saying, is how it's used.

I have a number of people, (many, in fact), where I find and record the Name differently, based on the Source and record that information with multiple Name Facts. I mark ONE as Preferred.

To use YOUR Name fact, I could not use the Preferred Only NAME and the (current) AKA field.


Re: Wish I had signed up for the beta

Posted: 1377004163000
Classification: Query

kj_norway comment on AKA [ and tony_knight comments]

kj I do have some [hopefully serious] comments on this --- I don’t know what is correct, but here is what I have been doing

Using the US census as the first example:

In one census I have a person named John Jones, so I list his name as John Jones and create all the appropriate sources, attributes etc

I another census I have the same person listed as James Jones, so I list his name as James Jones and I create all the appropriate sources, attributes etc

I do this process for many other censuses and find that his first name is either shown as James or John

So I create another name for him and call it John James Jones ---I have no record for this but I list it as a name and do not create sources, attributes for it because I have none [I also use this as the preferred name]

In all the above I use the fact name “Name”

I also have instances that run along the line of what tony_knight is talking about – an alias

In fact I have it exactly for my grandfather

When he was in Maine he used the name Robert E Johnson [I made this up to protect the innocent]

And when he was in Kansas he used the name William B. Johnson

I found that he had done this on purpose and was using the first instance as an Alias

So when I entered his name in the data base I entered it as William B. Johnson and then I entered the second name [Robert E. Johnson] as an AKA since to me he was actually using it as a different [alias] name and all the people he knew in Maine knew him as Robert E and all the people he knew in Kansas knew him as William B

I have other instances such as this and have ended up using both “Name” and “AKA” depending on the situation.

Again my old plea ---------it would be helpful if the people who are designing these systems would define their terms and provide example of how and when to use them

Re: Wish I had signed up for the beta

Posted: 1377005729000
Classification: Query
Edited: 1377017101000

You are missing the point. All instances of a name are important, most of my relatives have different AKA names based on where they lived at a given time. I always add one as the primary name, normally this is either their birth name or the name that most people knew them by while they lived. Then add the other names with a "type" of AKA or married.

Several of my relative, including myself, have "pen", "stage", or pseudonym which I also record. All of these names are still recorded as a name, but with different "type" values.

As far as spelling changes I record these as names as well not in the AKA field but as a NAME with an attribute of AKA. Using the same data construct is good database practice and can be better used in reports. Because then it is either a list of all name with their type attribute or the first ( primary) name when you only want one name listed.

So again... It's not that I want to eliminate AKA I want to organize it in the correct construct which is name.
per page

Find a board about a specific topic