The Database Sundials

ELISABETH RINNER
T H E D ATA B A S E
SUNDIALS
Contents
The Database Sundials as a Means of Research 5

Purpose of the Database 5
Data and Data Basis 5
Interoperability With Other Means and Other Requirements 6
Data Structure and Database Schema 9

The Objects 9
The Sundials 10
The Numbering by Gibbs 11
Additional Materials 11
References 11
Database Schema 12
Data Dictionary 13
Common Properties 13
Table files 13
Table holders 13
Table methods 13
Table objects 14
Table quantities 14
Table references 14
Table sites 15
Table sundials 15
Table sundial_types 15
Table values 15
Conventions 17
Sundial Types 17
References 17
Places 18
Coordinates 18
Transliteration of Greek Text in Inscriptions 18
Labels of Quantities 20
Values 20
Files 21
History 23
References 25
The Database Sundials as a Means of Research
Purpose of the Database
The database Sundials aims to provide data for the research on differ-
ent aspects of sundials as objects which incorporate scientific knowl-
edge such as the knowledge on astronomy used to design sundials or
the spread of sundials and the underlying knowledge.
To do this, the database has to meet several goals:
providing meta data (dating, provenance, holders, size, inscrip-
tions . . . ) on all ancient objects of the Mediterranean area contain-
ing sundials;
providing a classification of the sundials;
providing data on the values of the parameters which are char-

acteristic of the type of sundial for each sundial included in the
database;
providing information on additional materials (plans, photographs,

. . . ) on these objects and their sundials.
Data and Data Basis
The basis of our data stems from S. L. Gibbs standard work on an-
cient sundials.1 This work also provides a hierarchical classification 1
Sharon L. Gibbs. Greek and Roman
of sundials into different types and a classing of all cataloged sundi- Sundials. New Haven and London: Yale
University Press, 1976.
als at least into the main classes of this classification.
In addition to the sundials compiled by Gibbs we use the catalog
of Greek sundials by K. Schaldach,2 which also contains a collection 2
Karlheinz Schaldach. Die antiken
of digital photographies of the sundials included in his catalog. Sonnenuhren Griechenlands. Festland und
Peloponnes. Frankfurt am Main: Verlag
A third collection of sundials comes from N. Severino, who pro- Harri Deutsch, 2006.
vides a very heterogeneous corpus of digital resources.3 3
Nicola Severino. Orologi solari Romani.
The corpus of sundials provided by those collections can be ex- 2003; Nicola Severino and Adam
Shaul. Greek-Roman sundials catalogue.
panded to further objects. 2004; Nicola Severino. De Monumentis
Gnomonicis apud Graecos et Romanos.
Gibbs classification of sundials provides the basis of the classifi- 2005.
cation used within our database. Due to the enlargement of the set
6 the database sundials
of objects there can be additional types of sundials. Since very often

Gibbs only differentiates between main classes of sundials and pro-
vides no classification into subclasses there will also be modifications
of the classing of the sundials.
Gibbs, Schaldach and Severino focus on the dimensions of several

parameters which are characteristic for the layout of each type of
sundials (and thus characteristic for the knowledge used to lay out
the sundial). On the basis of these values they also determine sizes
of dependent parameters by calculation. Both types of values will
be included into the database to enable research on the knowledge
incorporated into the sundials.
To enable research on the spread of the sundials we also include

geographical coordinates on the provenance and the holders of the
objects as an extension to the information given in the works of
Gibbs, Schaldach and others.
Interoperability With Other Means and Other Requirements
The database Sundials should be implemented as a relational MySQL-

database. To make use of foreign-key referential-integrity constraints
InnoDB is chosen as storage engine.
To gain a good interoperability with other means and other

projects the database has to meet several requirements.
The research on sundials is part of a larger project on scientific

objects of the Mediterranean area. Therefore, the database Sundials
has to be laied out in such a way that it can be enlarged to a database
on scientific objects. To connect to recent research on sundials the
numbering of sundials introduced by Gibbs4 has to be included in 4
Gibbs, Greek and Roman Sundials.
the database, too.
The database aims to store information on additional materials on
sundials such as photographies or plans. The information stored in
the database should be both independent of the storage location of
the files and unique to the files in order to achieve a database which
contains as less as possible details of implementation.
Since GoogleMaps and GoogleEarth both use the World Geode-

