Return to tldapps Forum - Message Thread - FAQ

Username: ddnebert
Date/Time: Mon, October 30, 2000 at 4:33 PM GMT
Browser: Netscape Communicator V4.7 using Windows NT
Score: 5
Subject: Doubts about .geo TLD


This message represents personal discussions I have had recently with members of the U.S. Federal Geographic Data Committee, largely a group of volunteers involved in the establishment of the National Spatial Data Infrastructure over the past 6 years. The observations are mine and do not necessarily represent FGDC member organizations.

My reading of the .geo proposal and presentations on its architecture at the recent OGC (Open GIS Consortium) meeting lead me to believe that the proposal for a .geo TLD should not be approved for a number of reasons:

1) The service suggested can just as easily be done without a .geo
domain. The creation of an alternate TLD is not required to create a secondary information space akin to the DNS for geographic organization.

2) Although SRI has experience in the Web3-D and VRML development, their efforts are neither coordinated with nor represent the established providers and users of implemented geographic information systems (GIS) and image processing software and the terabytes of data behind them. There are initiatives at national and global levels known as Spatial Data Infrastructures in which the coordination and discovery of earth-related phenomena are being specified today. The dot-geo proposal confuses this coordination landscape by proposing an untested solution. Simply clarifying the relationship of the players and the proposing organization and the application of .geo domain will not make this proposal work better.

3) The use of a new .geo domain creates the perception that all organizations must somehow support geographic references to information objects on their own servers and index pointers in another domain. At a minimum, this creates dichotomies in implementation and in authority, reaffirming the concern in point number one: this can be done just fine without a .geo domain.

4) In creating the .geo domain, a split between things that are
geographically related and those that are not is invented -- this is
a disservice to the progressive integration of spatial and non-
geospatial information. For the past ten years we as software users along with our software providers have recognized and are working toward the integration of data objects and the properties that describe them -- moving away from separate data and catalogues. If in appearance only, the .geo proposal reinforces this separation once again and does not clarify what types of objects would be categorized in this spatial domain. Doing so is an immense political effort. Who will do this?

5) There is no clear way to address information that spans the multiple .geo-proposed latitude by longitude cells of the Earth. Increasingly, there are collections of data that are managed now as seamless continuous data sets over nations, continents, and the globe. They may or may not be decomposed into identified features on the Earth's surface (e.g. a pixel in a global image, the Mississippi River). The artificial hierarchical tesselation of the Earth's surface as the basis of the .geo proposal fails to address this phenomenon and raises issues again of object classification raised earlier.

6) The suggested scheme creates a dilemma over management of
existing indexed deep collections of spatial data stored in
terabyte databases (e.g. satellite images)  and an external .geo
index. This would lead to a .geo index of databases or images that would have to replicate the contents of these databases. Because the .geo proposal is an explicit domain proposal instead of a common application interface proposal, the choice of when and how to index objects is not made clear. The result continues to be an inconsistent reference to the universe of geo-enabled information objects on the Net.

7) A registration process is proposed for .geo domain nodes. The proposed registration process for what is essentially metadata would create an extra and completely unnecessary burden on an industry (and human behavior) that is already loathe to create such descriptions!
This extra registrar system creates extra bureaucracy that most organizations will find puzzling and will again implement in an inconsistent way. The world does not conveniently partition itself into neat hierarchies. I would submit that the human dimensions of organizing people and having them to agree to coordinate and register their information in a multi-scale environment is, from experience, the most complicated part of the discovery equation. The .geo proposal does not simplify this process or problem, and in fact, could be completely overwhelmed by this management of human information space. This is not something technology can solve, but could actually worsen if not taken into account.

8) There are already a number of internationally recognized capabilities for performing spatial search of information resources that would be in conflict with the .geo proposal. The issue with these existing protocols is not in their capability or scalability but in their publicity. The Web community needs to arbitrate the existing protocols and advance them rather than sanction something new and untested and potentially difficult to manage both on the human and computer levels.

An ISO-standards based search protocol exists for catalogue search across bibliographic, web, and spatial resources (ISO 23950-1995) providing an abstract interface to indexes that works independently of domain name and is implemented in many countries for many disciplines. A specific case of this is the GEO Profile of Z39.50 that supports
sptial search and supports inherited bibliographic and temporal properties within a registered set of named 'fields' and operators. The OGC has endorsed a Catalog Services standard protocol that adopts the abstraction and protocols in the ISO 23950 standard.

If one wanted to look at existing directory mechanisms that could function independent of a .geo domain, there is extensive commercialization of directory services these days. If one were to invest effort in geospatial discovery on an existing substrate, then I'd propose that the X.500 and LDAP referral services could be extended to perform cascading spatial search in a more interesting, flexible, and extensible way than the proposed .geo solution.

In summary, the .geo proposal is not necessary to the geospatial enabling of the Web. Alternate mechanisms should be encouraged engaging multiple sectors already working this problem and elevating the current issues and solutions to positions of prominence within the broader community.

Doug Nebert
U.S. Federal Geographic Data Committee Secretariat
Geospatial Data Clearinghouse Coordinator


Message Thread:

Privacy Policy | Terms of Service | Cookies Policy