16

Are there any standards, or common usage, for the creation of persistent (long-lived) URLs (web addresses) for genealogy events? (more accurately these would be called IRIs, but URLs are the more well-known term).

For example, Familysearch uses addresses like https://familysearch.org/pal:/MM9.1.1/MJ34-3M4 to refer to a person in an event. Is the "pal:" part of a standard, like perhaps "persistent archive link"? I've been unable to find any documentation on the meaning of the "pal:" prefix, or indeed how stable these addresses are intended to be.

Ancestry and Findmypast don't seem to put any effort into making their pages and records easily addressable. The record returned from a search is often an address like http://search.ancestry.co.uk/cgi-bin/sse.dll?rank=1&new=1&MSAV=1&msT=1&gss=angs-c&gsfn=edgar&gsln=jeffery&uidh=x26&pcat=1881UKI&h=17925715&db=uki1881&indiv=1&ml_rpos=1 . But within that record the individuals do have simpler references: http://search.ancestry.co.uk/cgi-bin/sse.dll?db=uki1881&indiv=try&h=17925715 . I doubt these URLs would be stable (kept available after a major software upgrade).

There are some "persistent URLs" in the academic, museum and library worlds, such as the Archival Resource Key and the Digital Object Identifier. Are there any projects in genealogy to use these or similar persistent identifiers (and is the Familysearch identifier connected to these in any way?).

Once records online are identified with persistent identifiers, the identifiers can be used as source references that can be shared and published, with the knowledge that there's a better chance the reference will still be there in years to come. At present, when a link to a web page is used as part of the source documentation of an event, there's a very good probability the link will be broken eventually (sometimes quite soon).

  • 2
    Great question. I am always disappointed when I read "Please DO NOT link to indvidual records, as the numbers change when corrections are uploaded" on the otherwise fantastic records of the Cornwall Online Parish Clerks e.g. cornwall-opc-database.org/search-database/more-info/…. As warned, I have observed some of these break within a couple of years. – PolyGeo Apr 21 '14 at 0:04
  • My work-around at the moment is to take a screenshot of the detail page (I use the Firefox extension Scrapbook) as well as downloading any record image that might be associated with that record. I rename the record image to match the "MM9.1.1/MJ34-3M4" -- taking out the characters which are not suitable for filenames. Scrapbook has a function to return to the live URL, but of course that doesn't address the issue of what happens when everything gets moved, nor is this method necessarily suitable for writing a citation that is of use to anyone else but me. – Jan Murphy Apr 21 '14 at 1:45
  • 1
    The Dutch National Archives use the handle system (see handle.net), which basically is a (reliable) third party where they have registered all of the URLs of records. These URL's have the form proxy.handle.net/10648/4243279a-653e-45ec-a31e-5bba6aace55f If the National Archives change their website or identifier of records they notify the third party, but the 'handle' stays the same. I did (just now) notice that this handle doesn't include the 'language' switch (I was on the English page copying the handle, but when I opened the address I got the Dutch page). – coret Apr 21 '14 at 8:22
  • @coret - thanks Bob, good to know at least one organisation is starting to use persistent addresses. Looks like the handle system is part of Digital Object Identifiers, that I mentioned above. You raise an interesting point about the language (of the labels, not the data) - should there be a separate identifier per language? Or should there be a way to pass parameters to the handle.net url, which probably isn't possible. Or should they (as they do) have a single URL, that maps multiple language versions to a single reference? And then what happens when they add another language... – Rob Hoare Apr 22 '14 at 1:33
  • Today's post from The Ancestry Insider: Monday Mailbox: Ancestry.com Consolidates Find-a-Grave Collections ancestryinsider.org/2014/06/… -- in which he mentions the trick of saving a file to the Shoebox first to get a shorter URL. – Jan Murphy Jun 23 '14 at 22:08
10

For some details of FamilySearch's PAL system (Persistent Archive Links), see "PALs that aren't PALs for long? A problem with some links in Massachusetts Land Records" on their GetSatisfaction site, submitted abt end March 2014 by user GeneJ. (And yes, I am aware of the irony of including a link!)

PALs are apparently FamilySearch's own technology, which were supposed to always link to the resource no matter what. The thread dealt with an instance where the links got broken - since FS committed to maintaining them, they will be fixing the broken links so they work again.

But apparently, FS intends to move (and I quote) "to using "arks" (an industry standard), and then hopefully stick with arks forever. But FamilySearch will still support all of the pals forever (i.e., by mapping them to corresponding arks)."

So arks(? ARKs? whatever - I do like the name...) seem to be the answer to the question, if we subtly rephrase it to refer to persistent linking to things on the web. And FS, for one, appear to be going towards using them.

None of which answers my objection to the plain unadorned use of PALs as they stand, which is that if I've got a PAL to something in FamilySearch and I'm using Ancestry (e.g. because I want to link it into my Ancestry tree), it's not much use to me. It's also not much good to me if I have a microfilm or even the original object in front of me. It needs to have a decent, human readable description of the object's location. (i.e. a readable citation). To what extent ARKs may suffer the same issue, I do not know.

Thanks to GeneJ and Randy Wilson on that linked thread.

  • thanks for that, this is going to be a problem with "persistent" urls - they'll persist until something better comes along! I see Familysearch are already listed as a provider on Archival Resource Keys (link in my question). ARKs do have an option to return metadata. About your FS/Ancestry point: if they (and others) each used persistent/stable urls for their own data, it would be possible to build a cross-reference between them (so, give the FS url, you could look up the cross reference, then find the Ancestry url - indeed as they work together they may already have this). – Rob Hoare Apr 22 '14 at 1:41
  • Unless the record URI is universally acknowledged (like the old OpenURL concept for publications) then I can't see the value of a standard. If a persistent URI is devised to address records of a specific collection, then the domain owner becomes the authority for interpreting and retrieving it, as with PAL. So what advantage does ARK have over PAL? Maybe I'm missing something... ? – ACProctor Apr 30 '14 at 20:17
  • @ACProctor - probably just the ease of maintenance of the software? Although somehow they need to deal with the existing PALs.... – AdrianB38 May 1 '14 at 9:07
2

Update to previous answer by @AdrianB38:

In a post (submitted byrraymondon Fri, 04/06/2018 - 17:28) in the discussion Using FamilySearch Citation on the Evidence Explained website, Robert Raymond says:

ARK addresses on FamilySearch are intended to be long-lived. It is our (FamilySearch's) intent to maintain them for "a long time." We recommend you incorporate them into your citations. Unlike DOI identifiers (which Elizabeth illustrates in Evidence Explained), ARK identifiers are expressed as URLs. Dropping the portion of the URL starting with the question mark does not affect the persistence of the ARK.

Elizabeth Shown Mills' response (submitted by EE on Fri, 04/06/2018 - 18:57) refers the reader to the relevant section in EE:

Incidentally, ARK citations to FamilySearch materials are illustrated at 9.55 and 11.55.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.