tic System 1984 (WGS 84) as reference coordinate system and both
applications provide low level tools for some questions of geoanal-
ysis, WGS 84 should be used as reference coordinate system within
the database. Besides its interoperability with these applications, the
WGS 84 standard is the most common reference system for positions
on the earth.
the database sundials as a means of research 7
To provide a better usability with other applications it is recom-

mended to avoid special characters such as Greek letters. Since
LATEXis used as a means for formatting texts in other contexts and
this application contains a adequate transliteration of Greek texts and
other special characters, its syntax can be used to gain a good inter-
operability. Due to the characteristic transliterations it also provides a
good possibility for string search.
All referencesthose concerning single information and those
relating to the object as a wholerelate to literature stored in one
of the projects bibliographical databases. The references stored in
the database should use the same bibliographical databases to re-
late to the literature. To mark those relations to the bibliographical
databases the LATEX(better: BibLaTeX) syntax should be used. Again,
this provides the possibility to search for all citations by searching for
the corresponding string.
In addition to references to traditional sources there is a repository
which contains digital resources to ancient sundials. References to
such resources refer to the database file of the repositoy and are
made in the same way as traditional references.
Wolfram Mathematica is supposed to be the main application
for evaluation of the information in the database. This application
supports the use of MySQL. For a better usability of the database
within Wolfram Mathematica the implementation of the database has
to meet several requirements such as the formatting of some fields
or the standardization of their entries. For example, the use of the
geospatial data types provided by the MySQL-InnoDB storage engine
should be avoided to leave the database open to the usage by a large
number of applications.
Data Structure and Database Schema
The Objects
All sundials are parts of objects that can show several different sundi-
als. For each object we have information about provenance, material,
or dating as well as holder and inventory number. In some cases
there are inscriptions that belong to the object as a whole.
Since there can be several sundials on a single object (for example
at the Tower of the Winds at Athens, fig. 1), there is a one-to-many-
relation between objects and sundials. Because of this information
belonging to a single sundial is stored in a separate table called Figure 1: Tower of the Winds, Athens.
This objects has several different dial
"sundials".
faces, which differ in the sundial types.
For every object there is an entry in the table "objects" to store
these information. Since all objects have (or could have) at most one
datum for the holder of the object and the number in the inventory,
for the material, the dating and the site of the provenance, there
are fields in the same table to store those information about these
properties of the object. Since there are one-to-one- or zero-to-one-
relations between these information and the objects, there are also
fields within this table for a description of the object, inscriptions and
references of those data. Because one site can be the provenance of
several objects and one holder can own several objects, there are the
tables "sites" and "holders" to take account of those one-to-many-
relations within the database. Relations to those tables are made by
referring to the IDs in the fields holder_ID and site_ID of the
table "objects".
For additional notes such as on information about former hold-
ers or contradicting information about the provenance there is an
additional field in the table "objects".
Holders can be characterized by the institution, the department
and the location where the holder is situated. For the location one
can determine latitude and longitude, which too are included in
the database. Because of the one-to-one-relation between all these
information on the holders one can use a single table to store the data
in the database.
The same is valid for the site where an object was found. In ad-
dition to a name of the site there are information on geographical
coordinates to characterize the site.
All these properties are common to almost all ancient scientific ob-
jects. By leaving all information that are characteristic for sundials to
other tables of the database one obtains the possibility to enlarge the
database to other types of scientific objects and the interoperability
with a database on scientific objects is guaranteed.
The Sundials
There are some properties that belong to a single sundial on an ob-

ject. For example there can be inscriptions like labels of lines that
are part of the sundial and do not relate to the object as a whole. All
these information can be stored in the table "sundials". An entry
of this table includes a short description of the sundial, a more de-
tailed description, the inscriptions that belong to the sundial and a
reference of these information.
Within the quantity of ancient sundials one can identify several
different types of sundials: The sundials show a different layout of
lines on different shaped surfaces that may face different directions.
For different types of sundials one can determine a set of several
quantities that is characteristic for this layout but can be common to
several different types of sundials. The values of these quantities are
characteristic for each realization of the layout as a single sundial.
By calculation, one can obtain other quantities like the geographical
latitude which again are characteristic for sundials.
Between types of sundials and sundials there is a one-to-many-
relation. Therefore, in the entry for a single sundial in the table
"sundials" the type of the sundial is given by the ID of its type,
which refers to an entry in a table called "sundial_types".
To take account of the many-to-many relation between sundials
and different quantities that can be determined for the sundials a
table called "values" is used to reduce this relation down to two
one-to-many-relations between the tables "sundials" and "values"
as well as a table called "quantities" (which contains the name of
the quantity and a short description of it) and the table "values".
The one-to-many-relation between methods of determining values
and the values themselves is reproduced by using a table called
"methods" to store those methods. An entry in the table "values"
consists of the value, the ID of the quantity, the ID of the method of
the determination of the value, information about the reference as
well as the ID of the sundial to which the value belongs to.
data structure and database schema 11
The relation between quantities and types of sundials is not re-

