"What bothers me about Iconclass..."

This topic summarizes a discussion that should have taken place at the 12th Conference of the Society for Emblem Studies in Coimbra in July 2022, but - due to covid-issues - it never did.
Dr Stefan Laube (Institut für Kulturwissenschaft Humboldt-Universität zu Berlin), offered some important observations about what he perceived as shortcomings of Iconclass. He kindly sent them to me after the conference, so I could respond to them here.
Dr Laube’s comments started thus:

Dear Colleague,
first of all, I hope that you are really recovered. It’s a pity that in Coimbra the technique didn’t work that way and therefore no real discussion took place. So now I’m still sending the passage from my talk in which I criticize Iconclass a bit. Iconclass may be useful when searching for foxes, storks, and camels, unambiguous schematic pictorial characters common in emblematics. But what about more complex images, with multi-faceted frontispieces, as for example:


My response to these initial remarks:

Even if we indeed limit ourselves to emblematics, foxes, storks, and camels can express a rich array of meanings and may be part of quite complex emblematic constructs, so I would not call them unambiguous or schematic characters. Still, I do understand why you use them as examples of more straightforward motifs, contrasting them to the more complex image on the title page of the Tripus aureus.
I shall deal with that title illustration in more detail below, but I do agree with your observation about the usefulness of Iconclass for this type of motif. Using Iconclass allows you to find those animals also when you search in other languages. In addition they are also implied in more general concepts like “Shore-birds and wading-birds”, “hoofed mammals” or “predator”. This can indeed be useful if you want to find different wading birds, like the stork, the crane, and the heron in a single search. To facilitate those broader queries, searching with Iconclass needs to be implemented in a certain way. This too I shall deal with below.

Dr. Laube continued thus:

In this example the fusion of theory and practice, so typical of alchemy, comes to appealing representation. The picture is divided into two parts. On the left, an abbot, a monk and a philosopher are exchanging ideas in a library. Their clothing and facial expressions show that they have no intention of doing alchemical work. Immediately next to this group of people – perhaps they are the authors of the three treatises – is a furnace that is being fired by an almost naked man – perhaps Vulcanus.

On top of the furnace is a tripod with a long-necked vial in which a snake-like creature is cavorting. It is probably meant to symbolise the dynamic principle of Mercurius, ultimately the philosopher´s stone. The laboratory on the right side of the picture is filled with all kinds of stuff; it seems to be a workshop. Library and workshop, neatly separated, are nevertheless united under one roof in the picture. The series of folios on the shelves on the left correspond to tongs and vessels on the right. And right in the middle is the vial, the golden tripod that gave the treatise its title. The message emanating from the image is that in alchemy theory and practice must be permanently fused.

My response:
As the description demonstrates, this is indeed an image that is rich in detail and meaning, and the question in front of us is whether the Iconclass system can cope with an image of this complexity.
When answering this question we need to be quite precise about what we expect from a classification system. The standardized words and sentences of a controlled vocabulary like Iconclass will not produce a text that has the richness and flexibility of expression of a description in a natural language. That is not its purpose.
Simply compare it to a dictionary. A dictionay provides definitions of the words we use to express ourselves. It does not produce readable texts. So, if the fact that it does not produce prose descriptions is “what bothers you about Iconclass” you may have been expecting it to do something for which it was not intended.
But if Iconclass is not there to generate descriptions in natural language, what then does it bring to the table to warrant the effort of using it?
To answer this, I propose we look at the issue from the perspective of information science, in particular at the aspects of coverage, semantics, grouping, and retrieval.

The coverage aspect boils down to the question whether Iconclass does indeed contain the concepts needed to tag the content of an image of this complexity. To help you assess this, I have made a list of the iconographic elements that are mentioned in the description. Do note that some elements are concrete – e.g. persons and objects – while other elements are quite abstract and require a sophisticated level of interpretation.
Also note that the list of Iconclass concepts proposed here as equivalent to the words from the description, is not exhaustive. Sometimes Iconclass offers multiple candidates; in those cases I selected the concepts that best fit the alchemistic context.
Some terms in the description are open to further interpretation, for example “facial expression”. In those cases I opted for a concept of similar generality, even though in Iconclass it can have many subdivisions.
Levels of insecurity - e.g. expressed by the word “perhaps” - were ignored.

