-------- Original Message --------
Subject:        RE: MAPS-L: Discussion Paper on adding coordinates to
authority records
Date:   Wed, 18 Jan 2006 15:03:44 -0500
From:   Jimmie Lundgren <[log in to unmask]>
To:     Maps, Air Photo & Geospatial Systems Forum <[log in to unmask]>


Dear Fellow MAPS-L Subscribers,
Thank you so much to those of you who have sent comments so far. The following text is compiled from messages on the discussion paper, "Recording geographic coordinates in the MARC 21 Authorities Format." The messages were sent in recent weeks either directly to me or to the MARC or MAPS-L discussion lists through 1/18/05 and are being sent to both lists since some questions were asked on one list and replied to on the other, etc. Please let me know if I accidentally change or omit any of them.
I look forward to further comments. Thanks,
Jimmie

Comments on Discussion Paper No. 2006-DP01:

"Hello -
I just finished reading the discussion paper about adding 034 fields to authority records.  It's a wonderful idea, and all of us here in the CU Map Library agree it's time for such an effort.

In the MAPS-L post announcing this article, it was mentioned that you are first author.  If this is true, I would like to point out one little item that should be changed.  In section 4 (questions for further discussion), in the discussion about a subfield for date, the terms BCE and AD are used together.  If you use BCE rather than BC, I think you should also use CE instead of AD.

Thanks for your time.  Will be looking forward to seeing how this issue progresses." (sent directly by Naomi Heiser)

"Myself, I thought this proposal was pretty much a slam-dunk; I would not predict much trouble in getting this passed.  But the questions at the end are indeed significant.  Myself, I'd say we should define the field exactly same as in the bib record, even while recognizing that some fields will never be used.  NACO documents should probably say as much.

Perhaps of interest, although immediately only to Voyager users:  Our cataloger's toolkit for Voyager already allows us to suck coordinates (and other stuff, including variant names) off of web pages and build the 670 automatically (not to mention 451s); there would clearly be the possibility of building the authority 034 automatically at the same time.  What fun!" (sent to JL by Gary Strawn)
----------
"FIRST - defining location
It may be possible that the 034, regardless where it is used, may need extension.
GNIS and GNS (currently) reference places by points, i.e., a single latitude - longitude set, rather than by bounding box as proposed in the discussion paper.  I don't know where either stands on support for boxes, polygon, etc. ... and my naiveté may clearly show.

While a point can be interpolated from the box, I'm not entirely sure that the interpolated point would be the point as defined by GNIS/GNS.  Additionally, if it can be interpolated, I'm not entirely certain that definition of the bounds (as opposed to the simple definition of the center point) will be supported by the economics of the institutions that will populate the authority records.  The proposal seems to want for the latitude and longitude of a center point.

Ideally, overtime, there should be convergence of the authority established by GNIS/GNS (i.e., US BGN) and that established by LC-Authorities.  The discussion paper doesn't preclude this convergence; but wonting the definition of a center point, it doesn't make the possibilities clear to those who might not otherwise naturally see it.

References:
http://geonames.usgs.gov/GNIS.html
http://earth-info.nga.mil/gns/html/gis_contryfiles.html


SECOND - defining location over time

There also is, I believe, sufficient argument for further extension of 035, in this case to enable systems vis-à-vis the organic structures of geo-political entities.

Authorities are largely narrow over time; that is they're often fixed at the time they were created (or last updated).  This seems especially true of geo-political entities that, like people, grow or shrink over time.  The city of Gainesville, Florida, for example, has grown over time; while the county of Alachua, Florida has decreased in size as other counties have been carved from it.

Digital projects such as our "Ephemeral Cities" look at places as living, changing entities.  The proposal appears to want for temporal (or geo-temporal, if you will) data that describes either (if not both) (a) the date for which the coordinates were fixed and (b/c) the date range [begin and end - where either may be open ended] of the entity's coordinates in time.

Why is this important?  Church and civil records are digitized logging Alachua County as the county of birth or other event.  They may also log the event city as Ocala, Florida.  "Smart systems" - as they used to be called - know that Ocala is in Marion County.  Advanced smart systems using other details of the text/map/resource resolve the event to have occurred in Marion County.  But less advanced systems, journal-off the data for human resolution.  Time is money, so there is no resolution: institution X can't afford it.  Or, time is money, so the institution Y, resolving the question, wants to protect its investment by citing the bounds/coordinates of the place at the specific time.

