Why are Missing Records Being Pushed as Record Hints?

LegacyUser

Jeff Wiseman said: I have seen at least a dozen of these in the last few days:



Choosing the Review and Attach only results in the generic missing record page with the suggestions to remove any bookmarks that you may have of that record.

When sources are removed from the system, why does the system continue to push them as hints? In examining some of the URLs involved, they all seem to be based on the old Persistent Archive Library (or whatever) PAL URLs. I know that these are being replaced with the more proper ARK URLs, but how can you be pushing specific records as hints, when those records have already been removed from the system?

LegacyUser

Brian Jensen said: Jeff,
We've had several reports of this and we will be looking into these issues on Tuesday.

LegacyUser

Amy Archibald said: Thanks Jeff for bringing this up! I keep running into this issue.

Sometimes the source is already attached and the 410 error shows up. Then I mistakenly detached one of those sources and now I have the suggested record hint for it, but I cannot do anything about it.

LegacyUser

Jeff Wiseman said: Try just marking it as "Not a Match" with a reason something like

"Why should I be paying any attention to hints that don't really exist?"

...er..., I mean:

"This record has been deleted by FS and shouldn't be treated as a hint"

Sometimes when you detach the broken citation (i.e., the PAL style citation--i've seen a bunch of these as well), the new ARK type citation that should replace the PAL one gets hinted. When that happens, of course, it should be ok to attach the new citation.

It would be a lot better though if when the PAL is removed, that the new ARK actually replaced it at the point where the PAL is removed.

That is, if that is what is really going on.

LegacyUser

Adrian Bruce said: Are you implying that the PAL URLs are actually being deleted - rather than not added to? In which case, what about any outsiders who stored PALs under the impression that they were, ahem, persistent? Surely there must be a bit more to it than that? Mustn't there?

LegacyUser

Jeff Wiseman said: I don't know exactly of what is going on, but I'm pretty sure that the PAL to ARK conversion works from just establishing a new URL to the record (ARK) and removing the old one (PAL). For a while, the old PAL URLs seemed to work in that once an ARK URL was put in place, the PAL URL would just forward to the ARK URL (or something like that). It seems that now the PAL URLs have just plain been REMOVED, and hence any citation referring to it (yes, including any outside references to it) will result in a "Record not found".

Now, I've not looked real close at it, but this situation might be reproducible under 2 totally different situations. The first is if an old record in the system is actually deleted from the system (e.g., a bad photo replaced with a better one). The second is if an old URL pointing to that record is deleted from the system, but the record itself remains in the system.

I suspect that it is the latter of these two. When an old PAL URL is replaced with a new ARK URL, all of the citations in the entire database that use that old PAL URL need to be updated to have the new ARK URL put into them and replacing the old ones.

The behaviors that are being seen here seem to imply that URL types in the system have been swapped, but the citations that used to use the old URLs are still using them (i.e., they have not been updated with the new URLs yet). Since the old URLs are not in the system anymore, using those citations results in an error.

Assuming those guesses are all close, one thing I cannot quite figure out is, why then do the old URLs of HINTs continue to show up? When I run a compare of citations stored in my Ancestral Quest database for a given record again those in FS for the same person, the failed citations in FS were all sync'ed to PAL type URLs in AQ as well (which also will fail if I attempt to view them). However, there also seems to be new sources with ARK type URLS that have been sync'ed down to AQ that appear as though they were intended to replace the old PAL URLs (e.g., same titles).

LegacyUser

Jeff Wiseman said: Adrian,

So maybe PAL stands for Persistently Anomalous Links?

(Sorry folks, having worked in technology for so many years, I've developed a serious case of "acronymitis")

LegacyUser

Adrian Bruce said: Persistently Annoying Links surely?
(Excuse the whimsicality again!)

LegacyUser

Merlene Juergens said: I just blindly believed the record had been removed for some reason known to FSFT, so I have detached every one I found. I sure hope those records pop back up as hints so I can re-attach them.

LegacyUser

Jeff Wiseman said: Well, it is SUPPOSED to be Permanent Address Link, but we know how that has turned out :-)

LegacyUser

Jeff Wiseman said: As I mentioned in the subtopic above, I suspect that will happen. As long as the historical Records are still there, they need a PAL or ARK type URL to be used. When PAL URLs are removed, I can only assume that it is because ARK type URLs have been inserted. The hints engine should eventually be aware of all of the URLs in the system.

Only if the historical record has been completely removed would the hints engine not know about it. But that really doesn't appear to be what is happening here.

I know that this conversion has been going on for a while now as I have observed it occasionally while sync'ing sources between FS and my AQ database. What is happening at present is an anomaly. Something has just gone wrong recently.

Here's a short topic on it from over a year ago. Note Ron Tanner's comment:
https://getsatisfaction.com/familysea...

I'm not positive about this, but I'm pretty sure that if those citations were left attached to the FS records, eventually they were supposed to be silently changed over to ARK type URLs.

LegacyUser

Jeff Wiseman said: ARK stands for Archival Resource Key.

Here's a FS description of these things:
https://www.familysearch.org/develope...

Note in the first large paragraph it states:

When a persistent identifier is provided for a resource, it means that FamilySearch has made a long-term commitment to maintain that identifier. This means that requests for the resource using the persistent identifier will always resolve to that resource.

In other words, "Can't Find Record" should not be an option--well I guess that really depends on the accurate definition of "long-term commitment", and whether the PAL identifiers were actually defined as "Persistent Identifiers"

LegacyUser

Juli said: I dug through my offline file and found an old PAL-style URL:
https://familysearch.org/pal:/MM9.3.1...
Plugging it into my browser, it changed into an ARK-style link:
https://www.familysearch.org/ark:/619...

I think this is the behavior alluded to in the FS article that Jeff linked: the address is outdated, but still works.

I have no idea how this relates to the missing records being offered as hints.

LegacyUser

Jeff Wiseman said: Right. In order to maintain the persistence, the old PAL URL is (theoretically) altered to automatically forward to the current ARK URL for the same record. So old citations based on PAL type URLs would continue to be valid (i.e. persistent). But when you get an error, it is either because the old URL was not set up to forward to the new URL, or the record that it was referencing has disappeared from the database.

Theoretically, you should never get a "Can't find record" message when using EITHER a PAL or ARK type URL.