Taken from: R. M. Whiting (ed.). Mythology and Mythologies: Methodological Approaches to Intercultural Influences. Melammu Symposia 2. Helsinki 2001, xvii-xxv.

N.B.: Even though the database still largely functions as described below (but is outdated on some important points; cf. the General Description of the Melammu Database), please bear in mind that it is not necessary to read this text to be able to consult the database or submit entries. The search engines and submit form all speak for themselves; the inclusion on this website of the text below is intended for those who are interested in the way the database works technically.

The Shape of the Database

by R. M. Whiting

As a result of the initial discussions about the format of the Melammu Database and what it should contain and subsequent investigations of the current state of the database art, the overall form of the database and the format of entries have begun to take a firm shape. The database is, of course, a work-in-progress and as such it is subject to more or less constant revision and improvement. But while the content of the database will always be a work-in-progress, the format should quickly become more or less fixed.

There will be two principal types of entries in the database. The first consists of citations from ancient texts. These entries are primary sources and consist of the ancient author's comments. Such entries have a "source" line which points to the ancient text and the <Text> field contains a translation of the ancient source. There may be bibliographical citations as well if the passage has been discussed or commented on by other scholars. Wherever possible, there will be a hypertext link to the actual text of the ancient source. Another type of primary source information will be ancient texts that illustrate some linguistic feature that has been transmitted to another language. In this case the entry contains simply raw data and will be linked to the corresponding feature through the headings or through keywords.

The second type of entry consists of modern comparisons between features or phenomena in the ancient world that may show the effects of cultural contact or cultural diffusion. Entries of this type generally have a "bibliography" line that points to the scholarly assessment of this connection rather than a "source" line. However, if ancient sources are important for this connection, there may be a "source" line as well. The <Text> field will contain an outline of the argument connecting the features or phenomena.

Both types of entries may have additional hypertext links that provide background information on ancient authors, sites, languages, or documents. Each entry may contain illustrations, either as part of the entry itself or as links to outside sources.

A database entry is defined by the following SGML-type tags:

<Entry>
<Number>
<Topic>
<Keywords>
<Period>
<Channel>
<Heading>
<Summary>
<Text>
<Links>
<Source>
<Bibliography>
<Graphics>
<Verification>
<Remarks>
<Contributor>

Each of these tags has a clearly defined function. Some tags are required and some are optional (in entry format). These tags serve as the field separators and identifiers for the database entry format. Some tags (fields) are restricted as to the amount or type of information that they can contain. Some tags (fields) may be empty even though the tag is required (usually for processing simplicity). A brief summary of the use of each tag (field), including its basic parameters follows.

<Entry>
Tag: required.
Field Restrictions: 0 lines.

No text can intervene between the <Entry> tag and the next tag. If any text is included in this tag it will be lost. This tag serves as the record separator for the database entry format. The software uses this tag to cycle through the entries and it serves no purpose except to indicate the beginning of a new entry; but this purpose is vital.

<Number>
Tag: not required.
Field Restrictions: 0 - 1 line.

No more than one line can follow this tag. The content is immaterial. The field is provided as a means of keeping track of individual entries locally. The information in this tag is discarded and has no significance for the central database. A sequential number is assigned to each database entry by the software after the entries have been sorted each time the database is updated. Thus a database entry's sequential number may change each time something new is added to the database.

<Topic>
Tag: required.
Field Restrictions: 1 - unlimited lines;
1 entry per line.

Any number of topics may be included in a single entry so long as each is relevant to the entry, but at least one topic must be included. Each topic should be entered on a separate line. The topics should be copied from the current topic list to ensure that the topic in the list and the topic in database entry are identical. Manual entry leads to errors. Since the software matches the topic in the entry to the topic in the list, the two must be identical. DO NOT copy the hierarchical numbers that identify the topic in the topic list into the database entry. These numbers are subject to change as the topics list is adjusted and cannot be used to identify topics in database entries.

