Most often each record of a database has a single digital image associated with it. In such situations, configuration is relatively simple and described fully in the data preparation documentation. It is important to read the general data preparation documenation first before proceeding with more complicated structures.

MySQL: ImageClass Data Loading: MySQL

The instructions in this document are for less common situations. When a record has multiple images associated with it, for example, several views of an sculpture. Each of the views might be of equal standing, or, perhaps there is one that alone does a reasonable job of summarizing the object, while the others provide valuable details difficult to see in the summary. These are just a couple of the possible structural configurations one might encounter.

The key factors for the accurate representation of image structures in the Iimage Class are:

• Representation of the relationship between image filenames and associated image captions within the fields of a record.
• Mapping of the fields for Image Class ingest.

Note that structures apply to entire collections and cannot vary per record.

Definitions

A filename field is a field of a database that contains image (or other media) filenames and nothing else. A filename field may have any number of repetitions.

A caption field is a field of a database that contains text that typically describes the image in a very specific way. For example, "View of steeple from the north." A record with multiple image filenames will often have a corresponding caption for each.

A record with a filename field that has 5 repetitions will often have a corresponding image caption field with 5 repetitions. The values in each are synchronized.

A record may also have multiple filename fields, and multiple image caption fields. Together they might represent a hierarchical structure.

To get an idea of a more complicated example, look at the this example from the Advanced Papyrological Information System at the University of Michigan.

Administrative metadata field mappings are used to identify filename and caption fields for the purpose of loading data. In addition to the very basic mappings IC_fn and IC_vi there is a complex set of mappings that can be used to represent complex structures. Generically the new mappings are referred to as IC_fn* and IC_vi* (the "*" suggests a longer, more complex, mapping).

A structure is a group filename and caption fields that together make up a structure. A record can have more than one structure. This papyrus example has two structures. The first structure ties all of the "front" views together, and the second ties all of the "back" views together. This causes the structural display online of thumbnail images to flow from front summary images to front detail to back summary to back detail. This flow can be changed through configuration.

Rules

1. A record may have many filename fields, which may have repetitions.
2. Each filename field must be mapped to only one administrative metadata filename mapping (IC_fn, IC_fn-st).
3. A record may have many caption fields, and the fields may have repetitions.
4. Each caption field may be mapped with any number of administrative metadata caption mappings (IC_vi, IC_vi-st).
5. Each caption field mapped to plain IC_vi will be associated with all image filename fields mapped to IC_fn (but not fields mapped to IC_fn-st).
6. Fields mapped to IC_vi or IC_vi-st may have one or more repetitions, which may be independent of the number of repetitions in the associated IC_fn or IC_fn-st mapped field.
7. If the filename field has repetitions but the corresponding image caption field does not, then the single value of the image caption field is associated with each of the repetitions of the image filename field.
8. Structures can only be specified at the collection level. It is not currently possible to have the structure change per record.

Syntax

Simple situations (one image per record) can be handled with a simple mapping of the filename field to "IC_fn" and the caption field to "IC_vi".

More complex situations rely on the structural mappings so far referred to as IC_fn* and IC_vi*. These are not the actual mappings, they are only generic and simplified representations to aid discussion. The actual mappings consist of a base (IC_fn and IC_vi) plus four attributes. When structural mappings are used, all four attributes are required to have values.

The base: IC_fn and IC_vi

Type Attribute

Face Attribute

Structural ID (STID) Attribute

stid=1 .. N

Each structure must be given a numeric ID. Be sure to read the definition of structure given above. Structural IDs can be assigned somewhat arbitrarily, though there needs to be at least one.

Y Attribute

y=1 .. N

Sometimes the images of a record represent cells of a two dimensional matrix, which can also be thought of as a table or tiles. The Y attribute, together with the X attribute, allow for a matrix of images to be stored in the data.

X Attribute (not configurable)

The fifth attribute, "X", is not configurable. It is calculated as the data is loaded based on the number of repetitions.

Database systems typically only offer the ability to have field repetitions in one dimension. That is, a 1xN field of repetitions can be built. To simulate a two dimensional matrix involves working with multiple repeating fields where each repetition represents a column (X) and each field a row (Y).

The Y attribute must be specified in the configuration file. The X attribute, on the other hand, is calculuated automatically at the time of loading and depends on the number of repetitions there are. A good example is this papyrus example.

Combining the Base with the Attributes

All attributes are required in all cases and the components must be joined with a period (".") as demonstrated below.

For an image filename field:
IC_fn-type=summ.face=front.stid=1.y=1

For the caption field that corresponds with the above filename field:
IC_vi-type=summ.face=front.stid=1.y=1

Configuring the Fields

Once the structural attributes are determined the mappings for the filename and caption fields are entered into CollMgr (MySQL) or the collection configuration (XPat). Mapping is handled similarly to all other field mapping, the only difference being the long length of structural attributes.

In Collmgr the example above looks like...

IC_fn-type=summ.face=front.stid=1.y=1:::filenamefield
IC_vi-type=summ.face=front.stid=1.y=1:::captionfield

(filenamefield and captionfield need to be actual fields)

Examples

University of Michigan, Bentley Historical Library.

View an example record online.

How it looks in Collmgr admin_field_maps...

IC_fn:::bhl_itno
IC_vi:::bhl_it

University of Michigan, Museum of Art.

View an example record online.

How it looks in CollMgr admin_field_maps...

