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.
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?
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
6) The suggested scheme creates a dilemma over management of
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.
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
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.
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.
Federal Geographic Data Committee Secretariat
Geospatial Data Clearinghouse Coordinator