Family Historian User Group

tatewise wrote: ↑

13 Apr 2023 20:06

IMO exporting your data and importing it again is red herring.

It is a red herring if "exporting your data and importing it again" is all you are doing. However, if you regularly export data from one product to another it becomes very important. I maintain my data in FH but I export it regularly to update changes on my TNG website. Consistency of the person and family ids between the products is very important to me because my website contains custom pages which have links to individual and family pages in the database. This is definitely not an unusual scenario amongst TNG users. Without that consistency those links could be broken each time I loaded an updated GEDCOM. That is the primary reason I did not consider Heredis for very long when I was looking for a new desktop program. What is a red herring for some may not be for all.

As a splitter, I have included enough fields in the record title that I rarely encounter two sources with the same name. In the case that I do have a source with the same record title as another, I will manually edit it (by un-selecting the autogeneration option) and add some sort of qualifier to differentiate the two. There would have to be some difference between them in one or more of the source citation fields, otherwise it would be the same source! <shrug>

I may have been trying too hard to use all the "bells and whistles" of FH7. There may be a very simple solution to my source naming issue.

My image records are currently stored with filenames that look like; The 1st instance of the person, the 1st of 2 images comprising the 1st birth record image. The 4-character code is simply the GEDCOM tag that corresponds to the main event documented in the image. To resolve conflicting names in my filesystem, I adjust the noted 3-digit "index" numbers. However; conflicts appear to have been rare over the past several years.

This means that a set of images falls under a single and unique "root" identifier, which looks like the following; If I have two ancestors in the same set of images, I usually duplicate the images and adjust the the filename appropriately. I know that one should likely keep only one copy of an original, but doing this makes filing conceptually easier.

Following this set of rules, so far, has meant that everything sorts well and I can easily find a file for a person.

Perhaps the simplest solution for me is not to autogenerate a name, but just copy the unique "root" identifier to the "Record Title Format".

Does anyone see any impending issue with this approach?

If I have two ancestors in the same set of images, I usually duplicate the images and adjust the the filename appropriately. I know that one should likely keep only one copy of an original, but doing this makes filing conceptually easier.

As of FH 7.0.17.1,

If you add a picture or other media item into a project, Family Historian will now check for duplicates, skip unnecessary file copies, and avoid creating a new Media record if there is already a Media record for the item in question.

If you add a picture or other media item into a project, Family Historian will now check for duplicates, skip unnecessary file copies, and avoid creating a new Media record if there is already a Media record for the item in question.

I interpret that as it looks to see if the same actual file has been added. I'd be surprised if it is looking for duplicates of the file where the duplicates have different names. Not impossible of course but would seem like a lot more work for the system to look at file hashes or whatever. I've just done a few experiments and that seems to be the case. If I tried to add the same file it just opened up the media record already linked to the file. But if I copied and pasted the file and added the copy in then it allowed the duplicate. I was actually able to then edit the duplicate media record and make it point at the same file but it didn't then seem to do anything to try to correct that situation so it seems to only be doing this check when the file is added initially.

Helen;
I appreciate you mentioning the new feature.

Does FH 7.0.17.1 (an onward) determine files are the same just by examining the filenames or by comparing some form of "digital fingerprint" for the files? I think the latter is unlikely. I believe that FH7 also uses the filename as the caption, which could be an issue if it were using that option and came across a duplicate.

In French État civil records, the record for an individual can span one or more images or there may be several persons of interest on a single image. Admittedly; the former is more common. This presents some problems in choosing a naming convention. So; to leverage the new feature, it appears that I have to have a filename just based on the image and not the person.

Gary_G wrote: ↑

14 Apr 2023 09:25

So; to leverage the new feature, it appears that I have to have a filename just based on the image and not the person.

I name the file (and the media record) the same as the Source (Short Title for Generic sources, Bibliography entry for Templated ones) -- but I'm a splitter, so it's easier to ensure a unique name. If there's more than one image for a source, I append a number to the end of the file and media title.

The duplicate file handling in FH V7 was fully discussed in Ver 7.0.17.1 - Duplicate Media Prevention (21133).
It does check the full file path and the file contents if two file paths are identical. Go read the other thread.

Where an image relates to multiple people I use the most senior person to determine the file name.
The most common case is Census Record images where it is usually the head of household.
Gary, surely you don't create a duplicate Census Record image for every person named in the household, so why do it in any other cases?

Harold, I said:
"Stick to one product to hold your master database and only transfer it out to other products, but never back again.
FH Record Id are never changed unless you deliberately use certain tools to alter them."
So your comments were just reinforcing what I had already said.
Remember also, I'm the author of the Export Gedcom File plugin so know how GEDCOM Rec Id transfer to other products.
It is only the transferring back that is a red herring.

Mike;