produced in the database schema, but it can be obtained by database
queries.
The Numbering by Gibbs
As an additional information on sundials there is an ID-number

which was established by S. L. Gibbs.5 This number does not relate 5
Sharon L. Gibbs. Greek and Roman
to single sundials but to the objects which contain sundials. Due of Sundials. New Haven and London: Yale
University Press, 1976.
this, a good place to store this information in the database would be
an additional field in the table "objects". Since this would destroy
the interoperability with a database on ancient scientific objects, the
ID-number is moved to the table "sundials".
Because there are only few objects with more than one sundial
there is an almost-one-to-one-relation between sundials and ID-
numbers of Gibbs, so adding this data as an extra field to entries
in the table "sundials" produces only few redundancies in the
database. This method is used in the database as a compromise be-
tween usability and good database schema.
Additional Materials
Furthermore, the database stores information about additional (dig-

ital) materials on the sundials such as plans or photographies. Since
in cases of objects with more than one sundial photographies often
show more than just one of the sundials and plans of sundials usu-
ally figure down the whole object and the relation of the sundials
on the object, the relation of the additional materials to the sundials
can be described by a relation between the files and the object (not
the sundial). To take account of the one-to-many-relation between
objects and files (there can be more than one file which belongs to
one object), there is an extra table called "files" to store the infor-
mation on the files. For each file there is information on the object
the file belongs to, the name of the file, a short description of the con-
tents of the file (for example a description of what can be seen on a
photography) and a reference to the source of the file.
References
The information about one single object goes back to different sources
of information. There are two different ways in which references re-
late to information of single objects: First, there is specific informa-
tion which goes back to specific sources (for example, measurements
of different quantities each go back to a specific source). Second,
Figure 2: Database schema of the

database Sundials.
there are general references to the objects which do not need to be
incorporated into the database (for example, articles on some art his-
torical aspects of single sundials). Both types of references are stored
in the database.
All bibliographical information of the research project on sundials
are stored in a BibLaTex database. The database relates to this bibli-
ographical database by using the citation statement "\cite{...}" as
defined by LATEX.
Information to specific data is stored next to this information in an
additional field of the table.
For the general references to all objects there is an extra table.
Since there is a one-to-many-relation between objects and references
to the object, there is an extra table called "references" to store these
information.
Database Schema
As a result the database has the database schema shown in figure 2.

Data Dictionary
Common Properties
All tables in the database use the InnoDB-type. The collation is

latin1_general_cs.
Table files
field type attributes null default extra links to comments mime

ID int (11) No auto_increment
object_ID int (11) No objectsID
file varchar (25) No
description varchar (1500) No
references varchar (200) No
Table holders

institutions varchar (150) No
department varchar (150) No
location varchar (20) No
latitude float No
longitude float No
In the implementation of the database on the server 141.20.159.95

with a usage of the phpmyadmin as database managing software, all
drop-down-menus referring to the table holders show the entries of
the fields ID and department given in this table.
Table methods

method varchar (20) No

drop-down-menus referring to the table methods show the entries
of the fields ID and method given in this table.
Table objects

short_description varchar (60) No
holder_ID int (11) No holdersID
inventory_number varchar (25) No
material varchar (50) No
dating varchar (25) No
site_ID int (11) No siteID
inscriptions varchar (1500) No
note varchar (500) No

drop-down-menus referring to the table objects show the entries of
the fields ID and short_description given in this table.
Table quantities

quantity varchar (1000) No

drop-down-menus referring to the table quantities show the entries
of the fields ID and quantity given in this table.
Table references

reference varchar (100) No
data dictionary 15

