* Duplicate citations after import from RM8

[rcpettit]

I did a direct import of my genealogy from RM8 (junk) and for the most part it was painless. Just wondering when cleaning up my citations after using the Citations to source, shouldn't editing one of the entries should update all the citations with the same record ID? Right now I have to edit one and go to each instance and do a delete/paste to get them all to match.

[Mark1834]

It's a reasonable expectation, but no, unfortunately FH cannot do this.

For background, read Citing Sources: Method 1 and Method 2 in the Knowledge Base. RM tends to make much more extensive use of Method 2 / Lumper sources than is the norm for most FH users. When a lumped citation is used to support multiple facts, each citation is independent of the others.

RM8 overcomes this problem with its "shared citation", whereby all identical citations are managed as one entity. FTM has had a similar feature for at least a decade, but CP have yet to introduce this for FH.

Now that FH is successfully attracting a significant number of users away from RM, I wonder if it is time to add a request for a similar shared citation to the Wish List? The reason that is usually trotted out for not doing it is that GEDCOM does not support the shared citation concept, but IMO that is not relevant. I suspect it can be done in the underlying code, but let's not second-guess the pros at CP on what is possible and what is not - our job is simply to ask for what we want...

[rcpettit]

I believe it could be done with code. The program could find all the instances of the citation and make the change automatically in the underlying gedcom. There could be an option to turn this feature on or off in setup.

[NickWalker]

I believe it could be done with code. The program could find all the instances of the citation and make the change automatically in the underlying gedcom. There could be an option to turn this feature on or off in setup.

It could certainly be done with code, but there would need to be a way to identify which citations are 'the same'. A 'lumper' (method 2) census source could have tens of thousands of citations so how would the program know which of the other citations to update when you edit the citation for one of the census households? There would need to be a unique identifier of some kind within each of the citations that are to be kept synchronised. "Where within source" could potentially be used to do this but is this guaranteed to be unique? Probably not, particularly if different census households were on the same census page.

This is also ignoring the issue of the same data being duplicated multiple times throughout the file - it would be far better if there was a shared citation structure that could be linked to each relevant citation. Effectively this is doing what a 'splitter' (method 1) source does though.

[Mark1834]

I agree that it could not be implemented retrospectively, and would only apply to new citations or imported projects. RM8 has a SharedCitations table in the SQLite database to keep things in order, so it might need a new Shared Citation record type. It’s quite a change, so probably wouldn’t be implemented in a minor version upgrade, even if CP thought it worth doing versus whatever other goodies they have lined up for FH7.1...

[rcpettit]

Ok! I see what's going on. I thought the Record ID was the id of the citation, but it's a person ID number. Dang, I thought it would be simple.

[tatewise]

FYI: There may be several Record Id involved.
Each Individual and Family record that has a Citation has a Record Id.
The Source record associated with the multiple Citations has a Record Id.
Any Media record linked to the Citation or Source has a Record Id.
What is needed is a shared Citation ID that uniquely identifies equivalent/duplicate Citations that need to be kept in sync.

[Mark1834]

That’s exactly what RM8 has. The SharedCitationID is the Primary Key of the relevant table, and this links to Events etc supported by the citation.

[AdrianBruce]

... The SharedCitationID is the Primary Key of the relevant table, and this links to Events etc supported by the citation.

Mark - speaking in FH terms, because I can't define them any other way, what does the Shared Citation actually hold in RM? Is it all the citation-specific details, including the assessment and note? I think that I can't tell from my free copy of RM.

[Mark1834]

I checked in the actual database tables, and it is essentially everything apart from the assessment. Personally, I think the note should be excluded as well, so the shared citation contains everything to do with its content (Text From Source, templated data fields, media, etc), but elements to do with its interpretation (assessment and note) are entered individually.

Incidentally, the table and field names I described above are not correct - I was responding on the ipad and didn't remember them correctly (before anybody else goes rummaging and corrects me... ).

[cwhermann]

As a former RM8 user, (albeit for a short time), I found I did not utilize the “reuse citation” feature very often. Most of the time the limitation was with the note. For example, even with 10 individuals in a census household, (citation fields identical and text from source identical) but I wanted to add an explanation in the note about the information for the citation attached to the head of household, but a different explanation for other information in the note for the citation attached to the two nephews who were living in the household.

[AdrianBruce]

I checked in the actual database tables, and it is essentially everything apart from the assessment. Personally, I think the note should be excluded as well, so the shared citation contains everything to do with its content (Text From Source, templated data fields, media, etc), but elements to do with its interpretation (assessment and note) are entered individually. ...

Thanks Mark. I'm not sure what I expected. It certainly wouldn't work for me (out of the RM box) because I like two levels of note in my split sources. One at the source-record level saying why I think this family in the census is my family (say) and a second at the citation-detail level saying (e.g.) how the age and birthplace from this census squares up with the current values. Much as you suggest, albeit in split form. Munging all that together at the level of the note in the citation level in a lumped setting is not a good prospect. But I am speaking from the point of view of having been a splitter for years...

And thanks to Curtis for his comment from experience.

[Mark1834]

Indeed - this is highly unlikely to turn splitters into lumpers, but it might make FH a little more lumper-friendly for those who are used to working that way in another app.