"Theoretically"; an true splitter would name each image according to the document and the page in the document, because it could then be used as support for any person. That would also guarantee a unique name for each image. However; one could then never locate an image involving a person based upon its filename alone. I understand that splitters have made a compromise and tried to name images by referencing the key person involved and the event type etc. That means that there would need to be multiple instances kept on file.

I don't usually keep multiple images for a census page. But what does one do if the same page holds a second family of interest? Surely you don't file a single image under the name of the eldest person of the two separate families?

The État Civil often has a similar situation. I could have several relatives in differently numbered "Actes", but on the same imaged page. I'm trying to find a reasonable way of naming the image so I can find a given person in my existing filesystem. That is why I duplicate the image for each key person, name it accordingly and place it in that person's sub-directory.

I had found the noted thread earlier, but it wasn't too clear as to what constituted having the same "content". It did mention several possible methods over the course of the thread, but didn't say what FH7 actually uses. Judging "content" based on file size would not provide the same guarantees as having the same digital fingerprint (ie. checksum etc.). So, I decided not to be too specific in my earlier post.

I should note that all my "duplicates" fall under your posts case #2. Each person has their own sub-directory outside of FH7. So; not only does FH7 not see my duplicated files as actual duplicates, it also only uses references to link to them.

By the way; what is the relevance of the quote by Harold to the issue of filenames???

Gary_G wrote: ↑

14 Apr 2023 11:34

Mike;

"Theoretically"; an true splitter would name each image according to the document and the page in the document, because it could then be used as support for any person. That would also guarantee a unique name for each image. However; one could then never locate an image involving a person based upon its filename alone. I understand that splitters have made a compromise and tried to name images by referencing the key person involved and the event type etc. That means that there would need to be multiple instances kept on file.

I never need to locate an image by filename alone -- to find an image involving a person, I use the Media Window and Find > Media for Selected Individuals of Find > Media Linked to Selected Individuals.

I don't usually keep multiple images for a census page. But what does one do if the same page holds a second family of interest? Surely you don't file a single image under the name of the eldest person of the two separate families?

I create a single media record (name not including an individual), and link it to a couple of sources (one per household) which do include the Head of Household or Person of Interest in the title/bibliography entry to distinguish them. Each Source has the transcript for the relevant household.

ColeValleyGirl wrote: ↑

14 Apr 2023 11:57

Gary_G wrote: ↑

14 Apr 2023 11:34

I don't usually keep multiple images for a census page. But what does one do if the same page holds a second family of interest? Surely you don't file a single image under the name of the eldest person of the two separate families?

I create a single media record (name not including an individual), and link it to a couple of sources (one per household) which do include the Head of Household or Person of Interest in the title/bibliography entry to distinguish them. Each Source has the transcript for the relevant household.

For what it's worth, I prefer my image titles to match my source titles (mainly because that is the way I've always done it) and I do duplicate the census page if there is a second family on the page. With disk space not being an issue nowadays I don't worry about having a duplicate. I'm not saying this is the right or wrong way to do things.

Helen;

So; you rely on the FH7 "database" to keep track of those to whom an image pertains? I know that is what I did when using a digital asset management system for my photographs, but I'm a bit cautious about trusting FH7 to do the same as certified archiving software. Besides; I have other software that needs access to the same image files. That software doesn't always have the same capabilities as FH7 does for managing media.

I'll have to think about this. Making changes of this magnitude could be very risky.

Nick;

For what it's worth, I prefer my image titles to match my source titles (mainly because that is the way I've always done it) and I do duplicate the census page if there is a second family on the page. With disk space not being an issue nowadays I don't worry about having a duplicate. I'm not saying this is the right or wrong way to do things.

How have you approached assigning filenames? Perhaps and example name would help me see how you attack it?

Gary_G wrote: ↑

14 Apr 2023 12:25

Helen;

So; you rely on the FH7 "database" to keep track of those to whom an image pertains?

Yes, but I don't need to access them from other programs. If I did, I would probably still use FH to locate them, and then use the green Play button to open the relevant program. (Your requirements may be less simple, so it might not work for you).

Helen;

I just want to make sure I understand what you are doing for filenames.
Re-organizing a file-system is not something I would consider without hearing from a few people and a bit of analysis.

Do you basically have a name of the form, Repository_Collection_Document_Page/Image or similar?
How do you assign filenames to locally stored documents etc?

Gary_G wrote: ↑

14 Apr 2023 13:11

Helen;

I just want to make sure I understand what you are doing for filenames.
Re-organizing a file-system is not something I would consider without hearing from a few people and a bit of analysis.

Do you basically have a name of the form, Repository_Collection_Document_Page/Image or similar?
How do you assign filenames to locally stored documents etc?

As I said earlier:

I name the file (and the media record) the same as the Source (Short Title for Generic sources, Bibliography entry for Templated ones) -- but I'm a splitter, so it's easier to ensure a unique name. If there's more than one image for a source, I append a number to the end of the file and media title.

So I have image and source names of the form: 'Death 1844 England Sawbridgeworth, Samuel Brown' or 'Census 1851 England Kingswinford, Thomas Stuins 1 of 2' (a household split over 2 pages)

And if the same image applies to more than one source, I modify the media and image title to reflect that: 'Birth 1828-1836 England Cradley, children of Thomas and Ann Stain' (a non-conformist register of birth and dedications where 5 children of one couple were born between 1828 and 1836 but all recorded on the same page.

Thanks, Helen.
Despite your previous note about naming the sources and files the same, I was having trouble visualizing what the name might actually be. Seems that you are trying to have a single copy of an image by making the assigned title cover all the contained people, rather than just describing the image as part of a particular publication. I understand what you're doing now.

Gary, the image title is determined by the source -- if the source doesn't need the name of an individual to identify it, the image doesn't either, e.g. Manorial Court Rolls 1697-1702 England Stalbridge for the source and 18 images named Manorial Court Rolls 1697-1702 England Stalbridge 1 of 18 etc.

That source names about 60 individuals and there's no way to name them all in the title of the source or image .

Helen;

I guess what I'm trying say is that the naming is more-or-less what I expected from one practicing splitting. The image is not actually related to any one individual no matter what it is named.

What really interests me, now, is the workflow possibilities this allows. If I'm redoing my database, I have a lot of images and transcriptions waiting to be processed. With the practice you've described, I believe one can create all the "stand-alone" source citations, attach images to them, add a transcription to them, then (after all that is done) finally attach the sources to one or more facts/events? If so; then the data-gathering & preparation is nicely separated from the population of the tree. This would allow me to compartmentalize the "re-do" process and concentrate on one aspect at a time. Fewer errors that way.

Gary, yes that workflow would be possible. However, are you intending to re-do the fact creation as well? If so, AS would be the way to go [[Nick Walker falls off his chair ]] as it's currently the best option for streamlining creation of sources, linking them to media and creating the facts.

That thought has made a wandering zig-zag across my mind

As you can tell, I'm getting all my ducks in a row and making sure that it ought to work before I commit to using that approach. Now's the right time to ask questions. Getting into the middle of the process and realizing that something is "wrong" is not something I want to happen. One thing that concerns me still is whether using AS for data-entry will overwrite the people I already have entered in my tree. When I played with it, it looked as if it expected to built the tree as data was entered. Also; as I have the data in my old RM9 database and can call it up. Should I consider blowing away all the existing sources in my imported version, so that AS adds the new sources to a clean FH7 database? It's rather difficult to figure out all these things on ones own. There's so much AS does.

I know Nick said he was working on an upgraded AS release. I thought I'd wait until it was out.

I'm planning a total re-do within the next 12 months, to take full advantage of the new facilities that V7 offers (once I've written the plugins I personally need to streamline creating sources, individuals and facts based on the information within a source (the same job AS does, but there are some wrinkles I need that I prefer to program myself in Lua) and also to streamline creating Research Tasks to manage the process (by updating my existing plugin Research Planner 2). And I will also be spending a lot of time making sure I've decided how I want to use which features (ducks in a row) so that I don't get part way and find a problem.

AS will not overwrite existing people; it will create them if they don't already exist. And bear in mind that it handles a limited set of source type/facts (BBMDB, plus census and census-like sources) so you will need a workflow for manually creating other source types and facts. I suggest you take AS for a test drive on a copy project -- there's nothing like getting hands on to understand what it does, even before ypu configure all its bells and whistles.

Have you seen Ancestral Sources v.7.7.4 Testing (April 2023) (21801)?

Ancestral Sources will now allow templated sources to be used for those who use Method 2 (lumper) sources. Various changes have been made to the user interface to accomodate this. For example the link to create a Repository will now only be shown if a repository is referred to in the source template.

Helen;

I just downloaded and fired up AS.
It threw an exception when I was scrolling through the configuration settings, so I captured the info and sent Nick a bug-report. It could just be that I'm using the 64-bit ARM version of Windows, but I'll wait to see what Nick says. The old 7.7.3 ran just fine on the same platform.

ColeValleyGirl wrote: ↑

14 Apr 2023 16:55

Gary, yes that workflow would be possible. However, are you intending to re-do the fact creation as well? If so, AS would be the way to go [[Nick Walker falls off his chair ]] as it's currently the best option for streamlining creation of sources, linking them to media and creating the facts.

I did read this on Friday but it has taken until now to get back off the floor and onto my chair. Thanks Helen, this made me smile

Helen;

Gary, yes that workflow would be possible. However, are you intending to re-do the fact creation as well? If so, AS would be the way to go [[Nick Walker falls off his chair ]] as it's currently the best option for streamlining creation of sources, linking them to media and creating the facts.

I just ran the new FH 7.0.20 import from RM9. It still has quite a few problems with custom census facts/roles and doesn't generate rich text on import as stated. Not too happy about that. So, I have a choice; check and fix everything or just re-enter all my facts. I'm starting to think the latter is the only robust approach.