Greetings. Since there were no distinctions among our group, I don’t need to introduce us. We sat and talked for a while, and then wrote down lots and lots and lots of items, and then laid them all out, categorized them into a number of bins, so to speak, and recorded basically how many items fell into each bin.
The first thing that I would like to do is give you an overview of those. Starting with the one that was the most strongly repeated theme: this was about linkages. And that’s sort of a general term for linkages within gazetteers and between gazetteers and between collections and gazetteers. That appeared 9 times in our discussions. The next three are all tied at 8 occurrences:
So I wanted to go through all of these. Among linkages: we talked about centralization versus a distributed model of gazetteers. Do we need one mother of all gazetteers, or is it going to be a system of coordinated and distributed gazetteers? There were obviously opinions on both sides in our group. But I think it was probably accepted by all that, at least within the foreseeable future, it is going to be a system of distributed gazetteers, and there needs to be a lot of work on coordinating them. Other issues in linkages were providing associations between names and lineages of a named object, which is sort of an internal issue. We need to define the linkages between collections and gazetteers, and protocols for establishing those. We need to enable batch processing of huge quantities of records, where the output is a linkage to an existing gazetteer or gazetteer entry. One of the things that was dear to my heart was the notion of decentralized development of gazetteers; in particular, communities are going to need to impose a data management discipline on their treatment of place names. So, almost by definition, there need to be gazetteers for particular communities. It would be nice, in the next two-three-five years, if we were to see the methodologies, the tools, protocols, etc., all laid out in an accessible way, such that the discipline of data management for place names could be applied within a community. So that the framework could in essence be cloned for a particular group. This applies, of course, within my community in natural history, where we have to deal with the names we have in our data records, but they might not ever make it into any gazetteers of official names.
In summarizing the issues in linkages, I think a lot of it boils down to just defining data models for gazetteers, taking what we have seen with the ADL protocols and the standards - the other UML-based things; defining those in ways that are accessible, such that the different features that we are going to be talking about in temporal variation, even spatial variation in named places, are actually accommodated or supported within gazetteers. So it boils down to a lot of data modeling for a gazetteer, or if you extend that to an O-O framework, (an object-oriented framework), then we need also to design interfaces for gazetteers, and protocols for querying them, and fail-overs and all the other things that we have been hearing about for the past two days. So there is lots of work to do on modeling and specification of gazetteers. That comes up again in standards.
I will switch over to temporal issues. Time has three aspects in the context of a gazetteer. There is the dataset itself, the whole gazetteer as a database or a dataset. It has versions where you would need to say, this is the gazetteer as of this point in time. There are entries within that, and they also have temporal components to them. We need to know how a record has changed and why. There are at least two types of changes, or maybe three. There can be name changes of the same thing, so that an object has multiple names. An object can have multiple extents over time. And then the third way that time affects gazetteers is in the metadata of the entry itself. So the entry can be of something that occurs at a particular time, or the source of that data has a particular date, and again, changes that are made to that. We have requirements for searching across time when we approach a gazetteer, and need to be able to express to it that we want to limit or extend our search over a particular range or context. That needs to be something that is reflected in the interface and in the data model and the functions. It also came up several times that the temporal issues need visualization, so that a very handy thing would be to be able to see a nice little picture - a sort of thumbnail - of how some place changes over time, how its extent has changed over time, for example. It would be very good for many users to not just see textual records and be overwhelmed by this flood of text data, but just to encapsulate the changes in pictures.
We need to consider the relationship between entries over time. So, you may think place X is in the larger place Y at one time, but larger place Y changes, so place X at some other time is now in place Z at another time.
Actions associated with dealing with temporal issues: we need to understand more about what time means within the context of a gazetteer. So, in essence, that is a specification of the requirements for incorporating temporal information.
We need to look at existing gazetteers and how they handle change - or don’t - and see what improvements need to be made. We need to define a data model, and how to include temporal information in standards. We need to investigate the way temporal information is supported in visualization and query protocols.
The next topic is legacy data. So, in a more action item way of dealing with that, it would be good for us to survey what exists in organizations, and be able to characterize the scope of data within any particular community that, in essence, represents that community’s legacy data and its geographic nomenclature problem. We need to inventory that. We need to estimate the costs of time for dealing with it. We need to prioritize those, and then mount projects to digitize that information. Some of that could then be re-formatted and either input into a gazetteer or held in that community’s separate gazetteer. Where it is appropriate, they need to be linked to authoritative sources. Again, they must link to the temporal dimension. It extends beyond present day - it includes archeology and paleontology.
Human-computer interface issues were summarized in one long sentence, which I will attempt to deal with here: "develop, through partnership, tools and methodology to access gazetteer data via intuitive but sophisticated, layered interfaces". These interfaces will embody technologically advanced natural query (speech for example) and functionalities or capabilities, where theme, temporal and spatial components are adaptable to user requirements and needs. One of the things that came up repeatedly in what we talked about was the importance of context. Where a user is coming with a particular context to a gazetteer, and the results need to be in essence adapted to their particular needs.
Among the representation issues that we discussed, we have the presentation of names for non-Roman alphabet and script languages, including methods of Romanization and interpretation, and these must be exchangeable. There are protocols for converting other alphabets and other languages into Romanized forms. Those standards should be applied within gazetteers to geographic nomenclature. Geographic locational representations of place names should assist in verifying the place, and could become part of a possible collaboratory project, which I will talk about in a second.
We talked about four potential projects. Within the natural history community we have a tremendous problem with legacy data, lots of locality information represented only in textual form. We saw from Ray Larson’s presentation the work that they have been doing with GIPSY, which is a parsing and georeferencing kind of a tool. One of the projects would obviously be to take some subset of natural history collections data and submit it to GIPSY and see what happens, and report that back to the rest of our community, and then as appropriate through digital library kind of work.
Getting back to this issue of visualizing place after somebody does a search on a place name: Allen Carroll from National Geographic said they would love to be able to provide their existing maps as part of a visualization interface or interface that includes visualization. It could possibly be done as a collaboration between National Geographic, ESRI, and ADL.
We talked about user interface and usability testing. From the federal government there was the federal web consortium (probably got the wrong name on that), but some of the prominent websites within that organization contracted with a human factors group, Human Factors International, and had studies done on the ways users approached problems, and basically made recommendations for changing those interfaces. The same sort of a protocol could be done here, and it could be in essence a follow-on workshop, where either particular gazetteers were studied by human factors groups and then presented, or where many people representing many gazetteers could come and benefit from that work in a follow-on workshop.
Finally, it was noted that international participation in the evolution of gazetteer development should be encouraged to the greatest extent possible. Again, the acronyms and organization names, but the UN group that deals with gazetteer and place name information should be a primary point of contact for that.
That’s it.