3.1 Uncertainties from Provenience

Provenience of a seal, i.e. the archaeological context in which it was found, is important to be able to examine the meaning of a seal considering its place of deposit and other objects associated with it. A secure find context also provides certainty for geographic localisation and dating of a seal. For a few seals, the lack of a secure context might even lead to question their genuineness. If a seal was acquired under dubious circumstances, which in most of the cases means that it was not found during an archaeological excavation, information about its geographic origin has to be taken with a pinch of salt and context dating is not possible at all. Geographic information is available for a total of 583 seals, although for only 289 pieces a secure context is known.

3.2 Uncertainties from a Seal’s Condition

The overall condition of a seal plays a crucial role in the identification of its engravings. Determining the used ornaments, hieroglyphic signs or a creature’s species is much easier when studying a well preserved and complete seal as opposed to a battered, broken or even fragmentary one. The seals in different preservation conditions in figure 2 shall serve as a visual example.

Fig. 2: A fragment of CMS IS 038a, the slightly damaged CMS I 287b, and the well preserved CMS XII 135b. The first seal side depicts either a bovine or a goat, while the others show a goat. [Graphic by courtesy of the CMS Heidelberg.]

3.3 Uncertainties by Human Action

An unpredictable cause for uncertain descriptions of a seal is human action, which is manifold. To begin with, the seals are man-made objects and thus already in their making the seal engraver may have made mistakes when cutting the stone or may even have obfuscated the motifs on purpose, thus resulting in ambiguous compositions. Additionally, the carved material, the tools used, the style, and the craftsmanship of the engraver led to very different depictions of the same motif. This can be seen by comparing the seal sides depicted in figures 2 and 3.

All this might then contribute to an uncertain denomination of motifs depicted on a seal by modern scholars while cataloguing the seals. Depending on a scholar’s background additional uncertainties may arise due to insufficient knowledge in other fields of expertise, as e.g. the wrong attribution of a specific bird species. In some cases, further vagueness is introduced when a seal is studied by more than one scholar, who might disagree in their interpretations.

When the information is then transferred into the database Arachne further uncertainties can be introduced by input errors or by leaving some fields empty. The latter is ambiguous, because it could mean that either the field was forgotten or that there actually is no information available for it.

3.4 Uncertain Values in the Data Set

Three different markers are used in Arachne to denote uncertain, but probable values in the database: a question mark, giving the different options, and a combination of the first two variants. When options are indicated, only two are given. In figure 3 for example, the values for the attribute ›Lebewesen‹ (creature) of CMS X 322c, CMS IS 038a, and CMS III 504a are ›Ziege?‹ (goat?), ›Rind oder Ziege‹ (bovine or goat), and ›Rind oder Ziege?‹ (bovine or goat?). In the dataset no value has more than two different options.

Fig. 3: Three seal sides with uncertainly identified creatures on them. The animal on CMS X 322c is designated as ›Ziege?‹ (goat?), the one on CMS IS 038a as ›Rind oder Ziege‹ (bovine or goat), and the creature on CMS III 504a ›Rind oder Ziege?‹ (bovine or goat?). [Graphic by courtesy of the CMS Heidelberg.]

For supposedly present values which could not be identified, the terms ›undefinierbar‹ or ›undef.‹ (undefinable, indeterminate) were used. The term ›Intagliolücke‹ (gap in the intaglio) is also used for similar cases.

Not all of the sources for uncertainties discussed above are represented in the data set. Some uncertainties caused by human action are not denoted as such, because they are implicit, such as those caused by errors or lack of knowledge. An additional attribute to state, whether a seal came from a secure context or not was added to the data set by consulting the introductory sections of the printed CMS volumes.[4]

Markers for uncertainty can be found in values for almost all attributes in the data set. From the eleven thematic groups mentioned in section 2 only ›identification‹ does not contain any vague values.

Besides the additionally introduced attribute for secure contexts, some attributes about the provenience of a seal such as places of origin are marked with a question mark when deemed doubtful. Uncertainties in the description of a seal’s shape are present if the seal is in a bad condition or only a fragment is preserved. This is why seemingly distinct properties such as the shape of the whole seal or of individual seal faces, the type of perforation or in one case – CMS V 256 – even the number of seal faces cannot always be indicated without doubt.

