- Q: Data import: Warning (1265): Data truncated for column. What is happening and how do I fix it?
- A: "Data truncated" means that the data in one of the cells (in that column) is longer than the column allows. For example if the warning is referring to “Latitude", the database only stores the first 3 decimal places. Either your data is unnecessarily long, or the column structure needs changing to accommodate it.
- Q: What are the model parameters for sequential isotopic data?
- A: Sinusoidal models can be formulated in various ways, so model parameters have been added in a flexible way to accommodate this.
- Q: Do animals get their own grave number, or are they considered grave goods?
- A: Consider the extreme theoretical case of a high prestige grave for a cow dressed with gold jewelry. With no human, this is still a grave, and the cow is grave goods. Therefore graves may or may not contain humans and/or grave goods. Furthermore, grave goods can be associated with a grave, or a single individual within a grave.
- Q: How do we aggregate data? What is our general philosophy of data aggregation?
- A: Not an easy one to formulate. Key principles are: 1) We are building a useful database, not accruing a data repository. We are not stamp collectors, or librarians. 2) We are making intelligent discard and aggregation decisions at each step to convert raw source data into new more useful data. 3) We maximize the usefulness and information content of data.
- Q: Item IDs: How do we ensure that we are building “bridges” within the database so that we can connect the different datatypes with each other? (E.g. How do we know that Grave X has two individuals of which Individual I has had strontium isotope analysis on all three molars and oxygen analysis on the second molar and individual II who has had strontium isotope analysis on M1 and M3 and oxygen analysis on M2)?
- A: Most tables are structured hierarchically, for example human isotopes belong to an IndividualID, which in turn belongs to a GraveID etc. However, there are some occasions where data across tables (that aren't hierarchically linked) come from the same sample. In these cases, assign the same ItemID to these data. More details provided here.
- Q: Site duplication: How should we check for nearby sites?
- A: BIAD includes a procedure called ‘check_nearby_sites’ which you can run to assist you in checking a new site. You need to enter the lat longs of the new site, and it will look for nearby sites already in the database. It is only an assisting tool - not a substitution for thorough checking.
- Q: How do we put people in age categories?
- A: If we have age ranges as years, store in max and min.
Categorical age ranges can be selected from the look-up table under ‘AgeCategory’. However, their interpretation differ between different osteological schools/methods. Store the original published age category/range in “AgeNote”, to assist assignment of numerical ages downstream. If you are certain of a translation, please provide the English equivalent. If unsure, report the proposed translation with the original category in brackets, in the original language and script.
- Q: Can I view all data associated with a site, or other data point?
- A: If you clone the Github repository ‘BIADwiki’, you get an R function called run.server.searcher() which extracts all related data. Since BIAD is a relational database, you can think of this as all direct ancestors and all direct decendants of the data point. There is an example R script in the repository called ‘example.searcher.R’
- Q: Non-latin characters/ accents: characters such as the double acute accent (ő) will throw an error in the search bar “SQL error 1267: Illegal mix of collations”. These ARE allowed in the database (e.g. of site names), but may be problematic for searching (?)
- A: The database uses UTF-8 for any character sensitive columns such as SiteName to ensure ANY characters are permitted. However, it deliberately restricts some columns to boring simple Latin1, such as simple SiteID codes. A generic search is across all columns, so with throw an error on the Latin1 columns. Either restrict your search to the column of interest, or you can circumvent the problem in HeidiSQL by going to EDIT→ FILTER PANEL. The search field will appear on the bottom left of the active pane.
- Q: Can a grave have many phases?
- A: Definitely not. A grave hierarchically belongs in a phase. If a single grave (e.g. a megalithic tomb) has been used across many different periods, each phase is assigned a different grave number (this is then noted in the notes field).
- Q: How do we enter data that has no associated culture or period. How can we assign it a phase? For example, the data is described as “not neolithic ?”
- A: Culture is not a prerequisite for entering phases into the database, nor is period. However, if there is no culture, no phase, and no date range, and we can't triangulate the published data with anything else, we really have to wonder if it is worth storing in BIAD at all.
- Q: Must a phase have a cultural affiliation?
- A: No. A phase can have no cultural affiliation (some countries do not use cultures in their archaeology) but should always have some chronological significance, e.g. “Period”.
- Q: What to do if two cultures existed at the site simultaneously? Must all phases be ordered?
- A: Phases needn't be ordered but should be provided if possible. Assign the ordering in the PhaseOrder table.
- Q: How do we phase data that has only very broad chronology i.e. as “Undetermined Mesolithic”?
- A: If that is all the chronological information available, then so be it. Undetermined Mesolithic is an option for Period in the lookup table: UM
- Q: How do we order phases there the order is not certain, or there might be overlaps?
- A: Phases can be ordered in the PhaseOrder table - but this is to represent very high probability ordering, for example from good stratigraphy, not guesswork. If there is substantial uncertainty in the order or there is a good chance that there are substantial overlaps, don't order them!
- Q: The publication I need to work with is not only in a foreign language, but the foreign language uses the Cyrillic script!
- A: The SiteName can be stored with any characters as it uses UTF-8, but ensure it is stored in a useful and searchable way - for example if the site is also referred to with an English translation, store both, semi-comma separated.
- Assuming that the publication is available as an image pdf with non-selectable text, you can OCR the document to allow text selection.
The following software worked remarkably well with scans of pre-1990 Soviet archaeological literature:
PDF OCR - Recognize text - easily, online, free - PDF24 Tools
Free Online OCR - Image to text and PDF to Doc converter - possible to export file in to a Word document following the origins structure of the text with images
OCR Recognize Text in PDF Online (sejda.com) - page by page OCR conversion, which means you can target specific text parts for translation rather than transform the complete document. Afterwards you can extract the relevant text parts and use automated translation with:
https://translate.google.com/
https://www.deepl.com/en/translator
- Q: How do I know if a published radiocarbon date listed as “BP” is calibrated or not?
- A: Minimum information required to store a radiocarbon date in BIAD is the Age, SD and labcode. By definition these are the uncalibrated ‘raw’ radiocarbon dates.
- Q: How should I convert a date given in BP to BC?
- A: The BIAD standard for converting BP to BC is to subtract 1950 from the dates BP. In this way, (date BP -1950 = date BC).
- Q: Phasing: The site I am trying to enter is already in the database but the phase information has only a name and cultural affiliation without citations. What should I do? Should I modify the contents according to the publication I am currently working on?
- A: It is always a good idea to examine which pieces of information will be affected by the changes you are implementing. Since the BIAD framework is constantly changing, it is possible that data inputted a long time ago is lacking some detail. This may require a literature search for whatever data is already associated with the site, in order to harmonise with your data. For example, there may be associated 14C data, the labcodes of which are easily searchable.
- Q: The site I am working was phased but the data I am collecting is not phased in a way which allows me to import all the fields I've collected. Is there a way to add this information from the literature without going into an analytical procedure?
- A: No. BIAD does not automatically generate phases for you. Careful structuring is required. For example:
Kivisaare is a site in Estonia periodically used for settlement and burial practices from Stone Age to the Bronze Age. With multiple excavations seasons preceding WWII, the phasing of the site has been modified frequently throughout the 20th and 21st century. By 2016 the site sequence based on settlement and burial finds was established as:
1. Mesolithic (undetermined) - settlement
2. Late Mesolithic - settlement, funerary: grave
3. Early Neolithic - settlement, funerary: cemetery
4. Late Neolithic - settlement, funerary: cemetery
5. Early Bronze Age - settlement, funerary: cemetery
A total of 30 graves with 43 individuals infrequently accompanied by material culture were discovered. The majority of graves and individuals were poorly preserved and discovered without preserved material culture. Only five radiocarbon dates are available, two of which come from the same individual. When presenting the grave material the 2016 source specified that burials belong to phases:
2. Late Mesolithic
3. Early Neolithic
4. Late Neolithic
5. Early Bronze Age
Phase 5 burials were removed from the primary sources and were published elsewhere together with the two corresponding radiocarbon dates as they fell out of the topic of the study. However, no information was provided on which burials should be assigned to which phase.
Radiocarbon dating of 3 individuals (1 individual with two dates) showed that:
2. Late Mesolithic - 1 individual
3. Early Neolithic - 2 individuals
This leaves 28 individuals without specific phasing; a prerequisite for importing data into the BIAD. In such case there are three things we can do:
- Keep only the data with reliable information and ignore the graves with unclear dating.
Quick and easy solution which affects our coverage: Estonian Stone Age burials are infrequent (max. 150 presented in a 2016 study), which suggests that ignoring these entries removes an essential chunk of information from our study.
- Ignore the 28 individuals for importing but save them as incomplete data.
Such a dataset can be stored outside the database in case a future publication (14C, aDNA, new method, clustering algorithm, etc.) will provide the necessary information to fill in the blanks necessary for importing. It's a solution but it means that a lot of time and effort went into curating a dataset, which we are unable to use in the foreseeable future.
- Modify phasing
By modifying the phasing initially presented as an accurate representation of site chronology, we can add the finds into the database by proposing a longer phase which decreases the resolution while remaining true in terms of an overall chronology. It allows importing the dataset for further processing, thus ensuring its usefulness for the project, and, more importantly, avoiding a situation in which we start to accumulate data which might never make its way into the database (see solution number 2).
In this specific case, it would be possible to modify the phasing as follows:
1. Mesolithic (undetermined) - settlement, funerary: cemetery (1 radiocarbon dated individual)
2. Neolithic (undetermined) - settlement, funerary: cemetery (2 radiocarbon dated individuals, 28 unknown individuals)
3. Early Bronze Age - settlement, funerary: cemetery
Its not an ideal solution because by reducing the information about the temporal relationship between burial practices following the creation of a settlement, we lose some information about burial pratices in Kivisaare. However, at the same time we have increased our coverage of Stone Age burial practices in Estonia, which gives us more opportunities to trace links of burial practices and material culture. Furthermore, should more data become available, it will be possible to correct the data directly in the database.