An a footnote to history, working in the Caribbean now to build the TICFIA-funded Digital Library of the Caribbean, geo-politics also tempts the suggestion of associating language with the entity fixed in place and time.  Dominica changed hands several times, sometimes seemly by the hour.  I presume that geopolitical parent rather than language would be associated?  But by what means?  The problem is evident in the formation and devolution of the Soviet Union, the Transcaucasian Federation, and other states -- as we see them in construction of a digital Russian philately site.  And, there too, is tied a question of political reference, of government.  Adaptation of the 034, extended or not, to authorities is fine and wonderful.  But, I wonder if the flat-file of the LC-Authority may not be a plaster wonting a relational phoenix.

Thanks again for sharing." And
I see that I missed the discussion questions.

On the question of center points:
Whatever the solution, it should not demand additional machine/computing resources.  The current practice is not optimal.

For the expression of place in time using a 034/045 pair, the subfield 8 solution is viable.

Other questions:

Subfield 2 - yes.
I'm sure that our Canadian colleagues would appreciate the ability to the differentiate US BGN data from their own geographic naming authority.
In our Digital Library of the Caribbean, I'd like to be able to easily differentiate between US BGN, UK and French data for Caribbean areas.

I wonder if there might also be the addition of subfield U - LC might not find it desirable in authority records - we, however, may find instances in which we'd like to point to an external authority's GML records."
(sent directly by Erich Kesse)

 "Just a few comments on the questions regarding coding details (I don't know enough to comment on the geographic aspects)

Q2: If only point coordinates are available wouldn't it be easier to use just $d and $f rather than repeat the data? If the paired subfields are being used for ranges, won't repeating the same data cause the software confusion?

Q3: Bibliographic subfields for scale, which cannot be applicable to the entity itself, are really not needed in the authority format. Having many non-applicable subfields defined can lead to coding errors. When field 024 was extended to the authority format, indicator values that could never be applicable in the authority format were not defined there, so we have precedent for tailoring the field.

Q5: Repeating 034 with a date of applicability subfield seems like a good solution when the geographic extent changes.

Q6: A source subfield also seems like a good idea.
(Sent to MARC by Pat Riva)


"I would like to see discussion about the use of coordinates for searching. This DP says: "Searching by geographic coordinates is offered as a mode of access by only a few library catalog systems vendors at this time, although it may be offered more frequently in the future."
The one time that I was involved in an attempt to define a search based on coordinates, we ended up not doing it because we couldn't find a clear definition of how such a search would work. Would the coordinates of a search query have to match the coordinates in the record exactly?
Would a record be retrieved if query coordinates were within the coordinates in the record? Overlapping with the coordinates in the record? Would a record be retrieved if the coordinates in the record were within the coordinates of the query? Does map scale matter?

So if someone has a query algorithm to offer, I, for one, would be interested in seeing it." (sent to MARC by Karen Coyle)
----------

 "Don't have an algorithm, but here's something by way of an answer,
anyway:  Endeavor offers a "geospatial search capability" as an additional-cost product for its Voyager system.  This feature allows OPAC users to retrieve bibliographic records based on information in the 034 field.  There's a two-page PDF "brochure" about the product available from the protected side of the Endeavor web site; this doesn't appear to me to contain anything fiercely proprietary and I suspect that would be supplied on application to the company.  Be that as it may, I think I'm not exceeding bounds to say that using this feature one can search for a single point (either for an exact point, or points within a specified radius from a given point), for points within a rectangle (by specifying two opposite corners), and for points within an irregular closed polygon (by specifying the vertices).  There are yet other search types that I'm not sure I understand even as much as the ones I've described.  The illustrations in the PDF are too small for me to read most of !
 the button captions anyway.

We don't have this add-on product here so I can't go into much detail based on my own experience; unfortunately, I also don't know of a publicly-available OPAC that includes it.  (I believe there is at least one U.S. government agency that has the product, but their OPAC isn't available to the public.)  I have seen it demonstrated, though, and I thought it was pretty darn cool.

