Why isn't policy of requiring standard dates and places revoked?
The stubborn policy in FamilySearch Family Tree of insisting of requiring standard dates (when there is actually no date shown in the record forces errors in documentation and disallows correction of that error) should be changed. This is true when a child's birth record is shown in christening records, but the baptism was not performed for one reason or another, yet the indexer supplies an incorrect date. The error becomes incorrectable in FamilySearch!
Similarly, when a death date is missing from a record, but indexer adds a date that is not shown in that record, and possibly a burial date is shown, (or vice-versa), when an attempt is made to note that date is wrong, it cannot be corrected by leaving a blank date. See where one of the church books lacks death date for Edvard Martinussen KZFG-YFB.
I submit that enforcing of standard dates and in cases where such exceptions is self-defeating both to the intent of the policy of allowing corrections to the database, but also to the users that attempt to make such corrections, but cannot do so because the forcing of a limited type of correction interferes with proper designations (such as no date shown).
There are also cases where incorrect places cannot be corrected.
I also submit that enforcing of standard places and in cases where such exceptions is self-defeating both to the intent of the policy of allowing corrections to the database, but also to the users that attempt to make such corrections, but cannot do so because the forcing of a limited type of correction interferes with current standard designations (such as the lack of a placename within the standard).
W. A. Levorsen
Answers
-
Dear M. Levorsen,
Your post includes so it hard tro4r me o evaluate your interpretation the records you've attached to the record for Edvard Martinussen KZFG-YFB.
FamilySearch does not require an exact date for any event. The following Knowledge Article found in the FamilySearch Help center seems to answer your question:
I do not know the exact date to put in Family Tree
If you do not know the exact date, you can leave it within the day or time of year based on other information.
Incomplete dates
If you do not know an exact date, you can enter incomplete dates like this:
- 1988
- August 1988
Calculated or estimated date
If you don’t know a date, maybe you can calculate one. For example, you can calculate a birth date based on the person's recorded age at the time of an event. So if an 1860 census lists a person as two years old, you can calculate the birth year as 1858. In Family Tree, you can enter the calculated date in one of these ways:
- 1858
- Calculated 1858
Death dates
You can also estimate the year of an event based on other information. In Family Tree, you can enter one of the following words with the estimated year:
- Before
- After
- About
Following are examples of how you can estimate a date.
- You have information that an ancestor died during World War I. The death date could be approximated as About 1914 (the starting date of the war; you could also list another year of the war if you knew the person died toward the middle or end of the war).
- You have information that an ancestor died just prior to the start of World War I. The death date could be approximated as Before 1914.
- You have a marriage date but not a birth date. You can approximate birth years from the year of marriage. The general assumption used for such instances is that a man married at age 25 and a woman at age 21. Thus, if you have a marriage date of 1875, you can list the husband’s birth date as About 1850 and the wife’s birth date as About 1854. (These are general rules and vary slightly based on culture, time frame, or country.)
- You know a marriage date but not the birth dates of the couple’s children. You can use an approximate year for the birth of those children. Estimate birth of the first child as one year after the parents’ marriage and that subsequent children were born every two years after that. For example, if a couple married in 1800 and had two children, the first child’s approximated year of birth would be About 1801 and the second child’s approximated year of birth would be about 1803.
- You can use family knowledge or tradition as sources for dates. For example, if family tradition says that an ancestor was 16 years old when she married in 1876, you can approximate the birth year as About 1860.
Date ranges
You know that an event occurred within a specific time period. In this case, enter the earliest date and the latest date, as in this example: From 1860 to 1870.
No death date
You know the person is deceased but do not know the exact date of death. Click the Deceased option and either leave the date field blank or enter an estimated year.
If the individual shows a death date and you try to delete it, a save failed error can occur. Use one of the formats for an estimated date instead.
Estimated and partial dates affect the birth order of children
- The standardized dates determine the order of children or multiple spouses in Family Tree.
- If you use an estimated or partial date for a child or spouse, they can appear out of order. See Related Articles for more information.
If you attach an indexed record to person in Family Tree. You can still change the event dates (Birth, etc) to reflect the correct date or absence of a date. You can also correct indexing errors as follows:
---------------------------------------------------------------------------------------------------------------------------------------------------
How do I correct indexing errors in historical records?
You can edit incorrectly indexed names, dates, and places on some record collections. Editable fields can vary based on the location and language of the user, and any restrictions associated with the collection.
When you submit corrections, please follow these guidelines:
- Do not use this feature to add name variations, nicknames, or aliases. Instead, use the Other Information section of an ancestor's person page for name variations.
- Enter the information as you see it on the image. For example, if the image contains initials, enter the initials.
- If information on the image is incorrect (a name that you know is misspelled, for example), you can correct it. For your reason statement, be sure to select Wrong in the Document.
Steps (website or mobile)
- Find the incorrectly indexed record.
- Display the indexed content (not the image).
- In the dark banner at the top, click Edit or Make a New Edit.
- To the right of the field you want to edit, click Edit.
- Make your correction:
- In the corresponding fields, enter the correct data.
- Select a reason for the change.
- (Optional) Enter a note to explain your change.
- On the image, click and drag to create a box over the changed information. The box helps make it clear which portion of the document you corrected.
- In some records, after you edit a surname, you can apply the change to all members of the household.
- Click Save.
Results
- The correction shows on the details page right away. In most cases, corrections are searchable within a few minutes, though the process can take longer depending on the current load on our system.
- For name corrections, after you make the correction, both the incorrect name and the corrected name appear in future search results.
- Only the corrected date or place appears in future search results.
Tips
- To edit or delete a correction you made, click the Edit icon.
- If you used the record to add a person to Family Tree, check the name in Family Tree, and make corrections as needed.
- After you make the correction, you can also attach the document to the record of your ancestor in Family Tree.
- Consider keeping a personal list of any indexing errors that you cannot fix. You can correct them later when more correction options become available. Thank you for your patience as we work to resolve this challenge.
-----------------------------------------------------------------------------------------------------------------------------------------------------
You can suggest a change to correct place names as follows:
How do I suggest a new place to FamilySearch Places?
You can suggest that we add a place to the FamilySearch database of standardized places.
Places have a connection with a life event. A standardized place has a specific format. Standardized places makes searching easier.
Before you start
A place in FamilySearch is a location with value to the entire community. The address of a person’s home, for example, is too specific for standardization.
Every new place requires a parent place. The parent place is the next larger geographic boundary. For example, the parent place for Manhattan is New York City.
Steps (website)
- Go to FamilySearch Places and sign in.
- In the top left, click + Suggest a New Place.
- Click a place category. To learn more about a category, click the circle next to the category. A definition appears.
- Click Next.
- Enter the name of the new place.
- In the next field, enter the Parent Place. A parent place is the next larger geographic boundary that includes the place.
- You see place-type hints for the parent. You are not limited to the suggestions.
- Click a standardized option.
- Verify that the Language field reflects the language of the name that you are suggested, rather than the native language of the place.
- Click Next.
- To help reduce duplicate suggestions, FamilySearch checks to see if the place already exists in our database. If you see the place in the search results, click Select. No further action is necessary.
- Click Create Place.
- (Optional) Add the geographic Location and the Source Web Address (URL). A place without this information cannot be a parent place to other places.
- Add Additional Information to add value to the place and the suggestion.
- Click Submit.
Acknowledgement of the submission is not available. We will begin email acknowledgement in the future. When available, you will be able to reply directly to the internal team should you have questions or have feedback.
I hope this information answers your concerns.
Elder Gary Kearl, Family Tree Support
0 -
@Gary Kearl2, the question is talking about index corrections, where FS _does_, in fact, require a standard. You cannot correct place or date fields to what the image actually says: if you try to make any changes to a place or date field, the correction cannot be saved unless the entered text is identical to a standards-database entry.
Here's my post on the same topic, though only addressing place fields: https://community.familysearch.org/en/discussion/125577/please-allow-transcription-corrections-in-indexed-placenames#latest
The system's insistence on a database value without a place to just enter the text that is there (or not there!) means that we cannot improve the database of indexed records, despite our best intentions.
1 -
There may be a work around. One of my recent ancestors was cremated but not buried. His ashes are in a son's home. When a burial record was added to that ancestor's vital information, I deleted it and added a custom event in Other Information called "In lieu of Burial." I was not prompted to add a date. For the "reason this info is correct" I put the following: "He is not buried. Please do not try to add a burial date. His remains are with one of his children." I just checked and so far no one has changed anything.
0 -
Please refer to the Knowledge Article I sent you on how to submit a change to a place name.
0 -
Regardless of whether you have missed the point of the poster's question, I do not agree at all with some of the general advice being offered here.
In particular, I believe birth dates should never be estimated on the basis of the year of marriage. Other users doing exactly what you suggest has led to me being thrown completely off-track in a search for some of my relatives' baptisms. The birth being marked as, say, twenty five years before the marriage is of no help at all to a researcher. As you must have experienced, our relatives married anything between the ages of 16 and 65 (sometimes older) so, no, I don't want a "hint" that I should be looking for a birth within a short time period, if there is absolutely no evidence for such a conclusion.
As Julia suggests, the point raised here does appear to relate to the indexing process, not what needs to happen following that. Not being an indexer, I did find the comments difficult to understand myself. If in doubt, I believe it best not to respond to issues where I might be end up applying a lot of effort in explaining solutions for another problem altogether.
0 -
I believe birth dates should never be estimated on the basis of the year of marriage.
I agree.
0 -
@Gary Kearl2, again, a correction to the places database is _not the issue_ being raised here.
It is not an indexing issue, either.
The problem is with the index-correction feature on FS. You know, the one introduced a few years ago whereby some fields of some published indexes can be corrected by FS's users?
As an illustration, I randomly found an Ellis Island manifest with a misread "Residence Place" field: https://www.familysearch.org/ark:/61903/1:1:JFKT-4ZG
The indexed text is "Felverpatak", where the "lv" is a misreading of an "h": the correct placename is Fehérpatak ("white creek"). There are two candidates with this name: a village in Vas county (which is now Tauchen, part of the municipality of Mariasdorf in Burgenland, Austria), and an outlying settlement belonging to Rózsahegy in Liptó county (now Biely Potok, Slovakia). Ideally, I just want to change the "lv" to "h" and call it good, because there's nothing on the manifest to make one place more likely than the other. But I can't do that. If I try to just choose the entered text rather than the proffered places database entry, it highlights the offending entry in angry red and pink and will not save.
Just to add insult to injury, the standards only have the place in Liptó county.
This means that this index entry really cannot be corrected. Any attempt at changing the nonsensical "Felverpatak" to what it actually says on the manifest will result in either possibly-wrong information or a loss of information.
4 -
What @Julia Szent-Györgyi said. This constraint of only entering a standard place name is really maddening, because so many place names are not yet in the Places gazetteer.
What would be neat is if this field worked like other place fields: enter text and have the option of selecting a standard place name.
That would be a feature request to send the engineers.
0 -
As seems to be the case more often recently, I have again missed the main point of the discussion! Following my suggestion to Gary, I will certainly not be adding further comments to this thread - especially as I never have cause to use the index-correction feature, as so few of the sources I add are accompanied by images, or - if so -rarely contain errors, when they do.
0 -
Julia Szent-Györgyi You made a pretty brilliant point. I have experienced this in a limited amount but never thought through the problems it creates. I've always just caved in and excepted the location suggested in the edit, except for one VERY WRONG correction in a marriage record that was needed and I reported it. What I hate is corrections that CAN be made and accepted that are clearly wrong, done by someone so that the location can be standardized. People born in the UK in the 1400s. People born in the USA in the 1600s. Ugh. THOSE are place names that should be restricted to appropriate dates.
0 -
It is interesting to me to note a sample selection of a Hungarian placenames in Slovakia. Several years ago, I was working with a Paul Smith, who had married a Slovakian girl of Slovak nobility heritage, including the Fehérpataky/ Fejérpataky family, a modern family who had lived in Pennsylvania. I am looking for the place where many of the historic Fejérpataky lived, such as in Kellecsény, Liptó, Hungary. Standard names of areas later dismembered from modern Hungary are not so easily found in FamilySearch standard placenames.
(This is posted as a matter of related interest to Hungarian/Slovakian researchers.)
0 -
The main point of my initial comment was the results of the policy related with the maddening statement in red which fails to accept corrections as they should be corrected, including the deletion of erroneous dates and/or the failure to provide methods of correction that make the most sense. My point is also that this policy of forced limited responses can also produce errors related to patron frustrations or insufficient level of technical geographic or historical education.
0 -
There's a somewhat subtle point here that I think most of us miss the first few times through: requiring a standard means that ambiguous entries would not be correctable even if the standards database were 100% complete and correct.
That is, even if both Fehérpataks were in the database, each of them would have a 50% chance of being the wrong one for that passenger.
Neither indexers nor would-be index correctors should need to do detailed genealogical research on individuals in order to produce an accurate index. And yet, that is what FS is requiring by making a choice of standard mandatory.
1 -
That is, even if both Fehérpataks were in the database, each of them would have a 50% chance of being the wrong one for that passenger.
Exactly. Even in the end stage on Family Tree I often must leave place names not standardized, or at a higher level jurisdiction, with a note such as "Suchavary, Hungary, but which one?"
0 -
FamilySearch might borrow from Wikipedia the use of disambiguation pages. The end goal is to have all links go to the correct page, but when an editor cannot tell which page is correct, they can as a fallback link to the disambiguation page. Later, editors who like this activity will go through all the links and sort out where they should go. Often, the process involves adding more pages to the disambiguation page.
FamilySearch Research wiki has a mere 151 pages in its disambiguation pages category: https://www.familysearch.org/en/wiki/Category:Disambiguation_pages
FamilySearch Places gazetteer could also have disambiguation place names, so that an indexer (robot or human) could select, say, Fehérpataks (ambiguous), Hungary when the context does not reveal which Fehérpataks.
1 -
Oh, and if place name disambiguation standards were acceptable in the Places gazetteer, then it would also be helpful to fast-track requests for them. So, someone realizing there are multiple places named Fehérpataks but only one is in the gazetteer could quickly create the standard to hold all those historical records mentioning Fehérpataks ambiguously, pending future disambiguation after the careful research work has been done to add the other Fehérpataks to the gazetteer.
1
