Using Permalinks in Citations

KBritanik,

If you take a look at this QuickLesson

https://www.evidenceexplained.com/content/quicklesson-12-chasing-online-record-its-rabbit-hole

and the Citation at the bottom of the page, you will see what a URL in a citation should look like.

Bottom line, for me, from Chapter 2 of Evidence Explained; Citing History Sources from Artifacts to Cyberspace is to use the "Home Page" URL.

So, in your example

Family Search (www.familysearch.org : accessed 03 Dec 2016)

would be the entry. I keep that Full URL in my database, just not part of the Citation. The reason, from my understanding, is that "what if the website changes the URL"? That is why we are encouraged to include that Accessed Date. Well, it was there on Dec 3rd, but it's gone. The rest of the Reference Note would be how you found that record.

Just my understanding and how I handle this topic.

Russ

I am doing some IT consulting for an archive that uses permalinks. Let me tell you, it is not easy to keep them "perma." There have been glitches when the data from an outdated system had to be migrated to a new system, which automatically generated new permalinks and it took a lot of effort redirect the old links. I can see how this could easily go wrong. 

I think using permalinks is great, but we should still include enough information in the rest of our citation to be able to find the source again if they break.

Personally, I use the long permalinks in my research notes but shorten them to just the root URL in publications. I like having the direct link in my notes to quickly access the record again and verify it is still working. 

I'm not suggesting a solution here, just making an observation.

If you cite something in an archive, you would include the codes by which it was catalogued, and you wouldn't just give its precise physical location in the building (although you might mention that it had to be retrieved from some external storage area).

It then seems wrong, then, that online resources are expected to be cited using their electronic location: the URL. If the online providers used an archival approach to their collections of images and transcriptions then the citation could specify them.

Also, a query-based URL (where there are parameters such as URL?name=value&name=value etc) can still provide electronic access to the item, but via the archival reference rather than the "location of the day".

As has been mentioned before, that "supermarket mentality" of having to continually rearrange stuff affects all of these sites, including the ones of the archives.

Tony

I’d like to add to this discussion and make a few suggestions. While “stable” URLs are somewhat of an oxymoron they can be stable for many years and, where possible, should be used in their shortened forms to provide direct links to pages and documents within online or PDF publications such as the various journals that are now frequently read online vs. printed forms. Of course additional information should be provided within the citation so that the documents may be accessed regardless of future URL modifications. The domain name and its TLD (top level domain, e.g., .com or .org) are less likely to change and is always at the root of the URL itself.

As such, I’ve spent a bit of time evaluating the name/value pairs within the URLs of some of the key sites and now use the shortened form in all URL citations as well as bookmarks. EE references the shortened form for FamilySearch with the use of the “PAL” URLs so below are those for Ancestry and Find A Grave that can be used in all situations:

Ancestry

http://search.ancestry.com/cgi-bin/sse.dll?dbid=1174&indiv=try&h=1466858

The only variables to change for every Ancestry URL are the dbid and the h. The value of the dbid can be found rather easily among all of the Ancestry databases. The value of the h can be a bit trickier, but it is within even the longest of all URLs one might find within the site.

Another example for a census record would be:

http://search.ancestry.com/cgi-bin/sse.dll?dbid=6742&indiv=try&h=42741427

or for a City Directory:

http://search.ancestry.com/cgi-bin/sse.dll?dbid=2469&indiv=try&h=843253739

Try this format for any database (dbid) and person (h) and evaluate for yourself.

Find A Grave

https://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=17182962

The only variable to change here is the GRid (grave ID) which also corresponds to the memorial number. This number can also be found among any searches for graves within Find A Grave.

For an example of a citation see below, but note that at the beginning of any report a simple statement of when the URLs were accessed will suffice to replace the “accessed” position of the citation, thus it has been omitted in this case. In fact, the length of the parenthetical statement containing the URL is about equal to that of the formerly used URL and accessed date within said parenthetical:

