2. The basic structure of AAF data

An AAF database is a text file containing a sequencial stream of records which are made up of one or more chunks. A record begins with an #A93 chunk followed by an any number of subsequent non-#A93 chunks. Every chunk begins in the leftmost column of a new line with a number sign and a chunk ID (for example #A93) followed by a colon `:' and one or more chunk data fields which are separated by commata.

Here is a beautiful example record:

#A93:Ferber,Tobias,m,27.9.1970,11:04,Kandel/Pfalz,D
#B93:*,49n05,8e11,1he,0
#ZNAM:CET

Note that you can use an asterisk `*' in all fields of a chunk if the correct field value is unknown. Note also that all fields can have leading and trailing white space White space is ment in the sense of C and POSIX locales, so these are: space, form-feed, newline, carriage return, horizontal tab and vertical tab. which is must be ignored by an application when reading AAF. Obviously, none of the comma separated fields can contain commata!

In the following sections we will now describe the meaning of the fields in the officially defined chunk types.

2.1 The #A93 chunk: Human readable chart-info data

This is the only required chunk in an AAF record. It also must be the first chunk of an AAF record, so a valid record can theoretically consist of a single #A93 chunk and nothing else however, full charts are usually not computable for such a record.

A chunk of type #A93 has 7 fields (0..6) with the following meanings:

0 Name

This name field holds the last name of a person or the title of a chart for an institution or an event. As all the other fields, this field must not contain commata.

1 First name

This field is only used for natal charts. Institutions and events usually have no first name so this field can be left empty for them.

2 Type (sex)

The sex field contains either `m' for male, `f' or `w' for female, `e' for events, `l' (ell) for a country and `o' (oh) for organizations and institutions.

3 Date

The date field holds a calendar date in day.month.year order, ie. from the smallest to the largest unit in ascending order. A period `.' must be used to separate day, month and year. The year must be given including the century.

An optional `g' or `j' can be appended to the year to force the Gregorian or Julian calendar respectively. If neither `g' nor `j' are appended, dates before October 15, 1582 are assumed to be in the Julian calendar, the Gregorian calendar is assumed otherwise.

Years BCE must be given astronomically ie. as a negative number counting from zero (1BCE). For example, 4 BCE must be given as -3.

Here are some examples:

  23.10.1966   24.12.-6g   7.10.1582j 

4 Civil time

The time field holds the birth time in hour:min:sec order, ie. from the largest to the smallest unit in descending order. A colon `:' must be used to separate hours, minutes and seconds. The letter `h' can optionally be used instead of the colon to separate hour and minutes. The presence of minutes and seconds is optional.

Here are some examples:

  16:55  22h30:12  19h  23:59:59

5 Place

The name of the place.

6 Country

The country abbreviation including an optional state code.

2.2 The #B93 chunk: Machine readable chart-info data

The #B93 chunk is required for a record to be computable. It entirely contains information which can be derived from the data given in the #A93 chunk.

A chunk of type #B93 has 5 fields (0..4) with the following meanings:

0 Julian Day

This field contains the Julian day plus a time fraction relative to noon, Greenwich time. The Julian day represents the number of days since epoch JD = 0.0 on January 1, -4712 (ie. 4713 BCE), 12:00 noon.

This field is optional since it can be determined very easily by a computer from the birth date, time, time zone and time type. We thus recommend using an asterisk `*' as a default value for this field. There are however some rare occasions (eg. when a source only gives the Julian day) in which case the date and time fields should contain an asterisk `*' in order to avoid ambiguities.

Note that if there is a legal value (not an asterisk) given in this Julian day field, then it has always precedence over the values in the date, civil time and time type fields!

1 Latitude

This field contains the geographic latitude of the place name given in the #A93 chunk. The latitude must be given in degrees, minutes of arc and seconds of arc. The degrees must be separated from the minutes using `n' for northern latitudes and `s' for southern latitudes. As in the time field of the #A93 chunk, seconds are optional and if present have to be separated from the minutes using a colon `:'.

Here are some examples:

  48n46   15s53:03   0:00  

2 Longitude

What has been said about the latitude field applies to this geographic longitude field as well, except that `e' must be used for eastern longitudes and `w' for western longitudes.

Here are some examples:

  9e10   74w54:45   0:00

3 Greenwich time offset

This field usually holds the time zone offset, ie. the difference in hours and optional minutes and seconds from Universal Time (UTC) without (!) daylight time. Note that some countries used the local time of their capital before the introduction of our current time zones. In those cases (time type `m') this field must contain the time difference of capital's local time to Greenwich time. In case of local mean time (time type `L') this field should contain a single asterisk `*'. It's value can be computed easily from the geographic longitude.

The format is similar to the time field in the #A93 chunk but `he' must be used to separate hours from minutes for time zones or meridians east of Greenwich and `hw' for time zones or meridians west of Greenwich.

Here are some examples:

  1he   5hw00   0h   0he32:06

4 Time type

This field must contain `0' (zero) for standard time, `1' for daylight savings time, `w' for war time (technically same as daylight saving), `2' for double daylight savings time (2 hours), `h' for half hour daylight time, `L' (ell) for local mean time, and `m' for a special time meridian (eg. the capital's local time).

Note that the times types `1' and `w' are technically the same. So are `0' and `m'.

In case of local mean time `L' the GMT offset field is not required if a longitude is given. We thus recommend using an asterisk `*' in the GMT offset field in this case to avoid ambiguity.

2.3 The #SRC, #VIA and #COM chunks: Annotations

These chunks are not split into fields, so commata have no special meaning in these chunks.

The #SRC and #VIA chunks contain information about the source of the data in their record. The #VIA chunk contains the name of the person who did the resarch for this data or the title of the publication where the data has been taken from. The #SRC chunk on the other hand describes the kind of source this person found (eg. the birth certificate).

The #COM chunk contains additional information about the chart which does not neccessarily need to be related to the information in #SRC or #VIA. The #COM chunk is just mentioned here because it is not split into fields as well.

2.4 The #ZNAM chunk: The time zone abbreviation

This chunk has one single field which holds the name of the time zone or the time zone abbreviation. As of yet there is no official standard which defines all time zone abbreviations. RFC822 defines only the time zone names UT, GMT, EST, EDT, CST, CDT, MST, MDT, PST, and PDT.

2.5 The invisible #: chunk

This chunk type is completely ignored by an AAF reading application. Nevertheless such chunks can be extremely useful eg. for debugging purposes or as a separator between different types of records in a database. These chunks are of course visible in a text reader only.

It is a good idea to place a #: chunk at the end a record which you want to submit via email or in a Usenet posting. Like that, everything following the AAF data is completely invisible to an application. Everything before the first #A93 chunk is ignored automatically.