SRI International (SRI) proposes to ICANN a new top-level domain (TLD), .geo, which will make the full power of geospatial knowledge available to all Internet users. Properly implemented, .geo will make the Internet more efficient, both technically and as a tool for human communication and commerce. It also will open new global and local opportunities for science, commerce, education, and enterprises - even in the developing world, where such civic and commercial activity has in the past been technologically or economically difficult or impossible.

This new TLD will provide a complete, virtually free, and open infrastructure for registering and discovering georeferenced information on the Internet. Georeferenced information is information that represents a geographically located place, object, or process with a geographic location. (Additional italicized words are defined in the appended glossary.)

SRI's proposal stipulates that the basic service made possible by .geo, the registration and discovery of georeferenced information, will be virtually free to Internet users and based on internationally accepted open standards. SRI anticipates that access to this information via .geo will vastly increase the Internet's usefulness and will have applications in diverse sectors including education, science, commerce, and government.
 

Geodata, Data, and the Power of .geo

In the world of digital libraries, metadata is an abstraction, or summary of data. Geodata, as we call it here, is a summary of georeferenced information. It may include the information's author, owner, date, geographic location, keywords, and one or more mime-type/URL pairs pointing to one or more attributes or digital representations of the georeferenced information. Today's Internet contains a great deal of information that can be georeferenced - the National Academy of Sciences estimates that 80 percent of the information on the Internet has a spatial component - but it does not provide the geodata necessary for the prospective user to exploit this information.

Online maps are a form of georeferenced information. These maps are inaccurate and often incomplete. They are also expensive to maintain, proprietary, and difficult for the average Internet user to use. Tellingly, more than 70 percent of adults cannot read maps. A new, more ubiquitous way of accessing, displaying, and working with georeferenced information is needed.

.geo will provide an intelligent schema for rapidly collecting and registering geodata that can then be used as a directory to georeferenced information. The geodata directs Internet users to the information they are seeking, based on the geospatial region in which the information resides or to which it relates. .geo-enabled searches will be much quicker, more focused, and more accurate than searches based on existing technology.

With new, freely available, browser technology developed by SRI and others, .geo will be able to present this information in two or three dimensions, time series, and other forms - including traditional lists with links - that will be easy for the typical Internet user to locate and use. This ubiquity of georeferenced information will provide a foundation for new Internet applications.
 

The New World of .geo-Enabled Applications

.geo will become the latitude and longitude of the Internet's virtual world. It will enable the essentially free registration and discovery of standardized geodata. Data Providers will generate and own this geodata and the georeferenced information to which it refers. They will be able to make this georeferenced information available to Internet users, either free or in return for considerations including subscriptions and major purchases of products and services.

The types of georeferenced information to which .geo will direct users may include non-digital legacy information, like maps archived in a library; digital maps, elevation data, and aerial and satellite images; geographic locations of businesses, commercial and government services, and natural resources; three-dimensional (3D) dynamic models of places including buildings, bridges, roads, sea and air lanes, vegetation, croplands, and vehicles; scientific models of natural phenomena; geoparsed textual information; and formats unknown to us today.

Data Providers will be able to geocode their information themselves or contract with others to do it for them. Similarly, Data Providers will be able to format their information for different types of access - for example, as 3D models or as lists with links - or contract with others to do the formatting.

Georeferenced information, as SRI envisions it, might include nearly every type of information currently available on the Internet and many types not yet available there. Similarly, many and various services will be based on this information. These services fall into three broad categories:

• Discovery and sharing of information, including:

  Education (about people, places, things, and processes)
  Travel and tourism
  Electronic commerce: for example, locating vendors
  

• Analysis of information, including:

  Economic development and health planning
  Business logistics
  Conservation and sustainable exploitation of resources
  Traffic congestion
  

• Collaboration based on information, including:

  More democratic, inclusive, informed governance
  Regional and international scientific and economic cooperation
  Flexible responses to health crises and natural disasters
  Rationalization of markets and the means to serve them
  

A thorough discussion of applications, including depictive user scenarios, is contained in this proposal's discussion of the Market, D13.2.3.
 

The .geo Hierarchy

.geo will organize the entire world of things and processes in geographical formats that are compatible with Internet use. It will not be a mapping convention, although it will be used to generate maps more complete than any on the Internet today. The .geo TLD, in combination with the Internet, will organically generate a dynamic universal atlas of natural and human phenomena - on land, beneath the waves, and in the skies (even in outer space).

The Schema. Everything in the world has one or more locations. .geo will categorize these locations according to a Domain Name System (DNS) hierarchy of geographic domain names. Unlike other proposed TLDs in which domain names are assigned arbitrarily, in .geo the hierarchical domain name will have real meaning: it will represent a region bounded by latitude and longitude. Such a region will be called a cell. Following are example applications of this schema.