Attributes in the thematic group ›material & technique‹ include information about a seal’s material, the technique employed to make the seal, and any other details worth cataloguing. Uncertain values are present for all of those attributes in the dataset.

As can be expected, attributes in the group ›measurements & preservation‹ containing dimensions do not contain any uncertain values. In contrast, the preservation condition of a seal does so, especially if it is not possible to securely indicate that a seal shows tool marks or signs of burning.

All attributes describing the engravings a seal is bearing have values with uncertainties. They are part of the thematic groups ›general information about decoration‹, ›stylistic classification‹, ›ornaments‹, ›characters‹, ›figurative motifs excepting creatures‹, and ›creatures‹. In addition to the example for uncertain identification of creatures given in figure 3 above, two more cases shall be provided.

The attribute ›Standardornament‹ (standard ornament), part of the thematic group ›ornaments‹, can contain multiple values, which in turn can all individually be marked as uncertain. In figure 4, CMS II,1 136a is shown. ›Standardornament‹ contains the value ›Hakenspirale?(2), Punkt, undefinierbar‹ (spiral hook?(2), dot, indeterminate). It indicates that possibly two spiral hooks, one dot and and a further, indeterminate element, are depicted on the seal.

Fig. 4: CMS II,1 136a. The engravings on the seal’s face are described with › Hakenspirale?(2), Punkt, undefinierbar‹ (spiral hook?(2), dot, indeterminate). [Graphic by courtesy of the CMS Heidelberg.]

The attribute ›Schrift‹ (script), which belongs to the thematic group ›characters‹, may also contain multiple values in order to list all characters present on a seal’s face. The script used on Aegean seals is in most cases Cretan hieroglyphic. The hieroglyphs are specified by using the acronym ›CHIC‹ and a number which relates to the Corpus Hieroglyphicarum Inscriptionum Cretae.[5] For example, the four-sided seal CMS II,2 316 in figure 5 has script on all sides, of which one character, CHIC 056, on face c is marked as uncertain because of the seal face’s damage.

Fig. 5: The four sides of CMS II,2 316 with Cretan hieroglyphs: CHIC 044, 049 | CHIC X, 029, 077, 049 | CHIC X, 057, 034, 056? | CHIC X, 044, 005. [Graphic by courtesy of the CMS Heidelberg.]

4.1 Data Model

A major difference between the data model described here and the one used by Arachne is that for the graph database seals and their seal faces were modeled as distinct nodes. This allows to separate attributes describing features of the whole seal like material, shape or geographic information, from those only describing a single face, such as depicted motifs. This distinction was not made in Arachne.

Besides the two node types for a seal and for a seal side, 13 further node types were included and are either related to the whole seal or to a side: ›Siegeltyp‹ (seal shape), ›Materialgruppe‹ (material group), ›Material‹ (material), ›Ort‹ (place)‹ ›Stilgruppe‹ (style group), ›Epoche‹ (period), ›Makroornament‹ (macro ornament), ›Standardornament‹ (standard ornament), ›Symbole‹ (symbols), ›Objekte‹ (objects), ›Pflanzen‹ (plants), ›Schrift‹ (script), and ›Lebewesen‹ (creatures).

Nodes can be connected with each other by edges which in Neo4j are called relationships. For this dataset, a total of 17 different relationship types were created. The relationship type defines how and to which other node types a node can be connected. For example, the relationship type ›hat_Siegelseite‹ (has seal side) connects the node type ›Siegel‹ (seal) with the node type ›Siegelseite‹ (seal side). Four different relationship types can be used to connect the node type ›Siegelseite‹ (seal side) with ›Epoche‹ (period), in order to state whether the period represents the beginning of a context date (›hat_EpocheAnfKontext‹), its end (›hat_EpocheEndKontext‹), the beginning of a style date (›hat_EpocheAnfStil‹) or its end (›hat_EpocheEndStil‹).

