General Metadata Considerations
What immediately follows supersedes anything below it if what is below it is in contradiction with this. We need elements to distinguish the "of-ness" and "about-ness" of a resource (where and when it was created as opposed to the time and place it is describing).
Where something was created = bf:place (https://id.loc.gov/ontologies/bibframe.html#c_Place)
A place the resource is describing = dcterms:spatial (https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#http://purl.org/dc/terms/spatial)
When something was created = dcterms:date (https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#http://purl.org/dc/terms/date)
A time period the resource is describing = dcterms:temporal (https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#http://purl.org/dc/terms/temporal)
Upper-level ontologies include time and space (place, location). All cultural heritage objects were created at a place or location in time (sometimes multiples of each). Therefore, all cultural heritage objects must include at least one element for time and for space (place, location). Where these are unknown, they are indicated with the code "(:unkn)" for "unknown", from the DCMI Kernel Metadata. The front end will render that appropriately for users. Where these are known, we use the following conventions.
Where something was created = bf:place (https://id.loc.gov/ontologies/bibframe.html#c_Place)
A place the resource is describing = dcterms:spatial (https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#http://purl.org/dc/terms/spatial)
When something was created = dcterms:date (https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#http://purl.org/dc/terms/date)
A time period the resource is describing = dcterms:temporal (https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#http://purl.org/dc/terms/temporal)
- Values for time (dcterms:date) are expressed according to ISO 8601-2019, falling back to EDTF as needed.
- Values for place use codes drawn from the Getty Thesaurus of Geographic Names (TGN).
- Values for the language of text objects and for other object types if there is a language aspect (dcterms:language) use codes conforming to ISO 639-3:2007.
Values for place and language effectively internationalize searches, since the vernaculars for each will be leveraged to find the corresponding items.
dcterms:spatial
The Dublin Core Metadata Initiative (DCMI) defines dcterms:spatial as follows: Spatial characteristics of the resource. The Metadata Standards Crosswalk maintained by the Getty maps the following to Subject or Coverage.Spatial:
260a Place of Publication 651 [Subject Added Entry-Geographic Name] 655$z Genre/Form Term - Geographic Subdivision 752 Hierarchical Place Name
The Atlas of Digitised Newspapers and Metadata maps Place of Publication to dcterms:spatial.
The above conform to a simple reading of the DCMI specification for dcterms:spatial: Spatial characteristics of the resource.
OCLC's Best practices for creating shareable metadata includes the following quotation: “Currently recommended by the “Collaborative Digitization Project Dublin Core Metadata Best Practices” guide for use only ‘in describing maps, globes, and cartographic resources or when place or time period cannot be adequately expressed using the Subject element.’ Coverage spatial refers to the extent or scope of the content of the resource (e.g., place shown on a map or in a photograph, or geographic locations that are the topic of a manuscript), not the place of publication or digitization.” - Metadata Best Practices Guide, Western Michigan University Libraries. Here dcterms:spatial is associated with MARC 522 - Geographic Coverage Note, and the best practice is to use it for a restricted set of materials or if Subject is not able to adequately express place or time period. This consideration is too restrictive to be of applicability to UChicagoNode.
The Map and Geospatial Information Round Table (MAGIRT) of the American Library Association defined Metadata Best Practices when using ALAIR writes: "Use [dcterms:spatial] to state the place or area that is described or represented by the resource, not the place where the resource was published." (p. 21) However, the scope of this document is limited to map and geospatial information resources.
The Ohio Digital Network maps dcterms:spatial to MARC "651 #0 (for LCSH place names) or #7 with the specific vocabulary source provided in subfield 2 (TGN, for example); 043 subfield c and 650 subfield z. (All of these refer to place names; geospatial coordinates are preferred when possible)". (https://ohiodigitalnetwork.org/elements/place/)
The above show that cataloging best practice has sometimes restricted the scope of dcterms:spatial.
We are left with a decision which might be expressed in the following terms.
If we conform to the simple reading of the DCMI standard, and apply dcterms:spatial as the Getty's Metadata Standards Crosswalk does, then we will have to use another element to express the spatial coverage of a cultural heritage object where dcterms:subject is found insufficient, for example, Schema.org's contentLocation.
If we conform to the best practice of some catalogers in the interest of consistency, and restrict the use of dcterms:spatial, then we are still confronted with the need to express where a cultural heritage object was created. This is because all cultural heritage objects, to exist, must have a where and when of origin. (Some compound cultural heritage objects will have more than one place and/or one time of origin.) To be able to search for the place of origin across all cultural heritage objects, including books and maps, we will need an element to express that. We could create a local element, e.g., uchicago:spatial. This would allow dcterms:spatial to be used as some catalogers are wont to do.
Discovery and Display
Under the aegis of the International Federation of Library Associations and Institutions (IFLA) a study group reformulated the objectives [of a bibliographic system]:
... to /find/ entities that correspond to one's stated search criteria ... to /identify/ an entity ... to /select/ an entity ... to acquire or /obtain/ access to the entity described ...
Elaine Svenonius, The Intellectual Foundation of Information Organization (Cambridge, Massachusetts: The MIT Press, 2000), p. 17.
IFLA's restatement of the objectives of a bibliographic system is more applicable than the preceding statements of Panizzi, Cutter, and Lubetzky to systems which include cultural heritage objects of all types, including but not restricted to the book. Descriptions that facilitate finding, or discovery, are not necessarily the same as those which allow for selection. For example, I might want to search for "1968", but only afterwards to distinguish objects from 1968 as opposed to objects about 1968: I might not have had this distinction in mind when beginning the process of discovery; the process itself might have revealed this to me, or reminded me of it, or I might have typed "1968" into a keyword search box. UChicagoNode should facilitate discovering all objects from or about 1968, or from or about London, while allowing one to distinguish among these when information about them is displayed. This means that descriptive elements, should support both of these objectives, and the implementation of the system should target the appropriate elements at the appropriate stage of the searching process: the initial hit list; the subsequent short or full record display. An initial search for "London" might discover all objects from or about London; the display of those objects should contain descriptive information to tell me which is which.
With respect to books and maps, some might wish to consider them as artifacts of human culture. For example, one might be interested in book binding, marbling, typography, or page layout. This might prompt one to search for all books printed in Venice in the 17th century, or the like. The content of a book (what it describes) might be of only secondary importance to this research. Of primary importance would be the time and place of production. The Library encountered something similar when working on the Goodspeed Manuscript Collection: one scholar, a specialist in New Testament and early Christina literature, was interested in the content of the texts; one scholar, an epigrapher, was interested in the scribal hands; one scholar, an art historian, was interested in the illustrations. In this collection it is clear that the when and where of a text was the primary consideration, not temporal or spatial coverage. A primary goal of this project was description that accommodated all three scholarly interests. Since we do not know who the audience for Node will be, either today or tomorrow, we should anticipate the need to accommodate a variety of research interests.
Dublin Core
Use DCMI Terms in preference to DCMI Elements. Where EDM requires a DCMI Element, duplicate the corresponding DCMI Term.
Required Elements
Use all required EDM elements. In addition, use all elements required by local practice.