• The geographic domain name 20e30n.geo identifies the 10-degree x 10-degree cell whose southwest corner is located at 20 degrees east, 30 degrees north.

• The geographic domain name 2e4n.10e50n.geo identifies the 1-degree x 1-degree cell whose southwest corner is located at 12 degrees east, 54 degrees north.

• The geographic domain name 11e21n.3e7n.30e10n.geo identifies the 1-minute x 1-minute cell whose southwest corner is located at 33 degrees, 11 minutes east and 17 degrees, 21 minutes north.

An XML name schema file downloadable from the URL nameschema.geo will specify the exact form of the hierarchy, the naming convention for cells.

GeoRegistries and Cell Servers. Each geographic cell in .geo will be assigned at least one server, called a cell server. Cell servers will be maintained by organizations called GeoRegistries, who will be contractually obliged to provide services for the registration and discovery of geodata according to protocols and minimum service criteria defined by the Sponsor. Briefly, a cell server assigned to a given cell will be responsible for storing and responding to queries for geodata that lie within its cell boundary.

GeoRegistries may charge a fee for registration of geodata, but this fee will not exceed a value specified by the Sponsor. GeoRegistries will not charge a fee for the discovery of geodata, unless they are doing so on behalf of Data Providers. GeoRegistries may offer other services to Data Providers, such as data hosting.

GeoRegistries will be identified by their brand name. For example, a GeoRegistry named "acme" may have a server (say server1.acme.com) that is assigned to cells 10e20n.geo, 10e30n.geo, and 2e5n.10e30n.geo. This means that the cell server domain names acme.10e20n.geo, acme.10e30n.geo, and acme.2e5n.10e30n.geo are all registered in the .geo gTLD registry, and are all delegated to server1.acme.com.

Note that several GeoRegistries may have cell servers assigned to the same cell. For example GeoRegistries "acme," "best," and "first" could all have servers assigned to the 20e30n.geo cell, designated acme.20e30n.geo, best.20e30n.geo, and first.20e30n.geo. Competition among GeoRegistries is ensured, since many GeoRegistries can assume stewardship for the same cell, competing on quality of service and other terms.

One special GeoRegistry must have a server assigned to every cell on the planet. This GeoRegistry will be called the default GeoRegistry named "earth." (The names of the other planets will be reserved for interplanetary geodata.) The default GeoRegistry will be used when client queries do not specify a GeoRegistry name, or when the specified GeoRegistry does not have an assigned cell server.

Since only one cell server can carry the default name, the default GeoRegistry will be maintained by one or more entities (corporations, not for profit organizations, government agencies, etc.) on a regional basis. For example, organization A may be assigned cells covering parts of North America, while organization B may be assigned cells covering parts of Europe. Organizations will be required to meet stringent performance and service standards and will be allowed to compete on a regular basis for the assignment of default cell server domain names.

GeoRegistrars. A Data Provider who wishes to make its georeferenced information available via .geo must use the services of an accredited GeoRegistrar (accreditation criteria will be defined by the Sponsor and implemented by an accreditation authority designated by the Sponsor, called the Accreditor). A GeoRegistrar will be analogous to a traditional Domain Name Registrar; but instead of registering a domain name in a Domain Name Registry, a GeoRegistrar will register a geodata record in a GeoRegistry. Specifically, the GeoRegistrar will (1) determine the cell(s) corresponding to the geographic location or area specified in the geodata according to the name schema, (2) choose a GeoRegistry, and (3) transmit the geodata record to the corresponding cell server(s) defined by the GeoRegistry name and geographic domain name.

For example, consider the simple case of a restaurant with an established Web presence (such as www.myrestaurant.com). In this case, a GeoRegistrar may offer a simple browser interface that would allow the restaurant owner to enter the street address of the restaurant, the restaurant's name, various keywords, and the URL of the restaurant web site. To register this geodata record, the street address will first be geoparsed and geocoded to provide the geographic coordinates of the restaurant (geoparsing and geocoding services are available today). Then, the geodata record will be registered as described above.

But consider a case in which the Web site describes several restaurants, each with its own home page (such as www.familyrestaurant.com/moms.html). Even though there will be only one web site for all of the restaurants, it will be possible to register a distinct geodata record for each home page because each geodata record contains one or more complete URLs for the information.

Home pages and domains are not the only kind of georeferenced information that a business may register. For example, a specialty firm may create and register a 3D graphics model of each restaurant's locale, with a hyperlink to the restaurant's home page. Many other classes of georeferenced information, such as digital maps, aerial images, or weather data, could be registered in this fashion.

