Standardized Dates and Places

LegacyUser

Jeff Wiseman said: Of course that is an alternate way to do it, and I have done it that way myself on many times over the past. But I don't like the fact that the map pin gets put onto a county that does NOT contain ANY of the three "Springfield"s.

I am familiar with the technique of additional commas. In fact it was a documented standard way of doing things in several places in the past (PAF was tool that encouraged its use). That could be a way to add extra information, but how do I know that "Springfield" isn't a county? The only thing that is known in the example I gave is that the birth place, as recorded in three different sources were all the same--"Springfield, Ohio". Since they are all American records, you could safely assume the country was United States, but you can't necessarily assume where Springfield was a city, village, township, county, or borough. By using terms like "Springfield Township" in the Standards database, FS has gotten away from the multi-comma formate.

Also the multi-comma format implies jurisdictional hierarchies which are different in different places of the world and can change over time. For example there are the cities in the US that do not exist inside of a county. If the Springfield in my example were one of these, then the extra commas would literally be wrong!

Anyway, these are some of the reasons that this technique has been deprecated by myself as well as the fact that sites such as FS also seem to be doing this.

In all cases though, the extra commas would be an assumption not based on actual data obtained from the sources. That in itself doesn't make it wrong, but it could be. Better not to make undocumented assumptions.

LegacyUser

Jeff Wiseman said:

There is a bit of a risk, however, that someone else will stumble across it, pick one of those three counties in Ohio that has a Springfield, and "fix" it for you. This would have a pretty good change of making both the displayed text and the standardized value wrong.

There is also a possibility that the new volunteer effort to fix standards and get rid of as many red icons as possible would find your entry and someone would pick the first standard he sees for the place. This would not change the displayed place name but would have a high chance of putting the wrong standard on it while removing your marker.

In both of these scenarios, we have a related situation where you already have an appropriate standard place assigned and someone comes through and breaks it in the same nonchalant way. Not much you can do about those people except try to educate them.

But realistically, when a person goes to eliminate a data error due to a missing standard place, when they are immediately confronted with three standard places that are obviously different but any of them could clearly be the legitimate standard match to the value entered (thus making the others wrong), it should be fairly obvious to the person what the issue is.

And if it is not, and their primary intent is to just eliminate data error warnings at all costs, there is nothing any of us can do (typical scenario). BUT, since I have a vested interest in that record he or she is changing, I have a watch on it. So when the change is made, supposedly I will be able to see it in my watch list. I can then go and correct it while documenting the reason that there is not enough information to standardize the display name of the place yet.

BTW, I assume that if a location (display) name for an event is not modified, but the standard place name assigned to it does get changed, that it will show up in the change history log and on the changes to my watch list if I am watching that person! Since the location conclusion involved BOTH of these elements in the place names system, it would be pretty ridiculous to track changes to just one and not the other.

And lastly:

The third issue is that by setting the Place as "None of the Above," you deprive yourself any hints for the item because the hinting routine is based on the standard.

Is this really true? Does the hinting system really ignore unstandardized place names in its algorithms? I'm not sure that is the case.

LegacyUser

Wayland said: This has turned out to be a very interesting discussion. Thanks for joining in. It is my understanding and observation that yes indeed the hinting feature and also the possible duplicate feature do not work without a standard date and place. I think we have pretty well eliminated having no standard date. As I said in an earlier post, there are untold number of records in the system without standard dates.

All you on this discussion come at these problems with a very good understanding of how the system works and I appreciate your concerns and comments. While I have a pretty good understanding of how it works, I try to come at these problems from what I see in being on the front line every week talking with patrons, many of which have little to no understanding of how things work. That is why I got concerned about scenario #3 which allowed getting different displayed date (regardless of format) and standard dates. I have seen so many of those that straddle the 110 year criteria because it causes problems.

