Auto Populate Standard dates and Names

LegacyUser

Jim Barnhart said: two suggestions today.

#1 - automatic standard Date and Name correction. If I type in 2 Sep 1940 auto populate to standard 2 September 1940 without scrolling and selecting another bar. Also, auto populate Standard names with Capital 1st letters.

#2 - When adding a marriage be able to add date without clicking on date bar.
Thank you.

LegacyUser

Tom Huber said: Not all cultures and languages support capitalization for places and, as far as that goes, for names.

As for dates, FamilySearch supports more than day-month-year and includes dual dates, from to dates, and about, before, after dates.

While the idea has merits, any automated routines would need to take into account all of these possibilities.

A while back FamilySearch ran a routine to set standards (they may still do it from time to time. There were situations where they decided that a human needed to make a decision and left those alone, especially where either the standard or the entered data was ambiguous.

Note, I am not saying this will not happen, but that there are situations where any automation would take a certain amount of intelligence to pull off. Artificial Intelligence, despite claims by science to the contrary, is still a matter of science fiction.

There are two areas in FamilySearch that could benefit if A.I. was actually possible: 1) the hinting system, and 2) the possible duplicates system.

LegacyUser

Stewart Millar said: Jim,
You seem to have missed an imporant point - FS always keeps 2 versions of dates and place names - a version as you prefer to see it - the date displayed in the record - as in the convenience of dates being dd Mmm YYYY . . . . to which, FS automatically generates an associated/linked standard version.

Similarly with place names - ideally the entered/displayed place name reflecting the source documentation . . . and FS will assign what it thinks is a best match standard place name to be linked to your entered place name. If you believe that to be unsatisfactory, you can edit the standard place name to select from the list of associated standard place names that FS can match to your entered place name.

Note that by hovering the cursor over any entered/displayed date (in whatever format) or entered/displayed place name - FS will display the associated standard that is being used.

There is absolutely no need to wander through other people's contribution to dates and places changing them to to be "Standardized" if they are already linked to an equivalent standard (i.e., not displaying a red exclamation mark indicating the entered date or place is not linked to an associated standard version).

LegacyUser

Jeff Wiseman said: Jim,
Doing so would totally break several of the significant benefits of the unique "dual name" and "dual date" system that they have (as Stewart Millar mentioned above).

It is not possible to create a "standard name" for every square inch on the earth for every year in time that we've had. We can't even do it for every house that has existed on every street within a city. It's impossible. But we can do it for significant places like towns, cemeteries, States, etc. And for places that we are not in the standards database, using the dual name feature we can add the important extra data that is known about the location.

For example, I have entered a residence location for one of my ancestors as:

22 Page Road, Chillicothe, Ross, Ohio, United States

That is not a standard place in the standards database but it describes down to within a couple of feet exactly where on the earth it is. But since it is not a "Standard", it means that it has no geo-coordinates assigned to it. But the following *IS* a standard location:

Chillicothe, Ross, Ohio, United States

Because it is a standard, it has a geo-coordinate that is based on the center of the city of Chillicothe. So I can use the standard place name (with its geo-coordinates) from the database to "standardize" the place name that contains the far more accurate street name and address.

So if the system were to automatically change my entry into so standard name from the standards database, it would throw away all of the useful extra location data that I have provided which is beyond anything that is in the standards database.

Standard names in the Standard Places database are not intended to be some common way of spelling a place name. The standards database is for identifying ALL of the names at different points in time that were associated with a single physical geographic location.

For example, "Union, Virginia" in 1860 and "Union, Virginia" in 1900 are standard place names for two totally different places that are a couple hundred miles away from each other. Union, Virginia in 1860 and Union, West Virginia in 1900 are the same physical location in the Appalachian mountains. They are truly the "same place" regardless of which name is used (West Virginia was formed from part of Virginia after the civil war)

Without the dual name system and the standard places database, this would be very difficult to accurately record. If the system were set up to always ensure that the name in the display for the Vital always matched a standard place with the same identical spelling, it would nullify a significant benefit of the system.