New Feature Idea: Linking residence and occupation to the applicable date.
This is a problem inherited from the previous linker, whereby it would take residence and occupation that were part of census data and attach them without including the date. It was not possible to follow the timeline.
Can the new linker be made to attach the date to these items so that the timeline is correctly presented?
コメント
-
This is another manifestation of the same "half event" frustration as I've posted about. If Source Linker stopped its Smarter Than Thou behavior and allowed the creation and editing of full conclusions — that is, if all additions were at the user's discretion rather than the machine's — then the "undated residences" problem would be just one of many to go away.
4 -
Would be most grateful for an update on whether this has been passed to the team to work on.
Plenty of examples, but here's just one:
How helpful it would be if that 1911 date could be added to not just the Residence, but Occupation and Marital Status items, too. It would save a lot of time entering the dates manually once "back" on the Details page. For example, I have some pages where, over the years, other users have added occupations without adding a date, so I then have to investigate what year is recorded for the change of occupation, say, from Miner to Insurance Agent (yes, one of my ancestors did just that) instead of (in the future, at least) helpfully having the date being carried over by the new source linker.
3 -
Paul W
Here is the update on source linker adding the Events: Custom Event (Birth Registration, Marital Status, Death Registration) and Residence and Occupation.
While it would be great to pull a date for an occupation or a residence, in many cases the record does not record a date as such. The Chief Genealogical Officer has reviewed the suggestion, and at the current time has determined that we should not assume a date for events where the record does not contain that information. You are allowed to edit the Custom Event, Residence and Occupation fields and add a date, but Source Linker will not be suggesting a date unless it is in the record, specifically pointing to the Event.0 -
@ScottSeegmiller said
"… While it would be great to pull a date for an occupation or a residence, in many cases the record does not record a date as such. The Chief Genealogical Officer has reviewed the suggestion, and at the current time has determined that we should not assume a date for events where the record does not contain that information. …"
I totally agree that the system "should not assume a date for events where the record does not contain that information." However, so far as I can see, the instances quoted above are about censuses. Occupations and residences listed on censuses are those current at the date of the censuses, i.e. the record does contain the date information.
What am I missing?
There are all sorts of other records where residences and occupations are quoted without a date being explicit or implied - I'm thinking, e.g. obituaries, where the obit might say "former steelworker from Springfield" and the deceased has been retired for years and moved across the country as well. I am assuming - bad habit - that Source Linker or the indexer or whatever can handle such cases separately.
1 -
@ScottSeegmiller, let's be a bit more precise: if the index doesn't explicitly label a date as belonging with a residence or occupation, then Source Linker will not offer that date to go with the residence or occupation. This is significantly different from the record not containing that information — and preventing the user from entering it is a serious flaw in both the workflow and the thinking behind it.
The problem is pretty fundamental: Source Linker treats indexes as Gospel — and it belongs to a particularly literalist sect. If the index doesn't contain exactly that data labeled exactly that way, then it doesn't exist, from Source Linker's point of view.
The problem is, indexes aren't complete transcriptions. They're not meant to be complete transcriptions. That is not their purpose. Their purpose is to help us find records.
So what is the purpose of Source Linker, exactly? Is it only and strictly for attaching the finding aid? Is it purposely constraining us to citing the card catalog in our bibliography, instead of the actual book?
The addition of the edit pencils to the new Source Linker implies to me that the answer to the preceding paragraph is "no". This is good, but unfortunately, it appears that it's only a qualified "no": Source Linker will now allow us to at least visit the right bookshelf under some conditions, but our bibliography contents are still being constrained by the contents of the card catalog.
There are lots of things in historical records that aren't in the indexes of said records. A well-designed sourcing tool would not only allow the addition of that information to the Tree, it would assist with such transfers, by giving users full visibility into both the record and the profile, and allowing them full control of editing and tagging.
1 -
As has already been pointed out, with census records (I should have made it clearer these are the primary subject of my comments) there is no ambiguity at all about the occupation and marital status applying to that date / year. Just as the census source rightfully does link the year to the individual's residence at the time, there should be no difference with labelling the other information with the same date.
Sadly, the Chief Genealogical Officer does not appear to have thought the matter through, by saying
"…we should not assume a date for events where the record does not contain that information"
because census records do exactly that!
So where you state
" …but Source Linker will not be suggesting a date unless it is in the record, specifically pointing to the Event"
are we to assume the situation will now be reconsidered in relation to census sources, where these "custom events" really do have a connected date?
At present, the lack of a carried-over date makes the Marital Status information particularly pointless, viewed from the Details page. It surely can't be impossible for me to be advised that at the time of the 1871 census an individual was Single, in 1881 be was Married, by 1891 he was Widowed and by 1901 Married again?
Sorry if I am "over stressing" the point, but as these are clearly dated facts, why not treat them in the same way as where the person's Residence was in 1871, 1881, etc.?
1 -
@Paul W said
"… the lack of a carried-over date makes the Marital Status information particularly pointless …"
I have seen the world's most pointless data item - an undated Marital Status of "Unmarried". I suspect that this applies to most of us at birth…
I have also deleted an undated Marital Status of "Married" many times when the person has a spouse and there is a marriage date on their relationship. Again, it's pointless.
These are not the fault of the Source Linker software but it suggests that the researcher adding that data hasn't thought the implications through. (Thinking things through isn't always obvious suggesting a need for training rather than software perhaps?)
1 -
Personally, unless I feel I have the time to add dates to all these marital status events, I think it best for me to simply not carry these items across. I notice that, for certain items, (must look at this more closely) an exactly worded item cannot be carried across, in any case. (e.g., if I already have "Shoemaker" as an occupation under Other Information, it won't carry that across again (though just a slight variant, even typo, on the occupation would go across, of course). The one I need particularly to check out is where I can move a Birth Date across, when I believe one already appears under Vitals. Another confusing item (as you know) is regarding a Death. For England (& Wales), half the Death Registrations now appear to be indexed as just that (i.e., Other Information item) and the other half as Deaths (Vitals item). So, just as in the past, when Baptisms and Christenings were treated differently (the former treated as Custom Event and the latter as a Vital), we currently have different treatment of records which are for the exact same event - a death registration!
There have been a lot of genuinely enhanced features with the introduction of the NSL (including the ability to edit certain items during the process), but I believe there remain many flaws - particularly when it comes to Marriage events, where multiple events can be carried across (though, again, as long as they are not identical to one that has already been added to the individual / couple on their profile pages).
0 -
Apologies for bringing up the competition - but Ancestry.com really does handle this in a superior way. Not only is a dated residence added, but a note is attached to it with, as I recall, the relationship to the head of family, their marital status then, and their occupation if available. This really should be the goal.
I'm now a genealogist, and have been a lead developer, so it's possible to be both. May I suggest that genealogy lessons be given to your developers, developers of genealogy software. It really does appear that at least one developer has little knowledge of genealogy - how else can you possibly explain the addition of an undated marital status?0 -
In every census record I have used the source linker to attach, when the residence data is copied into the person record, the date is automatically added. The residence record does not explicitly have a date associated with it, there is no place on the line in the census to record the date for every person, therefore it cannot be indexed on a person-centered system on a per-record basis.. The date for residence is derived from the fact that the census was taken on that date. This is the date of the event and it applies to every record. When the occupation, shown in the same census record, is copied over to the person record, the date is not added. This disparity is what I would like to overcome. What was apparently good for Residence should apply equally to all evidence in the record for each individual because they are all part of the same event for every person in that census. Arguably, the derived date should be applied to all records that are copied across. w.r.t. the statement from the Chief Genealogist, I fail to see how this is assuming a date.
Will somebody please show me how to add a date to an occupation when it is attached using the source linker, I have not discovered this feature.
1
