Several weeks ago users of the FamilySearch.org website reported that bookmarked URLs to images on FamilySearch.org stopped working. Users received this error:
A year ago Robert Kehrer, FamilySearch product manager explained that “[links to] FamilySearch person records and their associated images are built on a technology called Persistent Archival Links [PALs]. That is what the pal portion of the record URL means (ex. https://familysearch.org/pal:/MM9.1.1/X79S-N78). This is a technology that makes it so that the links should not change.”
In reporting the error above, “GeneJ” complained about “PALs that aren't PALs for long.” Users were angry and fearful.
Randy Wilson, rock star and FamilySearch Information Architect, responded to the report. He said, “This looks like a bug. I will get some engineers working on it.” A couple days later the bug was fixed and old URLs worked as expected.
Wilson explained why the URLs stopped working. FamilySearch had just switched the system it uses to hold records. This caused the URLs of all its images to change. An image that used to be
and the old URL stopped working.
Trouble was, the old URLs were supposed to continue to work. The guts of the PAL (the part before the question mark) didn’t change, so an old URL was supposed to still work. It didn’t. FamilySearch fixed it. Everyone’s (mostly) happy now.
Wilson also revealed that this change won’t be the last. In the coming months FamilySearch will switch from PALs to industry standard ARKs: Archival Resource Keys. He said old PALs will continue to work.
Citation GoobledeegookThis makes me think about some citation principles and why you should always copy and paste the FamilySearch suggested image citation rather than just the URL.
I have a family group sheet that lists one source: a Family History Library film number. The problem is, the FHL changed its numbering scheme since that sheet was authored. I have a PAF file that lists a single source: a Pedigree Resource File (PRF) submission identification number. The problem is, FamilySearch changed its numbering scheme when it republished the PRF on the current website. There are citations consisting of nothing more than Dewey call numbers for libraries now using LOC call numbers. Today’s ISBN numbers will be replaced by tomorrow’s ID du jour. Using a lone identification number (or URL) in lieu of a full citation is short sighted.
Redundancy in citations is generally avoided to avoid overly long citations. But in its suggested image citations, FamilySearch is redundant. Consider this citation:
It has both the PAL URL and the bread crumb trail. If the image is moved from "Massachusetts, Land Records, 1620-1986" to another collection, the PAL will get you to the image no matter what collection it is in. If the PAL breaks, the bread crumb trail will still get you to the image. If the bread crumb trail is changed, the PAL will still work. If several of these change, there is enough raw metadata that with some effort you will be able to relocate the image.FamilySearch has made copying the image citation convenient. Click Show Citation and Copy Citation. You can then paste the citation where ever it is needed. One day you will be glad you did.
FamilySearch has actually used three different microfilm numbering schemes. As Mr. Sider noted, many old family group sheets refer to the oldest scheme. When I was a professional genealogist doing research for clients, I often had to ask a FHL library attendant to get the old book off of the shelf that crosswalked the first system to the second system. The second system is also known as Red Numbers. I then had to go to the Family History Library Catalog on the old FamilySearch CDs and use a little-known trick to convert the Red Number to the third scheme -- the sequential numbers now in use.ReplyDelete
The problem is, I am pretty sure that doing this double conversion is no longer possible. The old book that converted the first scheme to the second scheme probably got tossed out years ago. And the FHLC on FamilySearch CDs DID get tossed out years ago.
And if you want to look up the image in an alternative place (e.g. on a microfilm, on paper, even on an "alternative" web-site) then having some descriptive text would be somewhat useful. Why would I want to do that? Well, it could be that the FS image is of an earlier, poor quality filming. Or even that FS no longer holds the image (yes, it does happen, as anyone who grabbed images from the Cheshire Collection when it appeared temporarily on FS will understand. In that case, it shouldn't have done so, so the FS image soon vanished.)ReplyDelete
These "Uniform Resource Locators" are supposed to be just that. Beyond the issue of coming up with overly complex naming schemes, they could easily have automated tests to ensure that the URLs that they said would continue to work are actually working. Instead of waiting for users to report that they broke the system they said won't break they could have been alerted to the situation within a few minutes of it breaking.ReplyDelete
Thanks for covering all this, and urging multiple bread crumb type things to include in sources. Also when using Tree Connect, be sure to copy all the information on the on-line source to the notes on the Source Template, and not just the URL.ReplyDelete
The moral of this story is, copy an image of the record into the Sources folder on your own computer as well as provide a robust citation on FamilySearch. Then when (not if), despite everyone's best intentions, the citation fails sometime in the future, at least you will have a copy you can always access. And, of course, it goes without saying (although I'm saying it just to be sure) that you have at least one backup for your Sources folder. Then be prepared for the inevitable change in image protocol; for instance let's say JPEG goes out of style in favor of something supposedly better. After a while software will no longer recognize JPEG, so when it becomes clear that JPEG is on it's way out, best convert all your JPEGs to the new protocol. Technology is wonderful, but it does have its problems.ReplyDelete