site varchar (30) No
latitude float No
longitude float No
Table sites

drop-down-menus referring to the table sites show the entries of
the fields ID and site given in this table.
Table sundials

short_description varchar (60) No
type_ID int (11) No sundial_typesID
inscriptions varchar (1000) No
number_gibbs varchar (5) No

drop-down-menus referring to the table sundials show the entries
of the fields ID and short_description given in this table.
Table sundial_types

type varchar (100) No

drop-down-menus referring to the table sundial_types show the
entries of the fields ID and type given in this table.
Table values

sundial_ID int (11) No sundialsID
quantity_ID int (11) No quantitiesID
value varchar (10) No
method_ID int (11) No methodsID
Conventions
Sundial Types
Within the classification of sundials Gibbs makes up several main

types of sundials such as spherical sundials, conical sundials etc.
that can be distinguished by the shape of the surface on which the
shadow is thrown. Within these main classes she differentiates be-
tween several subtypes, for example Hemispherical DialsCentral
Gnomon Point.
Since there are sundials that are not (or cannot be) classed into a
subtype, there have to be both main types and subtypes as possibil-
ities in the database. As a convention for each entry of a subtype in
the field type the main type is prepended to the subtype. Main
type and subtype are separated by a colon (:).
Example: The type Spherical Sundials has a subtype called Hemi-

spherical DialsCentral Gnomon Point. The field type of table
"sundial_types" contains the string Spherical Sundial: Hemisphe-
rical Dial--Central Gnomon Point.
References
All references are given by their BibTeX-keys in the bibliography

BAAP-BIB.bib. The LATEX-command \cite{BibTeX-key} is used to
mark the beginning of a BibTeX-key.
This convention is valid for any reference in any table of the
database.
Example: To refer to Sharon L. Gibbs. Greek and Roman Sundials. New

Haven and London: Yale University Press, 1976 with BibTeX-key
Gibbs1976, the string \cite{Gibbs1976} is used in the database.
The use of the string \cite{BibTeX-key} eases the full-text-search

for references and enables the use of LATEXwith BibTeX or BibLaTeX
and the bibliographies to which the BibTeX-keys belong.
Places
All place names are given in their national language. For countries
that do not use latin-based alphabets, a transliteration of the place
names is needed. In both cases the place names used by GoogleMaps
might help.
Example:
Roma is used for Rome;
In the national language Athens is called . In the database

Athina is used to transliterate the Greek .
Coordinates
The World Geodetic System 1984 (WGS 84) is used as reference co-
ordinate system of all coordinates stored in the database. Since this
coordinate system is also used by GoogleMaps and GoogleEarth,
both tools can be used to localize holders and sites of sundials.
In the database, values of latitude and longitude for all places are
given in decimal degrees. As decimal symbol a period is used. The
degree symbol is omitted. For places east to the prime meridian the
longitudes are stored as negative values. Since all places lie on the
northern hemisphere, there are no negative values for the latitude in
the database.
Example:
Athens lies at 37 580 N, 23 430 E; in the database, the value of the

latitude is 37.966667 and the value of the longitude is
23.716667.
Mrida lies at 38 540 N, 6 200 W; in the database, the value of the

latitude is 38.9 and the value of the longitude is -6.333333.
The use of the WGS84 as reference coordinate system enables

the use of tools like GoogleMaps and GoogleEarth as means for a
presentation of maps on the sundials within the web presentations of
the research project as well as the use of other GI-systems.
Transliteration of Greek Text in Inscriptions
Most inscriptions on sundials use the Greek alphabet. For the translit-
eration of Greek text the notation of the polutonikogreek-mode of the
babel-package of LATEXis used.
conventions 19
a b c d e f g h i j k l m n o p q r s t u w x y z

A B C D E F G H I J K L M N O P Q R S T U W X Y Z