Description term Iconclass equivalent
theory 52C5 Theory; ‘Theoria’ (Ripa)
practice 54D21 Practice; ‘Prattica’ (Ripa)
alchemy 49E39 alchemy
abbot 11P315311 abbot
monk 11P31521 monk(s), friar(s)
philosopher 49C3 scholar, philosopher
exchanging ideas 49C4 discussion, dialogue, dispute ~ scholar, philosopher
library 41A251 study; ‘studiolo’; library
clothing 41D24 clothes for special purposes
facial expressions 31B62 morphology of facial expression
no alchemical work 49E39(+2) alchemy (+ scholar, scientist in non-work situations)
49C3(+11) scholar, philosopher (+ in workshop, laboratory)
authors 48C92 author in non-work situation
furnace 49E3932 alchemistic furnace
fired 41B13 stirring up a fire)
41B12(LOG) burning as process: log
almost naked man 31D14(+89) adult man (+ nude human being)
31A559 partially clothed
Vulcanus. 92B252 Vulcan in his smithy
tripod 41A7111 tripod
long-necked vial 49E39311(PHIAL) bottles: phial
snake-like creature, cavorting 49E392 alchemistic symbols
25F42(+5213) snakes (+ rolling animal)
the dynamic principle of Mercurius 49E39421 Philosophical Mercury ~ alchemistic substance
philosopher´s stone 49E3945 Philosopher’s Stone (Lapis philosophorum)
laboratory 49E8 laboratory
all kinds of stuff 49E81 laboratory apparatus and equipment
workshop 47A11 workshop
folios 49M32 book
49L72 codex
shelves 41A7122 bookshelves
41A712 shelves, rack, sideboard
tongs 47D8(TONGS) tools, aids, implements ~ crafts and industries: tongs
41B2121 fire-tongs
vessels 49E3931 alchemistic vessels

Iconclass is an hierachically organized classification system, which means that the semantics of every concept are defined by its place in a branch of the hierarchy.
The Philosopher’s Stone, for example, is defined as a specific instance of an alchemistic substance, which in turn is a specific concept in the domain of alchemy, which is a subdomain of chemistry … etcetera - as illustrated by this screenshot from the Iconclass online browser:
As a consequence there is no ambiguity about the semantics of the concepts in Iconclass. This does not necessarily make the cataloguer’s life easier. For example: there is no Iconclass concept that corresponds with “all kinds of stuff”. Such an expression is comfortably unspecific. Iconclass, on the other hand, forces the indexer to choose and disambiguate. In this case the image provided sufficient information to choose the following concept as equivalent:

Labelling the elements of images with the stock phrases of a controlled vocabulary does not make sense when you are merely describing a single image, as the purpose of iconographic cataloguing is to record differences and similarities across (large) groups of objects as consistently as possible.
Those labels can only serve their purpose of grouping images, subjects and motifs if we allow for a certain loss of specificity. Here is an example of two images that I managed to retrieve together from a database, because they were both labelled with the same Iconclass concept, in spite of their obvious differences: 49E81 laboratory apparatus and equipment

Grouping is also an automatic effect of the hierarchical organization of the concepts. The two labels in my example share the “root” concept 49 education, science and learning so in a setting optimized for Iconclass retrieval a search for this concept would yield a rich harvest.
In such a setting retrieval will be based on the encoding. It is easy to see why that facilitates smooth switching between levels of specificity. When an object has been tagged with the concept of the 49E3945 Philosopher’s Stone it is automatically made part of the group of objects in the domain of 49E39 Alchemy, and gathering all those (related) objects can be done by simply trimming the code that is used for retrieval: 49E39* will do the trick.
Dependent on the way the Iconclass search facility is implemented in a local setting like that of the Herzog August Bibliothek, searches can be based on the encoding, but also on the words of the definitions, for example “alchemy”. It is also easy to see why searching with codes will yield more precise results than searching with words.

Dr Laube referred to the HAB website:

