-
Notifications
You must be signed in to change notification settings - Fork 0
Image Collections Metadata
Metadata for digitized images is typically submitted as a spreadsheet, comma delimited text file (CSV), or tab delimited text file (TSV), with one line per object. Metadata may also be submitted as MODS XML, but please contact us first if you plan to submit you metadata records as XML. An Excel template is available, and should meet the needs of most Historic Pittsburgh digital image collections.
The following elements are required for every image in the Historic Pittsburgh Image Collections. If you are currently using an in-house database that doesn't permit adopting these particular elements, you will need to ensure that the metadata you submit matches these elements. If you are in a position to either start an in-house database or modify an existing one, we recommended that the required elements serve as a guide for creating core fields.
- Title
- Creator
-
Subject
- Topical Subject (lcsh)
- Geographic Subject (lcsh)
- Name Subject (lcsh)
- Description
- Date
- Date Qualifier
- Identifier
- Copyright Status
- Publication Status
- Copyright Holder
- Type of Resource
- Filename
- Source Collection Title
- Depositor
- Genre
- Format
- Extent
- Contributor
- Source Identifier
- Source Collection Identifier
- Source Collection Citation
- Address
- Batch
CSV Element Name | title |
---|---|
Description | A name given to the resource. |
Mandatory | Yes |
Repeatable | No |
MODS Element | mods:titleInfo/mods:title |
Dublin Core Mapping | dc.title |
Vocabulary/Encoding Scheme | Free text. No limitations. |
Notes and Best Practices | Typically, a Title will be a name by which the resource is formally known. The title should be concise; longer and more detailed information about the image contents should be entered in the “description” element. Avoid use of explanatory or qualifying symbols (e.g., brackets). Descriptive and informative titles are preferred whenever possible (as opposed to things like "unknown" or an identifier number). |
Examples |
|
CSV Element Name | creator |
---|---|
Description | An entity primarily responsible for making the content of the resource. |
Mandatory | Required, if applicable |
Repeatable | Yes |
MODS Element | mods:name/mods:namePart with mods:role/mods:roleterm="creator" |
Dublin Core Element | dc.creator |
Vocabulary/Encoding Scheme | Library of Congress Name Authority File (LCNAF), if possible. |
Notes and Best Practices | Creator is the person or corporate entity that took the photo or created the image. Use a controlled version of the proper name, if possible, drawing from LCNAF. If LCNAF term does not exist, use a similar syntax (Last Name, First Name, YYYY-YYYY). Multiple creators should be separated using a semicolon. Avoid use of placeholder values (e.g., “Unknown”). |
Examples |
|
Currently, subjects are limited to compound topical subjects, geographic, and name subjects. While we do permit compound headings, due to the limitations of using spreadsheets for metadata creation, we do not currently allow for mixed-type subject headings (e.g., topic--geographic--geographic, or topic-genre, or name-genre, for example). Please split mixed-type subject headings into the appropriate fields. If any of these limitations affect your ability to properly describe your resources, please get in touch with us with any questions.
CSV Element | subject_topic |
---|---|
Description | The topic of the content of the resource. |
Mandatory | Yes |
Repeatable | Yes |
Vocabulary/Encoding Scheme | Library of Congress Subject Headings |
MODS Element | mods:subject/mods:topic |
Dublin Core Element | dc.subject |
Notes and Best Practices | It is strongly recommended that the subject descriptors prioritize what the image is “of” rather than the more subjective sense of what the image is “about”. Referring to the MARC 21 Format for Bibliographic Data Subject Access Fields (6XX) can be helpful in determining the appropriate format for different subject headings. Although the order of subject headings has no effect on online access, some catalogers may find it helpful to follow the order of MARC 21. Images assigned more than one subject heading should be separated using a semicolon (e.g. Mayors; Buildings--Design and construction) to ensure proper online display. Because of limitations presented by collecting subjects in a spreadsheet, non-topical subdivisions should not be used. Geographic and Name headings can be added to those fields specifically, and Genre terms can be added to the Genre field. We do not currently support other subject heading types. If this presents a problem, please contact us with more information. |
Examples |
|
CSV Element | subject_geographic |
---|---|
Description | An account of the geographic location of the resource. |
Mandatory | Yes, if applicable |
Repeatable | Yes |
Vocabulary/Encoding Scheme | Recommend selecting from the ULS Metadata and Discovery Unit's Geographic Headings List which is derived from the Library of Congress Subject Headings and Library of Congress Name Authority File, as appropriate. Many local place names may not have authoritative versions. |
MODS Element | mods:subject/mods:geographic |
Dublin Core Element | dc.coverage |
Notes and Best Practices | If the image documents a physical place, one subject heading should be a geographic heading. If LCNAF term does not exist, use a similar syntax. Images assigned more than one geographic subject heading should be separated using a semicolon (e.g. Oakland (Pittsburgh, Pa.); Shadyside (Pittsburgh, Pa.)) to ensure proper online display. Because of limitations presented by collecting subjects in a spreadsheet, non-geographic subdivisions should not be used. Topic and Name headings can be added to those fields specifically, and Genre terms can be added to the Genre field. We do not currently support other subject heading types. If this presents a problem, please contact us with more information. |
Examples |
|
CSV Element | subject_name |
---|---|
Description | A name used as a subject. |
Mandatory | Yes, if applicable |
Repeatable | Yes |
Vocabulary/Encoding Scheme | Recommend selecting from the ULS Metadata and Discovery Unit's Name Authorities List which is derived from the Library of Congress Name Authority File, as appropriate. Many local place names may not have authoritative versions. In that case, names should be structured using the standard NAF style. |
MODS Element | mods:subject/mods:name/mods:namePart |
Dublin Core Element | dc.subject |
Notes and Best Practices | If the image documents a person or corporate entity, one subject heading should be a name heading. If LCNAF term does not exist, use a similar syntax. Images assigned more than one name subject heading should be separated using a semicolon (e.g. Carnegie Museum of Art; Carnegie Museum of Natural History) to ensure proper online display. Because of limitations presented by collecting subjects in a spreadsheet, non-name subdivisions should not be used. Geographic and Topical headings can be added to those fields specifically, and Genre terms can be added to the Genre field. We do not currently support other subject heading types. If this presents a problem, please contact us with more information. |
Examples |
|
CSV Element | description |
---|---|
Description | An account of the content of the resource. |
Mandatory | Yes |
Repeatable | Yes |
Vocabulary/Encoding Scheme | Free text. No limitations. |
MODS Element | mods:abstract |
Dublin Core Element | dc.description |
Notes and Best Practices | Description may include but is not limited to: an abstract or a free-text account of the content. It should be noted when descriptions are derived from words written on or part of the image itself. Consider that all of the text in a description is included when a user performs a general search; for this reason background / contextual description that mentions people, places, or things not present in the image itself should be carefully considered. |
Examples |
|
CSV Element | normalized_date |
---|---|
Description | A date associated with the creation of the resource. |
Mandatory | Yes |
Repeatable | No |
MODS Element | mods:originInfo/mods:dateCreated[@encoding="iso8601" @keyDate="yes"] |
Dublin Core Element | dc.date |
Vocabulary/Encoding Scheme | ISO8601 |
Format | The date must be entered as a normalized date, roughly following the ISO 8601 standard. In practice, this means:
|
Notes and Best Practices | Generally, this is the date that the photograph is known or estimated to have been taken. An estimated date is better than not providing a date at all. For undated material, normalize as an interval (as with approximate dates), perhaps using context clues from the image, the collection dates, or life of creator. A "normalized", formatted date is required. Adherence to this format will allow dates to be manipulated in programmatic ways, such as accurate sorting of images. For display and sorting purposes, the normalized date will be transformed during metadata processing. Dates can be marked with a "ca." designation using the Date Qualifier element, described below. Date ranges will be collapsed to use the earliest date for sorting purposes. |
Examples | What follows are some suggestions and strategies for expressing unknown or incomplete dates while still adhering to a "normalized" date format, similar to the ISO standard.
|
CSV Element | normalized_date_qualifier |
---|---|
Description | Functional element used to designate approximate (e.g. "circa") dates |
Mandatory | no |
Repeatable | no |
MODS Element | n/a |
Dublin Core Element | n/a |
Vocabulary/Encoding Scheme | yes/[blank] |
Notes and Best Practices | Date Qualifier is used to designate "approximate" dates, will be represented by including a "ca." with the displayed date. The default is blank. If a date should be displayed with a "ca." designation, enter "yes" in the field. |
Examples |
|
CSV Element | identifier |
---|---|
Description | An unambiguous reference to the resource within a given context. |
Mandatory | yes |
Repeatable | no |
MODS Element | mods:identifier[@type="pitt"] |
Dublin Core Element | dc.identifier |
Vocabulary/Encoding Scheme | Specific formatting is required for this field: The value must be a combination of an eight-digit date, your depositor ID (see "Depositor Metadata" below), and a zero-padded four-digit number. The three data values should be joined with a dash ("-") and no spaces. No other punctuation is permitted. |
Notes and Best Practices | The identifier is a unique reference to the digital object that is being created. Using the format described above ensures uniqueness, while limiting the difficulties of creating and tracking identifiers. If a physical object already has an identifier, it should not be stored here. Instead, use the optional "Source Identifier" field (see "Recommended Elements" below). Using a Source Identifier field will allow you to identify and correlate the online images seen by users with the physical object in its existing identification scheme. |
Examples |
|
CSV Element | copyright_status |
---|---|
Description | Indicates the basic copyright information for the object. |
Mandatory | yes |
Repeatable | no |
MODS Element | mods:accessCondition/copyrightMD:copyright/@copyright.status |
Dublin Core Element | dc.rights |
Vocabulary/Encoding Scheme | Copyright metadata is based on the copyrightMD XML schema (user guidelines PDF) from the California Digital Library and rightststatements.org. |
Format | Values for copyright status:
|
Notes and Best Practices | The Copyright Status element is intended to provide user-oriented information about the object, and not intended to serve as a record keeping mechanism for other copyright-related information collected and gathered by institutions for internal management, such as donor agreements, copyright permission request histories, etc. During metadata transformation, the CopyrightMD code will be replaced with a rightstatements.org statement, as demonstrated in the examples below. |
Examples | Rights information will be displayed in the online collection using the following right statements. The displayed statement will include the copyright holder, if available.
|
CSV Element | publication_status |
---|---|
Description | Indicates the basic publication information for the object |
Mandatory | yes |
Repeatable | no |
MODS Element | mods:accessCondition/copyrightMD:copyright/@publication.status |
Dublin Core Element | n/a |
Vocabulary/Encoding Scheme | Copyright metadata is based on the copyrightMD XML schema (user guidelines PDF) from the California Digital Library and rightststatements.org. |
Format | Values for Publication Status:
|
CSV Element | rights_holder |
---|---|
Description | Indicates the copyright holder for the object. |
Mandatory | Required if Copyright Status is "copyrighted". |
Repeatable | no |
MODS Element | mods:accessCondition/copyrightMD:copyright/ copyrightMD:rights.holder/copyrightMD:name |
Dublin Core Element | n/a |
Vocabulary/Encoding Scheme | Library of Congress Name Authority File (LCNAF), if possible. |
Notes and Best Practices | Required only if Copyright Status is "copyrighted". It should be left blank otherwise. Copyright metadata is based on the copyrightMD XML schema from the California Digital Library (user guidelines PDF). |
Examples |
|
CSV Element | type_of_resource |
---|---|
Description | A term that specifies the characteristics and general type of content of the resource. |
Mandatory | yes |
Repeatable | no |
MODS Element | mods:typeOfResource |
Dublin Core Element | dc.type |
Vocabulary/Encoding Scheme | MODS Type of Resource Vocabulary |
Notes and Best Practices | The information in Type of Resource is taken for the MODS field of the same name, and describes the original or source object. For example, in the case of a digitized photograph, would apply to the analog original; in born-digital materials, it would apply to the original digital format. The values for Type of Resource are controlled and the available list is below. A majority of Historic Pittsburgh Image Collections will be still images, but if your collection includes maps (cartographic) or images of three dimensional objects, for example. This field maybe used for faceting. If you would like more fine-grained description of the object, you can include the optional genre and format fields (see below). |
Examples | Values for Type of Resource:
|
CSV Element | filename |
---|---|
Description | The name, including the type extension, of the file. |
Mandatory | yes |
Repeatable | no |
MODS Element | n/a |
Dublin Core Element | n/a |
Vocabulary/Encoding Scheme | The filename must be unique within your digital collection and should include the 3-character filename extension (most always .tif). |
Notes and Best Practices | The filename should contain alphabetic or numeric characters. The filename should not be case-sensitive. A limited set of punctuation is permitted, including dash (-), underscore (_), and period (.). If feasible, we recommend using the same naming scheme as with Identifier above, which ensures uniqueness while limiting difficulties of creating filenames. |
Examples |
|
CSV Element | source_collection |
---|---|
Description | Collection from which the images were selected. |
Mandatory | yes |
Repeatable | no |
MODS Element | mods:relatedItem/mods:titleInfo/mods:title |
Dublin Core Element | dc.relation |
Vocabulary/Encoding Scheme | Collection title, and dates |
Notes and Best Practices | The Source Collection name is generally an abbreviated version, with just the collection name and dates. A more complete collection name can be stored in the Source Collection Citation field. |
Examples |
|
CSV Element | depositor |
---|---|
Description | Official name of the depositing institution. |
Mandatory | yes |
Repeatable | no |
MODS Element | mods:name/mods:namePart with mods:role/mods:roleterm="depositor" |
Dublin Core Element | dc.contributor |
Vocabulary/Encoding Scheme | Free text. No limitations. |
Notes and Best Practices | The Depositor is the official name of the entity responsible for depositing the objects in Historic Pittsburgh. This metadata will be used in faceting to allow users to limit to materials in your collections. |
Examples |
|
CSV Element | genre |
---|---|
Description | A term or terms that designate a category characterizing a particular style, form, or content, such as artistic, musical, literary composition, etc. |
Mandatory | no |
Repeatable | yes |
MODS Element | mods:genre |
Dublin Core Element | dc.type |
Vocabulary/Encoding Scheme | Genre Terms for Historic Pittsburgh Digital Objects |
Notes and Best Practices | Genre allows contributors to give more specificity for the form of an object than the broad terms used in Type of Resource. It is recommended that contributors select terms from the "Genre Terms for Historic Pittsburgh Digital Objects", maintained by the University of Pittsburgh Metadata & Discovery Unit. |
Examples |
|
CSV Element | format |
---|---|
Description | A designation of a particular physical presentation of a resource, including the physical form or medium of material for a resource. |
Mandatory | no |
Repeatable | no |
MODS Element | mods:physicalDescription/mods:form |
Dublin Core Element | dc.format |
Vocabulary/Encoding Scheme | Free text. No limitations. |
Notes and Best Practices | Format includes information that specifies the physical form or medium of material for a resource. |
Examples |
|
CSV Element | extent |
---|---|
Description | Size or duration of the object. |
Mandatory | Yes, if known |
Repeatable | no |
MODS Element | mods:physicalDescription/mods:extent |
Dublin Core Element | dc.format |
Notes and Best Practices | Text representation of the approximate dimensions of the resource. |
Examples |
|
CSV Element | contributor |
---|---|
Description | An entity responsible for making contributions to the resource. |
Mandatory | no |
Repeatable | yes |
MODS Element | mods:name/mods:namePart with with mods:role/mods:roleterm="contributor" |
Dublin Core Element | dc.contributor |
Vocabulary/Encoding Scheme | Library of Congress Name Authority File (LCNAF), if possible. |
Notes and Best Practices | Contributor is the person or corporate entity that contributed in the creation of the resource. Use a controlled version of the proper name, if possible, drawing from LCNAF. If LCNAF term does not exist, use a similar syntax (Last Name, First Name, YYYY-YYYY). Multiple contributors should be separated using a semicolon. Avoid use of placeholder values (e.g., “Unknown”). |
Examples |
|
CSV Element | source_identifier |
---|---|
Description | Identifier associated with the physical object, rather than the digital image of the object |
Mandatory | no |
Repeatable | no |
MODS Element | /mods:mods/mods:identifier[@type="source"] |
Dublin Core Element | dc.identifier |
Vocabulary/Encoding Scheme | Free text. No limitations. |
Notes and Best Practices | May be accession number or other number associated with the image. Allows you to connect the physical item with the digital object. |
Examples |
|
CSV Element | source_collection_id |
---|---|
Description | Identifier associated with the physical collection, rather than the digital collection |
Mandatory | no |
Repeatable | no |
MODS Element | /mods:relatedItem[@type="host"]/mods:identifier |
Dublin Core Element | n/a |
Vocabulary/Encoding Scheme | Free text. No limitations. |
Notes and Best Practices | May be accession number or other number associated with the parent collection. Allows you to connect the physical collection with the digital collection. |
Examples |
|
CSV Element | source_citation |
---|---|
Description | Full citation for physical collection. |
Mandatory | no |
Repeatable | no |
MODS Element | mods:relatedItem/note[@type="prefercite"] |
Dublin Core Element | n/a |
Vocabulary/Encoding Scheme | Free text. No limitations |
Notes and Best Practices | Typically includes the full collection name, dates, identifier, and owning institution. |
Examples |
|
CSV Element | address |
---|---|
Description | Street address represented in the image |
Mandatory | no |
Repeatable | no |
MODS Element | /mods:note[@type="address"] |
Dublin Core Element | n/a |
Vocabulary/Encoding Scheme | Free text. No limitation |
Notes and Best Practices | Should only be used if an exact street address can be determined. Not recommended for most collections. |
Examples |
|
CSV Element | batch |
---|---|
Description | Internal batch number for a set of submitted objects. |
Mandatory | no |
Repeatable | no |
MODS Element | n/a |
Dublin Core Element | n/a |
Vocabulary/Encoding Scheme | Free text. No limitations. |
Notes and Best Practices | This is typically internal documentation, and is not used for display or sorting in the Islandora system. This is a "legacy" field from our old methods and is not recommended. |
Examples |
|