Duplicate topics in topics list: There are a number of places in the topics list where the same topic appears in different branches of the topics list's hierarchical tree. Such duplicate topics are identified by a number in parentheses at the end of the topic. DO copy this number as part of the topic into the database entry. The first duplicated topic has a (1) at the end as a flag that there are more identical entries. When you encounter a topic that is flagged in this manner, make sure that you select the topic that is in the appropriate branch of the topics tree to copy into the database entry.

Multiple topics in the same branch: It is not necessary to copy topics that are at a higher level in the particular branch of the topics tree than the topic selected into the database entry. The software will automatically associate any topic with all higher level nodes in that branch. On the other hand, it does no harm to include higher-level topics, it simply is not necessary.

Unlisted topics: If there is no topic in the list that seems appropriate, simply create a new topic for the database entry. The software will flag this as an unlisted topic and the database manager will adjust the topics list to include the new topic. This may be done also if the entry relates to an already existing topic but also relates to a topic that is not included in the list. DO NOT use semicolons (;) in topics as this will conflict with the processing software. If punctuation is needed in a topic, use a comma, colon, or dash.

<Keywords>
Tag: required.
Field Restrictions: 1 - unlimited lines.

At least one keyword should appear with each database entry. Keywords are selected for purposes of information retrieval and should be words or phrases that have particular relevance to the database entry. They may be personal or geographic names or topics that the entry is concerned with (even though they might not appear in the text of the entry itself). Only nouns and noun phrases are used as keywords. Verbs that are used as keywords should be in the form of gerunds (e.g., "weeping", "watering", etc.). Adjectives may appear as modifiers in phrases. Gentilic adjectives appear as collectives in the plural. Thus "Assyrian" should not be used as a keyword, but "Assyrians" may. However, "Assyrian" may appear in noun phrases such as "Assyrian language" or "Assyrian religion." To determine whether a keyword exists or not, use the index of keywords. However, the fact that a keyword does not previously exist does not affect its introduction. The number of keywords is not limited.

Individual keywords must be separated by commas if they are on the same line. Words not separated by commas will be treated as a single keyword. Only commas or spaces should be used between words (i.e., no other punctuation [including parentheses and brackets]). Keywords may be entered in any order and will be sorted by the software.

<Period>
Tag: required.
Field Restrictions: 1 - unlimited lines;
1 entry per line.

Each entry must be assigned to a period. It is not necessary that the period appear in the list of periods. If it does not, the software will flag it as unlisted. If the database entry has sources from more than one period, each period should be listed, earliest first. The period is used by the software to sort entries with identical headings (only the first period listed is used). Enter each period on a separate line. DO NOT use semicolons (;) in periods as this will conflict with the processing software. If punctuation is needed in a period name, use a comma, colon, or dash.

<Channel>
Tag: required.
Field Restrictions: 0 - unlimited lines;
1 entry per line.

It may not be possible to identify a channel of transmission for an entry, but the tag is still required. If no channel can be identified, simply continue with the next tag (i.e., leave the field empty). If a channel is assigned, it is not necessary that it appear in the list of channels. If it does not, the software will flag it as an unlisted channel. More than one channel may be entered if appropriate. Enter each channel on a separate line. DO NOT use semicolons (;) in channels as this will conflict with the processing software. If punctuation is needed in a channel name, use a comma, colon, or dash.

The <Channel> tag is required so that the software can find the heading in order to sort the entries. It would be possible to do this if the <Channel> tag were missing, but it is a lot easier this way.

<Heading>
Tag: required.
Field Restrictions: 1 line.

Each entry must have one and only one heading. Different entries may have the same heading in which case the software will number them sequentially after sorting them by period. The heading is used as the primary sort criterion for the database entries.

<Summary>
Tag: not required.
Field Restrictions: 0 - unlimited lines.

The summary can function in several different ways depending on the basic type of database entry. For discursive entries, it is meant to serve as its name implies: as a summary or abstract of the more extensive discussion in the <Text> field (see below). For primary source entries, it can serve to summarize the significance of the source, to provide interpretative nuances to the translation, or to paraphrase the translation of the source into clearer or more succinct language.