The node types and their relationships are depicted in figure 6. The node type ›Siegel‹ (seal) is further described with additional properties, including the CMS number, the calculated volume, and the numbers of empty seal faces and depicted creatures.

Fig. 6: The data model for Aegean seals used in Neo4j. [Graphic by Martina Trognitz, Vienna.]

4.2 Import into Neo4j

As described in section 2, the dataset was imported into two tables with further information provided in two additional tables. All those tables were imported into Neo4j with Cypher, a query language for graph databases. The Cypher script created for the import does not only import the dataset, but also cleans and filters it. This means that attributes with empty values are not imported into the graph, as well as attributes containing ›None‹ or ›nein‹.

In Arachne multiple equal values for an attribute are not listed separately, but the number of repetitions is set in parentheses, as already seen for CMS II,1 136a exemplified in section 3.4 and figure 4, where ›Standardornament‹ contains the value ›Hakenspirale?(2), Punkt, undefinierbar‹ (spiral hook?(2), dot, indeterminate). If the number is greater than six a greater-than sign is used, thus resulting in something like e.g. ›Hakenspirale(>6)‹. This was accounted for during import by creating an edge for each repetition. Unfortunately, it was not possible to determine the exact number for ›>6‹, which is why a maximum of six edges between a seal side and e.g. a specific standard ornament is created.

In figure 7, a part of the Cypher script for the import of ›Standardornament‹ demonstrates how data is converted into the graph data model. The resulting graph for the seal CMS II,1 085 from Figure 1 is shown in figure 8. Overall a total of 4637 nodes was created with 18306 relationships interconnecting them.

Fig. 7: A section of a Cypher script, which imports standard ornaments depicted on seal sides and sets a weight on the edges depending on the certainty of their identification. [Graphic by Martina Trognitz, Vienna.]

Fig. 8: CMS II,1 085 as a graph in Neo4j. [Graphic by Martina Trognitz, Vienna.]

4.3 Modelling Uncertainties

There are different ways to represent uncertainties in graph databases that depend on the application and its planned queries. For instance, different nodes can be created for certain and uncertain values, like a node for ›Ziege‹ (goat) and another one for ›Ziege?‹ (goat?). In the worst case this would lead to the double amount of nodes. Adding a property to indicate uncertainty to a node would also lead to an increase in the number of nodes. Another way is to use the edges, either by providing different kinds of relationships (e.g. ›has‹ and ›may-have‹) or by including weights. The former leads to an increase in the number of relationships in the graph. The latter approach keeps the number of nodes and edges at a minimum and also allows to include a measure for the uncertainty such as percent. In the data model presented here uncertainties are modelled by applying edge weights ranging from 0 (0 % sure) to 1 (100 % sure).

Not all of the uncertainties mentioned in section 3 can be represented in the graph database, this is only possible for those which are marked as such in the data source. The weights are also set with the Cypher script, based on the value provided in Arachne. If a value comes without any uncertainty marker (e.g. ›Ziege‹ (goat)), the weight of the edge is set to 1. If the value is marked as uncertain with a question mark (e.g. ›Ziege?‹ (goat)), the weight of the edge is 1 > x < 0.5 which in this case was set to 0.8. For those values where two options are given, two edges are created. The weight of those edges depends on the presence of a question mark. A value like ›Rind oder Ziege‹ (bovine or goat) leads to two edges with a weight of 0.5, i.e. a 50 % chance that one of the two options is actually depicted. The value ›Rind oder Ziege?‹ results in two edges with the weight of 0.5 > y < 0, which in this case was set to 0.3. Furthermore, a count was introduced in order to be able to distinguish between two uncertain edge pairs belonging to one seal side.

In figure 9, seal CMS IS 038 is shown as a graph in Neo4j. Three edges, connecting the seal sides with creatures are uncertain with weights of 0.5 and 0.8.

Fig. 9: CMS IS 038 with all its attributes in Neo4j. The edges connecting side A with creatures are weighted with 0.5, due to the value being ›Rind oder Ziege‹ (bovine or goat). Side B is connected with ›Greif‹ (griffin) with a weight of 0.8, because a question mark was present in the value. [Graphic by Martina Trognitz, Vienna.]