The fundamental flaw of the website
The problem: Person profile does not display up to date indexed information of the attached sources.
It only displays the indexed information of when the source was attached. Specifically, it does not display any information that was indexed after the record was attached. This flaw can be seen in the sources of the vital information in the Vitals section of the Details tab. And in the indexed information in the Sources tab.
Fundamentally, I believe that the profile freezes the information of the record when it is attached, which is very stupid.
Specific example: A birth record is attached without having first indexed the date of birth. If we index the date of birth after attaching the birth record, it will not be displayed as a source in the Birth field in the Vitals section of the Details tab of the person’s profile.
Correct behavior: Person profile should always display up to date indexed information from attached sources. In every place, including Sources tab and Vital section of Details tab.
Specific example with correct behavior: A birth record is attached without having first indexed the date of birth. If we index the date of birth after attaching the birth record, it should now be automatically displayed as a source for the Birth field in the Vitals section of the Details tab of the person’s profile.
This problem indicates a major flaw in the design of the logical architecture of the system. The indexed information of attached sources should, of course, always be up to date in the person’s profile, not frozen when attached.
In lower level language: there should not be a frozen copy of the indexed information of an attached record. The profile should always consult the attached sources current indexed information.
For me, this is the greatest flaw of the website and the one that most reduces the efficiency of the work that is done by users.
In this collaborative platform it makes sense to expect a constant increase in the quantity and quality of indexed information of already attached records. But this new information does not reach people's profiles, which can prevent the discovery of new important information and people and reduces the completeness of information in profiles.
This problem causes another: it strongly discourages users from collaborating by improving the indexed information of records that are already attached to people.
Why add or enhance indexed information of unrelated people if it won't even appear or be updated on the person's profile?
Currently, you cannot trust what the profile displays, as it does not show anywhere the potential additional information indexed after the records were attached.
Possible workaround (not tested): detach and attach the record again. I have not tested it because it is very inefficient and stupid that it has to be done in order to have the correct up to date indexed information in a person’s profile.
This is such a fundamental problem, that if solved, I believe the efficiency of the collaborative work done on the site will be greatly increased.
Answers
-
The details that appear in the Vitals section of a profile have generally been added in one of two ways: either by a user's manual input, or by being carried across to a previously blank field during the source linking process. When adding a further source, it is up to the user to check the accuracy of the data it contains and use their judgement as to whether to leave the original input as it stands (say in the Vitals section of the Details page) or to manually update with the fresh information. The only item that can be effectively overwritten whilst linking a source relates to the Marriage event - when multiple sets of data can be carried across, but only the source containing the earliest date will find its way to the Details page.
I really do not understand the point you are trying to make. It is up to the individual user to confirm what detail is correct and thus appears on the Details page. Some sources will contain more precise detail than others and some will have conflicting information. This difference in detail can be down to an indexing error (remember, there are often even multiple indexing projects relating to the same event) or where, say, two sources contain a different date of birth based on an original document. For example, if a census document shows a date of birth as one thing and elsewhere the DOB is recorded differently, why would you expect the program to be able to make a judgement on which is placed on the Details page?
Reading your comments in detail, you seem to be assuming any "up to date" indexed record will contain more accurate detail than previous sources. I also get the impression that you believe a newly indexed record acts / should act as a replacement for any previously indexed version. This is not usually the case (except perhaps where FamilySearch has added records from another provider (e.g. Find My Past) to its database. There are many examples of records that have been subject to multiple indexing and each retain their separate identity (URL) so their content can be judged on a one-by-one basis, rather than believing the most recent effort necessarily contains the more accurate detail, as you seem to be implying.
In summary, it is Family Tree patrons that need to be collaborating to ensure that trustworthy data is found on the Details page. You ask: Why add or enhance indexed information of unrelated people if it won't even appear or be updated on the person's profile? The simple answer is that more recently added / indexed records might not be as reliable as their older counterparts, but they are still worthy of examination, as they possibly will contain the correct data. Changes (on the Details page) are for researchers to decide upon, so should surely not be subject to amendment by some piece of FamilySearch programming.
6 -
I would sort of agree with this if we could trust either the metadata or the mapping of a source to a profile well enough to automate tagging based on it, but I would question that. A lot of collections' metadata can't be edited anyway, plus collections vanish from FS over time. And a lot of attached birth sources actually belong to the person's children ...
Community members have had bad experiences with previous automated updates.
What would perhaps help would be to allow people to watch records as we can profiles, and/or to improve the UI to make the sources less file-and-forget (especially relationship ones).
Honestly though, records often contain very little information to start with (early US censuses are a good example), and the structure of the metadata for a particular collection is not always optimal, however well or badly indexers populate it.
P.S. this crossed with Paul's more detailed comment, with which I would concur.
2 -
I admit to not having finished reading, but you appear to be basing your argument on flawed premises/foundations: you're trying to treat the finding aid as the data.
The index is not the data. It is merely a means of making it easier to find the data.
Yes, it would be nice if the computer could take over some of the more tedious parts of data entry and management, but where do you draw the line between helpfulness and overhelpfulness? Do you really want the computer overwriting your carefully-written source title, just because someone edited the index entry that it's connected to? If you tediously paged through a hundred images to find the not-yet-indexed event and then carefully transcribed and translated it in the source citation that you created, do you really, truly want your work overwritten by an indexer's misreadings of some small portion of that data?
When you attach an index entry as a source using Source Linker, the tool generates a title based on what's in the index at the time. That part of the attached source is static: it only changes if a user edits it. Ditto for the source tagging: whatever Source Linker (in its infinite wisdom) deigns to tag is what that source will be tagged with/to, unless a user changes it. The rest of the source entry, however, is dynamic: the system looks it up in the indexed records database each time, and generates a new summary. (I don't know which category the citation box falls into, as it's always so useless that I don't even bother looking at it any more. I do know that in Linker-generated sources, the citation is not user-editable.) In other words, if someone braves the gremlins in the index editor and fixes the name in the index, the title of the already-created attachment will not change, but the summary will. (See for example the 1878 source here: https://www.familysearch.org/tree/person/sources/GTN1-K7C.)
Better user control of Source Linker and of the image viewers' source-creation functions (such as full tagging control and access to the Notes/Description field) would unquestionably be a Good Thing, but it emphatically should not come at the cost of setting indexes on an even higher pedestal than they are now.
6 -
Yes, there are many instances where the indexed data is incorrect when compared to the paper source, and might therefore be corrected later on. But there are also many instances where the paper source can be deduced to be incorrect when compared to reality.
To take a typical example - if I have a birth certificate with one exact date and a 1939 Register (for England & Wales) for the same person, that has a different exact birth date, the two index records will have different values. How does the automatic process handle that? It can't - it has to be down to the researcher to decide which is correct. Normally people will guess that the one nearest the actual date will be correct - but this is a statistical guess, not guaranteed to be correct. My own grandfather is such a case - his birth certificate has a date that doesn't match later sources - the suggestion is that his birth was registered outside the elapsed time limit and therefore was adjusted to bring it back inside the limit.
The point at which research has to take place is on the profile, not on the indexes, which may exactly match the paper, but not each other.
4