Individual Document as Part of a Probate Packet

I found a probate packet related to the Sale of Real Estate from 1841 on Ancestry. It contains several documents and I'd like to cite each of them separately but I  am not exactly sure  I know how to make I show that it's part of a packet. I looked at 10.31 and 10.33 for inspiration and if I understand it correctly I would name the packet first and then the document of interest.

The packet doesn't contain a case file number or anything like that so I don't know if I should cite the titles exactly or if I should use generic description. In this case I wound up doing both, but I couldn't tell you if I got it right. Am I missing anything here?

Queens County, New York, "In the Matter of the Real Estate of Nathaniel Rider, Deceased, Petition for Sale," Appointment of Guardian, 27 May 1841; imaged in "New York, U.S., Wills and Probate Records, 1659-1999," Ancestry ( : accessed 6 June 2021) > Queens > Sales of Real Estate, 1834-1842 > images 376-377 of 472; citing " New York, Queens County, Sale of Real Estate Records; Author: New York. Surrogate's Court (Queens County); Probate Place: Queens, New York."

Submitted byEEon Mon, 06/07/2021 - 10:02

Hello, Hendrickson.  Of the two EE sections that you cite, for a probate packet EE 10.31 (Basic Formats: Loose Papers) is the only one applicable. EE 10.33 is for an online database that has no images—i.e., a database by some provider that just extracts names, etc., in which case we would be citing a creation by that provider, not the original files.

Now things get more complicated. The images you are citing at Ancestry are not within a “probate packet” for Nathaniel Rider. When we study the documents imaged before and after this document of interest, we see that

  • There is no probate “jacket” (a cardstock envelope of sorts) in which all of his papers, of various types, would have been inserted. That jacket, with documents inside, is the entity that is called a “packet.”
  • Instead, someone has assembled a collection of loose documents called “Sales of Real Estate, 1834-1842” by removing documents from packets and sorting them according to type of record—commingling everyone in that time frame into one big “batch” of documents that are related by subject matter, rather than keeping together all papers related to one probate.
  • In this collection, we have the documents that deal with sales of real estate. There would normally be a variety other documents relating to other legal actions taken in the probate of Rider’s estate. Those would seem to be in one of the other thousand or so “collections” created for Queens County probates.

Bottom line:

  • You cannot cite this in the manner in which you would cite an individual probate file you accessed in a courthouse. The organizational structure has been altered. Neither the images nor the provider’s source data gives you a probate case number or file number by which you could cite the packet for the case.
  • What you are left with is citing Ancestry’s database and its structure.

"New York, U.S., Wills and Probate Records, 1659-1999," database with images, Ancestry ( : accessed 6 June 2021) > Queens > Sales of Real Estate, 1834-1842 > images 376-377 of 472, administrators’ bond, estate of Nathaniel Rider; citing Queens County Surrogate's Court, Queens, New York.

You will notice three differences between this and your draft:

  1. Between the collection name and the website title, I’ve used the database-descriptor field to state that the collection we’re dealing with is a “database with images.”
  2. For its source data, Ancestry has a lot of words that repeat itself. In the source-of-our-source field, EE would strip Ancestry’s words down to essentials rather than exactly quote the wordiness.
  3. For the actual document, you’ve cited images 376 and 377 as “In the Matter of the Real Estate of Nathaniel Rider, Deceased, Petition for Sale.”  Those words do appear on image 376, which is the backside of one of the documents in the file, but 377 does not image the petition. It images the administrators’ bond. The actual petition is at images 382–85.

When this file was filmed, it was not filmed carefully. What we have at each image is this:

⦁    376 :  Backside of the folded court order that was issued in response to the petition
⦁    377 :  Administrators’ bond
⦁    378 :  Backside of the folded bond
⦁    379 :  A short scratch sheet, showing part of the next document
⦁    380 :  Court order in response to the administrators’ petition to sell
⦁    381 :  Court order, p. 2
⦁    382 :  Petition by administrators, asking to sell the property.
⦁    383 :  Petition, p. 2
⦁    384 :  Petition, p. 3 (a “schedule” attached to the petition)
⦁    385 :  Backside of the folded petition
⦁    386 :  A mortgage on the property, previously made by Rider
⦁    387 :  Bottom half of the oversized mortgage
⦁    388 :  Page 2 of the mortgage
⦁    389 :  Bottom half of p. 2 of the mortgage

You’ve given us a very instructive  example of why we have to analyze the content of each image rather than “just trust” that the film crew (or a book binder when documents like these are assembled into registers) has arranged things in proper sequence.

Submitted byHendricksonon Mon, 06/07/2021 - 11:33

I think I managed to confuse both you and myself by using the images numbers that I did. The so-called 'packet' actually starts at image 353.

What I actually quoted was that first image — what Ancestry is calling the 'cover'. Then as an item of interest on image 376 is the cover for the Appointment of Guardian. It appears that the page before 375 is related to guardianship, not 377 as I had in my citation. 

You are right though - its not imaged carefully and its hard to tell which papers belong together. I also saw mention of a special guardian on image 356. 

Thanks for being the voice of reason.

- Sloppy

Submitted byEEon Mon, 06/07/2021 - 13:23

Hendrickson, yes, the set of records start at image 353—but we still have no "packet" to cite, thus the restructuring of the citation to focus on the Ancestry database rather than the packet that would have been created originally.