Table 1: Greek letters in the polu-
tonikogreek-mode of the babel-package
The substitutions for Greek letters can be seen in table 1. There are of LATEX. Adapted from Frank Mit-
telbach and Michael Goossens. Der
also signs to reproduce Greek accents, acutes etc. (see tables 2 and
LATEX-Begleiter. 2nd ed. Mnchen et al.:
3). Pearson Education, 2005 p. 593.
acute a e h i o u w
dieresis "i "u "I "U
aspirated <a <e <h <i <o <r <u <w
not aspirated >a >e >h >i >o >r >u >w
grave a e h i o u w
circumflex ~a ~h ~i ~u ~w
period below a| h| w| w| w| >w| >w| <w| <w| Table
2: of Greek letters
Combinations
with spiritus and accent sign in the
To mark the beginning of a Greek passage or a single Greek word polutonikogreek-mode of the babel-
within a mixed text environment and to switch languages in LATEXthe package of LATEX. Adapted from Frank
Mittelbach and Michael Goossens. Der
command \selectlanguage{polutonikogreek} is used at the begin- LATEX-Begleiter. 2nd ed. Mnchen et al.:
ning of the Greek phrase. To mark the end and to switch languages Pearson Education, 2005 p. 593.
again, the command \selectlanguage{english} is used at the end of
the Greek passage. If a field in the database contains only Greek text,
the marking of the switch in the language is omitted.
>a >e >h >i >o >u >w Table 3: Combinations of Greek letters
with spiritus and accent sign in the
>A >E >H >1 >O >U >W 1
polutonikogreek-mode of the babel-
>a >e >h >i >o >u >w package of LATEX. Adapted from Frank
>A >E >H >1 >O >U >W 1 Mittelbach and Michael Goossens. Der
LATEX-Begleiter. 2nd ed. Mnchen et al.:
<a <e <h <i <o <u <w Pearson Education, 2005 p. 593.
<A <E <H <I <O <U <W
<a <e <h <i <o <u <w
<A <E <H <I <O <U <W
>~a >~h >~i >~u >~w
>~A >~H >~I >~U >~W
<~a <~h <~i <~u <~w
<~A <~H <~I <~U <~W
"i "i "u "u
Example: The transliteration of the Greek word is Ajhna.

Within a field that contains only Greek text, the transliteration is used
as it is. Within a text with mixed languages the markings of the be-
ginning and the end of the Greek passage are added. In these cases
the string \selectlanguage{polutonikogreek}Ajhna\selectlanguage{english}

is used in the database.
Labels of Quantities
Many standardized labels of quantities use subscripts or Greek let-

ters. In the database, the syntax for mathematical texts of LATEX is
used to reproduce all labels.
The substitutions for Greek letters can be seen in table 4.
Subscripts are generated by the use of _ between the letter and
the subscript. If there is more than one character in the subscript,
braces must be set ({ and }) to group the subscript. Braces are
used to group characters in case of multiple subscripts, too. There is
a difference between abc (a_{b_c}) and abc ({a_b}_c)!
\Delta \Gamma \Lambda \Omega \Phi

\Pi \Psi \Sigma \Theta \Upsilon
\Xi \alpha \beta \chi \delta
z \digamma e \epsilon \eta \gamma \iota
\kappa \lambda \mu \nu \omega
\phi \pi \psi \rho \sigma
\tau \theta \upsilon \varepsilon \varkappa
\varphi v \varpi $ \varrho \varsigma \vartheta
\xi \zeta Table 4: Greek letters in the mathemati-
cal mode of LATEX. Adapted from Frank
For fields that just contain a label, no sign is used to mark the be- Mittelbach and Michael Goossens. Der
ginning of the use of the syntax of the mathematical mode. If a label LATEX-Begleiter. 2nd ed. Mnchen et al.:
occurs within other fields the beginning and end of the mathematical Pearson Education, 2005 p. 543.
mode is marked by a dollar sign ($ $).
Example: The label e is stored as $ \xi_e $.
Values
All values are given as decimals. A period is used as decimal symbol.

In fields that do not contain other data than a single value the unit is
omitted. To guarantee uniformity in the database, the units are used
as described in table 5.
value unit Table 5: Units used in the database.

lengths mm
arcs decimal degree
latitude, longitude decimal degree
Example: As described above, the WGS84-coordinates for longitude
and latitude are given in decimal degrees. For Athens, which lies
conventions 21
at 37 580 N and 23 430 E (WGS84), the value of the latitude is

37.966667 and the value of the longitude is 23.716667.
Files
To render the database independent of the realisation of the storage