ic_vi:::musart_ti
ic_fn-type=summ.face=unspec.stid=1.y=1:::musart_sn
ic_fn-type=det.face=unspec.stid=2.y=1:::musart_rim
ic_vi-type=det.face=unspec.stid=2.y=1:::musart_rimc
    

University of Michigan, Advanced Papyrological Information System

View the example record online. Note that the apis structure has the potential to have a large number of images, but the example record happens to only have 6.

How it looks in CollMgr admin_field_maps...

ic_fn-type=summ.face=front.stid=1.y=1:::apis_fsfr1
   ic_fn-type=summ.face=front.stid=1.y=2:::apis_fsfr2
   ic_fn-type=summ.face=front.stid=1.y=3:::apis_fsfr3
   ic_fn-type=summ.face=front.stid=1.y=4:::apis_fsfr4
   ic_vi-type=summ.face=front.stid=1.y=1:::apis_fsfr1 apis_inv apis_inv apis_ss
   ic_vi-type=summ.face=front.stid=1.y=2:::apis_fsfr2 apis_inv apis_ss
   ic_vi-type=summ.face=front.stid=1.y=3:::apis_fsfr3 apis_inv apis_ss
   ic_vi-type=summ.face=front.stid=1.y=4:::apis_fsfr4 apis_inv apis_ss
   ic_fn-type=det.face=front.stid=1.y=1:::apis_600fr1
   ic_fn-type=det.face=front.stid=1.y=2:::apis_600fr2
   ic_fn-type=det.face=front.stid=1.y=3:::apis_600fr3
   ic_fn-type=det.face=front.stid=1.y=4:::apis_600fr4
   ic_fn-type=det.face=front.stid=1.y=5:::apis_600fr5
   ic_fn-type=det.face=front.stid=1.y=6:::apis_600fr6
   ic_fn-type=det.face=front.stid=1.y=7:::apis_600fr7
   ic_fn-type=det.face=front.stid=1.y=8:::apis_600fr8
   ic_vi-type=det.face=front.stid=1.y=1:::apis_600fr1 apis_inv apis_ss
   ic_vi-type=det.face=front.stid=1.y=2:::apis_600fr2 apis_inv apis_ss
   ic_vi-type=det.face=front.stid=1.y=3:::apis_600fr3 apis_inv apis_ss
   ic_vi-type=det.face=front.stid=1.y=4:::apis_600fr4 apis_inv apis_ss
   ic_vi-type=det.face=front.stid=1.y=5:::apis_600fr5 apis_inv apis_ss
   ic_vi-type=det.face=front.stid=1.y=6:::apis_600fr6 apis_inv apis_ss
   ic_vi-type=det.face=front.stid=1.y=7:::apis_600fr7 apis_inv apis_ss
   ic_vi-type=det.face=front.stid=1.y=8:::apis_600fr8 apis_inv apis_ss
   ic_fn-type=summ.face=back.stid=2.y=1:::apis_fsbr1
   ic_fn-type=summ.face=back.stid=2.y=2:::apis_fsbr2
   ic_fn-type=summ.face=back.stid=2.y=3:::apis_fsbr3
   ic_fn-type=summ.face=back.stid=2.y=4:::apis_fsbr4
   ic_vi-type=summ.face=back.stid=2.y=1:::apis_fsbr1 apis_inv apis_ss
   ic_vi-type=summ.face=back.stid=2.y=2:::apis_fsbr2 apis_inv apis_ss
   ic_vi-type=summ.face=back.stid=2.y=3:::apis_fsbr3 apis_inv apis_ss
   ic_vi-type=summ.face=back.stid=2.y=4:::apis_fsbr4 apis_inv apis_ss
   ic_fn-type=det.face=back.stid=2.y=1:::apis_600br1
   ic_fn-type=det.face=back.stid=2.y=2:::apis_600br2
   ic_fn-type=det.face=back.stid=2.y=3:::apis_600br3
   ic_fn-type=det.face=back.stid=2.y=4:::apis_600br4
   ic_fn-type=det.face=back.stid=2.y=5:::apis_600br5
   ic_fn-type=det.face=back.stid=2.y=6:::apis_600br6
   ic_fn-type=det.face=back.stid=2.y=7:::apis_600br7
   ic_fn-type=det.face=back.stid=2.y=8:::apis_600br8
   ic_vi-type=det.face=back.stid=2.y=1:::apis_600br1 apis_inv apis_ss
   ic_vi-type=det.face=back.stid=2.y=2:::apis_600br2 apis_inv apis_ss
   ic_vi-type=det.face=back.stid=2.y=3:::apis_600br3 apis_inv apis_ss
   ic_vi-type=det.face=back.stid=2.y=4:::apis_600br4 apis_inv apis_ss
   ic_vi-type=det.face=back.stid=2.y=5:::apis_600br5 apis_inv apis_ss
   ic_vi-type=det.face=back.stid=2.y=6:::apis_600br6 apis_inv apis_ss
   ic_vi-type=det.face=back.stid=2.y=7:::apis_600br7 apis_inv apis_ss
   ic_vi-type=det.face=back.stid=2.y=8:::apis_600br8 apis_inv apis_ss
   ic_fn-type=det.face=unspec.stid=3.y=1:::apis_alt
 ic_vi-type=det.face=unspec.stid=3.y=1:::apis_alt apis_inv apis_ss

dlxs-help@umich.edu