In Wolfenbüttel, at the Herzog August Bibliothek, a database has been open for a few years, in which sources on alchemy are united, not only texts, but also pictures (Thesaurus - alchemie). Let´s see where our example just discussed is stored there. The best thing to do is to open the picture browser immediately. Here you can get a page-by-page overview of the image collection, more than 1800 images have been uploaded.
Or you can use the classification criteria provided by Iconclass. You will find what you are looking for in “49E391 Alchemist at work”. If you click on the picture, you are immediately on the full-text page, from where you can navigate through the entire book.

My response (continued):

The classification and its implementation
These comments are invaluable, because they refer to an important aspect of every effort to standardize metadata with the help of shared thesauri or classifications. Even though institutions may apply the same standard for their metadata, whether it is for geographic names, the names of artists or iconography, that does not mean that the experience of the end user – in this case you, searching the alchemistic database of the HAB – will always be the same.
What you are describing here is the way the HAB has embedded its Iconclass information in its online catalogue of alchemistic illustrations.
This variation in end user experience may be quite confusing, but it is important to realize that the HAB’s solution is by no means the only way to do it.
Below is an example from the Arkyves database. It is using the exact same data about the Tripus aureus, but presents it in a different way.

The Arkyves database has a focus that is very different from the Wolfenbütteler catalogue, as it aggregates collections which all are using Iconclass for the information about iconography. The implementation of the Iconclass searching and browsing in Arkyves is quite different from the HAB’s, even where it uses the same data.

Dr Laube:

Undoubtedly, “Alchemist at Work” is a characteristic feature in this engraving. But the main theme seems to me to be the contrast or complementarity between theory and practice, between noble knowledge and painful craft. And what about the vial in which a snake is lolling? It falls under the table just as much as the interior of a library. Pictures are ambiguous, often distinguished by the fact that they overshoot any conceptual classification model. What to do then?

Response (cont’ed):
Even though the information about this complex image provided by the HAB/Bildindex is richer than may have been obvious to you when you searched the HAB’s database, I do agree that no classification, however rich, will offer the instruments to capture all the subtle details a specialist like you will observe in a single picture.
Iconclass, to repeat it, is not a toolbox for an ekphrasis. It is an instrument designed to bring our historical opponent – the objects that constitute our visual heritage – in the field so we can begin to do research at a different level of information. Like I said in Coimbra: tagging objects with Iconclass is like the opening moves of a chess game. Their function is to get the game going.

Dr Laube:

In order to do some justice to this characteristic of pictures, it is advisable to always design the categories of recording in such a differentiated and elastic way that a picture can appear from dozens directions.

Response (cont’ed):
Again, agreed, and that is precisely the point I made by juxtaposing the words from your rich description and the 35 Iconclass equivalents I have selected. Of course, not every project will be funded sufficiently to provide information of this density, but the hierarchical organization of the concepts, the multilingual keyword search options and the many cross references do provide rich retrieval options.

Dr Laube:

I think it is problematic that in most cases Iconclass is satisfied with only one characterization.

Response (cont’ed):
I do hope to have demonstrated here that this is not a feature of Iconclass, but of the way it is used in any given project, while emphasizing that the cataloguing effort at the HAB and Bildindex was far more substantial than assigning a single concept to a complex image. It also took the best part of a summer – and the help of various specialists in the field - to expand the Iconclass system with the alchemistic concepts that are now put to use at the HAB, e.g.:

Dr Laube:

And what to do with a classification in which under the head categories “religion and magic” and “nature” alchemy does not appear at all, it appears rather hidden under “science, civilization, culture” as a subitem of “chemistry”, Are not fruitful neighborhoods damaged there?

Response (cont’ed):
That is a good point. When Iconclass was constructed “alchemy” was defined as a sub-domain of “chemistry”. A debate about this decision could probably go on forever, and this would hold for many concepts in the Iconclass schedules. A decision about the location of a concept can be quite arbitrary – but at some point the Gordian knot needs to be cut…
Fortunately, it is extremely easy to create cross references from one Iconclass concept to another. In this particular case there is already a cross reference from a concept in the domain of Religion and Magic to Alchemy:

Dr Laube:

Do you think my criticism is exaggerated, or does it hit a point? Best wishes,

Well, if there ever were a perfect first topic to a Forum dedicated to discuss Iconclass issues, this is it.
Let us hope that the community chimes in …