So just for thinking, could we still eliminate #3 by making it the same as 1,4,5. And in its place, use the drop down on the standard date or place after choosing options 1, 3, 4, 5. For example on date, select the drop down on standard date and choose from the options or in place of "None of the Above"(which doesn't do anything except confuse us) allow entry of a standard date not on the drop down list. This would set the standard date while leaving the displayed date undisturbed. It also greatly reduces the chance that anyone could stumble onto this feature. It would also eliminate the multi-step process that some of you use of putting in a date to get the right standard date, saving and then coming back to edit and changing the displayed date and then selecting option #3. None of which seems very intuitive. Give it some thought.

Thanks again for sharing your thoughts. Another reason I get concerned about things like this is because of my background. I flew airplanes for 10 years (jet fighters and passenger planes) and then 30 years managing, designing pilot interface software and flight test. As you can understand, we had no tolerance for ambiguity or pitfalls in the software. Of course, I understand the consequences of things in Family Search are drastically different than aircraft software but I can't help being pretty sensitive to it. Thanks again, give some thought to my suggestion above. .

LegacyUser

Adrian Bruce said: Yes, point taken about the extra comma perhaps not being appropriate - although that does depend on how you believe "independent cities" should be comma'd.

That is an interesting point about the map pin appearing in the middle (?) of Ohio and being potentially misleading. Hmm

LegacyUser

Jeff Wiseman said: The map pin based on the larger "containing" area will always be a bit confusing, but that is a common element here. In the extreme it can throw you sometimes such as in the example of the British Honduras, British Colonial America where the map pin for BCA is next to Niagra falls.

On a different note, from my own question from further up the thread:

So does the Standard event date format include a "None of the above"?

Apparently it is, but it is broken at present:
https://getsatisfaction.com/familysea...

LegacyUser

Matthias Schulz said: If different people are wishing different display dates, it never can be the solution, to have a display date and a standard date.

You have to provide the user with the chance to generally decide, how the dates should be shown for him in the tree. So the solution is to provide us in the settings with the chance to display all the dates, as we want to see them. And then you don't need another date than the standard date.
If there are people, who wish to see also the day of the week, the system is also able to automatically calculate that and display it too. That should also be decided in the settings.

For the few exceptions, who like to enter any information from an exotic calendar, that can't be exactly calculated into the gregorianic calendar, the only ingenious solution is putting this information in a comment field, because it can't be used as an exactly defined date. You are than able to give the month and the year into the date field.

With this possibility to enter your preferred data format in the settings, you can also avoid, that data is changed constantly, because there are users, who want to see an English data format and others want to see a German data format and so on.

LegacyUser

crhansen said: Gordon, it happens when someone clicks "Save" before clicking on the standardized date provided by FamilySearch in response to the data entered in the date field. The currently entered data is saved in limbo.

To clean up dates or locations, I just hit space bar, and accept the standardized form if it's an improvement.
-crh

LegacyUser

crhansen said: I don't think we should preclude allowing dates to be decorated or ambiguous - we don't actually know the date then, do we? In this exception case the program could escape to using an unspecified string variable until better information is determined. However, for the vast majority of well-defined dates an internal definition may be used which could be displayed in any format. Having solid dates would propagate to the search engine to search only for people with exact matching birth dates, etc. A huge time saver!

LegacyUser

Paul said: See my comments at https://getsatisfaction.com/familysea...

LegacyUser

crhansen said: I agree, we need to standardize:
Jan Feb Mär Apr Mai Jun Jul Aug Sep Okt Nov Dez

At least, it's not French. ;-)

LegacyUser

crhansen said: I simply add a comment in the reason field:
in 1820: 1st Søndag after Treenighed = 4 Jun 1820

LegacyUser

crhansen said: My thanks for all the work the Family Search team does creating and maintaining this database. I can only imagine the complexity of the problem. It's a remarkably powerful tool!

But one more issue... FamilySearch.org spells out the full month name, while Ancestry.com uses 3 letter month codes, Jan, Feb, Mar, etc. as their standard. As profile information is automatically passed between the two, the date formats get intermixed. Personally I prefer the Ancestry.com format because it's simpler and sometimes matches the more common foreign languages. It would be nice if we agreed on the same standard, but automatic format conversion is another solution. Standard place names also get intermixed.