The wall to get over of course is that a search capability doesn't do much good if there isn't a substantial corpus of records with information against which to work.  I mention as a coda that a feature of our cataloger's toolkit for Voyager converts information on GNIS and GeoNet web pages into authority 670 fields (and sometimes 451 fields, too); there's every reason to believe that the same feature could be expanded to build an
034 field at the same time, where such a field to be defined.  This would allow at least some record creators to build these fields (chiefly in new
records) without additional effort.  Whether it would be possible to take an existing 670 field and derive the corresponding 034 from it is a matter for experimentation, perhaps by one of the bibliographic utilities.  In case anyone is interested, here's a brief description of this business as it exists today:
         http://www.library.northwestern.edu/ctkv/#usgs
         http://www.library.northwestern.edu/ctkv/#geonames "


(Sent to MARC by Gary L. Strawn)
----------

"I compiled the following few thoughts last week for April Carlucci at the British Library, who was co-ordinating a UK response to your 2006-DP01 proposal, so I thought there was no harm in copying them to you too. I'm keen that your proposal gets the support it deserves (even if from the UK it is a more theoretical than practical support!) whilst also taking account of some initiatives that could assist or modify it.
...
We agree with the points you made to Alan Danskin, particularly your feeling that the UK response should be supportive but not inclusive. Yes, we're right behind them on this, but may not be able to help them along very much! In spite of the growing online availability of coordinate information online (GeoNet names server, Getty TGN, GNIS, Google maps, etc.) making the look up easier, it still will require extra work that we don't have the resources to do. I think that the focus on adding coordinates to authority records, rather than bibliographic records is very sensible, not only saving time but also allowing for easier spatial searching, and this should be encouraged.

The following three points could be made in addition:

1. As geographic names and spatial searching are of much broader interest than just map libraries, we should encourage the broader acceptance of this proposal by central cataloguing departments, not just map cataloguers. The origin and emphasis of this proposal on map metadata and GIS retrieval should be broadened to make it clear that all geographic searching for map and non-map items would be facilitated - this could hopefully increase the numbers of those able to do it!