Dynamic GeoRegistrars. A special class of GeoRegistrars called Dynamic GeoRegistrars will handle dynamic data, such as the real-time position of aircraft or weather systems. We envision a Dynamic GeoRegistrar as a trusted agent that will maintain the real-time location (and other attributes) of the object. Each object in the Dynamic Registrar will have a unique ID such as aircraft-xxx, where xxx will be an encryption of the aircraft's identification number. The purpose of encrypting this information will be to create a unique ID for each aircraft without publicly specifying the aircraft to which it corresponds (for security reasons). This unique ID could be represented as a domain name, such as aircraft-xxx.id.geo, though this is not necessary.

For example, an aircraft equipped with GPS receivers and secure wireless Internet access could periodically contact the Dynamic GeoRegistrar (or the server delegated to its unique domain name) to update its current location, velocity, and other attributes. This information could then be used to update the geographic coordinates (and other attributes) in the corresponding geodata record in the .geo hierarchy, and, when necessary, transfer the geodata record to a new cell. This dynamic geodata can then be used for many purposes, including air traffic analysis and providing global near-real-time maps of air traffic. Of course, the aircraft could in turn use .geo to download or access localized flight/airspace support information.

In the case of weather data, the Dynamic GeoRegistrar might be the National Weather Service, which maintains real-time weather maps or storm locations. As in the example above, the Dynamic GeoRegistrar would periodically update the corresponding geodata record and, when necessary, transfer it to a new cell.

Note that, in general, the attributes publicly available in the geodata record (such as the location of the aircraft) may not be as accurate as the information in the Dynamic GeoRegistrar, for security reasons. Other information that is available in the Dynamic GeoRegistrar (such as the owner of the aircraft) may not be placed in the geodata record at all, or may be specified via a secure URL.

Validation of Data. To ensure the accuracy and validity of certain classes of data for certain purposes (such as elevation data used for city planning purposes), the geodata record will have a field for one or more optional validation certificates issued by validation organizations. The digitally signed certificate will certify that one or more elements of the geodata/data meet certain qualifications, such as accuracy or completeness, or compliance with local, national, or international standards or conventions. An organization authorized by the Data Provider to provide validations will be able to issue a validation certificate for geodata offered by the Data Provider.

Data Discovery. Users who wish to discover data for a given area will use either a .geo search engine Web site within a standard Web browser, a plugin, or a specialized application. In any case, the user will specify a query (e.g., all train stations within walking distance of a given location); the system will then compute the cell(s) that cover the query, choose a GeoRegistry, and transmit the search query to the corresponding cell servers. The cell server(s) will respond with a list of all geodata records that satisfy the search query. Where appropriate, the system will download the data referenced by the URLs in the geodata records and integrate these data into a view. This view could be a list of URLs ordered by distance from a point, or as a set of icons on a map, or as a set of 3D models with hyperlinks integrated into a 3D scene.
 

Benefits

