No. 5 - July 1997

This on-line version is the same as the paper edition, except for the navigational etc links. [ Also later updates:
1, 2, 3 - Ed.] To save costs, the paper edition is being posted only to those on the Contact List who do not have an email address. However, versions for local printing are available for download.

[ Home ] [ Contents ]



We are finally moving with cave data exchange and field definitions. This issue of our Bulletin introduces
UISIC's proposals, and hopefully by the time you read this, they are also being discussed over our mailing list on the Internet. Discussion will then continue at the Congress, and afterwards for some considerable time, I suspect! It's going to be a long haul, but ultimately worth it.

[ Home ] [ Contents ] [ Top ]


Our next meeting will of course be held during the UIS Congress in Switzerland in August this year. There will also be demonstrations of cave database software. All are encouraged to attend and take part in the discussion. If you have a particular item you want included on the agenda, please send me the details.

The main agenda items to date are:

[ Home ] [ Contents ] [ Top ]


The Commission has been putting the Internet to good use since the last edition as described below. There have also been some Internet address changes since then. These days, it seems that if you want to take part fully in desktop caving you need to be on the Internet! One very significant benefit is that issues can be discussed in an economic and timely manner by people spread around the world, where previously they would have had to attend a meeting personally. And as an effective communication medium, email definitely beats paper correspondence!

The Melbourne University Geography Department generously continues to host our Web pages, but their computer has been replaced, so our web address has changed to:

My email address has also changed. The new address is:

We now also have an Internet mailing list called CaveData. This is used for news, announcements, queries, and discussions. Any email sent to it is automatically retransmitted to everyone on the list. This mailing list has been generously provided by Rauleigh Webb in Australia.

To get on the list, send an ordinary email to Rauleigh Webb ( ), asking to be added to the list. [ Subscription method updated from the original on 26-Oct-97 - Ed.]

The web version of our contact list, UISIContact, has been a fast and economical way to keep people advised of the latest new and changed addresses. A new paper edition (No. 3) has been issued at the same time as this Bulletin.

Our field definition discussion will be held via the Internet (see also below), and the progressively developing definitions will be available on our web pages.

To reduce costs, this edition is being made available electronically to as many of you as possible via the Internet, either for reading on the screen, or for downloading and local printing.

Further Internet information related to UIS can be found in my 1993-97 Commission Report, which will be published in the UIS-BULLETIN.

[ Home ] [ Contents ] [ Top ]


The software I am designing for the Australian system is of course using all the proposed UISIC standards, and will be available to anyone on an inexpensive shareware basis. Separate database software will not be required. The first version is specifically designed to run on low-powered DOS PCs (286 with 1-2MB memory) to permit widest possible use, including in countries where PCs are still difficult to obtain. The software also runs under Windows 3.1 and 95. The subsequent version (also shareware) will be designed to take full advantage of Windows facilities, but will require a modern PC to run effectively. Java is also an option. The UISIC specifications will be freely available in the public domain so that other developers can produce UISIC-compliant database software, including Mac versions.

[ Home ] [ Contents ] [ Top ]


Brief news items about cave and karst informatics or documentation from around the world are welcome!

Australia - Peter Matthews

The Australian Speleological Federation has produced a comprehensive Data Use Agreement to help smooth the operation of its distributed Karst Index national database.

France - Eric Madelaine

A World Caves Database (caves over 3kms long or 300m deep), is available online at:

The author is always seeking contact-people in various countries to gather information for this database.

Contact (email only):

Great Britain - Graham Price

Development work is under way on a British Cave Register. The project is being co-ordinated by the National Caving Association (NCA). Initially only caves were to be included, however the spec has been expanded to include karst features and abandoned mines. Existing regional Cave Registries, the British Cave Research Association (BCRA) and the National Association of Mine History Organisations (NAMHO) are involved in the project.

A database design package, InfoModeler, is being used for development work. The advantage of this approach is that it enables full model-driven generation of complete applications and allows for documenting, alteration and maintenance of the physical database schema. The system will therefore be completely independent of the proprietary DBMS and a data compatible working database can be generated in any chosen application. Initially MS Access is being considered as the end-user DBMS since this has provision for run-time versions and a Web publishing facility, plus other advantages.

Concurrently, a GIS is being developed using MapInfo. The use of one of the new object-relational database management systems (ORDBMS) such as Informix Universal Server is being considered. Whatever systems are used it is intended that the data will be made widely available on a number of platforms and by a variety of means.

Contact: Graham Price, Co-ordinator, National Cave, Karst & Mine Register, National Caving Association, 3 The Acorns, Oakhill, Bath, BA3 5BT, England.
Email: Web: Info on Register via

Italy - Graziano Ferrari