At the present time, the summary is limited to one paragraph. Separate paragraphs may be included, but the software will combine them into one.

At the present time, the <Summary> field is not searched by the string search engine.

<Text>
Tag: not required.
Restrictions: 0 - unlimited lines.

The <Text> field is the meat of the database entry. There are two principal types of entries in the database, primary and secondary. The first consists of citations from ancient texts. These entries are primary sources and consist of the ancient author's statements and comments or raw linguistic data. Such entries have a <Source> entry (see below) which points to each ancient text cited and the <Text> field will contain a translation of the ancient source. Wherever possible, there will be a hypertext link (through the <Source> field) to the actual text of the ancient source. There may be bibliographical citations (see below) as well if the passage has been discussed or commented on by other scholars. For this type of entry, the <Summary> field should be used to provide a paraphrase or explain the context of the source.

The second type of entry consists of modern comparisons between features or phenomena in the ancient world that may show the effects of cultural contact or cultural diffusion. Entries of this type generally have a <Bibliography> entry that points to the scholarly assessment of this connection rather than a <Source> entry. However, if ancient sources are important for this connection, there may be a <Source> entry as well. The <Text> field will contain an outline of the argument connecting the features or phenomena.

At the present time, the <Text> field is the only field that allows multiple paragraphs. To begin a new paragraph, put two (2) blank spaces at the beginning of the line. The software will interpret these two blank spaces and create a new text field in the database storage format. It is not necessary to put a blank line between paragraphs (you can, but the software will simply ignore it).

The <Text> field is presently the only field that is searched by the string search engine. For this reason, it makes little sense to leave the <Text> field out of a database entry. There are instances where the text of an ancient source may not be available (as when it is referred to obliquely by another ancient author) and it may seem more appropriate to place the indirect source in the <Summary> field rather than the <Text> field. Such situations should be avoided. The indirect source should be placed in the <Text> field, and the situation should be explained as briefly as possible in the <Summary> field.

Obviously, it makes little sense to create a database entry with both the <Summary> and <Text> fields empty.

<Links>
Tag: not required.
Field Restrictions: 0 - unlimited lines;
1 entry per line.

The <Links> field is used for hypertext links to external sites. Such sites should provide supporting information for the text of the database entry, including, but not limited to: Enclyclopaedia articles or websites describing or explaining the document(s) cited; Biographies or identifications of the ancient author(s) cited; Maps or descriptions of sites mentioned in the <Text> or <Summary> fields; pictures on the web that illustrate some aspect of the database entry but that are not controlled by the Melammu Project.

Each entry in this field consists of 3 required elements: (1) a URL to the exact location of the external site, (2) a plaintext description of the content and identification of the site, (3) a semicolon (;) separating the two.

The URL must be complete and point to the exact location of the web page to be linked to. The easiest way to ensure this is to load the desired web page into a browser and then simply copy the URL and paste it into the <Links> field of the database entry.

Each hypertext link must be on a separate line in the <Links> field. The software will create a separate link field in the database storage format.

<Source>
Tag: not required.
Field Restrictions: 0 - unlimited lines;
1 entry per line.

The source field contains references to the sources cited in primary source entries. The source may be an ancient author, a cuneiform text, a papyrus, a biblical reference, and so on. Each source citation must be on a separate line.

Source citations should be in a standard format as recognized by the discipline where the source is at home. Each occurence of the same source in different database entries should be the same. A separate file will keep expanded source references that will specify the edition, translator and publication data of the specific source being cited. The contributor of the database entry must provide this information for the source being cited.

If the source is available on the web, either in the original or in translation, a hypertext link should be provided to the source. When there is a source available for linking, the source line should have the same format as a comparable line in the <Links> field (see above). This consists of the following three required elements: (1) a URL to the exact location of the souce, (2) a standard reference to the source, (3) a semicolon (;) separating the two. All this information must be on a single line.

Although most current browsers do not require the "http://" header for URL's, this header must be present at the beginning of the source URL (although it is not required for URL's in the <Links> field) because the software recognizes the presence of a URL by keying on this header (this is not required in the <Links> field because a link must contain a URL).