.geo will be an Ever-Expanding, Dynamic, Universal Atlas of Georeferenced Information. Unlike proprietary mapping systems, the .geo schema will distribute the responsibility for locating georeferenced information, putting its control squarely in the hands of Data Providers rather than self-appointed second and third party intermediaries. Because .geo will be able to demarcate very small as well as very large geographical regions, Data Providers will be able to offer information that meets the needs of highly focused searches as well as more general explorations. (For example, a Data Provider may want to provide information about a single location - even a single building - in which it does business, rather than count on its being included on some other entity's map or list.)

With .geo, individuals and organizations that cannot now afford to have their information made searchable by location (especially with search engine providers now charging extravagantly for the privilege) will be able to do so. .geo will greatly increase the population of Data Providers - and thus the cumulative value of the Internet - by enabling virtually any individual or organization to offer georeferenced information in a way that will make it discoverable by and useful to every user of the Internet.

Competitive Services. Because more than one GeoRegistry server will exist for every cell, competition at the cell level will be inherent to .geo. GeoRegistries that are locally based will be able to run each server, in competition with each other and with national and international organizations that have in the past dominated the provision of Internet search and directional services. Local GeoRegistries may be able to give better services to local Data Providers and thus encourage more regional commercial activity on the Internet.

Network Advantages. Since end users' client software will be directed to the cells for given geographic areas, single points of failure or congestion will be eliminated. Additionally, cell servers will be less likely to fail because, unlike conventional network servers, they will have reduced storage and throughput requirements: the information they contain will be geographically bounded.

Moreover, because each server can physically be located near or within the defined limits of its cell, overall load distribution for the global .geo network will be exceptionally balanced and even. In the early stages of .geo, many domain names initially can be assigned to single servers. For example, domain names acme.10e30n.geo, acme.10e40n.geo, and acme.20e30n.geo can initially all be delegated to a single server. As demand increases, the load can be transparently distributed by redelegating the names to distinct servers. The .geo network of cell servers will be dynamic and scalable, always on and always available to a great number of users.

The .geo-enabled Internet will be more robust than the current Internet. .geo will enhance the Internet's overall performance and will help allocate its resources more intelligently. By enabling end users to search for and discover information more efficiently - in the way users prefer, rather than the way current search engines require - .geo will eliminate redundant searching on the Internet, reducing the burden searching imposes.
 

Enforcing Standards, Protocols, and Performance Criteria

The distributed nature of the infrastructure will demand that all GeoRegistries within the hierarchy adhere to well-defined standards and protocols for the publication and discovery of geodata. In an open forum that includes GeoRegistries, GeoRegistrars, Data Providers, international standards organizations, and, most important, end users, the Sponsor will define the standards, protocols, and minimum performance criteria for GeoRegistries. These standards and services will evolve over time as new services emerge that fit naturally into this new hierarchy.

The gTLD Registry (in close cooperation with ICANN) will be responsible for accrediting both the GeoRegistries and GeoRegistrars, ensuring that they correctly use the Sponsor-defined standards and protocols, and meet the Sponsor-defined performance criteria.
 

Conclusion

As a new top-level domain, .geo will provide a unique paradigm for harnessing the power of the Internet. .geo will be based on the way human beings perceive and comprehend their world: geospatially, in three dimensions, and over time. .geo will enable Internet users to navigate, access, and visualize georeferenced data as they would in a physical world, but without the barriers imposed by space and time in the physical world. It makes the world knowable as never before.
 

Glossary

Accreditor (short for GeoRegistry/GeoRegistrar accreditation agency):

an agency designated by the Sponsor to apply the accreditation criteria defined by the Sponsor to GeoRegistries and GeoRegistrars.

Brand Name (short for "cell server brand name"):

the component of a domain name in the .geo hierarchy that represents the name of a GeoRegistry, such as the "X" in X.30e40n.geo.

Cell:

an area, bounded by latitude and longitude lines on four sides, defined by a geographic domain name in the .geo hierarchy, such as 3e4n.10e50n.geo.

Cell Server:

a server assigned to a cell, identified by a cell server domain name such as X.3e4n.10e50n.geo. Note that there must be one or more cell servers per cell. If only one cell server exists for a given cell, it must have the default brand name "earth."

Data Provider:

any individual or organization with georeferenced information, who wishes to register the corresponding geodata in a GeoRegistry.

Default Brand Name (short for "default cell server brand name"):

the special brand name, such as "mercury," "venus," "earth," "moon," "mars," that denotes the default GeoRegistry for a planet. Other cell server brand names always refer to the planet Earth.

Default Cell Server:

a cell server with a default brand name. Other cell server brand names always refer to the planet Earth. If there is only one cell server for a given cell, that server must have the default brand name "earth."

Dynamic GeoRegistrar:

a GeoRegistrar that maintains dynamic georeferenced information and periodically updates the corresponding geodata in a GeoRegistry.

Geocoding:

the process of translating a description of a location (such as a geoparsed street address) to a geographical coordinate, such as longitude and latitude.

Geodata:

the specialized form of metadata for georeferenced data used in the .geo hierarchy and stored in GeoRegistries.

Geographic Domain Name:

the component of a domain name in the .geo hierarchy that specifies a cell, such as 3e7n.10e20n.geo.

Geoparsing:

the process of parsing a string, such as a street address, into its components in preparation for geocoding.

GeoRegistry:

a distributed set of cell servers, maintained by a single organization, in which geodata is stored and retrieved. A GeoRegistry is identified by its brand name in the .geo hierarchy, such as the "acme" in acme.3e4n.10e50n.geo.

GeoRegistrar:

an organization that registers (and often creates or validates) geodata in a GeoRegistry on behalf of data providers. GeoRegistrars may offer their services via a Web interface, bulk geoparsing and geocoding of specialized databases, or other means.

Georeferenced Information:

any information, digital or otherwise, about an object or process with a corresponding geographic location or area.

Metadata:

an abstraction, or summary, of data.

Name Schema:

an XML file that specifies the structure and naming convention for cells and brand names in the .geo hierarchy.

Validation Certificate:

an optional, digitally signed certificate issued by a validation organization. It certifies that one or more elements of the geodata/data meet certain qualifications, such as accuracy or completeness.

Validation Organization (validator):

an organization that issues validation certificates. Any organization authorized by the data provider can issue a validation certificate against geodata/data owned by the data provider.