I hope I can capture the richness of our discussion. Patrick was our leader, and he was quite a taskmaster, and kept us going. We had two great scribes that captured a lot of this information, and Gail Hodge was the one who quickly captured it on PowerPoint.
We started with 6 categories, and reordered them slightly. So the topic that we actually started with was data gathering and sharing. We talked about a number of issues. One that came up immediately was - there are a lot of fuzzy things out there for capturing, there’s uncertainty in the concept, there’s uncertainty in the location. But we should not see that as necessarily problematic. So that’s not an enemy. We look at that more as an opportunity, and something we will come back to later.
The idea of interoperability as a long-term goal should be something that we consider as we start the whole date gathering and sharing process. Again, that is a goal that we want to strive towards.
Another key piece that we talked about was having some process and protocol for building in this interoperability, for building distributed federated sets of gazetteers. Again, this would be a set of guidelines, which relates to the second point, that we would see the possibility for multiple authorities. So we are saying that there could be any number of collectors and builders and creators of gazetteers. Then we have to have some protocol for which they establish their authority, and some process and protocol or guidelines about what they include and how they build their gazetteers. Then some process again for validating and verifying that. Multiple authorities and multiple creators, and then that is allowable by having a set of guidelines.
We talked about some minimum set of metadata also, that describes what was the process behind the collection of sets of elements that go in a gazetteer. We talked about the role of a number of different standards in building gazetteers; one particular standard like UNICODE and various text encodings. So, if we have gazetteers that are built in different languages, then we have to have a way of mapping across them. So, various standards would come into play in building these.
On the sharing side, we talked about the need, at least immediately, for having some mirror databases at various locations; in other words, some redundancy built into the system. So there could be redundant databases, redundant gazetteers at various locations.
Something else that we talked about is - if you did have to issue versions of CD distributions of the gazetteer, how would you manage that? How would you keep it up to date? How would you assure that you’ve got other versions out there that are not problematic because they are out of date? And we talked about some subscription services that might be supported; if you have new entries in your gazetteer, you have a subscription service similar to a newsletter that goes out to people who have subscribed to your gazetteer over time.
Multi-media access: that was a multi-media tutorial or expression, rather than a heavily text-based presentation. This is similar to group number 1; that is, having a visualization of the result of your gazetteer query as well as the text.
The whole notion of how you have rules and synchronization. Again, this whole idea of interoperability, of federated gazetteers able to work and talk amongst each other.
Then we moved on to uses of gazetteers. We talked from the general to the specific. To summarize this in the general terms: one use of gazetteers being an information resource unto itself. That you would have direct queries that go to the gazetteer, and the gazetteer is able to respond as an information source. The other role of the gazetteer is as a tool or resource used in conjunction with other applications. So again you are not using it directly, but it is an indexing or a service mechanism as a key piece of some other applications.
We talked a lot about it as a navigation tool, as a navigation tool to various other pieces of information, as a navigation tool in an information space, and possibly as a navigation tool and physical space as well.
We also talked about the gazetteer as an information management tool. This might be a tool that is used by librarians, information managers, to do something like Sharon mentioned, error checking. When you have multiple gazetteers, you need to have a process of validation; you may have multiple entries for the same place, for the same name. Again, you can use it to check and say, are these two consistent?
Under the two topics: as an information resource unto itself, and then as a tool as part of other applications, we got down to some specific questions that a gazetteer should be able to answer. These relate back to what Mike started with the first day: where is it? what is there? or what is here?, how has something changed? or when did it change? And, a little more of a stretch, getting at why (that would be more of an extension - not a direct query to the gazetteer). Once you have the gazetteer in place as a navigational aid, it might help you to get to those sorts of questions in the longer term. Certainly this brings up the question of what is it that we want to be able to use a gazetteer for.
Then we talked a lot about tools and tool development. What are some tools we need to actually build to use these gazetteers? This came back to this fuzzy environment idea, and needing a set of tools for approximation. How do we refer to fuzzy conceptual things, fuzzy locations, fuzziness also in time? In many cases, we are looking for response and we don’t even get a "no" response. This is the idea of inexact matching or proximation or similarity of things. So, all sorts of tools need to evolve for working with fuzzy things, so that we have tools that can deal with approximations.
We need tools to work on this process of protocol development and maintenance, including ingest tools. We talked a little bit about standards. There was some reluctance to adopt specific standards and say, “The gazetteer shall include this”. We talked about building tools, ingest tools, that would say, “Here’s a tool that will help you create a gazetteer”, and by default that will give you an easy way to build in some key elements, rather than having a strict standard that says you must include these in these particular formats. Those ingest tools would then be based on some sort of protocol. But that needs to be developed.
Functions to be performed: we talked about the gazetteer as primarily a translator, a translator tool. In this case, we talked about it being primarily the translator between a name and a location, but you also have multiple ways to refer to a location. So we need translators, not just between the gazetteer main function being between name and location, but how do we have sets of tools that make the translations between their multiple references to location? Similarly, we need translators between multiple referenced names. So we have the name to place translator, or name to location. Also location to location translator. Name to name or sets of names. We also talked about time as being a very essential component of the gazetteer, because it makes the connection between a name and a place at a specific time. So this name referred to this place at this specific time. In many cases, we absolutely have to have that to make sense. Again, this is the gazetteer as an index towards finding things, information about space and time.
Another thing that we talked about: how do you make the gazetteer responsive to naive questions? Patrick, who works as a librarian, gave the example of students coming in and asking for something, and he says, “what class are you taking?” So, being able to have a smarter gazetteer that knows how to respond to certain questions in an intelligent way; the idea of intelligent agents that can make the gazetteer responsive to naive questions. Then there would be a sense of negotiation, “but what do you really want?” sort of idea.
In terms of the research agenda: some of the things that we talked about were usage studies. Randy talked about people coming in, looking at the logs of various current gazetteers that are in use, looking at characteristics of use. Can we glean anything from that in terms of understanding who is using it, how are they using it, and that sort of thing? Some way of getting a sense of the sociology of the users of Internet gazetteers.
The tools that we mentioned as being a key part of the research agenda: there’s a lot of tool development that needs to go on, sort of virtual library issues, and interoperability of these translators, and so forth. Some on the idea of how to make gazetteers smarter, how to make adaptive interfaces, and the idea of intelligent agents who are sitting behind and making the gazetteer more responsive to different users.
We talked a little bit about this cascading architecture that Doug raised this morning. About a particular sort of a query, “well, I don’t know that, but somebody else does”, and you can cascade down and find it and be able to generate a response.
Then we talked about the possible collaborations. Randy expressed an interest in having people come in from academia and review the usage of their site, and also looking at contributors from various other fields, such as entomology and various other venues where place names are collected; looking at how they can contribute to existing gazetteers. This includes museums that are working with their collections. Also as to users, what are their needs? We talked a bit about working with some specific domains (I guess I’ll come back to that).
The other key collaborator was Open GIS. Again, building open architecture interoperability between gazetteers is something critical. We could learn some lessons from what OGC has been doing.
Certainly there are all sorts of commercial applications with gazetteers. Taking a very broad look at gazetteers, it could be something like the Yellow Pages, building all the locations of names of gas stations, where they are and so forth. How McDonalds or various others may want to use such a tool.
Another particular collaborator we talked about was the genealogy community.
How they are very interested in looking at tracing people, and where places
have changed over time, and being able to look at a specific domain that
uses gazetteers in a specific way to get a better understanding of what
that particular domain needs in terms of how do we develop specific services
within a gazetteer. And, in a certain way, the libraries and bibliographic
data base community as being an important community to talk to and understand
how they want to use gazetteers.