If the source cannot be linked to, then only the standard source citation is required.

Although the <Source> tag is not required, primary source database entries must have a source citation. In this way, the <Source> tag and the <Bibliography> tag (see below) are in a sort of complementary distribution. Even though neither is required, and although both may be present in a database entry, one or the other must always be present.

<Bibliography>
Tag: not required.
Field Restrictions: 0 - unlimited lines;
1 entry per line.

The bibliography field contains references to discussions of the material found in the text field of secondary source database entries. In addition it may contain references of discussions of the cited source in primary source entries. Bibliographic entries must be in complete bibliographic style and it is the responsibility of the contributor of the entry to ensure that the bibliographic reference is complete and correct, including specific page numbers referring to the discussion in the database entry.

The bibliographic references will be presented in an abbreviated format (scientific style) in the web display of the database entry with a mechanism provided to expand the abbreviated reference to the full bibliographic citation.

Bibliographic references will not normally be linked to other web sites.

Secondary source database entries must have a bibliograpy (a minimum of 1 entry in the <Bibliograph> field) that provides documentation for the text of the database entry. If ancient sources are included in the argumentation, these should be included in the <Source> field.

Although the <Bibliograpy> tag is not required, primary source database entries must have a source citation. In this way, the <Bibliograpy> tag and the <Source> tag (see above) are in a sort of complementary distribution. Even though neither is required, and although both may be present in a database entry, one or the other must always be present.

<Graphics>
Tag: not required.
Field Restrictions: 0 - unlimited lines;
1 line per entry.

The graphics field contains information about pictures and other illustrative material that are available on the Project's website on on another site that is controlled by the Melammu Project. Such graphics may be pictures, maps, graphs, or the like that illustrate some aspect of the database entry.

Only graphics that are physically located on Project controlled websites may be used in this field. Graphics that are located on, or accessed through, other websites must be entered in the <Links> field.

Each graphics reference consists of the following three required elements: (1) The name and location of the graphics file, (2) a plaintext caption that explains the graphic and its significance for the database entry, (3) a semicolon (;) separating the two. All this information must be on a single line.

The graphics file must be in a format that can be displayed in-line by a web browser. It must have the extension .jpg, .jpeg, or .gif. If the image file is located on the Project's home site, only the name of the file is needed. If the image file is located on another site, the URL of the file must be provided.

The software will assign a sequential figure number (Fig. 1, etc.) to each entry in the graphics field based on the order in which the graphics entries occur. In this way, the illustrations may be referred to in the discussion in the <Text> field.

Care should be taken about the size of graphics files. Large grapics files can take a long time to load in many browsers depending on the type of connection to the Internet. Images more than about 500 pixels in width are difficult to fit into the present format provided for the web display. Larger images should be reduced by the contributor either by cropping or by scaling. If the contributor of the image does not undertake this, the database manager will use his own judgement.

Care must be taken not to use copyrighted images. In-line images must be either self-created (and not by scanning a copyrighted image), released by the copyright owner, or in the public domain. This is why images at other web sites cannot be used in-line but must be linked to. If the image has been released by the copyright owner but requires acknowledgment as a condition of release, the caption should end with "\\(image courtesy ...)". The "\\" will generate a line break and the "(image courtesy" will cause the text to be in a smaller font size. Nothing else may come after this remark.

<Verification>
Tag: required.
Field Restrictions: 1 - unlimited lines;
1 line per entry.

This field is for internal administrative purposes, but it may become part of the web display. The verification field will contain a history of the entry. The first entry will be the date of submission (first compilation) which will be entered by the software the first time the entry is processed. Other entries will record dates of verification by Project consultants and dates of major revisions.

<Remarks>
Tag: not required.
Field Restrictions: 0 - unlimited lines.

This field is meant to be a means of storing memoranda about the entry and of communicating information and ideas about the entry. It can be used for messages from the contributor to the database manager, from the database manager to himself or to consultants, from consultants to the database manager or among themselves. This field is intended for internal Project use and will never be seen by the general public.

