Welcome to the Digital Data Stories of the Alexandria Archive Institute and Open Context! In this Data Story Short, you’ll build your own data set, in a spreadsheet, using notes from archaeological recording forms. This will turn these organized notes into structured tabular data. Structured data are data that can be filtered and/or easily read by a computer.
For this short, you’ll need a set of digital or physical archaeological forms. These can be site, level, or finds forms, or any other set of documents that structured someone’s observations. You can find copies of the forms illustrating this short here and see the Credits section for specific links. You can also create your own set of forms to use in this exercise by completing Learn to Conduct a Basic Archaeological Survey. You’ll also need a spreadsheet program where you will enter your data. For reference, all the screen captures that include a spreadsheet in this exercise were created in LibreOffice Calc but Google Sheets or Microsoft Excel work too.
The structure of an archaeological form
Before you start entering data, you’ll want to examine your form. It probably looks like a hand-written form you might encounter in daily life, with exception of the archaeology-specific vocabulary. What’s cool about forms is that rather than taking notes on whatever the recorder happens to notice, forms guide observations to focus on what the data creators want to record. So, read through your forms and consider the following questions:
- How many different sections are there in this form?
- Are there any boxes that contain words I’m not familiar with? Where could I look to see what those words mean?
- In the sections that use vocabulary I’m familiar with, how would I fill those out?
- Are some portions of the form blank, not filled in, or crossed out?
- What are some different ways people recorded their observations? What parts used numbers, written descriptions, drawings, lists, checkboxes, or some other recording method?
While archaeological forms that record the same kind of thing often have similar styles, they don’t always use the same vocabulary. Thinking about the above questions helps us see past the specific vocabulary or structure of a form to the similarities between them, focusing on what they record.
In addition, taking the time to explore a form helps you to understand its limits. No matter what questions you have, you can’t ask them if the data recorders didn’t capture that information. So it’s important to get to know what the form did record while keeping in mind what it didn’t.
Make sure that you read forms, plural, as you answer those questions. Looking at a couple different copies of a completed form, before committing to a particular structure for your data, is important because you want to design your digital structured data in a way that reflects and captures how people used the form. Often, basing structured data tables off a blank form (or only one filled out copy) means changing your data structure as you realize the discrepancies between your ideal table and the reality of how people recorded their observations in the forms you’re translating and transposing.
With this in mind, keep exploring your forms or scrutinize the examples below to see how recorders at the site of Gabii used their forms.
The example forms highlight differences in recording, despite the fact that each contains the same boxes. We’ll want to remember this as we consider our headings and rules for data entry. In addition, it’s clear from these examples that the folks working at Gabii created a lot of data in these documents, as did the folks who filled out your forms.
So, for this short, rather than represent everything captured by your form, focus on turning the notes and observations from a couple boxes or sections into structured data rather than every single one. Once you’ve had some experience transposing those data, you can apply them to any remaining sections as further practice.
Parts of a table
Now that you’re more familiar with your forms, you can consider how to structure different parts of the table. This is the point where we want to emphasize that we’re not creating a digital version of the form, like a typed up replica (or for the technical folks, an OCR’D PDF). We’re transposing the notes from a data format well equipped for capturing data in the field (the form) into structured data (a digital table) that allows for filtering, computer reading, and analysis. The goal is to be able to look at observations from multiple forms in a way that allows us to begin to see patterns.
We do this by transposing and translating the notes from the forms into one of two axes of information in the structured data table. The first axis are the things the form creator wanted people to record. You can think of each labeled space, section, or box to fill out on the form as part of this axis. These are referred to as headings, fields, columns, or attributes in a data set. You should only record these once because they provide the structure for the other observations.
The second axis are the actual things people recorded. These are the notes within those spaces, sections, or boxes and are known as the entry, row, or observation. These refer to the specific thing that someone observed and the particular attributes it had, which the recorder hopefully recorded when they filled in the form. These are the data you’ll be entering into the rows under our headings, building our table from each form.
Identifying and selecting our headings
Equipped with this information, you’ll need to pick which headings you’ll want to focus on for this exercise. However, the first step for this is identifying what is and is not a heading in your form.
Looking at the examples, there are WORDS IN ALL CAPS AND BOLD and others are Words In Camel Caps That Are Italicized And Bold printed on every sheet. These formatting differences separate primary headings from secondary headings and each will want their own columns if you include them. Now, read through your forms and identify their primary and secondary headings. Then, record what signals you used to identify them. For example, were they bold, italicized, Capitalized In A Specific Way, or in a different color?
Now take a look at this SOIL/MATRIX box from the example form. Based on the multiple, labeled boxes within it you can tell it has multiple headings associated with it. Does your form have any areas that indicate related primary and secondary headings? If you choose to include one of those in this exercise, it will need a more detailed name to identify the specific data it records. You also want to be consistent about how you name secondary headings so that you can identify related headings and separate primary from secondary headings.
For most data transposed from forms, it’s better to include more headings than less. That’s because it’s easier to recombine data in a clean way (meaning consistently and with fewer errors) than separate it after the fact. So, as you identify headings for your digital data table, consider separating sections, boxes, and observations within boxes into their own headings to create cleaner structured data.
Now that you’ve explored your forms’ headings, pick a few to use as practice for building a data set. In the following examples we use the boxes at the top of the page and then those from the DESCRIPTION box. If you’re not using a form like the examples, pick sections of your form that will create ten or fewer headings total for this exercise and use vocabulary you are familiar with. Once you know what sections you’ll turn into headings, you can start creating your table.
Setting up our table
Now that you know what headings look like in your form and have picked the ones you’ll use for the exercise, you’ll need to open a new blank spreadsheet in your preferred program. If you don’t have a preferred spreadsheet program we recommend LibreOffice Calc, Google Sheets, or Microsoft Excel.
In that document, type your headings into the first row. For the examples, we’d put SITE in the box located in the first column and first row; YEAR in the next column and same row as SITE; AREA in the next box over, and then SECTOR in the next. These headings are straightforward because they don’t have any secondary headings or special features. Now, in your spreadsheet type up the headings you picked that lacked secondary headings or special features in the same way. Pause to read the next part after you get to a more complicated heading or have typed up all your headings.
In the examples, we paused when we got to ELEVATION. That’s because within the ELEVATION box there were two secondary headings, “Min:” and “Max:”. They’re both about elevation but capture different things. Looking closer at the box, it appears that people recorded the observations for each just like our primary headings, so all we need to do is create two headings, ELEVATION_MIN and ELEVATION_MAX, one for each observation. If you’re not using the example forms, look at the sections you’re using for headings. Are there any that will need to be separated into multiple headings? If so, how many?
For the examples, we also paused at the STRATIGRAPHICAL UNIT box. It also has two pieces of information but people recorded the observations differently. For one section, people recorded a number and in the other they checked a box. Knowing this, we made a STRATIGRAPHICAL UNIT NUMERIC heading and a STRATIGRAPHICAL UNIT TYPE heading to capture the different kinds of observations. Based on these examples, how would you deal with the DESCRIPTION box from the example forms? If you aren’t using the example forms for your own practice, apply these rules to your form now. Are any of the sections you picked like these examples? What will you call the headings from those sections?
Deciding to separate sections of a form into their own headings is tough because fewer headings make it easier to type things up but more headings add detail to your table, creating a better chance of noticing patterns in various attributes. With this in mind, what sections of your form need multiple headings? Now, make sure to type those up before moving on.
Establishing standards for clean data
Now that you’ve added your headings, examine how you named them. Typically, you’ll want to reuse the forms’ names so people can see how the data table transposed and translated the form. However, for the other headings—like those taken from the same box or within a larger named section—the heading should reference the primary section or box on the form by including it within the secondary heading’s name. That way folks can identify related headings and attach them to the section of the form they came from. Using the ELEVATION and STRATIGRAPHICAL UNIT examples as a model, update any headings in your table that don’t reference the name of the primary section or box they came from.
For headings that lack a name on the form, you’ll want to reuse the capitalization and formats established by the existing headings to create standard naming protocols in your table to indicate relationships between headings. Furthermore, you want to be consistent with how you use things like capitalization and spaces in those headings to establish clean data entry standards for this table. The more consistent you are in your headings, the more consistent you’ll be when you start data entry. That consistency means you’re more likely to create clean (aka reusable, standardized, and consistent) data from those forms.
To keep track of standards and clean data principles for your table, we (the authors of this short) encourage you to add a README sheet like that pictured below. At its most basic, a README allows you to provide context for the data table by organizing and explaining the decisions you made for its structure. For those who want more explanation than that, read about READMEs here.
Deciding a heading data type
Ok, back to creating our data set. With the headings in place, we’ll use them to establish our “data types” for the observations we’re entering. Data types are another clean data standard and define how the computer stores observations. If you want to learn more about data types check out Gabbing About Gabii. For this short, follow this decision tree to establish the data type for your headings:
Is the recorded observation a number?
No, then it’s text.
Yes. Ok, is it a whole number or one with a decimal point?
It’s a whole number, then it’s an integer.
If it has a decimal point, it’s a float.
With these three types in mind, the next clean data rule is that if you establish a heading’s data type as an integer or a float, use a numeral (number) to symbolize it every time you enter an observation under that heading. If that heading’s data type is not a number, use consistently spelled, capitalized, and punctuated text when you enter observations under that heading. Finally, note these rules in your README.
Note: When we say “every time you enter an observation under that heading” we mean it. This is another spot (like with adding headings) where data entry is about transposing and translating forms, not replicating them exactly. While this seems easy to do when the first three forms all use numbers in their version of a particular box, it’s important to stick to your rule when someone decides, on a whim, to fill out that same section with a Roman numeral or spell out a number instead. It happens and, when it happens to you, resist the urge to change your data type because of one rebellious recorder. The only acceptable alternatives are blanks or N/A variants. See our section on those options here.
With that out of the way, we’ll walk through some examples of how to decide a heading’s data type and rules for entering observations under that heading. We explain these decisions for the following headings:
YEAR
AREA
SECTOR
ELEVATION_MIN
STRATIGRAPHICAL UNIT NUMERIC
STRATIGRAPHICAL UNIT TYPE
DESCRIPTION_PositionWithinSector
DESCRIPTION_Shape
While names can indicate a heading’s data type, always look at a couple of forms before deciding, just in case the name didn’t mean what you thought it did (see AREA in our examples).
YEAR is the year of the project. Or at least we assume so based on context. YEAR is always a whole number, so it’s an integer. When we enter this, we’ll default to using four digits, even if the paperwork only noted two. While that’s not an exact representation of the recorder’s notes, four digits ensures that someone analyzing the data (or a computer) doesn’t mistake 2010 for 1910 or 10 AD or autocorrect it to a different date. This is one example of why one should prioritize sticking to our data type rules and doing consistent data entry rather than exact replication.
AREA seems to be where people put the named region of the site the form observed. That means it is not “area” as in multiplying the width times the length. Based on a couple of forms, it’s usually a single letter. That means it’s a text. We’ll choose to always enter it as a capital (mentioning this in our README) so no one confuses lowercase L’s and uppercase I’s. Another spot where creating rules for data entry is important.
SECTOR looks like it’s often blank, so we didn’t set any rules. Instead, see some examples of how to deal with blanks in a subsequent section.
ELEVATION_MIN is where they noted the minimum elevation for…something and then recorded it to a number of digits past the decimal. This means it’s a float. However, comparing forms told us that people recorded ELEVATION_MIN with different levels of accuracy, including three and sometimes four digits after the decimal. For consistency, we’ll default to the largest number of digits past the decimal included in our forms to capture that accuracy where present. We’ll note in our README that an ending zero may not signal extra accuracy in the case of this measurement.
We’ll pause here in our headings and rules because ELEVATION_MIN should have units. Without them we don’t know if they measured elevation in millimeters (mm), centimeters (cm), or even meters. Examine your form, are there any spots where there should be units but aren’t? For our table, we added the heading ELEVATION_UNITS, but we’ll leave it blank when we start entering data. We want to record this decision somewhere too. Where do you think might be a good spot to do that?
Now that you’ve read through our decisions for those headings, do they help you decide your heading’s data types and clean data entry rules? If so, decide each one’s data type, record your clean data entry rules, and then add all of that to your README. You can also skip ahead to the Filling in the Table section if you’re ready to start entering data. If the previous examples aren’t enough, here are a few more:
STRATIGRAPHICAL_UNIT_NUMERIC was a heading we created. In it, we’ll enter the number from the STRATIGRAPHICAL UNIT box. It’s normally a whole number, aka an integer, so we won’t include decimal points when we enter those.
STRATIGRAPHICAL_UNIT_TYPE another heading we created. However, it’s a check box and not a number so based on our decision tree, we’ll record this as text, leaving it blank if neither box is checked.
DESCRIPTION_PositionWithinSector is another heading we created. It includes information about where someone recorded this form within the sector often in terms of compass direction. Unfortunately, those directions aren’t standardized enough for a separate heading so it’ll just be consistently spelled, capitalized, and punctuated text.
DESCRIPTION_Shape is also from the DESCRIPTION box and should be a one-word descriptor limited to words associated with potential shapes. However, sometimes people included additional information, so we’ll add another new heading called…
DESCRIPTION_Shape_Notes. This heading lacks a named space on the form but should be its own heading based on how people used the form. We noticed that people commented on the shape of what they described, or wrote additional observations occasionally irrelevant to shape, and we want to capture those notes. So we created a new heading, entered as text.
Now that you’ve read more examples, take a look at your headings, record what the heading is for, what data type it should be, and how to keep data entry for those standardized in your README. If you’d still like more examples, check out Gabbing About Gabii.
Headings without an equivalent on the form
Besides adding headings that break up the sections of the form into their own separate fields, you probably noticed that we made new headings for things not named or recorded in the form. These included headings for observations that lacked titles on the form but that people recorded (DESCRIPTION_Shape_Notes) and things that were left off the form but should have been included (ELEVATION_UNITS).
Other important additional headings to add are Notes headings. These may be a section of the form, for recorders to note observations that didn’t fit in another section, or can be observations made by the person doing data entry. These can be separated into headings such as FieldNotes, for those transcribed from paperwork, and LabNotes to account for observations made during data entry. Another potential heading might be EnteredBy, so we can acknowledge the hard work a data entry person did to transcribe these forms!
Looking at your form, what headings might you want to add as part of the data entry process?
Filling in the table
Now that you’ve picked your headings, their data types, and your clean data entry rules, you can start entering data! To practice this, enter at least 10 copies of your form into the table you created. It’s a lot to type but ten entries allows you to test whether your rules work or if they need to be changed.
And if they do need to change, that’s ok! It’s important to change your data entry rules and process (especially early on) if it doesn’t serve the needs of the data, answer our research questions, or record the observations you want. If you do change the process, just make sure to document when and why in your README.
How to fill in the table
Now we can start entering data, with our goal being to transpose and translate what was recorded in the forms in a standardized way. On that note: copy and paste is our friend. Copy and paste might, in fact, be our best friend, especially for any fields that contain text. That’s because it ensures we consistently use the exact spelling, spacing, punctuation, and other features for observations that have the same expression of an attribute.
Similarly, we want to ensure that we enter data under headings with the data type integer or float in the same way, either as whole numbers or numbers to a certain number of digits past the decimal. This allows us to do things like calculate and do other analyses in the future. Beyond that, go ahead and get typing, and then read the next section the first time you hit a blank on your form.
Dealing with blanks
One of the great and terrible aspects of data entry is the blank form or box because, unless we were also the recorder of the form, we don’t know why a section is blank. It could mean that the observation didn’t exist, that it didn’t apply to this observation, or (and we hope this isn’t the case but sometimes it is) the recorder forgot to fill out that section.
We are human and mistakes happen. Unfortunately, a blank can’t tell us which of these options explains its presence. And when we can’t ask someone about it, we need to decide and record for ourselves what to do when something was unrecorded. Key to this is deciding how, as the person doing data entry, we can differentiate between the discussed options.
For this short, note any blank or crossed out fields in the LabNotes heading. There, put any notes you made while doing data entry for a particular row, explain why any attributes were left blank, and what we know about those blanks (if anything). In cases of “N/A” or “not applicable” (or another clear indication that the recorder most likely saw the box and chose not to fill it out or noted that it did not apply), make a note within the LabNotes to state whether that “NA” reflected the original recorder or lab transcriber.
What does a structured data table look like?
Now that you know what to do, check out this example of a filled out table to see how it compares to your work.
Concluding this short
Congratulations! You’ve begun creating your own data set based on observations recorded in a form. This means that you’ve made some data entry decisions that created a structure for the data and recorded enough observations to feel like you understand how to turn notes into data. And if you aren’t comfortable yet, create more entries until you do. Or if you’d like more guidance, or a more rigorous exercise, check out Gabbing About Gabii to learn more about this process.
References for further reading
These references provide guidance on the pieces linked to in this Data Story Short and are listed in order of appearance in the text. If any of the included links below don’t work, please check out the Wayback Machine for an archived copy.
Check out other Digital Data Stories here: https://doi.org/10.6078/M74F1NW0
Find out more about the Alexandria Archive Institute at: https://alexandriaarchive.org/
Explore some data publications over at Open Context: opencontext.org
These archaeological forms work well for this exercise: https://opencontext.org/query/?proj=104-the-gabii-project&prop=104-file-attachment-type—104-context-sheet&sort=item–asc#tab=3/ovgrd=oc/zm=18/ov=sqr/aq=104-context-sheet
Or create your own forms by completing the Data Story Short Learn to Conduct a Basic Archaeological Survey: https://doi.org/10.6078/M7GX48Q8
Learn more about READMEs here: https://en.wikipedia.org/wiki/README
Check out Gabbing About Gabii for a more rigorous activity: https://doi.org/10.6078/M7T43R64
Refresh your memory of accuracy in measurement (aka significant digits or significant figures) with this article: https://en.wikipedia.org/wiki/Significant_figures
Learn how to process these data in Cow-culatating Your Data with Spreadsheets and R at: https://doi.org/10.6078/M73N21HR
The Creative Commons Attribution License (CC BY): https://creativecommons.org/licenses/by-sa/4.0/
Gain access to any broken links by getting an archived copy from the Wayback Machine: https://web.archive.org/
Credits
Unless otherwise specified below, this work and its components are shared under a CC BY license. To attribute this work, please use our suggested citation:
Paulina F. Przystupa and L. Meghan Dennis, 2025, “Going From Notes to Data”, Data Stories Program, Alexandria Archive Institute / Open Context, Published Online. DOI: https://doi.org/10.6078/M72R3PTR.
This Digital Data Story also includes the following licensed and credited materials:
“AAI-OC_DataStoryShortPublished_Header-NotesToData” by Paulina F. Przystupa from the Data Literacy Program / CC BY. It includes the icon “Museum #1982074” by Made x Made from the Noun Project (https://thenounproject.com/icon/museum-1982074/) under a royalty free license and an excerpt of “13754 from Europe/Italy/Gabii/Area B/Unit 1230” by Rachel Opitz, Marcello Mogetta, Nicola Terrenato (Ed). from Open Context (https://opencontext.org/media/f7a03f52-6a76-4c12-9b30-938dc3985bc4 or https://n2t.net/ark:/28722/k2ms3zr92) / CC BY.
“MultipleContextSheets” by Paulina F. Przystupa from the DLP / CC BY is a collage of excerpts. These are from “13755 from Europe/Italy/Gabii/Area B/Unit 1231”, “13754 from Europe/Italy/Gabii/Area B/Unit 1230”, and “13675 from Europe/Italy/Gabii/Area B/Unit 1158” by by Rachel Opitz, Marcello Mogetta, Nicola Terrenato from The Gabii Project (2017) on Open Context (https://opencontext.org/media/61a2f8a7-8e64-42ff-aca2-a62ecd781cc4 or https://n2t.net/ark:/28722/k21j9n02p; https://opencontext.org/media/f7a03f52-6a76-4c12-9b30-938dc3985bc4 or https://n2t.net/ark:/28722/k2ms3zr92; and https://opencontext.org/media/b2fd67d0-dd48-42dd-b66d-f344b49f5098 or https://n2t.net/ark:/28722/k21g0xk9w) / CC BY.
“SoilMatrix_Gabii_104-13675”, “FirstHeadings_13675”, and “Description_Gabii_104-13675” are all excerpts from “13675 from Europe/Italy/Gabii/Area B/Unit 1158” by Rachel Opitz, Marcello Mogetta, Nicola Terrenato from The Gabii Project (2017) on Open Context (https://opencontext.org/media/b2fd67d0-dd48-42dd-b66d-f344b49f5098 or https://n2t.net/ark:/28722/k21g0xk9w) / CC BY.
Acknowledgements
This is Version 1.1, published September 2025, of this Data Story Short. This page has been updated since initial publication to add the DOI for this page and to note that change here. Any further updates or changes will be noted here as well.
This Data Story Short is a collaboration between the authors, AAI/OC staff, the producers of the example data set, and the testing audiences, workshop participants, open peer reviewers, and the other wonderful people who helped make the original Digital Data Story that we adapted into this short, Gabbing about Gabii a success. These include folks like Rachel Opitz, Sara Perry, Kevin Garstki, Jenn Zovar, Ian Ray, Joshua Goode, and the anonymous testers and reviewers amongst our colleagues for the original Digital Data Story.
