Large Image
About
Large image is the content model that UT Libraries uses to serve and preserve image objects that require a “zoom and pan” viewer for user display. Other than pages, this is the most common type of object that we serve. Large images can be a part of a collection or compound object but never a book. A large image that is part of a compound object has its own distinct metadata that describes unique things about it from other parts of the compound object.
As of February 4, 2021, the Libraries has 37471 large image objects.
Islandora 7: The Model and Its Binaries
A standard large image object looks like this:
RELS-EXT explains what the object is and how it relates to other objects in the repository. The file is written in RDF XML and always describes its relationships to other digital objects it is a part of.
OBJ is the preservation object. This is the most critical binary here.
MODS contains our descriptive metadata. Its relationship to RDF and linked data is described in our `UTK MODS to RDF documentation<https://utk-mods-to-rdf.readthedocs.io/en/latest/>`_.
DC is generated from our MODS on ingest based on a transform we supply. It is useful to the current Fedora API but is not significant for migration.
TN a thumbnail. Normally, this is generated automatically from the preservation object on ingest. This is not significant to our migration.
JP2 a lossy JP2 generated from the OBJ to make the viewing experience more performant. This is not significant to our migration.
JPG a JPG that is generated from the preservation object on ingest. This is not significant to our migration.
TECHMD is a FITS generated XML file based on the preservation object (OBJ). Ideally, this would be triples in a
fedora:Resource(maybe on the file rather than the object) in our next system.
Islandora 7: Identifying via RELS-EXT
A standard large image object has RDF that describes it and its relationship to other objects. It always has a
<info:fedora/fedora-system:def/model#hasModel> of info:fedora/islandora:sp_large_image_cmodel like this:
@prefix ns0: <info:fedora/fedora-system:def/relations-external#> .
@prefix ns1: <info:fedora/fedora-system:def/model#> .
<info:fedora/adams:82>
ns0:isMemberOfCollection <info:fedora/gsmrc:adams> ;
ns1:hasModel <info:fedora/islandora:sp_large_image_cmodel> .
As stated previously, large images can be parts of compound objects. When they are, they have triples that look like this:
@prefix ns0: <info:fedora/fedora-system:def/relations-external#> .
@prefix ns1: <info:fedora/fedora-system:def/model#> .
@prefix ns2: <http://islandora.ca/ontology/relsext#> .
<info:fedora/100201:7>
ns0:isConstituentOf <info:fedora/pcard00:100201> ;
ns1:hasModel <info:fedora/islandora:sp_large_image_cmodel> ;
ns2:isSequenceNumberOfpcard00_100201 "2" ;
ns0:isMemberOfCollection <info:fedora/gsmrc:pcard00> .
As you can see above, the RDF states that the large image info:fedora/100201:7 is a
<info:fedora/fedora-system:def/relations-external#isConstituentOf> the compound object <info:fedora/pcard00:100201>.
It also has a <http://islandora.ca/ontology/relsext#isSequenceNumberOfpcard00_100201> of 2 indicating
that it should be sorted in second position (our indexes start at 1 not 0). Compound objects are discussed in greater
detail elsewhere in the document.
Reimagining Large Image with PCDM
This section describes how a large image remodeled with PCDM may look in our new system.
The Object
A large image is a pcdm:Object with many files and a member of at least one Fedora collection.
1@prefix pcdm: <http://pcdm.org/models> .
2@prefix pcdmuse: <http://pcdm.org/use> .
3
4<https://localhost/my_sample_object> a pcdm:Object ;
5 rdfs:label: "My sample large image" ;
6 pcdm:hasFile <https://localhost/my_sample_object/OBJ>, <https://localhost/my_sample_object/PRESERVATION>, <https://localhost/my_sample_object/TN> ;
7 pcdm:memberOf <https://localhost/my_sample_collection> ;
The object will have metadata that describes it.
1@prefix dcterms: <http://purl.org/dc/terms/> .
2@prefix edm: <http://www.europeana.eu/schemas/edm/> .
3@prefix pcdm: <http://pcdm.org/models> .
4@prefix pcdmuse: <http://pcdm.org/use> .
5@prefix relators: <http://id.loc.gov/vocabulary/relators/> .
6
7<https://localhost/my_sample_object> a pcdm:Object ;
8 rdfs:label: "My sample large image" ;
9 pcdm:hasFile <https://localhost/my_sample_object/OBJ>, <https://localhost/my_sample_object/PRESERVATION>, <https://localhost/my_sample_object/TN> ;
10 pcdm:memberOf <https://localhost/my_sample_collection> ;
11 dcterms:title "My sample large image" ;
12 dcterms:abstract "A description or abstract that represents my large image" ;
13 relators:cre <https://localhost/some_prolific_person> ;
14 edm:rights <http://rightsstatements.org/vocab/CNE/1.0> ;
15 dcterms:subject <http://id.loc.gov/authorities/subjects/sh85147447> ;
16 dcterms:subject <http://id.loc.gov/vocabulary/graphicMaterials/tgm008085> .
The Preservation File
The image object will include a pcdm:PreservationFile that will be untouched and uncropped but will be kept for
longterm preservation.
1@prefix pcdm: <http://pcdm.org/models> .
2@prefix pcdmuse: <http://pcdm.org/use> .
3
4<https://localhost/my_sample_object/PRESERVATION> a pcdm:File, pcdmuse:PreservationFile ;
5 rdfs:label "Original and Untouched Digitized file" ;
6 pcdm:fileOf <https://localhost/my_sample_object> ;
The pcdm:PreservationFile will include technical metadata about the file.
1@prefix ebucore: <http://www.ebu.ch/metadata/ontologies/ebucore/ebucore> .
2@prefix pcdm: <http://pcdm.org/models> .
3@prefix pcdmuse: <http://pcdm.org/use> .
4@prefix premishash: <http://id.loc.gov/vocabulary/preservation/cryptographicHashFunctions/> .
5
6<https://localhost/my_sample_object/PRESERVATION> a pcdm:File, pcdmuse:PreservationFile ;
7 rdfs:label "Original and Untouched Digitized file" ;
8 pcdm:fileOf <https://localhost/my_sample_object> ;
9 premishash:md5 "07159c47ee1b19ae4fb9c40d480856c4" ;
10 ebucore:hasmimetype "image/tiff" ;
11 ebucore:filesize "16940000" ;
12 ebucore:filename "my_sample_file_original.tif" .
The Intermediate File
In our next system, we want a pcdm:IntermediateFile to be used to generate derivatives if we are unable to
generate those on the fly with IIIF. We think about this file being similar to our OBJ in our current system in that it
is the file where derivatives are derived from.
1@prefix pcdm: <http://pcdm.org/models> .
2@prefix pcdmuse: <http://pcdm.org/use> .
3
4<https://localhost/my_sample_object/OBJ> a pcdm:File, pcdmuse:IntermediateFile ;
5 rdfs:label "OBJ for My Sample Object" ;
6 pcdm:fileOf <https://localhost/my_sample_object> ;
The pcdm:IntermediateFile also has technical metadata about it.
1@prefix ebucore: <http://www.ebu.ch/metadata/ontologies/ebucore/ebucore> .
2@prefix pcdm: <http://pcdm.org/models> .
3@prefix pcdmuse: <http://pcdm.org/use> .
4@prefix premishash: <http://id.loc.gov/vocabulary/preservation/cryptographicHashFunctions/> .
5
6<https://localhost/my_sample_object/OBJ> a pcdm:File, pcdmuse:IntermediateFile ;
7 rdfs:label "OBJ for My Sample Object" ;
8 pcdm:fileOf <https://localhost/my_sample_object> ;
9 premishash:md5 "0cc175b9c0f1b6a831c399e269772661" ;
10 ebucore:hasmimetype "image/jp2" ;
11 ebucore:filesize "361730" ;
12 ebucore:filename "my_sample_file.jp2" .
Derivatives like Thumbnails
Derivatives only need to exist if we have a use case. We expect things like thumbnails should be able to be generated
on the fly from the pcdm:IntermediateFile. If for some reason it cannot be generated on the fly, we’d expect it
to look like this:
1@prefix ebucore: <http://www.ebu.ch/metadata/ontologies/ebucore/ebucore> .
2@prefix pcdm: <http://pcdm.org/models> .
3@prefix pcdmuse: <http://pcdm.org/use> .
4@prefix premishash: <http://id.loc.gov/vocabulary/preservation/cryptographicHashFunctions/> .
5
6<https://localhost/my_sample_object/TN> a pcdm:File, pcdmuse:ThumbnailImage ;
7 rdfs:label "A thumbnail generated from the OBJ (if IIIF not good enough)" ;
8 pcdm:fileOf <https://localhost/my_sample_object> ;
9 premishash:md5 "d3b07384d113edec49eaa6238ad5ff00" ;
10 ebucore:hasmimetype "image/png" ;
11 ebucore:filesize "47161" ;
12 ebucore:filename "my_sample_file_small.png" .
Visualing an object and its files in a repository of triplestore
An object and its files in a repository or triplestore would look something like this: