[ Home ] [ Contents ]
[ Top ]
NEXT MEETING
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 Melbourne University Geography Department
generously continues to host our Web pages, but their
computer has been replaced, so our web address has
changed to: http://rubens.its.unimelb.edu.au/~pgm/uisic/
My email address has also changed. The new address is:
matthews@melbpc.org.au
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
( rauleigh@iinet.net.au ), 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 ]
[ Home ] [ Contents ]
[ Top ]
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: http://www.inria.fr/agos-sophia/sis/DB/database.html
The author is always seeking contact-people in various
countries to gather information for this database.
Contact (email only): Eric.Madelaine@sophia.inria.fr
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.
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.
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
( rauleigh@iinet.net.au ), 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.
PROPOSAL
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:
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:
aabbbnnnnn
For example: AUVSA00035
where:
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.
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.
Identifiers
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á!
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).
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,
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
This [paper] edition has been printed and distributed by Karst- und
Höhlenkundliche Abteilung, Naturhistorisches Museum, Wien.
INTERNET
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!
SOFTWARE
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.
WORLD NEWS
Brief news items about cave and karst informatics or
documentation from around the world are welcome!
Email: graham.price@ukonline.co.uk
Web: Info on Register via
http://www.nca.org.uk
Email: gferrari@etnoteam.it
Email: hmartin@magpage.com or caveslime@aol.com.
PROPOSAL FOR CAVE DATA EXCHANGE STANDARDS
[ 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. ]
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
Karst- und Höhlenkundliche Abteilung,
Naturhistorisches Museum,
Messeplatz 1/Stiege 10/1, A-1070 Wien, Austria.
Email: speleo.austria@netway.at
Publisher's Box
Newsletter of the UIS Informatics Commission (UISIC).
66 Frogmore Cres., Park Orchards, Victoria 3114, Australia.
Tel. +61 (3) 9876-1487 (home).
[Tel. updated Apr 2005 - Ed.]
Email: matthews@melbpc.org.au
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:
http://www.uisic.uis-speleo.org/ib05.html
Site: P. Matthews