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:CETNote 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 spaceWhite 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.
#A93
chunk: Human readable chart-info dataThis 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.
#B93
chunk: Machine readable chart-info dataThe
#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.
#SRC
, #VIA
and #COM
chunks: AnnotationsThese 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.
#ZNAM
chunk: The time zone abbreviationThis 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.
#:
chunkThis 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.