This is a very useful and pertinent discussion: thanks to both Dr Laube and Dr Brandhorst. In working to devise structured tags for the BASIRA database, we’ve been confounded by the limitations of a “flat” value list. One of the strengths – and challenges – of Iconclass has seemed to me to be its (at times) extreme specificity: however, once one has navigated down to a very exact description (Annunciation scene with Mary seated and Gabriel standing to her right), it’s simple to move up in the hierarchy to a more generalized tag. As we think about employing Iconclass tags, deciding upon and trying to standardize the appropriate hierarchical level remains something of a puzzle.

Could / would you explicate uses of paired searches? For example, images tagged both with a concept like “justice” and an artifact like “sword.”? Could you imagine developing a generalized protocol for paired searches?
Barbara Williams Ellertson

If I understand your post correctly, it actually asks two separate questions.

  1. How do we decide which level of specificity the indexer(s)/cataloguer(s) should stick to?
  2. When we assign multiple concepts to an object, can we then retrieve that object by simultaneously searching for more than one concept?

1. Level of specificity

The answer to the first question seems to me to be already in your question. Because the system is organized hierarchically, a more specific term inherits its meaning from its “parents”.

In other words: the Annunciation scene is automatically identified as an event described in the New Testament. This is “stored” in the notation as 73 is embedded in 73A521. All notations that start with 73 belong to concepts describing events or phenomena that are part of the New Testament.
Representations of the Annunciation with Gabriel entering the scene from the right, can be tagged with the concept 73AA521 the Annunciation: Mary standing - AA - Mary to the left, the angel to the right. A human observer intuitively grasps the information that this is a specific variant of the same theme, also inheriting the information that it is part of the New Testament. The Browser’s algorithm smoothly mimicks this intuitive observation:

In any cataloguing project, decisions about the level of specificity are basically editorial decisions, usually guided by the availability of time and money. If multiple cataloguers are collaborating, inconsistencies will inevitably sneak in. But because of the hierarchical organization it is easy to catch those inconsistencies. At some point simply retrieve all objects tagged with 73A52 and then decide for which one a more specific label should be used. But even if you skip this correction phase, your users will be able to retrieve a group of Annunciation scenes - and then decide for themselves.

2. The simultaneous retrieval of multiple concepts

Retrieving an object with the help of several Iconclass concepts working in tandem is not an Iconclass Browser retrieval issue. The Iconclass Illustrated Edition is not a pictorial information system. Its illustrations merely serve a demonstration and inspiration purpose: like scope notes they show how Iconclass concepts have been used in previous cataloguing projects, and how you can use them in your own project.
Normally more than one Iconclass concept is assigned to an object. Let us stick to the alchemy example we started with, and focus on two of the concepts I listed above: monk and alchemy. Below are Browser screenshots of those concepts with their hierarchical “parents” and the keywords with which they can be found in Iconclass:

These concepts are from separate branches of the Iconclass schedules. Neither the chains of notations nor the words of the definition or the keywords have anything in common. Still, if the appropriate software is in place, objects that were tagged with these two distinct concepts, can be retrieved from a database, even by simply using (key)words, as shown in this example from the website of the Herzog August Bibliothek:


Your sample query for justice and sword will yield some 150 objects in this database - on the basis of the same principle.

The key element is indeed “appropriate software”. In a sense the protocol you are asking about already exists - as a piece of software called the Harvester of Iconclass Metadata (HIM) - which is the software that works in the background of the iconographic image browsers at, for instance, the Herzog August Bibliothek, the Folger Shakespeare Library, and Glasgow University Library.

Question #1, level of specificity: this explication is helpful: I could see a “user guide” instructing that the tag level be chosen for the maximum amount of detail, with the hierarchy then used for broader levels of generalization.
Question #2: I had not been aware of the HIM software, and clearly need to learn much more about it. You are already way down the trail I was beginning to think about: a relatively standardized way to pair concepts and objects for different searches whose results could be reliably compared. We continue to puzzle over tags of allegory and analogy within the BASIRA database: I’ll be studying your PDF (Iconclass and AI) and hope to re-appear here soon with more questions. Thank you!