CORC, the Dublin Core, and Cartographic Materials
By David Yehling Allen
(This is a working draft dated 12/28/1999. Please send comments and corrections to the
author at email@example.com.)
Both the Dublin Core and CORC were intended, among other things, to simplify cataloging. A major reason for their development was to make it possible for staff with minimal training to create bibliographic records, particularly for materials found on the Internet. Simplicity and flexibility were the watchwords of the creators of CORC and the Dublin Core.
So far, the goal of greater simplicity has proved illusive, at least for those who work with cartographic materials in digital form. (Cartographic materials include maps, atlases, aerial photographs, satellite images and geospatial data files.) Only in the case of conventional maps and atlases on paper, can either the Dublin Core or CORC be said to have made cataloging easier. Both CORC and the Dublin Core do hold considerable promise for simplifying the cataloging of cartographic materials on the World Wide Web, but so far no consensus has emerged on how to use them for that purpose.
There are a number of reasons why CORC and the Dublin Core have not yet realized their promise in this area. Ironically, the very simplicity of Dublin Core cataloging has created a good deal of confusion about how it should be applied. The basic Dublin Core record consists of only fifteen fields, none of which are mandatory, all of which are repeatable, and all of which can be of any length and in any order. Given this situation, it is understandable that there should be some confusion about what goes where, especially when dealing with complex bibliographic records. Progress has been made in defining the content of the basic fifteen fields, but it is still not always clear how some of them should be applied in specific cases.(1) Guides to best practice have been developed for the basic Dublin Core fields. These can be quite helpful, but none of them directly address cartographic materials.(2)
The CORC project staff has responded to the need for definition by adding to the basic fields a number of extensions or "qualifiers." The purpose of these qualifiers is often not clearly defined, and it is sometimes difficult to decide in which subfield information should be entered. There is little documentation to help CORC users figure out how to apply these qualifiers. The CORC staff is constantly adding to and modifying the available modifiers, which means that records in CORC only a few months old are likely to be cataloged somewhat differently from those done today. Furthermore, the CORC staff has been reluctant to issue rules concerning how CORC should be used. They have only recently made it mandatory that all records contain a title.
The situation is further complicated for maps by the wide variety of cartographic materials, and by the complexity of some of the bibliographic records for them, especially records for geospatial data. Furthermore, there is no agreement among map librarians themselves as to what constitutes a minimally acceptable bibliographic record for a map, and some of the rules for cataloging complex cartographic materials are still undetermined.(3) Finally, there is a major unresolved controversy, which will be touched upon below, concerning how digital images should be cataloged using the Dublin Core. The many uncertainties and unresolved problems have made most map librarians reluctant to work with the Dublin Core, at least until some of the dust settles. This situation will doubtless persist until such time as map librarians themselves come to some agreement concerning what is "best practice" and "minimally adequate" Dublin Core cataloging, and how they should be implemented in the CORC environment.
Nonetheless it is possible to catalog the full range of cartographic materials using CORC. For those bold spirits who don't mind cataloging in an environment where all the rules have not been laid down, I can provide some suggestions. My suggestions reflect my own background, which involves considerable experience as a creator of computerized bibliographies of maps, but not as a cataloger. I am mainly concerned about how CORC and the Dublin Core can help map librarians with limited time and cataloging expertise. As a librarian, I nonetheless recognize the value of uniform cataloging, and urge that CORC records be modeled as closely as possible on standard MARC and AACR II. This commonality will facilitate the use of Dublin Core and MARC on the same platform, ensure that searches for records in automated systems will retrieve the maximum number of relevant records, and make it easier to upgrade Dublin Core to MARC cataloging.
In discussing the cataloging of maps on CORC, it is convenient to distinguish between
three groups of cartographic materials. The first group consists of old-fashioned maps,
atlases, and aerial photographs formatted on paper. The second group is made up of raster
images of paper maps and aerial photographs that appear on the Internet. The third group
consists of metadata for complex cartographic software and data files.
The Use of CORC for Conventional Map Cataloging
The application of CORC to conventional map cataloging is relatively straightforward. Although CORC was designed primarily for cataloging materials on the Internet, it is also used for cataloging of paper materials. The basic simplicity of the Dublin Core makes CORC an attractive option for this type of cataloging. Dublin Core cataloging on CORC is simple enough that many maps can be cataloged adequately by library staff with minimal training. They constitute a form of brief cataloging that is even simpler than brief cataloging in MARC.
Because of the flexibility of the Dublin Core, catalog records for maps in CORC can
range from the very simple to the very complex. A minimal level record might look
something like this:
CORC: 208353 Created: YSM 1999-10-19
Status: Complete Modified: YSM 1999-11-12
|Title||Map of Freeport village, Nassau Co., N.Y.|
|Description.Physical||1 map; 35 x 33 cm.|
|Creator.CorporateName||Smith & Malcomson|
Those who undertake to create minimal level records should try to follow standard cataloging conventions as much as possible. Names should be entered last name first; standard library practice should be followed for capitalization of titles; maps should be measured in centimeters (top to bottom, then left to right). Name authority control should be used wherever possible.
There is no agreement concerning what constitutes the minimum number of fields in an acceptable cataloging record for a map. Creator (author), title, and date of publication would seem to be the only absolutely essential fields. When available, publisher and place of publication would also be included by most catalogers. I consider the physical description to be very important. Some would consider scale or even bounding coordinates to be essential. Most libraries would want to put some sort of classification number in their records. Although maps can often be located using title keywords, standardized subject access is highly desirable. For consistency of retrieval in databases with MARC records, the use of LC subject headings is strongly recommended. As alternative sources of geographic names, digital gazetteers, such as The Getty Thesaurus of Geographic Names or the U.S. governments Geographic Names Information System (GNIS) might be used.(4) If subject keywords are used, the word "maps" should always be included to make possible retrieval by format.(5)
It is, of course, possible to create much more elaborate Dublin Core cataloging records, which have all of the elements of a complete MARC 21 record and more. Examples of such cataloging can be seen in illustrations 2 and 4. (Although these examples include some additional fields because they are records for map images on the Internet, most of the familiar MARC fields can also be seen in them.) Many map catalogers would urge the inclusion of such fields as scale and geographic coordinates in all records. But the creation of high-level cataloging requires a much greater investment in training and staff time, and librarians have to ask themselves whether the improvement in access made possible through the creation of such records justifies the additional time and expense. Keep in mind that brief cataloging can always be upgraded later. For those interested in high-level cataloging in Dublin Core, the Library of Congress has prepared a Dublin Core-MARC crosswalk. The latest revision of this crosswalk includes many of the CORC qualifiers for the Dublin Core.(6)
The only major problem catalogers are likely to encounter in creating Dublin Core records in CORC is with diacritics and special characters (including the degree sign used in geographic coordinates). These have to be entered by placing a special code between two vertical bar (pipe) symbols--for example |ds| for degree sign. At present these codes do not display the symbols they represent, and they make searching for words with diacritical characters nearly impossible. These problems are supposed to be fixed "when the CORC database migrates to Unicode." In the meantime, I would recommend not using any diacritical marks or special characters at all.(7)
At present there are not many libraries that would want to use CORC to catalog paper maps. Most CORC participants are large institutions that are used to cataloging on systems like OCLC and exporting the records to run on their own online catalogs. Since Dublin Core records in CORC have to be upgraded to MARC before they can be exported to OCLC. or run on most local catalogs, the effort involved in upgrading the records cancels out most of the savings in cost or staff time. In some situations, it might still be worthwhile for the map librarian to create records in Dublin Core format, and for someone in the cataloging department to revise them and upgrade them to MARC, but I know of no cases where this is actually done. Most of the map cataloging records in CORC that come from major institutions appear to have been originally created in MARC.
Librarians have also avoided using CORC for map cataloging because at present it has no means of indicating multiple holdings. Most librarians would agree that it makes no sense to create individual item records for materials held by many institutions. It is much easier to add a holdings symbol to an existing record. CORC recognizes this problem, and promises to institute multiple holdings sometime in the future.
These technical problems should be fairly easy to solve, and the CORC staff has
promised to take care of them. Once these problems are solved and CORC goes into
production mode around the middle of 2000, it is possible that CORC will come to be used
widely for cataloging maps, especially at smaller institutions, such as historical
societies. It will require several conditions for this to happen. First, it will have to
be made possible for such libraries to participate in CORC or its successor. It would be
helpful if software would be made available to individual libraries to run CORC databases
on their own computers. It would be highly desirable if CORC records could be easily
exported to local OPACs. And it would be necessary to make it possible to add holdings
information to records. If all or most of these conditions were fulfilled, Dublin Core
cataloging in CORC might take off.
Cataloging Raster Images in CORC
The most obvious use for CORC is cataloging images of maps on the Internet. There are by now thousands of raster images of maps and aerial photographs on the World Wide Web, but there is no practical way to search for them across platforms. Except in the rare cases where individual maps are listed in the metadata headers of Web pages, standard search engines do not pick up maps by title and author. Listservs used by map librarians and others interested in cartography have carried considerable discussion about how to facilitate finding individual maps on the Web. Creating records for these maps in the CORC database seems to be the best solution for this problem. Even with its limited holdings CORC is already the most comprehensive tool for searching out maps on the Internet.
However, there is no consensus concerning how raster images should be cataloged using the Dublin Core or in CORC. As with paper maps, it is possible to create records that range from very simple to very complex. There has been considerable debate within the Dublin Core community about how to catalog materials formatted as digital images. One issue is the extent to which catalogers should treat images as surrogates of the originals (much as microforms or photocopies), and the extent to which each image should be cataloged as an original, unique creation. Assignment of such primary fields as "creator," "publisher," and "date" is affected by how one regards this issue. One school of thought would assign all of these fields to the digital product, and relegate information about the original to the "Source" field (which can be used for information about the resource from which the digital resource is derived), or to the "Relation.Is FormatOf" field (now preferred). A related issue is the extent to which Dublin Core records should include detailed metadata about the image itself. Information of this type includes such things as dynamic range, color lookup tables, and characteristics of original image capture (such as scanning process, light source, and source image).(8)
There may never be complete agreement on these questions. As there are no established guidelines for cataloging cartographic images on CORC, I will suggest some of my own. My suggestions are based partially on statements from CORC staff on how individual fields should be applied. In other cases I have tried to follow common sense, and to mirror what I perceive to be standard cataloging practice. One of the principles I have tried to apply as much is possible is the idea that the record for the image of a map should resemble as closely as possible the record for the original map--i.e.. that the image should be treated as a surrogate of the original.(9)
Proceeding along these lines, the cataloging records for raster images of paper maps can be very similar to standard cataloging records for the original materials. To create a basic record for a digital image it is only necessary to add a few additional fields. These include, at the very least, the URL for the image, and information about the size and type of the image (e.g. JPEG 250 kb). Information about rights management may also be important. Additional information is desirable, but it is not always available. It is also questionable whether it is worth the time and effort to add detailed metadata about image creation to the record, as opposed to making a link to a site where it is available.
This approach is basically similar to that taken by the Library of Congress. The
following is an example of LC cataloging in Dublin Core format for one of the map images
they have placed on the Web. The record looks much the same as a record for a paper map,
with the sole exception of the addition of the "Identifier.URL" field.
CORC: 87 Created: DLC 1972-09-06
Status: System: OCL 1999-05-01
|Title||Map of New Jersey and Pennsylvania exhibiting the post offices, post roads, canals, railroads, & c.|
|Creator.PersonalName||Burr, David H., 1803-1875.|
|Description.Physical||col. map 91 x 124 cm. on 4 sheets 48 x 63 cm|
|Description||Relief shown by hachures.|
|Description.Summary||Detailed map showing relief by hachures, drainage, township and county boundaries, cities and towns, canals, roads, and railroads. [From published bibliography].|
|Relation.IsReferencedBy||LC Railroad maps.|
|Subject.LCSH||Railroads--New Jersey-- Maps.|
|Subject.LCSH||Postal service--New Jersey--Maps.|
|Subject.LCSH||Post roads--New Jersey--Maps.|
For some reason, the field for map scale, which displays in the MARC version of this record, is not mapped to the Dublin Core version. Note also that the "Date.Issued" field corresponds to the date of publication of the original map, as is the case with all the Library of Congress records for historical maps that I have seen in CORC. This record also is missing the "Format.MIME" field, which is not usually included in LC records for historical maps, but which I use to indicate file type and size.
Records in CORC for cartographic images can be even simpler than this The following is
an example of a record which the present author created from a record retrieved from the
CORC: 208856 Created: YSM 1999-10-26
Status: Complete Modified: YSM 1999-11-11
|Title||Chief points of interest in upper Manhattan|
|Description.Summary||Black and white tourist map (1920).|
|Format.MIME||image/JPEG (429 Kb)|
|Publisher.Name||Automobile Blue Book|
|Subject.Geographic||New York (N.Y.)--Maps|
Note the handling of the date of publication in the above record. The date of original publication is placed under "Coverage.Time," which is the practice recommended by CORC for the Dublin Core. If the information had been available, the date of publication of the digital image would have been placed under "Date.Issued." Since that information was not available, "Date.DataGathered" was used. This is not the practice that I would like to see adopted for dates. Ideally, I would prefer to see "Date.Issued" reserved for the date of publication of the original; "Coverage.Time" restricted to situations such as a modern map showing Europe at the time of Napoleon; and a new qualifier, such as "Date.Digitized" introduced for the date of creation of the digital image.
Although the above record would benefit from bibliographic enrichment, it was the best that could be done using the information available on the Web and without doing further research. I would submit that a simple record like this provides enough information for most researchers to locate the map. It is certainly better than nothing.
Records in CORC can be much more elaborate than either of the examples given above.
Here is an example containing most of the information that would be found in a standard
MARC record for a paper map, along with a good deal of image metadata:
CORC: 202432 Created: YSM 1999-08-05
Status: Complete System: OCL 1999-10-27
|Title||Connecticut and parts adjacent by Bernard Romans.|
|Title.Alternative||Connecticut at the time of the ratification of the Constitution.|
|Publisher||U.S. Geological Survey|
|Contributor.CorporateName||United States. Constitutional Sesquicentennial Commission. Geological Survey (U.S.)|
|Coverage.Geographic||W 73°40'--W 71°46'/N 42°10'--N 40°58|
|Creator.PersonalName||Romans, Bernard, ca. 1720-ca. 1784|
|Description.Edition/Version||Reprint of map published in 1780 by Covens and Mortier, Amsterdam. Originally published in Norwich, Conn., 1777.|
|Description.Physical||1 map : col. ; 46 x 52 cm.|
|Description.Note||Scale [ca. 1:500,000]|
|Description.Note||UCONN MAGIC: Connecticut Scanned Historical Maps|
|Description.Note||Relief shown pictorially.|
|Description.Note||Shows counties, towns, rivers, and post roads.|
|Description.Note||LC copy annotated in pencil: By Bernard Romans, 1777.|
|Description.Note||In upper border : Connecticut at the time of the ratification of the Constitution, from a 1780 original in the Library of Congress at Washington, issued by the United States Constitution Sesquicentennial Commission.|
|Description.Note||Scanned from the copy.|
|Description.Note||Image: 28.86111 inches high (2,078 pixels) 27.48611 inches wide (1,979
pixels) X dpi: 72 Y dpi: 72 Size in memory:
11,731,944 bytes. Original file size: 923,647 bytes on disk JPEG Compression 24-bit RGB Color
|Description.Summary||Scanned image of a 1937 facsimile of Bernard Romans' map of Connecticut and Long Island. Original copy published in Amsterdam in 1780 is based on an earlier edition published in Hartford in 1777.|
|Rights.Access||Contact Map Collection, University of Connecticut.|
|Subject.Keyword||Finley; Connecticut; history; map; MAGIC; Map And Geographic Information
Center; UCONN; University of
Connecticut; GIS; Graphic Information System; Geo-Spatial; Geography; Mapping; ArcInfo; MapInfo
|Subject.Geographic||Connecticut -- Administrative and political divisions -- Maps -- Early works to 1800.|
|Subject.Geographic||Connecticut -- Maps -- Early works to 1800.|
|Subject.Geographic||Long Island (N.Y.) -- Maps -- Early works to 1800.|
The above record illustrates one way a very complete cataloging record in Dublin Core format could be presented in CORC, although the choice of fields for some of the information is debatable. It also illustrates some of the problems which come up in assigning traditional author, publisher, and date information to a digital image of a map, which is itself a copy of a 1937 facsimile of an early map published in 1780 (which is turn a reprint of a map published in 1777). There is no obvious "best" way of handling these relationships. The assumption followed here is, again, that the researcher is most likely going to be interested in information about the original map, and I have relied on a series of notes to explain the complex chain of relationships between the image and its predecessors. Note also the use of keywords (derived from the metadata header of the Web version of this record at the University of Connecticut). The keywords are used in addition to conventional geographic subject headings. According to recommended Dublin Core practice, it is preferred that each keyword be entered in a separate field, but stringing them together separated by semicolons, as is done here, is acceptable.
Note also the geographical coordinates in the "Coverage.Geographic" field. This field corresponds to the 255 field in MARC (cartographic mathematical data), which is also used for scale. Given the purpose of the Dublin Core field, however, I would not recommend using it for scale as well as coordinates. For want of a better alternative, I have put scale under "Description.Note."
The inability of the present version of CORC to provide holdings information is not a serious drawback for images on the Web, since every image is in some ways unique. Each record will have a different URL, and probably different images of a map will be scanned at varying resolutions or differ in other ways. There may also be multiple images of a map, with some of them being details. Records for at least two different images of the Romans map discussed above can be found in the The CORC database, and multiple records can be found for several other historical maps with more than one image on the Web.
A word should be said about the use of "pathfinders" in the context of this discussion of records for digital images of maps. CORC has the ability to create "dynamic pathfinders" on any subject, including maps. These are pages of links to materials on the Web and elsewhere, and can be based on predefined searches. The pathfinders are automatically updated by CORC when new records matching predefined search criteria are added to the database. As an experiment I created a simple pathfinder for all of the New York State Maps in CORC (pathfinder no. 114). The pathfinder creation process is still riddled with computer bugs, and it was necessary for me to download the pathfinder in html and edit it to eliminate the most glaring errors before making it widely available.(10) In spite of the problems, these pathfinders are potentially useful as a way to allow inexpert users to find maps on a particular region or subject.
One peculiarity of pathfinders should be mentioned. If you want a description of a resource included with each link, the information has to be entered in a field entitled "Description.Summary." Making this change for a record produced by another library involves tinkering with someone else's cataloging. Revision of records is freely permitted by the CORC system in spite of its potential for mischief. It will be interesting to see how this issue will be dealt with if the CORC user community expands to a large number of libraries.
Although there is much to be said for CORC as a tool for creating and retrieving bibliographic records for images of maps on the Internet, it could be improved. A minor problem is the inability of its search engine to select from the database maps that are actually available on the Internet. A search for maps of a particular subject will indiscriminately retrieve records for both paper maps and Internet resources. This is an annoyance if you are looking for a list of links that you can actually click on and view. This problem could be easily solved by making it possible to exclude from a search records that do not have a URL.
Another problem for CORC users is created by the ephemerality of resources on the Internet. Some of this is unavoidable, but it is frustrating to create records for materials that cease to exist after a few months. Fortunately, most people who put up maps on the Web seem to keep them there more or less indefinitely. More serious is the problem caused by changing URLS, which quickly make links from CORC obsolete. OCLC has advocated the use of Persistent Uniform Resource Locators (PURLs) to solve this problem, and I heartily endorse the idea.(11)
There are also some fundamental problems with CORC as a retrieval tool for historical maps, although most of these problems are shared with other software used for retrieving maps. Researchers looking for cartographic materials are likely to be concerned with two things: retrieving maps of a specific geographic area, and being able to retrieve materials by date of coverage. CORC has significant weaknesses in both of these areas.
Most map searches are usually for coverage of a specific place. The lack of authority control in CORC makes search results less consistent than they would be if a uniform scheme, such as LC subject headings, were used. Nonetheless, the geographic subject headings used by the Library of Congress are little more than keywords, which are usually found in the title of a map. Thus, the lack of authority control is only a moderate drawback for keyword searching.
A broader problem, which CORC does nothing to address, is the inadequacy of both keyword and subject searching as a means of retrieving maps of a specific area. A researcher studying, say, a particular town, may want to look at many items that do not include the town name in either the title or the subject fields--these commonly include county maps, topographic maps, and aerial photographs. To solve this problem, map librarians have fought long and hard for the inclusion of geographic coordinates (longitude and latitude) in bibliographic records. As mentioned above, CORC has responded to this need by designating a specific field (Coverage.Geographic) for coordinates. But CORC does not as yet include any means of searching for records which include or fall within a specific set of coordinates.. This type of search is best done with a graphical interface in which the user can bring up a list of all of the maps that provide coverage for an area within a box drawn on a computer screen.
Even if CORC eventually provides for a means of searching by coordinates, it still leaves the problem that very few of the records in CORC (or elsewhere) actually contain them. It simply requires too much expertise or time for catalogers to include them--especially in a system designed for part-time or inexperienced catalogers.
The solution for providing improved geographic access may come through the development of a geographic thesaurus with coordinates for each place name. Such a system, which is under development as part of the Alexandria Digital Library Project, could automatically retrieve the coordinates for all of the place names located through a search of a database such as CORC, and then retrieve additional records covering the same geographic area. The success of such a system would, of course, depend on having the place names entered in a form it could recognize--which brings us back to the problem of authority control.(12)
The related problem of finding maps showing an area at a particular time should be easier to deal with. If both the "Coverage.Time" field and "Date.Issued" fields could be searched at the same time and by ranges of dates, the problem would be solved. This would involve a relatively simple change in the CORC software. Of course, it would help if all of the records of digital images of historical maps had the date of publication in the same field. At present, few records use the recently instituted "Coverage.Time" field, and it may well be that most libraries will continue to place the date of publication of the original paper map in the "Date.Issued" field.
Mapping Complex Geospatial Data into CORC
A substantially different set of problems is presented by attempting to bring into CORC more complex forms of geospatial metadata. This material usually takes the form of Federal Geographic Data Committee (FGDC) metadata, which is required for geospatial data produced by agencies of the Federal government. FGDC metadata is now widely used by geographic data producers throughout the United States, and efforts are underway to harmonize it with the International Standards Organization (ISO) Metadata Standard to create a single widely accepted standard.(13)
FGDC metadata can be and has been used for cataloging simple raster images, such as those discussed in the previous section. The Digital Raster Graphic (DRG) format used by the U.S.G.S is an example of this type of material. A glance at the metadata for a DRG will show that the FDGC approach to creating metadata for raster images is very different from that outlined above--especially in giving primacy to information about the digital data rather than its original source. The rationale for the FDGC approach becomes much clearer when one examines other types of digital data. The FGDC standard is usually associated with complex geospatial data, often in vector format, such as that used in GIS programs. Well known examples are the TIGER files and the digital chart of the world (DCW). As one might expect, the type of information needed by users of these files is longer and more complex than that usually encountered by users of ordinary online library catalogs. Records for FGDC metadata are often several hundred lines long.
At first glance, it may not be obvious why anyone might want to put FGDC metadata into CORC, or to use the Dublin Core instead of FGDC. FGDC metadata is now well established, and it is not likely to be unseated by a challenger. The FGDC has established searchable online clearinghouses for data in this format. The FGDC records look very different from conventional cataloging records, and probably most users of online catalogs would not know what to make of them.
Notwithstanding the above, a project team at the Energy and Environmental Information Resources Center (EE-IR Center) in Lafayette Louisiana has been experimenting with mapping FGDC metadata into both MARC and the Dublin Core.(14) They have made a strong case for creating Dublin Core records as (gasp!) "meta-metadata" for FGDC metadata. Their basic argument is that FGDC metadata is too cumbersome, too difficult to maintain, and too hard to search for widespread use. That is why we need "meta-metadata"--metadata about the metadata. However strange it may sound, the idea is by no means absurd. To implement their approach, they hey have developed a crosswalk between FGDC metadata and both MARC21 and the Dublin Core, and mapped a number of FGDC records into CORC. Especially after CORC records are integrated into the OCLC database (which OCLC plans to do around the middle of 2000), their Dublin Core records should be much easier for both experienced and casual users to find than FGDC metadata. There is much to be said for user-friendly one-stop shopping.
Although the Dublin Core is simpler than MARC, it is actually easier to bring complex FGDC metadata into Dublin Core format than into MARC. Unlike MARC, the Dublin Core has no restrictions on field lengths. Since all fields are repeatable, just about any amount of text can be brought into Dublin Core records, if only as a succession of descriptive notes. Although this can be done, such records would be cumbersome for someone browsing through a group of CORC records.
The approach taken by the team at the Energy and Environmental Information Resources
Center has been to map only selected elements of FGDC metadata into MARC 21 and Dublin
Core records--leaving out the technical information not needed by casual users. Their
records contain links to the complete FGDC metadata. A typical example of their work
CORC: 175784 Created: FZU 1999-04-02
Status: System: OCL 1999-10-27
|Title||1992 TIGER roads features layer for counties in the conterminous United States|
|Publisher||U.S. Environmental Protection Agency|
|Publisher.Place||[Washington, D.C.] :|
|Contributor.CorporateName||United States. Environmental Protection Agency Office of Information Resources Management.|
|Contributor.CorporateName||United States. Bureau of the Census.|
|Description||Title from Web page (viewed Aug. 11, 1999)|
|Description.Summary||The Roads library layer is derived from a subset of the 1992 Census Topologically Integrated Geographic Encoding and Referencing (TIGER)/Line data. The TIGER/Line files were released by county or statistically equivalent entity based on the 1990 census tabulation and publication boundaries. The National Geographic Information Services (NGIS) team at the Environmental Protection Agency's (EPA) Systems Development Center (SDC) was tasked to process the 1992 TIGER/Line data. The NGIS team processed the data into ARC/INFO coverages. Only data for the conterminous U.S. were processed. This coverage provides a valuable data layer for applications that include base mapping, routing, and geodemographic analysis. A fully compliant FGDC metadata record is available at the electronic address (URL) given below.|
|Relation.Requires||Mode of access: World Wide Web|
|Relation.Note||IsPartOf: TIGER/Line 1992 (OCoLC)29606048|
This record should be compared with the record for the Romans map above. Some of the differences between the two records are explained by the differences in the types of data being described. In other cases, similar information is put into different fields. In some cases information is included in one record that is omitted in the other. These differences underline the lack of hard and fast rules for creating records for digital data in Dublin Core format. Nonetheless, both records are useful, and could be found using the same basic retrieval strategies.
The CORC project is in its infancy, and it is too early to tell what it may look like as it evolves and is integrated into the OCLC database. It is certainly having its full share of growing pains. From the point of view of a map librarian, CORC holds out most promise as a means of keeping track of digital images of maps on the Internet. Since CORC uses a Web browser and can provide links directly to digital resources, it stands out in this area. In spite of many solvable problems, the simplicity of Dublin Core cataloging makes it much more suitable than MARC for the creation of bibliographic records for rapidly multiplying Internet resources in a world in which professional map catalogers do not abound. CORC also has possibilities as a means of cataloging and making available information about paper maps, as well as FDGC metadata, but its future for these applications seems more uncertain. The Dublin Core may eventually become a widely used international standard for map cataloging, but the future of the Dublin Core is not necessarily dependent on CORC. The eventual success of both the Dublin Core and CORC as means of dealing with cartographic materials is dependent on many things. Chief among these is probably the development of a consensus among map catalogers as to how the Dublin Core should be applied to various types of cartographic materials, and how it should be used by catalogers with varying amounts of time and expertise.
1. The latest interpretation is: Dublin Core Metadata Element Set, Version 1.1:
Reference Description <http://Purl.oclc.org/dc/documents/rec-dces-19990702.htm>.
" Status of this document: This is a Dublin Core Metadata Initiative Recommendation.
Publication as a recommendation signifies that the specifications are stable and are
supported for adoption by the Dublin Core community."
2. Guides to best Dublin Core practice include: Consortium for the Computer Interchange
of Museum Information, Guide to Best Practice: Dublin Core (August, 1999)
<http://www.cimi.org/documents/meta_bestprac_final_ann.html>; Guidelines for Use
of Dublin Core in University of Chicago Library Projects
3. For an authoritative guide to cataloging practices for maps and other cartographic
materials (including geospatial data) see the newly published Maps and Other
Cartographic Materials, ed. Paige G. Andrew and Mary Lynette Larsgaard (New York:
Haworth Information Press, 1999). This book was also published as a special double issue
of Cataloging & Classification Quarterly (Vol 27, nos. 1/2 and 3/4)
4. The Getty Information Institute's Thesaurus of Geographic Names can be
found at <http://www.ahip.getty.edu/tgn_browser/>. The URL for the Geographic Names
Information System is <http://mapping.usgs.gov/www/gnis/>.
5. The Dublin Core has a field name Type which can be used to specify "the nature
or genre of the content of the resource." Unfortunately, "map" is not on
the present draft of Dublin Core resource types. If it were, this field would be an
alternative to placing the word "maps" in a subject field.
6. The Library of Congress Dublin Core-MARC crosswalk is available at
7. The procedures for dealing with diacritical marks are described in the "CORC
System Quick Reference" guide (last revision May 14, 1999), 47-49.
8. Many of these issues are summarized in: Weibel, Stuart and Eric Miller, "Image
Description on the Internet: A Summary of the CNI/OCLC Image Metadata Workshop, September
24-25, 1996." D-Lib Magazine, January 1997.<
9. At least in the United States, this interpretation of the best way to catalog
digital copies of maps seems to be gaining ground. It is recommended by the University of
Chicago Guidelines cited above. As will be seen, it is also reflected in the way the
Library of Congress has been cataloging its digital images of maps.
10. The edited version of my pathfinder can be seen at
11. For information about PURLs, see: <http://purl.oclc.org>.
12. Information about the Alexandria Digital Library Gazetteer Project is available at:
13. The FDGC home page is at <http://www.fdgc.gov>.
14. Chandler, Adam, Dan Foley, and Alaaeldin M. Hafez, "Mapping and Converting Essential Federal Geographic Data Committee (FGDC) Metadata Into MARC21 and Dublin Core: Towards an Alternative to the FGDC Clearinghouse" (Created 1999-06-14; most recent version 1999-12-14) <http://eeirc.nwrc.gov/pubs/crosswalk/fgdc-marc-dc.htm>.