Digital Gazetteer Information Exchange Workshop

Breakout Group #1

 

 

Notes were taken on flip-chart during discussion;

After discussion, noted items were classified under eight topics;

The number of items in each topic were:

 

Linkage issues            9

Human Computer Interface issues            8

Time (Temporal variant data and versioning issues)            8

Standards            8

Legacy Data            4

Representation of information and relationships            3

Customization (of views to user-context)            2

Funding             1

 

(Counts should be understood to indicate how we spent our time, not a measure of consensus around a particular topic or set of issues.)

 

The issues under each topic were then summarized by teams of 1-3 group members.

 

Summaries

 

Linkage Issues:

 

Summary. Many of the "linkage" issues raised in our discussion, such as representations of place names, lineage of named feature data, relationships among features, and linkages between collections and place names could be addressed by developing and promulgating a shared object-oriented (e.g., UML) model of gazetteer systems.  The model would include (and resolve issues concerning) data structures, interfaces between distributed gazetteer systems, and interfaces between clients and gazetteer systems.

 

Linkage issues:

 

1.      Centralized vs. distributed (federated?) gazetteer systems

2.      Providing associated names and the lineage of a named feature

3.      How to link collections to gazetteers? e.g., copy/replicate place-name data out from source (concurrency problems) vs recording a place-name identifier in a collection to reference the place-name entry (guaranteed availability and performance of source to deliver data upon demand)

4.      Gazetteers and linked systems need to ensure that updates to gazetteer data (e.g., name changes, footprint changes/additions) are incorporated into existing catalog records.

5.      2-5 year goal:  enable "peripheral" place-name projects to use infrastructure for managing place-name data; could be accomplished by "product-izing" gazetteer software and making it available to such projects, or enabling such projects to establish and manage a "mini-repository" of place-name data within an existing larger gazetteer system (remote to the project).

6.      Provide associated names, including homonyms (e.g., Name as administrative unit, name as natural feature. May have different footprints: island of Hawaii vs. State of Hawaii; or may have same footprint: Reagan National Airport as administrative unit vs. Reagan National Airport as Airport.)  Provide thesaurus-like capability: type in variant name à display "official" name; under "official" name, provide historical names

7.      Enable viewing of temporal changes for a named place. (How has the footprint changed? How has the name changed?)

8.      Support batch processing of huge quantities of collection records, where output is linkage of collection records to gazetteer entries.

9.      Link named places to census units.

 

 

HCI

 

Develop (through partnerships) tools and methodologies to access gazetteer data via intuitive, but sophisticated and layered interfaces.  These interfaces will embody technologically advanced (e.g., natural language query, speech recognition) capabilities where theme, temporal, and spatial components are adaptable to user requirements (needs).

 

The idea behind layered interfaces derives from the fact that place-name and footprint data can get very deep, particularly if the data include historical versions, "unofficial names", etc.  The initial response (layer) to a place-name query might be relatively simple, but would include indications when additional data of a particular type exist for an entry term.  A layered approach would give the user capability to drill down into the associated data (or even go laterally to related places) as far as they care to.  Customization might let repeat users access deeper layers or particular attributes directly, depending on the potential volume of data returned by a particular query.

 

 

Standards Issues:

 

I.        Protocols are needed for :

A.   interchange for content and scope of controlled vocabulary keywords

B.   communication among processes

C.   communication between users and contributors

 

II.     How do we coordinate different efforts for standards among:

A.   International community

B.   Within other communities

C.   And ensure coordination/integration with other relevant standards (e.g., Dublin Core, FGDC)

 

III.   Who will be the authority for transliterations of place names?

 

 

Time (temporal issues):

 

I.        Time has three aspects in the context of a gazetteer:

A.   the dataset itself

B.   Actual data about the entries: name change, geometry change

C.   metadata about an entry (date of source, date a change was made)

 

II.     Require support for searching across time
Involves consideration of user interface, data model, & functions

III.   Require support for visualization of change

IV.  Also need to consider relationship between entries over time; e.g.,
place x is in area y at t1, but
place x is in place z at t2

V.     Actions

A.   We need to understand more about what time means in context of gazetteer

B.   Look at how existing gazetteers handle change (or don't); what rules are applied in each?

C.   Define data model or how to accommodate temporal changes

D.   Investigate support for searching and visualization of time-variant data.

 

 

Legacy Data

 

Definition: "Legacy data" exists in an organized form, but needs (digitizing) migration to modern systems and integration with other information retrieval systems, including authority control systems, thesauri, and gazetteers.

 

Recommended approach to solving the legacy data problem:

1)      Do inventory of legacy data

2)      Estimate cost and time

3)      Prioritize

4)      Digitize

5)      Reformat

6)      Link to authority sources

7)      (Must link to time dimension for disciplines such as archaeology.)

 

 

Representation of information and relationships

 

Aspects of representation identified:

·        presentation of names for non-Roman alphabet and script languages; includes methods of romanization or transliteration; must be exchangeable

·        graphic locational representation of the place names to assist in verifying the place (part of possible collaborative project)

 

 

Customization (see HCI)

 

Possible collaborations in research and infrastructure development

 

1)      Between the Natural History collections community and Berkeley digital library GIPSY project to geo-reference text-based descriptions of collecting localities.

 

2)      Enable response place-name searches to include visual display of feature location and context. Partners could include: National Geographic (World Atlas project), ESRI, and ADL.

 

3)      Usability testing / Interface Design of web interfaces to gazetteers.  Federal web committee engaged Human Factors International (http://www.humanfactors.com/) to user-test and review important federal web sites (e.g., Thomas).  An HCI specialist could be engaged to conduct user-testing of gazetteer web sites, report back, and then conduct a follow-on workshop with gazetteer info providers.

 

4)      International participation in the evolution and development of digital gazetteers.  Roger Payne suggested that he could present the results of this workshop at the international meeting in New York, January 2000.