Find A Grave (https://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=17182962), memorial 17182962, Rev. John Baptiste Laurens, Woodland Cemetery, Ashland, Hanover, Virginia.

Alternatively:

Find A Grave (findagrave.com), memorial 17182962, Rev. John Baptiste Laurens, Woodland Cemetery, Ashland, Hanover, Virginia.

The alternative one has shortened the URL further to the root and hyperlinked the memorial number.

Again with an Ancestry census record:

1880 U.S. census, Hanover County, Virginia, population schedule, The Town of Ashland, ED 62, p. 9, dwell./fam. 52, John B. Laurens; digital image, Ancestry (http://search.ancestry.com/cgi-bin/sse.dll?dbid=6742&indiv=try&h=42741427); citing National Archives microfilm publication T9, roll 1370.

Alternatively:

1880 U.S. census, Hanover County, Virginia, population schedule, The Town of Ashland, ED 62, p. 9, dwell./fam. 52, John B. Laurens; digital image, Ancestry (ancestry.com); citing National Archives microfilm publication T9, roll 1370.

Again the the alternative has the shortened URL and the name of the individual hyperlinked.

In this way, all journals read in online or PDF form would allow the reader to click the shortened link directly to the page desired, but it would also allow for the search of the record by the input of key data should the URL change in the future. Therefore, whether online or printed the source data is easily accessed and understood.

This is how I handle it, and it would be nice to see the NGSQ and others adopt this, but it may not be for everyone. Nevertheless, it is a better solution than what I have seen. I have many other shortened website forms and am happy to share those.

EE,

I have used these same URLs as bookmarks and within citations for many years now, perhaps as long as ten. They have not changed. I have also used “PAL” and “ARK” ones from FamilySearch although their URL structure differs from Ancestry and Find A Grave and I will explain those separately, but the quick version is that PAL (Persistent Archive Link) is being moved to to a more industry standard of ARK (Archival Resource Key). Just note that both PAL and ARK forms will be around for a long, long time.

For search page results, such as those I posted for Ancestry and Find A Grave, the key is in the use of the numeric IDs for the variables. Whereas the name of any data collection can and should change, such as when the year ranges are elongated to accommodate new data, the numeric value of the data collection stored within the database will not change. This is key to any data architecture.

I will explain a bit more with some examples and further suggestions for improvements.

Ancestry appears to be in the process of modifying its db variable. I believe that within its search results Ancestry mistakenly began using the db variable with the value being a text form of the database being used (e.g., “USpassports” or “1880usfedcen”) although they may have stored the actual dbid within the database. It is unwise to pass a text parameter that is a database identifier in a URL to begin with - far better to use its corresponding numeric value.

In the examples above I used the following for an Ancestry “U.S. Passport Applications, 1795-1925” database:

http://search.ancestry.com/cgi-bin/sse.dll?dbid=1174&indiv=try&h=1466858

The dbid variable is being used to represent the “U.S. Passport Applications, 1795-1925” database. However, the old text db variable can still be used:

http://search.ancestry.com/cgi-bin/sse.dll?db=USpassports&indiv=try&h=1466858

Note the text passed with the db variable, but also note that we have begun to see Ancestry allow the db variable to pass the numeric value of the database as well. Thus the following also works and is beginning to work for all databases (it may work for all of them now, but I have not tested each one):

http://search.ancestry.com/cgi-bin/sse.dll?db=1174&indiv=try&h=1466858

All three of these links take you to the same exact page at this time. Ancestry may have realized an issue and is attempting to remedy it, but the bottom line is you should be able to use the above shorted format for dbid or db with its associated numeric value for quite some time. The h variable for the specific individual remains constant

Again, it is important to note that while database names (and other text fields) may change, their corresponding numeric values will not.

In some cases Ancestry will force old databases that contain redundant or older data to point to one that is newer and perhaps more comprehensive. For example, there are several Civil War databases within Ancestry:

“American Civil War Soldiers” - http://search.ancestry.com/cgi-bin/sse.dll?db=hdssoldiers&indiv=try&h=5047198

“U.S. Civil War Soldiers, 1861-1865” - http://search.ancestry.com/cgi-bin/sse.dll?db=nps_civilwarsoldiers&indiv=try&h=5243298

“U.S., Civil War Soldier Records and Profiles, 1861-1865” - http://search.ancestry.com/cgi-bin/sse.dll?db=civilwar_histdatasys&indiv=try&h=97538

Note that all those URLs use the db variable with the text value of the corresponding database, but these could also be used by passing the much easier, more desired, and more permanent numeric value.

Especially note that when clicking the first URL for “American Civil War Soldiers” and then clicking again the name of the database directly underneath the “John Laurens” result, which is the title, it will take you to the search page for the newer, more comprehensive database in the third link above, ““U.S., Civil War Soldier Records and Profiles, 1861-1865.” In fact, “American Civil War Soldiers” can’t be located in the Ancestry card catalog, yet it is still there behind the scenes. Thus Ancestry is directing its user base toward what it wants to show going forward:

“U.S., Civil War Soldier Records and Profiles, 1861-1865” - http://search.ancestry.com/cgi-bin/sse.dll?db=1555&indiv=try&h=97538 (Note this link is using the numeric value of the db variable).

All Ancestry databases use this simple URL structure which is common for relational database structures. Of course any user submitted data, such as “Public Member Trees” are stored in a typical folder directory structure separated by the “/“ - so a tree may be https://www.ancestry.com/family-tree/tree/52173120/ for example, but still uses a number at the end to designate the specific tree.

Find A Grave is far simpler since it contains only one database and the minimum search parameters to achieve a result set were given in my earlier post.

Each site may do things different due to the technology being used. As mentioned at the beginning FamilySearch uses PAL and ARK - in some cases interchangeably - but ARK will be the long term version. However, the PAL links will not disappear any time soon - if ever.

I can go into more detail as desired, but hopefully that helps.

EE, 

I neglected to include a link detailing ARK with more information than may be desired!

https://confluence.ucop.edu/display/Curation/ARK

I am sorry for the revisions due to the mutability of the sites you reference. The web is eternally epehemeral - a true oxymoron.

Regards,

Having perhaps said too much already I will risk saying a bit more with some FamilySearch examples and thoughts. As previously stated, the FamilySearch pal format is being transitioned to the ark standard. Here is an example of both pal and ark links that provide the same page, a result set from “Georgia, County Marriages, 1785-1950”

PAL - https://familysearch.org/pal:/MM9.1.1/KXJ4-P37

ARK - https://familysearch.org/ark:/61903/1:1:KXJ4-P37

FamilySearch provides the ark link within its citation on each page since that is where it wants all “long-term” links going forward. The citation would be as follows for ark (again remembering the date accessed is presented at the beginning of each report):

Franklin County, Georgia, Marriage Book 1805-1826, p. 163, Wm. Williams and Jinsey Holbrooks, 24 August 1815; image, “Georgia, County Marriages, 1785-1950,” FamilySearch (https://familysearch.org/ark:/61903/1:1:KXJ4-P37).

Of course there are several images within FamilySearch that can’t be found via the search of a database, but only by browsing the images as one might browse a reel of microfilm. In fact, in the case above the marriage entry was recorded based upon the original marriage license and return, which is only found by browsing and cited thusly:

Franklin County, Georgia, Marriage records, 1806-1905, William Williams and Miss Jinsey Holbrooks, 24 August 1815; browsable film 2188932, “Marriage records 1806-1905 Wall, John - Yow, T.R.,” images 650-651, FamilySearch (https://familysearch.org/ark:/61903/3:1:3Q9M-C912-WQRC).

In this way, an online reader (via web or PDF) can link directly to the image cited, and a print reader can visit FamilySearch and enter the film number, find the subset with the range stated, and select the image numbers to see the actual images themselves.

Alternatively (and my preference), a shortened form would be:

Franklin County, Georgia, Marriage records, 1806-1905, William Williams and Miss Jinsey Holbrooks, 24 August 1815; browsable film 2188932, “Marriage records 1806-1905 Wall, John - Yow, T.R.,” images 650-651, FamilySearch (familysearch.org).

I’m sure EE might make further suggestions, but this is my own preference, and I believe it thoroughly covers the goal of the citation.

Thanks for the indulgence!

EE,

Ah the software citation templates, well intended, not so well executed although they have improved. I prefer free-form entries due to software makers proprietary nature, conflicts with GEDCOM transference, and general errors. Nevertheless, these are beneficial, and, with technical improvements, will  be perfected over time.

It would be best if the current locally installed software were instead SaaS (Software as a Service) or fully cloud-based. Architecturally, that is where we have been headed and why there have been recent changes. In this way changes can be made quickly, and conflicts with versions, various OS, and other variables mitigated or eradicated. More importantly, software of this type can employ machine learning algorithms that use statistical and predictive analyses as part of an overall AI that learns. While this is useful for companies that want to present you with customized data (Facebook) or to purchase something (Amazon), it can be employed for citations also.

People currently struggle with the citation template selection and then with the input of the details. What if by using the machine learning AI described above this is automated based upon the collective knowledge within the system? For example, as a person comes across a page of a book (online or off) that is relevant to their research a simple entry of any partial data related to that book - part of an author, title, etc. - would know that this book is cited in x manner and creates it for you. Even if it hasn’t been used before it can detect that this is a book and should be cited accordingly. No template needed. Someone can still add descriptive language or additional info (and even that can be machine learned), but you get the picture. Widely cited data such as a census would use these techniques to automatically provide what has and should be used - instant conformity and standardization.

Similarly, with existing online repositories like FamilySearch and Ancestry, when a person wants to cite a census, a citation or source link (directly or indirectly) can populate the URL and all pertinent citation information in the proper format. This isn’t that far-fetched, especially given the collaborative efforts among the various software makers and these online repositories. Open source AI can make this happen very quickly. Under this scenario, nearly all of the problems encountered by EE and software makers as template authors/creators and individuals as template users disappear.

I know people will fret about privacy, but this is still one’s own research, with better security and preservation. Best to remember that apart from privately held artifacts (and other exceptions) data is public, but the interpretation of data, our research, resides in the realm of intellectual property.

Ok, now to return to your specific statements and questions in the present! My focus is on improving citations as we transition from the age of Gutenberg to the age of Berners-Lee (Tim, inventor of the Web). The basics of EE generally follow the standard of author/owner, title (publication details, URL), locus/pertinent details, and I think that works for most things as well. Of course, as EE notes, when citing republished data on the web, such as a book, the owner/URL are at the end of the citation since the emphasis is on the “original” data. Same with an online census or newspaper - the owner/URL are at the end.

Even online marriage images within EE follow this format and I think this is the key. That is, if I am citing an online database - not an “original” online image - then the standard format of author/owner, title (URL) at the beginning is followed. However, if the reverse is true and I am citing an original online image then the URL component is at the end. Now I know there are oddities and exceptions as always - for example, when an online book has been parsed into a database (not scanned or OCRd) as Ancestry has been wont to do. In those cases I will still focus on the “original” image first with the URL at the end, including an “entry for” appended. (See http://search.ancestry.com/cgi-bin/sse.dll?dbid=61175&indiv=try&h=13772 as an example).

If the question is whether all online citations have URLs placed at the beginning or end I will defer to EE who has more expertise. In my experience, proper technical architecture can accommodate anything intuitively. Again, my primary goal is to ensure we allow for online citations to be linked directly when read online or in PDF form. Currently, not enough of that is happening within these publications.

Thanks again!

EE,

No issue on my part. Perhaps "end" is a poor word choice since the intent was to clarify what was not at the "beginning" in response to your comments about "front-loading" data. I may have misunderstood your intent in that regard, but I agree with the layered concept and use it accordingly.

I would enchance your example however for any electronic format:

“Muster Roll of the Field Staff and other Commissioned Officers in Colonel Goose Van Schaick’s Battalion of Forces raised in the State of New York and now in the Service of the United States of America, Dated in Barracks, Saratoga, December  17  1776,” for Daniel Budd, Adjutant; consulted as “Revolutionary War Rolls,” database with digital images, Fold3 (http://www.fold3.com : accessed 4 September 2014), images 10188247, 10188258, and 10188267; citing Revolutionary War Rolls, 1775–1783, National Archives micofilm publication M246, roll 77.

In this way one can directly access the desired image/s online. Same as I've been describing further up. Also, since Fold3 doesn't allow searches using the input of image numbers directly it makes more sense than only having the root website hyperlinked.

Just my thoughts and prefs.

Regards,

Many thanks for the discussion EE. This is helpful and I've learned much also. I am certain that process will continue. To this point I have remained on the periphery of the sphere of family history due to my work life, at times living abroad, and my young children. I suppose this is an emergence of sorts. I look forward to more interaction.

Regards,

This is a quick update to the URL standard for Ancestry I described above. The indiv/try name/value pair in the URL continues to work successfully as found in the example below:

http://search.ancestry.com/cgi-bin/sse.dll?dbid=1174&indiv=try&h=1466858

But now Ancestry also allows for a more streamlined binary yes/no value of "1" as well as the "try":

http://search.ancestry.com/cgi-bin/sse.dll?dbid=1174&indiv=1&h=1466858

As before, this works with all Ancestry databases.  Some examples are below:

http://search.ancestry.com/cgi-bin/sse.dll?dbid=6742&indiv=1&h=42741427

http://search.ancestry.com/cgi-bin/sse.dll?dbid=2469&indiv=1&h=843253739

Or any other Ancestry database one wishes to use.

I actually prefer the "1" since it is more accurate programming to answer the yes/no of whether to display the single page for an individual or not. In the simplest of terms, Ancestry is passing the database ID value, whether to display the page for a individual, and which individual to use. That corresponds to the three name/value pairs in all Ancestry database URLs.

Finally, in my case, a simple find and replace of the indiv=try with indiv=1 in URLs was done to mirror this preferred format.

Regards,

Like Robert, I often analyze URLs to see if I can understand the logic behind the parameters they use, and if I can use that knowledge to my advantage. 

For example, the Amsterdam City Archves has an "x" parameter in the URLs of their index pages that identifies the index you're currently searching. Through the normal website, these indexes can only be searched one at a time (see https://archief.amsterdam/indexen/index.nl.html). I have discovered that if you set the "x" parameter to 0, it will search all 30+ indexes with one query. Very useful to quickly see which indexes have hits. I will then repeat the search using the regular search interface and cite that for any results.

I have confirmed with the Amsterdam City Archives that this is indeed a hidden feature of the website but since the resulting display is a bit mangled they don't advertize this widely but power users are welcome to use it.

My problem is how to cite negative results from my "hacked" search. This is not a page that you would ever get at during normal use of the site; you have to manually change the URL to search all indexes at once. I think my citation would look something like this:

"Indexen" [Indexes], parameterized search query for "Hoitink" using x=0 to search all indexes at once, Gemeente Amsterdam Stadsarchief (https://archief.amsterdam/indexen/archiefkaarten_1939-1994/zoek/query.nl.pl?i1=1&a1=hoitink&x=0&z=a : accessed 20 April 2017). Note: this query is not available through the regular interface but only by changing the x-value in the URL to 0. 

I would welcome any thoughts!

Sounds like a plan :-) 

Heavy citation user here! (BU alum, ProGen member, client report author, and journal-writer wannabe)

And former web developer and interface designer.

With my web background and my strong desire to get genealogical writing right, I constantly struggle with the URL thing. I have waffled between obeying our agreed upon standard (EE) and embracing permalinks. I respect our citation standards because of the consistency they provide to our readers. I am excited about the promise of PAL and ARK, but other tech failures have instilled me with caution. My designer brain wants everything to look clean, clear, and approachable.

The argument I keep having with myself about this situation is this — if my citation provides enough information about my online source so that a person reading a printed copy of the report (and therefore, not possessing the hyperlinks) can easily access that source, do I really need to agonize over the link?

And assuming the hard-copy person has no trouble, the online reader, with the links available, should be ahead of the game. So, my conclusion each time I go through this argument (and I do go around with it) is that the generic URLs coupled with the standard Author, Title, Publisher info, Page Number, etc., per EE's examples, work best. Often, I do include the Ancestry path or other methods of wayfinding if the item is deeply buried.

One thing I do take liberty with is the regular long-form URLs (http://www.ancestry.com). In my humble opinion, both those and the shorter permalinks LOOK AWFUL on a printed page. There, I've said it. Nothing is more jarring to my eye than seeing slashes, question marks, ampersands, equals signs, and long strings of digits in an otherwise aesthetically beautiful report page. Latley, I have started shortening my generic links to the bare working minimum, substituing ancestry.com for the standard because it looks so much cleaner. I see that Robert Laurens and others do this as well.

So, no, I do not like permalinks. I do not trust their longevity and I dislike their jumbley look. I think Robert Laurens is genius for incorporating the direct hyperlink to the source within his citation, hidden behind identifying text that would be there anyway and plan on adopting that idea.

Sincerely,

Teresa Kahle

In reports, I use the short URL as link text in and the permalink as the link. Something like FamilySearch (http://familysearch.org : accessed 1 May 2017) using Ctrl-K in Word to edit the link text. For me, that's the best of both worlds.

Teresa - Thanks for the comments and kind words. That is the direction in which I would prefer we move as more items become available - and are consumed - online. Quarterlies and websites should provide direct links to sources while still allowing an offline reader to understand the source and locate its origin. This can be done in a clear and visually clean manner.

I have been doing this for many years now, but wanted to share some of my findings. I will list some examples of various online sources below in order to provoke thought, invite criticism, and seek improvement. Of course, these are my own preferences:

Ancestry - Census:

1870 U.S. census, Petersburg City, Virginia, pop. sch., 6th Ward, 1st Dist., p. 34, dwell. 283, fam. 319, John B Laurens; images, Ancestry; citing NARA microfilm publication M593, roll 1643.

*Note that a) the person of interest is directly linked with a shortened URL; and b) Ancestry, being a website itself, is linked to the homepage and should not require the explicit listing of the URL given its notoriety.

Ancestry - City Directory:

Woods' Baltimore City Directory 1867-68 (Baltimore, Maryland:  John H. Woods, 1867), p. 302, entry for "Laurens J.B."; images, “U.S. City Directories, 1822-1995,” Ancestry.

*Note again the direct linking to the subject in question via shortened URL.

Internet Archive - Book:

Edwin M. Snow, Charles V. Chapin, Dennett L. Richardson, eds., Alphabetical Index of the Births, Marriages and Deaths Recorded in Providence, 25 vols. (Providence: Sydney S. Rider, 1881), 3:25; images, Internet Archive.

*Note the actual page is linked and the homepage of the Internet Archive.

Fold3 - Multiple Images:

Compiled Service Records of Confederate Soldiers Who Served in Organizations from the State of Virginia, John B. Laurens, Capt., Co. E, 41st Virginia Inf.; images, Fold3, pp. 18, 24; citing NARA microfilm publication M324, roll 865.

*Note that the first page of the set of images is linked to the name whereas the actual pages of interest cited are linked directly to the page numbers. While Fold3 has URLs that contain image numbers, these image numbers are not found within the site itself, thus the page numbers, which are seen, are used.

Newspapers.com (or any newspaper site):

"Benefits of Life Insurance," The Petersburg (Virginia) Index, 29 March 1871, p. 3, col. 2; images, Newspapers.com.

*Note that the article itself is directly linked

Find A Grave:

Find A Grave, memorial 17182962, Rev. John Baptiste Laurens, Woodland Cemetery, Ashland, Hanover, Virginia.

*Note that either the memorial number, which is contained with the URL directly linked, or the name of the person of interest can be linked. The memorial numbers do not change since they are database derived, but names can since they are based on user input.

FamilySearch - Marriage:

Franklin County, Ohio, Marriage Book 6:336, Augustus B. Laurens and Mary Jane Washburn, 3 February 1857; images, “Ohio, County Marriages, 1789-2013,” FamilySearch.

*Note that I have linked directly to the page where the names are found in a database format with the image available to select. The image itself can be linked as well.

General, less known website, that is more susceptible to rapid change:

McColaugh Funeral Home , Frances Elizabeth Laurens (http://www.mccolaughfuneralhome.com: accessed 9 March 2015), obituary.

These are just a few examples and while not perfect, are helpful to me and I hope to others as we move towards more online reading and reviewing of information.

The refinement and improvement will continue...

Regards,

Robert

Find A Grave has formally released changes to their site and this includes the default URLs. Therefore, I am updating this thread with new URL details. The simplest form of the old URL was:

findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=17182962

Note that this still works and will for quite a while, but the site redirects you to the newer URL format of:

findagrave.com/memorial/17182962

The memorial ID discussed in above posts remains the key identifier present in both URL formats. A simple find and replace in all bookmarks and source citations can be done as follows:

Find: cgi-bin/fg.cgi?page=gr&GRid=

Replace: memorial/

This is a welcome change that places the technical infrastructure in a more modern state. I see some Bootstrap and other code behind the scenes. Also, with this being similar to a Fold3 URL I'd expect Ancestry to update their tech stack and URLs in the near future.

Regards,

Robert