2. The focus on MARC fields and library systems should be broadened through a dialogue with other geospatial tools and services. For example, the EDINA GeoXwalk project (http://hds.essex.ac.uk/geo-X-walk/) allows ways of semi-automatic georeferencing of materials with a geographic component through their geoparser, and could surely assist in this process of geo-referencing authority records for places? In the UK, the GBHGIS (http://www.port.ac.uk/research/gbhgis/) has developed an extremely detailed gazetteer of of historical jurisdictions in the UK, with the spatial footprints of these entities, not just bounding box coordinates. There are other institutional gazetteer systems in use with coordinates, such as the AGI GIGateway (http://www.gigateway.org.uk/ , or EDINA's Go-Geo, which record more detailed spatial metadata based on the ISO 19115 standard for places. Also, it would be surprising if commercial search providers such as Google are not developing methods of transla!
 ting a textual uncontrolled placemame entered into a search box into coordinates, as well as into standardised placenames for retrieval purposes. These projects do not necessarily diminish the need for this proposal, as their tools or data may not be accessible, but an awareness of them might facilitate and qualify the proposal. There may be an element of inventing wheels to it ?

3. The proposal would be stronger if the methods of recording co-ordinates could be more flexible. Yes, there is little doubt that decimal coordinates are essential for proper computer retrieval and should be preferred if only one system is permissible, but as DDD/MM/SS are easier for people to use, and the traditional form, then it would be useful to have the ability for some to enter the latter and use standard tools to convert into decimal coordinates. A subfield for indicating the type of coordinates (decimal or DDD/MM/SS) might allow this. Of course, lat-long coordinates are global, but it may be worth stating that the ability to define a particular local spatial reference system for coordinates, such as the British National Grid, would be a useful addition. Provided the coordinate system were properly defined in the 034 field, the coordinates could be converted into a global lat-long system, but I can see that from a MARC perspective there are probably stronger argumen!
 ts for converting into and sticking with the global lat-long system in the authority records.

Also bounding box coordinates are still rather imprecise for most entities that are not rectangular. If the exact boundaries of cities, counties, or parishes are available, these would be much better then bounding box coordinates, but the proposal does not allow for these. I also believe that effort would be wasted by recording point coordinates for anything other than very specific locations. The proposal allows for multiple 034 fields to build up a set of points that cover an area, but this would be vastly inferior to a polygon in spatial retrieval, and seems of dubious value. In this context, we should encourage the need to qualify the authority records by time (perhaps using the 045 field), as this is crucial for accommodating changes to jurisdictions over time." (sent directly by Christopher Fleet)
----------

 "Relative to questions below about the nature of a search by coordinates, I have to refer to the paper reference maps by USGS for their geologic investigations.  Although I have not had to reference these in some years, I assume they still publish these.


As I remember these maps were by State and showed the outline of the area of each geologic map.  In some cases the polygons of coverage were very odd-shaped, as they followed a valley of bit of stratigraphy.  There were reference numbers so that you could find the source of the original map and its scale.  If you wanted to know what geological literature existed for any specific place, you would start with these reference maps.

It seems to me, this is a standard that should be used if you want to search by coordinates.  If you define your coordinates of coverage based on the smallest rectangle that encloses the polygon, then in many cases you will imply availability of map coverage when it does not exist." (Sent to MAPS-L by Jim Carter)
-----------

" What Gary describes below is exactly how a system should work.  If a record only has 1 coordinate pair, a search by a bounding box (circle, polygon, etc...) should find all coordinates within the area.  Another nice feature would be to say "find all records within a certain distance (x feet, meters, etc) of a point.  But with Lat/Long there would have to be some additional processing to get the correct coordinates to calculate distance.  The search on a single coordinate should also be able to capture records, which fall within the bounding coordinates for the record.

The examples of Voyager presented by Gary http://www.library.northwestern.edu/ctkv/#usgs again demonstrate that the coordinates presented by USGS for the 670 field are not in decimal degrees and would require an algorithm to convert them, the same is true for the Geonames example.

My basic non cataloging question is why can't the 034 field use a negative sign for west longitudes and southern latitudes, instead of having to use the N,S,E,and W designations?  Additionally, why do we have to use a leading zero?

I am also not seeing the projection field discussed and how it can be extracted at the same time as the 034 field.  It is important for a user to know whether the lat/long coords are in WGS84, GRS1980, etc...

If I remember correctly, the 034 was not a field we at UF Libraries paid to have indexed, and therefore it is not searchable through our catalog.  Does ExLibris have this capability?  It is not something I have researched.

From my perspective as a user of the catalog, who would like to create a graphical geographic search interface (GIS), the tools to extract the data in real time and export them do not currently exist for these fields using ExLibris.

Karen's question about scale would apply to how the data in the record is used, and would have implications on the positional accuracy of the coordinates chosen to represent the record." (sent directly by Joe Aufmuth)


"Re Karen's query - here are a couple of answers.
1. There is a description - although it doesn't (as I remember) include computer code - of the 1st library catalog to search by coordinates, which was the Royal/national library of the Netherlands.
van de Waal, Hans. 1974. "The application of geographical coordinates for the retrieval of maps in a computerized map-catalogue."
International Yearbook of Cartography 14: 166-173.

2. The Alexandria Digital Library (ADL) does have search by coordinates:
http://webclient.alexandria.ucsb.edu

All of ADL's source code is open-source and downloadable from the website. But .. it would take a programmer to latch onto and implement the code.

That being said, ADL's ability to support coordinate search over MARC catalogs will - we hope -  increase markedly in 2006, when the metadata mapping infrastructure (for MARC and other metadata standards) that Greg Janee (lead engineer for ADL for a good many years and now working on the architecture for the National Geospatial Digital Archive, one of LoC's NDIIPP contracts) worked on in 2005  is combined with new ADL harvest/crawl/ingest software under development.
The plan is that it would be possible to automatically build ADL collections from any library's catalog portion of its ILS.
Another "but .." - configuring and running such mappings is likely to remain fairly technical and thus to require computer technical persons to work on it." (sent directly by Mary Larsgaard)

"a. searching by coordinates in ADL -
http://webclient.alexandria.ucsb.edu
I do realize the interface is difficult to use, and honestly, we are working on improving it.
The most effective limitation beyond coordinates is limiting by what collection you'd like to search. I discourage searches using "Words to search by", because the bib records are different in many ways from our standard AACR/MARC21 records - and one important one is that the records don't have the kind of subject headings we're accustomed to; and also the concept of added entry isn't the same situation.

