Showing if something is standardized
I suggest you put a icon on the details page to indicate if a date and/or a location are Standardized.
This would make it quicker to know if the date or locations are Standardized, instead of opening the edit box of each location and date to find out if they are Standardized.
Thanks
Ken
Best Answers
-
All,
Here is a simple example.
"England"
No non-standarized label will appear but the value the system reads is "England, United Kingdom". The problem is there was no United Kingdom prior to 1801.
The system then is looking for data after the 1800 date for persons who existed in the 1300, 1400, 1500, 1600 and 1700 hundreds. No data will be found.
I have found hundreds of examples where this has occurred. Once the location and date are "Standardized" for the system to read, more information is found for verification and support.
I have attached an example you can look at. Matthew Fuller LZ8B-LBR, the birth location shows England, but the system is seeing United Kingdom. The easiest way to check this is to go to tree fan view birth location. It will show him being born in the United Kingdom in 1610, which is of course wrong.
Let me know if anyone understands this.
Thanks
Ken
1 -
Attached a third example.
The location provided is a post 1800 location. Human intervention is needed. In 1600 only Norfolk, England existed. The other portions of the location did not exist. Knowing geography is helpful when standardizing locations.
0
Answers
-
There is a very blatant mark when a date or place is not standardized. It looks like this:
Unless the place name is wrong, incomplete, or in a format you want to change or unless the place is on the wrong spot on the time line map, there is no reason to be fiddling with the place name as long as that message is not there.
If that message is not there, the place name is entered correctly and the place name is standardized.
For more information about the all the correct ways to enter place names in Family Tree and what it means to correctly "standardize" place names, please see my short presentation: https://youtu.be/qLa5PC4RPPk
2 -
You don't need to open anything or do anything besides look on the Details page to see if a location or date is standardized (associated with a computer-parseable entity): if it's not marked in red, it's standardized.
You can see the exact label of the associated standard by hovering your cursor over the date or place; the standardized value will show up in a tooltip.
2 -
The key words in Julia's comment are "associated standard." The displayed text on the detail page can be whatever you need it to be for completeness and accuracy as long as it is linked to an associated standard that can be either the same, in a different language, or highly inferior due to incompleteness. Never degrade a date or text just to make it look like the associated standard. That is not standardization. That borders on vandalism.
Changing "1 Apr 1850" to "1 April 1850" is not "standardizing." That is just improving a format and is, of course, fine to do.
Changing "Palmesøndag (Dominica Palmarum) [9 April] 1775" to "9 April 1775" is not "standardizing." That is ruining correct, complete data and should never be done.
Standardizing means only to link the correct associated standard to the data shown on the Details page.
2 -
There are two ways to look at the issue of a displayed placename being "standardized". Firstly, if it conforms with an entry in the "Standards database", but secondly - and more importantly - if it has been standardized to the relevant location. To confirm the latter, it is necessary to click on the Edit icon. Otherwise, the perfectly acceptable-looking "Richmond, Surrey, England, United Kingdom" might have been standardized (by human or machine) as "Richmond, Virginia, United States", or any one of the large number of "Richmond" alternatives relating to places of that name throughout different continents.
I appreciate this type of problem is soon revealed from checking the Time Line, but this still illustrates that superficially a placename may appear correct (on the Details page), but there is a vast difference between a placename that has been standardized "full-stop" and one that has been standardized according to the intended location.
1 -
In direct answer to Ken's question, Gordon is correct is saying a warning flag will always appear if the placename (or date) is "Non-standardized", but I can't see how any programming would be able to determine (and thus produce an icon) to indicate a placename has not been standardized to the correct location.
1 -
Paul wrote that "it is necessary to click on the Edit icon" -- but he's mistaken: as I wrote, all you need to do is hover your cursor over the place, and a tooltip will tell you what it has been linked with.
He also wrote about things being "standardized (by human or machine)", but the latter -- "by machine" -- doesn't apply to conclusions in Family Tree: there is always a human involved in accepting a standard for those.
0 -
On the first point, yes I made a mistake there, but "hover or click" you still have to take some action , other than just "looking" at the page, to know whether the place has been standardized to the correct location. As you know, there are many users who are still to get used to taking this (hover over) action, which (I just found) is not quite so easy when using the old Details page (I had to hover to just the right place before the standardized name was revealed!)
On your second point, I have had conflicting "behaviours" with data that was carried across to Family Tree in 2012. The user is always shown as "FamilySearch", but sometimes a place in the format "Whitby, York, England" shows as being standardized, but on other occasions it is shown as "Non-standardized". "By machine" might not be the correct expression, but this certainly seems to relate to something that happened on or before this data came across to Family Tree - maybe manually, but certainly not the work of an identifiable Family Tree user.
0 -
I still wish FamilySearch had never called this whole dual place name system "standardization." The way FamilySearch uses the term, "Richmond, Surrey, England, United Kingdom" linked to "Richmond, Surrey, England, United Kingdom" and "Richmond, Surrey, England, United Kingdom" linked to "Richmond, Virginia, United States" are both standardized. The second one is standardized incorrectly but it is still standardized.
There are actually five ways to proof-read standardization.
1) Most importantly is to always check when entering a place name either by typing it in or using the source linker that one is also entering the linked standard correctly. In other words, do things right the first time:
2) Hover over the data on the detail page:
3) Click anywhere in the grey box that appears when over the data:
4) Click the Edit pencil:
5) For places that have dates check the timeline:
The map option is probably most efficient since you can check all places at once. Notice that only the standardized version of the text shows, not the actual linked data. (If you can't tell on the map whether the linked standard is the correct one or not, then you need to spend some time learning about your family and stop trying to edit place names until you understand those place names.)
Note that the old page's map pin would not have been helpful here anyway because this particular cemetery is not in the database under the city of Telluride as it should be according to the cemetery's own website ( https://www.lonetreecemetery.org/ ). It is only there under the subdivision of San Miguel which is inside Telluride or under the county of San Miguel. That means that there is no way to enter the correct place name and have a map pin.
Until people stop confusing correctly entered place names which might rarely be linked to an incorrect standard and place names only being correct if they are identical to the standard, I'm going to keep harping on the difference. Here is an even more correct entry for the above burial which again on the old pages would never show a map pin:
Do not say, "But we're not suppose to enter real place names, we're suppose to use standards." That is a completely incorrect interpretation of what FamilySearch means by "standardization" and a rejection of what FamilySearch has developed to overcome the limits and restrictions that predefined lists of places always impose. And do not say, "But extra place name information is supposed to be hidden somewhere else like the Reason Statement or in a Note or in Sources." There is no reason to hide information from other users when we have been given an obvious place to put it and a system that allows it to be there.
4 -
The only point on which I would disagree with your remarks here, Gordon, is with your comment "...correctly entered place names which might rarely be linked to an incorrect standard..." Rather than being rare, I have found this to be relatively common. It's not a big issue in itself to me, because - in case having the Richmond, Virginia as the standardized placename might affect my searches for events that took place in Richmond, Surrey, England, I nearly always carry out searches by just entering "Richmond", followed by a wildcard, in the "Place" field. That way, my search picks-up an event (i.e., produces a result) even if it has been standardized to a location thousands of miles away!
Without wishing to stray too far off-topic, I also find the practice of not entering the full placename useful in cases where search results might be otherwise hidden due to the autostandardization exercise. (I find wildcards work great, and only wish FamilySearch would mention the option on the Search page.)
0 -
(I find wildcards work great, and only wish FamilySearch would mention the option on the Search page.)
@Paul W To continue straying a bit ... The search tips document found on the search historical records page does include instructions for using wildcards (the link is kind of hidden in the graphic).
1 -
Indicate whether or not a date or place is standardized without clicking on each one first.
1 -
The person page does show whether or not dates and places are standardized.
3 -
@Gordon Collett That response is kind of pedantic. People are using 'standardized' to mean both standardized at all to any location and standardized accurately to the location that matches the user-facing text. Even if this benefits you personally, it clearly concerns enough users to generate multiple threads about it.
0 -
Thanks, I try to do my best here.
A problem with online conversations is the lack of immediate feedback and the lack of all the other components of communication such as body language, hands on demonstration, and the ability to make sure two people are using words in the same way. Pedantry and nitpicking in such forums is the difference between an angel food cake that is 1/2 inch tall with the density of a brick and a proper dessert.
I do approach these questions about "standardization" with a bit of trepidation because of the vagueness of the English language and the non-standard meaning computer programmers often use and realize that people could be meaning several different things in these pleas to have the map pin back:
1) "I want an easy way to see if a correct place name is linked to a 'standard' or not." - This is already present and is the function of the presence or absence of the red textual message. The map pin never had anything to do with this. This function previously involved the red exclamation point.
2) "I want an easy way to see if a correct place name is linked to an appropriate 'standard' or not." - Correcting or improving the linked standard is an important aspect of proof-reading data in Family Tree. The map pin would indicate if the correct place name was identical to the "standard" but its absence never meant the correct place name was wrong.
3) "I want an easy way to know if I need to remove a correct place name and replace it with an inferior 'standard.'" - This was never the intent of the map pin but the map pin seems to have encouraged this misguided mindset. Unfortunately most people asking for the return of the map pin seem to be requesting this data corruption feature.
As long as people keep asking for a hammer to wash their windows, I'll continue to try to teach as clearly as possible that a soft cloth works better.
3 -
Attached
Attached is an additional example
0 -
I believe you may be caught between expectations of what the Places database does versus the technological potential for what it could do.
You selected your prior posts as Answers (above) - so all that follows is related to your Answer post (above/now duplicated below - except the part at the end):
Redenhall Parish, Harleston, Norfolk, England
which is showing on profile LZ8B-LBR as standardized to United Kingdom (which is obviously incorrect as United Kingdom did not exist prior to 1801).
Response:
The reason this is occurring is that the place was 'standardized' to the United Kingdom (1801-Today) - because that is the only timeframe for the place listed in the FamilySearch Places Database. (the database is incomplete and will remain so until users or FamilySearch Places team get to it or change how places are implemented).
To correct this: Someone in the know about this place will need to Improve this Place (at that link) to include ...-1801 - where the place could be standardized to England
OR
as you mention, FamilySearch could see that attached Sources are prior to that places entry timeframe and thereby automate you submitting that source as documentation for ...-1801 existence of the place and thereby automate creation of that ...-1801 place entry Or automate by some other means the timeframe prior to 1801.
As the entry currently stands - it may be the correct place (with today's standardized reference) but not the correct sourced record timeframe and won't change until someone improves the place entry or FamilySearch chooses to implement places attached to sources differently.
Incidentally the tagged source for LZ8B-LBR birth does not reference the page/record indicating his birth - only the entire book or wikitree. I don't know whether you can change the URLs to reference his sources more directly.
Related to Fan Chart image of Fuller family Birthplaces showing standardized as England up to LZ8B-LBR (discussed above):
Without investigating the other Fuller family profiles that do show England as location in Fan Chart: Birthplace selected - I can only assume those places are correctly linked to the database timeframes for England - not United Kingdom.
Thus this particular standardization issue involves users understanding a bit about how places are implemented in the Places Database and how corrections can be made (manually Improve This Place) OR FamilySearch deciding to change how places are implemented/automated (the potential for how places could be entered in the future).
0 -
All,
Here is a simple example.
"England"
No non-standarized label will appear but the value the system reads is "England, United Kingdom". The problem is there was no United Kingdom prior to 1801.
The system then is looking for data after the 1800 date for persons who existed in the 1300, 1400, 1500, 1600 and 1700 hundreds. No data will be found.
I have found hundreds of examples where this has occurred. Once the location and date are "Standardized" for the system to read, more information is found for verification and support.
I have attached an example you can look at. Matthew Fuller LZ8B-LBR, the birth location shows England, but the system is seeing United Kingdom. The easiest way to check this is to go to tree fan view birth location. It will show him being born in the United Kingdom in 1610, which is of course wrong.
Let me know if anyone understands this.
Thanks
Ken
1 -
No non-standarized label will appear but the value the system reads is "England, United Kingdom". The problem is there was no United Kingdom prior to 1801.
The system then is looking for data after the 1800 date for persons who existed in the 1300, 1400, 1500, 1600 and 1700 hundreds. No data will be found.
As far as I am aware and as far as I have ever seen, the hinting system looks for additional hints based on the date for vital events and the underlying location represented by the various standard forms. From my experience, the hinting routine does not care about the time periods associated with the various historical place names. As far as the routine is concerned, England and England, United Kingdom, would be the same.
When looking at hints, don't be deceived by an optical illusion. According to Ron Tanner in a presentation about two years ago, and assuming the hint engine works about the same, the hint engine works two different ways.
First, it is given new historical collections to gradually work through and takes those records and tries to find people the record might be for. This is why you will find new hints on a person's page when you first come to it and how you get new tasks on the various task lists.
Second, when the hint engine receives notification that a user is working on a particular profile, the hint engine takes the profile and goes to work finding all the hints for that profile it can. The notification that triggers find hints for that one person is basically any kind of editing such as editing the person's name, adding a piece of vital information, adding something to the other information section, and, yes, updating a linked standard.
If you changed a linked standard from England to England, United Kingdom or vice versa then saw a bunch of new hints appear, it was not really because of the change in the linked standard. It was because you told the program, "I'm working on this person" and the hint engine went to work.
Again, this is based on information from one of Ron Tanner's live Q&A sessions. If someone at FamilySearch has information that the hint engine is working differently now than it was then, I'l love to hear about it and be corrected if I am wrong.
2 -
"Matthew Fuller LZ8B-LBR, the birth location shows England, but the system is seeing United Kingdom. The easiest way to check this is to go to tree fan view birth location. It will show him being born in the United Kingdom in 1610, which is of course wrong."
I understand the example perfectly. However, what definition are you using for "standardised"? The fact is that it is standardised because the Display Place of "Redenhall Parish, Harleston, Norfolk, England" is linked to the Standardised Place of "Harelston, Norfolk, England, United Kingdom". The fact that the link is date-inappropriate is another matter. Therefore the entry shows as "standardised" because it is not "not standardised". Nobody says anything about the standardisation being correct - the software cannot tell because (a) nobody's written date-matching into the recipe and (b) nothing(?) exists about the relationship between Redenhall and Harleston (that's the spelling in my enormous Atlas).
This may sound pedantry but unless and until people understand the difference between standardising (as in linking to a place) and standardising correctly, we're not going to get very far because the computer only does one thing.
Let me be clear - it is hugely important to me to get stuff time-appropriate. I would dearly love the standarisation process to check the date and suggest the correct entry datewise.
However, if we did that, the result would be an even bigger carve-up than we have now. For every use of "England, United Kingdom" prior to 1801, we have at least as many (Department of Unreliable Statistics here) uses of "England" (only) after 1801.
And, we would need many more entries that we have now if we start getting date accurate. For instance, it seems to have escaped FS's knowledge that England, Wales and Scotland were part of Great Britain between 1707 and 1801, or that Ireland was part of the United Kingdom from 1801 to 1922 (I wonder why that isn't in the database...?)
0 -
My definition is when the system places the "Location Icon" beside the location.
See attached in the red circle.
0 -
My definition is when the system places the "Location Icon" beside the location.
Yes, that is as I and Adrian explain above. The map pin location is 'standardized' - but not standardized correctly - because the database is incomplete and not corrected to that level - yet. But you can certainly Suggest> Improve This Place for Redenhall/Harleston for that timeframe and then attach that new standard. But also as Gordon mentions England and England, United Kingdom are the same place to the database.
0 -
No, the this database system see "England" and "England, United Kingdom" as two different places. And the system indicates that difference on the "tree fan place of birth screen".
See attached.
0 -
...database system see "England" and "England, United Kingdom" as two different places.
Yes, but not for "Harleston, Norfolk, England" before 1801. That is the whole point of your question.
Are you saying those other ancestors were born in Harleston?
Aha! I do see his father Edward shows:
" Redenhall with Harleston, Norfolk, England "
IS 'standardized'!
If you change Matthew's standardized birthplace to:
"Redenhall with Harleston, Norfolk, England" (instead of Harleston ... )
you WILL get England - as you wish.
Again - this just shows the trickiness behind 'standardizing' (you need to enter the exact place you want/need).
This also does point out the need to link the two places - Redenhall with Harleston and Harleston - apparently - at least for the timeframe... So someone familiar with these places should submit corrections as needed. It really would be nice if this thread could just be submitted and someone on the Places team take care of it.
0 -
I'm finding it hard to follow this discussion, with stuff yanked out of order by the forum software, but there's one aspect that I can address: I can say with absolute certainty that the hinting algorithm doesn't care about time periods or changing jurisdictions. Good thing, too, given that the vast majority of FamilySearch's indexed records database uses the current names for places, not the name at the time of the event.
To put it another way... Ken wrote:
"the value the system reads is "England, United Kingdom". The problem is there was no United Kingdom prior to 1801."
From the system's point of view, this problem doesn't exist. "England, United Kingdom" points to exactly the same place as "England", and no part of the system looks at the associated time period. (This is another good thing, given how incomplete those time periods can be in the Places database.)
The shouting in Matthew Fuller's birth reason makes no sense: the entry already is standardized, correctly. I don't know the history of England's ecclesiastic jurisdictions, but if circa 1610, Redenhall parish fell under Harelston's aegis, then this is one of the ways to capture that information in Family Tree. The other way is to choose Redenhall as the standard and then add Harelston to the name.
The likely reason it wasn't done this way is that it can't be done in a single step; even knowing that it could be done, it took me a few tries.
0 -
Yes, but due to the selected standard (someone selected Harleston, Norfolk, England, United Kingdom 1801-TODAY) - there IS NOT currently any other option for entry of Harleston, Norfolk, England...
So, this whole standardization problem - yes - started when someone selected (incorrectly) that 'standard'.
Which goes back to place 'standardization'. Specifically, if you want to enter
Redenhall Parish, Harleston, Norfolk, England
- you can currently select
"Redenhall with Harleston, Norfolk, England" (as I mention above) OR "Redenhall, Norfolk, England" (as you just mentioned)
- either will allow you entry of "Redenhall Parish, Harleston, Norfolk, England" as freeform entry (with slightly different 'standards' - which as far as I can tell both mean the same place. Which means someone needs to correct both AND probably Harleston as well.)
0 -
Icons on the details screen (as they use to be), would make standardizing easier.
That is my only point.
0 -
@KenWarren The 'standardization' icons are on the Details> Edit view - and even in this specific case if displayed on Details - would not have resolved your issue of seeing Harleston, Norfolk, England, United Kingdom NOT Harleston, Norfolk, England (and that specific issue won't be resolved until Suggested> Improve This Place). You would have had no idea from the map pin displaying on Details tab that the 'standardized' location was incorrect. Only the Fan Chart> Birthplace view would have clued you in on the incorrect 'standardized place' being applied.
0 -
No, the this database system see "England" and "England, United Kingdom" as two different places. And the system indicates that difference on the "tree fan place of birth screen".
The system actually just sees England and England, United Kingdom as two different labels for the same place. The fan chart just happens to give the two different labels two different colors. In all important routines they are treated as the same.
0