of the files of the additional materials, there is no information given
about the location where files are stored within the database. All
references to files are made by their name. Because of this, the names
of the files must be unique to the file.
As a convention, all files are named with a string of the form
OBJ????, where ???? means a number between 0 and 9999 which
is identical with the ID of the object the file belongs to. To discrim-
inate different files for a single object, there can be suffixes to the
name of the form _??, where again ?? is a number.
History
20120320, afternoon
Changes of the table "files" and new arrangement of the files.
20120320, morning
Backup of the database.
Autumn 2011
Adding of the table "references".
20110415
Changing of type of field dating of table "objects" to varchar(25).

20110411
20110401
Adding of field note to table "objects".

20110314
Start of data acquisition.
Till 20110310
Development of the database schema;

Implementation of the database schema;

Preliminary description of the workflow of data acquisition.
References
Gibbs, Sharon L. Greek and Roman Sundials. New Haven and London:
Yale University Press, 1976.
Mittelbach, Frank and Michael Goossens. Der LATEX-Begleiter. 2nd ed.
Mnchen et al.: Pearson Education, 2005.
Schaldach, Karlheinz. Die antiken Sonnenuhren Griechenlands. Festland
und Peloponnes. Frankfurt am Main: Verlag Harri Deutsch, 2006.
Severino, Nicola. Orologi solari Romani. 2003.
De Monumentis Gnomonicis apud Graecos et Romanos. 2005.
Severino, Nicola and Adam Shaul. Greek-Roman sundials catalogue.
2004.

The Database Sundials

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

The Database Sundials

Hochgeladen von

Copyright:

Verfügbare Formate

ELISABETH RINNER

The Database Sundials as a Means of Research 5

Data Structure and Database Schema 9

Purpose of the Database

providing a classification of the sundials;

providing data on the values of the parameters which are char-

providing information on additional materials (plans, photographs,

Data and Data Basis

of objects there can be additional types of sundials. Since very often

Gibbs, Schaldach and Severino focus on the dimensions of several

To enable research on the spread of the sundials we also include

Interoperability With Other Means and Other Requirements

The database Sundials should be implemented as a relational MySQL-

To gain a good interoperability with other means and other

The research on sundials is part of a larger project on scientific

Since GoogleMaps and GoogleEarth both use the World Geode-

To provide a better usability with other applications it is recom-

There are some properties that belong to a single sundial on an ob-

The relation between quantities and types of sundials is not re-

The Numbering by Gibbs

As an additional information on sundials there is an ID-number

Furthermore, the database stores information about additional (dig-

Figure 2: Database schema of the

As a result the database has the database schema shown in figure 2.

All tables in the database use the InnoDB-type. The collation is

field type attributes null default extra links to comments mime

field type attributes null default extra links to comments mime

In the implementation of the database on the server 141.20.159.95

field type attributes null default extra links to comments mime

In the implementation of the database on the server 141.20.159.95

field type attributes null default extra links to comments mime

In the implementation of the database on the server 141.20.159.95

field type attributes null default extra links to comments mime

In the implementation of the database on the server 141.20.159.95

field type attributes null default extra links to comments mime

field type attributes null default extra links to comments mime

In the implementation of the database on the server 141.20.159.95

field type attributes null default extra links to comments mime

In the implementation of the database on the server 141.20.159.95

field type attributes null default extra links to comments mime

In the implementation of the database on the server 141.20.159.95

field type attributes null default extra links to comments mime

Within the classification of sundials Gibbs makes up several main

Example: The type Spherical Sundials has a subtype called Hemi-

All references are given by their BibTeX-keys in the bibliography

Example: To refer to Sharon L. Gibbs. Greek and Roman Sundials. New

The use of the string \cite{BibTeX-key} eases the full-text-search

Roma is used for Rome;

In the national language Athens is called . In the database

Athens lies at 37 580 N, 23 430 E; in the database, the value of the

Mrida lies at 38 540 N, 6 200 W; in the database, the value of the

The use of the WGS84 as reference coordinate system enables

Transliteration of Greek Text in Inscriptions

Example: The transliteration of the Greek word is Ajhna.

the string \selectlanguage{polutonikogreek}Ajhna\selectlanguage{english}

Many standardized labels of quantities use subscripts or Greek let-

\Delta \Gamma \Lambda \Omega \Phi

mode is marked by a dollar sign ($ $).

Example: The label e is stored as $ \xi_e $.

All values are given as decimals. A period is used as decimal symbol.

value unit Table 5: Units used in the database.

at 37 580 N and 23 430 E (WGS84), the value of the latitude is

To render the database independent of the realisation of the storage