The format of this field will be exactly the same as the <Text> field (see above). Each entry in this field should be signed (at least initialed) by whoever makes it.

<Contributor>
Tag: required
Field Restrictions: 1 - unlimited lines;
1 entry per line.

Each database entry must have a contributor. No anonymous or unsigned entries will be accepted. Normally, the contributor will be the person who creates the entry. The contributor should provide an e-mail address that will be used to create a "mail to:" link in the web display of the database entry. The e-mail addresses of the contributors will be kept in a separate file and the link will be created by the processing software.


Summary of tag (field) parameters

Required tags:
<Entry> (must be empty)
<Topic>
<Keywords>
<Period>
<Channel> (may be empty)
<Heading>
<Verification> (left empty by contributor)
<Contributor>

Optional tags:
<Number>
<Summary>*
<Text>*
<Links>
<Source>*
<Bibliography>*
<Graphics>
<Remarks>
[any optional tag (field) may be present but empty]

Complementarily required tags:
Either <Summary> or <Text> must be present (entries without a <Text> field should be avoided).
Either <Source> or <Bibliography> must be present.

Tags (fields) that (presently) appear in the web display:
<Period>
<Channel>
<Heading>
<Summary> (if not empty)
<Text> (if not empty)
<Links> (if not empty)
<Source> (if not empty)
<Bibliography> (if not empty)
<Graphics> (if not empty)
<Contributor>
[the <Verification> field may be added to the web display]

Tags (fields) that (presently) are used for database entry retrieval:
<Topic>
<Keywords>
<Text> (if not empty)
[eventually <Periods> and <Channel> will be used for retrieval]


Database text entry

General Comments on Text Entry
All database text will be 7-bit ASCII text with no control characters (decimal 032-127). Tab characters (^I, decimal 009) will not be used. All other characters will be entered as unicode code groups with the format "\uxxxx" where "xxxx" is the four-digit hexadecimal unicode code for the character. The easiest way to accomplish this will be with a unicode-compliant text editor such as SC-Unipad (available at http://www.unipad.org/main/). Such applications will allow you to see the correct characters on-screen but will save them as unicode sequences. Those who cannot use a unicode-compliant text editor will have to enter the unicode sequences by hand without being able to see them on-screen. The potential for making mistakes in this environment is so great as to make it worthwhile, if not imperative, to use a system that allows unicode-compliant applications. Using 7-bit ASCII characters for all text is essential because it makes database entries completely platform independent. Database entries must be submitted as plain 7-bit ASCII text without proprietary word processor formatting. In addition, some database fields require that each entry in the field be on a separate line. Word processors that automatically wrap lines cannot be used to do this (unless the file can be saved as ASCII text with soft line breaks removed).

Unicode Characters
All special characters that fall outside the range given above (decimal 032-127) will be entered as unicode sequences. This includes characters for which there is presently an extended-ASCII character available. For example, the characters ä, ö, and ü will be entered as \u00eb, \u00f6, and \u00fc, respectively. Even some characters for which a 7-bit ASCII character is currently used will be entered as unicode sequences. For example, the character ' (apostrophe) is used for alif (´), and for the prime marker (e.g., 1´, etc.) When <' represents alif, it will be entered as \u02d2, and when it represents the prime marker it will be entered as \u2032. Single and double quotation marks, ellipsis, and em- and en-dashes can also be entered as unicode sequences, but at present this is not required. Basically, though, you can't go wrong by entering the unicode code.

For fields that appear in the web display, a subroutine converts the unicode codes into the nearest HTML equivalent when the html files are created. The unicode codes remain in the database. When we have unicode-compliant web browsers, the conversion subroutine will simply be eliminated.

Local formatting
To eliminate the potential for conflict between HTML tags and the SGML-type tags used for the database entry format, no HTML tags may be used in the database. In order to take advantage of HTML formatting tags, a number of arbitrary formatting conventions have been established. These formatting conventions will be augmented as the necessity arises.

The conventions provided thus far are: