Re: Image documentation within database
- From: "Kerry Raymond" <kraymond@xxxxxxxxxxxxxx>
- Date: Wed, 3 Sep 2008 06:21:11 +1000
Tacking on a picture of the thing is a waste of good Mbs.
I would disagree with this. The more "original" the source information, the
better. I agree that if you are writing a book or whatever, that you don't
necessarily want to include the source photo. But then when you are writing
a book, there's many choices of what to put in and what to leave out. But a
book is different to a record of your research, which is what many of us are
using FTM (etc) for.
Even the act of transcribing involves making an interpretation of it, an
interpretation of it that may introduce errors. We have a headstone photo
WWW site and so I am transcribing headstones all the time for the purpose of
indexing. I know that often I find it difficult to work out exactly what the
names are and which dates relate to which people. Now, with our site, the
names are just used for keyword searching to attract the researcher to look
at particular photos. The researcher can then make their own interpretation
of each photo, which they do with the additional background knowledge of the
family they are researching. However, if all we published were the
transcriptions as I made them, then some people would almost certainly be
"lost" in the sense that a researcher could not find them because I
misinterpreted what their name was. The worst ones are Scottish families
that often have surnames used as middle names, so if the surname is omitted
as it can be when there are many on the headstone, it is hard to know if the
last name is the true surname or just a given name derived from a surname --
that's a great way to lose someone in a traditional sort-by-surname index.
By providing the photo, we eliminate a source of error and of course provide
more context (photos of surrounding graves etc).
Look at FreeBMD and electoral rolls and census records on Ancestry and you
will see the same thing. Yes, someone has transcribed the record so
searching can be done but scans of the original record are available so you
can see for yourself what it said in case your interpretation is different.
The trend is making resources available online is increasingly towards
scanning the original records whenever possible and so our family history
software needs to accommodate that.
However, we do need good engineering solutions here. Scans do take up a lot
of space. And as an FTM user, I agree -- I don't need that bulk in my
database. Storing the image as a separate file is better from that
perspective, but then it becomes easy to disconnect the database from its
images. Also with separately-stored images, the main database does need to
have a way to hold the meta-data for the image at least (what it represents
and how it links to people in the database) which FTM doesn't do
tremendously well either (you can go from a person to an image but not vice
versa). Just putting a filename into a field somewhere in your database (as
a few people have suggested) is also a fairly poor solution (loses
meta-data). Note an underlying part of the problem is that most family
history software treats sources and photos as second-class information
relative to people.
So, I am with the OP. There is a need and AFAIK no genealogy software has
come up with a good solution yet. I have heard positive things about the
way the latest version of Reunion on the Mac integrates with the photo
software on the Mac, but I have yet to have a first-hand experience of it
but would be interested to hear from someone who had.
Kerry
.
- References:
- Image documentation within database
- From: Power-Post 2K
- Re: Image documentation within database
- From: singhals
- Image documentation within database
- Prev by Date: Re: Image documentation within database
- Next by Date: Re: Image documentation within database
- Previous by thread: Re: Image documentation within database
- Next by thread: Re: Image documentation within database
- Index(es):
Relevant Pages
|
