* Import: Multimedia Objects as Separate Record

[redynstruc]

Disclosure: I imported my data from another genealogy program into Family Historian after, first, converting it to the GEDCOM format.

My problem concerns links to multimedia objects. Actually, my issue is that most of my multimedia files were not imported as separate, 'object' records (such as @O#@) and, then, linked to an individual record as @O#@. Instead, 99% of my multimedia records were imported as object links within an individual record.

To illustrate the 1% of my multimedia objects which were imported correctly, I have provided an example below: in this example, a record of the multimedia object, @09@, was linked to the individual record @1265@ - as it should be. (Note: In this example, the record, @09@, references an image stored on the hard drive as [redynstruc_Photos/P20.jpg]).

0 @I265@ INDI
1 NAME Sophia T /THOMPSON/
2 GIVN Sophia T
2 SURN Thompson
1 OBJE @O9@
2 _ASID 1

In most cases, however, the multimedia object was not imported as a record, but, rather, was simply linked to the individual records it was associated with. Building off of the above example, the multimedia record @09@ has now become nothing more than an object referenced by the individual record @I265@.

0 @I265@ INDI
1 NAME Sophia T /THOMPSON/
2 GIVN Sophia T
2 SURN Thompson
1 OBJE
2 FORM jpg
2 FILE redynstruc_Photos/P20.jpg

Therefore, using my corrupted database, if I click on an individual, I can see that s/he is has twenty, for example, images associated with him/her. When I go to the multimedia view, however, I am virtually assured that not one of the images associated with this individual will be displayed. Tbis, of course, makes it difficult to manage the multimedia 'library' and assure that Picture @O09@ is not only associated with the records @I1@, @I2@, and @I3@, but also @I4@, @I5@, and @I6@.

Any, relatively 'easy' fixes, which can be offered will be sincerely appreciated.

Regards,
Curt Snyder
United States

ID:3593

[Jane]

FH does not change the way images are attached so your source system I suspect exported them that way.

I can't think of a quick way to convert them at the moment. I have a program to go the other way from media records to local attached, to allow transfer to other programs. So I suspect it might be possible to do so.

How ever it won't be a trivial job.

[JonAxtell]

Curt, I have a very 'in progress' program which will solve your images problem. I've sent you the location of my program privately.

The reason you have this issue is because FH does not follow the Gedcom spec 100%. The gedcom spec specifies that objects which have filenames are specified using the Object Structure which are always part of a owning record (individuals in your case), see the reference to FILE as shown below:
OBJE {1:1}
+1 FORM {1:1}
+1 TITL {0:1}
+1 FILE {1:1}
+1 > {0:M}

Using the object record is for embedding the contents of the file in the Gedcom file, see the use of BLOB (and lack of FILE) as shown below:
@XREF:OBJE@ OBJE {1:1}
+1 FORM {1:1}
+1 TITL {0:1}
+1 > {0:M}
+1 BLOB {1:1}
+2 CONT {1:M}
+1 OBJE @@ /* chain to continued object */ {0:1}
+1 REFN {0:M}
+2 TYPE {0:1}
+1 RIN {0:1}
+1 > {0:1}

FH gets round the issue of having multiple references to the same file by adding extensions to the object record. These extensions are valid Gedcom tags but are not understood by nearly every other genealogy program as extensions are defined to be specific to a program and not designed to be shared. FH could have kept to the Gedcom spec 100% and uses the object structure and used the method it uses to cope with multiple occurrences of place names to handle multiple objects. Instead it breaks the adherence to the spec and does not use the BLOB tag in object records which is a compulsory tag which is what {1:1} means.

So your other genealogy program is producing perfectly valid gedcom and it is FH that is at fault in not handling object structures in a nice easy way.

[Jane]

I suspect the main reason FH uses media records is the fact that it also supports, 'cutting' of parts of images and to attach multiple people to a single image, which makes more sense via media records, to me anyway.

[NickWalker]

Some of this was discussed in this thread:

http://www.fhug.org.uk/cgi-bin/index.cg ... y&num=2439

[redynstruc]

First, thanks to everyone who posted and, especially, to Jon who sent me a link to his utility for extracting multimedia links from individual records and recreating them as multimedia records.   The various posts are quite a bit above my head, but I will try to provide a rejoinder anyway.

If Jon is correct about FH not following GEDCOM 5.5, then I guess I am ambivalent about this because, while I would like the standard to be followed 100%, I also think that FH's use of separate multimedia records makes more sense than what I am understanding from Jon is the GEDCOM standard.  If I understand Jon correctly, GEDCOM 5.5 requires inserting the file type, location information, etc. into every individual record which refers to a single multimedia file.  If this is the case, then GEDCOM 5.5 requires the database to repeat the same information over and over again - not exactly what I would expect from the computer age.

To me, defining a given multimedia file once as a multimedia record and, then, referring to to this record as [1 OBJE @O29@] (to quote Nick Walker's post at http://www.fhug.org.uk/cgi-bin/index.cg ... y&num=2439) in 100 individual records makes more sense.   Besides reducing the file size, the FH approach seems to make it easier to implement changes affecting a given multimedia file:  instead of modifying 100 individual records linked to the multimedia file, FH only needs to modify the single multimedia record which are referenced by these individual records.   So if, for example, you move a multimedia file from [c:dataPictureOfMom.jpg] to [c:datagenealogyPicutreOfMom.jpg], FH only needs to make one change to your database, not 100.

Putting all of this discussion aside, the bottom line for me is that, unlike the last genealogy program I was using, I can actually look at the native file of FH using nothing more than Notepad and see what's going on.  So I now at least have half a chance of figuring out why my data is not being handled by the program the way it 'should' be and, then, do a reasonable job of evaluating whether this hobby is just a tad more than I really wanted to take on.  

[jmurphy]

I'd like to address the last point of this message:

redynstruc said:
So I now at least have half a chance of figuring out why my data is not being handled by the program the way it 'should' be and, then, do a reasonable job of evaluating whether this hobby is just a tad more than I really wanted to take on.

To me the point you make in the end (the 'and then' clause) doesn't follow from the matter you have in the beginning. If you were a mathematician, would you give up the study of math theory entirely, simply because you were working on a problem for which a computer-based solution would be useful, but the tools currently available to you were not up to the job?

There are plenty of things in the GEDCOM standard that I find unsatisfactory, and I have considered doing everything on paper or building my own database system, but even if I gave up using the computer for tree-building and record keeping, I wouldn't give up doing genealogy.

Of course your feelings may differ -- but please don't confuse the problems inherent with dealing with the GEDCOM standard and doing things 'to standard' as far as the computer is concerned with the doing of the actual research.

Doing the work properly -- evaluating what you find, keeping records so that you know where you found your data and can point someone else to the source so they can find it too, if needed -- and so on -- that is the important thing.

Jan

[JonAxtell]

Curt, you are right that the Gedcom 5.5 spec requires duplicate entries of file references if an object is used a number of times. It does this already with place names (a more likely candidate for multiple entries). This does not follow good database design guidelines - however Gedcom is not a database spec but a communications spec. It's up to the program to decide how to present this to the user.

In the case of place names, FH provides the work with places tool which works on all instances of a place name at once hiding this fact from the user. FH could easily have done something similar with file names. The fact that FH has to do all the work on changing 100 references instead of one is not a problem as that is what computers are good at. All the user want to know is that when they change a file name (or place name) that all occurrences are changed.

This is true for the underlying Gedcom too, a typical user doesn't need to know how the data is stored so long as they can use their data as they wish. If a user has to break out of the program and use something like Notepad to fix the data, then that means that the program has failed in handling the user's requirements. The only slightly good thing about using a text format for a database is that it easy to write utilities to work with the file, but a good file format definition or an API would do the job just as well.

[redynstruc]

Thanks to Jan and Jon for their most recent posts.  While I was being facetious about '...evaluating whether this hobby is just a tad more than I really wanted to take on....,' I do believe that, for some of us, the tools available are critical to our accomplishments.   Just as I wouldn't even think to go to the local shopping mall (a jaunt of a mile or two) if I didn't have a car, I would most likely not be doing genealogy were it not for programs like FH and the wealth of data available via the internet.  

For me, FH's use of plain text format to store the data is invaluable.  It's all too frequent that we run into what Jon described as '...the program....fail[ing] in handling the user's requirements...'   After clicking around on dialogue boxes for fifteen minutes or so, going to the help manual, and then back to the dialogue boxes some more only to conclude this exercise no further than when we started, we can either (1) wait and hope for the program to get better or (2) if the data is stored in text, dive in an edit it directly (remember how much easier it was to 'reveal codes' with Word Perfect than it is trying to get Word to realize that you really do want to edit the style tag which is, regrettably, 'inside' of your selection?).    

I also believe the plain text data format can serve as a Rosetta Stone of sorts.   I'm sure we all have files floating around on our hard drives that were created with programs we no longer possess and, therefore, the possibility for reading the data is virtually nil.  The chance of somebody (maybe even me) finding the data file on the hard drive a few years from now and being able to do something with it is immensely increased because of the text format.   This, I believe, can be an important part of what Jan described as '...keeping records so that you....can point someone else to the source so they can find it too...'

Anyway, there are many, many folks who would seriously disagree with me (starting with my spouse) so I leave this discussion with, 'I know my opinion might be less than valid, but I do believe there are others like me who might move just an inch further than they would have otherwise by taking this less-than-disciplined approach to the craft.'

Regards,
Curt

P.S.  Thanks, again, to Jon for sending me the link to his conversion program.  That was a real boon for a somewhat indolent neophyte like me.
 

[JonAxtell]

redynstruc said:
(remember how much easier it was to 'reveal codes' with Word Perfect than it is trying to get Word to realize that you really do want to edit the style tag which is, regrettably, 'inside' of your selection?).

You'll love this article about formatting codes then - http://www.codinghorror.com/blog/archives/000583.html

[jmurphy]

redynstruc said:Just as I wouldn't even think to go to the local shopping mall (a jaunt of a mile or two) if I didn't have a car, I would most likely not be doing genealogy were it not for programs like FH and the wealth of data available via the internet.

Ah, but as a city dweller, I can visit the  shopping mall via public transit, and while I may not make bulky purchases without a car, it works just fine for clothing shopping and other light items, and even for heavy items if one has a small shopping cart or a good sturdy bag.

I agree with you about the virtue of being  able to read the file as plain text. I would much rather have Word Perfect 5.1 plus for DOS and be able to reveal codes over any version of Word ever made, and if I had the space, I would keep one of my older computers active simply to run WP and some of the older robust programs from the days of DOS.

Jan

[NickWalker]

It was the plain text aspect that appealed to me about Family Historian in the first place as I knew as a programmer I could 'do things' with it if I needed to. And of course Gedcom Census sprung from that and couldn't have happened otherwise.

[redynstruc]

I wish I would have paid more attention to Jon's post which read, 'FH gets round the issue of having multiple references to the same file by adding extensions to the object record. These extensions are valid Gedcom tags but are not understood by nearly every other genealogy program...' (emphasis added to original text).  

Today I discovered (what Jon already knows) that the way FH stores multimedia as a top-level object instead of a record within an object is not recognized by PAF, Roots Magic, MyHeritage, and Family Tree Maker (these are the four I tested).   So now, thanks Jon's help (see a previous post about a utility he's written to convert the standard GEDCOM method of handling multi-media to the format FH uses), I have my multi-media in a format that FH can read, but not in one which any other program can read.  Aaargh!  This is what I was trying to avoid in the first place when I switched to FH!

In my 'fantasy world,' I would send the GEDCOM file, along with the multimedia, on a CD which also contained a freeware program so that anyone could run the software, read the data, and be well on their way to doing their own research.  Clearly, I can't do that with FH data in its native state.   Does anyone have a fix?

Regards,
Curt

[Jane]

Just use my FH Converter with Irfanview to convert all the links to direct ones.

http://www.fhug.org.uk/cgi-bin/index.cg ... edCom&id=4

I wrote it to convert for TNG, but it also works Legacy etc.

[redynstruc]

Jane,
Thanks for the link to the utility.  It's probably something I'm doing wrong, but when I run the program the command prompt window opens, invokes IrfanView and, then, hangs there until I close IrfanView.  Closing IrfanView lets the batch file proceed to the next step.  The funny thing is that after closing IrfanView several times and examining the command prompt window, it seems that the utility is only working with pdf or txt files.  The reason I say this is that after each line of the batch file which works on these files types, there will be a line of screen output indicating that '1 file was copied' or 'System can't find file; 0 files copied,' but for the jpg file types, there is no screen output; it just moves to the next line of the batch file.
Thanks anyway.
Regards,
Curt

[Jane]

Not seen that, can you let me know what version if Irfanview you are using and what OS. It worked for me last week OK when I used it.

[redynstruc]

I'm using Windows XP and Irfanview Version 4.0.

[Jane]

Can you try Irfanview 4.1, just to see if it helps.