b. lists of coordinates:
There is a coordinates email reflector maintained by the Geography and Map Division of LofC, and we're certainly looking for digital versions of all the hardcopy lists many of us have.
There is a counties list, but the coordinates are in decimal degrees, so a cataloger would either have to use decimal degrees
(MARC21 permits this) or convert each coordinate to D/M/Seconds. Colleen Cahill of LCG&M does if my memory serves now have this list of county coordinates available over the Web (?maybe only by ftp??)" (sent to MAPS-L by Mary Larsgaard)

"I don't have an algorithm to offer, but some years ago I did see a demo at LC G&M showing what Voyager was capable of doing using coordinate-based searching. It was a bit clumsy and needed some refinement, but I do not know where the company has gone with this capability, it is my understanding that they developed this as a "package" or "unit" of Voyager that the institution had to choose to pay extra for at one time. That said, the best way to make this useable would be to plug in a set of coordinates and have all items that overlapped within the given geographic area be retrieved. Map scale would not matter, what you are attempting to do is retrieve all items that touched upon or fell within a polygon (which could be a bounding box too) of coordinates and then allow the patron to sort through that set by some other parameter, one of which might be scale. I believe the coordinates searching capability on the Alexandria Digital Library works this way, and if not I'm sure Ma!
 ry L. can straighten me out in a hurry!

I see this as a very powerful means of retrieval, and more exact than textual combinations as well. In my workshops that I teach I always tell attendees that putting coordinates in a given record is an option withon our current standards, that the "LC practice" is to input coordinates when they appear on the map, but that in reality we should all be inputting coordinates at the very least when they do appear on the map because the time is coming when coordinate-based searching is going to really take off and thus we will be contributing to the good of such a mechanism. Its still up to each cataloger, but I have always input coordinates when they appear on the map, and will also input U.S. state coordinates even when they are not on the map simply because of a handy chart I still have from the map cataloging workshop I took from Arlyn Booth back in 1987!" (Sent to MAPS-L by Paige Harper)

"Can that chart be copied and distributed?
I would like to have a copy if you can bring it to San Antonio.
Thanks." (sent to MAPS-L by Carolyn Kadri)

"Given that coordinates may be represented in a variety of ways (decimal or coded, bounding box or central point), it is likely that authority record users will want the option to represent any of those ways. As a result, it is important to provide a means of clearly identifying what type of coordinates are given in the authority record." (RLG comments sent to MARC by Joe Altimus)

-----Original Message-----
From: Maps, Air Photo & Geospatial Systems Forum [mailto:[log in to unmask]] On Behalf Of Angie Cope, AGSL
Sent: Friday, January 13, 2006 3:35 PM
To: [log in to unmask]
Subject: MAPS-L: Discussion Paper on adding coordinates to authority records

-------- Original Message --------
Subject:        Discussion Paper on adding coordinates to authority records
Date:   Fri, 13 Jan 2006 15:19:26 -0500
From:   Jimmie Lundgren <[log in to unmask]>
To:     Maps, Air Photo & Geospatial Systems Forum <[log in to unmask]>


Dear MAPS-L subscribers,
        I am writing to call your attention to Discussion paper
2006-DP01, Recording geographic coordinates in the MARC 21 Authority
Format.
http://www.loc.gov/marc/marbi/2006/2006-dp01.html
        The basic ideas in this discussion paper have been talked about
among map librarians for a couple of years now, and everyone has been
very enthusiastic in supporting it and helping to develop the paper
(especially the Map Cataloging Committee and Rebecca Guenther). I feel
it has enormous potential for connecting users to information they need
through the geographic coordinates of places.
        The last section of the paper lists questions for further
discussion. While the primary idea of including the 034 field for
geographic coordinates in authority records for places is clear and
obviously worthwhile, some of the details are not yet worked out. I am
anxious that they be thoroughly discussed and successfully resolved so
that we can progress to writing the proposal and getting it adopted.
Please try to find time to read and send comments to this list.
        Your input is very important. Thanks and best regards, Jimmie

Jimmie Lundgren
University of Florida
Gainesville, FL 32611
352-392-0352
[log in to unmask]