At the 1997 national convention (Casola '97 - 1 Nov 1997) the Italian Cave Register Commission will deliver the first version of the National Cave Register and Program.

Data shown will be information about the registered caves of Italy (30,000 entries). The Program is a Windows-based read-only application with a lot of search selections on the various fields. The underlying database is Access.

Informatics work is ongoing in the following fields:

Contact: Graziano Ferrari, Coordinator, Italian Cave Register Commission.

USA - Harris Martin

The NSS Underwater Cave Study Group (UCSG) has a 1998 goal of developing a portion of a web site where cave (air-filled and underwater) survey datasets (excluding actual cave location coordinates) can be uploaded, compared, analyzed statistically, etc. so that geostatistical, hydrological, and speleological studies can be done by anyone who wants to access them. The Project Leader is William Wilson, Subsurface Evaluations, P.O. Box 3658, Winter Springs, Florida 32708 USA. Tel: +1 (407) 695-3414. Fax: 695-8563.

Contact: Harris Martin, Coordinator, NSS Underwater Cave Study Group, 229-A Presidential Drive, Greenville, DE 19807 USA. Tel: +1 (302) 427-8444.
Email: or

[ Home ] [ Contents ] [ Top ]


Peter Matthews, UIS Informatics Commission

[ Web Editor: This is the original version as published in the paper edition. There is a
separate version which will be progressively updated as discussion proceeds. ]

One of the basic aims of the UIS Informatics Commission has been to facilitate local and international exchange of data related to caves and karst. Most of the work which has been going on to date has been in preparation for opening this discussion. The International Geographical Union is also interested in this issue, and so it will be a joint UIS/IGU project.

Because the same database software or structure is not needed at each end, an exchange standard will facilitate:

Below is UISIC's opening proposal. Each aspect in turn will be presented for discussion via the CaveData Internet mailing list, prior to emailing (or posting) the results to delegates for comment and later for voting. (To get on the list, send an ordinary email to Rauleigh Webb ( ), asking to be added to the list.) [ Subscription method updated from the original on 26-Oct-97 - Ed.]

If you do not have an Internet connection you will not really be able to take part fully in this discussion phase. However, if you have views on this matter, you can still supply input by sending it to me (if possible in plain text on a diskette) for incorporation into the discussion. Official UISIC delegates who do not have Internet will still receive the final drafts by post for comment, and later will receive the final material for voting.


Requirements to allow data exchange

The following three requirements are needed to allow the valid transfer, comparison and/or consolidation of cave/karst data between independent databases:

  1. Record Identifier Use of a record identifier which is internationally unique and permanent for each cave or karst feature or other entity being transferred.
  2. Field Definitions Use of internationally agreed definitions for the data fields and field values to be transferred.
  3. Transfer Format Export and import of the exchange data from/to the database via an intermediate standard UIS transfer format.

It is not required that the same software or database structure be used at each end of the transfer.

We now look at these three requirements in more detail:

1. Record Identifiers

The record identifiers (database keys) should be constructed as follows to conveniently achieve uniqueness:


For example: AUVSA00035


2-letter ISO country code indicating the country where the record was originally created (example AU = Australia).
3-letter organisation code issued within that country and indicating the organisation which originally created the record. (example VSA = Victorian Speleological Association).
a numeric serial number, being an agreed fixed length for a given entity, and padded left with zeros. Unique within a given aa and bbb. See Entity List below for length.

Once created for a record, the identifier should never be changed, regardless of where the record travels, or what has happened to the original organisation, or which organisation is currently looking after the master copy of the record.

2. Field Definitions

When the field names and field values of international definitions are actually being used, they will need to be expressed in various human languages. Language-independent numeric codes are therefore used wherever possible as a common reference to the field name or field value regardless of the language currently being used.

2(a) Field names: Each field name is represented by a simple numeric integer such that a given field with a particular meaning has the same numeric code regardless of the language in which its name and definition are expressed. For example, a Field ID of "7" could have the name "Rock type" when expressed in English.

The field names themselves are recorded in two fields - one for normal usage and having a length of 25 characters, and another to suit some early database systems and having a length of 10 characters.

2(b) Field values: Each field value is, wherever possible, represented by a simple numeric integer code such that a given field value with a particular meaning has the same numeric code regardless of the language being used. For example, a Field Value of "26" in Field 7 (Rock Type) could translate to "sandstone" when expressed in English, or "Sandstein" when expressed in German.

Where commonly accepted local field values or codes already exist for a field which has only local significance, for example, "Geological Bed Names" or "Parish", then these local codes should be used, but the meanings will then need to be transferred, along with the data, in any data exchange.

3. Transfer format

When transferring data between different databases, UIS's standard transfer format should be used (Name: Karstcom? InterKarst? ...). This format uses only standard ISO text characters, and is independent of any database software or structure. Therefore any database system needs only to be able to translate to or from this one common intermediate format in order to exchange data with any other co-operating database system.

Entity List

The lengths in the following list should be used for the fixed-length serial number component in the record IDs of the respective entities. Note that the serial number need only be large enough to allow for the maximum number of records for that entity generated by the one organisation, not for the quantity of records stored at any one site; this is because any duplicate serial numbers will be distinguished by the originating country+organisation code.

The list is a draft initial list only. Further entities can be added as needed. The two-letter codes have been chosen to reflect the entity in more than one language where possible.

                                       Max Records
                          Length of    created by
ID    Entity              Serial No.   one Org.
----  ------------------  ----------   -----------
AR    article, paper      6            1M
AT    attribute, field    n/a
AV    attribute value     n/a
CA    cave/karst feature  5            100K
EN    entity              n/a
JN    journal             4            10K
OR    organisation        4            10K
PE    person              5            100K
PH    photograph          5            100K
PL    plan, map           5            100K
PM    permanent mark      5            100K
PS    map series          3            1K
RE    region, area        4            10K
RP    report              5            100K
SM    specimen            5            100K
SP    species             5            100K
ST    site, place         3            1K
SV    survey              5            100K
SU    subject             n/a
SY    system              n/a
XK    key-in batch        5            100K
XL    upload batch        5            100K
XU    update batch        5            100K


The first two requirements above (identifier and definitions) should be used from the beginning if possible. It does not matter which database software you use, nor the structure of your database, nor which subset of the available fields you have chosen, provided that you have adhered to the field and field value definitions. For example, multi-valued fields have to stay as multi-valued fields.

The fact that many of us already have cave databases in existence, and are already using various independent field definitions, should not be a reason to prevent us from establishing a standard which can be used by new systems, or by later evolution of our existing systems if/when we feel that the time is right. Further, as we go through the field definitions, it is expected that we can come up with definitions which will allow many of our existing fields to comply with them anyway. In fact, one of the fields in the proposed list allows classifying the level of compliance of each existing field. Any existing fields which are found to already comply with the standard definitions could then be validly transferred to other databases.


The use of an internal identifier (key) is normally routine for identifying and linking database records. However it needs to be globally unique so that there is no risk of it duplicating an existing key when loaded into someone else's database. We do not want to have to change the incoming key in such a situation, because then any linkages between entities in the original incoming tables would be lost.

Public "cave numbers", while needed for normal public usage, are not ideal for this identifier because they do sometimes get changed, they vary in their structure, and they can be unnecessarily long.

The record identifier does not need a component to identify the entity type, because this can readily be handled externally.

The scheme described above is currently in use as a test in the Australian national database.

The method described (a country code + an org code) allows each organisation which produces data records to issue internationally unique keys without needing to refer to any central authority. The 3-letter org codes would be set at the national level by the speleo community in that country.

The serial number part is fixed-length, left-zero-filled, so that the alphanumeric record IDs will sort correctly when required. The serial number component for the ID of a particular entity needs only to be large enough to cover the maximum quantity of records for the entity which could be generated by the one organisation, as opposed to the maximum quantity of entity records stored at any site. The proposed entity codes and key lengths are shown in the table above.

Regardless of ID design, organisational arrangements need to be made to allow separate clubs to contribute their data to the total database information for a given cave, i.e. merging of records. In the Australian pilot, this is done by allowing only one club to update the national database for any given cave area, but of course with a mechanism to allow other clubs to contribute, and to get proper attribution for the data they have provided.

Where a database already exists, and it proves to be not feasible to convert its keys to the above scheme, then a mechanism needs to be added so that the international keys are produced whenever data is exported. The mechanism must ensure that the same internal record always produces the same external key. For example, if the existing internal record keys were a simple integer, then the external key could be produced by left-padding the number with zeros and adding the appropriate five letters to the front.

Note however that if the key was changed in this way, any instances of its use as a "foreign key" in linked tables of other entities must also be changed. (A "foreign key" is a non-key field (usually) in a table whose value is the same as the key field(s) of a different table.). For example, a map entity record describing a map might have a field containing the ID of a cave entity which was shown on that map; when the map and cave records are exported, the cave ID value in the foreign key field of the map record must be altered in the same way as the cave records were. Obviously it's much simpler if a once-only change can be made to the whole database to align its keys and foreign keys to the international standard; from then on, no more key conversions need to be made.

Field definitions

Field definitions will be systematically discussed in English via the Internet before being circulated to UISIC delegates for further comment and eventual voting. This initial batch of fields are first-pass general caving fields; after some of these are out of the way we can also start to look at fields which are more scientific or specialised. The suggested procedure is (improvements invited!):

Transfer format

Background: An early version of the transfer format was successfully used by the Australian database in 1985 when ASF produced their national cave, map and reference list, the 500-page Australian Karst Index 1985. UISIC subsequently issued a draft standard to delegates for comment at the UISIC meeting during the 1989 UIS Congress in Budapest. In 1991 ASF produced a standard formalising their Karst Data Interchange (KDI) format as used in 1985. A programme has been produced by Glenn Baddeley which translates from this early KDI transfer format into a series of plaintext tables for importing into a multi-table database. This was demonstrated at the Beijing Congress. Based on the foregoing experience, UISIC will be issuing an updated version of the 1989 UISIC draft for further discussion and comment.

Basically, the sender uses their own DBMS software to export the required data to text files in comma-delimited or fixed-width format. They also construct some simple text files describing these tables. A UISIC-supplied programme then uses these descriptor files to convert the text data tables to a single consolidated text file in the transfer format. This is the file which is transferred. At the receiving end, a UISIC-supplied programme converts the transfer file into a receiver-specified set of text tables in comma-delimited or fixed-width format. The receiver then imports these text tables using their own DBMS standard software import utility. Voilá!

[ Home ] [ Contents ] [ Top ]

No.4 in a series

Dept of Speleology, Natural History Museum, Vienna.

Within the Austrian cave registry, which is based on natural boundaries together with a four-point registration number, there are 12,000 caves currently registered in a database. The main facts for these caves are reported each year from the responsible clubs to the documentation centre within the Department of Speleology at the Natural History Museum in Vienna. About 200 to 300 new caves are registered each year in this way. In the Department there is now for all users a complete alphabetic register of all cave names available. We plan to publish the natural boundaries within the publication "Speldok" as a diskette.

For two Austrian federal departments the "Katasterbücher" (cave-registry-books) are finished: in Vienna and Lower Austria it was done in Volume 4, and in Salzburg in Volume 6. These books present detailed information about the caves of these regions.

The new project of the Austrian Federal Office for Measurements and Surveying (Mapping Division) to publish a new topographic Map Series will bring great changes to the cave database. The new maps will have a new map size, a new geodetic datum and a new projection (UTM).

[ Home ] [ Contents ] [ Top ]

4 in serie

Karst- und Höhlenkundliche Abteilung, Naturhistorisches Museum, Wien.

Im Österreichischen Höhlenverzeichnis, das auf naturräumlicher Gliederung mit einem vierstelligen Kennziffernsystem aufgebaut ist, sind derzeit etwa 12 000 Höhlen in einer Datenbank registriert. Die Basisdaten dieser Höhlen werden unter der Bezeichnung Speldok-Austria jährlich von den zuständigen Vereinen zur zentralen Dokument-ationsstelle in der Karst- und Höhlenkundlichen Abteilung des Naturhistorischen Museums in Wien gemeldet. Rund 200 bis 300 neue Höhlen werden auf diese Weise neu ins Verzeichnis eingetragen. In der Dokumentationszentale steht aufgrund dieser Datenbank auch für Benützer ein komplettes elektronisches alphabetisches Register der Höhlennamen zur Verfügung. Es ist geplant, die naturräumlichen Grenzen der Katasterteilgruppen in der Serie "Speldok" als Diskette zu veröffentlichen.

In zwei Österreichischen Bundesländer konnten die Katasterbücher als reiche Informationsquelle abgeschlossenwerden. In Wien und Niederösterreich wurde das Werk mit dem Band 4 abgeschlossen, in Salzburg mit dem Band 6.

Das neue Projekt des Bundesamtes für Eich- und Vermessungswesen (Landesaufnahme) zur Herausgabe einer neuen topographischen Karte wird weitreichende ünderungen in der Höhlendatenbank erfordern. Das neue Kartenwerk wird einen anderen Blattschnitt aufweisen und vor allem wird ihm eine neue geodätische Grundlage und ein UTM-Koordinatensystem zugrunde liegen.

Günter Stummer,
Karst- und Höhlenkundliche Abteilung,
Naturhistorisches Museum,
Messeplatz 1/Stiege 10/1, A-1070 Wien, Austria.

[ Home ] [ Contents ] [ Top ]

Publisher's Box

Newsletter of the UIS Informatics Commission (UISIC).

The aim of UISIC is to encourage and facilitate the systematic collection and responsible use of cave, karst and related data on an international basis.

President & Editor: Peter MATTHEWS
66 Frogmore Cres., Park Orchards, Victoria 3114, Australia.
Tel. +61 (3) 9876-1487 (home). [Tel. updated Apr 2005 - Ed.]

This [paper] edition has been printed and distributed by Karst- und Höhlenkundliche Abteilung, Naturhistorisches Museum, Wien.

[ Home ] [ Contents ] [ Top ]

[ End of paper edition ]

Printed versions

Apart from printing this document direct from your browser, you can choose the following options for a printed version which is formatted near enough to the same as the paper edition: [ Home ] [ Contents ] [ Top ]
Page address:
Site: P. Matthews