Copyright: 'Describe' && 'Identify' -- Copyright © 1995-1999 G. Hagedorn  BBA, Germany. -- Date of last change:   Saturday, July 31, 1999 19:57:02
Citation: 'Describe' & 'Identify' - Copyright © 1995-1999 G. Hagedorn, BBA, Germany


Contents
 DeltaAccess: 'Describe' & 'Identify'
A SQL interface to DELTA (Description Language for Taxonomy), implemented in Microsoft Access

User Guide and Documentation

Copyright G. Hagedorn    Version 1.6.    Date of last change: 31.07.99

Main Table of Contents

First steps
   Overview
   Requirements
   Installation
   Conditions of use and acknowledgments
   Revision history

Introduction
   Introduction
   Concepts of structured data storage
   Single versus multiple projects
   Strategy and future development of DeltaAccess
   Database subsystems
   Software architecture of DeltaAccess
   DELTA software sources on the internet
   The Switchboard
   Introduction to the main DeltaAccess dialog box

Import and Export of DELTA Files
   Importing data
   Which DELTA files should be imported?
   What happened to the character name during import?
   What happened to my units?
   Importing subsets (include/exclude items/characters)
   Exporting data
   Creating natural language item descriptions
   Creating item descriptions as HTML forms
   Re-importing data posted by item descriptions HTML forms

Project Management
   Managing projects
   Creating new projects
   Subsets
   Character subsets
   Item subsets
   Overwriting project data
   Appending data to a project
   Backup and restore

Data Analysis
   Analyzing data
   Printing the analyses
   Analyzing parts or subsets of your data
   Using Access query design (QBE editor)
   Creating a cross-tabulation or pivot analysis in Excel
   Frequency distribution (histogram) of numerical characters
   Comparing characters with external classifications
   Summarizing items
   List of all analysis queries and reports available
   Analysis queries provided
   Analysis reports provided
   Analysis charts/graphs provided

Editing, basics
   Editing overview
   General hints on Windows operations
   The Windows clipboard
   Introduction to working with Access forms

Editing, project data
   Editing the item definition (ItemEdit-form)
   Editing multiple items simultaneously (MultiItemEdit-form)
   Editing the character definition (CharEdit-form)
   Editing character headings
   Editing link groups
   Reorganize definition (characters, states, headings, or items)
   Editing project properties

Editing, special topics
   Calculated characters
   Mapping character states (key states)
Interactive identification
   Introduction to interactive identification
   Identify in comparison with other identification software
   DELTA based interactive identification outside the realm of taxonomy
   Interactive identification: The Identify dialog box
   Compiling a project for interactive identification

Appendix 1: Advanced database administration information
   Fingerprinting data sets
   Securing an Access database
   Repairing a corrupted Access database
   Linking to other data sources
   Linking to other database subsystems
   Merging descriptor projects (data sets)

Appendix 2: Development documentation
   Limitations
   Recognized DELTA directives
   General development information
   Co-development issues
   Multi-language support

Appendix 3: Information model and data dictionary
   The information model of DeltaAccess
   List of entities and attributes
   Detailed attribute information
   Introduction to the concept of modifiers

Appendix 4: References, Glossary
   Literature references
   Glossary of terms and procedures

Next


 Overview

 DELTA and DeltaAccess:

•	DELTA (Description Language for Taxonomy) is a powerful data exchange format used by several important taxonomic software packages. It can be used to analyze taxonomic data, create natural language descriptions, or generate printed as well as interactive synoptic keys. DELTA was first introduced by Mike Dallwitz in 1973. The International Taxonomic Database Working Group (TDWG, a section of the IUBS) has endorsed the basic directives of DELTA as an international data standard.

•	Existing DELTA software packages operate as closed systems, interacting with other software through import/export procedures alone. Export functions to industry standard analysis and reporting tools (relational databases, spreadsheets, statistical analysis software) are usually very limited. It is not possible to link data from other sources (like nomenclatorial, specimen, or literature reference databases) with the DELTA data.

•	In contrast, DeltaAccess is designed to enable live data interchange with standard PC and internet applications like databases and web servers, using industry standard software interfaces (SQL, ODBC, DCOM). The reliance on industry standards lets taxonomists benefit from programming efforts undertaken primarily for business applications. Considering the limited resources available to the scientific and taxonomic community, it would probably not be possible to implement features like multi-user operation, data security models, or database replication in a dedicated taxonomic software.

 Using a database for descriptive biological data:

•	Descriptive taxonomic or systematic work is best done within a framework of integrated databases, combining raw observational/experimental data, and reviewed/summarized data with nomenclatorial, literature reference and specimen collection database subsystems. The aim of this release of DeltaAccess is to show that DELTA data can be accommodated within a standard relational database. DeltaAccess does not yet provide an integrated database environment. Neither is it a 1:1 port of the DELTA format into a database: Making some features of DELTA compatible with structured data storage imposes certain limitations on the data. On the other hand, observing the necessary data integrity rules opens up new possibilities for data analysis and verification of data integrity.

•	DeltaAccess makes DELTA accessible to the world of relational databases. It is a Microsoft Access based application that provides a complete environment to import, edit, analyze, and export descriptor projects. The source code is included and distributed free of charge under a General Public License. To run DeltaAccess, you must have Windows 95 or NT 4.0, Microsoft Access 97, and a computer with at least 16 MB RAM. (One of the next versions of DeltaAccess may be distributed together with a run-time version of Access.)

•	Microsoft Access is a relational database, which uses SQL (Structured Query Language). It can link (read and write directly) to most other relational databases on the PC market (Paradox, dBase, FoxPro, and any database for which ODBC drivers are available) and to most SQL-Servers (Microsoft SQL Server, Oracle, Sybase, Interbase, etc.). DeltaAccess can directly be used on a single PC or in a local area network with 20-200 concurrent users. To serve wide area networks with many more users, the data can be migrated to a SQL database server and DeltaAccess can be used as a front end application. In both cases, different user groups can be provided with different views (subsets) of the data. Subsets can focus attention on the relevant data or protect security relevant parts of the data set.

 Usage of DeltaAccess:

•	DeltaAccess can be used in 3 ways:  a) You can use DeltaAccess simply as a module to import DELTA coded text files into a database of your choice and then write an independent application for that database (e. g. a web interface).  b) You can keep your data in DELTA coded text files, and use DeltaAccess as a one-way import tool to analyze your data (incl. cross-tabulations, and charts), print form sheets to edit your data off-line, or to generate dynamic html/www output.  c) You can use DeltaAccess as the central data repository around which your work is organized. You can thus make full use of advanced editing functions of DeltaAccess, like the multiple item editor. Other DELTA compatible applications can still be used to take advantage of certain functions which are either lacking in DeltaAccess or which they perhaps perform better (e. g., printed keys, better natural language description, other identification tools). DeltaAccess exports as much information as possible back to DELTA coded text files, even where DELTA falls short in the support of advanced features.

•	DeltaAccess has already been used to analyze large data sets (G. Rambold, Univ. München, Genera of lichenized and lichenicolous ascomycetes) and to teach DELTA courses. Interfaces for interactive identification and data retrieval over the internet are available and currently being revised.

 Shortcomings:

•	Since a DELTA-editor was not the principal design aim, you may find the item editor slightly slow. Further, the formatted natural language output and the interactive identification Identify should be considered technology previews rather than final products. Finally, neither images nor character mapping ("KeyStates") are fully supported. Full support of images can be expected with the next major release of DeltaAccess. The generation of printed keys is currently not planned.

•	A word of caution: I consider DeltaAccess a useful tool for myself, which I use to explore the possibilities and limitations of existing approaches. I make this tool available free of charge because I think it can be useful to other people as well, but neither the application nor the documentation attempts to compete with commercial software products. You can expect those functions which are available to be reasonably bug free, but many desirable functions may yet be missing, and the documentation may be out of date and lengthy. Please consider this an academic exercise, to which you can contribute by reporting errors or shortcomings, or even by contributing to the development of DeltaAccess.

•	This user guide and documentation is available in HTML and in Windows help format. Both versions are identical. HTML allows you to read or print the documentation using your www-browser. The help file is context sensitive (press F1 while you are working with DeltaAccess to obtain help), and offers both improved browsing functionality and a full text index.

Copyright G. Hagedorn    Version 1.6.    Date of last change: 31.07.99

Main table of contents    [image] Next


 Requirements

Software: This utility is distributed free of charge, including the source code (see Conditions of use). It is not, however, a stand-alone application. To run DeltaAccess you must have Windows 95 or Windows NT 4.0 and Microsoft Access 97 (= Access version 8) installed on your computer.

A run-time version of Microsoft Access exists, but I do not have a license to supply it. Since DeltaAccess is designed to help you manage your data in the context of the standard Microsoft Access database functionality (like the ability to create your own queries, forms and reports, which is not part of the run-time version) a run-time version is of limited value. Nevertheless, some work has been done (e.g. the Switchboard form) to allow DeltaAccess to function under a run-time version in the future.

Hardware: Microsoft Access is a resource hog (even Microsoft acknowledges that!). I recommend at least 16 MB RAM under Windows 95 and 32 MB RAM under Windows NT 4.0. DeltaAccess itself consists largely of VBA/DAO code. It could thus be ported to the less memory demanding Visual Basic, but I will not be doing this. Since the price of 16 MB RAM has fallen below the price of a single scientific book, I do not consider it worth the effort and problems of parallel development. Anyone volunteering to do so is welcome.

Size of database files: Microsoft Access databases can become quite large. In general, the mdb-file is about 8 times as large as your DELTA text file, plus the base-size of the application plus ca. 0.5 MB/project for the forms you usually create. This will be the compressed size, Microsoft Access uses more space during operation. For example with an 800 kB import file, you should have 15-30 MB available on your hard disk. This should not be a problem with today's large hard disks.

Speed: Most of the development and testing is still done on a computer with a 486 processor at 100 MHz. Faster processors are nicer, of course, especially as the import process is relatively slow. Import takes about 1 minute for setup (creating tables, relations, and forms), plus a data set size dependent time of about 1 minute per 100 kB (on a Pentium 100 MHz). You need only import your project once, however; subsequently you can just open the database and edit or analyze it. Microsoft Access is a database that performs many operations on the hard disk, whereas other specialized programs perform such operations in the much faster RAM memory. The advantage is that your data sets can become much larger when using a database.

See the chapter Software architecture of DeltaAccess for a discussion of the advantages of using a relational database and the advantages and disadvantages of using Microsoft Access.

Main table of contents    [image] Next


 Installation

DeltaAccess is distributed as a self-expanding compressed file. To install, simply execute the downloaded file (e. g. double-click on it in the Windows Explorer) and follow the prompts. All files should be kept in the same directory. It is advisable to create a new directory into which all files from the self expanding archive are written.

There is no need for further installation of DeltaAccess if Microsoft Windows 95/Windows NT 4.0 and Microsoft Access have been properly installed. To start the DeltaAccess application, double-click on the file 'DeltaAccess.mdb' in Windows Explorer. Alternatively, you can first start Microsoft Access 97 and open the file using the menu (File, Open).

If you have problems at this point, please read the chapters on Requirements and Troubleshooting.

Upgrading existing DeltaAccess projects: The most important thing is that you rename the earlier version to a file name other than DeltaAccess.mdb (e. g. to 'DABackup15.mdb') to avoid overwriting the file with the new version. Alternatively, you could copy it to a separate folder. When you open a new version of DeltaAccess.mdb, in which no projects have been defined yet, you are asked whether you want to upgrade existing projects from earlier versions of DeltaAccess. Once you have selected the file containing the projects of your previous version, all existing projects will be upgraded to the new version.

If you want to upgrade only some projects, or if problems occurred, you can manually restore selected projects. Use the management action Restore from mdb to restore projects either from your earlier version of the DeltaAccess.mdb file or from any backup file created with the Backup to mdb-file action (present both in the management and the export dialog box).

Should you wish to add a shortcut to the programs menu (start button), drag the file 'DeltaAccess.mdb' with the right mouse button, drop it in: C:\Windows\Startmenu\Programs or another appropriate folder, and select create shortcut from the pop-up menu which appears when you drop the file. You can also drag the file directly onto the start button, which will automatically create a shortcut in the Start menu itself.

The primary address for the distribution of DeltaAccess is http:// www.bgbm.fu-berlin.de /Projects/DeltaAccess/. Updates will be announced at that site.

Main table of contents    [image] Next


 Conditions of use and acknowledgments

DeltaAccess is free software. You can redistribute or modify the application under the terms of the GNU General Public License ver. 2, as published by the Free Software Foundation. It is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License (FSF_GPL2.TXT) for more details. If this file is missing, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

The source code of this application is not read-protected and you may modify it to suit your needs. As long as significant portions of my code remain, you must give appropriate credits and you may not charge for it beyond a handling fee (e. g. for sending out diskettes). Note that this 'User guide and documentation for DeltaAccess' is not included in the GNU General Public License for the application. It may be freely redistributed, but no modifications or incorporation of parts of it into another free program are allowed without first obtaining a license to do so.

I encourage you to join me in the effort to improve this software by sending in additions or improvements and I promise to credit such efforts appropriately. I reserve the right to use part of the current code in future versions of a similar program, for which a fee might be charged. If you want to sell a program based on or integrating parts of the current code, but with significantly enhanced functionality, you must purchase a license for commercial purposes. No code or functionality sent in by users for integration into DeltaAccess, as suggested above, will ever become part of a commercial version. Thus your cooperation in the development of DeltaAccess will ensure that there is always a free, up-to-date version of this application available.

I assert that I am the author of the distributed code and documentation, unless marked otherwise. Any opinions, findings, or recommendations expressed in this material are those of the author and do not necessarily reflect the views of the BBA.

Copyright Gregor Hagedorn © 1995-1999. All rights reserved.
Institute for Plant Virology, Microbiology and Biosafety,
BBA, Federal Biological Research Center
Königin-Luise-Str. 19, 14195 Berlin, Germany.
email: G.Hagedorn@bba.de

Support

Depending on the number or requests, I may or may not be able to provide support for DeltaAccess on an individual level. I therefore recommend that all usage questions (beyond beta testing problems) be addressed to the DELTA mailing list.

Acknowledgments

I wish to extend special thanks to Gerhard Rambold and Walter Berendsohn for their many suggestions and assistance with beta testing and to Mike Dallwitz, who has been most helpful and patient (despite occasional disagreements about how DELTA data should be structured). If you are interested in lichens, check out Gerhard's Lias site (http://www.botanik.biologie.uni-muenchen.de/botsamml/lias/lias.html)! As well, I am very grateful to Désirée Maltais, who helped in correcting my English (sadly, I always introduce new errors...). Particular thanks are also due to Noel Cross, Richard Pankhurst, Per de Place Bjorn, Robin Wilson, and Joseph H. Kirkbride, Jr., for discussions and comments.

See also the next chapters Revision history and Trademarks.

Main table of contents    [image] Next


Revision history
 Revision history of DeltaAccess:

The copyright of DeltaAccess goes back to the first release of the MINOS (microbial information system) application in 1995. MINOS is still unfinished. The descriptor subsystem of MINOS was developed into DeltaAccess starting in the summer of 1996.

Version 1.0 (31.7.97). Earlier public releases were vers. 0.99 beta (30.6.97, first public beta version of DeltaAccess), and vers. 1.0 beta (16.7., limited distribution).

Version 1.1 (24.10.97): Includes character subsets, copying subsets, support for subset import/export; 'Authors' attribute is removed from item definition and joined with ItemName attribute. Many bug fixes and enhancements.

Version 1.2 (16.11.97): Includes the MultiItemEdit dialog box to insert or delete data in multiple items simultaneously, the Item description report with checkboxes, some enhancements and bug fixes.

Version 1.3 (26.3.98): Major improvements to the compilation for identification; information model changed considerably (ID_... tables, Char, Char_Heading, Rsc, Descr); special forms to edit headings and link groups; complete revision of documentation; minor additions and bug fixes.

Version 1.4 (St. Martin's day, 11.11.98): Many bug fixes, including problems with item subsets which were introduced in version 1.3; output of HTML forms added; Summarize items feature added; AutoGroup feature added to headings, headings integrated into Identify; documentation revised and corrected.

Version 1.5 (1.12.98): This is mainly a maintenance/consolidation version to replace 1.4. Minor changes to the information model are introduced. The selection of multiple items and characters in item subsets and dialog boxes has been reworked. Starting with this version, changes and bug fixes will be documented more thoroughly, see Revision details, version 1.5.

Version 1.51 (18.12.98): Minor changes and bug fixes; see Revision details, version 1.51 for further information.

Version 1.6 (public beta versions: 27.5. and 2.7., final release: 31.7.99): Major revision of backup and restore (now handles all project types, including links and subsets). and of Reorganize project definition (character heading and item resequencing added, new functions to insert a character/character heading/item above an existing one, to copy them to another descriptor project, and to add/remove them to/from a subset), updates to HTML form creation and HTML form re-import. Many other bug fixes (some serious ones) and minor changes; see Revision details, version 1.6 for further information.

See also the chapter Strategy and future development of DeltaAccess.

Main table of contents


Revision details of DeltaAccess version 1.5

(See also Revision codes)

Update, Char table: Values of attribute MultiStateType redefined. Old values: 0=OR, 1=AND, 2=TO, 3=EXCL. New values: 0=EXCL, 1=OR, 2=AND, 3=TO/OR, 4=TO/AND. This was necessary for non-continuous ranges; it allows to differentiate between '1-3 or 5-7' and '1-3 and 5-7'.

Update, Modifier table: Attribute SkipOperator redefined; type changed from Boolean to Byte and renamed to Operator. Values now indicate operator meaning (AND/OR/TO) to improve language independence. All table updates are automatically performed when a backup of a previous version is restored.

Bugfix, DELTA import: Slashes ('/') not followed by a blank or new line where already correctly treated in character names, but they were erroneously interpreted as the end of the name in item and character state names.

Bugfix, DELTA import: Item description notes after ranges were erroneously imported to first state of range, i.e. '1-3<note>' became '1<note>-3'.

Bugfix, DELTA import: The test whether incompatible local numerical formats are defined in the local Windows version failed in some cases and was missing from HTML-form re-import. This could lead to '12.5' being imported as 125 if the decimal separator was a comma, and the 1000-separator was set to a period ('.').

Update, DELTA import: The default of the import option 'Item name comments are authors' was changed from true to false. Comments/notes after item names are thus written to the Notes attribute, instead of being appended to the item name. To restore the previous behavior manually select the option before importing.

Bugfix, HTML-form re-import: Long postings created using Netscape contain a '!' at position 922. Depending on whether this '!' occurred in a note, text, or elsewhere, data may have been changed or errors may have occurred.

Bugfix, HTML-form re-import: The last character was missing from the supplementary DELTA code showed to find an error. This bug only occurred when already another error occurred during re-import.

Bugfix, Identify: You could not specify an item name condition immediately after setting a condition using categorical characters.

Bugfix, Character subsets: The test whether all controlling characters are included in a character subset reacted to the 'No'-button with 'Yes' and vice versa.

Bugfix, MultiItemEdit: Essential controls remained permanently invisible, making the form unusable.

Addition, DELTA import: The file names 'CNotes' and 'CImages' are now recognized during Confor-compatible DELTA import.

Addition, DELTA export: An option to start each character in the item description on a new line (instead of being written continuos, separated by blanks) was added.

Update, HTML-form creation and HTML-form re-import: The major numeric attributes (Min, Lower Range, Mean, Upper Range, Max) are coded as 1-5 now. This is intended to make the HTML form transfer code more independent from DeltaAccess conventions. No changes to existing forms are required, the update is fully backwards compatible.

Addition, HTML-form creation: The index options have been moved to a separate page and a new option to create an internal index on the second word of the item names in the index files has been added, see Index file tab page. Some additional changes to the code were made, which should make it more robust, but which should not affect the use of the dialog box.

Addition, HTML-form re-import: An option to ignore the original item ID (thus not adding a note "Revision of …") and an option to directly overwrite the original item was added.

Addition: Dialog to select multiple items, characters, or headings added and integrated with single selection dialog. Buttons to select/deselect all and to select using SQL-where conditions or the Identify dialog added. Buttons calling this dialog added in several dialog boxes and forms.

Addition, Item subsets: An option to directly select item ID numbers using the new multiple selection dialog (instead of always using Identify with a condition) was added. The new dialog also replaces the Reorganize dialog for selection of character subsets.

Update, Switchboard dialog box: If no projects are present (e.g. when first using DeltaAccess), only the 3 applicable tasks are displayed.

Update, DELTA import: Several data sets analyzed use the DELTA Heading directive with a trailing colon (example: '*HEADING: Amorales'). This usage is not formally described in the DELTA documentation, but actually used in the example in that documentation. Similarly, SHOW is used occasionally with a colon. Starting with this version, such leading colons are ignored. Also, #DATE and #TIME are removed from Heading. In static documents they can be replaced with the date and time of creation, but this is not appropriate for the title of a dynamic data set in a databases, which can be used at any time.

Revision history


Revision details of DeltaAccess version 1.51

(See also Revision codes)

Bugfix, Toolbar-buttons: The Switchboard button ( [image]) was not working under certain conditions.

Update, HTML-form creation: The coding of text characters in HTML forms was changed. Example: CID 91 of Type TE used to be coded "T91_TE" and is now coded as "T91"! This change should be fully compatible, i.e. results from old forms can be imported without problems and results from new forms can be imported by version 1.5 of DeltaAccess.

Bugfix, HTML-form re-import: The problem with spurious '!' already addressed in 1.5 could reappear if the '!' appeared 1 or 2 characters after a '%' character. I hope this is the final fix for this problem!

Update, Identify: Added descriptor project and application information ("About").

Revision history


Revision details of DeltaAccess version 1.6

(See also Revision codes)

Bugfix, Restore of project backups: A serious and very regrettable error was introduced in the previous version (1.51), causing a failure to restore saved backups. I apologize for the problems caused by this bug!

Update & Addition, Restore of project backups: It is now possible to restore either a selected project or all projects stored in a backup mdb-file. A new dialog box was added for backup and restore. Further, 1.6 is the first version where all linked projects and subset projects can be correctly restored. This includes mixed projects (i.e. an independent item project with a link/subset to the character definition of another project). Please note that while dynamic item subsets created in version 1.6 will be restored unchanged, dynamic item subsets created in previous versions of DeltaAccess are converted to equivalent static item subsets, i.e. they become based on IID numbers.

Addition, Installation: The handling of the restore function during upgrades to a new version of DeltaAccess has been improved. The Switchboard (the dialog box which comes up at startup of DeltaAccess) now directly offers an upgrade option if a new DeltaAccess version is opened (i.e. if no projects have yet been defined). This should make the upgrade to new versions of DeltaAccess easier.

Bugfix, Importing DELTA files: The following problem is due to a change in the libraries distributed by Microsoft. It does not affect customers with a US or British version of Microsoft Access, nor does is affect customers with any international version of Office 97 as it was originally distributed. So far, it has been detected only under the following circumstances: (1) Access running under German NT 4.0 with service pack 4 installed (service pack 3 does not yet produce the problem). (2) Office running under Windows 95 on a computer where the German Visual Basic version 6 has been installed. The change in the VBA libraries is not documented to the best of my knowledge and not logical either. It also contradicts the original documentation published by Microsoft. It basically means, that the settings for the decimal separator (English uses a period, but some other countries a comma) and the 1000 separator during conversion of strings to a number are now ignored. The number type seems to be hardcoded to the most frequent use in Germany, which means that numbers using a period (like DELTA does) can no longer be imported. This required a deep change in DeltaAccess, and I hope that no further problems result from this.

Bugfix, Importing DELTA files: Errors occurred if an item name in DELTA coded text files had one of the following unusual forms: (a) only a number, e.g. '# 1./'; (b) only a comment, e.g. '# <x>/'; or (c) nothing at all, e.g. '#/'. The item name is still required in DeltaAccess, but a prompt to enter an appropriate item name is now automatically added in the latter two cases.

Bugfix, Importing DELTA files: If a UNIT notation was used in categorical characters (as is not allowed in DELTA, but common in data sets originating from TAXASOFT) DeltaAccess would already in previous version attempt to append the UNIT to the character states. However, the unit string was erroneously not removed from the unit field and would therefore be duplicated in the output.

Update, Importing DELTA files: If an imported file contains character heading definitions, but no named character group definitions (= Define Characters directive in IntKey), the character headings are also used as character groups.

Update, Exporting to DELTA files: A warning is now issued if the character ID number are non-continuous (e.g. 1, 2, 4, 5). While DeltaAccess has no problem with this situation, many other DELTA compatible programs including Confor will not import such a data set.

Bugfix: If a text character was created or modified in the Character Editor Form of version 1.51, the corresponding TE state was not correctly created. This lead to problems in the item editor later on. The error did not occur if a project was imported from a previous version or from a DELTA text file. It was due to a tiny apostrophe erroneously deleted. NOTE: You must repair such a data set! Please go to "Analyze data" (e.g. using the Switchboard), select Analysis type: "Repair and maintenance" and Open analysis: "Add CS: Internal state TE for all text char (TE)". Click on OK, Answer YES twice, answer YES if an error message appears. This will insert the missing TE states. (Example for error message: If you have a total of 6 text characters, DeltaAccess will try to insert 6 characters. If the error message reports that 4 records could not be inserted, this means that 2 TE states have been added, repairing the 2 damaged text characters.)

Bugfix: Character Heading Editor and data model for headings: In previous versions of DeltaAccess, cascades deletes were active between headings and characters. Deleting a character heading that was used as a CharHeading or ItemSubheading in the character definition would thus cause the deletion of all related character records, which in turn would delete all related character states and item descriptions for these characters. Since this behavior is unintuitive and dangerous, it has been changed. In tables or queries, headings that are not used as CharHeading or ItemSubheading you can no longer longer be deleted directly. To delete such a heading you must use the Character Heading Editor or the Reorganize form, where the links to the Char table (CharHeading, ItemSubheading) are now automatically removed before the heading is deleted.

Bugfix, Create new item project linked to a subset of an existing character definition ("mixed projects"): The setting of referential integrity relations for the new project was faulty. Projects could be used, but changes in the original project (esp. renumbering/reordering) were not reflected in the linked subset project. Also, it was not possible to directly overwrite an existing character subset project. The project had to be explicitly deleted, and then recreated.

Bugfix, Character subset: Excluded characters remained in the item description if no item subset was defined at the same time. The error would show only when opening the project queries directly, or when the special "ALL" view of the item editor was used. Most analysis queries would have been unaffected.

Update, Item subsets: The method to define subsets has been reworked, to simplify the management of subsets and to enable to change the item sequence (and the IID numbers) in the future. With previous versions of DeltaAccess, changes in the IID number would not be reflected in the subset. Character subsets were already resistant to changes in the CID numbers; a similar method is now used for item subsets. Please note that this does not apply to dynamically defined item subsets (a condition defined through Identify). These subsets will be invalidated by changes in the CID (i.e. the character, not the item sequence!). See also Further information about subsets.

Bugfix, Identify: Under certain conditions a single item would be listed multiple times in the item list (after clicking evaluate). All items should now appear only a single time.

Bugfix, Summarizing items: An error would occur, if descriptions with multiple, non-identical modifiers were compiled into a summarized item (and the option to ignore modifiers was deselected). Example: categorical character leaf number, species 1: "6-10", species 2: "about 6-10" would be ok, but if a species 3: "usually 6-10" would be added an error would occur because the combined modifier does not exist. The new version now ignores all but the first modifier. Any better ideas how to deal with multiple modifiers during Summarize?

Bugfix, Summarizing items: If the temporary Item-summarize table was not manually removed in the Summarize items dialog box, it would not be removed together with the other project tables when the entire project was later deleted. As a related upgrade, an option to automatically delete the summarize table was added to the Summarize items dialog box.

Bugfix, Item Edit Form, Preset Items: The button was not working any more; the list of items to select from was empty.

Bugfix, Editing character headings: On computers with a VGA screen resolution and large fonts the upper part of the form could become hidden behind the toggle buttons used to switch between heading and link-group editing. Also, the Notes and HID attribute were misplaced when the width of the form was changed.

Bugfix, Appending data to a project: Errors could occur if the project defined character headings or character dependency. Also, updated to add the project name rather than a number after the character or heading names.

Update, Deleting descriptor projects: A warning message is now issued if attempts are made to delete a base project without deleting the dependent linked projects.

Bugfix, HTML-form re-import: If the information posted back from a DeltaAccess HTML form is corrupted and cut off at some point during the transmission (esp. by email), the import process could fail to finish. The bug caused an infinite loop and the process would "hang". This has been fixed and appropriate error warnings have been added. However, please note that for old HTML forms (created by DeltaAccess versions before 1.6) there is no method to determine whether indeed all characters have been returned. You will not be warned if the truncation removes trailing characters at the "correct" point, i.e. as they could have been send by the HTML form itself. Forms created by DeltaAccess 1.6 have a special end of data marker ("DHF_END=1") which is checked.

Bugfix, HTML-form re-import: If the information posted back from a DeltaAccess HTML form is corrupted and cut off at some point during the transmission (esp. by email), the import process could fail to finish. The bug caused an infinite loop and the process would "hang". This has been fixed and appropriate error warnings have been added. However, please note that for old forms (created by DeltaAccess versions before 1.6) there is no method to determine whether indeed all characters have been returned. You will not be warned if the truncation removes trailing characters at the "correct" point, i.e. as they could have been send by the HTML form itself. Forms created by DeltaAccess 1.6 have a special end of data marker ("DHF_END=1") which is checked.

Bugfix, HTML-form creation: Radio buttons had no "neutral" position. The HTML form could start up with no button selected, but if anything was erroneously selected, it was impossible to revert to "I want to say nothing". An additional radio button with the default labeling "none selected" has now been added for this purpose. (Suggestions for an improved label text are welcome!)

Bugfix, HTML-form creation: The color of states was ignored (the other color settings worked).

Bugfix, HTML-form creation, Localization strings: The labels for numerical units (default 'Units:'), special text in a categorical character (default 'Other (enter as text):'), and for the new item in the index file (default 'Add a new item') remained unformatted. This could lead to problems if the localization string was changed and contained accented characters or special characters like '>', '<', or '&'. Additional strings that were fixed in previous versions were added to the user interface to allow localization. Update: Some localization string defaults were changed.

Bugfix, HTML-form creation, Output options: For radio buttons and pick lists (i.e. in the case of exclusive characters), modifier and notes field were always displayed, irrespective of the setting in the dialog box.

Update, HTML-form creation, Formatting options: The default for the number of character states up to which radio buttons were used (a pick list is used if more states are present) in exclusive categorical characters was changed from 7 to 4. The number now refers to the actual radio buttons displayed on the form. Previous versions of DeltaAccess counted special states present in the character definition, even when they were excluded from the HTML form.

Update, HTML-form creation: Two new special fields have been added to the form definition. This updates the Descriptor HTML interchange format from version 1.0 to 1.1. Both versions are recognized by the HTML-form re-import starting with DeltaAccess version 1.6. The first change introduces a hidden data element indicating the end of data. This element ('DHF_END=1') is evaluated to detect truncated transmission, which may occur especially if the data are returned by email. The second option adds a field to enter a required user name or email address of the person filling in the form. This is especially useful when using a CGI-gateway script that can reject a form where this information is missing. The user name field can be suppressed by leaving the localization string (tab page Localization strings) empty.

Update, HTML-form creation, Formatting options: Text characters which are set to several lines height (i.e. where a TEXTAREA with scrollbars is displayed) are now created with the attribute WRAP=SOFT. Thus lines wider than the display area wrap to a new line, without being broken in the data posted back to the database. Hard returns can be inserted as before and are transmitted.

Addition, HTML-form creation: If character headings are used, and if an internal index to character headings exists at the top of the document, a new option has been added to insert links back to the index of headings after each character heading (new checkbox on tab page Output options, phrase on tab page Localization strings). The default is the text "-- back to index", but it is possible to use any text or a small image instead. If the phrase entered here ends with '.gif', '.jpg', or '.png' it is assumed to be a relative or absolute URL to an image that you supply. Please contact me if you want to use other file extensions than the 3 mentioned.

Addition, HTML-form creation: Optional hyperlink to return to the index of item descriptions file added.

Addition, HTML-form creation: You can now choose to overwrite all files instead of being prompted each time a file is already present.

Update & Additions, Reorganize definition dialog box: The formerly independent reorganize character and reorganize character state dialog boxes have been joined and facilities to change the sequence of character headings and items have been added. Further, new functions have been added to insert a character, character heading, or item above an existing one, and to copy them to another project. Finally, a special function to reset the sequence of categorical states in the item description has been added.

Addition, Reorganize subsets: The Reorganize definition dialog box now recognizes if it is used on a subset and warns if the character headings, states, or description tab pages are selected. It enters a special mode for characters and items, allowing to add or remove them from the subset definition or a linked project (not possible for dynamic item subsets).

Bugfix, Reorganize character state: When, while joining two states within a single character, the new state code was accidentally left empty (i.e. the command was given to join a state with itself), the state and all linked item descriptions were deleted (because they were treated as remaining duplicate item descriptions!).

The formerly independent reorganize character and Reorganize character state: dialog boxes have been joined and facilities to change the sequence of character headings and items have been added. Further, new functions have been added to insert a character, character heading, or item above an existing one, and to copy them to another project. Finally, a special function to reset the sequence of categorical states in the item description has been added.

(Cosmetic) Bugfix, HTML-form creation: Some Output options: were displayed in such a way that they covered the label, making the label unreadable. This problem affected only the user interface, not the functionality of the program.

Revision history


Codes used in Revision details
Codes used in the lists of revision details:

Update = change of existing functionality, which may influence third party products using DeltaAccess databases. Bugfix = necessary change due to erroneous behavior of the previous version. Addition = new additional feature or option, should not influence third party products using DeltaAccess.

Not listed are: Cosmetic changes (changes to messages, labels, control placement, and other immediately obvious changes) and changes in the VBA code libraries. Please note that if you are using DeltaAccess VBA code in your own functions, you must test them before relying on a new version.


Trademarks
Trademarks: All terms mentioned in this documentation that are known to be trademarks or service marks have been appropriately capitalized. Use of a term in this documentation should not be regarded as affecting the validity of any trademark or service mark. The following list of trademarks, registered trademarks, and service marks has been compiled to the best of the author's knowledge, but the accuracy of this information can not be attested to by the author: Microsoft, Access, Excel, FoxPro, Microsoft SQL-Server, Visual Basic, Windows, Windows NT, and Word are trademarks of Microsoft Corp. Paradox, dBase, and Interbase are trademarks of Inprise Corp. (formerly Borland International Inc.). Oracle is a trademark of Oracle Corp. Sybase is a trademark of Sybase, Inc. Macintosh is a trademark of Apple Computer Inc. SPSS is a trademark. SAS is a trademark of SAS Institute, Cary, NC.

The Characterize and Identify icons ( [image] and [image]) and the terms "DeltaAccess", "Characterize", "Describe", "Minos", and "Identify" are trademarks for computer software and protected titles of copyrighted material.


Main table of contents    [image] Next


Introduction, Table of contents
 DeltaAccess –
a SQL interface to DELTA (Description Language for Taxonomy), implemented in Microsoft Access

Introduction

   Introduction
   Concepts of structured data storage
   The mountain and the pebbles: A global knowledge base versus multiple discrete projects
   Strategy and future development of DeltaAccess
   Database subsystems
   Software architecture of DeltaAccess
   DELTA software sources on the internet
   Next table of contents: Import and export

Main table of contents    [image] Next


 Introduction

What is DELTA?

DELTA (Description Language for Taxonomy) is a powerful data exchange format for descriptive data. It goes back to work done by Mike Dallwitz at Canberra University in 1973, and was officially introduced in Dallwitz (1980). DELTA is probably the widest used general purpose standard for descriptive data and is used by several important taxonomic software packages ("The Delta package" containing Confor, Delfor, and Intkey; Pankey and Pandora; DeltaAccess; Taxasoft; and with restrictions also by LucID and CABiKey). It is rivaled only by the NEXUS format, which in its current version 2 (Maddison & al. 1997) is still limited to analytical purposes and can not deal with basic data types like text or multistate characters.

The inventor of the DELTA data exchange format (Mike Dallwitz) calls his software package "DELTA" as well. Although he undoubtedly has a right to do so, this is very confusing. It places a heavy burden on the data standard issue and probably will make it necessary to rename the data standard for descriptive data in the future. To avoid confusion between the data standard and Dallwitz's programs, this documentation therefore refers to the programs in this package (Confor, Delfor, and Intkey) instead of to the package itself.

DELTA was first introduced by Mike Dallwitz in 1973. The Taxonomic Database Working Group (TDWG, a section of the IUBS) has endorsed the basic directives of DELTA as an international data standard (see http://www.tdwg.org/standrds.html).

Technically, DELTA is a delimiter based free text format which works similar to a programming language. Its main advantages are that data files are plain ASCII, comparatively compact, and remain to a certain degree readable and editable in a word processor. In fact, the reliance on this ability has seriously handicapped the wider use of DELTA. The structure is sufficiently technical to prohibit most biologist from trying to understand and use it. Two DOS based editors are available (DEDIT by R. Pankhurst and TAXASOFT by E. Gouda.) The first graphical, Windows based editor appeared in 1997 with DeltaAccess. Only recently, i.e. after 18 years, the first beta versions of a DELTA editor for Dallwitz's "Delta package" have appeared.

For the purpose of this introduction, it is sufficient to view DELTA as a data interchange format. More detailed information can be found in Dallwitz & al. (1993) and chapter 5 of Pankhurst (1991).

DELTA uses the terms item and character(1). An item can be a taxon as a whole (e. g. a species or genus), a specimen of any specific or subspecific taxon, or any other object (e. g. a vegetation unit). Compare also Interactive identification packages outside the realm of taxonomy). Characters, sometimes also called attributes(2) or features, describe the items. Characters should be defined in such a way that they are independent, and that each independent feature is represented by a single character. Note that this is frequently not the case in traditional morphological descriptions. Taxonomists often tend to think in terms of character complexes rather than in terms of atomized characters.

If the character type is categorical, a discrete number of character states is defined for each character. Other character types are numeric, where measurement values or statistics (mean, standard deviation, etc.) can be entered directly, and text, where any free text can be entered. Images (photographs, line drawings, etc.) can be attached to the character definition, as well as to the item description.

DeltaAccess is a software package to import and export DELTA files. It converts the DELTA coded text files to relational database structures. Some of the reasons for writing DeltaAccess are presented in the following chapter Concepts of structured data storage. Although DeltaAccess currently supports only a subset of the directives supported by Dallwitz's Confor program, in many other ways it goes further than the Confor program, which only supports a subset of the DeltaAccess directives. DeltaAccess tries to overcome the limitations of DELTA without giving up the compatibility with DELTA data files and programs supporting DELTA.

DeltaAccess is explicitly not designed to only code existing data for later compilation into natural language descriptions or for use by interactive identification programs. DeltaAccess can be a general data repository, in which the raw data can be entered during work in progress. It should be a working tool of the biologist, rather than an additional task after the completion of data collection. The data are edited or analyzed in the database, not in DELTA coded text files.

The Identify module of DeltaAccess allows the user to identify an unknown item at hand by comparison with the items stored in a DELTA database. It is currently not finished, and supplied as a preview only. In Identify, one or several character states for each character can be described as present or absent, numerical measurement values can be used directly, and words from the free text descriptions can be searched. Although development of a stand-alone identification-only application is possible, given my intentions of supplying a working tool, I currently have no plans to do this. See the chapter Identify in comparison with other identification software for a comparison of the working tool approach with the publishing tool approach.

If a read-only version of a descriptor project is required, the database could be protected using the Microsoft Access security model, but whenever possible the user should have the option to add his or her own data. See the chapter Fingerprinting data sets for an alternative method of copyright protection.

Main table of contents    [image] Next


Terminology: Characters and Items
(1) DeltaAccess uses the terms character and item. Synonyms for character are: feature, attribute, property, and descriptor. Synonyms for item are: taxon and OTU (= Operational taxonomic unit). The item synonyms apply only when used in a taxonomic/systematic context; however DeltaAccess can be used to identify vegetation types as well as specimen!

Compare: Colless (1985) and Inglis (1991).


Terminology: Attribute
(2) M. Dallwitz uses the term attribute in relation to scoring characters for specific items in the item descriptions. The documentation of DeltaAccess does not follow this usage, because in data modeling the term is usually understood in the sense of attribute (= "field") of an entity (= "table").


 Concepts of structured data storage

	Who should read this: People interested in the concepts and current development trends of the various DELTA programs. Reading this chapter is not necessary for the use of DeltaAccess.
Structuring data is at the very heart of any descriptive work. The degree to which data should be structured depends on the objectives of the project. Often it is also a matter of taste and tradition.

Any text is structured. A well written monograph is better structured than a poorly planned collection of descriptions. Using well structured outlines, and making them readily intelligible to the reader using appropriate formatting, is a basic requirement of writing.

The origins of DELTA go back to a time when word processing applications had limited features if they were available at all. At that time it was probably necessary to have a formatting tool and a specialized word processing programming language to use with descriptive data. The proprietary formatting codes still used by current versions of Confor have their justification in that period.

Today, word processing programs are powerful, sometimes feature-overloaded applications which are readily available. They are used on an everyday basis to write reports and scientific publications by almost every scientist. Formatted output is achieved by industry standard interchange formats (Postscript, TEX, RTF, etc.) and software interfaces (e. g. printing services and hardware drivers supplied by the operating system). With such flexible and powerful programs already in widespread use, why would one want to learn yet another word processing tool?

In my opinion, DELTA will only survive if it is seen as a data interchange format for data with more structure than normal text.

The description of taxa and specimens is a task, which can benefit enormously from structured data storage in a database. Whenever possible, the information gathered should be linked to voucher specimens, e. g., insects or herbarium sheets. Descriptions taken from the literature should be linked to a reference in the literature database. Generic taxon descriptions can then automatically be prepared from the separately entered descriptions of specimens or references. If later the identification of a specimen from which date were recorded changes, or if certain references turn out to be unreliable, this can automatically be corrected in the taxon descriptions. See the documentation of the Summarize feature of DeltaAccess for more information.

A database system which supports structured data storage very well, includes a "Summarize" function and is in use for a number of years is Richard Pankhurst's Pankey/Pandora packages. The disadvantages of the Pankey/Pandora combination are that Pandora uses an implementation specific data model called "post-relational" which is a mixture of relational and hierarchical elements and which is incompatible with other database programs. Also, Pankey and Pandora are currently limited to the DOS operating system.

DeltaAccess tries to provide a similar database interface for standard relational databases under a modern operating system. Microsoft Access, one of the most widely distributed PC desktop databases, was chosen as the basis for this development (see the chapter Software architecture of DeltaAccess).

In contrast, most of Mike Dallwitz's DELTA package seems to be evolving in the opposite direction. Instead of viewing DELTA as a general data collection and analysis tool, the basic guideline for the development of Mike Dallwitz's DELTA package seems to be the book metaphor. The primary purpose of collecting the data is to compile the DELTA project either into a book (including natural language descriptions, printed images, and printed dichotomous keys), or into a data set for the interactive identification program IntKey. This is especially true for the not yet finalized (as of May 98) new version of the DELTA format (see Dallwitz et al., New Features for the DELTA System).

In this new version, DELTA seems be developing into a programming language, which can be compiled into material for a taxonomic monograph, like dichotomous keys or natural language descriptions. Other examples of such free-text coding formats are HTML, the format used for World-Wide-Web documents, or the RTF exchange format used by word-processors. Examples for constructs incompatible with structured databases are:

•	comments dispersed anywhere in the text, the absence of any unique identifier for items,

•	an unlimited number of subfields in the character name, and

•	the list feature, which allows an undefined number of quasi relational links anywhere in the text, including the comments.

Such free text formats do have a structure and they contain information, but they are still incompatible with all existing structured databases (excluding perhaps the semi-relational free text database specialist AskSam). Both the structured and the unstructured approach have their strengths and weaknesses. The difference becomes evident for example where comment text is used to modify the information defined by the character state, e. g., through adding "sometimes", "rarely", or even "but not". This works well when compiling natural language descriptions or printed keys, but not when items are identified in the database.

Natural language descriptions and dichotomous or multichotomous printed keys are certainly very important, but they are not the only tasks desirable. A descriptor database can be used to organize the data collection and editing work itself. For this purpose it is important that the data can be analyzed to search for missing information, and that data can be selectively retrieved in a process which is very similar to interactive information. Questions like "Do I already know about this?", or, "which evidence supports this observation, and which contradicts it?" should be readily answered in a consistent application environment. This makes it necessary that the interactive identification works online on the most recent data available. It should be possible to improve the character definition as required by the ongoing work.

The current version of the DELTA format poses several problems in this scenario.

The capability to annotate the source of information or the responsible author, typist or editor is very poorly developed in DELTA. This becomes particularly cumbersome if several workers cooperate on a single project.

Another problem of the current DELTA definition is that for numerical characters the meaning of the range and central value remains unclear. The range could be a confidence interval, a quantile, mean plus/minus s.d.; the central value could be a single measurement, a mean, median, mode, etc. In the book paradigm, such information might be given in the introduction, but this is not possible in a worldwide network of distributed databases.

In many cases it is preferable to use a link for scientific names, literature references, geographical places, collectors numbers, collection unit numbers in specimen collections, etc., instead of describing the information in a plain text string. Links may be based on text strings, but they are protected to guarantee that the corresponding information in the external database subsystem can be found automatically by the application, even if the corresponding information has been updated. In contrast, a literature reference entered as text is resolved in the brain of the user, and is not accessible to a program.

Main table of contents    [image] Next


 The mountain and the pebbles: A global knowledge base versus multiple discrete projects

	Who should read this: People interested in the rationale of having several projects, people interested in implementing a general descriptor database in a large scientific organization, and people interested in building a network of scientists working on closely related subjects.
Theoretically it would be possible to integrate all existing descriptive data about organisms into a single set of database tables. This model would represent the sum of the worldwide taxonomic knowledge, including groups as diverse as viruses, bacteria, protists, algae, lower and higher plants, fungi, and the various groups of animals.

Such a global data set is certainly an attractive idea. Nevertheless, DeltaAccess implements multiple discrete data sets called descriptor projects instead. In a discussion of the respective merits of these approaches, the conceptual problems of a global character definition should be distinguished from the technical problems related to the information model and its implementation, which are discussed in the chapter Information model for multiple projects.

In principal it is possible to create a character definition for a global, all-taxa descriptor database. Using the inapplicable character mechanism, the number of characters visible could be reduced to a bearable measure. Unfortunately, creating a global character definition requires a considerable amount of research and discussion about terminology. It is probably impossible to automatically merge existing character definitions, which contain a mixture of logically identical characters (named identical or not) and non-congruent characters (named differently – or identical!). Unless a character definition was already specifically devised with a global scope in mind, it is difficult to integrate it into a global character definition.

Example: The character "Presence of wings" does not refer to the same thing in insects, birds, and bats. This may appear to be irrelevant at first, yet it is not. In a key to insects, you may want to distinguish between front and hind wings, or add a third alternative to deal with cases where the wings are reduced, but still visible (e. g. halteres in Diptera). Or, you may want to make the feather characters of birds dependent on this character. If you are currently identifying a bat, being asked about feathers will then be confusing.

Even after these problems of a global character definition are solved, "projects", as local chunks of data, remain a necessity. While a global data set is very attractive for analysis/identification purposes, it may not be a good research tool.

The quality of a data set strongly depends on the understanding of the researchers responsible for it. If they are experts only for a small group, this group should be their only concern. Data collection or editing should therefore remain a local process, involving only those characters and items necessary. It is important to maintain the flexibility to change the character definition ad hoc, without having to consult a multinational committee... A modification of a character definition might be erroneous, but we might learn more from our errors than from our omissions.

The knowledge of biological organisms is usually local to taxonomic groups as well as to geographical regions. It does not seem to be a wise decision to burden the character definitions of researchers with the problems that would result from enforcing global character definitions.

I believe that ultimately these issues can be reconciled, but many problems need to be analyzed in first. It is important to distinguish between the requirements of the analysis and information retrieval (including identification) processes and the editing process, respectively. The first actions should focus on data set integration for analysis and identification purposes, i.e., the consolidation of multiple data sets in a one way process for use in identification applications.

An important option of descriptor databases for the purpose of data set integration would be a "validation" of individual characters against a reference character definition. Such reference character definitions for larger areas (e. g., higher plants, insects, or fungi) should be created in coordinated projects involving as many researchers as feasible. They should be issued with a version number. Each character in a new version of a reference character definition should be validated against the previous version. The validation assures that the two versions are backward compatible, although the wording of a character may have been changed, or additional character states may have been added. Individual researchers could validate characters in their definition against a specific version of a reference definition. This procedure would maintain the option to introduce additional characters, or even have a deviating opinion about how a character should be defined. Such a deviation would then at least be a deliberate and documented process.

If reference character definitions exist and if individual data sets are already validated be their authors against (possibly different versions of) these reference character definitions, a major part of the integration process could be automated. The remaining conflicting characters could be analyzed manually, which itself in many cases may give valuable insights into the structure of the data.

In the absence of reference character definitions, and while the available tools (including DeltaAccess) do not support a character validation mechanism, one can still start to integrate existing data sets. The major task is that the character definitions of these projects must manually be made compatible. If you anticipate that you want to consolidate existing or planned projects in the future, you might already want to initiate discussions with your colleagues to make your respective character definitions convergent while your projects remain otherwise separate. The chapter Merging projects (data sets) discusses the practical problems involved in the integration of existing data sets using DeltaAccess and DELTA.

Already in the current version of DeltaAccess it is possible for scientists to work together on a common descriptor project. The character and item subsets facility of DeltaAccess can be used to present each person only those items and characters in which she or he is primarily interested. Each researcher can concurrently edit and analyze this subset without the danger of creating any inconsistency in the data set as a whole.

If it has been decided to implement an institution-wide descriptor database, and the problems outlined above are consider to be not relevant (e. g., because of closely related areas of work), one can ignore the multi-project capabilities of DeltaAccess and create but a single project. As the project name you could choose the name of your organization, or a generic name (e. g. "Descriptors").

It is important to remember that descriptor projects are not taxonomical name databases. The presence of the usually scientific item names in the item entity may lead to the false assumption that items are taxonomical entities. This is not the case. DeltaAccess is a descriptor database subsystem, which should be linked to a separate taxonomical database subsystem. Thus, in a global view, the item entity of a DeltaAccess information model would be a link table between taxonomic entities, literature references and descriptor definitions (character matrices).

Main table of contents    [image] Next


Strategy and future development
 Strategy and future development of DeltaAccess

	Who should read this: People interested in the development guidelines of DeltaAccess and in an outlook on what can be expected from future versions of DeltaAccess.
The development of DeltaAccess is guided by two principles:

1. Concentrate on the management of "descriptors" of items. Other data should be stored in appropriate database subsystems. Such subsystems are literature reference databases, nomenclatural databases, and specimen collection databases. Subsystems should be linked using references to object identifiers in the subsystems. The architecture of the subsystems should be modular to allow the exchange of one subsystem against another. See the chapter Database subsystems for more details.

2. Make as much use of available software tools as possible. While the use of industry standard software interfaces may not lead to a remarkably small and fast application, it does minimize the development effort while maximizing the available functionality. See the chapter Software architecture of DeltaAccess for more details.

The current version of DeltaAccess is only the first step in a planned strategy. Besides implementation issues (character state mapping, illustrations, etc.), the major conceptual drawbacks of DeltaAccess are currently:

•	Limited multi-project integration: Although several descriptor projects can be managed within a single DeltaAccess application, only limited interaction among these projects (e. g., using character links to use a unified character definition) is possible. No true integration of projects is available, e.g. it is not possible to analyze several projects in a single step to identify items. See also the previous chapter The mountain and the pebbles: A global knowledge base versus multiple discrete projects.

•	Lack of interaction with other database subsystems: Descriptor projects remain isolated databases, without interaction with other database subsystems (e. g. literature reference, nomenclatorial, specimen collection, and loan management subsystems). Standard database functionality can be used to implement such interactions, but no interactions have yet been implemented in the application (see links to other database subsystems for further information).

•	Limited multi-user integration: The cooperation of several workers on a single descriptor project has become easier with DeltaAccess, but is not supported by a logging and auditing implementation yet.

The next full version (2.0) is scheduled to fully implement images, perhaps also character mapping ("Key states"), and to improve the functionality of the internal interactive identification module Identify (*** external interfaces already make use of the compiled identification information starting with DeltaAccess version 1.3, but Identify itself needs to be revised). In that version or the version after that, the identification process will be changed to offer error tolerant ("fuzzy") searches, and offer estimates of resolution power of characters based on the item description data. See also the chapter Limitations which will be removed.

Only after these single-project-changes have been made, will I try to improve the integration of descriptor projects into a global supra-project structure, including links to other database subsystems and integration of descriptor projects. See also Merging projects for a discussion of manual project merging.

Main table of contents    [image] General development information    [image] Next


Descriptor database subsystem and other database subsystems
 Database subsystems

	Who should read this: Users who are interested in the idea of descriptor databases and in a theoretical discussion of how modular a database should be.
A common problem with current biological database implementations is their monolithic design. While parts of existing applications may be excellent, other parts may be lacking in general, or may be unsuitable for the needs of a specific organization. The solution to this problem is a integrated biological database built from modular applications. Such modules are called database subsystems in the current documentation.

DeltaAccess is a descriptor database subsystem. Other common database subsystems are literature reference databases, nomenclatorial databases, and specimen collection databases.

Both the information model and the application of each subsystem should have well defined interfaces to other subsystems. Subsystems should be seen as exchangeable modules. Thus the literature reference database could be replaced, if it did not fulfill the expectations and a better product was found. Such a design would also allow you to be independent of DeltaAccess in the future, should a different application be found to serve your needs better.

A descriptor subsystem contains observations on the objects. Usually this excludes attributes which are essential for the definition of the object or related to the management of objects. This distinction can often be made more clearly in the case of physical objects (e. g. a specimen unit) than in the case of abstract concepts (e. g. a nomenclatorial name). DELTA deals with both types of items. Some examples to clarify this distinction are given below:

Specimen: The location and date of collection can not be observed. It is essential information about a specimen which can only be obtained from the original collector. Typical management attributes are: location in collection, history of origin, loan/exchange management, treatment for preservation, etc. The details of identification (including the possibility to preserve a history of multiple identification events) should also be treated separately.

Examples for specimen descriptors are size, secondary metabolites, or DNA sequences. Some descriptors form a special problem, because, although they are clearly descriptors, they can be observed only at the time of the collection event. Examples are habitus of the organism in the field, behavior of animals, association with other specimen, and any character which does not survive the conservation method, e. g., many flower colors. These are essentially descriptors of an observation unit from which the collection unit is derived. See Berendsohn et al. (1997) for more information about Collection management subsystems and this problem.

Literature reference: The authors, title, source, etc. are essential attributes of a literature reference. Some standard descriptors are commonly carried in the literature database subsystem itself, e. g., size of book (important for filing) and signatures. Index keywords are descriptors which should best be placed in a descriptor subsystem, although this is usually not done. Extracting item descriptions for a descriptor project from a literature reference is a special way of abstracting and indexing.

Nomenclatorial names: Essential attributes are the basionym, type specimen information, status of name, etc. The description of the taxon should be treated as descriptors attached either to the type specimen or to the literature reference which contains the protologue of the type.

In the descriptor database, only linking information (the identifier of a literature reference, the nomenclatorial name, or the code of a specimen) should be stored. For example, the scientific name of an organism can serve as a primary object identifier in a nomenclatorial database, allowing the retrieval of nomenclatorially relevant information about nomenclatorial combinations, synonymy, or the type specimen.

The current version of DeltaAccess does not implement subsystem links on the user interface yet, although the attributes are already present. See Links to other database subsystems in the appendix. Naturally, in the absence of appropriate database subsystems, characters can be introduced to store non-descriptor information inside DeltaAccess. This includes taxonomical information or lists of synonyms. No support for special requirements of such characters will be implemented in DeltaAccess though. The special features for nomenclatural purposes to be introduced in the new version of Confor (see Dallwitz et al. New Features for the DELTA System) will not be supported beyond import.

Main table of contents    [image] Next


 Software architecture of DeltaAccess

	Who should read this: Users who are interested in a discussion of the advantages and disadvantages of using a relational database in general and Microsoft Access in particular.
DeltaAccess is based on a wide array of existing software tools. It uses a relational database as storage subsystem, industry standard software interfaces (SQL, ODBC, DCOM/OLE), a high level programming language, and a visual development tool. This strategy lets taxonomists benefit from the million dollar programming efforts, which are undertaken primarily for business applications. Using standard relational database management systems makes features like multi-user operation in local and wide area networks, data security models, and database replication available. Implementing these features in a dedicated taxonomic software package would probably not be possible, considering the limited resources available to the scientific and taxonomic community.

Microsoft Access was found to be a suitable tool for the current stage of the development of DeltaAccess. It allows the development of an application which can be used without modification both on a single PC and in a local area network. Theoretically, up to 255 users can use a single descriptor project concurrently. In practice, 20 permanently active users (e. g. typists) and perhaps 50 occasional users is quite realistic. To support significantly more users, wide area network operations, or high volume transactions from web interfaces, data can be ported to a large scale SQL-database-server (see Linking to other data sources). The Microsoft Access application (e. g. DeltaAccess) can then be used as a client or "front end" application. The same feature can be used to create links to other database subsystems. For example, if your reference manager supports ODBC, you can link directly to your literature references.

The JET database engine used by Microsoft Access provides a fairly complete implementation of the relational database model, including declarative referential integrity with optional cascaded updates and deletes. The data are stored compressed (text attributes are not filled with blanks up to their specified length) and long text attributes may contain up to 65535 characters.

Microsoft Access and JET already provide advanced features like a tight security model (see Securing an Access database in the Appendix) and database replication without the help of a database server.

A further advantage of Microsoft Access is its unique combination of development tool and visual user interface. The visual tools and wizards allow users who have a full version of Microsoft Access (i.e. they do not use a run-time version) to modify the parts of the application to suit their needs. This ranges from minor changes in reports or analysis queries to adjust the look on a specific printer or paper format, to major extensions and improvements to suit their own needs (see the chapter Co-Development issues in the appendix). Microsoft Access is very widely distributed as part of Microsoft's Office package.

Some of the disadvantages of the software architecture chosen are

•	The size of the software which must be downloaded is relatively large. The compressed size of the run-time version is about 10 MB. This problem is somewhat compensated for by the fact that the full version of Microsoft Access is very widely distributed. Thus, in many cases no additional download is necessary.

•	The DeltaAccess application files itself are also comparatively large. Although this is a problem when downloading it from the internet, it is not large enough to cause problems on modern hard disks.

•	The software architecture is relatively complex. This is especially true if you want to link to a SQL database server. It is doubtful though, if any other development system would be easier to manage in such a situation. Managing database servers still requires experienced personnel.

•	The speed of the application is not always satisfactorily. This does not mean that any application developed in a low level programming language (e. g. in C) is necessarily faster. I have personally seen many standalone applications developed from scratch which were significantly slower than Microsoft Access. Development in C gives the opportunity to optimize performance, but it does not guarantee it. Part of the speed problem is that the optimization is not optimal for small or medium size descriptor projects. On today's computers, most descriptor projects could be kept completely in memory. Using a database for data management means that some operations occur on the hard disk. This problem is compensated by some advantages: DeltaAccess can handle very large data sets and multi-user operation, both of which would be almost impossible if project data were kept entirely in memory.

Since most of the functionality of DeltaAccess is based on Microsoft's VBA (Visual Basic for Applications) and JET (Joint Engine Technology), it is possible to use other front end tools, including Visual Basic and Visual C, in the future. Such applications (e. g. a fast, specialized item description editor) could be developed by other people as well (see Co-development issues in the Appendix). Provided that they use JET and the same information model, such applications could even be used simultaneously on the same descriptor project data (by a single user or even by multiple users in a network).

The development of a fast stand-alone application (e. g. in C) with the number of features DeltaAccess offers is beyond my resources. You need a sizable programming team to do that. If you are just looking for a fast editor to edit your DELTA data sets more comfortably and with less errors, and if you feel comfortable with DOS programs, you may want to look at the shareware program TAXASOFT by Eric Gouda. You can also look at the new Windows versions of M. Dallwitz's DELTA package, which are currently developed and contain a good and useful editor for DELTA.

Main table of contents    [image] Next


 DELTA software sources on the internet

The following is an annotated list of software resources related to DELTA of which I am aware.

•	DeltaAccess itself is distributed primarily from http:// www.bgbm.fu-berlin.de /Projects /DeltaAccess/. Minor updates will be announced through that site. Only major updates will be announced through the email lists as well.

•	DELTA mailing list: An email list is available called "DELTA Software Discussion List". This is currently the preferred forum for discussions and requests for support of DELTA programs, including DeltaAccess. A list server is a utility, which distributes all incoming messages to all members of the mailing list. Thus, when you ask a question, all members of the list will receive an email with your message. Conversely, you will receive regularly messages from other members. To subscribe to the mailing list DELTA-L, send the message: "SUBSCRIBE DELTA-L your-first-name your-last-name" by email to listserv@nic.surfnet.nl. Under http:// listserv.surfnet.nl/ archives/ delta-l.html you can join or leave the list using a web browser, and browse or search old list postings.

•	DELTA Newsletter: http:// www.calm.wa.gov.au/ science/delta/news/ index.html. Several back volumes are available online, unfortunately only in Adobe PDF format. They can be read using a special program from Adobe, which is free, but a huge download.

•	DELTA: CONFOR, DELFOR, INTKEY, etc. (Mike Dallwitz, delta@ento.csiro.au): http:// www.biodiversity.uno.edu /delta/. This is the "DELTA home page". Mike Dallwitz originally invented and developed DELTA. The most complete and probably most widely used package, but very difficult to use (command line / batch file oriented). The package is accompanied by a very extensive and helpful documentation. The programs are continually updated. The base programs (Confor, Delfor, Intkey etc.) are shareware. They can be freely redistributed, but you must pay a license fee (ca. 400 US$) if you use them. Generous exceptions are granted to school use or use by Ph.D. students. The Intkey package for interactive identification must be licensed when redistributed. Intkey itself is a Windows 3.x program. Thus, although you have to deal with a difficult user interface yourself, you can pass a program with a Windows user interface to end-users for computer assisted identifications. The other programs are available in versions compiled for Windows as well. They use extended memory, which allows larger data sets, but the user interface is currently identical with the DOS versions (command line / batch file oriented). New versions with a true Windows user interface are expected in the summer of 1998. They will be based on a significantly changed (and, unfortunately, largely incompatible) DELTA language. This new version will no longer provided structured data compatible with databases, see the discussion in Concepts of structured data storage.

•	Two menu-oriented shells are available to run the command line oriented DELTA programs under Microsoft Windows: DIANA, by Mauro J. Cavalcanti (maurobio@uerj.br), http:// www.biodiversity.uno.edu /delta /diana and Delta Menu System, DMS by Nicholas S. Lander (nlander @calm.wa.gov.au), http:// www.biodiversity.uno.edu /delta /dms. These shells run the normal DELTA programs (Confor, Delfor, etc.) and integrate an editor for text and batch files, or create common batch files themselves.

•	PANKEY (Richard Pankhurst, r.pankhurst@rbge.org.uk): http:// www.rbge.org.uk /pankey.html. Extensive set of tools, comparable or exceeding Dallwitz's Confor/Delfor/Intkey program suite in scope. PANKEY uses DELTA version 3. It creates natural language descriptions (allowing user defined output) and dichotomous keys (in automatic or semiautomatic mode). Also includes the interactive identification program ONLINE and a simple DELTA editor DEDIT. DEDIT has a deep menu structure which makes it difficult to edit characters or character states. The basic DELTA directives can be edited, but some features (like character dependency, character headings, deleting characters, changing the sequence of characters) remain "not implemented". PANKEY (including DEDIT) is only available for DOS. Except for the DEDIT editor it is available only commercially from Exeter publishing.

•	MacPANKEY: 4 programs of PANKEY were ported to the Macintosh operating system by Brian Duff, see http://wiredsoc.ml.org/~pankey/. The user interface is limited to open/save file dialogs to process command batch files.

•	PANDORA (Richard Pankhurst, compare PANKEY): http:// www.rbge.org.uk /research /pandora.home. Pandora is a complete database for managing taxonomic and descriptive biodiversity information. It includes bibliographic information and a collection subsystem sufficient for printing and managing label information. It is the only application besides DeltaAccess which integrates DELTA files into a database. The application is based on a Advanced Revelation (AREV) database (proprietary mixed hierarchical/relational database model called "post relational"; uses multivalued fields; some functionality comparable to PICK). The PANKEY programs can be called from within PANDORA. Currently still only available for DOS, although a Windows version is planned. Since May 1999 it is free and can be downloaded from http://metalab.unc.edu /pub /academic /biology /ecology+evolution /software /pandora.

•	TAXASOFT (Eric Gouda, gouda@cc.ruu.nl): http:// www.ruu.nl.botgard /taxasoft.htm and http:// biodiversity.uno.edu /pub/delta /taxasoft. The program is distributed as shareware, i.e., you must pay a license fee to use them. Includes a DOS editor with a decent user interface, which maintains the consistency of characters, character states, and items during editing, inserting or deleting. Other tools generate natural language descriptions and printed keys. This is not a shell to Dallwitz's suite of DELTA programs (Confor, etc.), but an independent implementation! TAXASOFT sometimes uses DELTA in non-standard ways, which is unfortunately not very well documented.

•	ALICE (R. Allkin, P. J. Winfield, http:// dspace.dial.pipex.com /alice/): A large software package based on a relational database model. It seems to be centered on nomenclatorial features, but provides support for bibliographic and descriptive data as well. DELTA is supported only as an export format. Available only for DOS, commercial product, expensive.

•	BG-Base (http:// rbge-sun1.rbge.org.uk /BG-BASE): A collection database primarily aimed at managing information in botanical garden living collections. The status of DELTA support is not entirely clear, as of July 98 (.../modules.htm, 'Descriptor module') it was marked as 'under development', while other documents seemed to assume it had been finished. DELTA seems to be is supported only as an export format. BG-Base uses the same database software as PANDORA (see above). Available only for DOS, commercial product, pricing information could not be found on the website.

•	Nexus Data Editor, NDE (Roderick Page, http:// taxonomy.zoology.gla.ac.uk /rod/NDE /nde.html) is primarily aimed at editing NEXUS files, but it can read and write the categorical characters (OM/UM) from a DELTA coded text file, and can save the data matrix from a NEXUS file as a DELTA file. According to the author himself NDE is in a very early stage of development (version 0.1.1, crashes frequently). Despite the early development stage a very promising tool for the future. Freely available for Windows 95, NT 4.0 or later.

•	CABIKey (CAB International, author: I. White, http:// www.cabi.org /catalog /cabikey /cabikey.htm): CABIKey consists of a player and an editing module. The latter is able to import and export part of the information contained in a DELTA file (separately for Pankey- and Confor-compatible DELTA files). Neither the player nor the editor can, to my knowledge, be purchased directly. Only finished identification packages for the various groups are sold by CAB. Available for DOS and Windows. The program must be paid with each (quite expensive …) identification package.

•	LucID (Cooperative Research Centre for Tropical Pest Management): http:// www.ctpm.uq.edu.au /Software /Lucid.html. An interactive "key player" for interactive identification and a builder for these keys. Commercial program. The builder can import part of the information contained in a standard DELTA version 3 file. Export to DELTA files does not seem possible. Warning: Before settling on this program, check how many character states it supports. The analyzed version seemed to be limited to 20 character states per character, and a complete redesign of the non-normalized data structure would be necessary to circumvent this limitation.

Web interfaces

•	NaviKey (Version 2,0 has now been released!) is an internet application for identification purposes. It is a Java applet/servlet. It was written by Michael Bartley (mbartley@fas.harvard.edu) and Noel Cross, see http:// www.herbaria.harvard.edu /computerlab /web_keys /navikey. It is free, unsupported software.

•	DeltaAccess Perl is a perl/CGI script interfacing to DeltaAccess style tables for interactive identification over the web. It was written by Noel Cross, see http:// www.herbaria.harvard.edu /computerlab /web_keys /delta_access_perl.html. It is no longer maintained because of the creation of the more sophisticated NaviKey (see above). The advantage of DeltaAccess Perl over NaviKey is that is does not require Java, thus running on older browsers and working much better over slow internet connections. A version ('DAP') with some minor updates, capable of running with the current version of DeltaAccess, has been created by Dr. A. Findling and is available (together with a documentation in German) under http://www.lrz-muenchen.de/~findling/programs/dap.

•	DeltaAccess Web Interface DAWI (Leibniz Rechenzentrum München, Dr. A. Findling): Developed for information retrieval using Windows NT 4.0 and Microsoft Internet Information Server (IIS) or Personal Web Server (PWS). Freely available (but documentation available only in German), see http://www.lrz-muenchen.de/~findling/programs/dawi.

•	PollyClave (University of Toronto: Libraries and Department of Botany; Royal Ontario Museum): http:// prod.library.utoronto.ca/ polyclave. This is a web based, multiple-entry interactive identification key. It is a CGI web interface provided as ANSI C source code, which you can compile for your own operating system. It reads DELTA files directly. Freely available for research and academic use.

•	WebDelta (Istituto di Scienze Biochimiche, Univ. Parma). A combination of PERL and Java code to provide simple web identifications and access to an image gallery. Reads Delta files directly (only character list, character type, and item description directives). Freely available for non-commercial purposes. See WebDelta (http:// irisbioc.bio.unipr.it /webdelta /webdelta.html) and TuberKey (http:// irisbioc.bio.unipr.it /tuber /tuberkey_english).

Other useful resources related to databases of descriptive information

•	The DELTA home page (http:// www.biodiversity.uno.edu /delta/) is identical with the distribution site for Confor and Intkey mentioned previously. It also hosts much interesting general information regarding DELTA, including extensive literature references.

•	Mauro J. Cavalcanti compiles the Digital Taxonomy home page (http:// www.geocities.com/ RainForest/ Vines/ 8695/). Amongst other things, it contains an overview of DELTA software (http:// www.geocities.com/ RainForest/ Vines/ 8695/ software.html) and a list of data sets (http:// www.geocities.com/ RainForest/ Vines/8695/ data.html). Note though that most data sets are encoded in the proprietary Intkey format, which has nothing to do with DELTA, except that DELTA data sets can be compiled into the Intkey format. The data sets are therefore essentially read-protected.

•	Two very useful lists of interactive identification programs (whether they support DELTA or not) are maintained by Mike Dallwitz (http:// www.keil.ukans.edu /delta/www/idprogs.htm) and Marco Bleeker (http:// www.euronet.nl/ users/ mbleeker/ prog/ swtaxlst.html).

•	The current TDWG standards are listed on http://www.tdwg.org/standrds.html.

•	See also the Internet directory for botany: Software (http:// www.helsinki.fi/ kmus/ botsoft.html).

Main table of contents    [image] Next


Import and export, Table of contents
 DeltaAccess –
a SQL interface to DELTA (Description Language for Taxonomy), implemented in Microsoft Access

Main dialog box, import and export

   The Switchboard
   Introduction to the main DeltaAccess dialog box
   Importing data
   Which DELTA files should be imported?
   What happened to the character name during import?
   What happened to my units?
   Importing subsets (include/exclude items/characters)
   Exporting data
   Creating natural language item descriptions
   Creating item descriptions as HTML forms
   Next table of contents: Project management

Previous table of contents    [image] Main table of contents    [image] Next


The DeltaAccess menu
 The Switchboard

DeltaAccess provides a switchboard dialog box (form 'Switchboard'), which can be used instead of the database explorer(1) to open the other forms and dialog boxes. You can always reach the switchboard using the [image] -button in the tool bar.

On the left side of the dialog box you can select the task you want to do. On the right side you can optionally choose a project name of an existing descriptor project. Some tasks ignore the project name, e. g., importing DELTA text files into a new project. If the project name is required for a task and you have not selected a descriptor project, you will be prompted to select a project later.

When you select a task, a short description will be displayed at the bottom of the dialog box. Similarly, when you select a project, the project title, project authors, and copyright (see Editing project properties), will be displayed in the same space.

Double-clicking on either a task or a project name will directly start the selected task with the selected project.

Note: DeltaAccess currently does not use any true menus (= the entries immediately below the title bar of the application window). The menus you see are the unchanged Microsoft Access menus. So far I found it too much work to use menus, since Microsoft has changed the programming of menus in every version of Access. I may introduce menus for Microsoft Access97 in a later version of DeltaAccess.

Main table of contents    [image] Next


The DeltaAccess Switchboard, function in runtime version
(1) The Switchboard form is necessary if you run DeltaAccess under a run-time version of Microsoft Access. No database explorer is available in the run-time version. You will quit DeltaAccess completely, if you close the switchboard under the run-time version.


Project Name
The project name identifies your descriptor project in DeltaAccess. You can keep multiple descriptor projects in a single version of DeltaAccess, e.g. import several DELTA data sets. Descriptor projects can be either entirely independent, or they can be linked to each other. The project name is also used as the prefix for table names and editing forms.

A project name can contain 1 to 20 characters, and may not contain the following special characters "-", ".", "!", "[", "]", "`", and " " (= blank).


 Introduction to the main DeltaAccess dialog box

	Who should read this: This chapter is relevant only if you open the form named DeltaAccess manually from the database explorer. It does not apply if you normally use the DeltaAccess Switchboard. You will then use the same views of the dialog box, but they will appear as independent dialog boxes.
The form DeltaAccess contains the import, management, analysis, and export dialog boxes. If you open it manually from the database explorer, you can select on the right hand side of the dialog box whether you want to:
   import data from a set of DELTA files into a DeltaAccess descriptor project,
   manage projects (create, copy, link, or delete descriptor projects, etc.),
   analyze or edit data, or
   export data from the tables of a descriptor project to a DELTA text file of other formats.

The left part of the dialog box will display the appropriate controls for each option. Common to all options is the setting of a project name, which identifies your descriptor project in DeltaAccess. The 4 different options of the DeltaAccess dialog box are described in the following sections:
   Importing data
   Managing projects
   Analyzing data
   Exporting data

Main table of contents    [image] Next


 Importing data

	Who should read this: Users who already worked with DELTA and want to import one or several existing projects using DELTA coded text files as a data interchange format. If you do not have DELTA files to import, please continue with the next major section Manage projects.

(This is a hypergraphic)

DeltaAccess works with multiple data sets called a project. Each project is equivalent to a DELTA file in Pankey/Pandora, or a set of files (items, specs, chars) in Confor. To import data you must enter a project name. If you have previously used Confor, you probably have separate directories for each DELTA data set, so the name of the directory would be a good choice for the project name.

If you are using Pankey, your data are probably in a single file. Enter the name of this file under Import file name. You can click on the button with the open-folder-symbol ( [image]) to select the files using a dialog box.

If your data set consists of multiple files (e.g. Items, Chars, and Specs used by Dallwitz's Confor) you should select any file (e.g. Chars). The checkbox Import all "Confor" files: Chars, Specs, Items, etc. is automatically activated in this case. This causes DeltaAccess to search for the commonly used files. See the following chapter Which DELTA files should be imported? for more information.

If your import file contains Include/Exclude Character/Items directives, the complete set of data is imported, and a separate subset honoring these directives is created. Consult the chapter Importing subsets for information on how to import subsets separately.

The following options are available for import:

•	Item name comments are authors: By default notes or comments after the item name (i. e. text enclosed in "<>") will be read into the ItemNote attribute. If you activate this option, such notes are interpreted as author names and read together with the item name into the ItemName attribute. If your data set uses item name comments for both purposes, select the most frequent one, and manually edit the item definition afterwards.

•	Convert weights: By default Character and Item weights are converted into Reliability/Abundance values. If you uncheck this option, the directives Character reliabilities / Character weights and Item abundances / Item weights are treated as synonyms and no conversion occurs.

•	Use extended numeric attributes: See Extended numeric attributes for the difference between the standard attributes defined in DELTA (Min, Range, Mean, Max) and the ability of DeltaAccess to make available additional attributes like sample size and standard deviation.

•	Character set: if you choose ASCII, the extended ASCII characters in the range of 128-255 are converted into their ANSI equivalent where possible.

•	Create editing forms: Normally, editing forms should be created for a new project. If you use DeltaAccess only as a link to another database, you can disable this time-consuming process. You can later add forms to a project using the Add forms management option.

The import process has several limitations: Neither line numbers nor the "data compression" option are allowed. You can use M. Dallwitz's Confor program to remove these features. Empty comments ('<>') are removed, i. e. they will be missing when the data are later exported back to DELTA file format.

Some problems arise with the mixed use of OR (/), AND (&), and TO (-) for character states of the same character, and with the use of multiple numerical entities within a single character. (Multiple statistics like mean, median, s. d., s. e., etc., for one entity are no problem, but multiple minima or maxima are a problem.) See the chapter Limitations for a comprehensive overview of supported directives and problems that may arise during import.

Note that there is no such thing as a unique character name in DELTA. The DELTA character string as used by Confor identifies the character and provides natural language output as well. It may consist of a comment alone or be empty altogether. In contrast, DeltaAccess requires unique character names. It tries to use the information from the input file, and appends random numbers to create unique names if necessary. Consult the chapters What happens to the character name during import? and What happened to my units? for further details.

As a result of these limitations you might receive several warning messages. A typical warning message is "A random number was appended to the following duplicate values to achieve unique names in the field 'CharName': blades structure (CID=36.); scape (CID=60.)". DELTA does not require characters to have a unique name, but DeltaAccess does. The warning message means that two characters had the name "blades structure" and two other characters had the name "scape". The character names of the characters with number 36 and 60 were automatically modified so that all characters have unique names.

You can later check the warning messages again in the _PROPERTY table property OriginalImportWarnings. Other information stored as properties are:

•	the Comments property contains the Comment directives,

•	the ProjectTitle property contains the Heading directive, and

•	the OriginalImportSkippedDirectives property contains all directives not recognized by DeltaAccess. You should check this property when you start to use DeltaAccess, to see which of your directives are being ignored.

See Editing project properties for further information about how to view and edit project properties.

You can not import character definition or item data separately, e. g., to overwrite the item data, but preserve the character and item definition. For a method to accomplish this task nevertheless, see the overwrite action of the management dialog box.

Introduction to the DeltaAccess dialog box    [image] Main table of contents    [image] Next


 Which DELTA files should be imported?

If you are using Richard Pankhurst's Pankey all your data are probably in a single file. Import this file.

If you are using Mike Dallwitz's Confor or Eric Gouda's TAXASOFT, you are probably using multiple files. The main files are usually called Items, Chars, and Specs. Please note that some information important to DeltaAccess is usually not present in the 3 main files, but in additional 'batch' files, e. g. ToInt, ToKey, ToNat, or Intkey.ini. DELTA, as used by the Confor program, does not distinguish between data directives and program command directives. Some directives, which could well be viewed as formatting commands, are treated as data by DeltaAccess. For example, the Character Reliabilities and Key States directives might be available only in the ToKey command batch file, and the New Paragraphs, Item Subheadings, and Link Characters directives only in the ToNat command batch file. See the List of supported directives for information about which directives can be imported by the current version of DeltaAccess.

DeltaAccess will automatically search for these files if you activate the checkbox Import all "Confor" files: Chars, Specs, Items, etc. The following files will automatically be imported: 'Chars', 'Specs', 'Items', 'Extra', 'CNotes', 'CImages', 'TImages', 'ToInt', 'ToNat', 'ToKey', 'ToDis', and 'Intkey.ini'. 'Extra' is an additional file used by DeltaAccess for its own directives and is present only if the data set was previously exported by DeltaAccess. The only information imported from intkey.ini is currently the Define characters directive. If you use additional files, DeltaAccess will automatically include them as well, as long as they are referenced by an INPUT FILE directives in one or several of the files listed above.

DeltaAccess is not sensitive to multiple appearances of the same directive. For most directives it will simply import the first version of a directive.

You can import one set of Include/Exclude Character/Items directives together with your data. Further sets can be imported in separate files, see the chapter Importing subsets.

Importing data    [image] Main table of contents    [image] Next


 What happened to the character name during import?

	Who should read this: Users who are experienced with DELTA and want to understand how DeltaAccess modifies the data during the import process.
Because DELTA mixes the functions of character name (unique identifier for a character, suitable for data entry, retrieval and interactive identification) and character phrase (optimized for natural language output), some extra processing is necessary during import. First, if a unit-string is present, it is removed and written to the separate Unit attribute.

The resulting string is written directly to CharPhrase. This is the only place, where the DELTA comment brackets "<>" are preserved in DeltaAccess. You might want to use them for some special formatting in other DELTA programs like Pankey, TAXASOFT,or Confor.

The CharName attribute is constructed from CharPhrase, by appending the notes without brackets. DeltaAccess requires the name to be unique. If the same name occurs multiple times, a random number must be appended to the second and further occurrences of the same name. Usually it will be advisable to manually edit the CharName attribute after import, to create short and precise character names for data entry and identification.

If CharName, CharPhrase, or Unit are longer than 255 characters, they will be truncated to 255 character. You will be warned about this in the message displayed at the end of the import process.

Importing data    [image] Main table of contents    [image] Next


 What happened to my units?

	Who should read this: Users who are experienced with DELTA and want to understand how DeltaAccess modifies the data during the import process.
After the character name in a DELTA character list, an optional measurement Unit can be placed, like "mm" in the following example:

   #6. length/ mm/

Units for numerical characters are fully supported by DeltaAccess (please inform me if you are missing them in some report or output, I may have forgotten to include them there).

Units for text characters are not defined in DELTA and make no sense. If DeltaAccess detects them in an import file, they are preserved, but never used.

Problematic are units after categorical characters (UM/OM). They are not officially allowed in DELTA version 3, but are frequently used, esp. by users of TAXASOFT. They are used for repeating phrases after the character states. This is considerably more difficult to handle in a database, because the descriptive string for a character state must be assembled each time it is used, e. g., during data entry or identification. I see no reason why the text entered under Unit should not be at the end of each character state, even if this means pasting some text into several states. I also consider this a better solution for multi-language data sets (i.e., several languages concurrently available in a single descriptor project) because languages will differ in their ability to use a common end phrase for a set of character states.

The answer to the question "What happened to my units?" in the case of categorical characters is therefore: They have been appended to the end of the character state name during the import procedure.

Importing data    [image] Main table of contents    [image] Next


 Importing subsets (include/exclude items/characters)

When the import process detects one of the following directives:
   Include Items,
   Exclude Items,
   Include Characters, or
   Exclude Characters

it will create an Item subset, a Character subset, or both. If the DELTA file contains data (i.e. at least the character list and item description directives) as well as these directives, the subset is automatically based on the imported data. The name entered under project name is used for the main project, and a name for the additional subset is requested.

If the imported DELTA text file contains no data directives, you will be asked upon which existing project the subset should be based. The name entered under project name is now used for the subset project. Thus, to import several predefined subsets, and link them to existing projects, you should import these directives alone. A file to import an additional subset definition could, for example, contain just the following lines:

*EXCLUDE CHARACTERS 1 4-7 71-96
*INCLUDE ITEMS 1-120 310-420

Avoid importing subsets using batch files, which contain references to the Items, Chars, and Specs files in addition to the include/exclude directives. Importing such files will import the data independently for each subset. Although you will have successfully imported the subset for analysis functions, you will not be able to edit the underlying data for all subsets simultaneously, because multiple copies will exist. Create copies with the include/exclude directives alone, and import these files into DeltaAccess.

Importing data    [image] Main table of contents    [image] Next


 Exporting data

(This is a hypergraphic)

After you have selected the main option Export to file from the pick list, you must select the project name, the name of the file into which the data shall be exported, and an export format. Available export formats are:

•	DELTA text file: version 3 to 4 of the DELTA standard file format. The "New DELTA" format can probably not be supported, but upcoming versions of M. Dallwitz's Confor will always be able to import DELTA version 3 or 4 data. See below for additional information.

•	Strict DELTA: similar to DELTA, but modifiers will be placed after a character states, while the normal export places them in front of the state (which is not standard DELTA, but compatible with current usage, e. g. by TAXASOFT). Further, new directives defined by DeltaAccess are omitted; thus some information may thus be lost when re-importing such a file to DeltaAccess. The Strict DELTA option is provided for improved compatibility with Confor, which crashes when encountering directives not defined by itself, see also the following chapter Variants of the DELTA format.

•	Natural language description (*.RTF): see Creating natural language item descriptions.

•	HTML Tab-separated text file (*.HTM): The fields of each table of the descriptor project are exported as a separate HTML document containing an HTML table. (Note that HTML tables can be re-imported by MS Access!)

•	Comma-separated text file (*.CSV): all fields of the table are separated by a comma; the text is enclosed in quotes (""). Quotes already in the text are doubled. The decimal separator will be used for numerical values. In some language settings of Windows, the fields may be separated by a semicolon (";") instead of a comma (",").

•	Access-file (*.MDB): A new Microsoft Access database file, containing only the tables of the selected descriptor project will be created. The indexes and relational integrity are removed to make the file more compact. This export option uses the same functions used by the backup to database dialog box, see the chapter Backup and restore for further details.

•	Excel-file (*.XLS): Each table is saved as a separate Excel file. The file format used is Excel 8 (= Excel 97). Note that Excel is limited in the number of rows it can handle, and the amount of text you can have in a single cell, so your data may be truncated. Normally you would not want to export your raw descriptor project data to Excel, but only the results of analysis queries. Consult the chapter Cross-tabulation (crosstab) queries, pivot analysis in Excel for details of exporting analysis results to Excel.

All formats use the period (".") as decimal separator in numbers, to be internationally compatible. If your national settings are different and you experience problems importing, e. g., a CSV file into MS Excel, you should temporarily change the settings in the Windows control panel, applet International, to a period and change it back after import.

If you choose the ASCII character set, ANSI characters are converted into their (IBM/DOS) equivalents where possible. This option is applicable only to some formats.

If you select DELTA text file, you can choose whether to Export into a single file (preferred by DeltaAccess and Pankey) or whether to use separate multiple files for ITEMS, CHARS, and SPECS. If you enter ITEMS as a character name, the other files will be named CHARS and SPECS, otherwise the extensions '.CHARS' and '.SPECS' are appended to the filename you have entered. A fourth file named 'EXTRA' is used to export the additional directives defined by DeltaAccess, see also the following chapter Variants of the DELTA format.

Related topics: To export a formatted report of the current character definition, use the tabular character definition report and export it to Word (see Office Links).

Introduction to the DeltaAccess dialog box    [image] Main table of contents    [image] Next


 Variants of the DELTA format

Since there are already many variant DELTA dialects, files exported by DeltaAccess will generally differ from the import files. With few exceptions, the data will be identical, but the formatting may be more difficult to read, e.g. because no range notation ("1-3") is used in the output. Also, you may have to adjust the wording of the directive, if your preferred tool does not support the directive name I use for output. I am open to criticism about which directive names should be preferred.

In many ways, DeltaAccess provides features that are not supported in standard DELTA. To improve the usability of the DELTA format for export and reimport into DeltaAccess, additional DeltaAccess-directives have been defined. Unfortunately, M. Dallwitz's Confor aborts whenever it encounters a directive which has not been defined by Mike Dallwitz and his coworkers. This is a violation of the DELTA standard, which explicitly states that programs should skip any unknown directives which they encounter.

To solve this problem, two solutions are provided: - 1. If you select the multiple files option, the special DeltaAccess directives will be written to a separate file named EXTRA. Since Confor normally does not read this file, the data remain compatible with Confor. - 2. If you want your data in a single file, you can select the export option Strict DELTA. DELTA coded files created using this option include only directives defined by Confor itself.

Currently the export of additional features of DeltaAccess back to DELTA files is still under development, so that not all DeltaAccess features will be preserved when a descriptor project is exported to DELTA and re-imported into DeltaAccess. For this reason, the preferred format for backup copies of a project should be the internal backup in MDB format, see the chapter Backup and restore for further details.

Notes on specific problems: The DELTA character "name" is imported into the CharPhrase attribute, and if a CharPhrase is present it is preferred during export over the CharName attribute. The Notes originally extracted from ItemName comments are exported as a separate directive. The LitRef/CollUnit attributes are not yet exported. Modifiers are added back as item description notes, but slight changes compared with the original description may occur.

DeltaAccess allows the character numbers (CID) to be non-continuous (e.g. 1, 2, 4, 5). Many other DELTA compatible programs including Confor will not import such a data set. The CID numbers need to be renumbered, e.g. using the auto-resequence utility of the Reorganize form. Since this would permanently change the project that is exported, it is not done automatically, but an appropriate warning will be issued upon trying to export a descriptor project with non-continuous character numbers to DELTA.

TAXASOFT style comments (before and after the character state) are imported using the pipe symbol '|'. This is resolved during export to natural language by DeltaAccess, but not when exporting to DELTA files, since the TAXASOFT style is incompatible with other DELTA programs. Instead you will find entries like "8,1<bright yellow- | and often white-cretaceous> " " in your export file.

Compare also the chapter Limitations and the table of recognized DELTA directives.

Introduction to the DeltaAccess dialog box    [image] Main table of contents    [image] Next


 Creating natural language item descriptions

In most taxonomic monographs, in addition to the information provided in dichotomous or synoptic keys, each taxon is described in a coherent text, which may look like the following example:

Stromata small, superficial, orbicular to elongate, at first gray, later black, 1-3 x 1-2 mm and 0.5 mm high; perithecia semiglobose, 0.5-0.6 mm in diam. with papillate ostiola; asci cylindric, 80-90 x 7-11 µm; ascospores uniseriate, elliptical, with obtuse ends, dark brown, often with large oil drop in center, 15-18 x 5-8 µm; paraphyses present.

The creation of natural language descriptions from a descriptor project is a relatively straightforward process. For each character present in a given item, the natural language phrase for the character (CharPhrase, if missing CharName can be used instead) is output and the character state name is appended to it. In the case of numeric characters, the numeric values and the optional Unit is appended to the character phrase. If several character states are present, the states are appended with or, and, or to as defined in the MultistateType attribute. If the states present in the current item all end with the same words, these words can be omitted except for the last state. Similarly, if several characters start with the same words, and are defined as a LinkGroup, the start of the characters is abbreviated. Any text in larger/smaller signs (<>) is omitted in the natural language description (this is the only place where DeltaAccess respects this DELTA convention, otherwise it resolves all comments during import and stores them in appropriate attributes).

Thus, if all characters in the following example form a single link group:

#1. leaves <hairiness>/

    1. not hairy/

    2. sparsely hairy/

    3. densely hairy/

#2. leaves <shape>/

    1. linear/

    2. elliptical/

#3. leaves <length>/

    mm long/

and an item includes the following DELTA codes:

1,2/3 2,1 3,12-20

it would be rendered as:

leaves sparsely or densely hairy; linear; 12-20 mm long

A simple version of such text can be automatically produced from a structured DELTA data set and is called a natural language item description.

(This is a hypergraphic)

The export format Natural language description creates a simple natural language item description, formatted as Rich-Text-Format (RTF). RTF can be read by Microsoft Word and most other word processors under either the Windows or the Macintosh operation system. The natural language export is currently not very sophisticated and rather a "technology preview". I am aware of some places where the output is less than satisfactory. If you are interested in using this feature, you can help improving it by pointing out what it does, and what you expect it to do.

The main reason for this feature is that I want to use it in the next version of DeltaAccess during interactive identification. At present, for generating better natural language descriptions or printed dichotomous keys, I recommend using M. Dallwitz’s Confor or R. Pankhurst's Pankey (see DELTA software sources on the internet).

The following attributes (compare the CharEdit form) are evaluated mainly during Natural language description. Follow the links to obtain more information on an attribute:

•	CharPhrase: Phrase inserted for the character in the natural language description.

•	FormatString: Format for numeric values.

•	ItemSubheading: A subheading inserted into the item description before the first character for which this attribute is set.

•	LinkGroup (= Link characters directive): Consecutive characters having the same LinkGroup number are output as one sentence.

Return to Export    [image] Main table of contents    [image] Next


Creating item descriptions as HTML forms, Overview
 Creating item descriptions as HTML forms

	Who should read this: This chapter is relevant to you if you want to present your data in the internet using HTML forms with clickable checkboxes. Users on the internet can correct existing data or insert new data, and send the results back to you.
The HTML-form creation dialog box writes one or several files formatted in HTML (= hypertext markup language, the format used in the word wide web). This dialog box can be called from the DeltaAccess Switchboard or by opening the form entitled ToHTMLForm in the database explorer.

You can use HTML forms as an off-line editor to add new items or edit existing items over the world-wide-web. See the following chapter for information about re-importing the information you will receive back.

The HTML form generation dialog contains a multitude of options to customize the HTML code generated. Naturally, the amount of options can be confusing. Please note that the only required options are found on the first two tabs, General and Output files. You must select a descriptor project and specify the post method and address to which the edited data shall be returned. With these minimum settings, you can already generate a form for new items. Beyond that, the three most useful things you can do to optimize the output are:

•	Set the project properties (ProjectAuthors, ProjectEditors, ProjectCopyright, ProjectTitle, and ProjectIcon) which are used in the default header of the forms. See Editing project properties for further information about how to view and edit project properties.

•	Revise your character definition and set the MultistateType to Exclusive (= 0) for all characters which are not really multistate, i. e. where only a single state may be present in any item. If you are importing DELTA files, you achieve the same effect by using the appropriate character types EUM/EOM for these characters.

•	If you have numerical characters where a range or minimum/maximum is never expected (e. g. "number of species in genus") you should revise the character definition within DeltaAccess, deleting the unwanted numerical states. Consult the paragraph Numerical attributes at the end of Output options for further information.

The number of parameters available (more than 80 parameters can be set) makes it likely that some combination may not work as expected. Please contact me in this case, providing a documentation of your settings, an example of an HTML form which looks unexpected, and either a description of what you expected, or a manually edited HTML form (perhaps one character only) which confirms to your expectations. Please try the default settings first and modify them only if you find them unsatisfactorily.

The following sections discuss the options on each tab page:

   General
   Output files
   Index file
   Include files
   Output options
   Formatting options
   Font formatting options
   Localization strings
See also
   Example

Limitations:

You can not use or change a user-defined sequence of character states in an item description, which is different from the default sequence defined in the character definition. In DELTA and in DeltaAccess you can specify for a certain item and character, that states "2 or 1 (rarely)" are present. After using an HTML form to update the date, this will be changed to "1 (rarely) or 2".

I may be able to provide additional options for customization. If you want a different appearance for you forms, please modify a form manually, and explain separately what you have done. If this can be done automatically based on the information in a DELTA character definition, I will try to include it in the next version.

Return to Export    [image] Main table of contents    [image] Next


Creating item descriptions as HTML forms, General options
General:

On the first tab page you must select a project name. For each descriptor project (including subset projects) you can save all other settings in this dialog to retrieve them later, using the Save settings and Open saved settings buttons placed directly under the project name field. The settings are stored as a property entry in the PROPERTY table. Note that it is possible to "copy" the settings from one project to another: Select the project for which settings have been previously stored, click on Open saved settings, select the project for which you want to use the settings and click on Save settings.

The option Form, post action at the bottom of the tab page determines how you want to retrieve information sent back to you over the World Wide Web. If a user presses the Send item description button in her or his web browser, the browser will send the contents of all elements in the form over the internet using a "post" action. This information will be sent to the URL that you entered in the field at the bottom of this tab page.

The simplest way to retrieve the information is to enter a mailto-action in this field. This is especially useful if you do not have direct access to a web server, which would have to react to other types of URLs. You will receive an email under the address you enter here, containing the returned data in an encoded format. See the following chapter for information about re-importing the information you will receive back. Example: If your email address were yourname@yourserver.edu, you would enter 'mailto:yourname@yourserver.edu' (without the quotation marks) in the post action field.

If you want to program a web server to directly react to the action, you can enter a full URL, or simply a path. If you enter /Delta/response/ the web browser would sent the reply to this folder on the same server from which the form was received by the browser.

Return to HTML form overview    [image] Main table of contents    [image] Next


Creating item descriptions as HTML forms, Output file options
Output files:

On this tab page you can select which HTML documents the procedure will generate, and how they shall be named. Available options are

Empty form for a new item: Create an empty form directly from the character definition. This form can be used to add completely new items to a descriptor project over the internet.

Filename for new item form: You must enter at least one filename, which will be used directly for the new item form. You can use the button with the save icon ( [image]) to select the path and filename using a dialog box.

Note that the empty item form will be without any data at all (the 'implicit' attribute of the character state definition is not yet observed). If you want to create "new item forms" which already contain default settings for several characters, you should create a pseudo-item in your descriptor project with the appropriate settings, and use the form created by this item as the new item form. However, you currently must manually change one setting of the form. If the item you use as a template has the item ID (IID) 1, open the form in a text editor, and replace the string 'DHF_IID1' with 'DHF_IID0' ('0' indicates that the data are to be treated as a new item and not to modify an existing item).

Forms for each existing item: Create a similar form for each existing item in the current descriptor project. The fields of the form will already contain the information that is present in the database. Thus, text fields will be filled, and checkboxes or radio buttons appropriately set.

Limit output ...: Below the checkbox, you can optionally enter a list of IID numbers. Only the items with these IID numbers will be output. Click on the [image] -button to change the list of items. You can also directly enter IID numbers separated by comma, semicolon, or blanks (example: "1, 3; 48 283"). All items will be output if you leave this field empty. Note: This list is primarily intended to manually update one or few item forms. Create a full item subset project for more complex selections, or for a subset in which also some characters shall be omitted (see character subsets).

Filenames for existing items: The HTML documents for existing item descriptions are always written into the same directory as the form for the new item. An option group gives you 3 possible choices which filename will be used for items: Using the item ID (IID number alone), appending the IID to the name used for the new item form (e. g., if the new item form name is 'forms.html', the item with IID=3 will be written to 'forms.003.html'), or using the item name as filename. Several problems exist, if you choose to use the item name option: the item name may be too long, it may contain characters not compatible with a file name, and it may not be unique. See Rules for filenames based on item names and Integrating HTML forms or natural-language-description documents into other applications. for more information.

Return to HTML form overview    [image] Main table of contents    [image] Next


Creating item descriptions as HTML forms, Index file options
Index file:

The options on this page are only available if the option Forms for each existing item on the previous tab page has been selected.

Additional index file index.html: To help with the generation of a web site with many item description forms, a basic HTML index file is generated. It contains hyperlinks to all HTML forms generated. The index file contains the same header as the item forms, which may not always be appropriate. It is assumed that the index will generally be manually incorporated into a more complex HTML document. The index file is always named Index.html. You can rename it if you want to support HTML forms from several descriptor projects in a single folder.

Sort index by: You can further choose in which order the links to the item forms are included in the index file. This also influences how the entries in the index are written. If you choose IID, the entries will start with the IID followed by the item name, if you choose item name, the item name comes first followed by the IID in brackets. Note that for technical reasons, you can not sort the index by IID if you derive the filenames from item names (= third option in the filenames option group, see previous tab page).

Internal index: The entries on the right side concern an additional internal index within the index file. This internal index helps to jump directly within the list of item links to all items starting with a certain letter. An internal index is especially useful if the index contains several hundred items. This option is meaningful and available only if the index is sorted by item names (see previous option).

Internal 1st-letter alphabetical index: Enables the internal index and the associated options. At the start of the index document, each letter of the alphabet with which at least one item starts is added as a hyperlink. Clicking on a letter jumps directly to those items in the index starting with this letter.

Two variants are available: On first word of item name provides a new link whenever the first letter of the item name changes. This is useful if you have, e.g., a list with many genera and not too many species in each genus. On second word of item name provides a new link whenever either the first word of the item name (which is usually the genus) or the first letter of the second word of the item name (which is usually the species name, but may be the author if your descriptor project includes the genera themselves) changes. A new list of first letter characters will be started for each genus. Example:

Item names	First word index	Second word index
Anathema excelsior Anathema erasii Anathema xanthippii Bertholdia arnoldii Bertholdia borriquino Deltaria janthii	A B D (Note that 'C' is present neither in the item names nor in the index)	Anathema E X Bertholdia A B Deltaria J
Known limitations: The internal index will not work very well if you use the variant item notation defined in DELTA (but not yet supported by DeltaAccess). The item name of variant DELTA items starts with a '+'.

The option Add horizontal line at new 1st letter inserts a horizontal line whenever the first letter of the item name changes.

The option labeled Link prefix may contain the publishing folder for the item descriptions. The text in this field becomes part of the hypertext link in the index file. If it is left empty, most web browser will work well as long as the file is placed in the same directory as the index file. If the prefix does not end with a slash ('/'), a slash will be appended. An example for a valid link prefix would be: http://www.bgbm.fu-berlin.de /Projects/DeltaAccess/

Return to HTML form overview    [image] Main table of contents    [image] Next


Creating item descriptions as HTML forms, Include file options
Include files:

This tab page allows to define two include files, which will be included before and after the form part in each HTML document created.

The include files should contain text or HTML codes which can be inserted directly into the HTML files generated by this procedure. The text read from the include files will not be modified in any way, thus you can use any HTML formatting you wish to. On the other hand, you must already transcribe things like accented characters into their HTML transcriptions (e. g. use "&uuml;" for "ü").

The include files may not be a full HTML files though. They may not contain the usual <HTML></HTML> start and end codes, and they may not include any header information. To produce include files, it is easiest to modify an existing form in any HTML editor, save the file, and open it with a plain text editor. Then copy the start and end part, which shall be inserted into the new HTML forms, into separate files.

Normally, DeltaAccess will produce a default HTML header, which includes information read from the project properties ProjectAuthors, ProjectCopyright, ProjectTitle, and ProjectIcon (see Editing project properties for further information about how to view and edit project properties). You also have the option to customize the HTML color definitions used in this default header. The color definitions define which colors are used in the web browser for text, background, and links.

Alternatively, you can select the option to Replace the default start with the include file for the start. In this case, in contrast to what was said above, the start file must include all necessary HTML start and header tags. Still, it may not include an </HTML> tag indicating the end of the HTML file.

Return to HTML form overview    [image] Main table of contents    [image] Next


Creating item descriptions as HTML forms, Output options
Output options:

This tab page offers the option to define the information included in the HTML forms generated. Except perhaps for the option to include headings (which improves the structure and usability of the item descriptions), the options on this page increase the complexity of the forms and make them more difficult to use. Choosing the right balance between easy-to-use forms and including all information is often difficult. The default settings will export all available information, but do not, for example, allow entering notes for a newly selected character state. If you want to use the forms for true revision over the internet, you should not restrict the output further, or you may loose information during the revision. On the other hand, if you mainly want to present your data, and use the forms to get a more general feedback from your colleagues, you can disable special character states (like U/V/-) and even omit all modifiers or notes.

Include headings from character definition: If you have added headings to your character definition and defined them as CharHeading or ItemSubheading, you can improve the structure of the item descriptions form by inserting the appropriate headings in front of the character group to which they apply. See the chapter about the heading editor (EditHeadings) for further information about headings.

Internal navigation within the HTML document using headings: If add internal index of headings at top is checked, a bookmark will be added to each heading and a hyperlink index for the heading bookmarks will be added at the start of each HTML form document. This enables the user to jump directly to a specific heading instead of scrolling down to find the relevant information. The "'Go-to'-phrase for internal index" on the tab page Localization strings 2 is used in front of this hyperlink index. The checkbox is disabled if no headings are included. If add link back to index after each head. is checked as well, a hyperlink (text or image) is inserted after each heading, to return to the index of headings at the top of the HTML document. The "'Back-to-index'-phrase or image" on the tab page Localization strings 2 determines the text of the hyperlink (default: "-- back to index"). If this phrase ends with '.gif', '.jpg', or '.png' it is assumed to be a relative or absolute URL to an image that you supply. Please contact me if you need to use other file extensions than the 3 mentioned above.

Special character state options: Special character states (U/V/-/TE, for Unknown, Variable, Not applicable, or Special text, respectively) are not included in a DELTA import file. Since they are implicit in the definition of the DELTA format, DeltaAccess adds them automatically during import. The default settings of the HTML form generation dialog box ensures that all existing special character states are included in the item description output. The option Autodetect ensures, for each character separately, that whenever a special character state has been used in at least one item, it will be included in the form for all items. This setting will usually work well with descriptor projects that already contain many items. An exception is the special character state 'TE' in categorical or numerical characters. Since it must either be already used in an imported data set or manually added to the character definition, it is output wherever it has been defined (option Always). You can also suppress the use of special states (option Never). Please note, that suppressing information will cause problems if you want to use the form for the revision of existing items over the web, since you will loose the information encoded by special character states.

Alternatively, you can check in which characters a certain special state has not been used and will never be used. For example, you may not want to use the variable state at all, or the definition of character dependency may be sufficiently well developed that the explicit inapplicable state is never needed. In this case, you can remove these states from the character state list in the character definition; see the character states section of the character definition editor (CharEdit). Special character states removed from the character definition are not included even when the option Always is used.

Numerical attributes (Min, Max, Ranges, etc.): Sometimes, a minimum and a maximum may not be appropriate for a real or integer numeric character. Currently no option is available to skip some numerical attributes for a subset of the numerical characters. A future version of DeltaAccess could use an Autodetect mechanism similar to the one used for special character states (see above). Nevertheless, you can eliminate the inclusion of Min, Max, or Ranges in the HTML form. Since an imported DELTA definition lacks any information about this, DeltaAccess adds these attributes during import. It does not require them to be present though. Within DeltaAccess, you can define exactly which numerical attributes you want to be preset. You can simply delete the unwanted numerical attributes in the character states section of the character definition editor (CharEdit). Note that if Mean, Median, Mode, or Value are left as the single numerical attribute, the HTML form will include it without the usual table display and without a label. It is assumed that the character name gives sufficient explanation in this case.

Include item descriptions … Notes (= comments) and Modifiers:

At the bottom of the output options tab page you can determine the rules for adding item description Notes and Modifier attributes to characters or character states. Notes are equivalent to the standard DELTA comments (which are no true comments, but data items). Modifiers are a special feature of DeltaAccess. During import of a DELTA file, many comments are recognized as modifiers and removed from the notes. See the chapter Introduction to the concept of modifiers for further information.

Adding a text field for inserting the modifier and the note for each character state makes the resulting forms look rather chaotic. Most of these fields will not be used, since usually only 1 or 2 character states are active, and you can add notes only to activated checkboxes (note that this can not be enforced in the HTML form itself!).

The default settings are therefore to output only existing modifiers and notes. This allows a complete revision of the data for existing items, but no new notes or modifiers can be entered. As an alternative to adding a text box for notes for each character, you can select the option existing, plus single new. This will output an editable text field for any note which is already present in the data set. In addition, it will add one further text field to enter a new note. The state to which the new note applies can be selected from a pick list of all available states.

The settings can be set separately for categorical (type UM/OM), numerical (type RN/IN), and text (type TE) characters. Modifiers are not defined for text characters, and since only a single Note can be added to a text character, the option existing, plus single new is not available here.

Return to HTML form overview    [image] Main table of contents    [image] Next


Creating item descriptions as HTML forms, Formatting options
Formatting options:

This tab page contains many options to customize the appearance of the forms generated. No setting on this tab page will influence the data included in the form, while settings on the previous Output options tab page influence both the formatting and may suppress existing data.

The first option influences, whether characters will be separated by horizontal lines or not. The default is Not consecutive text/numeric. It means that the horizontal line is skipped between two consecutive text characters (type TE), or two consecutive characters of the same numeric type (RN/IN). Note that lines will be inserted between text and numeric, as well as between real numeric and integer numeric characters. If you select not within LinkGroup, horizontal lines will be suppressed within the LinkGroups defined in the character definition. All characters not in a link group will be separated by a horizontal line. You can edit the link groups in a special editor, see Editing link groups.

The second option is used to enable text boxes with multiple lines and scrollbars. By default, all text characters are output as input boxes, which display only a single line. HTML forms offer multiple line text windows, which include scrollbars (using the <TEXTAREA> HTML tag). You either always use these text boxes, or you can use them only for those characters, which contain a larger amount of text. Enter the character numbers of the desired text characters into the text field below the radio buttons, leaving a blank between the numbers. The button with the lightning symbol ( [image]) will automatically select appropriate text characters. It will include all text characters, where at least in one item description the text is 1.5 times longer than the current width defined for a single line text input field. Click on the [image] -button to change the list of text characters manually.

At the right side, immediately above the radio buttons, you can also change the height of these text boxes in lines. Only text characters can be changed to windowed text boxes; the special text state 'TE' possible for categorical (UM/OM) characters is always treated as single line input field. The HTML text boxes use the tag <TEXTAREA WRAP=SOFT>. This causes lines that are wider than the display area to wrap to a new line. Hard returns inserted by the user are preserved and transmitted back.

The next section is concerned with the width of the available editing elements. The first two define the width of single line normal text, and the multiple-line text boxes. Note that multiple-line text boxes usually appear wider than single line text input boxes, which is why the defaults are set to 70 and 80, respectively. Special text is used whenever the special 'TE' character state has been enabled for a categorical character. This feature of DELTA can be used to allow the user to enter information, which is not available in the list of categorical characters. The phrase used in front of these special text characters can be set on the tab Localization strings. Numeric input is used to enter the values for numeric characters; Modifier text and Notes text are used for the width both of directly output modifiers/notes, as well as for the combination of an additional modifier/note with a character state combo box. Note that modifiers and notes for those numerical attributes that are presented in a table (Min, Max, Mean, etc.) always use the numeric input width as well, to keep the table properly formatted.

The option Observe NewParagraph attribute will insert an additional paragraph in front of each character where the NewParagraph has been set in the character definition.

The option Start each char. state on a new line will start a new line in front of each character state checkbox or radio button. Instead of being displayed as continuous text, wrapping to the width of the web browser window, the states will now be displayed in a tabular form. As long as the browser window is wider than the longest character state phrase, this format may be easier to edit.

The option Observe MultistateType = Exclusive... allows the use of radio buttons or a pick list instead of checkboxes wherever the character is defined as 'exclusive'. These controls are more appropriate than checkboxes for this purpose, since you can only select a single option. If you have many character states, giving all options as check boxes or radio buttons takes up a lot of space and can be confusing to the user. A pick list (= combo box, HTML SELECT tag) is smaller and easier to use in this case. Directly beneath the checkbox, you can set up to how many states radio buttons will be used, and from which number of states onwards a pick list will be used. If you enter a 1, all exclusive characters will be output as a pick list; if you enter a large number like '999' all exclusive characters will be output as radio buttons. By default up to 4 states are output as radio buttons. Note that due to the inclusion or exclusion of special states (U/V/-/TE), the number of states is not necessarily identical with the number of states in the character definition. The number entered here refers to the actual number of radio buttons that will appear on the HTML form. See the Include U, Include V options on the tab page Output options for ways to influence the availability of special states.

Background information on exclusive characters: DELTA supports the character types EOM/EUM for categorical data that allow only a single state in each item. During import to DeltaAccess, this information is converted to the "Exclusive" (= 0) value of the MultistateType attribute. In practice, these character types are rarely used. Before creating HTML forms, you should reconsider your character definition whether more characters should be defined as exclusive. See the analysis option Character state analysis (char. state usage) for a query which can help you to find categorical characters which could potentially be changed to Exclusive.

Return to HTML form overview    [image] Main table of contents    [image] Next


Creating item descriptions as HTML forms, Font options
Fonts:

This tab page contains additional formatting options, mainly the character formats (font name, size, color, bold or italic font).

In addition to the fonts formats itself, the outline level of several parts of the form can be set. An outline level of 0 indicates body text, levels 1 to 4 indicate the first to 4th heading level. If, e. g., character name is set to outline level 3, it will be marked with the HTML tag "<H3>" and displayed with the font, size, and color which was defined in the web browser for this outline level.

The following form elements can be adjusted separately:

Document title and subtitle: the HTML form document starts with a title and subtitle. The subtitle contains information on the authors, editors, project version, etc. These settings apply only if a default document start is created, i.e. not if the option Replace default start on the Include files tab pages was chosen.

Item name: In the current version the setting of item name changes only the label for the editable textbox containing the item name.

Character heading: The format of the optional character heading (or item subheading, see the Output options tab page)

Character name: The label of the character name.

States / description: All other text within a character. In the current version the format of the editable text boxes is not affected, therefore this setting only determines the labels of checkboxes, radio buttons, and pick lists.

Note that too much formatting results in lengthy HTML documents, which may not look identical on all web browsers or may be difficult to read at some screen resolutions. The latter is especially true for the settings of size, which is normally set by the user specifically for her or his web browser. Leaving size empty and font name and color on default settings will preserve the default appearance of HTML documents and will not generate any HTML tags that increase the size of the HTML documents.

Return to HTML form overview    [image] Main table of contents    [image] Next


Creating item descriptions as HTML forms, Localization strings
Localization strings:

All phrases used by the program in the forms generated can be modified on the two tab pages labeled Localization strings 1 and Localization strings 2. This is useful for general customization as well as for the generation of forms in languages other than English.

Note that some formatting features can simply be disabled, by removing the string on the localization tab. For example, you may not want mandatory characters or explicit states to be marked in any way. To achieve this, simply delete the respective localization phrase.

Label for special user code/email address: This adds a field directly above the send/reset buttons of the HTML form, asking for either a user name or the full email address of the person editing the data. When you use a CGI-gateway instead of the 'mailto'-method to receive updates over the internet, you no longer have an email address of the person sending you updates. Some means of verification is usually required. If you use a CGI-script, it can directly reject submissions where this information is missing and inform the user accordingly. Simply remove the label if you do not want this feature.

For modifiers and notes, you can define a start and end phrase. The defaults are simple parenthesis, but you could also use a label like "Modifier:".

The Phrase for add single new and Character state pick list for add single new ... apply only if you have selected the option Existing, plus single new for Notes or Modifiers on the Output options tab page. The sequence of phrases and controls used for these options is (using Notes as example): Notes start [e.g."("]; Character state pick list phrase start; <Pick list to select a character state>; Phrase for add single new note; <Text field for the Notes themselves>; Character state pick list phrase end; Notes end [e.g.")"]. The checkboxes New line after the Phrase for add single new apply only to the single new modifier or note as well. If checked, a new line will be started before the whole add single new sequence.

Return to HTML form overview    [image] Main table of contents    [image] Next


Creating item descriptions as HTML forms, Example
HTML form example

The following excerpt of a DELTA character definition was the basis for the parts of an HTML form shown at the end ("[…]" indicates omissions of part of the definition).

*HEADING LIAS - Genera of lichenized and lichenicolous Ascomycetes
[...]
*CHARACTER TYPES 1-5,TE 42-43,OM 50-51,OM 63,OM 68,IN
69-70,RN 71,OM 81,EUM 88,IN 89-92,TE 94,TE
[...]

*CHARACTER LIST
#1. genus type:/
[...]
#64. ascospores <shape>/
1. ellipsoid/
2. broadly ellipsoid/
[...]
16. semilunate, crescent-shaped, hooked/
#65. ascospores poles <shape>/
1. obtuse/
2. aciculate, apiculate, attenuate/
#66. ascospores <septation type>/
1. aseptate/
2. transversally septate/
3. polarilocular, plurilocular/
4. (sub-)muriform/
#67. ascospores <septa type>/
1. euseptate/
2. distoseptate/
#68. ascospores <transverse (disto-, eu-)septa number>/-septate/
[...]
#81. Ascomycetes order:/
1. Arthoniales/
2. Caliciales/
[...]
[...]
#92. data set revised by/
[...]

*CHARACTER HEADINGS
#1.  Taxonomy and references
#6.  Ecology
[...]

*ITEM DESCRIPTIONS
# Abrothallus De Not. (1845)/
1<Abrothallus bertianus De Not.>
[...]
63,2/3 64,1/2/3 65,1/2 66,2 68,1-3
[...]
81,19
[...]
92<D. Triebel 01-01-98>

[…]

[…]

[…]

Return to HTML form overview    [image] Main table of contents    [image] Next


 Re-importing data send by item descriptions HTML forms

	Who should read this: People who use the item description HTML forms described in the previous chapter, and need a means to re-import the revised or added item description data sent over the internet.
	Note: The HTML form support was new in DeltaAccess version 1.4, and the form generation itself has undergone a number of revisions and seems to be fairly stable. The reimport described in this chapter, however, had to be largely rewritten in version 1.6. If you find a problem please inform me and I will try to create an intermediate version of DeltaAccess including a bug-fix.
Two methods exist to receive the revision information entered by a user on the internet: email and cgi-gateway. This method is determined when the forms are created on the General tab page of the HTML-form creation dialog box.

•	CGI-gateway: This method requires access to an internet web server, on which a small program (often written in Perl) has to be installed. A single program can be used for all your descriptor projects. An example Perl script is currently developed and tested in cooperation with Gerhard Rambold and Loran Pezdirc. This script saves the post information it receives to a file to be further processed by DeltaAccess.

•	Email: This is the simplest way and does not require access to an internet web server. If you are using the mailto:<your_email_address> setup for the form, post action , you will receive an email whenever somebody has sent a revision to you. You should save this email to a file. If possible, save it directly without opening it first, since some email readers will reformat the data during opening, and will save the reformatted data. See Saving posts in common email programs.

In the re-importing form, select the saved email file under 'File containing post:'. If you saved your files with an extension '.dat' they will be directly displayed in the dialog box that appears when you click on the file-open button on the right side; otherwise you must change the file type at the bottom of the file-open dialog box. You may use wildcards (* for any number of letters, ? for a single character) in the filename to import multiple files with a single command. For example, importing 'C:\Data\S*.dat' will try to import any file in the named directory which starts with 'S' and has a file extension 'DAT'.

Please note that, although a project name can be set on the import dialog box, you can leave the field empty if you want to re-import data into the same descriptor project from which the HMTL forms were originally produced. The original project name is part of the data returned to you. You can import data into another descriptor project, but it is your responsibility that the character definitions of the two projects are compatible. The data in the post contain the character ID (CID), so for each CID the character type and available character states must be identical with the original project. Other changes, e.g. in the character or character state name, notes, mandatory definition, etc. provide no problems.

See Re-importing data from HTML forms, Import options for information about the options available on the second tab page of the dialog box.

Click the button 'Re-import HTML form postings' at the bottom of the dialog to perform the import.

If the import process encounters any problems during import, a DELTA coded text containing the information about the current item is displayed. You may use it to identify the problem in the DELTA coded text and use this manually in an DELTA import. Please note that depending on the type of error, the import may have been partially successful and some data may have been added to your descriptor project.

Return to Export    [image] Main table of contents    [image] Next


Saving posts in common email programs

Pegasus (3.01d/W32):	Unopened message: Select from the context menu (right mouse-click on message in the New Mail folder) Save message to file. Opened message: Usually you will already be prompted to save contents to a disk file. In older Pegasus versions, you may have to select Save message to file from the Reader menu. The re-import works with Pegasus Mail for both methods (the resulting files are slightly different!), but the first method is preferred (only here the email headers are available).
Eudora (only version tested: Eudora light, 3.0.6/32):	Normally you can select a message in the In-box, select Save As in the File menu, save as text. For some reason, this does not work with www-postings, they are automatically converted. Open the message with the post and the posting will be placed already as a file in the Attach folder. You can use the file directly from there.
Other:	Please contact me if you have problems with the files saved by your email reader. Please note that I will not be able to help you finding the function to save an email message to a file is in your program--Pegasus is the only email program I use. If you had problems with your program and solved them, you could send me a description and I will insert it here.
Re-importing data from HTML forms    [image] Return to Export    [image] Main table of contents    [image] Next


Re-importing data from HTML forms. Import options

Currently available options are:

Append or overwrite:

Re-imported items contain the ID of the item they were created from. This information can be used to:

•	Append as new item under new IID. The old item remains unchanged under its original item ID (IID) and the revised item is added as a new item under a new IID.

•	Directly overwrite original. This is a dangerous option, since you may loose your original data if the re-imported data are incorrect, or even if the re-import fails. If the old IID is not available, or can not be deleted (e.g. because some records are currently edited and therefore locked), the re-import will create a new item instead like in the first option.

•	Directly overwrite, copy old item to a backup project. Before the item is overwritten, the item definition and description are copied to a backup project. This is the recommended option and it is used by default. The project will remain to function as if the revision had been made in a local item editor, but you can still trace the changes made over the internet. A backup project is a project with independent item tables, linked to the character definition of the base project (i.e. a mixed project) and with the name of the base project plus the suffix '_IBK' (for item backup). Example: If the base project name is 'LIAS', the name of the backup project will be 'LIAS_IBK'. The backup project will be automatically created if it does not exist yet.

Overwriting an item means that all item descriptions are deleted and the new descriptions are then imported. However, the item definition itself is not deleted and then reinserted, but directly modified. This means, that additional information linked to an item (including item notes, or resources) remain intact.

The overwrite options do not apply to new item forms. Data from such forms are always appended (they use IID=0, which is recognized by the re-import procedure).

Annotation (old IID, sender name, date):

The purpose of annotations is to save information about the original item, which was revised over the internet, its possible backup location, the name of the person responsible for the revision, and the date of revision. The following options are available:

•	Do not add. No annotation is stored at all.

•	Add to item note. The annotation is appended to the text already present in the ItemNotes.

•	Add to a text character. Like the option above, only that the information is added to a specified text character. The character for annotations can be set using the provided button. The value is stored in a project property separately for each project. Thus, if you plan to import data from multiple projects, do the following: Select each project on the first tab page of the dialog box, click on the Select CID button on the second tab page, and select the character. After you have finished doing this for each project delete the project name on the first tab page; otherwise data from all projects would be imported into that project.

Other options:

•	Show DELTA code after import: by default, the DELTA code for the imported item is shown only if an error occurred during import. If you activate this option, the code from all imported items will be displayed in a message dialog box. You can select it and copy it to the clipboard (Ctrl-C) to use the code elsewhere.

•	No warning if project names differ: The postings which you import contain the project name of the project from which they were originally created. You can re-import them into any compatible project, but by default a warning is issued for each imported item. Activating this option suppresses the warnings.

•	'Item comparison' after each import: This option automatically opens the item comparison form (*** NEW; NOT YET DOCUMENTED) after each item that is imported. The form allows to check the differences between the original version of the item and the revision sent in over the internet. The form can and will not be opened if either the item was directly overwritten without any backup, or if a new item was imported. If several items are imported from a single file, or if several files are imported using wildcards, the import process will continue after the item comparison form has been closed.

Limitations which should be overcome in a future import:

•	The currently available test version of an item comparison is not yet finished, a more sophisticated summarize/contrast option is planned which allows writing out the contrasts or summarized data.

•	The import process has been written to deal with multiple items (posts from HTML forms) in a single file. You may want to try it, but please be warned that this feature has NOT been tested well.

•	Should the header information of the email (containing the sender, date, etc.) be added to the new items?

•	The item comparison form allows updates only of item name, notes, etc., but no changes in the item description. This is due to technical limitations of the database engine and will be difficult to overcome in the current version of Microsoft Access.

Re-importing data from HTML forms    [image] Return to Export    [image] Main table of contents    [image] Next


Project Management, Table of contents
 DeltaAccess –
a SQL interface to DELTA (Description Language for Taxonomy), implemented in Microsoft Access

Project Management

   Managing projects
   Creating new projects
   Introduction to subsets
      Character subsets
      Item subsets
   Overwriting project data
   Appending data to a project
   Overview over methods to copy information
   Backup and Restore
      Introduction
      Backup
      Restore
      Problems during Restore
   Next table of contents: Data analysis

See also: Reorganize characters or character states

Previous table of contents    [image] Main table of contents    [image] Next


 Managing projects

Various management tasks are grouped in the Manage Projects dialog box (part of the "DeltaAccess" dialog box). The tasks are selected from a pick list labeled Action.

(This is a hypergraphic)

Management tasks:

Create new project is used to create an entirely new descriptor project (tables and forms). You will use this if you start from scratch, and have no existing DELTA text files to import. The options ( [image]) are explained in the next chapter. After you have created the project, you can use the buttons in the section Analyzing data to open the item and character editor forms (ItemEdit, CharEdit) in which you can insert new character definitions and item names. See also the following Note for new users(1).

Delete project: will remove all tables, queries, forms, reports of a descriptor project. All queries, forms, and reports of a project are deleted if they still have the standard names, even if you have modified them in some way. You can prevent loosing modified queries or reports by saving them under a new name. Such objects (including saved analysis queries) must be deleted manually. Generally you will receive a warning if you try to delete a project that is the base project of other linked/subset projects. However, you may be able to delete a subset project which on which forms the basis of another subset project in a recursive definition of projects.

Add Forms: Creates editing forms for a descriptor project that was initially created without forms. Useful if you skipped the time consuming forms generation during the creation of a subset and later want to permanently use this subset for editing. You can also add forms to a project which was created by manually linking tables from another mdb-file or SQL-Server.

Overwrite item/char definition: Overwrites the data in the descriptor project selected under project name with data from the projects selected under '...from:'. See the following chapter Overwrite project data.

Append item/char definition: Appends the data from the descriptor project selected under '...from:' below the action pick list to the project selected under project name. See the following chapter Append data to project.

Compile and compact database: DeltaAccess is supplied in a compiled state, but the forms created together with new projects remain uncompiled until this option is selected. Also, Microsoft Access databases usually increase their size quickly and then remain at that size. Disk space occupied by deleted objects is marked as available, but is not physically freed up. Thus, if you delete a descriptor project, the mdb file does not become any smaller. To decrease the size of the database and to improve the performance of DeltaAccess, you should compress the database from time to time. It will then have the smallest possible size. Note that you are currently asked to perform the compaction process manually. MS Access 97 does not support executing this command from within the application very well. You can use the menu command (Tools, Database utilities, Compact database) at any time as long as no other user has opened the DeltaAccess database file.

The option Create editing forms is used with several actions and defines whether a new descriptor project will be created with or without editing forms. Creating editing forms is relatively slow and you may not need them, if, for example, you create item subsets for analysis purposes. You can later add forms to a project using the Add forms management option explained above.

Other topics related to Managing projects:
   Creating new projects
   Subsets (Item subsets, Character subsets)
   Overwriting project data
   Appending data to project
   Backup and restore
   Linking other data sources

Contents of Project management    [image] Introduction to the main DeltaAccess dialog box    [image] Main table of contents    [image] Next


Note for new users
(1) Note for new users: If you are new to DELTA, you may need help with how to create a character definition appropriate for your descriptor project and how to use all these strange fields. When you use the editors mentioned above, some help is displayed in the status area at the bottom of the screen or in the ToolTips (yellow boxes appearing when you stop moving the mouse over an object on the screen). The help topics for the CharEdit-form and the information model give further information on specific points. However, I am aware that in too many cases I assume that the reader already has been using another DELTA software package. Unfortunately, I have not yet found the resources to write a comprehensive guide for those parts of DELTA which DeltaAccess supports.

For further details, I recommend reading the extensive and well written User's Guide to the DELTA System by M. Dallwitz, T. A. Paine, and E. J. Zurcher, which is part of Dallwitz's DELTA package. The guide might be confusing at times, however, because it is very much tailored to directly writing DELTA codes in a text editor. It also does not distinguish between data, formatting information, and commands to the command line oriented programs. The DELTA User Guide is not directly available as a help or text file. You will have to either print it, or generate a plain text version with a program called TYPSET (see the file DOCPRINT.DOC in Dallwitz's DELTA package for details).


 Creating new projects

When you create a new descriptor project you have several options for both the character definition and the item data: . The subset option is available only if you select copy or link.

The default (empty/empty) will create new tables which are empty except for the modifiers table (..._MOD, which will contain the default modifier templates), and the property table (..._PROPERTY, which contains the default properties like version information).

If you already have a similar descriptor project in DeltaAccess, you can base a new project on an existing project using the copy or link options.. You must select a base project for both the character definition and the item definition/description in the pick lists labeled from:. In contrast to the main project name pick list in the upper part of the dialog box, the pick lists of these controls contain a short indication of whether the character or item data of the table are original data (= 'Table'), a link or a subset to another project (= 'Link'), or attached tables from an external data source (e. g. SQL server; = 'Attach.').

Copy is identical with the empty option in that a base project with physical tables is created. Normally you will copy the data, for example, create a new project with the character definitions of another project. If you choose to copy item data, but not character definition, only the item names will be copied. If you copy both, all data (item descriptions) will be copied.

Please note that:

•	You can use Create New with the Copy option to rename a descriptor project (delete the old project afterwards). As an alternative to copying data at the time of project creation you can later use the overwrite action.

•	You can select different descriptor projects for character definition and item data, but you have to make sure they are compatible. You will get error messages saying that relations can not be created, if you use characters or character states in the item description which are not defined in the character definition of the other project. If you choose to work with such a project despite these errors, many things will be non-functional, because relational integrity has not been activated.

•	You can later copy characters, headings, or item definitions selectively using the Copy button in the Reorganize definition form.

Link means that new descriptor project will mirror the character definition or item definition and description of the other project. Selecting the link-option for character definition and empty- or copy-options for the item definition and description is useful to base several projects on a common character definition. If you simply have two independent character definitions (e. g., created with copy characters) you will have to manually make changes in both projects. If you link the character definition, changes in either character definition will affect both projects.

0	Linked descriptor projects normally behave as if they had a single character definition. The single exception, as far as I know, is that you cannot delete a primary project (= the one selected under Based on item/char. data from) until all secondary projects ("child projects") depending on the primary character definition are removed as well.

1	Please note that:

•	You can select different projects for character and item definition, but this can be very dangerous. It is your responsibility that the projects are compatible, and, in contrast to the copy option discussed above, you will NOT receive any error messages if they are incompatible. One possible reason for doing this nevertheless, is that it might make sense to link the original character definition and a subset.

•	Linking both character and item definition to the same project results in a perfect mirror of the primary project. This is not very useful by itself, but you can use it to manually add restrictions to the link queries created to create your own user-defined subsets.

•	You can not select item link together with the empty or copy option for character data. This is a deliberate limitation, because it would not be possible to enforce referential integrity in the second character definition. Therefore, you can only perform this procedure manually.

Background information: A linked character set is achieved through the use of queries. In the database explorer you will therefore find queries for the new child project, which have the names usually used for project tables. Relational integrity will always be defined directly, based on the true character definition of the parent project.

The subset option is available during the creation of a copied or linked descriptor project. When selected, you are asked to enter a restriction such that only a part of the base project is copied or linked. Subsets are most useful in the form of subset links. This will create a dynamic view through which different users can see different parts of the same data. Please read the following chapter Subsets for more information. Please note that throughout this documentation, the term subset will refer to a subset link, unless otherwise stated.

Contents of Project management    [image] Main table of contents    [image] Next


 Introduction to subsets

Subsets create a dynamic view through which different users can see different parts of the same data set. The most recent data are immediately visible to all users, and any changes apply to the base project as well as to all subsets. For a user, no difference exists between a full, unrestricted project and a project which is a link to a full project, and which may include a subset restriction. Subset projects can be edited, analyzed, or exported just like full projects.

•	Character subsets create a restricted view for some users, excluding characters. This can focus attention on relevant parts of the data, exclude potentially confusing characters, or protect security sensitive characters.

•	Item subsets can be used to create a view of your data, which excludes items from the full data set. For example, item subsets can be used to assign parts of a large data set to specialists for certain genera of families. The item subset would function like an independent descriptor project, containing only the species of certain taxonomic group. Item subsets are especially useful for analyzing data.

The concept of subsets is comparable to the masking of data using M. Dallwitz's Confor directives Include / Exclude characters and Include / Exclude items. These DELTA directives can be imported to create separate subsets.

A general discussion of the usefulness of subsets can be found in the chapter The mountain and the pebbles: A global knowledge base versus multiple discrete projects. See also the following chapter Further information about subsets.

Contents of Project management    [image] Main table of contents    [image] Next


 Further information about subsets

A subset is defined through a table or query called for each the character definition and the item definition. For example, for a descriptor project named 'X', in which both the character and item definition are restricted to a subset of the base project, the tables or queries 'X_CHAR_Subset' and 'X_ITEM_Subset' will exist in addition to the usual link queries. All other link queries of the subset project refer to these subset definitions (technically they are 'joined' with them).

The definition of a subset can be either dynamic or static. The term static here means that the membership of a character of item in the subset is static. It does not mean, that the data of a character or item are static in respect to the subset. Any subset remains a dynamic view to the basic data, regardless whether they are viewed or edited in the base project or in any linked project. The following table gives an overview over the two types of subset definitions:

Subset type	Statically defined	Dynamically defined
'..._Subset' is a:	Table	Query
Defined through:	List of ID numbers(CID or IID)	SQL condition
Currently implemented for:	Item subsets and character subsets	Item subsets
Advantages:	Changes in the CID or IID  numbers are automatically  reflected in the subset	An item subset can be based on the presence of a char. state in the item description. Changes in the item description are automatically reflected, including new items
Disadvantages:	New items or characters must be  added manually to the subsets	Changes in the CID numbers (e.g. when the character sequence is changed) can invalidate the subset
To change an existing statically defined character or item subset, you must change the list of CID or IID numbers in the '..._CHAR_Subset' or '..._ITEM_Subset' tables. No special editing tool is currently provided, but you can simple open the respective tables and delete records or insert new records at the end.

Note that you can dynamically define item subsets based on the start of the item name. This is extremely useful to define subsets for genera or groups of genera. Also, the disadvantages of other dynamically defined item subset, i.e. that they may become invalid if the CID number are changed, does not apply to this type of item subset. To define a subset based on the item name, simply use the normal procedure for item subsets, and when the Identify dialog box opens select Item Name in the pick list at the left side, where you normally select character groups. This will change the mode of identify to add a item name condition.

Please note that subsets can be defined recursively, i.e. a subset project can use another subset project as its base project. Unless the recursion is deep, the speed of such projects will usually be sufficient. However, it is generally preferable to keep the relations between projects as simple as possible.

Contents of Project management    [image] Main table of contents    [image] Next


 Character subsets

A character definition subset link differs from a full character definition link, in that only a subset of the characters of the original project are visible. A character subset can be used together with a link to the full item description, or in combination with an item subset (see the next chapter).

If several researchers cooperate on a single project, character subsets can be defined, in which characters that are irrelevant to the group a researcher is working on are absent. Other uses of subsets can be to exclude potentially confusing characters from views designed for non-expert users, or to exclude security sensitive characters from views presented to external users.

The character definition of the subset project can be edited just like the original project, although I would not recommend doing this: The invisible characters and character numbers might be confusing.

If you have selected the subset checkbox during the creation of a new linked project, a dialog box opens with a list of all characters of the project on which your new project is to be based. Select the desired characters using shift-mouse-click or control-mouse-click combinations. Assuming that you want to include most characters in the subset, a good strategy would be to include all characters (use the button to the right of the list) and then deselect those characters you want to have excluded using control-mouse-click. Press the Close-button after all characters you wish to include in the subset are marked.

After the initial selection of characters, you are warned if you excluded characters defined as mandatory in the original project, or if you excluded characters which are the controlling characters of potentially inapplicable characters of your subset. In both cases you have the options to automatically add these characters to your subset or to ignore the warning.

Changing existing subsets: To add or remove a character to or from the subset you can use the Reorganize dialog box on the subset project. The 'delete' button removes one or several selected characters from the subset definition. It does not delete characters in the base project. The 'insert' button opens a dialog box in which the characters that are present in the base project but not yet in the subset project are shown. Select one or several characters to add them to the subset definition. See the chapter Reorganize subsets for further information.

Currently only static character subsets are implemented in DeltaAccess. Characters added to the base project are by default excluded from any subset project based on this project (see also the chapter Further information about subsets). You must manually add them to each subset.

Contents of Project management    [image] Main table of contents    [image] Next


 Item subsets

You may create 'mirror versions' of an existing descriptor project in which only a subset of all items of the original project is present. Item subsets can be used together with a link to the full character definition or in combination with a character subset. Similarly to character subsets, item subsets can be used to focus attention of researchers or students on the group they are interested in, which may be only the species of one or two genera in a large project containing hundreds of genera. Item subsets are also useful for analysis purposes, e. g., to create crosstab analyses, or for natural language descriptions of parts of the projects a single genus.

A subset works similar to a link project explained above. The main project as well as any item subsets can be edited. Changes will be reflected in all projects based on the same set of original tables.

You can disable the option to create editing forms for the new subset, in which case the subset occupies very little space (they do not contain any data) and is created much faster. This is especially useful if you need the subset mainly to analyze data. Leave the checkbox enabled if you want to edit the subset with the standard editing forms.

After you have selected the item subset option, three additional options are enabled in the lower right corner of the dialog box. The selection of the items belonging to the subset can be:

•	dynamic (using Identify): The restriction will be evaluated each time you operate on the item subset. If, after the creation of the subset, you add a new item which fulfills the subsetting condition, the next analysis of the subset will include this item.

•	static (using Identify): The items which fulfill the subsetting condition at the time the subset is created are recorded. This item set will not change when you change your data or add new items. You should use this method if you want to run many crosstab queries on the item subset, since the static item subset is significantly faster than the dynamic item subset.

•	direct (static, selecting the items by item number or name): .If you only want to create a small subset, you can also directly select the items belonging to the subset by name or item number (IID). The subsets resulting from the use of the static or direct option will be identical; only the selection method differs.

A major difference between dynamic and static item subsets is that item added to the base project are by default excluded from any subset project based on this project (see also the chapter Further information about subsets). You must manually add them to each subset (see below).

If you select dynamic or static, the interactive identification dialog Identify will be opened when you click OK to start the creation of the new project. Define your restrictions as if you are trying to identify the group in question. You can use categorical (UM/OM), numerical (IN/RN) or text (TE) characters. Especially useful for subsets containing all species of a genus is the option to select items by defining the start of the item name (select "Search in item name" in the character group pick list above the character list; you can then enter the start of the items for your subset). Restrictions involving text characters should not be used in combination with dynamic item subsets. The subset will execute rather slow (or dismally slow, depending on the size of your data set). You can also enter a restriction based on the item name, e. g., to create a subset for a specific genus. Press the evaluate button to check if the subset contains the items you would expect and then close the Identify dialog box.

If you need a dynamic subset but can not define it based on a combination of the existing characters, you should read the following chapter Using management characters to define item subsets.

Changing existing static subsets: To add or remove an item to or from the subset you can use the Reorganize dialog box on the subset project. The 'delete' button removes one or several selected items from the subset definition. It does not delete items in the base project. The 'insert' button opens a dialog box in which the items that are present in the base project but not yet in the subset project are shown. Select one or several items to add them to the subset definition. See the chapter Reorganize subsets for further information.

Contents of Project management    [image] Main table of contents    [image] Next


 Using management characters to define item subsets

You may want to define an item subset, which can not be defined by reference to existing characters. If you come to this point, you should stop for a moment and think about why this is the case. It may point you to a problem in the definition of your character definition. Does the new character indeed confer independent information, or is this situation due to an inadequate analysis of the character relations?

One scenario where an additional "management character" may be needed, is when different people are responsible for editing groups of genera, which are not necessarily correlated with systematic groups. Another reason might be that a project is to be split for management reasons, where the characters on which the splitting is based are unknown or not yet recorded in some items. If these items will not all be assigned to one subset project, but individually and arbitrarily assigned to one or the other group, you would have to create a special management character.

See the chapter Calculated characters for methods of inserting a new character based on existing information. After you have used the Identify dialog box (which is also used to create item subsets) to select a set of items in the MultiItemEdit dialog box, you can manually modify the selection before inserting a character state into all selected items.

Contents of Project management    [image] Main table of contents    [image] Next


 Overwriting project data

	Who should read this: The operations addressed in this chapter are mainly relevant to the advanced user, who, e. g., has created modified DeltaAccess reports, or uses links to external data sources (ODBC).
You can selectively overwrite the data of an existing descriptor project with data from another project. The result is in many ways similar to creating a new project with data copied from an original project. The difference is that tables and forms of the project are preserved, instead of being deleted and recreated.

The major use of this option is to replace the character definition while preserving the item definition and description, or vice versa. For example, if you select a project under item definition and data, but none under character definition, the character definition will remain untouched, while the item definition and data will be overwritten. Thus, to update item data from an external DELTA coded text file, without loosing the character definition of a project you have already edited inside DeltaAccess, you can import the DELTA item file together with a compatible DELTA character definition file into a new project, and then use the overwrite option to selectively overwrite the item data of the existing project only.

Note that it is your responsibility to verify that the character definition is compatible with the item description. I expect some problems with the use of Modifiers. They are not defined in DELTA and extracted from the item description notes. These notes are likely to change when the item description is changed. The overwrite process might therefore have to be revised at some point.

Please note that Overwrite may invalidate linked or linked subset projects:

Type of project that depends on the project that is overwritten:	Effect of overwriting character definition:	Effect of overwriting item definition and description:
Fully linked (no subset definition)	No change	No change
Dynamic item subset definition (i.e. defined using Identify)	No change	No change
Static item subset definition	Subset is empty	No change
Static character subset definition	No change	Subset is empty
The reason for this behavior is that the character or item IDs on which the subset definition is based is protected by referential integrity. This means that changes of the ID in the base project are reflected in the subset, including deleting a character or item. Normally this is desirable, however, in the case of overwriting the deletion which has to occur before the new characters or items can be inserted will also remove the characters or items from statically defined subsets. If you want to overwrite a project with another equivalent project and want to preserve the subsets, you can try to remove the referential integrity definition (using the standard Microsoft Access tools) before using overwrite and recreate them afterwards. This will work as long as the old and new project have equivalent or compatible ID numbers (CID or IID).

Another important use of this option is relevant if you use external ODBC connections (for example, if the tables reside on SQL-Server and are linked into Access). Since you have to create the connection ("link" or "attachment") with the tables residing on the server manually, deleting a project would delete the link, and recreation would create a local copy again. The overwrite management action preserves the connection to an ODBC source like SQL-Server. You should therefore try to use the overwrite action with ODBC connections whenever possible.

If you want to restore a project, but first review the condition of the backup, you can restore to a new project name and later replace the data of your usual project with the data from the previous project. Since no new forms have to be created, this method is slightly faster than renaming using the actions Delete and Create New with the Copy option.

Contents of Project management    [image] Main table of contents    [image] Overview over methods to copy information    [image] Next


 Appending data to a project

	Who should read this: The operations addressed in this chapter are mainly relevant to the advanced user who manage multiple descriptor projects and want to merge them.
You can append data only from one descriptor project to another. Thus, to append data from external, DELTA coded text files, you must first import these files into a separate project.

Basically, appending characters or items manipulates the ID numbers (IID, CID, and HID) in a way that they don’t conflict with the numbers in the project to which they are appended. The manipulation is performed such that the project which is appended remains unchanged. It is important to understand that appending first the items, and then the characters is different from appending both together.

Examples. If you have two projects with the following character/item matrices,

  IID: 1 2 3        IID: 1 2 3
CID 1  A A A      CID 1  B B B
CID 2  A A A      CID 2  B B B
CID 3  A A A      CID 3  B B B

you can achieve the following results:

A)	Appending only the items from B to A results in a merging of the two projects in regard to the character definition.

  IID: 1 2 3 4 5 6
CID 1  A A A B B B
CID 2  A A A B B B
CID 3  A A A B B B

Notes: Only item data and descriptions are appended. It is your responsibility to check the compatibility of the character definitions of the two projects that are merged. DeltaAccess can check compatibility only insofar that all character/character state codes used by the project to be appended must be available in the project to which the data are appended (the appended project may have additional characters/states which are not used). Since only the codes can be checked, the user must guarantee that the meaning of characters/and states with the same code is compatible, otherwise the meaning of the item descriptions will become corrupted. The character definition is updated only insofar that modifiers will be enabled for all characters, for which they have been used in the project to be appended. Modifiers will not be added to the project-wide modifier table (_MOD).

B)	Appending only the characters from B to A results in:

  IID: 1 2 3
CID 1  A A A
CID 2  A A A
CID 3  A A A
CID 4
CID 5
CID 6

Notes: No effort is made to find characters which might be identical (e. g., by checking the character names). Because the character and heading names must be unique, the project name of the appended project is added in square brackets to each character name. Currently, this is done regardless of whether a duplicate name exists or not.

C)	Appending both characters and items from B to A results in:

  IID: 1 2 3 4 5 6
CID 1  A A A
CID 2  A A A
CID 3  A A A
CID 4        B B B
CID 5        B B B
CID 6        B B B

Note that the character definitions may be incompatible in this case. The information is fully maintained. However, the results are probably not fully satisfactorily if some characters have the same meaning. You can use the character state reorganization dialog box to join or move the character states of characters which are actually compatible. If you have joined all states of one character with the states of a second character, the item descriptions will all be moved to the second character. You can thus delete the first, stateless character without affecting any item descriptions.

D)	It should be clear that first appending the characters and then the items (i.e. in two steps) results in something rather useless:

  IID: 1 2 3 4 5 6
CID 1  A A A B B B
CID 2  A A A B B B
CID 3  A A A B B B
CID 4
CID 5
CID 6

E)	If the two character definitions are only partially compatible, but you can guarantee that identical CID numbers have identical meaning, e. g.,

  IID: 1 2 3        IID: 1 2 3
CID 1  A A A      CID 1  B B B
CID 2  A A A      CID 5  B B B
CID 3  A A A      CID 6  B B B

and you want to obtain

  IID: 1 2 3 4 5 6
CID 1  A A A B B B
CID 2  A A A
CID 3  A A A
CID 5        B B B
CID 6        B B B

you currently have to resort to semi-manual methods. You can first copy character 5 and 6 to the first project. Since appending the character definition using the case B) described above would change the character numbers, simpler to use the copy character button in the Reorganize form to do this. After you have done that, you can append the items like in case A). For further information and detailed step-by-step instructions see the chapter Merging descriptor projects.

Note that you can select different projects for character and item data. However, you should use this option with great caution, since DeltaAccess can not check the compatibility of the character definitions. Normally you will not need to use this option, as you will usually append both character and item data from the same project.

Contents of Project management    [image] Main table of contents    [image] Overview over methods to copy information    [image] Next


 Overview over methods to copy information

	Who should read this: This chapter gives an overview over the methods to copy information (e.g. character definitions or item descriptions) that are available in the various parts of DeltaAccess.
You can always copy small pieces of data, like selected text or single records using the Windows clipboard and standard Microsoft Access methods. However, to simplify certain common tasks in the management of descriptor projects, DeltaAccess offers several specialized methods to copy data. Copying data can be relevant if you want to copy or move definitions or descriptions between descriptor projects, or if you want to duplicate definitions or descriptions within a single descriptor project.

The management actions Overwriting project data and Appending project data described in the previous chapters deal with all information from entire descriptor projects. The entire character definition, item definition together with description, or both, can be copied (usually to a separate project). If you want to restrict the scope to part of the character definition or only some items, you first must define a temporary character or item subset, which you can then use as the source to copy from.

In the Reorganize project definition form you can copy the definition of selected characters, character headings, items, or states within a project or between projects. If you copy a character, all states of this character are automatically copied as well. A copy of the definition alone (leaving the with item description checkbox unchecked) is typically used to duplicate parts of the project definition to use them as a template for new characters etc.

Except for character headings, you also have the option to copy the item descriptions together with the definition (by checking the with item description checkbox). In the case of copying a character, all item descriptions referring to any state of the character in all items are copied; in the case of copying an item, all item descriptions referring to this item and to any character state are copied. Copying with item description is typically used to duplicate some information before you modify it. For example, you may want to make a "backup copy" of a group of characters which you consider ill defined. The original coding can then be revised (e.g. using move/join on the Reorganize character states tab page of the Reorganize project definition form) while a copy of the character and item coding is retained. Another use is that you want to split a single state, that makes two independent statements, into two states (e.g., to change Leaves: 'rough and hairy' to Leaves: 'rough' and Leaves: 'hairy').

The following table gives an overview over the available options. Please follow the hyperlinks for further information about each method:

Method	Source	Copy without / with item description	Copy to same / different project
Overwriting project data
character definition	Entire project/subset	/	/
item definition/description	Entire project/subset	/	/
Appending project data
character definition	Entire project/subset	/	( [image]) /
item definition/description	Entire project/subset	/	( [image]) /
Reorganize project definition
Copy item(s)	1 to N item definitions	/	/
Copy character(s)     together with states	1 to N characters with their states	/	/
Copy char. heading(s)	1 to N char. headings	/	/
Copy character state	Single state	/	/
Item editor
Preset item description	All item descriptions  of single item	/	/
( [image] = possible / [image] = not possible / [image] = not applicable )

Contents of Project management    [image] Main table of contents    [image] Next


Backup and Restore
 Introduction to backup and restore

	Who should read this: Creating backup copies of your descriptor projects is important to all users. Instead of keeping copies of the entire DeltaAccess.mdb file, you can use the tools described here to preserve hard disk space or selectively backup specific projects.
The backup and restore function are combined in a single dialog box, which can be opened from the DeltaAccess Switchboard or by opening the form DescrBackupRestore in the database explorer.

You can also simply make backup copies of the DeltaAccess.mdb file by copying them in the Windows Explorer to another folder or another filename while it is not open. Any DeltaAccess.mdb can function as a backup file, i.e. you can do a restore from it. The advantage of using the specific backup function is that the backup database file contains the project tables alone (without indices, and without forms, reports, or VBA code). Thus explicit backup files are significantly smaller.

Another method to save your project data is to export them to a DELTA coded text file. However, re-importing these files into DeltaAccess may result in some information loss. To preserve part of the information that is specific to DeltaAccess (e. g., character names, MultistateType, formatting), DeltaAccess has some provisions for directives beyond those defined by Confor. Nevertheless, some conversions need to be done during import which may change the data. DeltaAccess tries to remain as compatible as possible with other DELTA programs, and this compatibility leads to some problematic conversion issues, especially in regard to comments and modifiers.

Therefore, the preferred and safest method for backup, data exchange between co-workers using DeltaAccess, etc., is the use of a backup database file.

The backup mechanism is also used to upgrade descriptor projects to new versions of DeltaAccess. All necessary changes to the data structure are automatically performed during the restore process. This ensures that old backups, made under previous versions of DeltaAccess, can always be used with the current version. The Switchboard (the dialog box which comes up at startup of DeltaAccess) automatically offers an upgrade option if a new DeltaAccess version is opened (i.e. if no projects have yet been defined).

Further information about Backup and Restore can be found in the following chapters:
   Backup,
   Restore, and
   Problems during Restore.

Contents of Project management    [image] Main table of contents    [image] Next


 Backup

On the first tab page you can enter the name for a new backup database file. Although a file date is visible in the Windows Explorer, it is good practice to include it in the filename of the backup file. You can also click on the button with the open-folder-symbol ( [image]) to select an existing file using a dialog box, but please note that this means you are going to overwrite that file.

The main list shows all project names currently defined in the database. You can simply click on any project to include it in the backup, or you can use a button to select all projects. Click on the Start button to begin the creation of the backup file.

On the lower left an additional button provides an option to Delete the selected projects. This may be useful if you have created temporary projects for a specific purpose (e.g. using the summarize items function).

Introduction to Backup and Restore    [image] Contents of Project management    [image] Main table of contents    [image] Next


 Restore

On the second tab page you can select the filename of backup database (*.mdb) file containing descriptor projects (click on the button with the open-folder symbol:  to select the file using a dialog box). This may be a file created with the backup function, or any DeltaAccess.mdb file of the current or any previous version of DeltaAccess.

The main list shows all project names available in the specified backup database file. You can simply click on any project to include it in the backup, or you can use a button to select all projects. Click on the Start button to begin restoring the selected projects.

If you are restoring only a single project, you can choose a new name for the project in the field labeled Rename to local project name. A new project with that name will be created in the current database and will be filled with the data from the project that you selected from the backup file.

Introduction to Backup and Restore    [image] Contents of Project management    [image] Main table of contents    [image] Next


 Problems during restore

Restoring dynamically defined item subsets created in DeltaAccess before version 1.6: Starting with version 1.6, linked projects and subset projects can be correctly restored. This includes mixed projects (i.e. an independent item project with a link/subset to the character definition of another project). Two limitations remain: (1) While dynamic item subsets created in version 1.6 will be restored as such, dynamic item subsets created in previous versions of DeltaAccess are converted to equivalent static item subsets, i.e. they become based on IID numbers.

Restoring linked or subset projects when the base project is missing: All link or subset projects need their base project to operate. Only a base project contains actual data, links and subsets are only operational views. If Restore encounters a link or subset it does the following:

•	Check in the current database, if the necessary base projects are present (or, if multiple projects are restored, are restored in the same restore operation).

•	If the project is not available, it looks in the backup database file and asks whether the base projects shall be restored together with the link/subset project.

•	If the base projects can be found in neither database, it will attempt to do a direct restore. This restore is very limited, and should be seen as an emergency operation. It can not upgrade links between versions (different versions of DeltaAccess may implement links or subsets slightly different), and several error messages will be given if it encounters a mixed projects (item tables plus character link) even from the current version. Neither for mixed projects, nor for subset projects the necessary referential integrity definitions will be set. Finally, in any case, before you can use the restored project, you must provide a suitable base project. Given these limitations, it is evident that the best way to restore such projects it to first restore the required base projects and then restore the link or subset projects again.

Introduction to Backup and Restore    [image] Contents of Project management    [image] Main table of contents    [image] Next


Data analysis, Table of contents
 DeltaAccess –
a SQL interface to DELTA (Description Language for Taxonomy), implemented in Microsoft Access

Data Analysis

   Analyzing data
   Printing the analyses
   Analyzing parts or subsets of your data
   Using Access query design (QBE editor)
   Creating a cross-tabulation or pivot analysis in Excel
   Frequency distribution (histogram) of numerical characters
   Comparing characters with external classifications
   Summarizing items
   List of all analysis queries and reports available
   Analysis queries provided
   Analysis reports provided
   Analysis charts/graphs provided
   Next table of contents: Editing data

Previous table of contents    [image] Main table of contents    [image] Next


 Analyzing data

(This is a hypergraphic)

Several queries or reports to analyze your data can be selected from a pick list. You must first select a group of queries or reports under Analysis type. All analysis queries or reports of this group are then available in the second pick list Open analysis or report. Click the OK button to run the analysis. See List of all analysis queries and reports available for a complete list of all available analyses.

Some queries will generate views of the data, while other queries will perform updates to the data. A warning message will appear before any data are updated. If you have a full version of Microsoft Access (i.e. not a run-time version), you can select whether you want the query to run directly or to see it in design mode first. For notes about printing see the next chapter printing analyses. The checkboxes for interaction with Microsoft Excel are explained further below.

Note that most queries will automatically be deleted after use. If you want to keep a query to run it directly from the database explorer, you can use the File, Save as command in the menu. Save the query under a different name (e. g., add a "1") to avoid it being deleted when closed. If you want to compare the results of several queries, you must use saved queries, since you can only open one query at a time using the current dialog box. If you select a report, a report specific to your descriptor project will be created and opened. Reports are not deleted after use.

The main analysis dialog box also provides a button to directly access the interactive identification Identify.

The following chapters explain further details about the analysis options:
   Printing the analyses
   Analyzing parts or subsets of your data
   Cross-tabulation (crosstab) queries, pivot analysis in Excel
   List of all analysis queries and reports available
   Analysis queries provided
   Analysis reports provided
   Analysis charts/graphs provided

Contents of Analysis    [image] Introduction to the main DeltaAccess dialog box    [image] Main table of contents    [image] Next


Printing analyses
 Printing the analyses

Normally no special printing command is required. You can print out queries, forms, and reports/graphs using the standard Microsoft Access menu commands. To avoid wasting paper, you can switch into print preview mode first. You may want to adjust column widths and heights, or switch to landscape printing to make the query fit well. When you view a report you will see a page preview, which should be identical to what your printer produces.

Formatting analysis queries for printing:

Most analysis queries are not preformatted for printing on a certain page format. To adjust page layout and formatting, select the portrait or landscape page orientation from the page/print setup (File menu). Change the page margins if necessary. Adjust the column width to your needs and perhaps hide columns that you do not want to have printed. To change the sequence of columns mark them (move the mouse on the column label, and click while the mouse cursor has the form of a down-pointing arrow) and drag them to their new position. Sometimes it may be preferable to have narrow columns and to increase the line height to display several lines of text for each record. Use the horizontal line between the record selectors on the left side of the table, and drag it up or down. You can also change the sorting order or filter your data before you print them. Use page preview (in the File, not in the View menu!) to check the results before printing.

Note that if you save the query under a new name, most of these settings are saved. Yet, whenever you create the same query for a new descriptor project using the DeltaAccess dialog box, you will have to repeat this procedure. Please contact me if you think that the sequence of fields should always be different.

In contrast to queries, reports are already provided with a certain page setup. Since in Europe we use A4 page format, you may have problems with the American letter format. I tried to take this into account, but it might not be working. You may have to adjust the report in design mode, e. g., by making the graph object frame smaller. If you send me an adjusted version of a report, I will change the setup in the next version of DeltaAccess accordingly.

Contents of Analysis    [image] Main table of contents    [image] Next


 Analyzing parts or subsets of your data

Sometimes you may want to restrict your analysis to a subset of your data. You can create character or item subsets, in order to reduce the number of characters in a report, or to run character state crosstab queries only on those items which fulfill a certain condition (e. g., are in some genus, or contain a specific character state). Use the link option together with the subset option of the management action create new project to create such subsets. If you disable the create editing forms option, the subsets will be created much faster and will use very little space in your database.

You can also design "on the fly" subsets if you modify the SQL queries, which form the basis of the analysis options. Some basic procedures for modifying queries are explained in the following section Using query design.

Microsoft Excel: Sometimes it may be faster to simply export your data to Microsoft Excel and delete unwanted rows or columns before you format and print your results. Excel is considerably more powerful in formatting tables than Microsoft Access. You can print labels at any angle, join cells, center headings over multiple cells, or use lines and other graphical elements to format your results. I especially recommend Excel if you want to design your own charts. Modifying and fine-tuning charts/graphs is considerably more transparent in Excel than it is in Access (although both programs use the same applet for the charts). The disadvantage of using Excel is that you have to repeat the export and chart creation process each time you change your data, while with MS Access, you can save a modified query or a report including a chart for later use. Microsoft Access queries are dynamic, i.e., they use your most current data whenever they are executed. Many queries will even update their data while they are open, if a colleague changes the data they are based upon (Access calls this a "Dynaset"). In a network you may get different results on two consecutive runs of an analysis, because as colleague changed something during the previous 5 minutes! Consult the next chapter on how to export data to Microsoft Excel.

Contents of Analysis    [image] Main table of contents    [image] Next


 Using Access query design (QBE editor)

DeltaAccess frequently uses queries instead of reports. Reports are much more powerful in formatting, but they are difficult to modify. Queries, on the other hand, are much easier to understand and to modify. You can create your own reports based on queries if you need more sophisticated formatting. Microsoft Access provides a report wizard and an autoreport function, which make this easy for many types of reports. Select the saved query in the database explorer and select Insert, Report from the menu.

Some modifications to queries can be performed in datasheet view and are discussed in the previous chapter Printing the analyses.

To make the best use of the standard queries provided by DeltaAccess, you can modify them in design view. You must have a full version of Microsoft Access to do this, the run-time version lacks the necessary design tools.

The MS Access QBE (query by example) editor is opened if you click on the design button ( [image]) in the tool bar, or select View, Design from the menu. You can also open the query directly in design mode using the design-mode-option in the main analysis dialog box.

In the upper part of the QBE window you see a graphical representation of the table included, and the relations between them. You can add or remove tables, and change the relations between them. Doing so requires some understanding of the internal structures of the database (i.e. the entity relation model, see the chapter Information model).

In the lower part of the window you see a datasheet of the attributes (fields) present as columns in the query. Changing the design in this part is much simpler and you should start trying to understand this part first.

The first row of the datasheet determines the name of the attribute. This name may have two parts: first the name shown to the user, then after a colon (':'), the name of the table attribute (= field name). Thus 'IID \ CID=: IID' means: this is the field IID, but the column label is 'IID \ CID='.

Depending on the type of query and the settings of your version of Access, you may or may not see a row containing the table name to which an attribute belongs, a row where you can define that the records will be sorted by one or several attributes, and a row with checkboxes where you can define whether attributes are visible (checkbox on) or hidden.

The most important rows for modifying queries start below the row with checkboxes. In the English version of Access, the rows are labeled criteria. This part can be used to restrict the number records which will be returned when the query is executed. Using criteria can be a very fast way to analyze many temporary item or character subsets, without creating subsets as full linked subset projects. If you want to restrict a character usage crosstab query to the first 20 items and to characters 1, 3, 6, 8, 9, 10, 11, 12, you should enter 'Between 1 And 20' as criteria for the IID attribute, and 'IN (1, 3, 6, 8, 9, 10, 11, 12)' as criteria for the CID attribute. Both criteria should be entered without the quotation marks.

Consult your Microsoft Access documentation for further explanations about the use of the qbe (query by example) editor. It requires a little effort to learn at first, but then it really is a wonderful tool. For more general information about Microsoft Access queries see the Contents of the Access 97 help file, Introduction to Microsoft Access 97, Queries:

Queries: What they are and how they work
Ways to customize a query
Ways to specify multiple criteria in a query
Ways to work with data in a query's datasheet
Example of a crosstab query
Join types and how they affect query results

and Working with Queries, Creating and Modifying Queries:

Create a query
Design or modify a query
About using the asterisk in the query design grid
About working with blank fields in queries

and many further topics under the heading Working with Queries.

Note that even the reports supplied get most of their power from the queries used for their recordsource. If you view a report in design mode, you can modify the query behind the recordsource property of the report.

Contents of Analysis    [image] Main table of contents    [image] Next


 Creating a cross-tabulation or pivot analysis in Excel

DeltaAccess provides only simple crosstab queries, which are limited in several ways. They are limited to 2 dimensions, they can not provide column sums (row sums are complicated, but possible) and they will leave fields with a count of '0' empty. The latter is convenient for a quick overview, but inconvenient if you want to analyze your data further, e. g., in Excel. Because of these limitations, I recommend using the provided crosstab for quick direct analyses and error checking, and the Excel pivot wizard for more sophisticated analyses.

In the analysis section of the DeltaAccess dialog box you will find a checkbox Analyze in MS Excel, which will automatically export the results of the query to Microsoft Excel. You must have Excel 97 installed on your computer.

If the export option provided by DeltaAccess does not work (e. g., because of version or registry problems), check if the file has been created (either in your default data directory or in the directory where DeltaAccess.mdb is placed). You can also try to use the standard Microsoft Access functionality: Select Tools menu (German version: Extras menu), Office Links, Analyze in MS Excel (for other languages: Tools is the 3rd-last menu, Office Links the 3 entry there) and the data will be displayed in Excel. Note that Excel (97, version 8) is limited to 65536 rows. If your query returns more rows (look at the record count at the bottom, next to the navigation buttons), you must first restrict your query so that it returns less data. In the DeltaAccess export dialog box you can also find an option for a simple export of all your project data to Microsoft Excel, but this will be of limited value for larger projects.

The pivot function of Excel is one of the most powerful functions on your PC. The checkbox Create pivot table in the DeltaAccess dialog box tries to automatically create a pivot table for you. Currently this functionality is provided only for few queries (e. g. Char-state usage Char 1 x 2 (list), and ... (list, names)). You need a list type analysis output, i.e., you can not create an Excel pivot table from an Access crosstab type analysis. If you always get error messages during the automatic creation of pivot tables with DeltaAccess, either Microsoft Office may not be correctly installed, or the code may not work with all language versions of Excel 97.

To manually create a pivot table, put the cursor into the cell where the data you want to analyze start and select pivot wizard from the Data menu of MS Excel. The first 2 pages can usually just be accepted as they are. On the third page you must define which variable you want to display where. The result variable, often called X or Count should be dragged into the main part of the table displayed on this form. By default is will be entered as Sum of ..., which is correct for most purposes. (In fact, since Microsoft Access already groups the data into counts, there will usually be nothing to sum at all. A pivot table could itself do the grouping, which Microsoft Access already did, but this would be much less effective.) Further, you must drag the other variables into the column and row headers, or into the page (upper left box, this will result in a separate page for each value in this variable). You can drag more than one variable into the row or the column headers. The sequence of multiple row or column header variables can be changed and defines the hierarchy of the pivot table. On the last page of the wizard, you should decide to create the pivot table on a new Excel sheet. The option button that is available on this page gives you access to several pivot options, but you do not have to change them the first time.

There are more options for a pivot table than you can imagine. Some of the more important options are:

•	Rearranging the pivot table: You can dynamically rearrange your pivot table by dragging the variables (the gray, button like cells) from the row header into the column header or vice versa.

•	Displaying empty cells as zero: Put the cursor into the data area of the pivot table and click with the right mouse button to display the context menu. Under Options you will find, among other things, the option Display empty cells as. If you enter a '0' here, the empty cells in your table will appear as '0', which is convenient for statistical purposes.

•	Choosing percentage display: If you select Field from the same context menu, click on the options button to extend the dialog box, you can select whether you want to see your crosstab as row-percent, column-percent, or total percent, instead of the absolute values.

You may also right-click on any of the variables (the gray, button-like cells). The context menu entry Field will give you options specific to this variable. Please consult your Excel documentation for further details on pivot tables.

It is possible to integrate these pivot tables into Microsoft Access forms or reports (provided Microsoft Excel is installed). You will have to create these reports yourself, because they will be specific to the combination of characters you currently analyze. If anybody creates generally useful reports, forms, or queries in any way, which do not entirely depend on his or her own project, I would be grateful to receive them and will integrate such reports into the next releases of DeltaAccess.

For more general information about the interaction of Microsoft Access and Microsoft Excel see the Contents of the Access 97 help file, Sharing Data Between Applications, Sharing Data with Microsoft Excel:

Export a table or query to a spreadsheet
Save an object's output as a Microsoft Excel or rich-text format file
What is a PivotTable?

See also Introduction to character cross tabulation for a discussion of the general properties of cross-tabulation analyses and statistics.

Contents of Analysis    [image] Main table of contents    [image] Next


Frequency distribution (histogram) of numerical character
 Frequency distribution (histogram) of numerical characters

Currently, DeltaAccess offers no frequency distributions for numerical characters. This chapter explains how to retrieve the relevant information and how to create a frequency distribution using Microsoft Excel. An independent tool will be introduced in a future version of DeltaAccess, together with the mapping of categorical and numerical character states.

To create a frequency distribution of numerical characters, using a combination of DeltaAccess and Microsoft Excel, try the following steps:

In DeltaAccess, open the analysis dialog box and select the Analysis type Edit or view data. Select the query Mean, or middle of ranges/min/max of 1 numerical char. Check the checkbox Analyze in MS Excel and click on the OK button.

Continue the analysis in Microsoft Excel, which will normally be opened automatically with the Excel file into which the data were exported. The Excel spreadsheet contains the information about the character you selected, the measurement unit, the item names, and a column displaying the statistical attributes (mean, ranges, etc.) combined into a single formatted string. The final column (CalcMean) calculates a single "middle" value for each item. This is the mean if available, otherwise the middle of upper and lower range (or minimum/maximum, if ranges are lacking as well).

In the column to the right of the CalcMean column, enter the class borders for the intervals into which you want to group the values:

To count all items where the calculated mean of the character in question is in these intervals:	Enter these values as class borders:
smaller or equal 10:	10
greater 10, smaller or equal 20:	20
greater 20, smaller or equal 40:	40
greater 60, smaller or equal 60:	60
greater 60:
As you can see, the upper class border is included in the range, i.e. a value of 10 would be included in the first interval in the example above. You now have two options:

a)	Create a frequency table using a wizard:

This requires that you have installed the Analysis add-in supplied together with Excel. At the end of the end of the Tools menu you should then have an entry Data analysis. Select this entry and select Histogram from the list in the dialog box. Follow the instructions, selecting the data range (note: you should select the exact range containing your values, not the whole column) and the class border range ("bin") in your spreadsheet.

The wizard can optionally create columns with cumulative percentages, and create a second copy of the frequency table sorted by frequency instead of class borders (Pareto diagram). It can also automatically create a chart for you.

The disadvantage of the wizard method is that the data are static, i.e., not calculated through a formula. Updating data will not automatically result in an update of the frequency table. For this reason and because some users may not have the Analysis add-in installed, a manual method is described below, as an alternative to using the wizard.

b)	Create a frequency table manually:

In the column to the right of the class border column, select an area with one cell more than you have entered class borders. Keeping the cells selected, type "=FREQUENCY(" on the keyboard. Select the column with the CalcMean values, type a ";" on the keyboard, and select the column or area with the class borders. Close the function by typing ")" and press Shift-Ctrl-Enter to enter it as an array formula. The selected cells should now contain the frequency distribution. In the formula bar, the function should look like "{=FREQUENCY(F:F;G:G)}". If the braces (= "{}") around the function are missing, you have not used Shift-Ctrl-Enter. Do not type the braces themselves; the formula will then look correctly but will not work!

Note for users of non-English versions: Unfortunately, in contrast to Access, Excel does not automatically translate the English function names for you. The appropriate function can be found in the "Statistical" category of the function wizard (click on the button labeled fx in the toolbar).

The result (note the area which was selected before entering the array formula) could look like:

To create a histogram chart based on these results, click on the ChartWizard button ( [image]) while the cells containing the frequency function are still selected. Normally you can accept the default (Chart type column, sub-type 2D clustered columns). Click Next, accept the defaults for data range (the series are in columns), click on the second tab of this step, labeled Series. Go to Category (X) axis labels at the bottom, select the range of cells with the class borders (the cell addresses are automatically entered if you select an area with the mouse). Click Next again. In the options step you can enter titles for your chart and uncheck the box to show the legend (Legend tab). Click Finish to create the chart. The labels on the category axis are slightly confusing, because they correspond to the class borders, but are placed in the center of each class. For publication, you may wish to add an additional column containing the corresponding intervals (compare the table above) and use this column for the Category (X) axis labels.

Consult also the chapter Character cross tabulation (numeric) for further details.

Contents of Analysis    [image] Main table of contents    [image] Next


Comparing characters with external classifactions
 Comparing characters with external classifications, phylogenetic trees, or cluster analyses

	A frequent request is to compare trees derived from external analyses with data in a DELTA data set. The tree may be derived from classical morphological studies, statistical multivariate analyses or from molecular data (e. g. DNA sequences). DeltaAccess currently does not offer any sophisticated analyses to map character distributions on phylogenetic trees. The current chapter describes how the use of character cross-tabulation nevertheless provides some interesting insights.
To some extent, relevant features of tree diagrams can be reduced to categorical characters. In the following hypothetical example:

You could be interested in the main bifurcation and analyze groups A versus group B, or you could compare the 3 groups 1, 2, and 3. If the distances on the tree correlate to distances in the data set (e. g., in the example above, the distance between groups 2 and 3 is larger than between items 1 and 2), you should select groups which encompass the major distances in the tree. Although an analysis which traverses the above tree further to the right would be possible, it would be difficult to interpret the results of such an analysis, because it yields to many groups on the same level. This is less of a problem if only a subtree is analyzed, e. g., in a comparison of item1 to item 5.

To perform the analysis in DeltaAccess, you would:

•	create a new "tree-character" in the character editing form and create a character state for each group you want to study (e. g. A and B or 1, 2, and 3)

•	insert an appropriate state for each group of items into this character, using the Multi-ItemEdit dialog box as described in Calculated characters (to analyze the three item groups in the example above, you would insert "1" into items 1 to 5, "2" into items 6 to 8 and "3" into items 9 to 12)

•	use the character from the data set which you want to analyze and this "tree-character" in a character cross tabulation (you could also create charts for Two-character comparisons)

Using a statistical analysis tool (e. g. SAS, categorical data analysis) you can analyze the significance of the differences. You could use a chi-square test, a loglinear test ("G-test"), or Fisher's exact test to test the assumption of independence of the two factors. If the null-hypothesis of the test can not be rejected (no significant result), the two factors are independent. This means that the classification factor ("tree-character") does not influence the character you are analyzing. Such a result would be expected, if the members of each group were chosen at random.

Note that chi-square or loglinear tests are valid only if a sufficient number of samples in each group are present. The expected frequencies under the assumption of independence should not fall below a certain number (which depends on the test used). Most statistical packages will issue a warning if this condition is violated, but you might want to verify it yourself. Although Fisher's exact test will be valid for low frequencies, this does not necessarily imply that the result is very meaningful if the null hypothesis could not be rejected. As with other tests, the probability of accepting a false null hypothesis is usually not calculated. The error "beta" (as opposed to the error of rejecting a true null hypothesis = the significance level "alpha") depends on the sample size and the minimum required difference.

Contents of Analysis    [image] Main table of contents    [image] Next


 Summarizing items

If you have recorded data on several species of a genus, you can automatically create a summary of these data. This could provide a description of a genus, which applies to all species of this genus included in the data set. You can use also this feature to create equivalent summaries for feature groups. You could, e. g., be interested to see a summary of all items living in a certain habitat.

Define projects

You must select a source project, from which the items to be summarized are retrieved, and a destination project, to which the newly summarized items will be written. The source and the destination project can be identical.

If you enter the name of a non-existing project as destination project, a new project will be created. The character definition of the new project will be linked to the source object and the item definition and description will be created as an empty table.

Create summarize table

To summarize items, you must first create a table defining how items shall be summarized. If the source project name is "X", the name of this table will be "X_Item_Summarize". Not that although you have several options to automatically create this table, you can manually modify the "SummaryName" attribute to change which items will be summarized later on.

Summarize based on offers the following options:

•	complete ItemName: Use this option if you have multiple items with identical item names. This happens if you have created separate items to record data from voucher specimen or different literature references. This is recommended, because only in this way you can later correct errors introduced by misapplied names, or remove some literature information, which you found to be unreliable. The summarized items will be equivalent to taxon (usually species) descriptions.

•	first word in ItemName ("genus"): Use this option if you want to create generic descriptions from species. In the absence of a taxonomic subsystem, DeltaAccess has no idea of nomenclature and does not really know about a genus, but the first word of the item name usually is a good choice. The first word is defined as all characters up to the first blank, period, comma, ";", "(", or "[".

•	the following character...: Use this option to summarize items according to the character you selected. If the character is categorical, the new summarized items will use the character state names as item names, if it is a text character, the text is used directly. Not that if a categorical character is not exclusive, a single item may be added to several "character-state-items", i.e. the sum of items may be larger than your original items.

Press the button Create summarize table to create the table.

Summarize items

The button Create summarized items appends the newly summarized items to the destination project selected in the first step.

You have the option to include or to ignore the item description modifiers or notes. If you include them and the same state from several items must be combined into a single new state, the notes will be appended, separated by a ";" and a new line character.

Categorical characters: The resulting set of character states is the union set of all items summarized in the new item. Thus if for character 2, item 1 has 2,1/2 and item 2 has 2,2/4, the resulting summarized item formed from item 1 and item 2 will have the states 2,1/2/4.

Text characters: data from several items are concatenated, separated by a ";" and a new line character. If two items have identical text entries, this text will not be appended a further time (even if other text was appended in between). Still, some manual editing may be necessary to obtain satisfactorily descriptions.

Numerical characters: The "summarized minimum" is the minimum of the minimum of the summarized items. The maximum is the maximum,

Example:

Item	Min	Lower range	Mean / Median / single value	Upper range	Max
item 1	2	3	5.5	7
item 2	1.5	2	4.5	7	9
item 3	5	6		8
Summary:	1.5	2	5	8	9
and with an additional item 4 added to item 1 to 3, this would look like

item 4		1	8	12
Summary:		1	6	12
Note that in the summary of 1-3, item 3 does not influence the mean value. This is not optimal, but should the median of the range be included in the calculations?

In the second example of item 1-4, one can see that the minimum and maximum values are dropped, if they are already included in the normal range of at least one item.

Contents of Analysis    [image] Main table of contents    [image] Next


 List of all analysis queries and reports available

Analysis Group	T	Name	Description
Analysis of Item relations	Q	Simple-matching similarity for single IID	Note: A matrix of all IIDs against each other would be very slow for larger datasets
Character analysis	Q	Character usage BY Item (crosstab)	Count of character states used for each character/item combination, special states treated as missing
	Q	Character usage BY Item (list)	List version; use Excel pivot analysis to make a cross-tabulation
	Q	Character usage BY Item, incl U,V,-,TE (crosstab)	Here the count of states includes the special states U,V,-, and TE
	Q	Character usage BY Item, incl U,V,-,TE (list)	List version. General note: these queries are useful to check the completeness of character or item data
	Q	Character usage cross tabulation (test scoring dependencies; U,V,- = missing)	Which combinations of characters are used how often in the items? 'U'/'-'/'TE' are counted as not used, 'V' as used//CHECK: CORRECT?.
	Q	Character usage cross tabulation (test scoring dependencies; U,V,- = used)	Which combinations of characters are used how often in the items? 'U'/'V/'-'/'TE'' are counted as used.
Character cross tabulation	Q	Char-state usage Char 1 x 2 (crosstab)	Cross-tabulation (= 'contingency table') of 2 characters against each other
	Q	Char-state usage Char 1 x 2 (crosstab, names)	Names version = uses character names instead of CID numbers
	Q	Char-state usage Char 1 x 2 (list)	List version; use Excel pivot analysis to make a cross-tabulation
	Q	Char-state usage Char 1 x 2 (list, names)	Names list version = uses character names in addition to CID numbers
	Q	Char-state usage Char 1 x 2 x 3 (list)	List version for 3 categorical characters; use Excel pivot analysis to make a cross-tabulation
	Q	Char-state usage Char 1 x 2 x 3 (list, names)	Names list version for 3 categorical characters, uses character names in addition to CID numbers
	Q	Char-state usage Char 1 x 2 x 3 x 4 (list)	List version for 4 categorical characters; use Excel pivot analysis to make a cross-tabulation
	Q	Char-state usage Char 1 x 2 x 3 x 4 (list, names)	Names list version for 4 categorical characters, uses character names in addition to CID numbers
Character cross tabulation (numeric)	Q	Numerical x categorical char (list, names)	Numerical x categorical character, use pivot analysis in Excel = ANOVA design
	Q	Numerical x numerical char (list, names)	Two numerical characters = regression design
	Q	Numerical x numerical x categorical (list, names)	Two numerical characters are crossed with a categorical character = GLM design
Character state analysis	Q	Char-state usage BY Char (crosstab)	In how many items are the states of each character used? Sorted by char. number (CID)
	Q	Char-state usage BY Char (crosstab) only IN/RN	As above, numerical characters only
	Q	Char-state usage BY Char (crosstab) only OM/UM	As above, categorical characters only
	Q	Char-state usage BY Char (crosstab) sort by name	In how many items are the states of each character used? Sorted by char. name
	Q	Char-state usage BY Char (list/percent)	List version. The percentage of each state relative to all states of the same character is calculated
	Q	Char-state usage BY Item (list)	List of char./char. states x items; for categorical characters = complete matrix in list form; useful only as basis of further analyses
	Q	UM/OM char-state multiplicity BY Char (list/percent)	For each char: How often are 1, 2, 3, ... different states of this char. used in a single item
	Q	UM/OM char-state multiplicity BY Char (list/percent, resolving combined CS)	As above, combined states (1&2) are treated like separate states (1/2)
	Q	UM/OM char-state multiplicity: Potential additional exclusive (Multistate=0) characters	List characters where any item uses at most a single character state, could be set to Multistate = exclusive
Chart/graph reports	R	Char. state usage of Char 1 x 2 (bar graph using CS-Name; like a crosstab)	Char. state usage of 2 characters (cross-tabulation as bar graph; using char. state name)
	R	Char. state usage of Char 1 x 2 (bar graph using CS; like a crosstab)	Char. state usage of 2 characters (cross-tabulation as bar graph; using the state code; state names are given in a legend)
	R	Char. state usage of Char 1 x 2 (bubble graph using CS; like a crosstab)	Char. state usage of 2 characters (cross-tabulation as a bubble graph, size of bubble -> proportion of items with this combination; using the state code)
	R	Character state usage over all items, separate bar graphs for types: UM/OM/RN/IN	In how many items is each state used? (Quantitative)
	R	Character state usuage by character (graph), all items + each item separately	Is a state used or not? (Qualitative, first page shows all items together, following are 1 page for each item)
	R	Mean, range, min/max of categorical/multistate characters, over all items (Graph)	Box plot like for numerical character, sometimes useful for ordinal char. (note: mean is not really defined for type OM!)
	R	Mean, range, min/max of numerical characters (Graph)	Box plot with indications of mean and min/max for each numerical character, over all items of current subset
Checking data	Q	Exclusive character state condition (Multistate=0) violated	List all items where multiple character states are scored(e.g. '1/2'), although the char. is defined as exclusive
	Q	List items where all states of a char. are used (states are 'saturated')	If all states have been used (scored), you might consider coding the item as variable (V) in respect to this character instead
	Q	List items where both "Present" and "Absent" states are used	If a char. has only two exclusive states like present/ absent, the special state 'V' should be used to indicate variability
	Q	List items where both normal and special CS are used	You have used a char. state combination like 1/U or V/1 or 1/-. normally these do not make sense.
	Q	List items where 'mandatory' characters are missing	Which items are not using which mandatory characters?
	Q	Numerical chars, Max of each statistic (crosstab)	Plausibility test: Display the maximum for each numerical statistic (attribute, e.g. min, mean, max, ranges)
	Q	Numerical chars, Min of each statistic (crosstab)	Plausibility test: Display the minimum for each numerical statistic (attribute, e.g. min, mean, max, ranges)
	Q	Numerical chars, Min/mean/max of any statistic	Quick plausibility test, it does not matter in which numerical attribute the Min or Max are found.
	Q	Numerical statistics, sequence violated (min>mean, etc.)	Plausibility test: The main numerical attributes are checked for min < range < mean < upper range < max
	Q	Test for use of "-" ("to"-operator, modifier) in UM type characters	If a char is type UM, 1-3 is equivalent to 1/3, not 1/2/3. You may have coded correctly, but its worth checking
Consistency checks if 'referential integrity' failed	Q	DEP (dependency) records with non-existing char./char.state comb. or inapplicable char.	Use ONLY if you received an error message "relation could not be created" during import
	Q	DESCR records without CS record (= Items with non-existing character/char.state combination)	Use ONLY if you received an error message "relation could not be created" during import
Edit or view data	Q	Edit Data + CS	Example of item description join. Use not recommended, use ItemEdit form instead!
	Q	Edit Item + Data	Example of item description join. Use not recommended, use ItemEdit form instead!
	Q	Edit Modifier templates	Called from button in CharEdit edit form! Organized into usage groups, which can be enabled as predefined modifier set.
	Q	Full item data output	This is the base query used to export a project to DELTA or natural language (as RTF) format.
	Q	Items with single text character	Can be used as very simple tabular report. You can enter the CID of the text character you want to list.
	Q	List linked characters (char groups)	Overview over linked characters. Should be replaced by a graphical overview in the future.
	Q	Mean, or middle of ranges/min/max of 1 numerical char.	Displays the "(Min-) LowerRange-Mean-UpperRange (-Max)" formatted data for a single numeric character; plus the mean, or the middle value between Ranges/Min/Max
	Q	Mean, ranges, min/max of numerical char. for each item, columns	Displays the main statistical attributes, one column each for Mean, Ranges, Min, and Max; without Notes
	Q	Mean, ranges, min/max of numerical char. for each item, columns, incl. Notes	Displays the main statistical attributes, one column each for Mean, Ranges, Min, and Max; plus Notes of all numerical attributes (concatenated into 1 column)
	Q	Mean, ranges, min/max of numerical char. for each item, formatted, incl. Notes	Data are formatted as "(Min-) LowerRange-Mean-UpperRange (-Max)"; all Notes collected into 1 column
	Q	Show max of LinkGroup	Show the highest LinkGroup number. Normally not very useful.
	Q	Show max of NumStates	The character with the most character states has this many states defined. Normally not very useful.
	Q	View a list of all analysis queries, forms, and reports provided in the analysis section	This list in the help file has been generated using this query!
Inapplicable characters	Q	Inapplicable chars defined as mandatory	Mandatory + potentially inapplicable is possible, but not recommended
	Q	Inapplicable chars used (not updateable)	List items where a character has been used although it should be inapplicable
	Q	Inapplicable chars used (write to table TEMP_InapplicableUsed)	List items where a character has been used although it should be inapplicable; creating a table that can be used to join it with the DESCR table for editing
	Q	List controlling chars/states with inapplicable chars	List all controlling characters/states together with the inapplicable characters they control
	Q	List controlling chars/states with inapplicable chars, 4 levels hierarchy	As above, plus a 4 level deep recursion if an inapplicable char. controls another inapplicable char.
	Q	List inapplicable characters (DELTA Format)	List all potentially inapplicable characters, formatted like in the DELTA Dependent/Inapplicable directives
	Q	List inapplicable chars with controlling chars/states	List all potentially inapplicable characters together with their controlling characters/states
Reorganize project	Q	Implicit states: Check applicable (= no other state used)	Which items, where characters with an implicit state are not used otherwise, would receive the implicit state?
	Q	Implicit states: Insert permanently into item description (_DESCR)	Insert the results of the check implicit query as permanent data (table <projectname>_DESCR)
	Q	Unused chars: Insert 'U' as item data (all types)	Insert special state 'U' for each item/char combination where no other data have been set
	Q	Unused chars: Insert 'U' as item data (OM/UM only)	Like above, restricted to categorical characters (type UM/OM)
Repair and maintenance	Q	Add character heading default AutoGroups	Add default AutoGroup headings to character headings (special named character groups for identification). Automatically executed when new project is imported or created!
	Q	Add CS: Full numeric attributes for all RN/IN	Add the extended numeric states (sample size, Confidence intervals, etc.) to the minimal numeric states.
	Q	Add CS: Internal state TE for all text char (TE)	Only for repair of a corrupted char. definition: Insert character state TE into all chars of type text
	Q	Add CS: Minimal numeric attributes for all RN/IN	Only for repair of a corrupted char. definition: minimal numeric states are default for all numeric chars.
	Q	Add CS: U,V,- for all OM/UM/RN/IN	Add the standard DELTA special states to all categorical and numerical characters
	Q	Char. Definition: Move Unit of categorical characters to CharStateName	Already used during import to remove Units from categorical char. and append them to CharStateName
	Q	Enable all modifiers for all characters (not recommended!)	Enabling all modifiers results in huge pick lists including inapplicable modifiers like colors for non-color chars.
	Q	Item description: Move recognized Notes to Modifier	Try to recognize modifier strings in the Notes field, move them to the Modifier-field. Executed during import.
	Q	NumStates: Set to used	Number of states attribute is calculated from the number of states actually used
	Q	NumStates: Used <> Defined	Check where the number of states used differs from the number defined
Special character states	Q	Combined categorical char. states, e.g. '1&3' (Char. def.)	In which characters have combined character states been defined?
	Q	Combined categorical char. states, e.g. '1&3' (Item list)	In which items have combined character states been used?
	Q	Not applicable ('-') used (Item list)	List all character/item combinations where the special state '-' has been used
	Q	Not applicable ('-') used explicitly where already implicitly n/a	List all character/item combinations where '-' has been used although this is already defined through character dependency/inapplicability
	Q	Not applicable ('-') used explicitly where already implicitly n/a: delete!	Delete all character/item combinations from the query above
	Q	Text ('TE') instead of categorical (UM/OM) data allowed (Char. def.)	In which characters has the text override state (TE) been defined?
	Q	Text ('TE') instead of categorical (UM/OM) data used (Item list)	In which items has the text override state (TE) been used?
	Q	Unknown ('U') used (Item list)	In which items has the special character state 'U' (unknown) been used?
	Q	Variable ('V') used (Item list)	In which items has the special character state 'V' (variable) been used?
Tabular reports	R	Item description report w. checkboxes for categorical char., includes notes, numerical/text char.	To be used as a form for "offline" editing. Categorical char appear as checkboxes, numerical and text char. as separate lists
	R	Simple tabular character/char. state definition report	Character definition, character states, optionally linked modifiers; includes character headings
	R	Simple tabular item description (= data) report	Item name together with description (scored char. state + numerical and text data)
	R	Simple tabular item name report, grouped by 'genus'. 2 columns.	("Genus" is defined as the first word in item name)
	R	Simple tabular item name report, sorted by % of unused chars (UV- = unused)	Item names, sorted by number of characters in which item is not used (special char. states treated as not present = missing)
	R	Simple tabular item name report, sorted by % of unused chars (UV- = used)	Item names, sorted by number of characters in which item is not used (special char. states U/V/-/TE treated as normal states)
	R	Simple tabular item name report. 2 columns.	Item names alone
Unused items/characters	Q	Unused Char-states (U/V/- excluded)	Which character states (except for the spec. states U/V/-/TE) have not been used (scored) in any item?
	Q	Unused Char-states (U/V/- included)	Which character states (incl. the spec. states U/V/-/TE) have not been used (scored) in any item?
	Q	Unused chars per item (%/item-order, UV- = unused)	Number of characters in which item not used (special char. states treated as not present = missing)
	Q	Unused chars per item (%/item-order, UV- = used)	Number of characters in which item not used (special char. states U/V/-/TE treated as normal states)
	Q	Unused chars per item (%/percent-order, UV- = unused)	Number of characters in which item not used (special char. states treated as not present = missing)
	Q	Unused chars per item (%/percent-order, UV- = used))	Number of characters in which item not used (special char. states U/V/-/TE treated as normal states)
	Q	Unused item-char combinations (CID-order)	List all items which do not use a given character state, sort by CID
	Q	Unused item-char combinations (item-order)	List all items which do not use a given character state, sort by item name
	Q	Unused items per char (CID-order, UV- = unused)	Number of items in which char not used (special char. states treated as not present = missing)
	Q	Unused items per char (CID-order, UV- = used)	Number of items in which char not used (special char. states U/V/-/TE treated as normal states)
	Q	Unused items per char (percent-order, UV- = unused)	Number of items in which char not used (special char. states treated as not present = missing)
	Q	Unused items per char (percent-order, UV- = used)	Number of items in which char not used (special char. states U/V/-/TE treated as normal states)
Contents of Analysis    [image] Main table of contents    [image] Next


The column T indicates the object type: Q = query, R = report, F = form. You can click on the name of the Analysis Group/Type to jump to more detailed explanations of the analyses in each group.

When opened from the main analysis dialog, queries are normally deleted after use. To use them again directly or save modifications, you must save them under a different name.


 Analysis queries provided

A comprehensive overview over all analysis/editing queries and reports available can be found in the previous chapter List of all analysis queries and reports available. The following sections supply detailed information about most of the available queries:
   Analysis of item relations
   Character analysis
   Character cross tabulation
   Character cross tabulation, numerical characters
   Character state analysis (char. state usage)
   Checking data
   Consistency checks if 'Referential Integrity' failed
   Edit or view data
   Inapplicable character (= character dependency)
   Reorganize project
   Repair and maintenance
   Special character states
   Unused items/characters
See also:
   Chart/graph reports
   Tabular reports

Note: Several queries need "helper queries" (e. g. named <Your Projectname>_IID_x_CID...), which will not be deleted after use. You can delete them if you have not saved any queries using them. If you open a query from the DeltaAccess dialog box, any necessary helper queries will be recreated as needed.

Please tell me if you are looking for other types of analysis (they may not be easy or possible though). If you create useful queries yourself and want to share them, I will be glad to integrate them into future versions of DeltaAccess. Also, please contact me if you would like to see more explanations for a specific analysis.

Contents of Analysis section    [image] Main table of contents    [image] Next


 Analysis of item relations

Currently there is only a single very rudimentary analysis, Simple-matching similarity for single IID. It will calculate the number of all matching character states between a specified item (you are prompted to enter an item IID when you run the query) and all other items. Non-matching character states are ignored. After you have switched to design view, you can remove the restriction to a single item and generate a full matrix of item relations. Be warned though that with a large data set this can be a very slow process. The size of the join will be approximately the square of the number of records in the _DESCR table, which may be 105 × 105 = 1010 records, the index alone of such a thing would be 74 GByte... Such analyses and more sophisticated similarity calculations can not be executed with straightforward SQL, you have to use more sophisticated algorithms and program them separately.

Instead of programming multivariate analysis techniques like cluster analysis into DeltaAccess, an export format for the major statistics packages (SAS, SPSS) will be added in the next version.

Analysis queries    [image] List of all analysis options    [image] Next


 Character analysis

Character usage BY Item (crosstab) displays for each item and character the number of character states used. The character number (CID) is listed as column heading. This version excludes the special states (U/V/-/TE); all text characters (type TE) are therefore completely missing. A second version includes these states (Character usage BY Item, incl. U,V,- (crosstab)). Here the cell is empty if the character is not used at all, and an "X" appears if the character is textual or numeric, i. e. no categorical character states are defined.

The cross tabulations will work only up to 255 characters. To analyze descriptor projects with more characters, you can define character subsets (e. g., with categorical = UM/OM characters only), or you must use the list versions Character usage BY Item (list) and Character usage BY Item, incl U,V,- (list) and finish the analysis using the pivot analysis in Excel.

To see a total of the above queries, i.e. how many items have used 1, 2, or more states for a give character, use one of the char-state multiplicity BY Char analyses under Character state analysis. These analyses above and the multiplicity analyses are closely related. The 'Character usage BY Item' analyses above could also have been called 'Character state multiplicity BY Item'. The different naming conventions were chosen, because the primary interest in the analyses above is whether states have been used at all. The multiplicity of character states is added information, which is only rarely useful.

The character usage cross tabulations do not provide row and column percentages. You might therefore want to export the DeltaAccess cross tabulation to Excel, and do the following:

Column percentages: In Excel, insert a new row above the data, enter an equation in the cell above the first column, containing: =COUNT(B3:B100)/ROWS(B3:B100), assuming that your Count of character state data for this column are in B3 to B100. Format the cell with Percentage, 1 decimal place (Format Cells in the context menu, select the first tab Number, Percentage). Copy it, mark all the empty cells above the columns to the right, and paste a copy of the first cell.

Row percentages: Insert a new column in front of the data, enter an equation like: =COUNT(C3:Z3)/COLUMNS(C3:Z3) into the first cell, format as percent. Copy the first cell, mark all the empty cells in front of the rows, and paste a copy of the first cell.

In combination with row and column percentages, the character usage table is an excellent tool to check the completeness of your data set. Any char with a column percentage close to 100% should be checked for the missing data (items which have not been filled). It is likely, that this character should in fact be available and scored for all items. Any item with a low row percentage is recognized as badly treated.

*** Note: it would be better to have character instead of character state counts, make additional analyses using the same helper queries used by cross tabulation below ***

While the above queries count how many states are used in each character, the following queries count the use of any state of a character:

Character usage cross tabulation (test scoring dependencies; U,V,- = missing) and ...; U,V,- = used): In this analysis, all characters are tabulated against all other characters. The table counts in how many items a pair of characters is used together. In the first analysis, a character is counted as used (scored), if either a normal character state, or the special state 'V' was used. The special states 'U'/'-'/'TE', are excluded and counted as missing. The second analysis (...; U,V,- = used) counts all states as used.

This type of analysis is useful to detect hidden dependencies among characters. Note that this analysis will not show you characters dependent on a certain state. It will only show exclusive groups of dependent characters. For example, if character 2 is applicable only if state character 1, state 1 has been set, and character 3 is applicable only if character 1, state 2 has been set, a result could look like:

	1	2	3
1	87	69	12
2	69	14
3	12		1

Compare also the queries in the following section Unused items/characters for more detailed information on which item/character combinations have not been used. If you want to know in which items you have used one of the special character states (U/V/-/TE) you can use queries from the section Special character states.

Analysis queries    [image] List of all analysis options    [image] Next


 Introduction to character cross tabulation

If you want to analyze how characters interact, you can make a cross tabulation (or contingency table) of characters. Only for binary characters (which are not available in DELTA) you would cross the character directly. In categorical characters (UM/OM) you cross the character states instead. Since conceptually you want to compare characters rather than states, DeltaAccess uses the term character cross tabulation. The following chapter Character cross tabulation discusses the available analysis options for categorical characters.

If you want to compare numerical characters (IN/RN) you must first group the values into classes, to get a one-dimensional frequency distribution of each character you want to compare (see Frequency distribution of numerical characters). These frequency distributions can then be compared in a cross tabulation. Currently, DeltaAccess offers only limited support for cross tabulation analysis of numerical characters; you must use, e. g., MS Excel to finish you analysis.

You can further analyze cross tabulations statistically by exporting them to a statistical analysis software (e. g. the SAS system) and run a chi-square test, G-test (loglinear test), or Fisher's exact test. The latter should be preferred, if sample size is small and many cells of the table contain less than 6 items. Although Fisher's exact test was originally defined only for 2 x 2 tables, most statistical software packages will offer a generalized version of Fisher's exact test for n x m tables. On the other hand, Fisher's exact test will be very slow if the size of the table becomes large, so you might have to resort to the approximate chi-square or G-test.

These statistical tests test the null hypothesis that the characters are independent. Character dependence can have several causes:

•	A single gene could influence some states of both characters. For example, if the ability to synthesize dark pigments is lost in a certain species that can survive without such pigments, many characters many turn from dark or colored states to colorless.

•	The characters may be genetically linked. For example, if your data set contains closely related organism, characters could remain linked if relevant genes are situated in close neighborhood on the same chromosome.

•	There may be a phylogenetic correlation. This occurs if two genetically independent characters, which have arisen not multiple times in the evolutionary history of the organism group studied, have evolved in the same branch.

Statistical methods of phylogenetic inference assume that the characters (whether morphological or molecular) are independently identically distributed (IID condition of random variables). Clearly, the assumption of independence is rarely fully satisfied. Even consecutive bases of DNA sequences of non-coding regions are not completely independent.

Note that the statistical test mentioned above can not test the validity of this assumption. They can not distinguish between the first causes mentioned, which make the phylogenetic inference unreliable, and phylogenetic correlation.

See also the chapter on Comparing characters with external classifications, phylogenetic trees or cluster analyses.

Analysis queries    [image] List of all analysis options    [image] Next


 Character cross tabulation

(See also Introduction to character cross tabulation.)

Char-state usage Char 1 x 2 (crosstab) will generate a cross-tabulation of the character states of two characters. You will be asked for the numbers (CIDs) of two characters when you execute the query. Note that although explicitly coded U/V/-/TE states are present, neither implicit character states nor Null-states (i. e. states you have never used) are. Thus when you look at the row-sum for, e. g., state 1, further items may have the state 1 of the first character you selected, but for these items the second character is not defined at all. Also, note that because of multiple character states, the row sum may exceed the number of items in your data set. A second version: Char-state usage Char 1 x 2 (crosstab, names) uses the character names instead of the character number (CID) as column headers. It is not possible to display both the number and the name as column label of a crosstab in the current version of Access. You can do it only with the following list versions and Pivot analysis in Excel.

To analyze 2 to 4-way interactions between characters, including "0"-entries, row sums, and column sums, the queries: Char-state usage Char 1 x 2 (list) to Char-state usage Char 1 x 2 x 3 x 4 (list) provide the information equivalent to a crosstab in list form. The queries named Char-state usage [...] (list, names) are identical with these queries, except that they add the character and character state names to the list. This can be convenient if you want to make reports. See the section about crosstab queries above for a discussion of how such lists can be used together with the Excel pivot wizard to create very flexible multidimensional crosstab analyses.

Note that the results will only take explicit 'U'-states into account. DELTA defines unused characters (for this item no character state has been set) as implicitly unknown. It is therefore possible that if character 7 and 12 are crossed, and the independent count of items for which character state has been used is as follows:

CID	CS	Count
7	1	8
7	2	5
7	3	1
12	1	1
12	2	13
12	3	1
The cross-tabulation of CS1 = CS(character 7) and CS2 = CS(character 12) looks like:

CS1	CS2	Count
1	2	8
1	3	1
2	2	5
2	3	1
3	2	1
This is so because missing states can not be crossed. If you want an analysis including the missing states you must use reorganize queries to insert 'Unknown' into item descriptions. Inserting 'U'-states guarantees that each item uses all characters, so the cross-tabulation will be complete.

Analysis of states within a character: Note that you can use the analysis queries discussed above to analyze the relationship between the character states of a single character. If you start Char-state usage Char 1 x 2 (crosstab) and enter the same character number (CID) for the first and the second character, you will analyze multistate situations within a character. For example:

In the following example, the results for a character with 3 states indicate that character state 1 occurs 74 times alone, 4 times in combination with state 2, which occurs 126 times without other states. State 2 also occurs 10 times together with state 3, which never occurs alone. Such a result should be reason to reassess the definition of state 3. It seems likely that state 3 is not independent of state 2. Note that this is always a symmetrical matrix, since, e. g., CS1 x CS2 must be identical with CS2 x CS1.

CS (char 1)	CS (char 2) ->	CS1	CS2	CS3
1		74	4
2		4	126	10
3			10

If you want to tabulate complex "features" of your items, which are defined through a combination of several characters, you can use the Multi-ItemEdit dialog box to create calculated characters. Compare also the chapter Comparing characters with external classifications.

As discussed in the Introduction to character cross tabulation, the analysis queries in this section cross the character states of several characters against each other. An analysis which indeed crosses all characters against all characters, counting only whether a character is used (scored) or not, is Character usage cross tabulation. It is listed under character analysis.

Analysis queries    [image] List of all analysis options    [image] Next


Character cross tabulations, numerical characters
 Character cross tabulation, numerical characters

In addition to the cross tabulations of categorical characters against each other, 3 analyses involving numerical characters are provided. They are provided in list format only (i.e. not crossed inside DeltaAccess) and intended for use with the pivot analysis in Excel.

Numerical x categorical char (list, names)
Numerical x numerical char (list, names)
Numerical x numerical x categorical (list, names)

You can cross two numerical (IN/RN) characters alone (Numerical x numerical) or under the condition of a categorical (UM/OM) character (Numerical x numerical x categorical). You can also tabulate a single numerical character against a categorical character.

For the numerical characters, the Min, Mean, Max, and lower and upper range are given. The "Mean" column may contain a mean, median, mode or a single value. A field CalcMean is calculated, which is defined as the Mean if present, or the Mean of the upper and lower range. The queries with two numerical characters also calculate the ratio of the calculated mean of the first numerical character through the calculated mean of the second numerical character.

In contrast to the list versions for categorical characters ('Char-state usage Char 1 x 2...'), the result of this list is not a count of occurrences, but the original values. Because of this, the results contain the attribute ItemName. The results of the analyses involving categorical characters can be further analyzed using pivot analysis in Excel. Excel can, e. g., calculate the mean, min, max, count, etc. of the mean values of the items.

Compare also the chapter Frequency distribution (histogram) of numerical characters.

Analysis queries - [image] List of all analysis options    [image] Next


 Character state analysis (char. state usage)

To analyze how often certain character states of each character have been used, you can use Char-state usage BY Char (list/percent). The percentage is relative to all states of the same character. It pertains to all items, even if the character in question is inapplicable to some items.

The option Char-state usage BY Char (crosstab) presents this as a cross-tabulation in more compact form, but without percentages. In the cross-tabulation the special states (U/V/-/TE) are excluded. Three more analysis variants are available to restrict the analysis to numerical (...only IN/RN) or categorical (...only UM/OM) characters only, or sort the crosstab by character name instead of character number (...sort by name).

Character state usage by item cross-tabulation would be a very large matrix containing only yes/no values. Since Access is limited to 256 columns in a cross-tabulation, only a few characters could be displayed as a matrix. The information in list form is available as Char-state usage BY Item (list). It is not very useful in itself, but provided here as the basis of further analysis steps. A similar query is, e. g., the basis of the checkbox report.

Multiplicity: If you want to know how often you have used multiple states of a categorical character (type UM/OM), you can use UM/OM char-state multiplicity BY Char (list/percent). This query counts the number of times 1, 2, 3, etc., states (regardless which states, except for the special states U/V/-/TE). The first query treats combined character states (which have been defined as, e. g., '1&2' in the character definition) as a single, additional state. UM/OM char-state multiplicity BY Char (list/percent, resolving combined CS) is more exact (but slower) and resolves these cases. Use the Character usage BY Item analysis queries from Character analysis to analyze the character state multiplicity by item.

An interesting option to revise your character definition is: UM/OM char-state multiplicity: Potential additional exclusive (Multistate=0) characters. It checks which characters could potentially be changed to MultistateType exclusive (value=0), without any item descriptions violating this condition. Exclusive characters do not allow the scoring of multiple character states of a character. For example, '1,1/2' = character state 1 OR 2 of character 1, would not be allowed. Restricting your characters to exclusive simplifies many statistical analyses, which are difficult to interpret if multiple states can be present. It is therefore desirable to define as many characters exclusive as possible. Classical DELTA defines the EUM/EOM character types for this purpose, while DeltaAccess uses the MultistateType attribute. Under the analysis section Checking data a query to check your item descriptions for violations of the exclusive multistate type can be found; in a way the current query does the opposite and looks for a potentially more stringent character definition.

The related question of character state usage of multiple characters crossed is found under the analysis type Character cross tabulation. Such cross-tabulations or contingency tables analyze, e. g., for 2 characters with 2 states each, how many items have the character state combinations '1,1 x 2,1', '1,1 x 2,2', '1,2 x 2,1', and '1,2 x 2,2', respectively.

Note that you can also cross the states of a single character. If you enter the same character number both as first and second character of the cross-tabulation, you can see how often certain states occur single or together with another state. See Analysis of states within a character for more information.

Analysis queries    [image] List of all analysis options    [image] Next


 Checking data

This group of queries is concerned with checking the integrity or plausibility of your data.

Exclusive character state condition (Multistate=0) violated: If a categorical character has been defined as MultistateType exclusive (value = 0), this query finds all items where more than one character state has been entered. Example: if character '1' is defined as exclusive, then '1,1/2' violates this restriction. Compare the section on Character state usage for a query to search for potential additional exclusive characters.

The group starting with List items where... checks certain character state situations in categorical characters.

List items where all states of a char. are used (states are 'saturated'): Lists all characters and items where all character states (except the special states U/V/-) have been used (= scored). Another expression for this situation is that the character states are "saturated" for this item. You might want to consider using the special state 'V' (variable) instead. If all states are scored, no information is available for identification.

List items where both "Present" and "Absent" states are used: If a binary character has two exclusive character states, they should normally not be both used (or scored) in a single item. The special state 'V' (variable) should be used instead. Note: The query searches for a combination of the strings "presen" and "absen" (to cover "present" and "presence"). It therefore works only with english wording. If you have used "Yes" and "No" or using a different language, you can easily modify the query in design mode.

List items where both normal and special CS are used: The special states U/V/- should normally not be used together with other character states or themselves. Such combinations do not make sense in an analytical context. The query finds all cases where for single item both special and normal states are defined, e. g., 5,4/- or 5,U/1. This should normally considered an error, although in rare exceptions it might not be one.

List items where 'mandatory' characters are missing: Characters can be defined as mandatory (or 'required') in the character definition. The query lists all item where this condition is violated. Compare also the option to check for potential conflicts between mandatory and inapplicable definitions. ***Currently this includes mandatory characters which are inapplicable, must be revised! Note that if you use the internal forms provided you will be alerted during data entry that a mandatory character has not yet been entered, this option is relevant mainly after import of and after you have made a character mandatory which was not mandatory before.

Checks specific to numerical characters: The queries testing Min/Max of each or any statistic across all items are not very valuable to analyze items, but very useful to catch errors in the data set.

Numerical chars, Max of each statistic (crosstab) and Numerical chars, Min of each statistic (crosstab) will not retrieve the minimum or maximum entered for an item, but the minimum or maximum of the statistic (= numerical attribute, e. g., minimum, mean, or maximum). This can be very useful for error checking. Normally you will now the probably range of your values. Also, if the minimum of all means is less than the minimum of all minima, you probably have made a mistake during data entry. Numerical chars, Min/mean/max of any statistic even pools all statistics, i.e. it calculated the minimum of any value entered for an item for this character. This is very useful for a fast for an initial search for errors which result in values of different orders of magnitude, e. g., the omission of a decimal point. Then use the detailed tests to see in which statistic the errors can actually be found.

An additional plausibility test that can be performed on the statistics entered for numerical values, tests for the sequence of attributes: Numerical statistics, sequence violated. It checks whether Min  lower range limit  Mean/median/mode  upper range limit  Max. Note that the conditions involving the range are not strict. If, e. g., the distribution is asymmetrical and the range is defined as mean plus/minus standard deviation, the minimum can be larger than the lower range limit, or the maximum larger than the upper range limit.

Test for use of "-" ("to"-operator, modifier) in UM type characters: If the '-' operator is detected in the imported data set (e. g. '2,1-3', where 2 is a UM character), it will be translated using a 'to'-modifier (unless the 'to'-operator is always used, in which case the MultistateType is changed). Frequently, the use of '-' in DELTA data sets turns out to be unintentionally. If a character is of type UM, the DELTA code '1-3' is equivalent to state '1' or '3', not '1' or '2' or '3'. You probably have coded your imported data correctly, but it is worth checking. The query will list all occurrences of this situation, so that they can be confirmed or corrected.

The queries Inapplicable chars defined as mandatory and Inapplicable chars used (not updateable) from the section Inapplicable characters are useful for error checking as well.

Analysis queries    [image] List of all analysis options    [image] Next


Consistency checks if Referential Integrity failed
 Consistency checks if 'referential integrity' failed

	Who should read this: The queries in this section are only needed if you received a message during the import process that a relation could not be created.
Referential integrity protects your data set from becoming inconsistent. For instance, the referential integrity between the character definition and item description guarantees that you can not add a character number to item descriptions which does not exist. If you change a character number (e. g., to change the sequence of characters in the Reorganize character dialog box), the character number in the item description is automatically updated to maintain the integrity of the link.

Referential integrity can only be installed, if the conditions that shall be protected are initially fulfilled. If your imported data violate these conditions, you will receive an error message stating that referential integrity could not be created.

If the relations are properly installed, these queries cannot return any records!

•	DEP (dependency) records with non-existing char./char.state comb. or inapplicable char.

•	DESCR records without CS record (= Items with non-existing character/char.state combination)

Only a few queries are currently provided, because many potential integrity violations will not occur in data sets imported from DELTA coded files. While it is possible to use characters/states in the item descriptions that are not defined in the character definition, it is not possible to define a character state without a corresponding character number.

If you find cases where additional referential integrity checks are needed, please inform me and send me a data set where such an error occurs.

Analysis queries    [image] List of all analysis options    [image] Next


 Edit or view data

Edit... queries

The queries starting with Edit... are editable views to one to several tables. They are provided more as an example of how to join the base tables of the DeltaAccess information model, than because they are particularly useful.

Starting with DeltaAccess 1.6, several queries will be created with each project as default queries. These include queries useful for editing, like ..._StatesPlus_Ordered. However, in general it is recommended to use these queries only as a basis for you own analyses, and use the Character and Item editor for editing.

Currently the only exception is:

Edit Modifier templates: This query is used by the button in the CharEdit-form as well, since the form only supports to edit the enabling of modifiers already present.

Numerical data

There are 3 queries (Mean, ranges, min/max of numerical characters...) available to view the major numerical attributes in more compact format. All three are not updateable (i.e. you can not use them for editing). Two queries displays each attribute in a column of its own, with and without Notes, the third formats the attributes in the usual way as "(Min-) LowerRange-Mean-UpperRange (-Max)", e. g. "(2.0-) 3-4.5-7 (-11)". Since each numerical attribute may have Notes of its own, the Notes shown are collected and concatenated.

The numerical data lists are sorted first by character, then by item. To sort by item first, you can select the column labeled IID and click on the sort button ( [image]) in the toolbar. To restrict the list to a single character or item, ascending, mark this character or item and click on the AutoFilter button ( [image]) see Filtering data.

Mean, or middle of ranges/min/max of 1 numerical char. Asks for the character number (CID) of a single numerical character. In addition to the formatted display (identical with the last query discussed above), for all characters where no mean is given, the middle value of the ranges is calculated. This query is especially useful to create a frequency distribution (histogram) in Microsoft Excel, see Frequency distribution (histogram) of numerical characters.

Sorry, this chapter is incomplete! See the description column in the List of all analysis options for some additional information on the remaining queries.

Analysis queries    [image] List of all analysis options    [image] Next


 Inapplicable characters (= character dependency)

After you have defined some character as dependent on certain character states (i.e. they become inapplicable in any item where this character state has been selected), you can view your definition using:

•	List controlling chars/states with inapplicable chars

•	List controlling chars/states with inapplicable chars, 4 levels hierarchy
(like the previous one, plus up to 4 levels of inapplicable characters, which depend on other potentially inapplicable character are displayed as well)

•	List inapplicable chars with controlling chars/states
(this listing reverses the sorting compared with the previous ones)

•	List inapplicable characters (DELTA Format)
(the first column contains strings identical with those in the DELTA directives Dependent Characters or Inapplicable Characters)

To check for potential error situations, you can use:

•	Inapplicable chars defined as mandatory
List characters which are defined as mandatory and could potentially become inapplicable. Whether you consider the fact that a mandatory character can become inapplicable an error or not is up to you. DELTA data sets often allow this, which means that the character in mandatory only if not inapplicable. Both modes are supported in the editing forms. This error-checking query is provided only to check whether you have not accidentally introduced this situation.

•	Inapplicable chars used (not updateable)
List item/character combinations, where characters have been used despite the fact that they should be inapplicable. This checks which data in the data set violate the restrictions imposed by characters defined as inapplicable. You should test your data set using this query, especially after you have changed the definition of inapplicable (dependent) characters. This query is not updateable, i.e. you can not edit or delete data directly in the query. Unfortunately this query can not be made updateable, so you have to use the item edit form to modify the data.

•	Inapplicable chars used (write to table...)
Like the query above, only that it writes the results to a temporary table "..._DescrInapplicableUsed_TMP". You can use that table to join it with your item descriptions table to obtain an updateable recordset of your item description. A frequent use of such a join is to remove the special states 'U'/'-' from inapplicable characters. These special states are frequently found in inapplicable characters, because they were either explicitly coded as inapplicable ('-') before a general dependency rule was introduced, or because the inapplicability was not sufficiently apparent and therefore first coded with 'U' for unknown. -- A short description of this process follows; please consult the Access documentation for further information: Create a new query (button in database explorer), selecting Design view. The Show Table dialog box allows you to add the temporary table and the table (or query) starting with your project name and ending with "_DESCR". Now you must double-click on the '*' in the ...DESCR table, to add all fields of this table to the datasheet view, and drag the attributes IID, CID, and CS with the mouse from the left table to the attribute with the same nameon the right table, thus creating joins.

Queries involving the explicit inapplicable character-code ('-') can be found under the heading Special character states.

Analysis queries    [image] List of all analysis options    [image] Next


Reorganize project
 Reorganize descriptor project

Most reorganize functions of DeltaAccess are found in the Reorganize project definition form (reorganize characters, items, headings, and  character states) or directly in the item-, heading-, or character-editor. The queries provided here only deal with implicit character states, for which no other dialog exists yet in DeltaAccess.

Implicit character states:

Implicit character states are not converted to data during import or after editing data in DeltaAccess. Treating them like actual data will be desirable for analysis and interactive identification purposes. Adding the implicit states is a comparatively complex process, and it would be very slow to integrate this into the other queries. A database draws its power from the use of indexes, and although generating a view including implicit states (union query) is not too slow, all subsequent operations will be much slower because they cannot use the indices any more.

Implicit states: Check applicable (= no other state used
Implicit states: Insert permanently into item description (_DESCR)

The first option will give you a list of characters that would be inserted if the second option is selected. Implicit character states will then be inserted as actual data (for any item where no other characters states of the same character are already set). This is equivalent to the DELTA directive "Insert implicit values".

Unused characters:

The special state 'U' for Unknown of a character is implicitly present in all items that are unused or not recorded, i.e. no other state of a character has been scored in this item. The behavior is equivalent to defining the special state 'U' as implicit. Therefore, similar queries to the ones described above for user-defined implicit states are provided for the default implicit state 'U':

Unused chars: Insert 'U' into item description (all types)
Unused chars: Insert 'U' into item description (OM/UM only)

These queries insert the special character state 'U' (unknown) into all item/character combinations not yet used (as found by Unused item-char combinations... from the Unused Items/characters query group). This can be useful for analysis purposes, but normally "no entry" (= unused) should indicate that the character has not yet been checked, while an explicit 'U' entry indicates that is has been checked, and either positively no information is available, or contradictory evidence could not be resolved.

Analysis queries    [image] List of all analysis options    [image] Next


 Repair and maintenance

Most of these options should not be needed, because they are either set by default, executed during import or editing of characters in the CharEdit-form, or simply not recommended. They are provided as help in system maintenance, or as repair options only.

Note that the options presented here are only concerned with local problems in a correctly functioning database. Read the section on database repair if the database itself should have become corrupted, e. g., if Microsoft Access can not open it any more.

Add character heading default AutoGroups: Add default AutoGroup headings to the character headings entity (special named character groups for identification). Automatically executed when new descriptor project is imported or created! Note that executing this query may either add only the missing AutoGroup headings (if the default HIDs remained unchanged) or may add duplicates (if the default HIDs had been changed).

Add special CS-Queries: In normal DELTA several special character states, representing the unknown/variable/not applicable codes (U/V/-), are considered implicit. They need not be present in the character definition and are added automatically. DeltaAccess adds them as explicit character states automatically during the import process of external DELTA files. The option Add CS: U,V,- for all OM/UM/RN/IN repeats this at a later time. It might be useful, if you have accidentally deleted the special states.

Similarly DeltaAccess uses several internal character states which are not part of the normal DELTA character definition for the numeric attributes (min, mean, max, etc.) and a special default state for text characters (TE). If you experience problems, you can always run the queries starting with Add special CS: ..., which will insert possibly missing states. Usually you will receive an error message about duplicates (i.e. records to be added are already present), which can be ignored. The difference between the number of records quoted in the error message and the number originally quoted by the append query is the number of internal character states which have actually been added.

The only query in this group that is more generally useful is Add CS: Full numeric attributes for all RN/IN. If during import you did not check the extended numeric attributes checkbox, you can later do this using this query.

Note that instead of adding states globally, you can also add them to selected characters in the CharEdit-form, using the pick list in the header of the character states section, which adds default states for some numeric characters instead of all.

Modifiers: The query Item description: Move recognized Notes to Modifier is executed during setup, you could try to repeat it at a later time, but note that the modifiers will not automatically be enabled. You should enable modifiers either singly, or using the predefined modifier sets.

The number of states options allow you to check if any inconsistency occurred in this calculated field (it is normally calculated if CharEdit-form is used, but you might have added states directly through the use of tables or queries), and to recalculated the NumStates attribute.

Analysis queries    [image] List of all analysis options    [image] Next


 Special character states

If you want to know in which items you have used one of the special character states (U/V/-) you can use:

Not applicable ('-') used (Item list)
Unknown ('U') used (Item list)
Variable ('V') used (Item list)

Searching for 'U' states only returns items where a 'U' has been explicitly entered, not the characters for which no states have been recorded (unused). Compare the section about inserting 'Unknown' into item descriptions.

The code for not applicable ('-') should only be entered explicitly where it is not already evident from the inapplicable character (character dependency) definitions (= implicitly not applicable). Two queries allow you to edit or delete cases in which the not applicable ('-') code is used redundantly:

Not applicable ('-') used explicit where already implicitly N/A
Not applicable ('-') used explicit where already implicitly N/A: delete!

The special state 'TE' may be allowed to directly enter textual information, in effect turning a categorical character into a text character. This might be convenient, yet it is questionable in terms of data integrity. Therefore you can not only check in which items you have used the feature, but also where you have allowed it in the character definition:

Text ('TE') instead of categorical (UM/OM) data allowed (Char. def.)
Text ('TE') instead of categorical (UM/OM) data used (Item list)

Similarly, you can check where you have used combined character states, and where you have defined them:

Combined categorical char. states, e. g. '1&3' (Char. def.)
Combined categorical char. states, e. g. '1&3' (Item list)

Analysis queries    [image] List of all analysis options    [image] Next


 Unused items/characters

The analyses in this group check in various combinations whether any character state has never been used so far, or more specifically, which item/character combinations do not occur.

Unused Char-states (...) checks, which character states, have not been used in any item. Two versions are available: ...(U/V/- included) lists unused special states together with normal states, ...(U/V/- excluded) ignores them.

The queries Unused item-char combinations (CID-order) and Unused item-char combinations (item-order) list all character/item combinations which have not been used. That is, for any given item they list all characters that have not been used in the item description. For large data sets these queries can be quite slow and return many records, which can be confusing to analyze further. Therefore try to use the following queries first:

The queries starting with Unused items per char ... list only the number of items which do not use a given character. Queries starting with Unused chars per item ... are the "character-complement" of Unused items per char... and list the number of characters used for a given item. They are especially useful to check the extent to which an item can be regarded as 'finished'. Use Unused item-char combinations... if you want to see which items are missing.

Both query types are available in different order = sorting modes (percent-order, or item-order/CID-order) and in two versions each, which differ in the way the special character states (U/V/-/TE) are treated. If the query description ends with UV- = unused, the special states are counted as if no character states had been entered, while queries ending in UV- = used count special character states just like normal characters. Use Unused item-char combinations... if you want to see which characters are missing. The Unused item-char combination-queries always work with the UV- = used assumption.

If you want to insert the special character state 'U' (unknown) into all item/character combinations not yet used (as found by Unused item-char combinations...) you can use queries from the Reorganize descriptor project query group, compare inserting 'Unknown' into item descriptions. This can be useful if you want to analyze certain kind of questions. Normally "no entry" (= unused) should indicate that the character has not yet been checked, while an explicit 'U' entry indicates that is has been checked, but the question could not be resolved.

Analysis queries    [image] List of all analysis options    [image] Main table of contents    [image] Next


 Analysis reports provided

Only a few reports are currently provided. If you create your own useful reports and send them to me, I will integrate them into the next version of DeltaAccess. Also, please notify me about any problems with DeltaAccess analysis reports; so far they have not been tested exhaustively.

Reports are created the first time you use them, and unlike the queries, are not deleted after use. You do not have to save them under a new name as you would for queries.

To keep the reports readable, you are frequently asked to enter the first and last character or item number (CID or IID) to be plotted. You can enter, e. g., 1 and 999 to get all characters or items. Please note that in some graphs only every second or third character may be labeled if you try to plot too many characters.

NOTE: There is a bug in Microsoft Access, involving the use of parameters to restrict the scope of the report. Whenever you are asked to enter something like report!FirstCID, or report!Type (German version: e. g. Bericht!FirstCID) simply click OK. Normally this occurs only the first time a report is created from the DeltaAccess dialog box, not when opening existing reports from the database explorer.

Since charts, graphs, or diagrams are in fact reports with embedded charts, compare the following chapter: Analysis charts/graphs provided as well.

Reports to document your project definition or data

Name in DeltaAccess analysis dialog box	Name in database explorer = <Projectname>_ + ...
Simple tabular character/char. state definition report	SimpleCharDefinition

Creates an overview of the character definition of your descriptor project, including Character headings, if available. When you open the report, you are asked about the inclusion of character states and modifiers. For character states you can include all states, only the normal states (without the special states (U/V/-), or no character states. The internal state 'TE' for text characters is never printed, the special state 'TE' for categorical characters is included with the normal states. Similarly, the modifiers defined for each character can optionally be included. Image definitions are currently not printed.

You can use this report (like all other tabular reports) to export the information to Word or another RTF-compatible program. Click on the toolbar button [image] or select Tools, Office Links, Publish it with Word from the menu.

Simple tabular item description (= data) report	SimpleItemDescriptionReport

Can be used like natural language descriptions, but presents data in a tabular form for each character. Useful for error checking, creating printed output to work off-line.

This is the only report which can potentially become very large (several 1000 pages for large projects with several 100 items and a large character definition). For very large data sets it may take 15 minutes or more until the formatting is finished (i. e. the last page reached in preview mode). When opening the report you are therefore prompted for the first and last item to print. You can enter, e. g., 1 and 9999 to print all items. If formatting takes too long, you can abort the report by pressing Ctrl-Break, and open it with fewer items, or open it based on an item subset.

Item description report w. checkboxes for categorical char., includes notes, numerical/text char.	ItemDescription_Checkbox

A full item description which uses checkboxes for the states of categorical characters. This is one of the most powerful reports of DeltaAccess. It is documented in the separate chapter Checkbox report.

Simple tabular item name report. 2 columns	SimpleItemNameReport

Basic item names, IID, abundances

Simple tabular item name report, grouped by 'genus'. 2 columns	SimpleItemNameReport_Genus

As above, item names are grouped by 'genus' (= the 1st word in ItemName). Useful for overview in large item sets.

Simple tabular item name report, sorted by % of unused chars (UV- = used)	SimpleItemNameReport _MissingChars

As Simple tabular item name report, plus the information about how many characters have been filled in like in the Unused Chars per Item queries is added. The special states (U/V/-/TE) count as normal character states.

Simple tabular item name report, sorted by % of unused chars (UV- = unused)	SimpleItemNameReport _MissingChars

As above, except that the special states (U/V/-/TE) are treated as if non-existing. Compare Unused Chars per Item queries. Note that the last two reports have identical names, you can only use either of them. Rename the first before you create the other one to use them both concurrently.

A report is available in the database explorer only after it has been created once using the DeltaAccess dialog box for the given descriptor project. Since the analysis charts/graphs described in the following chapter are always embedded in reports they are listed under reports in the database explorer as well.

*** Two further reports of a new project-independent generation of reports are available from the character dependency tab page of the new character editor or from the database explorer only. They are called DescrCharDependencyDefinition_ByControlled and DescrCharDependencyDefinition_ByControlling and are not listed in the Analysis pick list of the DeltaAccess dialog box. This type of reports will be increased in the future, after which the access to reports will be reorganized.

These character dependency reports list controlling characters, controlling states, and inapplicable characters (= controlled characters). The first report ('by controlling') lists all controlling characters and states together with the characters they control, the second report ('by controlled') lists all characters that are controlled together with the controlling characters and states. Each of the two reports contains the full character dependency definition, only the output is sorted the opposite way.

For more general information about Microsoft Access reports see the Contents of the Access 97 help file, Introduction to Microsoft Access 97, Reports, especially:

Reports: What they are and how they work
Ways to customize a report
Sections of a report

and the help topics in the Contents of the Access 97 help file, under Working with Reports.

List of all analysis options    [image] Contents of Analysis    [image] Main table of contents    [image] Next


 Checkbox report

Analysis group: Tabular reports, Name: Item description report w. checkboxes for categorical char., includes notes, numerical/text char.

This report is intended to print out form sheets, which can be corrected offline, or to enter data on paper. It exports all important item description data. The output is grouped into 4 sections:

categorical (UM/OM) characters with checkboxes (see figure above),
notes/comments associated with categorical data,
numerical characters, and
text characters.

Within each group the characters are sorted by character number (CID). This design was chosen in preference of a strict character sequence, to guarantee that the layout of the checkboxes is identical between items. This is very helpful for data entry and proofreading. The notes to categorical data are output separately, but modifiers are output immediately in front of the character states. Note that classical DELTA has no modifiers, so you had to use the Notes/Comments feature much more frequently. Each item will be printed starting on a new page, and the states are always kept together with the character. This might result in some free space at the bottom of the pages. The sequence of character states defined in the item description is ignored, since all available states are printed. Character headings are not yet included in the output; they might be included in a later version of DeltaAccess.

This report will be rather slow: the number of records equals the sum over all characters of the product of items times character states. I recommend testing it on a subset before running it on a large project with several hundred items. When you start the report you are asked for the first and last item number, so you can easily print, e. g., 50 items at a time. You can create item subsets, to restrict it other than by a range of item numbers.

You are also asked whether you want to output the special states (U/V/-/TE) or not. If you click OK without entering anything, special states will be ignored in the output. If you enter, e. g., 'U' instead of the requested '*', a checkbox for only this special state will be added to the output. See also the development note.

The report is explicitly designed so that it can be exported in RTF format to Microsoft Word. This is convenient, if you want to send proofreading forms to your colleagues using email. Most Windows word-processors should be able to read the RTF format.

Finally, if you want to print a report with only part of the data, e. g., without the text characters, you can modify the saved report. Open the report in the database explorer in Design mode. In the center of the report, under the gray horizontal bar labeled "Detail", you see 4 subreport controls for the 4 report sections mentioned above. Select the control you want to remove, press the delete key on the keyboard. Optionally you could rearrange the remaining subreport controls to eliminate superfluous space. Save the report under a new name.

Compare the chapter Creating item descriptions as HTML forms for similar report using checkboxes. The HTML forms can be used directly in a www browser to edit exiting or create new item descriptions.

Tabular reports    [image] Contents of Analysis    [image] Main table of contents    [image] Next


 Analysis charts/graphs provided

In MS Access, a chart, graph, or diagram is always embedded in a report. The available analyses are described in the following sections:
   Charts: Item analysis
   Charts: Character analysis
   Charts: Two-character comparison

Overview of analysis options    [image] List of all analysis options    [image] Contents of Analysis    [image] Main table of contents    [image] Next


Diagrams: Item analysis
 Charts: Item analysis

Currently there is only a single report with a graph which provides item specific data. Please tell me what other graphs you would like to see:

Graph of mean/ranges of numerical characters for each item: A graph with mean (as a bar chart), normal range (as a box), and min/max extremes (as a line) or all items, for each numerical character on a separate page. The graph is sorted by item mean, of no mean is recorded for an item, the middle of the ranges is used instead. If you want more complex item sets than simple ranges or item numbers, you can create an item subset and plot that. -- This is currently the only graph in which items are compared. Which other are graphs do you consider desirable (other than phylogenetic/similarity comparisons which require special algorithms)?

Analysis charts/graphs provided    [image] List of all analysis options    [image] Contents of Analysis    [image] Next


Diagrams: Character analysis
 Charts: Character analysis

Character / character state analysis:

A graph similar to the one comparing numerical characters for each item is provided for multistate characters: Mean, range, min/max of categorical/multistate characters, over all items (Graph). Note that the mean of ordered categorical characters can not be interpreted as the mean of a numeric character. By definition, the interval between ordered character states is not defined. Yet, the calculation of a mean assumes that the interval is identical. This may sometimes be a good approximation, in which case the graph for these characters may be useful. The graph for the unordered categorical character on the second page of the report is even more difficult to interpret, in most cases one of the following character state usage graphs will be more useful. The name of the saved report in the database explorer is <Projectname>_CategoricalStatGraph.

Char-state usage BY Char (graph): This is the graphical equivalent of the Char-state usage BY Char (crosstab) query! Note that because of the logic of the graph (x/y graph!) all characters are present on the x-axis, but only the character states of ordered/unordered categorical characters (UM/OM) are plotted. The special character states 'U' and 'V' are plotted as 0, the non-applicable marker '-' as -1. Only the first 15 character states are plotted, if you have characters with more states all higher states are ignored. The first page of the report contains an overview of all items, the following pages contain the graphs for each item separately. The name of the saved reports in the database explorer is <Projectname>_CIDxCS_Graph.

While the previous graph only plots the presence or absence of a character state, Character state usage over all items, separate bar graphs for types: UM/OM/RN/IN plots the distribution of character states (average of all items) as percent of all items for which this character has been used. Thus the base is not total items, and is different for each character. The name of the saved report in the database explorer is <Projectname>_CIDxCS_BarGraph_by_Type.

Analysis charts/graphs provided    [image] List of all analysis options    [image] Contents of Analysis    [image] Next


Diagrams: Two-character comparison
 Charts: Two-character comparison

Three different reports with charts are available to compare the character states of 2 characters. The results are graphical representations of the cross-tabulations in the analysis queries Char-state usage Char 1 x 2 (crosstab). In each case you are asked which characters you want to analyze each time you open the report. The number and name of the selected characters and character states are printed on top of the report.

Name in DeltaAccess analysis dialog box	Name in database explorer = <Projectname>_ + ...
Char. state usage of Char 1 x 2 (bar graph using CS; like a crosstab)	CIDxCID_BarGraph_CS

If you have a large number of character states, consider the bubble graph chart below, which is much less confusing in such cases.

Char. state usage of Char 1 x 2 (bar graph using CS-Name; like a crosstab)	CIDxCID_BarGraph_CSName

Identical with previous graph, except that the character state names are plotted directly on the axis. This is not always better, since it leaves less space for the chart, and the states will be sorted alphabetically.

Char. state usage of Char 1 x 2 (bubble graph using CS; like a crosstab)	CIDxCID_BubbleGraph

The area of the bubbles is proportional to the number of items which posses the given cross of two characters. Further, a linear regression of the item counts is calculated. The correlation coefficient r2 can give you an idea of the amount of total variation that could be explained by a linear relationship between the characters. Note that a correlation analysis is only meaningful if both characters are ordinal. It is not possible to create a version with character state names plotted on the axis like in the bar graph chart.

Previews of Two-character comparison graphs:

Char. state usage of Char 1 x 2 (bar graph using CS; like a crosstab):

Char. state usage of Char 1 x 2 (bar graph using CS-Name; like a crosstab):

Char. state usage of Char 1 x 2 (bubble graph using CS; like a crosstab):

Analysis charts/graphs provided    [image] List of all analysis options    [image] Contents of Analysis    [image] Next


Editing data, Table of contents
 DeltaAccess –
a SQL interface to DELTA (Description Language for Taxonomy), implemented in Microsoft Access

Editing data

   Editing overview
   Editing Basics
      General hints on Windows operations
      The Windows clipboard
      Introduction to working with Access forms
   Editing the item definition and description
      Editing the item definition (ItemEdit-form)
      Editing multiple items simultaneously (MultiItemEdit-form)
      Calculated characters
   Editing the character definition
      Editing the character definition (CharEdit-form)
      Editing character headings
      Editing link groups
   Reorganize project definition
      Introduction
      Reorganize characters, headings, or items
      Reorganize character states
      Reorganize descriptions
      Reorganize subsets
   Editing project properties
   Mapping character states (key states)
   Next table of contents: Interactive identification

Previous table of contents    [image] Main table of contents    [image] Next


 Editing overview

For each descriptor project, a set of editing forms is created (unless you have unchecked the Create Forms checkbox). To open an editing form, either choose an appropriate task in the DeltaAccess Switchboard, or select the forms tab in the database explorer and double-click on the name of the form(1). If your project name is X, you can open the form X_CharEdit to edit characters and character states, and X_ItemEdit to edit item or taxon data. Further forms are available, which are applicable to all projects (DeltaMultiItemEdit, DeltaReorganize_..., etc.).

If you are not yet acquainted with Microsoft Access you may want to read the following chapter General introduction to Access forms first. The main forms are described in the following chapters:

   The ItemEdit-form,
   the CharEdit-form,
   the MultiItemEdit form, and
   Edit project properties form, and
   Reorganize characters or character states,

You can also use many queries of the analysis section for editing, but in general this will be less comfortable. For example, although you have some pick lists (= combo-boxes) in the queries, only in forms you can have a pick list for character states which is specific to the current character. Also, some queries are not editable, i. e. you can only use them to view data.

Contents of Editing    [image] Main table of contents    [image] Next


Editing overview, hidden forms notes
(1) Hidden forms: Depending on the settings of some Microsoft Access options you may or may not see additional forms in the database explorer, which have a gray symbol and names starting with "USys". These are subforms used by the main forms and should not be opened themselves.


 General hints on Windows operations

	Who should read this: If you are relatively inexperienced with the manipulation of Microsoft Windows-windows (:-) in general, the following hints may be useful: Continue with the next chapter otherwise.
Windows: Most windows contain a title bar. If you want to move a window on the screen, click with the left mouse button on the title bar, hold the button, and move the mouse. This is called drag and drop in Microsoft Windows.

To change the size of a window, move the mouse over any border until the mouse pointer changes (e. g., to [image]), and drag the border in the direction of the arrow. If you use the corners of a window, you can drag into both directions. Note that some windows can not be resized (e. g., the main DeltaAccess dialog box). Resizing some windows will only increase the empty space. The Editing forms can be resized and the additional space will be used to some extent. Some windows in DeltaAccess will only make use of additional space in the vertical, but not in the horizontal direction.

The title bar contains the following buttons on the right side: . The left button minimizes the window, the center button maximizes the window, and the right button closes the window. Note that, e. g., the editing forms have no special close button. To close them you can either use the File menu or this close button. If the window has already been maximized, the center button will look like in the following set: of buttons:  and will restore the window to its previous size. There is both a window for the application (Microsoft Access, DeltaAccess respectively) and the child-windows of this application, like the editing forms. Sometimes child windows do not have all buttons; e. g., the main DeltaAccess dialog box window has only the close button.

Help: The usual key to obtain help in Windows is F1. DeltaAccess provides its own context sensitive help. If you are reading this in the HTML-version of the documentation, note that the help file is identical with this text. Because of the way in which DeltaAccess is integrated into the underlying database management application Microsoft Access, depending on where you click F1, you sometimes find yourself in the DeltaAccess help and sometimes in the Microsoft Access help.

You can also double-click on the file DeltaAccess.hlp in the Windows Explorer to read this documentation in the help file format.

Keyboard basics: (Only differences to common DOS programs are explained here)

•	A very useful feature of any Windows program is that you can reach menu entries by holding the Alt-key down and pressing the letter which is underlined in the menu. For example, if you have an English Access or Word version, you can start the Find command by pressing Alt-E and then F (the menu entries are written Edit and Find). It is often easier to memorize these keystrokes than obscure shift-control-function key combinations.

•	You can always use Ctrl-F4 (F4 = 4th function key) to close a window inside a program (like an Access form, or an Excel document) and Alt-F4 to close a program, like Access or Excel.

•	Do not use the return or enter key to go from one field to the next, like you would do in most DOS applications. Use the TAB key (usually on the left side of the keyboard, often marked with and arrow pointing to the right. Use Shift-TAB to go back.

•	Another difference to DOS is that to go to the start and end of a table or text, you use Ctrl-Home and Ctrl-End instead of the usual DOS combinations Ctrl-PageUp and Ctrl-PageDown

•	The clipboard keys (Ctrl-X/C/V) are explained in the chapter about the Windows clipboard.

If you are in a table in an DeltaAccess form and cannot move with the Cursor up and down keys between records, please inform me. Access does not do this in subform automatically, but I should have added a function which adds this functionality.

The next chapters Windows clipboard and General introduction to Access forms explain further basic operations which are more specific to Microsoft Access forms.

Contents of Editing    [image] Main table of contents    [image] Next


 The Windows clipboard

Like in most Windows programs, you can use the Windows clipboard to transfer data from one point to another. The clipboard can copy information within DeltaAccess, or copy it to other programs. The clipboard always operates on the selected information on the screen. In Access, this might be a complete record (see record selector above), a marked control containing the complete data from a field, or any text currently selected. The clipboard shortcut keys are chosen because they can be easily reached on the keyboard. The three keyboard combinations Ctrl-C to Copy, Ctrl-X to Cut (= copy and delete, mnemonic: cross out), and Ctrl-V to Insert (mnemonic: like the inserting mark you would make above a line of text to insert new text) are probably the keys most worth remembering. You can access the clipboard functions also through the Edit menu, or through tool bar buttons.

If you want to know more about using the clipboard, or have problems getting the expected results, the following Advanced Windows clipboard information may be worth reading. The next chapter General introduction to Access forms explain basic operations more specific to Microsoft Access forms.

Contents of Editing    [image] Main table of contents    [image] Next


 Advanced Windows clipboard information

	Who should read this: This in-depth note on clipboard operations tries to explain some advanced concepts of the clipboard. Understanding it is helpful for troubleshooting, but not essential for the operation of DeltaAccess.
The clipboard is a very powerful tool. For the simple case of copying unformatted text, the visualization of a separate "clipboard place", to which the text is copied and from which it can be retrieved, is quite sufficient. Yet in many cases this picture can be confusing. To understand the possibilities and limitations of the clipboard better, it is important to visualize the clipboard rather as a notice board, on which offers for information can be posted.

Most programs which copy to the clipboard can offer the information in multiple formats, e. g., as formatted or unformatted text, as vector graphic or as bitmap. A program which pastes information from the clipboard, can decide which format it prefers. In the Microsoft Office programs, the entry Paste Special gives the user control over this choice. The default, which would be inserted with the standard Paste command, is the format selected in the list.

Information offered can be indeed transferred directly to the clipboard. Because this must be done separately for each format offered, this is rather inefficient for large volumes of information. Instead, many programs only paste a reference to the data to make an offer for information. The transfer of the information itself is delayed until another program requests it for a paste operation. This explains why programs sometimes ask upon termination "You copied a large amount of data onto the clipboard. [...] Do you want to save this data on the clipboard?" Also, sometimes unexpected results may occur. For example, if you copy a chart from Excel, you can insert it into Word as Excel Chart Object (default) or as Metafile Picture while Excel is still open. If you terminate Excel, the object has disappeared from the clipboard. If you have not saved the file from which you tried to copy it, relying on the clipboard, you may have lost your work!

Contents of Editing    [image] Main table of contents    [image] Next


 Exporting data to Word or Excel (office links)

If you want to export all the data in a form or report to Microsoft Word or Excel, an alternative to the clipboard are the Office Links. Select Office Links from the Tools menu, or click on the tool-bar buttons [image] (Publish it with MS Word) and [image] (Analyze it with MS Excel).

These actions will write a file in the appropriate format (RTF for Word, Version 5 XLS file for Excel) and open Word or Excel with this file. The files are either written into the active directory, or into your default data directory on your hard disk. If you want to keep the data, it is advisable to rename the files in Word or Excel (using Save-as). Otherwise the file may be overwritten when you export the same query or report the next time.

The functionality of the export to Word is sometimes not fully satisfactory. In general, the layout will be preserved for printing, but the data may be difficult to reformat in Word. This is especially true if you export a report with multiple columns; the columns will be separated by tabulators, which makes it impossible to reformat them. In this case, change the layout of the report to single column first (switch to design view, open the File menu, Page setup).

Contents of Editing    [image] Main table of contents    [image] Next


 Introduction to working with Access forms

	Who should read this: The following sections try to give a short introduction to Microsoft Access forms in general. I can not possibly write a complete introduction to Microsoft Access, but I hope this will get you started. See also the previous chapters: General hints on Windows operations and Windows clipboard.
Please inform me what puzzled you most when you started to work with the DeltaAccess dialog boxes and editing forms! Or: write it up for your colleagues, so I just have to paste it in here...

The following basic topics are available:
   Form views: single record versus multi-record table
   Moving between records, inserting new records, deleting records
   Fields, controls, and pick list (= combo box)
   Editing and saving
   Undo operation
   Sorting and searching data
   Filtering data
   DeltaAccess specific tool-bar buttons

The following paragraphs describe the scope of the topic listed above:

Form views: single record versus multi-record table: Many editing forms can be switched from single record view to a table like, multiple record datasheet view (tool bar buttons: , [image], and [image]).

Moving between records, inserting new records, deleting records: Working with records in general (tool bar buttons: , [image]).

Fields, controls, and pick list (= combo box): Fields are the elements of a record. Navigation between controls. (button symbols on the form: , [image]).

Editing and saving and Undo operation: Working with data within a record (toolbar button [image]).

Sorting and searching data: (tool bar buttons: , [image]) and Filtering data (tool bar buttons: , [image], [image]): Sorting records in a table, query, or form; selecting records based on criteria; finding text in a record set. See also Using Identify to search items.

DeltaAccess specific tool-bar buttons: Explains the function of the following tool bar buttons: , [image], [image], and [image].

If you are new to Microsoft Access you may want to read the following Microsoft Access help topic: Getting started with Access. See also (in the Contents of the Access 97 help file, Introduction to Microsoft Access 97, Forms):

  Forms: What they are and how they work
  Ways to work with data in a form

Contents of Editing    [image] Main table of contents    [image] Next


 Form views: single record versus multi-record table

Form views: Forms can be switched between the detail view (= form, tool-bar symbol: ) and datasheet view (tabular, tool-bar symbol: ) view, using the View menu, and then Table vs. Form. The third view mode is design mode (tool-bar symbol: ), which you only need if you would want to modify a form. (1)

You would switch to datasheet view to get a quick overview over all characters or all items in a descriptor project (or to print them out). Maximize the form (see Title bar in General hints on Windows operations) to see as many records as possible. Note that you can use the tool-bar button search record ( [image]) in datasheet view as well as in form view. A dialog box opens where you can select a character-, item-, or heading-record by number (ID) or name.

Although you can edit some information visible in tabular view, you do not see all data. To edit a single character or item, you should switch into form view. The main editing forms are designed to run in VGA mode (640×480 pixels), but if you resize them or maximize them, they will use the additional space to a certain degree.

Contents of Editing    [image] Main table of contents    [image] Next


(1) DeltaAccess uses special tool-bar definitions, containing the separate buttons [image], [image], and [image]. Special tool-bars are necessary, because the default tool-bars are not visible in the run-time version of MS Access.

{bmcl Viewtool.bmp} If you have a full version of Access, you are probably used to this drop down control at the left side of the toolbar, which can be used as an alternative. (Back to Form views: single record versus multi-record table)


 Moving between records, inserting new records, deleting records

Navigation buttons:  At the bottom left border of a form, table or query are buttons to go to the first, previous, next, last, and new record. An additional new record button is usually present in the tool-bar below the menu as well. You can also see on which record out of the total number you currently are. If you enter a number in the number field you will go directly to this number. Note that the record number displayed at the bottom is not necessarily identical with your item or character number (CID/IID). If you delete, e. g., a character, the character numbers are not automatically renumbered.

Record selector: The record selector is the bar (or 'column') at the left side of forms, tables, or queries. In datasheet view, a record selector is displayed for each record. It normally looks like: , and changes to [image] if the record is selected. To mark or select an entire record (e. g., to copy into the clipboard or to delete), click with the mouse on the record selector. As soon as start editing a record, the record selector changes to [image], to mark this. New records which are not yet edited are marked [image]. Microsoft Access normally saves records automatically, but if you want to save a record manually you simply click on the record selector.

Deleting records: To delete a record click on the delete record button in the toolbar ( [image]). See also delete a record for an alternative method using the keyboard.

Inserting records: To insert a new record (e. g., to add a new character), click on the insert record button in the toolbar ( [image]) or the equivalent navigation button [image] at the bottom of the form. In a datasheet (table, query, or form in datasheet view) you can also simple put go to the last row where the record selector looks like: . The star indicates a new record.

You can also select one or several records, copy them to the Windows clipboard (Ctrl-C), go to a new record and insert them from the clipboard (Ctrl-V). Note that this method does not include related records. For example, in the Character editor (CharEdit), only the character definition itself will be copied, but not the associated information about character states.

The elements of a form (navigation buttons, toolbar) are further explained in the following Microsoft Access help topic: Working with data in forms.

Contents of Editing    [image] Main table of contents    [image] Next


Tool bar buttons: inserting new records, deleting records
Tool bar buttons: inserting and deleting records

	Insert New Record: Moves past the last record of the form or table (datasheet) so that you can enter a new record. The function is identical with clicking on the navigation button [image] at the bottom of the window.
	Delete Record: Deletes the selected record or records (see record selector) from the form or table (datasheet). See also delete a record for an alternative method using the keyboard.
Contents of Editing    [image] Main table of contents    [image] Next


 Fields, controls, and pick lists (= combo boxes)

Fields: The fields (often also called controls of a form, or attributes of an entity or table) are usually labeled with a short name, which is also used in the queries. Project name [image] is a field or control. To get more information about an element on the screen, put the mouse cursor above it, and stop moving it for a moment. A little box with yellow background will appear (called ToolTip; in the above example it contains the text: 'Enter the name of the project') and give you some extra information. Also look at the status area at the bottom of the screen where the same or additional information will appear.

The above control is called a combo-box. It is a combination of a text field, where you can edit (see the black vertical line = cursor where you would start to type), and also contains a pick list. The pick list opens when you click on the [image] -button on the right side of the control, or use the F4-key or the Alt-Cursor-Down combination. A pick list contains valid entries for the current purpose. It is often faster, and avoids typing errors to use a pick list instead of typing directly. Also, sometimes you can only enter values which are available in the pick list, because all other values would cause an error (e. g., you can not export a non-existing project name).

A double-click will zoom many controls, e. g., to have more space to read and edit text. Some fields are purposely left quite small, e. g., when notes fields are just large enough so that you can see whether there is any note at all. Editing the text in zoom mode is much more comfortable, because you have a lot of space and use a larger typeface. The same applies to images; here you actually have to zoom to set or delete the image at all. You can adjust the size of both zoomed text and zoomed images.

Buttons with 3 dots ( [image]) will either open the contents of the control next to it, or zoom a linked record, e. g., all items using a certain character state.

Navigating between controls: You can go to any control by simply clicking with the mouse on it. If you prefer using the keyboard, you should use the TAB-key to move from one control to the next control, and Shift-TAB to move backwards. These keys are the preferred method in most Windows program. Do not use the return key, since this works sometimes, but leads to confusing results at other times (see below). You can also use the four cursor arrow keys (left, right, up, down). Yet, because the arrow keys work differently depending on whether you are currently editing a single field or moving around in a form or table, I recommend using TAB to move forward and backward. Use the up and down arrow keys to move between rows in datasheet view.

Contents of Editing    [image] Main table of contents    [image] Next


 Editing and saving

Editing data: If you have moved to a control (= field) which already contains data, the text will be marked (= displayed in reversed colors). Starting to type will delete the marked text. To edit existing data, you must go into the field first, clicking on it a second time with the mouse, or pressing the F2 key. The behavior of Microsoft Access regarding moving between and editing of controls is identical with the behavior of Microsoft Excel in regard to cells.

Editing data within a control: Backspace deletes the character before the cursor, Delete either the marked text, or the character to the right of the cursor. To clear a control completely, select the text contained in the control (tip: since text is automatically selected when you enter a control, the simplest method is to press Tab, Shift-Tab) and hit the Delete key. To clear one line, mark it (use the mouse or press Home, Shift-End) and hit Delete. If you are editing within a text control, you can move faster using Ctrl-right and left arrow keys to move the cursor by word instead of by character. The Insert key will toggle between 'insert mode' (square cursor) and 'overstrike mode' (bar cursor).

Remember that pressing the "return" key is not necessary to enter data into a field. This is an obsolete DOS thing, not valid in most Windows programs. Sometimes this may have unexpected results, since Return might insert a new line into the current field, or it might automatically execute the default button (initially usually the OK button) immediately.

Saving data: In Access you normally do not have to save explicitly after data have been edited. Going to another record, or closing the form, query, or table will automatically save the record. If you nevertheless want to save manually, the simplest method to manually save a record is to select the whole record, i.e. you click on the record selector on the left side. Also note that the Save button ( [image]), which may be present in the tool-bar, does not save the record. Instead, it saves the definition of a form or query.

Contents of Editing    [image] Main table of contents    [image] Next


 Undo operation

To undo changes, select the appropriate menu entry in the Edit menu, or press the Escape key, or click on the Undo-button in the tool bar ( [image]). If you press Escape once, the changes to the current field will be undone, if you press Escape all unsaved changes to the record are undone.

If a form consists of several parts (main form and subforms, like the table in the center of the CharEdit form where you can edit the character states, or the item description) any move between parts will save the record. This can be confusing if you want to undo your changes, because you many not be able to undo as many changes as you would expect. This is a limitation of Microsoft Access that can not be changed by DeltaAccess.

Contents of Editing    [image] Main table of contents    [image] Next


Printing, print preview, page setup
 Printing, print preview, page setup, Zoom

	Immediately starts to print the current form or report with the current default printer. If you are using a network with various printers, use the menu entry File, Print which calls up a dialog box first in which printing options, including the printer can be changed.
	Before printing, it is usually advisable to take a look at a preview of the printout on the screen.
	The following tool bar buttons are available in page preview (e. g., of a report) only:
	Opens the Microsoft Access dialog box to change the page setup for printing. this includes Portrait versus Landscape printing, paper size and margins, number of columns.
	Changes the zoom factor. Clicking on the looking glass button will toggle the view between 100 % and full page preview. You can use the pick list to the right of the button to set different zoom factors.
Close	In the print preview mode of reports, you can click on the button labeled Close to close the preview of the report. This button is available for convenience only; its functionality is identical with clicking on the close button of the window.
Contents of Editing    [image] Main table of contents    [image] Next


 Other tool-bar buttons

	Clicking on this button will invoke the spelling checker. The spelling checker is used by all Microsoft Office programs. It depends on your installation of Microsoft Office, which languages are available. You can change the language using the Options button in the dialog box which appears after the first unknown word has been found. No spelling checker is included in the run-time version of Microsoft Access, but it may be available if other fully licensed office products are installed on your computer. Please refer to the standard Access documentation for more information about spelling.
Contents of Editing    [image] Main table of contents    [image] Next


 Sorting and searching data

(Applies to Tables, Queries, and Forms)

Sorting: For fast sorting in a query or form, select the columns by which the data shall be sorted and click on the sorting buttons in the tool bar. Use [image] for ascending, and [image] for descending order. The resulting sort order becomes part of the filter (see below).

Filtering: If you want to restrict the current list of character or items, you can use a Filter. A filter creates a temporary view of the data. It contains a conditions that defines which records are displayed, and may contain a sorting order. If the character definition or the item definition/description are filtered, a filter can be seen as a temporary item or character subset. Filters are a standard Microsoft Access functionality, some of which is not available in the run-time version. Filtering (tool-bar buttons: , [image], [image]) is explained in more detail in the following chapter Filtering data.

Jumping: If you do not want to restrict your record set, but just want to move to a specific character or item, use the [image] -button in the tool bar or on the form (available in CharEdit, ItemEdit, and EditHeadings) This will call up a dialog box where you can select characters, items, or headings by number or name.

Searching: As an alternative to filtering you can search through your data like you would in a word-processor. For example, this can be useful to find information hidden in the notes. Click on the [image] -button in the tool bar or select Find in the Edit menu. Note that searching is slow compared to other database operations, because it does not use any indices. An option to do a find and replace is available in the Edit menu as well. For a small or intermediate number of records, replace can often be used as a simple alternative to SQL update queries. Note that you can filter your data set first to the relevant records, and use find and replace only on these records.

Contents of Editing    [image] Main table of contents    [image] Next


 Filtering data

(Applies to Tables, Queries, and Forms)

If you want to restrict the current list of character or items, you can use a Filter. A filter creates a temporary view of the data. It contains a conditions that defines which records are displayed, and may contain a sorting order. If the character definition or the item definition/description are filtered, a filter can be seen as a temporary item or character subset. See also Using Identify to search items for an alternative method of creating temporary item subsets. Filters are a standard Microsoft Access functionality, some of which is not available in the run-time version.

AutoFilter: A very fast and simple way of filtering is provided by the AutoFilter function. When you click on the tool-bar button [image] the record set will automatically be restricted to those records which contain the currently selected value in the current field. See also the AutoFilter example.

The button with a red minus in front of the AutoFilter symbol will restrict the record set to those records which do not contains the selected text.

Filter-by-form: Select in the menu: Records, Filter, By Form (or click in the tool-bar on [image]), enter your filter condition, and select Apply filter in the menu (or click in the tool-bar on [image]). You fill your restrictions ("where conditions") into the same fields which you use for data entry. Note that filtering in a subform (e. g., the item description or the character states list) restricts only the records in the subform and has no influence on the main recordset. See also the Filter-by-form example.

Remove filter: Once you have applied a filter, the [image] -button will appear depressed to indicate that a filter is active. The string "(filtered)" is added to the total number of records in the record navigation buttons at the bottom of a form or query. Click on the [image] -button again to remove a previously set filter.

Advanced filtering: From the menu, a further filtering mode (advanced filtering and sorting) is available, which offers the most complete and powerful filtering options. This filtering mode is normally not available through a button in the toolbar. The mode uses the QBE (query by example) editor, compare Using Access query design (QBE editor).

For more information about Microsoft Access filters see the Contents of the Access 97 help file, Finding and sorting data, Finding Data by Using Filters:

Create a filter in a table, query, or form
Modify a filter in a table, query, or form
Apply a filter in a table, query, or form
Remove a filter from a table, query, or form
Delete a filter from a table, query, or form
About using criteria in queries or advanced filters to retrieve certain records
Similarities and differences between select queries and filters

Contents of Editing    [image] Main table of contents    [image] Next


Example for AutoFilter
Example for AutoFilter: An especially simple situation exists if the ItemName contains scientific organism names starting with the genus, and you want to restrict the scope of the ItemEdit form to a particular genus. Jump to the first species of the genus, and select the leading characters of the genus name in the ItemName field. Be sure to leave at least one character unselected, like in the following example:

To restrict the view to those records starting with the selected characters, click on the AutoFilter button: . Note that in the above example might exclude the genus item itself, because it restricts the records to those with the genus name plus a following blank.

See Filtering data for more information on filters.


Example for Filter-by-form
Example for Filter-by-form: To select all items of a certain genus, enter the genus name in the ItemName field and add the wildcard character "*" (= right truncation). If you enter "Par*" you will see all items starting with "Par". You can also even enter "*parmel*" to see all item names containing this string (= instring search). Note the tabs at the bottom: you can add several such conditions combined with OR. Consult your Microsoft Access documentation for further information about filtering (see below).

See Filtering data for more information on filters.


 Using Identify to search items

(Related to Filtering data is the identification of items:)

Identification: Selecting an item based on the data/character states defined for it (= interactive identification, or determination) is possible in the identification dialog Identify. This form is also used when an item subset is defined. The Identify dialog box can also be used to create a temporary subset for editing purposes: After using the evaluate button ( [image]) in Identify to display the list of items remaining, you can click on the button with 3 dots ( [image]) to open these items in the item edit form. You can also manually select certain items in the item list.

Contents of Editing    [image] Main table of contents    [image] Next


 DeltaAccess specific tool-bar buttons

When the DeltaAccess editing forms and dialog boxes are displayed, the following special DeltaAccess buttons are visible in the tool-bar:

	= Open the DeltaAccess Switchboard dialog box. All other DeltaAccess tasks or actions can be started from this central switchboard.
	= Open the main DeltaAccess dialog box for project import, creation, management, analysis and export.
	= Open the Identify dialog box for interactive identification of items.
	= Open the help file DeltaAccess.hlp with the topic related to the currently selected form or control, or with the main table of contents if no context sensitive help is applicable.
See also the chapter General introduction to Access forms which explain basic operations of Microsoft Access forms.

Contents of Editing    [image] Main table of contents    [image] Next


Basic terms and procedures:


Database Explorer
Database explorer: All objects of Microsoft Access are visible in the main window, called database explorer or database window. It works similar to the Windows Explorer used for file management, but has tabs on top where you select the object type. Use the database explorer to directly open tables or queries, or to open existing forms or reports. You open an object by double-clicking on it or clicking the Open-button.

In general, you can access all features of DeltaAccess using the DeltaAccess Switchboard, instead. You would use the database explorer if you want to modify queries or reports, or if you feel comfortably with it because you use it in other Access databases.

See also the following notes.


Database explorer, notes
Database explorer, notes:

1.	The database explorer is not available in the run-time version. Use the DeltaAccess Switchboard, instead.

2.	If you close the database explorer, you close the database. Microsoft Access will remain open without a database.

3.	Most queries accessible in the analysis dialog box of DeltaAccess are not permanently stored. They are created dynamically when you open them. To see a query in the database explorer (tab for query objects), open it and save it under a new name.

4.	The tabs for Macros and Modules are relevant for developers only. No Macros are used by DeltaAccess.

5.	Two Microsoft Access system options (menu: Tools, Options, View-tab) hide certain objects. System Objects hides those starting with MSys and USys, Hidden Objects those which are marked hidden in the object property sheet. In general, unless you are developing your own additions to DeltaAccess, you should leave system and hidden objects invisible.


File selection dialog box
The File selection button calls the standard Windows dialog box to browse through your folders and select a file from a list. Use the pick list on top to change to the drive or network volume where the file is placed. Double-click with the mouse on folders (= 'subdirectories' under DOS) to open them (this is equivalent to the cd-command under DOS), use the Backspace key or click on ( [image]) to return to the parent directory ('cd ..' under DOS). The buttons on top toggle between list view ( [image]) and detail view ( [image], file size and date visible). To adjust the column width to view the file size, etc., move the mouse over the separation line in the column header until it changes to [image] and drag the separation to the side.


Drag and Drop
Drag and Drop: This is used to move objects with the mouse on the screen. Drag refers to the following procedure: place the mouse cursor over the object on the screen (e. g., a file in the Windows Explorer, or a window border or title bar), press the (normally: left) mouse button and keep holding it. When you start moving the mouse the object will follow, i. e. you drag it to the new place. When you have reached the desired location stop holding the mouse button, you drop the object.

Drag and drop is frequently used to copy or move objects, like files in the Windows Explorer. Note that the shift and control keys modify the behavior between copy and move. Simply watch the mouse cursor: a plus indicates a copy action. Another frequent use it to adjust borders like window size, column width, line height, etc.


Deleting records
To delete rows (i. e. the complete record) of a table or a tabular subform (datasheet view):

Using the mouse: Click in the tool-bar on the delete record button ( [image]).

Using the keyboard: Press shift-blank on the keyboard (this is the same key used by MS Excel to select a row on the spreadsheet). The record selector [image] will be displayed inverted, to indicate that the complete record has been selected. Press the delete key to delete the record.


Hiding a column
To hide columns (e. g., to remove them temporarily so that they are not printed) you can adjust the columns width to zero, i. e. you drag the column separation in the header completely to the left side. Use the Format menu, Unhide Columns to redisplay hidden columns.


Adjust column width
To adjust column width use either the context menu of the column or simply the mouse: Move the mouse over the separation line in the column header until it changes to [image] and drag the separation to the side. This works in Microsoft Access just like it does in the Windows Explorer, Microsoft Excel, etc.


Multiple selection in a list box
Selecting several entries in a multiple selection list: Some list boxes allow the selection of several list entries (or lines). They may operate in two different modes: Simple multiple selection and extended multiple selection.


Simple multiple selection
Simple multiple selection list: To select multiple list entries (or lines), simple click on each entry you want to select. To deselect an already selected entry, you can click on it again. Use the spacebar to select entries with the keyboard.


Extended multiple selection
Extended multiple selection list: Select or deselect multiple list entries (or lines) by holding the control-key while clicking with the mouse on it. To select a continuous range of entries, select the first entry of the range, hold the shift-key and select the last item of the range. The extended multiple selection mode is used frequently in Windows applications, e. g., in the Windows Explorer to select files.


Contents of Editing    [image] Main table of contents    [image] Next


Contents of Editing    [image] Main table of contents


 Editing the item definition (ItemEdit-form)

(If you have not done so already, please read the previous section General introduction to Access forms first. If you are creating a new descriptor project you must have already defined characters before you can use the item edit form!)

This section is still incomplete!

(This is a hypergraphic)

The item identifier attribute (IID) is a positive integer number, which uniquely identifies a character. When you add a new record it will be preset to the next available number. You can change the number at any time, as long as the new number is not used by another item record. The default sequence of items is determined by this number. You can change the IID number directly to change this sequence. The Reorganize project definition dialog box, however, provides more comfortable means to changes the item sequence, including a function to sort all items by their item name.

The ItemName should be the main name for your item, usually the scientific name. Taxonomic authors of the item name should be entered directly after the item name, without any comment markers ('<'/'>'). The full taxonomic name, including authors and perhaps subspecific ranks provides a link to a future taxonomic subsystem. Only after this link has been implemented, will it be possible to format names in italic, authors and rank identifiers ('ssp.', 'var.', etc.) non-italic.

The search record button ( [image]) to the right of the item name allows you to jump directly to a new item. A dialog box allows you to select another item to jump to, either by item number (IID) or by item name. Note that using the search button is not identical with selecting a name from the drop-down pick list ( [image]): Selecting from the pick list will edit the current record, not go to the first record with the selected name!

An alternative way to get an overview of items is to change the form view to tabular. You can position the cursor on a new item and change back to form view to edit that item. To print a list of items use the item list reports in the analysis section.

Comments, which differentiate multiple entries of the same taxon, like literature references or reference to collection specimen units, should be entered into the respective fields. Further comments can be put into the Notes field provided. Do not enter any text into ItemName which would not appear there in a taxonomic database as well.

The Abundance of an item is relevant only in the generation of printed keys (e. g., with Confor, Pankey, or TAXASOFT), or during interactive identification with the Identify dialog box in DeltaAccess, M. Dallwitz's Intkey, or other programs supporting DELTA. Items with a higher abundance will be preferred in key construction, so that items frequently encountered have a shorter identification path.

Below these general fields you see the data entered for each item. You have two options how to view them: By-character and All, see the following chapters Item description editor: By character view and Item description editor: All character view.

For information about the buttons above the item description subform see the following sections Preset Data and CS sequence.

Related topics: Entering fractional/exponential values.

As noted previously, the item editing form has not been the main goal of the descriptor project. It should therefore been regarded only as a first attempt at producing a DELTA editor. The following is a summary of known shortcomings of the current ItemEdit form:

•	Relatively slow

•	No warnings are issued about missing mandatory characters in by-character view

•	MultistateType = Exclusive is not enforced

•	Inapplicable characters are not hidden in by-character view

•	The designation of inapplicable characters in by-character view is not revised during data entry. To force a reevaluation of inapplicable characters, you have to go to the next item, and go back to the current one.

Contents of Editing    [image] Main table of contents    [image] Next


Presetting item descriptions data

Use the button labeled Preset of the Item editor to copy item description data from an existing item into the current item. Usually you do this immediately after you have created a new item, which is similar to an existing item. You are asked for the name or number of the existing item, and the complete description of the existing item is copied into the current one. You can then edit the copied description.

Using this button can be a big time saver. If you have previously edited DELTA files in a text editor, you have probably done a similar thing by copying similar entries and then changing them. You may have had a special "dummy" item filled with default values for the whole data set. The preset option is currently even more important, because DeltaAccess does not support the +-option (which defines a carry-over of data from the previous item in DELTA).

See also Overview over methods to copy information for a comparison of available copy methods.


Changing the sequence of states in item description

If you click on the button labeled CS sequence, the arrow buttons to manipulate the sequence of character states will be turned on. With these buttons you can change the sequence in which the character states are output, e. g., so that state 3 is output before state 1.


[*** Not yet implemented; attributes are present in data model and item tables, but hidden in forms: The following attributes exceed the current DELTA standard, but I consider them vital. Any item should be clearly labeled as to which source the data are derived from. If you study a specimen in a collection, you should enter the collection unit code (which may not be a code, but just the collection acronym plus the taxon name the specimen is filed under) in the CollUnit attribute. If you evaluate an item in the literature, you should similarly clearly enter the data for each reference separately, and link each item with the reference using the LitRef attribute. If you are evaluating additional information, like existing card indexes, laboratory books, etc., I suggest treating them like an unpublished literature reference. Currently both source attributes are simple text fields, compare the chapter about database subsystem links.

If you follow these guidelines you can always find the source of confusing or ambiguous information, esp. if several people are cooperating on a project. The current way most DELTA data sets are build is very much like publishing a review article without quoting the sources of information. DeltaAccess offers a Summarize Items command that combines all available information for a name and generates consensus items. Unfortunately, since DELTA has no provisions for linking information, these attributes will be exported as comments after the item name, and can not be parsed back during import.

LitRef: Special notes on Literature References (perhaps rename to SrcRef?): This should include URL references (add the date when the URL was last visited and you verified that the information referred to was still there). You can optionally set a bookmark as reference detail. Similarly, database references, e.g. for DNA sequences stored in GenBank, should be quoted with the name of the database as the reference, and the accession number as reference detail.

CollUnit: Mainly thought to refer to a collection unit already in a separate database subsystem, but can also textually refer to a certain collection, and if possible to an accession or collection number. Please try to verify what kind of number you are referring to, sometimes 100s of specimens have the same number (if the number is a batch number). It is therefore wise, to store the scientific name under which the unit is currently stored in this attribute, even if this name is not the name you would accept. The latter would be the name stored under item name.

***]


 Item description editor: By character view

(Set the view using the View option labeled All in the ItemEdit form.)

In the By-character view mode you see a list-box containing all characters on the left side, and the item description data for this character on the right side. If you click on the labels above the character list, the list will be sorted by that column. If you click on the [image] -button you can open the full character definition of the selected character in the Character Editor form.

The list of characters includes inapplicable characters, which are marked in the 3rd column (marker column). Currently no warning is issued if a dependent character is already set and then becomes inapplicable because a controlling character states is set.

The pick list for the character states on the right side contains the number of the state, an "*" if the state is implicit, and the name or description of the state. States already set for an item are excluded the next time from the pick list.

Contents of Editing    [image] Main table of contents    [image] Next


Item description editor: Character marker column
Marker column: The 3rd column of the character list in By character view contains the following information:

!	An exclamation mark indicates that the character is mandatory, i.e. it must be set in all items

A cross-out symbol indicates that the character is inapplicable, based on the setting of other characters

A bullet is shown in all characters which have been recorded for the current item

Note that a combination of mandatory and inapplicable may occur, if in the character definition mandatory was considered as mandatory if applicable.


 Item description editor: All character view

(Set the view using the View option labeled All in the ItemEdit form.)

In the All view mode, you see all attributes at once, regardless of their character type. The restrictions apply nevertheless, you can use the X field only for numeric and the TXT field only for text characters. This view is less comfortable, but good for a quick overview about which data are present. Similar to the By character view, you can open a character definition editor (CharEdit) by clicking on the on the [image] -button above the CID pick list in the table. The other [image] -buttons will zoom the text of the attribute below.

Contents of Editing    [image] Main table of contents    [image] Next


 Editing multiple items simultaneously (MultiItemEdit-form)

In classical DELTA software applications information is processed item by item. This is appropriate if the information you evaluate is organized in the same way. You can use the ItemEdit-form to do this in DeltaAccess.

However, it frequently happens that data are organized by character. For example, you may have tabulated information of secondary metabolites, or literature references you want to enter into your database. The MultiItemEdit form described here helps to enter information regarding a single character into multiple items in a single step. You can open the MultiItemEdit form from the Switchboard or by opening the form DescrMultiItemEdit directly in the database explorer.

MultiItemEdit also allows to insert "default values" for certain groups (e. g., all species of a genus; compare implicit character states for global implicit values). You may have done a similar thing when you used search-and-replace in a text editor operating on DELTA text files to perform certain changes.

Initially, you will often be faster using the MultiItemEdit form mode to fill up your data set. You can easily set global defaults, which you can later modify in a revision process (where the ItemEdit-form is usually more suitable). Note that you can call the ItemEdit-form for the selected items using the button in the lower right corner of the form.

(This is a hypergraphic)

Character Selection

You can select a character either by number or by name. At any point in the form you can press Ctrl-PageDown to go to the next character, or Ctrl-PageUp to go to the previous character. Depending on the type of the selected character you get one of the following options:

Categorical characters: You can select one or several character states to insert. If you select a single state, you have the additional option to insert a Modifier phrase and Notes as well. The latter will be disabled if you select several states. If you want to add multiple states, but also modifiers and Notes, you can insert the states in several steps.

Numerical characters: You can select a special states (U/V/-) or a numerical attribute. In the latter case you must add a value (field "X") for the numerical attribute selected, which is only available if you have selected but a single numerical attribute. The possible multiple selection is thus useful only to delete item descriptions of numerical characters.

Text characters: You can add text and notes.

Item Selection

You can select multiple items simple by clicking on them. On the right side of the item list additional tools to select items are available. The first group of 3 buttons provides general functions to select, deselect, or reverse the current selection.

The second group of buttons uses criteria for item selection. The two buttons Used items and Unused items refer to the character state currently selected on the left side (this can be a different state then the one you finally want to insert!). They can be used for quick analysis of items where one or several character states are present or absent. A typical use of the Used items button is that you have a printed list of items where a certain property has been found. You select the character states for this property on the left side and click on the Used items button to select all items for which the occurrence of the property is already stored in the database. You can now compare the selected items with your printed list and make the necessary additions and perhaps even deletions. (Note: If you select multiple states on the left side, all items where any of these states is present will be selected, not only those items where all these states are present.)

The Identify... button opens the Identify dialog box for the selection of items based on complex criteria. Use the Identify dialog box to define the group of items in question. After you click the Evaluate button in Identify, you get a list of remaining items. If you close the Identify dialog box, the items in this list will also be selected in the Multi-ItemEdit dialog box.

The Cumulative-Checkbox below these buttons defines whether the item list is cleared before Used, Unused, or Identify are executed, or whether the results are added to the items already selected.

Insert button: The selected states, or the numerical value together with the numerical attribute, or the text and note information is inserted into the item descriptions of the items selected on the right side. If several character states have been selected, they are inserted as if they would have been inserted in several steps.

Delete button: Item descriptions containing a selected character states, including any additional information such as modifiers or notes, are removed from the items selected on the right side. If several character states have been selected, they are delete as if they would have been deleted in several steps.

Only the character states information (or even only the character itself for text characters) is used during delete (and also during selection of Used/Unused items using the buttons on the right side). That is, any information present in the additional controls Modifier, Notes, TXT (for characters of type text), or X (for numerical characters) is ignored. A warning is issued if any such information is present.

(Please note that whereas the Insert Button works with linked or subset projects as well as with base projects, the delete button may or may not work with linked subset projects. This seems to be due to a bug in Access, since the problem occurs only in code, not when doing the deletion manually.)

The Multi-ItemEdit form is also useful in the creation of calculated characters, see the following chapter.

Shortcomings: It is not possible to automatically add notes to numerical characters during insert. There is no test for inapplicable characters, i. e you are allowed to insert states into items, where the character should not be applicable.

Note that although this form is fully functional, the item selection list box may be very slow in large projects. It may, e. g., take a full minute to select 800 items. I did some testing and decided that this is a Microsoft Access bug, which hopefully will be removed in a future version. The error is entirely due to user interface operations beyond my control; no database operations are involved! Such a slow operation is certainly bothersome for some larger projects. Nevertheless, I hope that using the dialog box will still be faster than inserting the data manually...

Contents of Editing    [image] Main table of contents    [image] ItemEdit-form    [image] Next


 Calculated characters (= compound features)

You can use the Multi-ItemEdit dialog box to set a character based on other characters. This is mostly useful for analysis purposes. If you want to create a crosstab between an compound feature of your organisms and other characters, you could calculate the compound character. For instance, you might want to analyze a xeric life habit of your organisms, which you deduce from the presence of absence of several characters you have actually observed.

To create calculated characters, follow these steps:

•	Using the CharEdit-form, create a new character and the character states you want to use in your analysis. Usually it will be useful to include special states (U/V/-/TE) as well. To avoid confusion with real characters, you could give such analysis characters a very high number (CID), e. g. 1000.

•	(If you have already previously used such a character and want to update your calculation now, you should use Multi-ItemEdit to select all character states of your calculated character, select all items, and click the delete button to remove all previously calculated item descriptions.)

•	Use the Multi-ItemEdit dialog box to select the items for each of your calculated character states:

•	If your calculated character is defined as the intersection set:  of the items defined through each character, you can click the Identify button, to make a complex selection of items using the Identify dialog box. Identify allows you to combine several characters with the AND operator. Character states are combined with the OR operator if they are selected in the multiple selection character state list during a single step (one entry in the list of identification steps) and combined with the AND operator if they are added separately (two entries in the list of identification steps). Example: Character 20, states 2 or 3 AND character 21, state 1 define a xeric life habit when they occur together. You would: Click the Identify button, select character 20, click both on state 2 and 3 to make a multiple selection, click Present. Select character 21, click on state 1 and click Present again. Click Evaluate and click Close to close the Identify dialog box.

•	If your calculated character is defined as the union set:  of the items defined through each character, you can use the buttons Used/Unused or Identify several times while the Cumulative-Checkbox below the buttons on the right side is set. Now the selected items from several selection processes add up. The result is the equivalent of the characters combined with the OR operator. Example: Any of the following conditions is an indicator of xeric life habit: Character 10, states 2, 3, or 4, OR character 11, state 1, OR character 20, states 2 or 3 when occurring together with character 21, state 1. You would: Check the cumulative checkbox, perhaps click Deselect all items to reset the item list. Choose character 10 on in the MultiItemEdit form, make a multiple selection of the 3 states, click on the Used-button. Repeat this for character 11,1. Click the Identify button and continue with the example above.

•	Make sure that the appropriate state of the calculated character is selected on the left side. Click on the Insert button to insert this state into all selected items.

•	If your last state of the calculated character shall be the complement of the other states (e. g. presence/absence), you can select the appropriate set of items with the Used button while all other states of the calculated character are selected on the left side. Then click on the Complement-button to invert the list of selected items, select the final state on the left side, and insert it into the selected remaining items.

You should consider dealing with unknown states separately, before adding the last character state as the complement of the previous states. Whether you want to define your calculated character as unknown if a single character, upon which it is based, is unknown, or only if all base characters are unknown or variable, is your decision.

Contents of Editing    [image] Main table of contents    [image] Multi-ItemEdit    [image] Data analysis    [image] Next


 Editing the character definition (CharEdit-form)

(If you have not done so already, please read the previous section General introduction to Access forms first.)

Starting with DeltaAccess version 1.6, a new experimental character editor is provided in addition to the old editor. It is planned that this editor will replace the previous editor in future versions of DeltaAccess. In the current version most tab pages of the new editor contain exactly the controls in the old character editor shown below. Only the character dependency and modifier association have already been reworked and are described in detail if you follow the respective links.

(This is a hypergraphic)

The attribute CID (character identifier) is a positive integer number, which uniquely identifies a character. When you add a new record, the CID field will be preset to the next available number as soon as you start entering, e. g., the character name. You can edit the CID number at any time. To swap characters 1 and 2, you can change character 1 to 999 (or any number not yet used), character 2 to 1, and character 999 (= previously 1) to 2. The database engine will automatically update all item data to the new character numbers! A more convenient way to do this is supplied in the Reorganize project definition dialog box, which is accessible from the navigation pick-list below the character states table.

The Character name is a unique identifier for each character. Note that this is a new concept for DELTA, it did exist so far. In general the character name should be chosen such that it is useful and legible for entering data or interactive identification. In contrast to other DELTA tools, you do not have to consider natural language output at this point, compare the attribute CharPhrase.

The search record button ( [image]) to the right of the character name allows you to jump directly to a new character. A dialog box opens where you can jump to another character by selecting a character number (CID) or a character name.

Notes contains remarks/comments for the character in general. Whether you use it for internal purposes or for output purposes depends upon you.

The following attributes define basic properties of the character as a whole: Click on the link to see detailed explanations:

Type: See character types.
MultiStateType: See character multistate types.
Unit: See measurement units.
Mandatory: See mandatory characters.

Under this line of primary character definition attributes, a set of radio buttons allows to select different views for the tabular subform below. The options are: character states, character images, or character modifiers.

Character states

Each character state consists of the character state identifier (label: "CS#"), character state name, Notes and a checkbox indicating whether the character state shall be assumed to be implicit.

The character state identifier (or "code") should be numeric for any state you want to define. Possible non-numeric entries are the predefined special states (U/V/-/TE) and the identifiers ('Min', 'Mean', 'Max', etc.) for the various numerical statistic attributes used for character type IN or RN. Further, you can define combined character states here, like '1&2' (e. g. for 'red with white dots'), or '3-4' (e. g. for 'between white and yellow', as opposed to 'white to yellow', which would include both white and yellow). Such combined states are already created in the import process where necessary. The character states the combination consists of must be defined separately as well, since the export to DELTA will skip the combined states.

The character state name should be text starting in lower case letters, and make sense when read together with the CharPhrase as a natural language phrase.

)A pick list in the column header allows you to automatically add certain standard character states (e. g. presence/absence, U/V/-/TE). Select the desired option from the pick list and the appropriate character states will be added. If you only want U and -, but not V, you can simply delete the V-character state afterwards. Always delete the full record (=row), not only the CS-attribute of the row.

You can enter any further internal comments or remarks into the Notes attribute. Double-click on it to read or edit the text in a larger editing box.

When the implicit checkbox is checked, the character state is assumed to be the default state for each item where no other state (including a special state U/V/-/TE) has been scored. See also: Implicit (attribute of character state definition).

Do not ignore the warning message when you delete character states: If it mentions "... and further records from linked tables", you have already used this character state in your data. Deleting the state will also delete all item data using this state. The state will be removed from any item where it has been scored. Other states of the same character will not be affected. Deleting states can be dangerous, but also useful: For example, to remove all U codes, you can delete the character state and all occurrences of U for this character. You can check which items have used the current character state using the navigation pick-list below the character state table.

Character images

(Character images are not fully implemented or tested in the current version. Some functionality is present, but use it at you own risk...)

For categorical characters you often want to add illustrations which are specific to a certain character state. DeltaAccess supports linking an illustration to a character state, but not that this information is lost when the data are exported to a DELTA coded text file. For numeric characters you could add an illustration of the way some measurement should be taken. Illustrations relevant to text characters will probably be rare, but can be attached nevertheless.

DeltaAccess only stores references to illustrations, not the illustrations themselves. Resource should be filled with the file name of the illustration. If possible use a project wide default pathname and enter only the filename into Resource.

Character modifiers

In the modifiers subform you only define the association between modifiers and characters. Think of the process as enabling a modifier for the current character. Only the modifiers you add here are available for this character during data entry. You can add groups of characters by using the pick list at the top of the subform. It is usually faster to insert a whole group and then delete those which you think should not used, than adding each modifier separately.

The modifiers must have previously been defined. During the creation of a new descriptor project, DeltaAccess creates a default set of modifiers, which will be available to all characters. To add or remove project wide modifiers, set the navigation pick-list to Edit modifier definition and click on the Open button to the left of the pick-list.

The concept of modifiers is further explained in a separate chapter, see Introduction to the concept of modifiers in the appendix.

Inapplicable Characters: For categorical (UM/OM) characters a list to define inapplicable (= dependent) character states is displayed in the lower right corner of the form. This list always refers to the currently selected character state and is therefore visible only when the character states are visible.

Defining a character inapplicable for a certain character state is very useful to reduce the complexity of the character set. Imagine that you have a diverse group of plants in you item set, some of which have leaves, while others don't. You can now use the inapplicable mechanism to define all characters which describe properties of leaves as inapplicable for the character state: absent of the character: presence of leaves.

The Inapplicable Characters list allows you to add each character only once. You only see the character numbers directly, but if you open the pick list the names are visible as well. Note that while Confor recognizes a hierarchy of inapplicable characters (i. e. if you make a character inapplicable, those characters dependent on states of the inapplicable character are automatically made inapplicable as well), you must enter each character directly in DeltaAccess.

DeltaAccess does not support the applicable directive which in standard DELTA is an alternative to the inapplicable directive. During import, applicable characters are converted to their complement of inapplicable-characters.

For the KeyStates attribute, see the chapter Mapping character states.

(This is a hypergraphic)

The following attributes define formatting properties of the character. They are relevant mostly for Natural language descriptions. Click on the link to see detailed explanations:

CharPhrase,
FormatString (directive: Decimal places),
LinkGroup (directive: Link characters),
NewParagraph,
SemicolonToComma,
OmitFinalComma, and
OmitValues.

Contents of Editing    [image] Main table of contents    [image] Next


 Character definition editor: Character dependency tab page

On this tab page of the EditCharacters form the definitions for character dependency can be changed. See chapter *** for an introduction to character dependency.

Defining a character as inapplicable in all items where another state has been scored is very useful to reduce the complexity of the character set. Imagine that you have a diverse group of plants in your item set, some of which have leaves, while others don't. You can now use the inapplicable mechanism to define all characters which describe properties of leaves as inapplicable for the character state: absent of the character: presence of leaves.

Note that while Confor recognizes a hierarchy of inapplicable characters (i. e. if you make a character inapplicable, those characters dependent on states of the inapplicable character are automatically made inapplicable as well), you must enter each character directly in DeltaAccess.

DeltaAccess does not support the applicable directive which in standard DELTA is an alternative to the inapplicable directive. During import, applicable characters are converted to their complement of inapplicable-characters.

Inapplicable Characters: For categorical (UM/OM) characters a list of the current character states (special states: U/V/-/TE are excluded) is displayed on the left side. The list contains the state code, name, and the number of inapplicable characters already defined in square brackets.

For each controlling character state one or several characters can be defined as inapplicable or dependent. These characters are displayed on the right side of the form. This list always refers to the currently selected character state. You can use the following buttons to change the list of inapplicable characters:

Add character to list: If you click this button a dialog box opens that contains all characters that have not yet been defined as inapplicable for the current controlling state. You can select one or several characters and click OK to add them to the list. (A selection of characters in the list on the right hand side of the dialog box does not influence the behavior of this button.)

Remove selected character(s) from list: You can select one or several characters in the list of inapplicable characters and click on this button to remove them from the list.

Report button: The action of this button is always the same, regardless with character is currently visible in the editor. A character dependency report for the entire project is created. You are asked, whether you want to see the report sorted by controlling or by inapplicable/controlled character.

Character editor    [image] Contents of Editing    [image] Main table of contents    [image] Next


*** New Character Editor only: At any point in the form you can press Ctrl-PageDown to go to the next character, or Ctrl-PageUp to go to the previous character. ***


Navigating from the character editor (CharEdit)
 Character definition editor: Modifier association tab page

On this tab page of the EditCharacters form the association between modifiers and characters can be edited. This association defines which modifiers are available for a given current character. Only the modifiers listed for this character are available during data entry of item descriptions. Modifiers can not be defined for text characters.

Introducing restrictions on which modifiers can be used for a character avoids the display of modifiers not applicable to the character in question (color modifiers like "dark" for shape, location modifiers like "at the tip" for colors), and it guides the use to avoid using multiple synonymous (or almost synonymous) modifiers like "usually"/"generally", "almost always"/"with few exceptions". The definition of appropriate modifiers is therefore an important part of the character definition.

To simplify the process of selecting modifiers, you can add predefined groups of modifiers by using the pick list at the top of the modifier list labeled "enable entire usage category". It is usually faster to insert a whole modifier group and delete unwanted modifiers than adding each modifier separately.

Add modifier to list: If you click this button a dialog box opens in which you can select a modifier to be added. [***This is a preliminary implementation, which will later be replaced by a list that allows to select multiple modifiers in a single operation.]

Remove selected modifier(s) from list: You can select one or several modifiers in the list and click on this button to remove them from the list.

The modifiers must have previously been defined. During the creation of a new descriptor project, DeltaAccess creates a default set of modifiers, which will be available for all characters. To add or remove project wide modifiers, set the navigation pick-list to Edit modifier definition and click on the Open button to the left of the pick-list.

The concept of modifiers is further explained in a separate chapter, see Introduction to the concept of modifiers in the appendix.

Character editor    [image] Contents of Editing    [image] Main table of contents    [image] Next


 Navigating from the character editor (CharEdit)

At the bottom of the character states, resources, or modifiers list, a combination of a button labeled "Open:" and a pick-list of possible actions is available. This tool is used to navigate from editing characters (CharEdit form) to other dialog boxes.

Available options are: Open...

All item records using the current character	Opens the ItemEdit form
All item records using the current character/char.-state	Like above, but only items which contain the currently selected character state are displayed
Reorganize character sequence	Opens the Reorganize characters dialog box
Reorganize (copy, move, join) character states	Opens the Reorganize character states dialog box with the current character state
MultiItemEdit: insert/delete current char. in multiple items	Opens the MultiItemEdit form
Edit Headings	Edit definition of character headings, item subheadings; this is identical with a double-click on one of the heading attributes displayed in the lower part of the form, see Edit character headings
Edit character link groups	Identical with a double-click on the LinkGroup attribute displayed in the lower part of the form, see Edit link groups
Edit modifier definition	All characters of a project use a common set, which can be edited here. The modifier list that can be displayed in the table above only defines the associations of the modifiers defined here with a character. The concept of modifiers is further explained in a separate chapter, see Introduction to the concept of modifiers in the appendix.
Edit project properties	Opens DescrEditProperties to edit project wide properties like comments, import warnings, or project authors, copyright, and title.
Character editor    [image] Contents of Editing    [image] Main table of contents    [image] Next


Overview of uses of character headings
 Overview over uses of character headings

A character definition heading defines a group of characters. Headings are used for several purposes in DeltaAccess:

Character headings are used when the character definition is printed for reference purposes. Used in the Character definition report and when other programs, e. g., Confor, use data exported from DeltaAccess. See also the character definition attribute CharHeading.

Item subheadings are used when the item descriptions are output, e. g., during the generation of natural language descriptions. [*** Not yet used in the natural language output of this version of DeltaAccess, but used when, e. g., Confor is used on data exported from DeltaAccess.] See also the character definition attribute ItemSubheading.

Named character groups are mainly used during interactive identification. They define a group of characters, which can be selected by the user instead of selecting single characters directly. For example, it is better to ask whether on wants to answer questions about "leaf characters", or "flower characters", or "fruit characters", than to ask directly for all characters which might be in these named groups.

Import from DELTA: Named character groups may be imported from the Define Characters directive (usually found in the intkey.ini file if you have prepared an IntKey distribution). If an imported file contains a Character heading, but no Define characters directive, the character headings are also used as character groups and will be exported in a Define characters directive.

Confor allows recursive definitions in the Character definitions directive, i.e. one definition can be based on other already defined group names instead of character IDs. Recursive definitions are currently not supported by DeltaAccess. At the moment you would have to change the recursive definitions by manually replacing the names with the appropriate character IDs to import these groups as well.

See Editing character headings for more information.

Contents of Editing    [image] Main table of contents    [image] Next


Editing character headings (incl. Item Subhead., Char. definitions for Identify)
 Editing character headings (incl. item subheadings, char. definitions for Identify)

This special dialog box allows to edit several types of character headings (compare Overview of uses of character headings). You can open it from the Switchboard, from the navigation pick-list in the CharEdit form, or by opening the form DescrEditHeadings directly in the database explorer.

At the top of the form you can change the editing mode of the form. Changing the setting to LinkGroup allows to edit the low level association of characters into link groups, see Edit Link Groups.

The upper part of the form allows to edit the headings themselves. The HeadingName attribute is the primary heading name used. It is preferred for use as character heading and named character group during identification. The HeadingPhrase, if present, is preferred for natural language output of item subheadings. The HID attribute defines a unique number for each heading. The association of characters with headings are stored using this number. The only reason why you might want to change this number is that the sequence of named character groups is based on HID. Changing HIDs will alter the sequence of named character groups in identification. A more comfortable way to change the sequence of headings is provided in the Reorganize project definition dialog box. For additional information on the information model used for character headings see CHAR_Heading.

The lower part of the form (character association list) defines, which characters belong to the current heading. To associate a heading with a character, click on the appropriate checkbox for character heading, item subheading, or named character group. Whenever you click on a checkbox with the mouse or press the spacebar while it is active, the setting will be reversed. For technical reasons of the implementation, the table must be updated each time. The character which you have edited last will remain the current one, but it will be repositioned as the first visible row of the table. Use the scrollbars to see other characters.

When you move in the form to the next heading record (e. g., using the Navigation buttons [image] at the bottom of the window), the character association list will be positioned to the first character where this heading has been used as character heading, item subheading, or named character group. If a heading has not been associated with any character, the last character will be displayed.

Note that you can have only one character heading and item subheading for each character, but several named character groups. For example, if you check the character heading and the named character group checkboxes in the first heading for character 1, go to the next heading and check both checkboxes again for character 1, the named character group will be added, but the character heading association will be replaced. If you go back to the first heading, only the named character group checkbox will still be checked in character 1.

Deleting character headings: In versions of DeltaAccess before 1.6, cascades deletes were active between headings and characters. Deleting a character heading that was used as a CharHeading or ItemSubheading in the character definition would thus cause the deletion of all related character records, which in turn would delete all related character states and item descriptions for these characters. Since this behavior is unintuitive and dangerous, it has been changed. In tables or queries, headings that are not used as CharHeading or ItemSubheading you can no longer longer be deleted directly. To delete such a heading you must use the Character Heading Editor or the Reorganize form, where the links to the Char table (CharHeading, ItemSubheading) are now automatically removed before the heading is deleted. Note that one problem remains in the current implementation: If you try to delete a heading (e.g. using the toolbar button for delete record), but then decide to cancel the deletion, the heading will not be deleted, but the links to CharHeading/ItemSubheading (= active checkboxes) will be lost. In this case you must manually restore the previous situation by clicking on the checkboxes again.

Contents of Editing    [image] Main table of contents    [image] Next


 Editing link groups

The link group editor is part of the dialog box that also allows to edit character headings. Setting the view option on top of the form DescrEditHeadings to LinkGroup will start this editing mode. The form DescrEditHeadings can be opened from the Switchboard (task Edit character headings) or from the database explorer.

A character link group is defined as a set of characters, which are closely related and usually described in a single sentence. It is used in natural language item descriptions and in the HTML form generation. The settings of the attribute LinkGroup are imported from and exported to the DELTA directive Link characters.

A positive integer number identifies each link group in DeltaAccess. All characters with the same link group number belong to the same link group. Characters without a number in the LinkGroup attribute belong to no link group. The link groups are visualized by colored vertical bars in front of the LinkGroup numbers.

In the example, character 44 belongs to no link group, 45-47, and 52-54 belong to one, and 48-51 to another link group. If any character between 48-51 is present in an item, the item description will look like as if characters 52-54 belong to a third link group. Only if all characters between 48-51 are missing, will the disjunct parts truly form a single link group.

The fastest method to edit link groups is provided by the buttons at the bottom of the form. Next (Shortcut: Alt-N) and Previous (Shortcut: Alt-N) simple move to the next or previous character, respectively. Start new LinkGroup (Shortcut: Alt-S) will insert a number which has not been used for any other link group so far in the base character definition. Join with previous (Shortcut: Alt-J) joins the current character with the nearest link group above. If several characters are in between the current character and the nearest which is already assigned to a link group, these characters remain unchanged. See the discussion about gaps in link groups above. Disjoin (Shortcut: Alt-D) removing the current character from a link group (i.e. the LinkGroup attribute is cleared).

After pressing a button to start, join, or remove, the cursor automatically moves to the next character. Thus, using the keyboard shortcuts, you can quickly move through a character definition and edit the link groups.

In addition to editing the LinkGroup attribute, two related attributes that govern natural language output are available in this form as well:

New Paragraph defines that in front of the current character a new paragraph is started in natural language output. The settings are imported from/exported to DELTA directive New paragraph at character.

Semicolon to comma defines that the characters in the current link groups are to be separated by a comma (',') instead of the usual semicolon (';'). The settings are imported from/exported to DELTA directive Replace semicolon by comma.

Contents of Editing    [image] Main table of contents    [image] Next


 Jump to a Character or Item

When editing items, characters, or headings, using the ItemEdit, CharEdit, or HeadingEdit forms, respectively, you can jump to a specific record using the search record button ( [image]) to the right of the item, character, or heading name. The button is also sometimes available in the tool-bar on the top of the screen. It opens a dialog box, which for characters would look like the following:

You can type a number, or a name, or pick a number or name from one of the lists. If you start typing a name, the name list will automatically position itself and select the first appropriate entry in the list (see illustration). You can double-click on a list value to select it and close the form.

Note 1: You can change a form to datasheet view mode using the [image] -button in the tool-bar. This will give you an overview of all characters or items, in which you can go to a certain character or item, and then switch back to form view ( [image]). See Form views for further details.

Note 2: The numbers and names in one line do not correspond. Both lists are independently sorted. The selected character in the example above has the CID number 13, not 9.

Note 3: Item names are not required to be unique. If two items have the same name, selecting one of these items by name will result in the first IID to be selected. This might be confusing, but it is unavoidable. No problem arises during the selection of characters or headings, since these names must be unique.

Alternatives: When editing a well defined subgroup in a large descriptor project with many items, it may be faster to create a record set containing only the records in question. Several methods are possible. If you want to retrieve the same set of records many times, you would best create an item subset project. To create temporary subsets based on simple conditions, see the AutoFilter example. and the chapter Filtering data. If the conditions for a temporary item subset are more complex, see Using Identify to search items.

CharEdit-form    [image] ItemEdit-form    [image] HeadingEdit-form    [image] Contents of Editing    [image] Main table of contents    [image] Next


Reorganize definition (characters, states, headings, or items)
 Reorganize project definition (characters, states, headings, or items)

You can open the Reorganize project definition form from the Switchboard, from the navigation pick-list in the CharEdit form, or by opening the form DescrReorganize directly in the database explorer.

This dialog box allows to edit certain aspects of the character or item definition, which are difficult to edit in the CharEdit and ItemEdit forms because they may operate on multiple characters at once. The dialog has several tab pages:

  Reorganize Characters
  Reorganize Headings (see Reorganize Characters for explanations)
  Reorganize Items (see Reorganize characters above for explanations)
  Reorganize character states
  Reorganize descriptions

If the dialog box is opened with a subset project a special mode is entered, see the chapter Reorganize subsets.

CharEdit-form    [image] Contents of Editing    [image] Main table of contents    [image] Next


 Reorganize characters, character headings, and items

The tab pages for characters, character headings, and items of the Reorganize project definition form offer identical functionality and are therefore discussed together. On these tab pages you can change the sequence of the definitions, insert a new definition between existing ones, delete or copy a definition. Special options and restrictions apply to linked and subset projects, please refer to the chapter Reorganize subsets.

(This is a hypergraphic)

On the left side you can select one or several characters, headings, or items on which the action buttons on the right side of the dialog box operate. Buttons to select all, deselect all, or reverse the selection (complement) are provided at the bottom of the form. The following action buttons are available:

Insert above button: Insert a new character, heading, or item above the first one selected on the left side. You will be asked to provide a name for the new character, heading, or item. You can also add new characters, headings, or items in the respective editors (CharEdit, HeadingEdit, or ItemEdit), but only after the last existing record. Using the insert above button avoids having to move the new entries to the desired location.

Delete button: Delete the selected characters, headings, or items. If you delete a character, the associated character states, and all item descriptions using this character are deleted as well. If you delete an item, the item descriptions and associated resources are deleted as well. You can not undo this operation once you have confirmed it!

Copy to project button: Copy the selected characters, headings, or items to a second descriptor project. By default the destination project is identical with the currently edited source project, but you can select a different in the pick list below the button. If the ID number of the source definition already exists in the destination project, the definition is inserted under a new ID number. In the case of characters and headings, a random number will be appended to the name if another character or heading with the same name already exists in the destination project (these names are required to be unique). In the case of characters the character states are copied as well, whereas in the case of items and headings only the definition is copied.

By checking the checkbox with item description below the copy button, you can copy the associated item descriptions together with the definition. See Copying items or characters, with or without item description for a visualization of the copy options in the Reorganize form, and Overview over methods to copy information for a tabular comparison of all available methods.

 Move buttons: The selected characters, headings, or items are moved relative to the deselected ones. In a control under the buttons you can determine how many steps the selection is moved in a single operation. Each Move-step is relatively slow, so selecting steps greater than 1 saves time, if you want to move the selection many steps down. To enter a positive integer number, use the keyboard, pick list, or spin controls (buttons with up and down symbols). See also In depth information about sequence changes.

Auto-Resequence: After the deletion of characters, headings, or items, the sequence of ID numbers (CID, HID, IID) will be non-continuous. The auto-resequence function will renumber all to create a continuous sequence. Select the entry continuous IDs in the pick list and the characters will be sorted by their current character number. Example: a sequence '1,3,4,6' would become '1,2,3,4'. Another option renumbers the characters, headings, or items by their name. This may be useful if you want to make a complex rearrangement and rather prefer to change you character names in a way that they can be sorted, than sorting the characters in this dialog box manually.

The auto-resequence function offers the option to use the steps setting to renumber the ID with a step value greater than '1'. Using a step of '10' will result in a ID sequence of '1,11,21,31, ...'. This might be convenient while you actively develop your character definition to directly insert additional characters between existing characters. The disadvantage is that the moving of characters becomes confusing (see above). A step of '1' is recommend under most circumstances.

Reorganize overview    [image] Contents of Editing    [image] Main table of contents    [image] Next


In depth information about sequence changes:
In depth information about sequence changes: Changing the sequence of characters, headings, or items involves changing the IDs (CID, HID, or IID). You can do this at any time manually in the respective editing forms as well, as long as you do not change the ID to an already existing ID. The Reorganize project definition form avoids this problem and provides a visual interface to sequence manipulation.

The move algorithm really manipulates (increases/decreases or swaps) the ID numbers (CID, HID, or IID), which determine the sequence. Occasionally irritating results are possible if the IDs are not continuous. Example: If the number 7 is moved one step down in the sequence '..., 6, 7, 9, ...', the result is '..., 6, 8, 9, ...' and the sequence was not effectively changes. (The algorithm will probably be improved in a later version of DeltaAccess, but currently I do not have the time to do it.)

Negative IDs are not allowed. If you try to move ID '3' 5 steps up, it will be changed to ID=1. On the other hand, there is no limit to the number of steps you can move characters, headings, or items down, i.e. increase their ID. You can use this behavior to Select all (see button at bottom of dialog box), and add the Steps value to all ID numbers. For example, this is useful if you want to manually merge two previously separate character definitions.


 Copying items or characters, with or without item description

If you think of your descriptor project as an item by character matrix, the options to copy items or characters, with or without the associated item descriptions (= data in the matrix), can be visualized in the following way:

Characters: Copy character 1 and 2 from

CID Items       CS	1 TE	2 1	2 2	3 1	3 2
1. Species A	abc
2. Species B	nop
3. Species C	qrst
•	without item description (checkbox unchecked) results in

CID Items       CS	1 TE	2 1	2 2	3 1	3 2	4 TE	5 1	5 2
1. Species A	abc
2. Species B	nop
3. Species C	qrst
•	with item description (checkbox checked) results in

CID Items       CS	1 TE	2 1	2 2	3 1	3 2	4 TE	5 1	5 2
1. Species A	abc					abc
2. Species B	nop					nop
3. Species C	qrst					qrst
Note: If you want to copy a single character state within or between already existing characters and with or without the item descriptions, you can use the Copy method of the Reorganize character states tab page.

Items: Copy item 1 and 2 from

CID Items       CS	1 TE	2 1	2 2	3 1	3 2
1. Species A	abc
2. Species B	nop
3. Species C	qrst
•	without item description (checkbox unchecked) results in

CID Items       CS	1 TE	2 1	2 2	3 1	3 2
1. Species A	abc
2. Species B	nop
3. Species C	qrst
4. Species A
5. Species B
•	with item description (checkbox checked) results in

CID Items       CS	1 TE	2 1	2 2	3 1	3 2
1. Species A	abc
2. Species B	nop
3. Species C	qrst
4. Species A	abc
5. Species B	nop

Compare also the method Preset item description in the Item editor: This method requires that a new item is already existing and allows to fill this item with the item description of a selected item. Thus in the situation

CID Items       CS	1 TE	2 1	2 2	3 1	3 2
1. Species A	abc
2. Species B	nop
3. Species C
editing the new item 3, clicking on the preset button and choosing to copy the item description from item 1 results in

CID Items       CS	1 TE	2 1	2 2	3 1	3 2
1. Species A	abc
2. Species B	nop
3. Species C	abc
Reorganize overview    [image] Contents of Editing    [image] Main table of contents    [image] Next


 Reorganize character states

This tab page of the Reorganize project definition form allows you to move, join, or copy character states within a character or between two characters of the same descriptor project.

(This is a hypergraphic)

On the top left and right side of the form you select the two characters you want to reorganize. You may select them either by number of by name. After you selected a character, the list of character states below the character will be filled. The buttons always operate from the left to the right character. To move a state from the right to the left side, use the button between the character names on top to swap the characters. After you have selected a character state, the action buttons in the center are enabled.

Moving character states moves the definition as well as the data from the left character to the right character. For example, you can create a new character in the main character edit form, and move certain states of the original character into the new one. This can be very useful if your characters have become very complex and you realize that the character states really belong to different characters. You might have started with a character like "leaf adaxial surface" and character states "glabrous, coarse, pubescent, velutinose, spiny, glandulous, etc.". Later you might realize that the different forms of spines and the different hair types are better treated in separate characters.

Joining character states is useful, e. g., if you have previously made fine distinction, which you later consider irrelevant and want to remove. If the distinctions are meaningful, but confusing to less well trained people during identification, you should consider preserving the character states and use the mapping character states mechanism instead.

The button with the red cross allows you to delete a character state. It always acts on the left list only. Note that usually it is simpler to delete character states in the main editing form; this option is provided to delete states while reorganizing them.

Copying the definition of character states is useful if you need to create a similar set of character states for closely related characters, e. g., one character for the upper and another for the lower side of a leaf. Note that you can also copy entire characters together with all their states on the Reorganize characters tab page.

By checking the checkbox copy with item description, you can copy the item description associated with this character state together with the definition of the state. This is especially useful if you want to split a single state, that makes two independent statements, into two states (e.g., to change Leaves: 'rough and hairy' to Leaves: 'rough' and Leaves: 'hairy'). See also Overview over methods to copy information for a comparison of available copy methods.

Which buttons are enabled depends upon whether the character state code (CS, usually a number) of the state you selected in the left list is already present in the second character (only the code is relevant, differences in the character state name are ignored).

If the character state code does not exist in the second set of character states, you can either move the character state into the second character (all item data are automatically changed), copy it (only character state definition copied, no item data changed).

If the character state code already exists in the second character, you can join the character states, i. e. you move the state from the left character to the right character, merging the information of the states with identical state code (CS) in both characters. Note that while the first actions are reversible (just move the character state back, or delete a copied one) you can not reverse a joining action!

The option "Assign new state code before copy/join/move:" allows you to rename the character state (CS) of the first character while you copy, join or move it. For example if both characters have a state 1 and 2 and you enter '3' here, you can still move (instead of join) character state 1 to the second character, while renaming it to character state 3.

If you want to join two states within a single character, you can select the same character on both sides, select the first state, and enter the code of the second state in Assign new state code... You could also use it to rename the code of a state, but it is easier to change the CS field in the list of character states in the Character Editor (click on the [image] -button above the list of states).

If you reorganize large character definitions (e.g. when merging projects) and have to move or join many states, you can (a) suppress warning messages by checking skip warning messages and (b) simply double-click on a state in the left character state list to move or join it to the right side (whichever button is enabled, see above).

Currently there is no option to change the sequence of states using up/down button (it is planned to add this feature later). You can manually change the state codes in the character definition form. For example, if you want to reverse the sequence of character state '1' and '2', you could change CS of the first state from '1' to '99' (or any unused number), the CS of the second state from '2' to '1', and then change the first state back from '99' to '1'. The database engine will automatically change all occurrences of the codes in the item description (due to mechanisms protecting the 'referential integrity'). Note that if you would change the character state names instead, no item description has to be changed!

Reorganize overview    [image] Contents of Editing    [image] Main table of contents    [image] Next


 Reorganize item description

In the DELTA standard it is possible to define an item specific sequence of character states Example: With the character 'color', and states '1 = red', '2 = green', '3 = blue', an item can be coded as 'color blue or green'. The ItemEdit form supports this by using the CS sequence buttons.

This tab page of the Reorganize project definition form allows you to reset all user defined, item specific sequences of character states to the default sequence of character states defined in the character definition. This is useful if you don't want to indicate an item specific sequence of states, and have reorganized the character definition in a way that the states are no longer in their natural sequence.

On the left side you can select one or several characters for which the resequencing shall occur. If you want to resequence the entire project, press the Select all button below the list box. Pressing the button labeled 'Reset state sequence…' will reset all items to the native sequence of states defined in the character definition.

Reorganize overview    [image] Contents of Editing    [image] Main table of contents    [image] Next


 Reorganize subset definition

Special options and restrictions apply if you use the Reorganize project definition dialog box on a linked or subset project. It is not recommended to use the options on the pages 'Character headings', 'Character states', and 'Item description' on a subset or linked project. An appropriate warning will be issued if you select one of these tab pages. The reason is that changes to the linked project will always affect the base project and all other linked projects using this base project as well. This is usually undesirable, will be irritating, or may cause a change to be aborted.

However, the dialog box offers a special mode to allow you to reorganize the character and item subset definition of a subset project. You can add or remove characters/items from the definition using the following buttons:

The 'insert' button opens a dialog box in which the items that are present in the base project but not yet in the subset project are shown. Select one or several items to add them to the subset definition.

The 'delete' button removes one or several selected items from the subset definition. It does not delete items in the base project.

In addition two more buttons appear on the character and item tab pages if the descriptor project is a subset:

Remove unused

Character tab page: Remove all characters not used ('scored') in any item of the current subset from the subset definition.

Item tab page: Remove all items not used ('scored') in any character of the current subset from the subset definition.

Add used

Character tab page: Add all characters of the base project that are used ('scored') in the base project in any item of the current subset.

Item tab page: Add all items of the base project that are used ('scored') in the base project in any character of the current subset.

(Insight note on adding/removing characters or items: technically records containing character or item numbers (CID/IIDs) in the _Subset tables are added or removed. You can manipulate these tables yourself with SQL insert/delete queries to achieve complex changes.)

Reorganize overview    [image] Contents of Editing    [image] Main table of contents    [image] Next


 Editing project properties

Project properties contain information which concerns a descriptor project as a whole (= meta data about a project). They are stored in the property table. A special editing form (DescrEditProperties) can be used to edit project properties. In the header of this form, you can select the project name and can restrict the properties displayed to a certain group of properties. The following properties are currently used:

PropertyName	Description
User defined properties:	(the user defined properties are exported and imported to DELTA, compare the new DELTA Project directive)
ProjectAuthors	Authors of the project definition and data
ProjectComments	Comments concerning the descriptor project (imported from and exported to the DELTA Comment directive)
ProjectCopyright	Copyright notice for definition and data
ProjectDescription	Description or short introduction to the descriptor project
ProjectEditors	Can be used together with ProjectAuthors or as an alternative. Appropriate if the data are collected by a larger group of scientists, some of which function as editors.
ProjectIcon	Path to a bitmap containing an icon or symbol for the project. The size should be between 16 x 16 and 64 x 64. Use the GIF-format, if the icon shall be used in a web interface.
ProjectTitle	Title/long name of the descriptor project (imported from and exported to the DELTA Heading directive)
ProjectVersion	Version number or string for the project data set
ResourceDefaultPath	Default path if no specific pathname is given; refers to Resource attribute of _RSC
ResourceDefaultURL	As above; alternative path used for internet access; should point to identical resources
Information about origin of project:	(automatically created when using DeltaAccess, neither imported nor exported)
CopyOfCharProject	Source of character definition if project was created by copying another project
CopyOfItemProject	Source of item definition/data if project was created by copying another project
LastBackup	Date and file name of last backup to an mdb backup file
LastExport	Date and file name of last export, e. g., to a DELTA file
LastRestore	Date and file name of last restore from an mdb backup file
OriginalImport	Date and file name of import, e. g., from a DELTA file
OriginalImportSkippedDirectives	Text of all unrecognized information in the import file
OriginalImportWarnings	The text of the warnings displayed after import
Internal properties of the application:	(These properties are required, do not delete them!)
Format	The name of the format used, currently always "DeltaAccess"
FormatVersion	The version number of DeltaAccess, e. g., "1.4". DateTimeValue contains the date and time at which the project was created.
IdentifyLastCompilation	See Compiling item descriptions for interactive identification
Options_ToForm_DEFAULT	Saved options of the HTML form generation process.
Options_ToNat_DEFAULT	Saved options of the natural language item description process.
For each PropertyName a TextValue, DateTimeValue, and a NumericValue are given. The TextValue contains most of the information. It can be up to 64000 characters long. The date and time information (e. g., import or export date and time) are stored together in a single attribute.

Contents of Editing    [image] Main table of contents    [image] Next


 CharEdit form: defining character mappings (key states)

This option is currently not yet available and will be added in one of the next versions. A subform will be implemented to define character mappings. Some information can be found in the following chapter: Mapping character states (key states).

Contents of Editing    [image] Main table of contents    [image] Next


 Mapping character states (Key States)

* In the current version of DeltaAccess this feature is implemented as a text attribute only. The data are imported and exported, but no further use is made of them inside DeltaAccess. No special editing support is provided. The next version will translate the KeyStates attribute into data structures and use them during interactive identification. *

Mapping character states is useful to present a simpler choice of options for identification purposes, while maintaining the possibility to record more subtle differences during data collection. Two main applications can be distinguished:

For categorical characters (UM/OM) it might be useful to combine several character states, so that during identification someone with less training does not become confused. For example, the distinction between 'velutinose' and 'subvelutinose' can be meaningful, but difficult to decide unless you are well acquainted with the group you are identifying. Using character state mapping, you can combine both states into a single state for use during identification.

For numerical characters, entering the exact measurement is usually the most powerful way during identification. Yet, it is often faster to offer a choice of ranges. If the important question is whether conidia are smaller or larger than 10 µm, usually a single look into the microscope will suffice, while you have to measure at least 30 conidia to get an exact measurement.

DeltaAccess does not provide a utility for the generation of printed dichotomous keys itself, but you can use R. Pankhurst's Pankey or M. Dallwitz's Confor for these purposes.

It is possible to map character states in such a way that the ranges overlap. For example it is possible to map '1-3 -> 1', and '3-5 -> 2'. Thus, items with the original state '3' now have the mapped states '1'/'2'. This is useful to increase the error tolerance of the identification (while decreasing the resolving power).

Note that this mechanism also allows to define alternative character states which are mapped to a single original state (i.e. they are synonymous states). If you define '1 -> 1', '2 -> 2', and '1 -> 3', the mapped state '3' is a synonym of the mapped state '1', both pointing to the original state '1'.

Contents of Editing    [image] Main table of contents    [image] Next


Interactive Identification, Table of contents
 DeltaAccess –
a SQL interface to DELTA (Description Language for Taxonomy), implemented in Microsoft Access

Interactive identification

   Introduction to interactive identification
   Identify in comparison with other identification software
   DELTA based multiple entry, interactive identification outside the realm of taxonomy
   Interactive identification: The Identify dialog box
   Compiling a project for interactive identification
   Next table of contents: Appendix 1: Advanced database administration information

Previous table of contents    [image] Main table of contents    [image] Next


 Introduction to interactive identification

	Who should read this: People interested in the concept of interactive identification programs in general. For help of the identification module of DeltaAccess, go directly to Identify.
Interactive Identification is the term adopted in this documentation for a process which is also known as online-identification, computer assisted identification, electronic synoptic keys, multiple entry keys, or polyclave keys.

In a conventional dichotomous key the user is presented with a question with two (or sometimes multiple) alternative answers. After each answer, the next question with which one has to continue is indicated. Thus a strict, treelike hierarchy of questions must be answered to read a successful identification. Two methods of printing such a key exist:

1 Leaves simple 2 1* Leaves compound 4 2 Plant more than 50 cm high  S. magna 2* Plant less than 40 cm high 3 3 Flowers yellow S. lutea 3* Flowers white S. alba 4 Fruits hairy S. pubescens 4* Fruits smooth S. glabra	1 Leaves simple 2 Plant more than 50 cm high  S. magna 2* Plant less than 40 cm high 3 Flowers yellow S. lutea 3* Flowers white S. alba 1* Leaves compound 4 Fruits hairy S. pubescens 4* Fruits smooth S. glabra
The method displayed on the right side has certain advantages, because the hierarchy of the key is easily understood. For example, on the left side it is much more difficult to see that S. glabra must have compound leaves. Its main disadvantage is that in large keys the alternative questions are hard to find. They might be several pages away from the first alternative. Also, a key is often too long to allow any indentation like the one used in the example.

A major problem of printed dichotomous keys is the fixed order of questions. Authors of dichotomous keys often put a lot of effort into determining, which are the most useful questions to start with. Yet, since the answer to this depends strongly on the condition of the object to be identified, they often can not possibly find optimal solutions. Examples are the stage of the life cycle of the organism (insect larvae or imago?), which organs are available (flowers or fruits?). Even when theoretically all questions can be answered in a well collected, well preserved specimen, the specimen might be incomplete or damaged.

Another common situation is that often certain features of an object are rather prominent and could lead to safe and fast identification. Yet, since only a very small fraction of all items have this feature, it will never be used in a printed dichotomous key anywhere near the start. Until a user comes to the place where these questions are actually asked in the printed key, she or he might have been unable to answer several other questions.

Printed synoptic keys offer a solution to these problems. The basic idea behind these types of keys is that the user can determine which questions he or she wants to answer first. The example above could look in synoptic form:

1. Leaves a) simple 1, 2, 3 b) compound 4, 5 2 Plant height a) more than 50 cm high 1, 5 b) less than 40 cm high 2, 3, 4 3 Flowers color a) yellow 1, 2 b) white 3, 4, 5 4 Fruit surfaces a) hairy 4 b) smooth 1, 2, 3, 5		Species: 1 S. magna 2 S. lutea 3 S. alba 4 S. pubescens 5 S. glabra
The identification of S. glabra could start with plant height: > 50 cm and flower color white. Since the intersection of the two sets {1, 5} and {3, 4, 5} yields {5}, the identification is already complete, without the need to use any fruit characters.

Their major disadvantage of synoptic keys is that for groups with more than around 40 species they are unwieldy to use. Writing down large lists of taxon/item numbers for each question answered, and manually determining which numbers occurs in all sets, is very difficult and tedious for large keys.

A computer program can easily perform the manual work involved in the creation of intersection sets of several questions. Such a program would fit to the terms "multiple entry identification" or "electronic synoptic keys".

Many interactive identification programs go one step further. They are truly interactive in that they support the user in the decision, which question to answer next, by ranking the available questions by usefulness. The answer to this question is local to the subgroup of items already keyed out by preceding questions. Since no fixed sequence of identification steps must be followed, an optimization function tries to determine the most valuable next steps.

Finally, it is desirable that such a program offers verification options after an identification has been reached. This can be done by offering a full natural language description of the item, which incorporates all available information, or by offering specific questions which support the current identification.

Unguided identification works well only up to a certain number of taxa. The computer only extends the usefulness of synoptic keys. The limitation, that with increasing number of organisms the number of characters also increases, remains and becomes limiting. If the list of features offered becomes too long, the identification process becomes tedious.

Also, hardly any identification program will be able to lead untrained users to successful identifications. The best a program can do is to offer support in the training itself, with liberally supplied annotations and illustrations.

Identification is always an interaction between previous knowledge of the person using an identification program, and the information database available to the program itself. This often leads to conflicting interests in the optimization of the identification process. The questions whether an organism is a plant or not can be highly effective for someone sufficiently knowledgeable. But a single definition of a plant is not an easy thing. Not every plant is green (e. g., saprophytic or parasitic plants are sometimes without any chlorophyll) and green organisms are not necessarily plants (e. g., some porifera have acquired symbiotic algae). The knowledge of what a plant is and what not is closely linked to at least the superficial recognition of the main branches of the plant and animal kingdom. A person without biological training might even be able to answer such a question in many cases, but if she or he is asked next whether the organism is a moss or not, she will often be lost, even when given an exact definition of a moss.

A related problem concerns the rules for defining a character. Complex characters are usually undesirable for analysis purposes. For example, whether the surface of a leaf has a thick waxy cuticle through which is becomes shiny, or whether the leaf has simple, complex, straight, curved, or glandular hairs, are anatomically really unrelated things. Yet, since a hairy surface is never shiny, the conventional complex character "leaf surface" would encompass all these things.

For identification purposes, it will often be preferable, to stick with conventional, complex characters. The user is well acquainted with them, and the faster the character list can be comprehended, because of reference to well known concepts, the better an identification data set is.

The use of illustrations for the same purpose should not be underestimated. Illustrations not only improve the exactness of the identification, in cases where it is difficult to convey the form of some organ in words. Detailed illustrations of photos would be chosen for such a purpose. Yet, the simple, schematic drawings are essential to make the user comprehend the character list fast. These illustrations are probably more important to the acceptance of an identification program, then the detailed ones, although both types should be available.

A general discussion of which other disciplines might benefit from the use of such software, see the following chapter Uses of multiple entry, interactive identification packages outside the realm of taxonomy.

The module used for interactive identification in DeltaAccess is Identify. It is still under development: The current version is geared towards analysis and information retrieval purposes than true, error tolerant identification. No character ranking or verification options are implemented yet. See the chapter on DELTA software sources on the internet for other DELTA based identification programs. Also, at the end of that chapter several lists of identification programs in general are referenced.

For a conceptual comparison of Identify with other identification software see the following chapter.

Contents of Identification    [image] Main table of contents    [image] Next


The position of Identify in comparison to other identification software
 Identify in comparison with other identification software

	Who should read this: People interested in interactive identification programs in general and in how the concept of Identify compares with other programs. This chapter provides no further information for the use of DeltaAccess or Identify. See also the previous chapter Introduction to interactive identification, which introduced the general concepts of interactive identification.
Probably most identification programs follow the traditional concept of printed monographic books. Ideally, the data and expertise for the identification process are collected from experts, prepared and tested for use by the general public and published in a user-friendly form. In this context, the identification tool serves as a publishing medium to carry a one-way flow of information from the expert to the user.

In contrast, DeltaAccess is designed to be a working tool of scientists themselves. Today, a word-processor is no longer a tool for a specialist, to whom the scientist passes the hand- or typewritten manuscript, but the production tool of the scientist her- or himself. Databases should become production tools as well.

Using DeltaAccess, a team of scientists can collect data for their own use, review and revise the data. They can analyze the data for errors, omissions, and for insight, e. g., performing statistical analyses. An important feature of DeltaAccess is that it can link directly into other databases, like nomenclatorial, specimen, or literature reference databases. Using the subset feature of DeltaAccess, each user can be supplied with a view restricted to those characters or items, which she or he works with. In a Local Area Network all changes can occur concurrently and are immediately visible to all users. In the future, using replication technologies already available in Microsoft Access, it will be possible to edit data offline, e. g., on a notebook while on excursion, as well. Periodically the replicated databases can be connected and the main as well as the child databases are updated.

The Identify tool of DeltaAccess for interactive identification should be seen in this context. It operates on live data, on "work in progress". It is designed primarily as an analysis or information retrieval tool for the scientist. Using it to find items that fulfill certain criteria is a helpful working tool, and a constant validation of the correctness of the information used in identification as well. Not only is Identify used to create item subsets, or select items in the MultiItemEdit dialog box, it also branches directly into item editing mode if the [image] button above the Item list is clicked.

Identify can be used as a full identification tool nevertheless, but neither its implementation nor the documentation are currently fit to distribute it as a stand-alone publishing tool. Identify is currently marked as a "preview", because some important features like character state mapping and images are not yet fully implemented in the current version of DeltaAccess.

The "publishing" kind of identification tools mentioned first are as important as are interactive data repositories like DeltaAccess. Both tools complement each other. The publishing tools are most important for teaching and training purposes, as well as for applied identification purposes. Both tools need interfaces for the web, as well as stand-alone applications to use on notebooks or personal digital assistants (PDAs).

Identify could (and hopefully will be) developed into a publishing tool, intended for end users in read only mode as well. The implementation of it would probably use another development tool to make it independent of MS Access. Ideally, it would still use the Jet Engine and mdb data structure (e. g. Visual Basic and C can do this), which would allow it to be integrated into the networking environment described above.

---

Each identification tool must assess, which audience is expected to use the software. There will certainly be a market for attractive, polished multimedia packages. One such market are for example high school and perhaps some undergraduate courses. Yet, in most cases, a simple flip-chart containing the 20 observable species of whales, or a field guide with annotated pictures of birds will be more useful, more attractive, lighter, and more waterproof than computers will be in the near future.

The basic assumption of DeltaAccess and Identify is that there is less need for polishing existing knowledge, than there is a need for the collection of knowledge. DeltaAccess and Identify aim at the professional or amateur scientist. Some identification tools seem to assume that the major problem with the identification of biological objects is that the available data are too difficult to handle. This might be the case in some situations, especially if available literature is lacking adequate illustrations. Yet, in many cases the problem is much more difficult in that there are no up to date keys available at all, or that only keys to small subgroups can be found in specialized articles. In the latter case, much identification experience (to recognize the subgroup) and bibliographic knowledge is required, before an identification can be obtained.

Given the current lack of taxonomic expertise, it can not be expected that sufficient funds will become available to have the systematists do their basic work, and then convert and tailor this information for use in interactive identification programs.

The position of DeltaAccess as a working tool is essential to improve this situation. If any software requires much effort in coding the data for the single use of publishing and identification program, it will be of limited use. DELTA based data sets can be used to prepare printed monographs as well as interactive identification packages. They can contain much more information, especially more detailed information than the interactive identification package would include. Using DeltaAccess, the scientist can use the data set as primary data storage to organize and analyze her or his work while it is still progressing. At the end, data should be made available to the scientific community, which can be used to integrate them into more comprehensive data sets.

The data themselves should be made available, in a format, which can be modified and enhanced. Science is an enterprise concerned with progress, not final products. Software should at least offer a facility that the user can annotate the information provided with his or her own knowledge. Preferable, the data should be modifiable themselves, so that added knowledge is immediately used during the next identification runs. Any printed key provides the latter opportunity!

Unfortunately, currently the tendency seems to be, to remove DELTA data sets from public access. Almost any available "DELTA" data set is in fact encrypted in the proprietary format which IntKey uses. The understandable concern is the protection of copyright, of the effort necessary to create a large data set. DeltaAccess databases also can be protected using either a database password or the Microsoft Jet security model. The preferred method of copyright protection should be fingerprinting though.

Contents of Identification    [image] Introduction to interactive identification    [image] Main table of contents    [image] Next


DELTA based multiple entry, interactive identification packages outside the realm of taxonomy
 DELTA based interactive identification packages outside the realm of taxonomy

	Who should read this: People exploring the use of identification software in other disciplines for non-biological objects. This chapter provides no further information for the use of DeltaAccess or Identify.
The concept of the synoptic keys and interactive, multiple entry software was developed mostly in the context of identification of biological organisms. Under which conditions can this concept be used for similar tasks in other disciplines?

Organisms usually have a large number of features ("characters"), many of which may be redundant for identification. This redundancy often depends on the state of other features. A feature may be non-informative in one subgroup, but necessary for identification in another subgroup. Some features may be reliable, but rarely accessible, other features are comparatively unreliable but readily accessible. An feature may be unreliable because it is highly variable in itself, or because the observation process is problematic, so that both the observation of the object under identification, as well as the recorded data are usually unreliable.

A task where the similarities are obvious, is the diagnosis of human illnesses. The primary diagnostic feature is often inaccessible (e. g., because an operation would be necessary to achieve an unambiguous diagnosis, or because a routine test would be too costly), so that many illnesses must be deduced from secondary symptoms. These symptoms may be slightly different in each person. After the tentative initial diagnosis based on well accessible characters, a verification of the diagnosis based on less accessible (costly in terms of time or money) features is usually done. An interactive diagnosis program could make proposals for the most cost-effective diagnostic routines in the present case. Such a program certainly could not replace a practiced physician, and probably no physician would ever turn to such a program in common cases. A potential for such a program could be rare illnesses, which physicians currently have to look up in books. Examples are poisoning cases, or tropical diseases in non-tropical regions.

The identification of cultural artifacts in museums or in archeological projects could be a potential task for interactive identification programs. Museum objects, which have been mishandled, or where the label is missing, could be re-identified. The use in archeology will often be limited beyond training purposes, because the characteristic lack of characters. One example were DELTA has already been used is the identification of pottery (Louhivuori 1996).

The perhaps most promising application in this area could be the identification of stolen works of art, or stolen valuables in general. The international trade of stolen art works and antiques is a serious problem. To discourage art theft and fraud, and to help in the recovery of stolen art, it is essential that as many collectors, auctioneers, and art traders have an opportunity to check offers against catalogues of stolen property. Such catalogues exist in printed versions as well as on the internet (see, e. g., The Art Loss Register, www.artloss.com). Achieving meaningful results without having to browse through hundreds of illustrations usually requires a good knowledge of the way in which the items are described. The Art Loss Register employs trained art historian staff for information retrieval (www.artloss.com/alrinfo.htm, 11.3.98), which makes the use of the register expensive. Interactive identification software could potentially increase the identification success of untrained persons considerably. Works of art have a large number of features, many of which are applicable only under certain circumstances. An integration of illustrations into the identification process is vital. Similar to biological objects, readily available features may lead only to an temptative identification, which must then be verified by costly expertises or analytical procedures. A differentiation between the reliability and the availability (or cost) of a feature is essential to find the most cost effective verification method. Such a differentiation is not available in the DELTA standard, but has been implemented as an added feature in DeltaAccess.

Many general information retrieval situations can be understood as "identifications". Interactive identification has usually limited value in the case of artificial classifications or hierarchies. Neither in a library organized by the Dewey decimal system, nor in a database of legal cases, organized by an abstract legal classification, will the approach of interactive, synoptic identification programs be especially useful. These classifications have rarely redundant features, so that all questions must be answered anyway, and although some questions may be necessary only in part of the hierarchy, following the hierarchy will usually be an optimized search tree.

Yet, even in these cases some insight gained from interactive identification systems could be useful. Literature search queries conventionally work "bottom up", i.e. you have to enter keywords, and get all articles where these keywords have been entered. A problem is that the use of many of these keywords is not immediately clear to a non-librarian researcher. Without knowledge of the thesaurus used during indexing the articles, it can be very difficult to find the right keywords. This problem is increased by the fact that keywords are often used inconsistently, and that some keywords may be outdated while other keywords have been used only in new entries, but not in the older literature. The effect is that literature queries of scientists, which have not become experts in information retrieval, often return too few, too many, or entirely the wrong articles.

One solution could be to use a "top down" approach in the selection (or "identification") of the desired articles. Starting with a guided identification key, which could be either designed by experts or calculated from the data themselves, the user could be offered a free query, which potentially allows to enter any keywords, but restricts the pick-lists of keywords to those relevant to the remaining articles. Similar to biological identification programs, an option could be offered to sort these remaining keywords by their "identification usefulness"; i.e. how well they split the remaining articles into distinct groups.

The new approach would be to narrow the scope of the query systematically, until the set of remaining articles is large enough to be reasonable sure that the desired articles are in the set, but small enough to allow an interactive support of user decisions in a free keyword query.

Another test case could be real estate sales. The buyer could attempt to "identify" offers for sale, given her or his very personal preferences. A very useful feature of biological interactive identification software would be the free choice which questions to answer first (while offering a default sequence of questions, which the agent considers most useful) and the implementation of inapplicable characters, which are quite frequent in real estate situations.

Some of the features found in interactive identification systems could be useful in cases where no real classification exists, and where large data sets are used for exploratory research. For example, in a business database one might be interested whether other operations which fulfill some criteria the researcher deems significant, has similar problems in a certain field. Existing applications often use multivariate statistical methods (clustering, PCA) to find the most similar enterprise. Yet it might be useful to leave the choice of questions to the intuition of the researcher in certain cases. While this could be accomplished with conventional information retrieval interfaces, a unique feature of identification systems, the option to ask for "verification of identification" could be very useful to gain additional insight, which might support or reject the initial hypotheses.

Further information on existing interactive identification programs (mostly not based on DELTA) can be found in Pankhurst (1991). Beyond examples from biology itself, examples from medicine, pharmacognosy, and geology are mentioned there. Relevant internet link pages to interactive identification programs can be found in the chapter DELTA software sources on the internet of this documentation.

Contents of Identification    [image] Introduction to interactive identification    [image] Main table of contents    [image] Next


 Questionnaires

Questionnaire (e. g., in sociology) can be viewed as descriptive data. DeltaAccess provides a general tool to handle questionnaires. If one would try to handle questionnaire data directly in a table, the maximum of 255 fields per table limits the amount of options in a single table. DeltaAccess effectively removes such limitations.

The most important character definition attributes are CharName for the name to be displayed for a variable, Type, and MultistateType. Set the latter to Exclusive to prohibit entering multiple choices for a single question. You can further structure a questionnaire using Character headings.

An interesting option is to provide a categorical character/variable (use Type, UM for unordered and OM for ordered categorical data) and enter the common options as character states in the character editor. Then add an additional state 'TE' to give an option to directly add additional states. Such "Other, please specify:" choices are a common feature of many questionnaires.

Especially useful in this context is the option to Creating item descriptions as HTML forms. These forms provide an easy way to put a questionnaire for direct fill in on the Internet.

Contents of Identification    [image] Main table of contents    [image] Next


Interactive identification: the Identify dialog
 Interactive identification: the Identify dialog box

This part is a preview of what will be possible in the next version. It can currently be used for information retrieval only and has only limited functionality.

If you have yet not done so, you might want to read the Introduction to interactive identification.

Character groups and character list: On the left side of the dialog box you see a list of characters. The combo box on top of the character list defines which named character group is displayed in the list. Currently the default is "All categorical and numerical characters". See Character list for more information.

Conditions: After you have selected a character from the character list you can specify a condition for this character. Depending on the character type, different sets of controls appear on the right side of the character list. Follow one of the following links for information about defining a condition for categorical, numerical, and text characters.

The place in the lower center part of Identify is reserved for images, which are not implemented yet [*** scheduled for a future release].

Identification steps: Each identification step you have added will be displayed in the list in the upper right part of Identify. You can select a step and delete it using the [image] -button. See Identification steps for more information.

Evaluate button: After you have entered one or several conditions you can execute the identification by clicking on the Evaluate-button. This will execute the query based on all conditions defined so far, fill the item list, and revise the character list (the latter only if less than 500 items remain *** NOT YET IMPLEMENTED). The symbol indicates that you filter those items, which fulfill the defined conditions:

Items or taxa remaining: Displays the number and name of all items, which fulfill the defined conditions. See List of remaining items for more information. You can open the remaining items in the item edit form by clicking on the button with 3 dots ( [image]). If you select one or several items from the list, you are given the option to open only the selected items, instead of all remaining items.

Contents of Identification    [image] Main table of contents    [image] Next


 Identify: Named character groups

Any character may be a member of several named character groups. Named character groups are stored in the _Char_Heading table and can be edited using the Edit character headings form. See the chapter Overview over uses of character headings for further information

Identify    [image] Contents of Identification    [image] Main table of contents    [image] Next


 Identify: Character list

On the left side of the Identify dialog box you see a list of characters. The combo box on top of the character list defines which named character group is displayed in the list. Currently, the default shows all categorical (UM/OM) and numerical (IN/RN) characters. Alternatively you can search in text characters or item description notes (notes of all character types), or enter a restriction for the item name.

For each character, the number (CID), Type (UM/OM/IN/RN and TE), and character name are shown. The column labeled "!" indicates whether a character is mandatory, i.e. present in all items.

The standard sorting is based on an internal estimation of the separation power of characters. The characters most likely to give fast progress in the identification should be listed first (*** Currently only based on the reliability defined for a character, not on the item descriptions like in M. Dallwitz's IntKey. ***). By clicking on the column headers above the list you can alternatively sort the list by character number (CID), character type, or character name. Click on Std to restore the default sorting order.

Identify    [image] Contents of Identification    [image] Main table of contents    [image] Next


 Identify: Selection of categorical character states

For categorical (multistate, UM/OM) characters you now select one or several of the character states listed. The list is initially sorted by character state code (CS); you can sort it by character state name by clicking on the column header labeled CharStateName. The first column labeled Items displays the number of items(1) for which this state was scored in the project. The column labeled with "*" indicates that a character state where a "*" is displayed has been defined as implicit.(2)

You add the states to the list of identification steps by clicking the Present-button ( [image])

If you select several character states, as shown in the example above, you specify that you are uncertain about which state applies. If, e. g., you select both 2 and 3, the object in question may have state 2, or state 3, or both (i. e. state 2 OR 3).

Identify    [image] Contents of Identification    [image] Main table of contents    [image] Next


Identify: Item distribution among character states
(1) Item distribution among character states: The column labeled Items shows the number of items to which a state applies. The number always refers to all items, not just the items remaining. Thus previous errors in the identification will not influence you in your decisions. Note that more items may remain after evaluation than the number listed here. Unless the Exact-checkbox has been set, items coded as unknown or variable (U/V/TE) for the selected character are included in the remaining items, but not in the count in the character state list.


Identify: Implicit character states
(2) Implicit character states (indicated by an "*" in the second column of the character state list) may lead to problems when retrieving information directly from an uncompiled descriptor project. Items where a state is only implicitly present will not be retrieved. No problems occur when using a project which has been compiled for identification, because these states have added there.


 Identify: Using numerical characters

For numerical (IN/RN) characters you either add a single value or a range of values.

Single value:

The difference between the two options "Single measurement" and Average of several measurements is that a single measurement may be an extreme value. Thus all items where this value is in the range of minimum to maximum for this value are included in the resulting item set. If you specify that your value is the result of several measurements, the value must be within the normal range specified for a given item.

Selecting a single measurement is very restrictive. You can optionally add an error margin to your value, to make your condition less stringent. In the example above, all items between 5 and 15 are included in the resulting item set. Note that the result of the error margin is immediately shown in the gray range controls (Between __ And ___) at the bottom.

Range of values:

A range of values is considered inclusive. In the example above items with 8 or 15 would be included in the resulting item set. Click on the Add-button ( [image]) to add the numeric condition to the list of identification steps.

Identify    [image] Contents of Identification    [image] Main table of contents    [image] Next


 Identify: Using text character and Notes

If you have selected a text character (TE) from the character list on the left side of Identify, you see the following controls in the upper center:

You can enter two text strings, which will be searched as an instring(1). You can decide whether you want to combine the two strings with the AND or the OR operator.(2).

Querying text characters in retrieval mode is rather slow, because no index is available. It is much faster when a compiled item description is used, since a word index is created during compilation. has yet been implemented. To add the condition to the list of identification steps you click on the Add-button ( [image]).

Identify    [image] Contents of Identification    [image] Main table of contents    [image] Next


Identify: Instring search
(1) Instring search: The search text may be anywhere in the text. An exact search for "XYZ" would not find a "See XYZ.", while an instring search would find it. The SQL statement for an instring query would be "Like '*XYZ*' ".


Identify: Adjacent words
(2) Adjacent words. In the above example the first string consists of several words. When Identify is used directly on the current item description (uncompiled) it will execute a true instring search and a record containing "Costa Brava, Rosa Rica" would not be found, while "Costa Rica, ANAROSA" would be found.

When using the compiled item description with a word index, the sequence of words is currently ignored, and the words may not start with additional letters. Thus the situation above is reversed: "Costa Brava, Rosa Rica" would be found, while "Costa Rica, ANAROSA" would not be found. The SQL used on the compiled word index would look like: "Where 'Costa*' and 'Rica*' and 'Rosa*' ".


 Identify: Character illustrations

If any images are available for the character or character state selected, these will be shown in the lower center. [IMAGES ARE NOT YET IMPLEMENTED]

Identify    [image] Contents of Identification    [image] Main table of contents    [image] Next


 Identify: Identification steps

In the upper right part of the Identify dialog box all conditions entered so far (see using categorical, numerical, and text characters) are listed. This allows you to verify which steps you have entered so far. for each step, two lines are displayed. The first line gives the character, the second line an abbreviated statement of your condition.

During identification, you may reconsider a previous identification statement. If you want to remove any condition, select it and click on the "reset single" ( [image]) button.

Clicking on the "reset all"-button ( [image]) will reset the identify form to the state when it was initially opened.

In the current version of Identify you can not modify conditions after they have been added. Remove the condition and add it in the modified form. The sequence of conditions has no influence on the outcome.

Identify    [image] Contents of Identification    [image] Main table of contents    [image] Next


 Identify: List of remaining items

In the lower right part of the Identify dialog box the number and name of all items, which fulfill the defined conditions (see Identification steps) are listed. The items are sorted by name.

The list is displayed the first time after you performed your first evaluation (Evaluate button, [image]). Whenever you add additional identification steps, the background of the list changes to gray, to indicate that the list is not current and that a new evaluation is necessary. The Exact-checkbox determines whether unknown or variable characters shall be assumed to be identical or not.

To the right of total number of remaining items a button with 3 dots ( [image]) is shown. You can open the remaining items in the item edit form by clicking on this button. If you select one or several items in the list, you are given the option to open only the selected items or all remaining items.

Identify    [image] Contents of Identification    [image] Main table of contents    [image] Next


 Identify: Item list options

If you click on the [image] -button above the item list in Identify, the following dialog box opens: ...

[*** New Navigation dialog box, not yet incorporated into version 1.6. Link from previous chapter is needed]

Identify    [image] Contents of Identification    [image] Main table of contents    [image] Next


 Identify: Evaluation mode "exact" (checkbox)

Exact (checkbox): For categorical and numerical characters you can decide whether unknown/variable states should be assumed to be identical with the character states you have selected (not exact) or not (exact). "Not exact" is more preferable for identification purposes, since otherwise all items coded as unknown are excluded. For information retrieval, if you want to obtain a list of items where a certain state has positively been entered into the database, you might want to change the setting to "Exact".

If you accept the default "not exact", all items coded with the special character states U, V, or TE are treated as if they would have the character state you are searching for. Note that if you exclude character states (press the Exclude = minus-symbol button), the result will always be exact. See also Combining character states with logical operators and Discussion of the SET MATCH terminology used by IntKey.

Identify    [image] Contents of Identification    [image] Main table of contents    [image] Next


 Identify: Combining character states with logical operators

All entries shown in the list of Identification steps are combined with the AND operator.

You can make multiple selections in the character state list box. Multiple character states selected in a single step are assumed to indicate uncertainty (if the color could be called yellow or orange, you select both states), and are combined with the OR operator.

To expressly specify that your object has character state '1' AND character state '2' of the same character, you can add these conditions in two steps, pressing the Present-button each time. The result should be two entries in the list of Identification steps.

Identify    [image] Contents of Identification    [image] Main table of contents    [image] Next


 Discussion of the SET MATCH terminology used by IntKey

	Who should read this: People used to the logic and terminology used in M. Dallwitz's IntKeyprogram.
DeltaAccess follows the usual database terminology of setting conditions which must be fulfilled by all items returned (predicate logic), while Intkey uses a model of two sets of objects. Thus Intkey treats character states of items like physical objects. This is not entirely a bad visualization, but it could be confusing if you are using a standard database. DeltaAccess does not have any "MATCH" options, but the same results can be obtained fairly straightforward using the predicate logic of database queries. The following paragraphs describe how to obtain results equivalent to the use of Intkey "MATCH" options.

IntKey provides the following options for the SET MATCH command:

Overlap (SET MATCH O):

"specifies that two sets of values match if they overlap, that is, if they have any values in common (e. g. 1/2 matches 2/3; 2-5 matches 4-10). (S and O cannot be used together.)"

This is the default in DeltaAccess, if you select one or several states in a single step. In the example "2-5 matches 4-10", you would select all states from 2 to 5, and then click on the Present-button. The resulting Boolean condition would then be: "where '2' OR '3' OR '4' OR '5' ".

Subset (SET MATCH S):

"specifies that two sets of values match if one set (usually the values of the specimen) is a subset of the other (e. g. 1/2 matches 1/2/4 but not 2/3; 2-5 matches 1-6 but not 4-10)."

Instead of selecting multiple states in a single identification step (which combines the conditions for each state with the OR operator), you would specify each state as a separate condition. This combines the conditions with the AND operator. In the example "2-5 matches 1-6 but not 4-10", you would select state '2', click the Present-button, state '3', click the Present-button, and so on. The resulting Boolean condition would then be: "where '2' AND '3' AND '4' AND '5' ". This condition is fulfilled by all items where states 1-6 are present, but not by those where states 4-10 are present. Compare Combining character states with logical operators.

Exact (SET MATCH E):

"specifies that two sets of values match only if they are identical."

In addition to adding the states as separate steps as in the example above, you also must exclude the states that may not be present. If you want to see only items where a certain state (e. g. '1') but none of the other states (e. g. '2', '3', '4') is present (i.e. only a single state was scored for the item), you would select '1', click the Present-button, and in a second step select '2', '3', and '4' and click on the Absent-button. The resulting Boolean condition would then be: "where '1' AND NOT ('2' OR '3' OR '4')".

Unknowns (SET MATCH U), Inapplicables (SET MATCH I):

"specify respectively that `unknown' `inapplicable' match any value. The default setting is O U I, which is usually the most appropriate for identification. For information retrieval, the most appropriate setting is usually O."

In DeltaAccess you can influence the behavior regarding the special character states U and V through the setting of the Exact-checkbox. Note that DeltaAccess never includes inapplicable states in the query.

The quotations are taken from the IntKey version 5 help file. No other source for this information could be found.

Identify    [image] Contents of Identification    [image] Main table of contents    [image] Next


 Compiling a project for interactive identification

	Who should read this: People interested in creating interactive identification tools, which use DeltaAccess for importing, or which work directly on the data structures of DeltaAccess. You should be acquainted with the general information model of DeltaAccess. See also Comparison of direct and compiled identification modes.
(*** NOTE: This is currently a rough collection of information for developers, which will be reorganized at a later time)

Identification using the _DESCR table directly poses several problems. To solve these without making identifications unduly slow, it is necessary to compile the information available in _DESCR into the separate table _ID_DESCR. Compilation modifies the item descriptions to achieve error tolerance and deals with implicit character states, including implicit unknown ('U') states, which must be inserted whenever no data are recorded at all.

The current version of DeltaAccess for Access 97 already contains a subset of this functionality. It is not integrated into the user interface yet, and is not yet used by Identify itself. It is included for use with external software (e. g. web interfaces) alone.

To compile your descriptor project (in full version of Access, not possible in a run-time version)
   Press Control G (= open the immediate window)
   If your project name is "Borneo", type:
   ID_Compile "Borneo"
   Press Enter
   Wait for a message box indicating success and close the immediate window

Problems already addressed are:

•	Implicit states are added

•	Character/item combinations saturated with states (i.e. all states are present), and character/item combinations which contain both a special state and a normal state (compare queries: Checking data) are converted to U

•	The special states V and TE are converted to U, the special state '-' is removed

•	Implicit unknowns (i.e. no state used at all for categorical characters) are added

•	Items, where for a real or integer numeric character only a single value (e. g. the mean) has been entered, are converted to ranges using the Fuzziness and FuzzinessIsPercent attributes. Note that the lower percentage calculation differs slightly from the one IntKey uses!

•	In addition, Fuzziness is also evaluated for characters of type OM. If CS=3 is scored, and Fuzziness=1, CS 2 and 4 are added as character states.

•	Combined character states (e. g. '1&2') remain in the compiled item descriptions, but the constituent states ('1' and '2') are added as well. In contrast, IntKey would only provide constituent states, but not the combination to the user.

•	The reliabilities of character and modifier are combined, see Calculation of combined reliabilities.

•	The combined reliability value in this table is set to 0 for all characters scored as unknown (U).

•	Notes and Text are removed from the main table. Instead, TXT and Notes are compiled into a word-wise full text index (see entities _ID_TXT and _ID_NOTES). Certain common words, are ignored (= "stop words", e. g. "the", "at", "it", etc.). The list of stop-words is hardcoded in the function IsStopWord(), and is designed to work with English, German, French, Spanish, and Italian. If the list gives unsatisfactorily results, you might want to send me a list of words, which should or should not be stop words in your language.

Problems not yet addressed are:

•	Mapped character states are added in their mapped form

•	Real/integer numeric values are mapped to categorical states according to their mapping definition

•	If no mapping definition for numerical characters is present, a default mapping is created automatically

Use the compilation always on the original base project (the one containing the ..._DESCR table), not on a project which contains an item link or subset instead of the original table (i.e. a ..._DESCR query). The _ID_DESCR table is not protected by referential integrity; you must recompile the ID_DESCR data after you have made changes to your character definition. //Perhaps CID could be protected, CS not because used for word index! Perhaps automatically invalidate?

The following assumptions may be made about the ID_DESCR table:

For each item, at least one record is present in ID_DESCR for all categorical and numerical characters. This might be a "U" for unknown. If characters of type text have not been used in an item, the item/character combination will be missing.

Categorical characters: CS contains only true character states and U (i.e. not the special states V/TE/-).

Numerical characters: CS contains "+" and "-" for upper and lower limit of range, respectively, "Min", "Max", and "U" for unknown. Mean/Median values have been converted into ranges, using the Fuzziness and FuzzinessIsPercent attributes of the character definition. If you write identification code, and have a range to test against (ID1 and ID2, for the lower and upper values of the range entered by the use), the conditions: "(ID1<ID_DESCR.X Where ID_DESCR.CS='+') AND (ID2>ID_DESCR.X Where ID_DESCR.CS='-')" must be fulfilled by the items.

Text characters are missing in _ID_DESCR. The contents of the TXT attribute, parsed into words, is compiled into _ID_TXT.

Notes are removed from _ID_DESCR. The contents of the NOTES attribute, parsed into words, is compiled into _ID_NOTES.

Other issues relevant for authors or interfaces (e. g. web-interfaces) to DeltaAccess style compiled data sets:

The first steps in the identification uses Named Character Groups. These can be manually defined character groups (see Edit character headings) or groups defined through the AutoGroup attribute.

During compilation, the headings where the AutoGroup attribute does not start with X (including the user defined SQL AutoGroup definitions) are translated into records in the link table _CHAR_Heading_Link and can therefore be treated just like manually defined Named Character Groups. In both cases, the character IDs of the characters to be presented in the second identification step (selection of character) can be retrieved using: "Select CID From PRX_CHAR_Heading_Link Where HID=[User-selected Heading ID]);"

Those AutoGroup codes starting with X (compare the list of predefined AutoGroup codes) require a special treatment. If this is not possible, they must be excluded in the query which retrieves the headings presented during identification (e. g. "Select HeadingName, HID From PRX_Char_Heading Where AutoGroup Not Like 'X*';").

Identify    [image] Contents of Identification    [image] Main table of contents    [image] Next


 Comparison of direct and compiled identification modes

This chapter is preliminary, because the options discussed are not yet fully available!

You can choose between two methods of identification in DeltaAccess:

•	Direct identification on the active item descriptions. Good for information retrieval, always contains the most up-to-date data.

•	Compiling the item descriptions for use by identification programs (Identify, web interfaces, etc.)

You can already compile a descriptor project for interactive identification, see Compiling a project for interactive identification. Note: This is a preliminary implementation for web interfaces! Identify itself does not use it yet, but later versions of Identify will offer this option!

Identification by use of the compiled data set is faster, safer (certain error conditions and ambiguities in the data set are excluded), and you can fully use implicit character states. The text information (TXT and Notes) is already parsed into a word index (each word of a text is a separate entry in such an index), which makes searching such information relatively fast.

On the other hand, compilation may take significant time for a large data set, and it must be repeated each time you have changed the item descriptions.

The alternative is to directly use the current item description. Its main disadvantages are that no re-evaluation of characters during identification occurs, that the evaluation of numerical characters is more complicated. On the other hand, you have actually have more options here, because you can include minima and maxima in your search, by specifying that your value is a single, potentially extreme value.

You can search for information in text characters, or in the Notes attached to any character, but this will be relatively slow, because no index is used.

In the case of combined character states (e. g. '1&2', 'flower: like red with white dots') you can not identify an item if you only select one of the constituent states (e. g. '1' = 'red').

You can improve direct identification, if you decide that you do not want to use the special states U to differentiate between whether a character has been checked, but is positively unknown, or whether it has not yet been checked. Use Reorganize queries, Insert unused characters to insert a special states U wherever a character has not been used (scored) in an item. You can also insert the implicit character states. This process is not easily reversible and it makes it difficult to assess later whether a character state was inserted because it has actually been checked for this item, or whether it is based on the global assumption which lead to the declaration of a state as implicit.

Contents of Identification    [image] Main table of contents    [image] Next


 Calculation of combined reliabilities

During compilation for identification, the following reliability and abundance settings are combined into a new reliability value:
   character Reliability,
   character Availability,
   modifier Reliability, and
   item Abundance.

The following chapter describes how these values are combined.

Character Reliability and character Availability are combined to a new reliability value, which is the minimum of either value. ******** NOT YET IMPLEMENTED!

Modifier Reliability is added according to:

The neutral element of the reliability scale is the value 5 (default value). The absence of a modifier in an item/character/state tuple is assumed to be equivalent to a modifier with the default reliability of 5. The combined reliabilities of character Reliability and modifier Reliability are calculated, using the following algorithm:

CombinedReliability = ((CharacterReliability/5) * (ModifierReliability/5))*5
= (CharacterReliability * ModifierReliability)/5

(i.e. the range 0-10 is rescaled to 0-2, the default 5 becomes the neutral element 1). Because the result is rounded to the nearest integer value, it looks like:

   |  0  1  2  3  4  5  6  7  8  9 10
--------------------------------------
 0 |  0  0  0  0  0  0  0  0  0  0  0
 1 |  0  1  1  1  1  1  2  2  2  2  2
 2 |  0  1  1  2  2  2  3  3  4  4  4
 3 |  0  1  2  2  3  3  4  5  5  6  6
 4 |  0  1  2  3  4  4  5  6  7  8  8
 5 |  0  1  2  3  4  5  6  7  8  9 10
 6 |  0  2  3  4  5  6  8  9 10 11 12
 7 |  0  2  3  5  6  7  9 10 12 13 14
 8 |  0  2  4  5  7  8 10 12 13 15 16
 9 |  0  2  4  6  8  9 11 13 15 17 18
10 |  0  2  4  6  8 10 12 14 16 18 20

Item Abundance: ******** Combination NOT YET IMPLEMENTED, currently Abundance has no influence!

Note that the compilation for identification process and the Identify dialog box assume that you are working with Reliability (0-10) values and not with fractional "weights" (compare Weight conversion). DeltaAccess allows the use of unconverted character weights (1/32 to 32), but it recommends using reliability values. Using Identify with Weight values will result in no differentiation of weights below 1.

Compiling a project for interactive identification    [image] Contents of Identification    [image] Main table of contents    [image] Next


Appendix 1. Advanced database administration information, Table of contents
 DeltaAccess –
a SQL interface to DELTA (Description Language for Taxonomy), implemented in Microsoft Access

Appendix 1: Advanced database administration information

   Fingerprinting data sets
   Securing an Access database
   Repairing a corrupted Access database
   Linking to other data sources
   Linking to other database subsystems
   Merging descriptor projects (data sets)
   Next table of contents: Appendix 2: Development documentation

Previous table of contents    [image] Main table of contents    [image] Next


 Fingerprinting data sets

Scientific data should be shared as much as possible. Yet, since the procedures of electronic publication, authorship and copyright to data sets are not yet settled (note that major changes to data set copyright were introduced around 1997), this if often not the case. The protection of the intellectual property rights of databases is a difficult problem. Regarding DELTA data sets, it seems that currently almost nobody is willing to share her or his work, because of concern about fraudulent use.

One method, which can be used to share data sets without loosing control over them, is to fingerprint them. Fingerprinting allows other people to use them, but it allows the author to recognize that somebody is in fact using her or his work. There are two variants that can be used:

Destructive fingerprinting

This method arbitrarily changes data in the data set. You could simply exchange some item names, swap parts of item descriptions, or arbitrarily change character states. This is a rough method, which seriously reduces the usefulness of the data set. It can be used to send out an example, or to send (e. g. me) a data set which produces a certain kind of error with DeltaAccess or some other DELTA software package.

Steganographic fingerprinting

With a little bit more effort, a data set can be changed in a way which is neither obvious nor creates major problems in using the data set, e. g., for identification methods. Depending on the size of the data set, change 2 to 10 items for each type of character:

Text characters: It is very simple to change textual information in a way that is very difficult to find: the spelling of the publication reference of a species, final page of literature references, deviating abbreviations of journals, etc. The idea is that the changes should be such that they are not likely to arise if somebody else collects the data independently, and that they are not easily removed by rewriting a few sentences.

Numerical characters: Change the least significant digit of the mean: For example changing 2.5-3.8-4.6 to 2.5-3.7-4.6 has almost no influence on the usability but uniquely identifies the data set.

Categorical characters: These are most difficult to change without impeding identification results when the data set shall be used. You can always change Modifiers or Notes, and you could change some character which is usually not used in identification, but present for analysis purposes only (e. g. biochemical data).

The logic behind fingerprinting is: if anybody invests enough work to find the minor errors introduced by the fingerprinting, she or he has probably also discovered some real errors present in the data set, and spent enough time improving the quality of the data, to demand a kind of authorship her- or himself.

Fingerprinting is commonly used in commercial data collections. For example, any serious address collection will have some incorrect entries, which possibly point to private addresses of employees of the publisher. If anybody start using these addresses in forbidden mailings, or incorporates them into another address collection, the source can be identified.

Appendix 1: Table of contents    [image] Main table of contents    [image] Next


Securing a DeltaAccess database
 Securing an Access database

	Who should read this: Experienced administrators who want to restrict access to their data to specific users or user groups.
DeltaAccess databases can be protected from being accessible to anybody, using the Microsoft Jet security model. Since DeltaAccess is distributed under a GNU General Public License, any user is allowed to secure her or his version of DeltaAccess.

To secure your database, you must have a full version of Microsoft Access. It is not possible to do the following with a run-time version. Please consider the alternative method of copyright protection using data fingerprinting.

Database password protection: A simple method of protecting data is setting a password for the entire database file. Close all forms of DeltaAccess, leaving the database explorer open. In the Tools menu, select Security and then Set Database Password. All users must now enter this password before they are allowed to open the database. This is an easy way to prevent unwanted users from opening a database. However, no other security measures are provided once it is open.

User-level security model: A much more powerful security model is the user and group level security of the Microsoft Jet Database engine. Users and groups can be given very specific rights or restrictions for each object separately. Some users may be allowed to modify the character definitions, while other users may only read them.

Using user-level security requires a good knowledge of the security model and can be complicated. I recommend studying the documentation provided by Microsoft (see Security in the Microsoft Access help contents). The following chapter Tips on user-level security may help you to get started and avoid some potential pitfalls. It is, however, not a step by step introduction.

Note that DeltaAccess exports data during the backup process to an unprotected database. This is intentional. It avoid problems during upgrading or when exchanging data with other users. (It can be quite confusing to unprotect a database.) If you use database security, keep all backup copies made by DeltaAccess in a secure place, and protect them by other measures.

Appendix 1: Table of contents    [image] Main table of contents    [image] Next


 Tips on user-level security

This chapter is no introduction to user-level security. It may clarify some points, after you have read the MS Access documentation on the topic.

User and group definitions are stored in the system.mdw database. Each installation of MS Access (or any other application using Jet) installs this file. If multiple users in a network use databases concurrently, they must use a single security workgroup database. The MS Access Workgroup Administrator, a link to which can be found in the main office directory, allows the administrator to change the security workgroup database to which an installation of Access is connected.

The default account is called, e. g., Admin or Administrator (the name depends on the language version of Access that you have installed). Any new installation of MS Access uses that account. As long as this account does not have a password, you are not given the option to log in under a different user name. To start using user-level security, you thus must enter a password for the administrator account.

Enter additional users and groups. (Unfortunately, user passwords can not be set from the administrator account. You must close Access, and log in under the new user name to set a password.) It is good practice to give rights only to groups and not to users. Create the groups you consider necessary, e. g., "Developer", "Scientist", and "Typist".

During the creation of groups and users, you are asked for a personal security ID (PID) for this user or group. This is a crucial point of the security model. You should make a note of the string you have entered here and keep it at a secure place. Note that the PID is case sensitive. The string is used to create an internally unique identifier in the workgroup. If another workgroup has defined the same group names, but did not use the same PIDs, the groups will be treated as different by Access. However, if you install your database in a new workgroup, and create groups with the same name and PID as in your original workgroup, the new groups will have the same rights as they used to have in the previous workgroup.

Thus, if anybody gets to know the names of groups and their PIDs, e. g., by stealing your written note, she or he can make a copy of the database, and create the appropriate groups in a new installation of Access. It is not necessary to know any user names or passwords, since she or he can create any user, and assign this user to the duplicated groups. On the other hand, if you do not know the PIDs of your own groups, it may be impossible to update your data to a new version of DeltaAccess or Microsoft Access at a later point. Also, your system.mdw might become corrupted or lost, in which case you will be locked out from your own security. If you know the PIDs and group names, you can recreate the most vital part of the system.mdw. The easiest way to understand the PID is to view them as a password for the right to create a specific user or group.

Now revoke or grant your new groups for each object in the database the desired rights. A good strategy would be to make all forms, reports and modules read only. Grant read or write rights to the project tables (or queries in the case of subsets).

If you have followed these steps so far, you have secured your users. This will avoid unintentional changes or deletions by users, which should not be allowed to do certain changes. Unfortunately, the database itself is not yet secure! The reason is that anybody who does not use your workgroup definition (system.mdw), but has access to the database (whether by stealing it or by normal access over a network) has still all original administration rights. The following two steps describe how to create a truly secure database.

The database and objects in it have an owner, who has always the right to the object, whether she or he has explicit user rights or not. The owner of DeltaAccess, as distributed, is the administrator! (This is necessary, if I want to give you full access, including the chance to fully secure a version of DeltaAccess. Only these administrator rights, give you the right to secure DeltaAccess.) Again, as in the situation above, any newly installed version of Access has full rights to the database! You must therefore change the ownership as well, to secure the database. Note that a user with administration rights can assume ownership of all objects in the current database. Unfortunately, you can not assume ownership of the database itself. Only this process in non-reversible, and is therefore required. To fully secure a database, you must create a new database while you are logged in under a username you have created yourself, i.e. not as the database administrator. Import all objects from the other database into your new database. Doing this, you will become the owner of these objects.

Another common error which is easier to fix than the ownership issue, is to remove users and groups from the default groups (like the administrators group). The effects is that indeed user rights are restricted to the rights given to the user itself or to the groups to which she or he still belongs. The problem is, that although the operation in the current workgroup (system.mdw) has been secured, the database has not been secured. Any user accessing the database (e. g. DeltaAccess.mdb) with a newly installed version of Microsoft Access will be an administrator in her or his own system.mdw. Thus, it is important to revoke all rights the default groups have to the objects in the database you want to protect. Select the administrator user, select all tables, queries, etc., and revoke all rights. Do the same for the default groups which are present in a newly installed version of Access.

DeltaAccess has not yet been tested in a fully secure mode. If you have problems, please contact me. You may have to set more differentiated rights for some forms. If you figure out what you have to change, I would appreciate a note. If sufficient interest exists, I could create default groups in the distributed version of DeltaAccess, which could be used as templates for your own groups.

My recommendation about implementing security is, not to secure DeltaAccess.mdb itself. Create a new database under a non-administrator user account as described above. Import only the tables and queries of your base and subset projects. Secure these fully in the new database. Open the original DeltaAccess.mdb again and delete the tables and queries you have imported to your new database. (If you use the management option Delete project, forms will be deleted as well; use the management option "add editing forms" at a later time to recreate the forms.) Create links back into the original DeltaAccess.mdb. You now have table like objects, which function almost like a table, but do not contain any data. The process is similar to linking tables from SQL-server into DeltaAccess. You do not have to revoke any right from these links. Even if a link has full rights, the external source of the data, i.e. the mdb file which you have secured, will limit the rights. The advantage of this solution is that it is easy to upgrade to new versions of DeltaAccess. You do not have to test which application objects require which rights for which users.

Note that it would be very difficult to create a DeltaAccess user interface for administering user-level security. A considerable knowledge of the local situation (in a network) is required, and security would not be complete unless the programmer has no ownership of the database anymore. To administer any security model in a local area network, a database administrator is required.

Appendix 1: Table of contents    [image] Main table of contents    [image] Next


 Repairing a corrupted Access database

If your system is stable, database corruption occurs very rarely under Access 97. It usually occurs if your computer or the operating system crashes, and you could not close your programs normally. I have not had a case yet, where the options 2.a) or 2.c) did not work.

The following is a short list of things you should do to repair a corrupted Access database (*.MDB) file:

1. Close Access and make a copy of the database file. This is important, because sometimes a failed repair attempt can prohibit another attempt, which would otherwise have been successful. In a network, make sure no other user is accessing the database.

2. Try one of the following options. Always work on a new copy of your original database. Each option may repair your database. Use the next option only, if the previous option was not successful.

2.a)	Reopen the database in Access, and select from the Tools menu, Database Utilities the option Repair database. This is the automatic repair mechanism build into Access, which rebuilds all internal data structures. If a message tells you that the repair was successful, select the option "Compact database". Usually these two steps are sufficient.

2.b)	If this was not successful, make a new copy from your original corrupted file, and reverse the steps: First compact, then repair. This may in fact not be different from 2.a) anymore. My experience with it goes back to Access 95 and it probably was a bug in the repair process of Microsoft Access 95, which may have been corrected in Access 97.

2.c)	If the error still persists, it might be due to corrupted code. Change the VBA project name, which can be found in the Tools menu, Options, Advanced tab, in the middle lower right of the dialog box. Change the name to any name, e. g. "TMP". This causes all modules to decompile. Execute step 2.a). If the corruption has been solved, you can change the VBA project name back.

2.d)	If neither of these steps has helped, the last things you can try before you decide that you have to go back to a backup, is the following: Get a fresh copy of the DeltaAccess application and use the restore option, using your old, corrupted database file (DeltaAccess.mdb) as a backup file. You should rename the file first, to avoid confusion with the fresh copy of the same name. If the corruption involves only forms, reports, or code but not your data, you could be successful. If the automatic restore option of DeltaAccess fails, you could even try to create a fresh, empty database in Access (File, New) and manually import the database tables of your descriptor project (all tables starting with your project name; use the standard Access tools found under the File menu) into that. If that was successful, you could try to repeat the automatic restore explained above. I had no occasion, where this was necessary, so I explain this is just as a possibility.

3. Rename the copy back to your original filename (usually DeltaAccess.mdb).

Appendix 1: Table of contents    [image] Main table of contents    [image] Next


 Linking to other data sources

	Who should read this: This chapter is relevant to you only if you want to store your data outside of DeltaAccess, e. g. on a SQL server in a network, but still want to use the analysis and editing functions of the DeltaAccess application. Storing data on a SQL server can be useful if many users access the data (e. g., an average of more than 20 concurrent users) or if you want to publish your data online on the internet.
There is no automatic routine to link external data sources (from Microsoft SQL-Server, or other databases) into DeltaAccess. The exact procedures depend on the database server available. I assume that this task is performed only by experienced users and therefore provide the following instructions to do it manually instead. Linking data sources is not possible with a run-time version of Microsoft Access; you need a full version. Two tasks can be distinguished:

a) Linking tables which already exist in an external database into DeltaAccess

Linked tables are a special feature of Microsoft Access. A linked table can be opened like an internal table, but the data remain in the external source. The table is not imported. Changes in the external data are immediately reflected inside Microsoft Access. Linked tables are represented in the database explorer by an arrow in front of the table symbol (e. g. ). The linking of existing tables is necessary, e. g., if you integrate other database subsystems manually; see also the following chapter Links to other database subsystems.

To manually link a table, select the database explorer window and use the menu entry Get external data, Link tables in the File menu of Microsoft Access. The following process depends on the driver for the external database. Consult your Microsoft Access documentation if you can not find your data source or the linking does not work (see the Microsoft Access help topic Import or link data). You may have to install additional drivers either from the Microsoft Access package (not all drivers are installed in the default setup) or you may have to install an ODBC driver supplied by the manufacturer of your database server. Perhaps try to link any table from another Access database (mdb-file; use, e. g., a backup of a descriptor project) to get acquainted with the process and make sure your problems are driver specific.

b) Porting the information model used by DeltaAccess to an external database server

If you want to keep the data of a descriptor project on a SQL server database server and use DeltaAccess as a front end to it, you must first create appropriate data structures on the server, before you can link these tables back into DeltaAccess. Porting data to a server usually requires administrator privileges.

To create a functional descriptor project with data residing on a SQL server, first create an empty new project. Now create a table on your database server for each table created in DeltaAccess. This must be done manually, unless you migrate to Microsoft SQL-Server. A very useful porting tool for MS Access databases (or other ODBC sources) is the dbScripter (see www.dkgadvancedsolutions.com). It can convert the table structure to a SQL script, which can be run on the database server.

The foreign tables must have the same structure as the ones in Microsoft Access, especially regarding the field names. The sequence of fields (= attributes) does not matter. The field types should be equivalent to the types used in DeltaAccess. Replacing some types should work well (e. g. using double precision real numbers where DeltaAccess uses single precision, or integer where DeltaAccess uses Boolean = Yes/No). The most difficult situation occurs, if you have no equivalent type to the memo type used by DeltaAccess (= VARCHAR; up to 64000 characters). You should test the behavior of DeltaAccess and inform me about errors. I may be able to improve the error handling in a future version of DeltaAccess.

Some functionality of DeltaAccess described in this manual relies on relational integrity rules being implemented. Beware if you use a database which does not implement these rules.

After you have created the tables of the DeltaAccess information model in the external database, you must link these tables back into DeltaAccess, see the task discussed above.

Next, delete each table created for your empty new descriptor project inside Microsoft Access (select it in the database explorer and press the Delete key) and rename the equivalent linked tables from the foreign source to these names. The table names in the foreign source (SQL server) and inside Microsoft Access can be different, but you must use the standard names for the linked tables inside DeltaAccess. To rename a linked table click twice on it in the database explorer.

You now have an empty descriptor project, where the data reside on the SQL server and the editing and dialog forms are available in DeltaAccess. Avoid to delete this descriptor project using the delete management option. This will break the connection to the SQL server (it will not delete the data though).

Note that you can not import DELTA files directly into such a server based descriptor project! The import process always deletes existing projects and creates a new project. To import data from DELTA into your SQL server tables, import the data set to a different (temporary) project name, and use the overwrite management action, to move the data to the SQL server. This action should preserve the connection to the server (this has not been tested yet, please inform me if problems occur!).

Note that the information model and thus the table structure may be changed in new versions of DeltaAccess. When upgrading to a new version of DeltaAccess, the restore backup mdb function changes old projects to conform with the current information model. If you have moved data to a server, you may have to do this manually. The information model on the client and on the server side must be identical. You have several options:

•	Create a backup of your server based descriptor project, and restore this to the new version of DeltaAccess. Export the new table definitions to your server again.

•	Create a new, empty descriptor project, and manually check the table definitions for changes, which would affect the server. Changes like different phrases in the description do not affect the server. Manually change the server tables accordingly.

•	If you are experienced with Microsoft Access/VBA, you can read the upgrade code used by DeltaAccess. Open the module DeltaLibRestore and look at the vba code starting with "If Version =" in the RestoreBackupMDB function. This code performs the version conversion during restore. Upgrades are often performed by SQL queries, but since these are embedded into the general VBA-restore code, some knowledge of VBA will be necessary.

c) Possible problems

Experiments were made with linked external tables, but porting descriptor projects to a SQL database server has not been tested. I will try to help you if you experience problems. The following problem was already found:

When you create a linked character subset, a special table containing the CID numbers included in the subset is created. DeltaAccess tries to protect this table through referential integrity to make it immune to changes of CID. Such changes occur, e. g., if you reorganize the sequence of characters. If the subset is based on a descriptor project linked in from an external data source, referential integrity will not be possible. In contrast to character subsets, linked item subsets should be no special problem. Static subsets are vulnerable to changes of IID, but dynamic subsets should work as expected.

Appendix 1: Table of contents    [image] Main table of contents    [image] Next


Migrating to Microsoft SQL-Server
Migrating to Microsoft SQL-Server: If you consider using Microsoft SQL-Server as your database server, a migration tool called upsizing wizard (http:// www.microsoft.com/ AccessDev/ProdInfo/ AUT97dat.htm) is available free of charge from Microsoft. This tool will create tables with a compatible data structure on the MS SQL-Server and will create triggers simulating the relational integrity rules that were defined in Microsoft Access. It also will automatically move your data, and give you much information about the cooperation of Microsoft Access and Microsoft SQL-Server. A good book about the interaction between both systems is Access and SQL Server by Viescas, Gunderloy and Chipman (Sybex). If you are using MS SQL-Server 6.x, be sure to select "Use Triggers" and not "DRI" (= declarative referential integrity) when exporting the referential integrity. Only triggers will export the cascaded updates and deletes, which are necessary for the functionality of DeltaAccess.


 Linking to other database subsystems

	Who should read this: Experienced administrators who want to integrate other database subsystems into DeltaAccess. See also the general introduction to the concept of database subsystems in the introduction. The previous chapter Linking to other data sources contains additional technical information about the process of linking data sources into Microsoft Access.
The attributes CollUnit, LitRef, and ItemName of the Item entity should link into separate database subsystems for collection management, literature references, and nomenclature respectively. Currently these attributes are simple text fields, not protected by relational integrity. You can enter any text, whether it is available in your specimen, literature, or nomenclature database or not. This clearly is not how it should be. The entries should be selected using pick lists linked directly into the foreign database, and a double-click should open the linked record in the foreign subsystem, e. g. a literature reference.

I can do this for my own literature and collection subsystem database (an unpublished Microsoft Access application), but other databases must provide an ODBC driver and you have to do the linking manually using the standard Microsoft Access tools. If enough experience is accumulated, it may be possible to generalize this process sufficiently, that it can be performed with the help of a wizard like tool. Anybody volunteering in this area is more than welcome!

I would very much like to link commercial literature/reference software into DeltaAccess. I would be grateful to anyone who could help me with this, by checking if his or her software allows Microsoft Access to link to any part of it (preferably a list of unique reference identifiers, if possible user readable like using the Harvard format). In general this would either mean that the reference manager uses a standard PC database format, or that it provides an ODBC driver. I currently do not know of any reference manager that provides this.

Some technical hints about using links in Microsoft Access can be found in the previous chapter Linking to other data sources.

Appendix 1: Table of contents    [image] Main table of contents    [image] Next


Merging Delta projects (data sets)
 Merging descriptor projects (data sets)

	Who should read this: Experienced administrators who manually want to merge existing descriptor projects into a joint project, possibly using subsets to offer multiple views on the single data set. The general rationale of using separate projects has already been discussed in the introduction.
DeltaAccess supports multiple independent descriptor projects. This corresponds with the current use of DELTA in taxonomy. Yet, in many cases it will make sense to join existing projects concerning closely related subjects into a single project. Multiple subset views, restricting the visible characters or items, can be created for different researchers, taxonomic groups, or regions. In contrast to the text-file-based classical DELTA programs, DeltaAccess supports multiple, concurrent users as long as they are connected through a local area network.

The main problem in merging data sets is that usually the character definitions of the descriptor projects are incompatible. If they are compatible, you only need to append the item definition and item descriptions, see the chapter Appending data to a project.

If the character definitions of the descriptor projects are dissimilar, you have to merge the character definitions first. This can be a difficult process, because usually only experts can decide which characters are identical and which are not. It is not sufficient that the character name is identical: the same term might be used for entirely different features if the item groups are sufficiently distinct.

A true merge, which will append those characters which have identical meanings, but append all other characters is not yet available among the options of the append management action. Two semi-manual methods are therefore outlined in the following paragraphs:

Semi-manual method to merge two descriptor projects, inside DeltaAccess

To achieve a merging of two projects with only partially compatible character definitions, you can do the following:

Examples:		First project "P1":	Second project "P2":
Situation: Character 1 and 2 are compatible, character 3 has to be manually resolved, while the color has been recorded only in the second project.		1. notes 2. substrate 3. spore length 4. spore width	1. notes 2. substrate 3. spore size 4. color
Step 1. Append the character definition of the second project to the first project using the Append management action (leave "append item definition from" empty). The characters of the second project will be appended using consecutive ID numbers after the last number used by the first project. Note that the project name of the second project will be appended to the character names, to guarantee that the names are unique.		1. notes 2. substrate 3. spore length 4. spore width 5. notes [P2] 6. substrate [P2] 7. spore size [P2] 8. color [P2]	(unchanged)
Step 2. Move all characters in the second project up, using the Reorganize characters tab page of the Reorganize project definition form. If you set the Steps-value to the last character number in the first project ('4' in the example), you can do this with a single click on the Move-down button. The second character set should now have identical character numbers with the newly imported additional characters in the first project.		(unchanged)	5. notes 6. substrate 7. spore size 8. color
Step 3. Delete all newly imported characters in the first project, which have already a corresponding CID coming from the first project. You can do this in the Reorganize tab page used above, where you can select multiple characters and delete them in a single operation.		1. notes 2. substrate 3. spore length 4. spore width 7. spore size [P2] 8. color [P2]	(unchanged)
Step 4. In the second project, edit each character you have deleted in the first project, and change its CID to the CID of the corresponding character in the first project. The simplest way to do this is to directly edit the CID number in the character editor, since no other character will use the same number.		(unchanged)	1. notes 2. substrate 7. spore size 8. color
Step 5. Append only the items of the second project to the first project using the Append management action.

Manual method to merge two descriptor projects, using DELTA coded text files (export/re-import)

Open the Reorganize method, select all characters of the second project and "move" them as many steps down as the first project has characters. The result is that all characters will be renumbered in a way that the two projects have separate sets of character numbers, which do not overlap. If you have verified that some characters are identical, you can move these characters down again, so that their CID number equals the CID number of the corresponding character in the first project. Export both projects to DELTA coded text files, and join the two projects by manually appending the additional characters of the second project to the character definition of the first project. Do the same with the item descriptions and re-import the combined DELTA file. Use the Reorganize character states method to join those characters which are identical indeed (join all character states of these characters). Beware that some DeltaAccess features might be lost when you export to and re-import from DELTA coded text files!

Appendix 1: Table of contents    [image] Overview manage projects    [image] Main table of contents    [image] Next


 Troubleshooting during installation

	Who should read this: Users who have problems installing DeltaAccess the first time.
So far I found the following sources for problems you might have:

•	If you cannot open the file DeltaAccess.mdb in Microsoft Access, try to open Access and using the file open command, instead of double-clicking on the file in the Windows explorer. If this does not work either, you might be using the wrong version of Access. Check which version of Microsoft Access you have installed, and which version of DeltaAccess you have downloaded. DeltaAccess is available only for Access 97 (= Access version 8) and can not be used with earlier version of Access like Access 95 or Access 2. It may work with the coming Office 2000, but this has not been tested yet.

•	If text on the screen is only partially readable (labels on the forms, etc.), you should check whether the Windows standard TrueType fonts Arial and Tahoma are properly installed. Some reports also need the standard TrueType fonts Times New Roman and Wingdings. These fonts are installed by default on any computer with MS Office/Access 97, but you may have deinstalled them.

•	If you receive the following error immediately after opening DeltaAccess: "The expression XXX you entered as the event property setting produced the following error: ...", where XXX stands for On MouseMove or On Timer, Microsoft Access has probably failed to localize a library necessary for its operation. This is a problem of the Microsoft Access installation itself. To close the error dialog box and prevent the error from reappearing immediately, move the mouse to the background area and press the escape key twice. If the welcome message is still open, close it (use the menu: File, Close; use the keyboard if the mouse can not be used). If the database explorer, is not visible, unhide it (menu: Window, Unhide, "DeltaAccess: database"). Select a module in the database explorer (e. g. UsrLib) and click on the Design button. Select References from the Tools menu, and check the path to the libraries marked as used in the list. One or several of these libraries might be missing. Correct the path to the libraries, close the dialog box and select Compile and save all modules from the Debug menu.

Installation    [image] Main table of contents    [image] Next


Appendix 2. Development documentation, Table of contents
 DeltaAccess –
a SQL interface to DELTA (Description Language for Taxonomy), implemented in Microsoft Access

Appendix 2: Development documentation

   Limitations
   Recognized DELTA directives
   General development information
   Co-development issues
   Multi-language support
   Next table of contents: Appendix 3: Information model and data dictionary

Previous table of contents    [image] Main table of contents    [image] Next


Limitations, Overview and Table
 Limitations

This chapter consists of the following sections:

  Recognized DELTA directives

  Limitations which will be removed

  Problematic limitations

  Limitations which have low priority

Appendix 2: Table of contents    [image] Main table of contents    [image] Next


 Recognized DELTA directives

Directive	Import	Export	Functionality/Remark(s. also Legend and Notes)
Character list =  Character descriptions	Yes	Yes	OK.
Character types	Yes	Yes	OK, default UM is not exported. Imported into the Character Type attribute.
Numbers of states	N/A	Yes	OK, superfluous information, ignored during import. The default value 2 is not exported.
Multistate types	Yes	Yes*	OK. New Directive: and/or/intergrade/exclusive (i. e. EOM, EUM), see MultistateType attribute.
Mandatory characters	Yes	Yes	OK. See mandatory characters.
Implicit values	Yes	Yes	OK. Currently not observed during identification; see option under Analyze to insert implicit values as explicit data.
Character reliabilities  / Character weights	Yes	Yes	OK. Reliabilities preferred, Weights are optionally converted during import.
Character availabilities	Yes	Yes*	OK. New directive, see Availability attribute
Absolute error	Yes	Yes	For numerical characters only. Imported to/exported from the Fuzziness/ FuzzinessIsPercent attributes.
Percent error	Yes	Yes	For numerical characters only. Imported to/exported from the Fuzziness/ FuzzinessIsPercent attributes.
Link characters	Yes	Yes	OK, see attribute LinkGroup/Link characters.
New paragraphs  at characters	Yes	Yes	OK. In natural-languages descriptions a new paragraph is started before each character where this attribute is set.
Replace semicolon  by comma	Yes	Yes	OK. In natural-languages descriptions, characters linked by the LinkGroup attribute (see Link characters directive) are separated by a comma, instead of a semicolon. Confor would also omit the commas which normally separate multiple character states in a single character. [*** Imported and exported, but not yet used in DeltaAccess natural language output.]
Omit final comma	Yes	Yes	In natural-languages descriptions an item description with more than 2 states (e. g. 1,1/2/3) is normally translated into "... state 1, state 2, or state 3". If this directive is set, the final comma before the "or" is omitted. [*** Imported and exported, but not yet used in DeltaAccess natural language output.]
Omit lower for characters	Yes	Yes	For numerical characters only. Defines in natural language output that only the upper range/max will be output. Imported/exported into OmitValues, but currently not supported in natural language description of DeltaAccess.
Omit upper for characters	Yes	Yes*	The complement to "Omit lower ...". For numerical characters which contain a minimum statement ("at least x mm wide"). Available in DeltaAccess, although not supported by Dallwitz's Confor program (why not?).
Character headings	Yes	Yes	Imported into HeadingName of _CHAR_Heading table; linked through character definition attribute CharHeading. See also Overview of uses of character headings.
Item subheadings	Yes	Yes	Imported into HeadingPhrase of _CHAR_Heading table, linked through character definition attribute ItemSubheading. See also Overview of uses of character headings.
Define characters	Yes	Yes	This directive is used by Intkey and usually found in the intkey.ini file. DeltaAccess imports this directive as named character groups (tables _CHAR_Heading and _CHAR_Heading_Link). Can be edited in the Character Headings form. Recursive definitions (named group defined based on other group names instead of character numbers) are currently not supported. If an imported file contains a Character heading, but no Define characters directive, the character headings are also used as character groups und will be exported in a Define characters directive. See also Overview of uses of character headings.
Decimal places	Yes	Yes	Converted to the much more powerful character definition attribute FormatString during import, converted back during export. Additional FormatString information is currently lost during export because not supported in DELTA.
Character names	Yes	Yes*	New Directive: DELTA does not define a unique character name, the character strings are optimized for natural language output and are, even including the comments not necessarily unique. The export routine will export the attribute CharPhrase as the "normal" character string, and will import/export this string separately. *** Import: Behavior if attempting to import non-unique character names (they must be unique) not yet tested, problems expected!
Character notes	Yes	Yes	OK, see character definition attribute Notes.
Character images	No***	Yes	Not tested, import to be implemented. New feature: character images may be associated with a char. state. Ex-/import of this feature not yet implemented.
Dependent characters =  Inapplicable char	Yes	Yes	OK, see _DEP entity. Enforced in the editing forms, but not in directly in queries/tables.
Applicable characters	Yes	N/A	OK, converted to Inapplicable during import.
Key states	Yes	Yes	OK, but as text only. The string can be edited directly and is exported, e. g., for use by Intkey. No consistency checks are implemented in the editing forms and they are not yet used in the internal identification. See Mapping Character states.
Key character list	No	No	Will be used in a future version for character states names of key states only. Thus, in contrast to Confor, it must be present in addition to the Character list directive.
Item descriptions  = Item list	Yes	Yes	The Item names are imported into ItemName attribute, the item descriptions into the _DESCR table.
Item abundances  / Item weights	Yes	Yes	Abundances are preferred, Weights are optionally converted during import.
Item notes	Yes	Yes*	New Directive: DELTA-comments after item name are not always author names. This field is used for other item comments. Comments, which differentiate multiple entries of the same taxonomic name, should ultimately be moved to the new literature reference and specimen unit fields. (Note: I am actually not sure how necessary or useful this is; I intend it mainly for internal comments.)
Taxon images	No***	N/A	Images will be fully supported in a later version of DeltaAccess, imported into the resource (_RSC) structure.
Character for  taxon images	*?*	*?*	Images will be fully supported in a later version of DeltaAccess, imported into the resource (_RSC) structure.
Comment	Yes	Yes	Stored in the ProjectComments property, see editing project properties.
Heading	Yes	Yes	Stored in the ProjectTitle property, see editing project properties. The closing literal separator ("/") required by Pankey is not required by DeltaAccess.
Project Authors Project Editors Project Copyright Project Description Project Version Project Icon Project DefaultPath Project DefaultURL	Yes	Yes*	New Directive: Standard DELTA does not define general descriptor project information. These directives have been added to import and export the following project properties: ProjectAuthors, ProjectEditors, ProjectCopyright, ProjectDescription, ProjectVersion, ProjectIcon, ResourceDefaultPath, and ResourceDefaultURL.
Include characters  Exclude characters	Yes	Yes	OK. DeltaAccess equivalent: Character subsets.
Include items Exclude items	Yes	Yes	OK. DeltaAccess equivalent: Item subsets.
Emphasize characters	No	No	Formatting command for natural language output, implementation planned in future version.
Emphasize features	No	No	Formatting command for natural language output, implementation planned in future version.
Formatting marks	No	No	Formatting command, very limited support by Dallwitz's Confor program itself.
Typesetting marks Omit typesetting marks	N/A	N/A	Formatting command for natural language output, specific to the unique typesetting marks used by Dallwitz's Confor program.
Number of characters	N/A	Yes	OK, superfluous information, ignored during import.
Maximum number  of states	N/A	Yes	OK, superfluous information, ignored during import.
Maximum number  of items	N/A	Yes	OK, superfluous information, ignored during import.
Data compression	No	No	(See note.)
State codes Replace state codes	No	No	(Use of letters instead of numbers for character states; use is not recommended for DELTA programs, see note.)
Input file =  Include file	Yes	N/A	During import, up to 3 files which can be specified directly. Any file referenced in these files using the "Input file" directive is added to this list. All files are treated as a single stream of data, it does not matter to DeltaAccess where which information is stored. Only few restrictions on the sequence of directives exist (much less than in the definition of the DELTA format).
Input delta file	N/A	N/A	(Like Input file, but searches the Confor directory; not applicable to DeltaAccess.)
Previous input file	N/A	N/A	(Return to previous file from which the include file was called; this directive is the default at end of an include file.)
End	N/A	N/A	(Stop processing; default at end of file. Ignored during import.)
Accept duplicate values	N/A	N/A	(Editing tool of Confor, not applicable to DeltaAccess.)
Data buffer size	N/A	N/A	Internal command for Dallwitz's Confor program.
Special storage	N/A	Yes	Internal command for Dallwitz's Confor program.
Error file	N/A	N/A	Error checking command of Dallwitz's Confor program, not applicable to DeltaAccess.
Show	N/A	Yes	(Text printed in Confor's error and listing files. Ignored during import, but supplied in export file.)
Data listing No data listing	N/A	N/A	Error checking command of Dallwitz's Confor program, not applicable to DeltaAccess
List characters List heading List items Listing file	N/A	N/A	Error checking commands of Dallwitz's Confor program, not applicable to DeltaAccess.
Stop after item	N/A	N/A	(Not applicable; meaningful only for programs using DELTA files as their primary data repository, instead of importing them like DeltaAccess. To ignore certain items use the Exclude Items directives instead, see Item subsets.)
Print all characters	N/A	N/A	(Overrides subset definition with Include/Exclude characters.)
Print summary	N/A	N/A	(A form of data analysis performed by Dallwitz's Confor program. Compare the section on Data analysis.)
Print character list Print comment Print file Print heading Print item descriptions Print item names Print uncoded characters	N/A	N/A	(Compare the export functions of DeltaAccess.)
Print width	No	No	(Export fixed to 75, could be supported if necessary.)
Insert implicit values	N/A	N/A	Action command, not evaluated during import, but available in DeltaAccess as an action query.
Vocabulary	No***	N/A	The current versions of DeltaAccess are English-only. Preparations for multilingual data sets are already being made. The Vocabulary directive will be implemented at that point.
Overview over limitations    [image] Appendix 2: Table of contents    [image] Main table of contents    [image] Next


 Recognized DELTA directives: Legend and Notes

Legend:

N/A = not applicable to the design of DeltaAccess (superfluous information, action commands for Confor which are specific to its command line interface, etc.).

Yes* = (in the export column) new directives defined by DeltaAccess. They are exported with the setting "DELTA text file", but not with "Strict DELTA" (the latter provides compatibility with Confor, which crashes when encountering directives not defined by itself). See also the chapter Variants of the DELTA format.

No*** (boldface with 3 asterisks) = Not yet; implementation has already started

Notes: The documentation of DELTA does not distinguish between directives containing data or formatting information, and commands which control the actions of the programs in Dallwitz's suite of DELTA programs (Confor, Delfor, Intkey). This would be very desirable for a standardization of DELTA. The entry N/A in the table below indicates that a feature is not applicable to the way DeltaAccess handles the data. These are program specific directives of Dallwitz's DELTA suite, which are not needed in DeltaAccess. The list of directives is not complete. I am still working through Dallwitz's DELTA documentation to see which directives are commands for Confor inapplicable to DeltaAccess and which directive contain generally valuable information. Please notify me about any directive you are missing.

The directive table is currently not well sorted (***), I will organize it into topical sections in the future. An alphabetical list of directives can be found in the windows help version of the documentation under DELTA directives by opening the index on DELTA directives.

Overview over limitations    [image] Appendix 2: Table of contents    [image] Main table of contents    [image] Next


Limitations to be removed
 The following limitations will hopefully be removed in a future release:

(if enough people are interested in DeltaAccess to make it worth while ...)

•	Not all directives are currently supported, compare the previous table.

•	The most important data related directives missing are all image directives (Character Images/Item Images). Some work on them is already done, but they are not imported exported and largely untested. They will be included in the next release. Similarly the directive Character for taxon images is not tested yet.

•	KeyStates are currently imported and exported as text only. No further editing support is given. Thus, your data will remain preserved, but no functionality is offered. The next version will implement separate data structures for KeyStates, compare Mapping character states.

•	The Identify dialog box is currently only a preview. After the implementation of KeyStates and Images, Identify will be finalized. Separate data structures have to be introduced, which have to be updated in a compilation process. The sum of all queries necessary to support of KeyStates, implicit values, implicit U-values (i.e., all characters not used for an item), and an evaluation of character differentiation power would be too slow to be used in real time on the current data.

•	Partial imports are currently not supported, i. e. you must import/export all data of a descriptor project, including files containing character notes, images, etc., in a single import action. Note that the Input file directive is supported, which allows you to import metafiles with include statements.

•	Multi-item taxa (automatic carry-over of characters to items denoted by "#+" delimiter) are not supported. I would like to import such data in the future, although I think that this concept offers only a limited method to record variation within taxa. I prefer a clean method of summarizing data recorded from different sources (e. g., different literature references or voucher specimens), which are unambiguously linked in the database to their references or specimen units.

•	A problem I feel I have not solved satisfactorily is the mixing of comments and character states, which some people use. Especially the TAXASOFT style seems to be rather incompatible with the DELTA standard: 1<comment 1>,1<comment 2>/3<comment 3>/<comment 4>6/<comment 5>9-10<comment 6>. I already use the piping symbol "|" to allow during output to pipe the CS into Notes if desired:

This is clearly not entirely adequate. In general, "fine tuned" data sets, optimized for natural language descriptions will suffer. Pankey-like data sets generated with a structured approach in mind, or data sets suitable for Intkey (interactive identification) should fare better. I would also like to add that comments in the item description (i. e. per character/character state) are extremely difficult to translate. A comment that has to be in front of the character state in one language may have to be after it in another language. In general, if you are using a lot of comments/notes among the character state descriptions, you should consider revising your character definitions.

If you have any ideas how to improve the parsing please tell me. I have been thinking about some heuristics, e. g., assuming that preceding comments in "()" really belong to the previous item, but that is difficult to verify and implement. The parsing and strict association of CS and Notes on the other hand is absolutely necessary to make DELTA data database compatible.

Overview over limitations    [image] Appendix 2: Table of contents    [image] Main table of contents    [image] Next


Problematic limitations
 The following limitations are problematic, but I think they should not be removed to make DELTA more structured:

•	A mixed usage of '/' and '&' operators (i. e. OR and AND, respectively) within a character is not directly supported. The '-' operator can be used in conjunction with either '/' or '&' for OM type characters, but only single for UM type characters. In general, each character has a global between states operator defined in the attribute multistate type. If you want to mix operators you have two options:

a) Instead of using the '&' operator you should consider adding additional combined character states to the character definition. If the color of an insect consist of yellow and black stripes, I would much more prefer to be offered this as a choice during interactive identification, than being asked whether it is either black or yellow, even if the identification process will correctly identify the insect if I only say yellow.

This is exactly what the import procedure will do when it encounters the and-operator (&) together with the or-operator (/). It leaves a combined character state like 1&2 in the data table and adds this state to the list of character states. If you find yourself in a situation where you get very many such states, check whether you did not really want to have all states combined with "and", and used the or-operator only accidentally once or twice. Revise the import file, and re-import it. If only and-operators are present, no combined states are necessary; instead the MultistateType attribute will be set accordingly.

b) You can use an item description Modifier with the Operator attribute set to a value > 0. In the default modifier list modifiers for "and", "or", and "to" are predefined, you only have to add them to those characters where you want to use them. Note that the "to" (= "-") operator for consecutive values of type OM is implicit if MultistateType is set to TO/OR or TO/AND. For UM type characters, import will add the "to" modifier to the list of available modifiers, if the "-" operator is used. For other characters, you have to explicitly enable these modifiers for the character first. If you use modifiers, the sequence of character states becomes relevant. Although most database routines will assume that character states are commutative, i. e. the sequence is irrelevant, you can manipulate it, and natural language output will adhere to the defined sequence.) This method gives you almost all the freedom you used to have in DELTA. The major exception is that '34,2/1-2' is not supported, you would have to be able to add the character state '2' twice, and each character state can be added but once. This last problem is the only one, which I feel real concern about. You can solve it by using method a), i. e. create a new combined character state, but this is not recognized during import.

•	DELTA supports constructs like "1-2/1/2" for categorical characters (UM/OM). In DeltaAccess character states must be unique, therefore this is not possible. In terms of strict logic, 1-2/1/2 is a superfluous, and 1-2/1 (i. e. but not 2) impossible construct. For many characters nobody will in fact use these constructs: 1 to 2 or 2 bristles is clearly illogical. Even the example in the DELTA example-data set: "Poa: glumes of female-fertile spikelets are more or less equal or very unequal to more or less equal (nearly always subequal' with the G1 somewhat shorter)" appears to be quite constructed. The reason why constructs like '1-2/1' appear nevertheless in DELTA data sets (except for coding errors) is that sometime 1-2 means not '1 or 2 or in between', but 'in between 1 or 2, but neither 1 nor 2'. For example 'red-brown or brown' could be understood in such a way. Note that already light brown to black or black sounds quite illogical again. The restriction which leads to this problem could be removed, but the lack of uniqueness of character states would make many analysis and queries much more difficult to construct (and also much slower to execute). I therefore prefer to keep the restriction and ask people using this to create an extra character state for intermediate states which are distinct from either of the 'parent'-states.

•	Multiple values for statistics of numeric characters (character type IN/RN) are not supported. They will be imported, but only the first group of attributes is imported as numbers, the remaining information is written into the Notes attribute. Technically it would be possible to support it, but it would make the information model more complicated and I consider it logically undesirable. I rather propose to exclude such use from DELTA, since although they are supported in Confor, they are not documented in the manuals up to version 3.

Having multiple means or modes implies that the distribution of the measurement variable is multimodal, which is very hard to analyze. Although modes and extreme values can be defined, means, ranges, standard deviation, etc. are undefined. There is no statistically meaningful interpretation of multiple modes for a single item (unless you are thinking in terms of performing an ANOVA...). Analytically, multimodal distributions are usually the result of not differentiating objects, which in reality should be treated as two distinct objects. For example, if organism size is multimodal, this could be the result of not distinguishing between male and female organisms, or organisms of different distinct age classes.

Probably the most frequent use of multiple values for statistics of numeric characters results from the way many people code a genus when they intend to construct a key for the generic level alone. A genus might consist of species with different, distinct distributions. It might in fact be advantageous to define a character for a genus as, e. g., '12-15 or 30-45'. This indicates that although the character is quite variable for the whole of the genus, no species falls into the range of 16-29. I suggest in these cases to add the genus as two separate items, and using comments to annotate to which subgroup of the genus the measurements in question actually belong.

Joseph H. Kirkbride, Jr., supplied another example for filament length in flowers of heterostylous species, where he coded the long and the short filaments as multiple values of character type RN (e. g. 0.2-0.4/1.1-1.8). This is fully satisfactorily if the aim is primarily to produce natural language output. In the long run I think it is undesirable to code data in this way, because it creates problems in the analysis of data. Even a simple calculation of average filament length would give a confusing result, and proper similarity or relationship analysis would be impossible because in fact different things would be compared. A preferable way to code heterostyly would be:

#1. Flowers heterostylous (type: UM, MultistateType exclusive)
state 1: Homostylous (Inapplicable: 3 and 4)
state 2: Heterostylous, bistylous (Inapplicable: 3)
state 3: Heterostylous, tristylous
#2. length of normal or short filaments (type RN)
#3. length of intermediate filaments (type RN)
#4. length of long filaments (type RN)

A final example are spores, which indeed have only 1, 3, or 5 septa because the septation occurs always symmetrically. Thus if a spore can have 1 or 3 septa, 1-3 is not as appropriate as 1/3. Strictly speaking, no average can be calculated from such values, although this might seem justifiable. A calculation of variance is definitely statistically meaningless. The character is in fact not of IN, but of OM type.

Do argue if you disagree, I am open to criticism. The only point, which I will not follow, is that everything, which is possible in a book, should be possible in structured data storage. Both media will have advantages and disadvantages, even in the best of all worlds...

Overview over limitations    [image] Appendix 2: Table of contents    [image] Main table of contents    [image] Next


Limitations probably not removed
 Removing the following limitations is either not planned or has low priority:

•	DELTA allows the special states U/V/- for text characters. It would be possible to support this, but would make the user interface and the integrity rules considerably more difficult. I currently do not consider this very important. The import will translate these states into full text (i. e. "U" -> unknown, "V" -> variable, and "-" -> not applicable). If you want to code this kind of information, simply enter these words as text. I appreciate your comments about this.

•	Some directives are converted during import. This applies to the Applicable directive, which will always be converted into Inapplicable and exported such, the weights directives (although the conversion can be eliminated, DeltaAccess will always internally assume that you are using abundance/reliability values). Taxon images will be converted to a new character state and exported using the Character for Taxon images directive. The EOM/EUM character states will be translated into the new MultistateType directive.

•	Currently only DELTA as described in the "User's Guide to the DELTA System", version 4.02 is supported. Some proposed new DELTA extensions are supported, most are not. It will always be possible to export DELTA files maintained in DeltaAccess or other databases into Confor for key or natural language description output, but some new features ("free-text-format") of new DELTA are not very compatible with structured databases, and fine-tuned data using these options may suffer upon import into DeltaAccess. On the other hand, many things, which can be adequately described in a database, are not provided for in the DELTA format. I see many advantages of a more structured approach. Firstly you can link your own data directly into databases of nomenclature, literature references, specimen, or geographical places. You do not have to copy these data, convert them, and maintain them yourself. Secondly I see the possibility to deal with much larger volumes of data than classical monographs, in world-wide collaborations with distributed data (each researcher maintains and improves his or her own data sets) which can be queried across country or language gaps nevertheless. Using electronic publications, the authorship of each piece of information could remain unambiguous, despite the free exchange of data. -- I am open to all suggestions how to bridge the gap, but I will not change DeltaAccess into a 1:1 replicate of DELTA-data and restrict the use to a programming language/formatting marks context. I am not saying this is a wrong approach altogether. Right now I am using a word-processor which handles data in exactly this way. Only: a word-processor is a very poor database!

•	A hierarchy of character dependencies (which is defined in M. Dallwitz's DELTA manual and supported by Confor) is not interpreted. A hierarchy of dependent characters means that if the controlling character is itself inapplicable, the characters controlled by this character will automatically be inapplicable as well. Such a hierarchy is a convenient feature, but difficult to implement. Thus, to fully use DeltaAccess, the dependency scheme in your character definition may have to be changed such that the first controlling character includes all dependent characters and does not rely on such a hierarchy. This should have no influence on the interaction with other DELTA programs.

•	Neither line number nor DELTA files compressed with the Data compression directive are supported. You can use, e. g., Confor from M. Dallwitz's DELTA package to remove line numbers or compression.

•	Character states (except U/V/-) must be identified by numbers. M. Dallwitz’s Confor program allows to use single letters instead of numbers (directive State codes), but the use of them is discouraged. Use the Confor directive Replace state codes before you import your data to DeltaAccess. If you use data looking like 1,A/C/X 2,B 3,X you have to convert them before you can not import them, while data like 1,1/3/6 2,U, 3,- are OK.

•	The DELTA equivalent of an empty string ("<>") is converted to Null (i. e. nothing, an empty value) during import. Thus the import "2,1 3<> 4,2<>" will be exported as "2,1 4,2".

•	The proprietary TED/DELTA formatting codes (e. g., [i text ]) are not supported. The new Delta programs from CSIRO use RTF instead, and a converter is provided to convert these codes to RTF. See also the respective developer note.

In the following points DeltaAccess handles the data in a different way, while providing a similar functionality:

*** Critical discussion, what still does not work is: Character1<comment>,1. This would result in Character1,1<comment> in the export, while Character1<comment>,1<comment2> is preserved.

•	DELTA allows that any character can behave like a text character (i. e. without a ",") if this seems to be appropriate for a certain item. For example, in M. Dallwitz's example data set the UM type character 13 is used as: "... 12,2 13<of pseudospikelets...> 14,1 ...". To handle this case, the special character state 'TE' is used not only for text characters, but for categorical characters (UM/OM) as well. You do have to define it specifically for one character, to enable the use of this feature. I consider this restriction desirable, because whenever you replace a coded character state with a descriptive text you loose a lot of information in analysis and interactive identification, though not in the natural language description. Select the option "Add option to use text instead of CS" from the "add character states" pick list on top of the character state table of the character definition form to enable this feature for certain characters. If you import existing data, it will be automatically enabled for all characters using it already. During analysis and identification the U/V/TE-states are treated identical.

•	A related problem is that although allow item specific comments for each character state are allowed, there is no way to store comments directly linked to the character itself. These are normally joined with the first character state, if there is one. Mike Dallwitz's Confor natural language export would translated comments that immediately follow the character number without parentheses, while character state comments after a character state appear in parenthesis. E. Gouda has further implemented the use of character state comments before character states as well as after; this is not defined in the standard DELTA definition, although similar things are planned for the next version.

•	DeltaAccess will treat the character comment of categorical character (UM/OM) as if it would have appeared after the ",", i. e. 1<note 1>,3/5<note 2> is treated as 1,<note 1>3/5<note 2> (which does not really exist in DELTA version 3). I will try to fix this problem as much as possible, without actually changing the data structure. Please mail excerpts of DELTA code and the expected natural language to me if you find cases where it works badly. I do not want to change the information model, because it would only help for DELTA version 3, but neither for the TAXASOFT dialect of DELTA nor the planned version 4.

•	I found that in practice the comment after the character is most often used as a modifier of the following character state. This is clearly an unsatisfactorily situation, since this can only be done for the first character states of the multiple states possible. The introduction of the modifier concept in DeltaAccess improves the usability of DELTA drastically, without sacrificing the compatibility with structured data storage (as I suspect DELTA version 4 does).

•	Note that since modifiers are not part of the concept of DELTA yet, I currently do not export the modifiers themselves, but convert them back to comments. This is only a temporary solution, I hope that I can work out together with M. Dallwitz and other people developing DELTA a way how these structures could be properly supported in DELTA. It is difficult to add new directives to the DELTA definition, because you have to manually remove them before, e. g., M. Dallwitz's Confor will accept the data set. Although you can use a program like Delfor for this purpose, I think that most people will not find it acceptable to have to go through these extra steps. Please contradict, if you think otherwise; perhaps I think so only because I would not know how to do it using Delfor :-).

•	The current situation is that you should not use the DELTA text format as your primary backup medium, unless you are willing to live with some problems during the conversion of concepts. I recommend to use the backup and restore functions of DeltaAccess instead. You can export to, e. g., Confor or Pankey to produce a natural language description or a key nevertheless.

•	I appreciate your comments on the current situation and examples where the conversion works unsatisfactorily. I currently resent fully supporting this difference, since I think even if I would introduce an additional table layer, which would slow down operations, it would not work for the proposed new version of 'DELTA II' anyway.

Further information on these topics can be found in the following chapter Internal information.

Overview over limitations    [image] Appendix 2: Table of contents    [image] Main table of contents    [image] Next


 General development information

	Who should read this: People interested in a discussion about design decisions and the internal processes of DeltaAccess. People interested in adding functions to DeltaAccess should also read the following chapter Co-development issues. Please refer also to the chapter Strategy and future development of DeltaAccess. Reading this chapter is not necessary for the use of DeltaAccess or Identify.
•	The forms (except for the Identify dialog box) are designed to work on VGA (640 × 480) resolution, mainly to be compatible with notebooks. In general, I consider this resolution not appropriate for Windows, you should have 800 × 600 minimum. Most forms can be manually resized, and some forms resize themselves automatically when they detect a higher resolution.

•	The utility works best when used with data exported from another DELTA application like Confor/Intkey, Pankey, or TAXASOFT. Although some errors possible when hand-coded data are imported, others may produce error messages which are difficult to interpret. I will try to improve on that if you report such situations, but until then you can try whether another program gives more meaningful error messages to help you with your coding errors.

•	Some directives are used synonymously to support different programs and coding errors. Specifically these are: Character list = Character descriptions, Item descriptions = Item list, Dependent characters = Inapplicable characters. The first directive is the one used during export.

•	I think that Items should have a permanent item number, just like characters have a number. Item names are not necessarily unique (Richard Pankhurst assured me that this is not even necessarily the case if the DELTA-comments are included!). The ItemName attribute itself can not be unique, because it must be possible to add data separately for separate specimens of the same taxon, or separate literature references concerning the same taxon. In that light the fact that Mike Dallwitz uses item names (including comments!) as primary key to link Taxon images presents a special difficulty. I think there is a need for some clarification in the DELTA definition. -- Having said this, I should clarify that, to remain compatible with other DELTA programs, I currently do not use the item numbers of DeltaAccess (IID) in import or export. Similar to the other programs, a continuous sequence relative to the current export (which is very cumbersome to do in any kind of database...) is used. Pankey seems to use item numbers judging from some data sets, but Richard Pankhurst confirmed that it only uses numbers as part of the item name, they could possibly be different and are irrelevant in regard to the import process of DELTA files. Thus, if item with number 3 would be in 2nd position, the abundance would be found under 2, not 3! During import, I accept numbers, but will remove them, in export I omit them.

•	Images are currently supported in the database structure, but neither imported nor exported. Images are stored as file names similar to the way they are supported in M. Dallwitz's DELTA package. New feature, not supported in DELTA: Character images may now be linked to a specific character state. Multiple images in DELTA-style and image annotations are imported/exported, but not truly supported! Currently, the Taxon images directive is only supported when item numbers are used, not item names!

•	Images are stored as separate files, not within the database. Although Microsoft Access can handle integrated images, these are difficult to import/export automatically. To work with Intkey, they would have to be written out as files anyway. Further, storing them inside the database uses significantly more space than storing them in separate files. The disadvantage is clearly the absolute path, which makes it difficult to move data into a different directory. It is therefore recommended to use only relative paths, or put the image files into the same directory as the database. A management tool to update paths will be added in a later version!

•	The DELTA definition seems to expect only one character marked as Character for taxon images. I do not enforce this because I think that grouping the images into different characters is useful.

•	M. Dallwitz's TED/DELTA formatting codes (e. g., [i text ]) are currently not supported. If you write a function converting between these codes and RTF/HTML, I will integrate it. Compare the module FTextLib which handles the RTF/HTML formatting, this will give you some start. However, the new Delta programs from CSIRO will no longer use this formatting, so it is probably not worth the time. Mike Dallwitz provides a conversion function to convert the old codes to RTF.

•	Problems with character dependency: a) The DELTA documentation states that the Applicable characters directive is an alternative to the Inapplicable characters or Dependent characters directive. I convert Applicable to Inapplicable, by making the dependent characters inapplicable for the complement of character states for which they were defined applicable. I am not sure whether it is correct to do this, since the logic may differ in the case that the controlling character is not set. Yet, if a difference is intended, the directives could not be exclusive, or? b) hierarchy of dependencies is ignored, see under limitations above. c) TAXASOFT uses ranges in the specifications of controlling character states ("1-2"), while M. Dallwitz's DELTA documentation requires a slash notation ("1/2"). I support both styles during input.

•	The attribute NumStates (number of character states) is not available in the CharEdit form. It is updated internally; no user interaction is necessary.

•	During export I sometimes export character states separately or use a multi-range notation ("1:2:3:4:7") instead of using ranges ("1-4:7"). This is easier to program than ranges and should be compatible with other DELTA programs, although slightly more difficult to read for humans. If you think this is an issue, you are welcome to make the appropriate amendments in the code of the export procedure.

•	Range notations for character states like: '-3' or '2-' (used by TAXASOFT) are converted to '1-3' or '2-<highest defined state>' upon import. They are not supported for numeric data. Since Keystates are currently imported as text only and not interpreted, the use of "-" or "~" is unproblematic there.

•	Text files filled with EOF characters at the end are not supported by DeltaAccess. Such files have a file length setting larger than the actual contents and the additional space is filled with EOF characters. Old DOS programs usually ignored these characters, but Windows programs don't. Since, e. g., old Pankey programs (up to perhaps end of 1995?) might have written such files, you might encounter old DELTA files that have this problem. Microsoft Access can handle such files as binary files, but reading binary files is very slow. I consider files using EOF fill-characters obsolete. Therefore, an error message is issued when such a file is encountered, which asks to manually remove the EOF characters. You have to open the file in a text editor, and delete the EOF characters, which usually turn up as the little boxes or arrows at the end of the file.

•	For a discussion of the rationale to implement multiple descriptor projects in separate sets of tables instead of a "general multi-project descriptor database model", please refer to the chapters The mountain and the pebbles: A global knowledge base versus multiple discrete projects and Information model for multiple projects.

•	Help file: You can merge the specific DeltaAccess help file with the main Microsoft Access help file. To merge the index, remove the ';' in front of the lines starting with ':Index Microsoft Access 97'. You could merge the contents as well by adding an include statement instead of the link at the end of the contents file, but I find that confusing.

•	The application is currently available only in Genglish (what a German considers English) and Germlish (German with untranslated bits). It is basically language independent, but some modifications would be necessary, and the language recompilation engine is not supplied with the current releases of DeltaAccess (it is part of the Minos package to be released in the future). I appreciate any help in translating it to other languages!

Appendix 2: Table of contents    [image] Main table of contents    [image] Next


 Co-development issues

	Who should read this: The following information is only relevant for people considering co-development. Co-development means that you either help in the development of DeltaAccess, or that you develop a separate application which interacts with DeltaAccess. You could help in the testing, as well as in sending me enhancements to be incorporated into a future version of DeltaAccess (compare Conditions of use). Further general development information is given in the previous chapter. Reading this chapter is not necessary for the use of DeltaAccess or Identify.
•	If you just want to help in the development of DeltaAccess, but have not much experience in programming Visual Basic applications, you could help in the testing of new or existing functions. Sending in detailed error reports, or suggestions about improvements to the user interface are quite important to me.

•	I could use a lot of help in testing the documentation. If you are starting using DeltaAccess, it would be very helpful if you could take notes about which information was missing or hard to find in the documentation. If you try to look up keywords in the help index which are not there: please send me a list of what you have been looking for. Further, I could use the help of someone whose native language is English to improving the style of the documentation.

•	DeltaAccess can be translated into multiple languages. If you are willing to help translating it into your local language, please contact me.

•	The easiest place to start co-development is the modification of existing or the creation of new queries or reports. Neither queries nor reports make much use of code. If you have created a generally useful query or report, and have written a documentation why to use it and how to interpret it, please send them in.

•	In exchange for making the full library available (see note on commented source code version), I request that you either do not change the code in the standard (global) modules, or notify me about where, and why you think it must be changed. Changing global modules carries the danger that the code you develop will be incompatible with code in a new version or from other people. Try to use the functions provided in the library modules, esp. in StdLib though.

•	If you want to add a new functionality, try whether you can encapsulate your code in a local form or report module (= vba class module). If you need global functions (e. g. to be used in a query), put them into UsrLib and send me a copy.

•	The VBA code is not always as transparent as I would wish. To read it, you definitely want to download the commented source code version of DeltaAccess. The DELTA format turned out to be so complicated and full of exceptions, that the import code has become complicated in places. If you want to cooperate, I suggest to first leave the import process alone, or look only specifically at certain places, e. g., in the export, which is simpler. The editing forms are simpler and there is a lot of things to improve there, e. g., many error checking SQL queries could be added. Still, the ItemEdit form is one of the most complicated forms I have ever designed (dynamic rearrangement of forms, event-driven code interaction between subform and main form.

•	If you are seriously interested in development, one area I would think useful is a dedicated, fast editor for item descriptions. I think that the current editing tools are quite sufficient and fast enough for occasional changes of the character definition, but clearly the item description editor is somewhat slow (depending on your computer, of course), and it will be the tool used most often. Also, several user interface improvements are conceivable, which would be difficult to implement in Access. The language or tool you are using for such development would be irrelevant, as long as it can work directly on the mdb-tables (using JET or ODBC). This means that DeltaAccess and your program can be used concurrently by a single user on a single PC as well as by multiple users in a local area network. I suggest to consider development in Visual Basic 5, which would allow porting a major part of the code and would integrate seamlessly with DeltaAccess.

•	I will not add any web interface tools myself. If you were interested in such development it would be great. All you really need are the tables to do this. You could start a completely autonomous application, which uses the same data structures that DeltaAccess uses. Do try to use the existing data structures, and not to import data into another information model. If you have a problem with the current information model, it may be worth a discussion to change it for both applications. I think that web interfaces should be on-line applications, not data you always have to recompile. Compare DeltaAccess Perl for existing web interfaces to DeltaAccess.

•	Another item on my list which I probably will not find the time to complete soon are import and export functions to the Nexus format used by phylogenetic analysis applications like PAUP (David Swofford) and PHYLIP (Joe Felsenstein). A separate utility for this, working on the same tables as DeltaAccess, would be very useful.

•	I do not plan to add support for printed dichotomous keys in the near future. It would be nice to have it integrated, but I will not have the time in the foreseeable future. If you are not satisfied with the result you get using, e. g., Dallwitz's Confor program, you are welcome to add tools implementing this feature.

Appendix 2: Table of contents    [image] Main table of contents    [image] Next


 Reporting errors and other feedback

I appreciate any feedback, like error reports, comments on the general design, or suggestions for improvement. Please do not hesitate to contact me in such cases.

This project has become far more complex than I anticipated. Some originally functional features may have become dysfunctional during development, or may not work under certain circumstances. I can not possibly test every functionality each time over and over again. This application is free software and programmed in my spare time. Any help you can give me in finding these things is most welcome.

If you find errors, please try to reproduce them and describe the exact steps one must perform to recreate the error. Perhaps send me the data set or an excerpt which causes the error. If you are concerned about the copyright of the data, you could fingerprint your data set. Please report the version number of DeltaAccess, which is displayed in the copyright notice at the bottom of the DeltaAccess opening dialog box.

Also, I realize that part of this documentation must be reworked. I am grateful for reports of errors in the documentation, if you point out unclear language, or misunderstandings of concepts of other people's work. Please read the chapter problematic limitations of DeltaAccess if you want to comment on design issues.

Regarding suggestions: I am aware of several shortcomings of the current version. I keep a list of suggestions and constantly try to improve the application. Yet, because of limited time, I can not promise to implement even obvious improvements immediately.

Thank you in advance for any help you can give me!

Gregor Hagedorn

Appendix 2: Table of contents    [image] Main table of contents    [image] Next


 Multi-language support

One of the design goals of DeltaAccess is to allow reports in multiple languages from the same database. There are several options to do this. One would be to introduce an explicit layer for all descriptive strings like character / character state names, CharPhrase, etc. This would be the cleanest model and would have the advantage that changes would automatically occur in all language descriptions. I did not use this model, because I assume that most people will work 99% of their time with their preferred language only. The multilanguage support implemented in such a way would very significantly reduce the execution speed of DeltaAccess when executed on a currently common PC. Therefore, the multilanguage support is implemented using a link between the item data of an existing project and the character definition of a new project. The latter is first copied from the original data set and can then be translated.

It is already possible to do this in the current version, although you would have to create the link by hand. The reason that the combination of character data with item link is disabled in the Management section of the DeltaAccess dialog box is that the lack of relational integrity would be confusing or dangerous. You currently can present multilingual views, but are fully responsible to synchronize any changes yourself. This situation is entirely equivalent to keep several chars DELTA text files for multiple languages for use with Confor or Intkey.

In the future I plan to define special secondary language character definitions, which remain fully linked with the primary character definition in your principal language. A special character definition editing form would allow you to edit all linked character definitions in a single view.

The item description notes are currently not part of the translation scheme. I assume that nobody would be willing to constantly translate them into multiple language. You can of course do it in a one-way process like you would have done

Entirely independent of these information model considerations is the fact that the DeltaAccess application is also largely able to adjust the user interface to a different language, but this functionality is not distributed yet. It will be opened up in a later version. Basically it will require a recompilation of the application with a new resource set. Messages, status area messages/tool tips, the descriptions and text in most pick lists, and most captions on the forms can be fully translated. Some parts are very difficult or impossible to translate: Names of objects like tables, queries, forms, and fields in tables. Because of this, I purposely kept these names non-descriptive, abbreviation-like (e. g. "X_DESCR" instead of "item description data", which Access would allow).

The Vocabulary directive will be supported with the first release of a multilingual version of DeltaAccess.

Appendix 2: Table of contents    [image] Main table of contents    [image] Next


Appendix 3: Information model and data dictionary
 DeltaAccess –
a SQL interface to DELTA (Description Language for Taxonomy), implemented in Microsoft Access

Appendix 3: Information model and data dictionary

   The information model of DeltaAccess
   The theoretical item description information model and its simplification
   Information model for multiple projects
   List of entities and attributes
   Detailed attribute information
   Introduction to the concept of modifiers

Appendix 4: References, Glossary

   Literature references
   Glossary of terms and procedures

Previous table of contents    [image] Main table of contents    [image] Next


 The information model of DeltaAccess

The following diagram illustrates the core information model of this implementation. Each box in the graph below represents an entity (= table in the database), the attribute names (= fields of the table) are listed inside the boxes. Bold attributes are the primary key (or part of it, i. e. the combination of all boldface attributes must be unique). The connecting lines indicate the relations. The type of a relation is indicated by the 1 and the infinity symbol ( [image]) at the start and end of the lines. The attribute on the 1-side may occur only once (i.e. it must be unique), while the attribute at the infinity (or "n") side can occur multiple times. All relations are protected by relational integrity rules with cascaded updates. Thus, if the attribute on the 1-side of a relation is changed, the attribute on the n-side is automatically updated to the new value.

(This is a hypergraphic)

The major entities of the character definition are the character entity (X_CHAR) which is linked by the character identifier (CID) with the character state entity (X_CS). The item data are the three entities displayed on the right side. They consist of the item definition (X_ITEM), which contains the item name and additional management information (including information regarding the data source, i.e. Collection Unit [= "specimen"], literature reference including a page or table number (LitRefDetail). The item identifier (IID) is used to link the item with the main item description entities, X_DESCR and X_RSC. Character and character state scores (for character types UM/OM), numerical data (for character types RN/IN) and text (for character type TE) are recorded in the item description entity (X_DESCR). The Resource entity (X_RSC) is used to store external resources like images, illustrations, hyperlinks etc. Such resources can be linked to a character, or even more specifically to a character state. Since multiple resources can exist for each association, the combination of IID, CID, and CS does not provide a primary key in X_RSC (like it did in X_DESCR), and a Resource identifier (RID) is added for internal reasons. It is currently not referenced any further in the information model.

Some additional information: Attributes ending with ID signify a numeric identifier, thus CID is the character ID (= number), IID the item ID. CS is the abbreviation of Character State; it is of type text to allow special states (U/V/-) and numerical/statistical attributes (mean, min, max, s.d., etc.). In X_DESCR, X is a real numeric attribute used only for numeric character types, TXT is a long text attribute used only for text characters, and SEQ is a sequence number to define a sequence of character states in the item description. The rationale and definition of modifiers are discussed in more detail in the following chapter. The use of character and character state definition attributes, and the item definition attributes are explained in the chapters about the character editing form, and the item edit form, respectively.

Perhaps 95% of the functionality of DeltaAccess is based on the core information model above. The full information model is considerably more complex. It adds the concepts of modifiers (X_MOD), headings (X_Char_Heading), and character dependencies (X_DEP). The full information model looks like:

(This is a hypergraphic)

(See major data tables, link tables, and accessory tables for a short explanation of all table names. A complete list of attributes, their type and indexes is supplied in the following chapter: List of entities and attributes.)

[*** DISCUSSION TO BE REVISED, part of material below is from Version 1.2 ***]

The _PROPERTY table is not integrated into the general information model (i.e. it has no relations to other entities). It is used to store internal properties of each descriptor project. Examples are author and copyright of the project data, date of import, version number of the information model, etc. See Editing project properties for more information and an overview of the currently defined properties.

The following accessory tables are not always present: X_ID_DESCR and X_ID_TXT are created only after the data set has been compiled for identification purposes. X_CHAR_Subset exists only for projects with a character subset (i.e. the character definition is based on another project, but only selected characters are visible).

Details of the information model: The Modifier and Character Heading structure

(This is a hypergraphic)

[*** MAKE Separate topics, + ADD back links from attribute to this discussion!]

Character Headings (X_CHAR_Heading and X_CHAR_Heading_Link)

Confor and IntKey use 3 different heading directives: Character Heading, Item Subheading, and Character Definition.

A Character Heading is a heading to a group of characters. It is used when the character definition is presented. Analogous item headings are not defined in DELTA. The term Item Subheading used by DELTA is somewhat deceptive, although the prefix "sub" tries to indicate the difference. Item Subheadings are headings to a group of characters in the natural language descriptions of each item.

Thus, Character Headings are used together with CharNames, while Item Subheadings are used together with CharPhrase in natural language descriptions. Both heading types are combined in the current information model. The HeadingName is the primary attribute. The optional HeadingPhrase attribute is preferred when Item Subheadings are output in natural language descriptions. If no HeadingPhrase is defined, the HeadingName is used here as well.

The association between characters and headings is defined in the relation between the character definition attributes CharHeading and ItemSubheading and the character heading definition attribute HID. Each character can have at most one heading defined for character definition output and one heading for natural language item descriptions (1:n relation).

A further header type is Character Definition. It is defined as an Intkey-directive in the Intkey.ini file. Character Definitions are called Named character groups in DeltaAccess. They are primarily used during interactive identification to restrict the number of character from which the user must choose. A complete list of perhaps several hundred characters would be cumbersome and confusing to use during identification. Instead, users can select from a list of Named character groups. In contrast to Character Headings and Item Subheadings, a single character can be a member of multiple Named character groups, which may be defined under different aspects, e. g., by organ of the organism, by observation or analysis method, or by developmental stage.

The association between characters and headings used as Named character groups is defined in the relation between the character definition attribute CID, the character heading definition attribute HID, and the link table _CHAR_Heading_Link (n:m relation).

[*** MODIFIERS: DISCUSSION TO BE WRITTEN IN NEXT VERSION ***]

The rationale and definition of modifiers are discussed in more detail in the following chapter Introduction to the concept of modifiers.

Details of the information model: The Character Dependency (DEP) structure

(This is a hypergraphic)

Character dependency describes relations between characters. The only relation defined in DELTA is that a character (which may be of any type) may become applicable or inapplicable, depending on the presence of a certain state in another categorical character. The latter character is called the controlling character. Theoretically, it would be possible define dependencies where the controlling character is numeric, but appropriate situation are exceedingly rare in practice. Supporting numeric controlling characters would require significantly different additional data structures. Therefore, neither standard DELTA nor DeltaAccess allow to make a character inapplicable, if a numeric character does or does not exceed a certain value.

The additional entity DEP links through CID and CS to the character state which is the controlling state of the controlling character. Dependent from this state are all characters linked through the Inapplicable CID attribute. Only inapplicable characters are directly supported. DELTA allows an alternative statement of making a character applicable only if a certain state is present. This statement is identical with this character being inapplicable if the other states of the controlling character are present. DeltaAccess makes appropriate conversions during import.

The structure used is similar to the BAOBAB model proposed by White & al. (1993), except for the fact that DeltaAccess defines inapplicable dependent characters, while their model defines character explicitly as applicable. While this inverse definition is equivalent as long as all controlling characters have been scored, different problems arise if the controlling character is undefined.

A special problem of this simple structure occurs if a recursive definition of character dependency is used. Recursive character dependency are allowed in the DELTA definition (Dallwitz & al. 1993). They occur, if the controlling state of a character may become inapplicable depending on yet another controlling character. A short example should illustrate this:

Controlling character	Controlling character state	Inapplicable character
Leaves (presence)	absent	Petioles
Petioles	absent	Petioles (hairiness)
Petioles (hairiness)	not hairy	Petioles (hair length)
Leaves (presence)	absent	Leaves (compound or not)
Leaves (simple or compound)	simple	Leaflet petioles
Leaflet petioles	absent	Leaflet petioles (hairiness)
Leaflet petioles (hairiness)	not hairy	Leaflet petioles (hair length)
Starting with the question of whether leaves are present, two chains of inapplicable characters are illustrated in the example. If leaves are absent, all characters listed in the right hand column become automatically inapplicable, even though the state immediately controlling them is not scored.

Thus, although the data model is perfectly capable of storing the information presented in the example, evaluating it in the application becomes considerably complicated. It is not possible to use simple SQL queries for such recursive evaluations. The current version of DeltaAccess therefore does not yet observe recursive (or "indirect") character dependency definitions. In practice, this can be overcome by making "Petioles (hairiness)", "Petioles (hair length)", etc. directly dependent on "Leaves (presence)". Naturally, this is less convenient and more error prone.

Other notes on the information model:

The model uses natural keys, many indexes (the data are not transactional but comparatively static), and collapses 1:1 relations (exclusive-or subtype structures) into a single table with alternatively used attributes. The net effect is that storage considerations (other information models could require less storage space) are sacrificed for speed gains. This decision is not based on the current size of DELTA data sets. In fact, I would expect much larger data sets to be created with DeltaAccess than are currently possible using Dallwitz's Confor. Rather, I consider the increase in storage space moderate, and storage space has become cheap. The decision to include even a moderate amount of illustrations in your data set is likely to have a much larger impact on the size of the data set, than any information model design decisions.

The decision to use the natural combination of CID and CS as primary key instead of an artificial primary ID key (e. g. counter attribute) to the _CS entity, but has several advantages, but some disadvantages as well. Referring to a single foreign key in the _DESCR entity instead of the combination of CID and CS would reduce the storage consumption of _DESCR, and allow a more direct query during identifications. Since both approaches can be converted into each other without any information loss, the choice between these options is assumed to be an implementation specific decision.

The use of natural keys does rely heavily on referential integrity with cascaded updates and deletes. It should not be used on any databases engine not supporting these features.

At several points a n:m relation was taken into consideration, e. g., for the character states. Many character states are identical across characters, especially the universal numerical statistic attributes and Unknown/Variable/Not-applicable, but also generic attributes like present/absent, colors, etc. The reason not to use n:m relations is, besides simplicity, that in one language it may be satisfactorily to say '... present' and '... absent', but in another language a different wording may be necessary for some characters but not for others. Duplicating the information right from the start makes it more difficult to change the wording for present/absent characters in the whole database (which I consider a rare event), but avoids problems during the translation. In the future special translation tools will be made available, which can do automatic updates of all identically phrased character states. The implications of the planned multilanguage support on the information model are further discussed in a chapter further below.

See also the following chapter Discussion of the theoretical item description information model and its simplification.

Appendix 3: Table of Contents    [image] Main table of contents    [image] Next


 The theoretical item description information model and its simplification

	Who should read this: This chapter is exclusively addressed to people with a theoretical interest in information model of descriptor databases.
While character and item definition are straightforward and fully normalized, the item description part (_DESCR table) is slightly denormalized. The item description part of the theoretical information model would be more complex (modifier, dependency and illustration parts are removed to simplify the example):

(This is a hypergraphic)

A separate entity could exist for each for each character defined for an item (X_DESCR, CID/IID links), to which an entity for the text data is linked 1:1, and separate entities for numeric and categorical data are linked 1:n. The use of these tables would be exclusive, i. e. which entity could be linked would depend on the character type defined in X_CHAR. X_DESCR would contain only foreign keys plus a notes field which is not really used like that in DELTA (the notes directly after the character behave not like notes after character states, but rather like a TEXT character). The only advantage would be that the rule "only one entry per IID/CID combination" would be enforced on the database engine level. Since this solution requires frequent joins and, worse, slow union queries, I have not followed that path.

Instead, the X_DESCR entities are merged. The Jet database engine of Microsoft Access handles empty attributes extremely well (text attributes use a single byte storage space per record, and the indexes can be defined to ignore all unused values). Instead of implementing rules that only one of the additional entities X_DESCR_CAT, X_DESCR_NUM, or X_DESCR_TXT may be joined, the attributes themselves are declared exclusive. A database engine level rule defines that the attribute TXT may only be used when the CS is TE, that the use of X and TXT is exclusive, and that X may not be used for numeric CS. On the engine level, this allows only very few unwanted entries in X (e. g., when CS is '1&2'), which has to be prevented on the level of the editing forms. Note that the merging of the DESCR entities is an implementation specific decision, which has no influence on the data collected. Data are fully convertible between both information models if all described integrity rules are observed.

As a further internal decision, the use of a default character state TE is enforced for text data. The only reason to do this is that referential integrity can then be activated for all character states. This is only possible if CS in X_DESCR is required and part of the primary key. Referential integrity with cascaded updates makes using the database much safer and easier. It means that if you change character state '3' to '4' in the character definition table X_CS, all data in the item description will automatically be changed. This is enforced on the database engine level and will therefore work in queries as well as in the editing forms.

A possible abnormality of the entities as implemented in DeltaAccess, is that it is possible to enter records for characters of text or numeric character types, without a text or numeric value, respectively. This must be taken into account when creating analysis queries. It is not a flaw of the information model though, but in fact an inherent property of DELTA, which allows text and numeric comments without requiring a value.

Appendix 3: Table of Contents    [image] Main table of contents    [image] Next


Information model for multiple projects
 Information model for multiple descriptor projects

	Who should read this: This chapter is exclusively addressed to people with a theoretical interest in information model of descriptor databases.
As discussed in the introduction The mountain and the pebbles: A global knowledge base versus multiple discrete projects, a descriptor database should be capable of handling multiple independent descriptor projects as well as multiple related descriptor projects. The implementation details of multiple independent projects is discussed in this chapter, the latter are discussed in the chapters on linked projects and subsets.

Two options are available to implement a multiple project descriptor database:

1.	Create a full set of tables for each project, letting the database engine handle the management of projects. Each set of tables has the same structure, but the table names are prefixed by a project identifier.

2.	Add an additional project identifier to the information model. In the current model, a project identifier would be required at least in the CHAR, ITEM, and PROPERTY entities. A project identifier is not absolutely necessary in the CHAR_Heading entity, but it would probably be useful to get an overview over all headings of a project. All other entities are linked with these entities that the project can be uniquely identified. The primary key of CHAR and ITEM would be a composite index based on the project identifier and the CID and IID, respectively.

The second approach is the preferred one, used, e. g., by PANDORA and TreeBase. PANDORA implements all descriptors in a single set of tables, to which a ***Pandora uses which term //handout Paris, DeltaNewsletter*** and uses composite indexes, called "****". TreeBase is a cooperative project sponsored by NSF, Harvard University Herbaria and University of California, Davis (see www.herbaria.harvard.edu /treebase/schema.html, seen 13.3.98). As far as can be deduced from the documentation published on the web, the characters are organized into multiple character matrices (Matrix entity), which are then linked by a MatrixTaxa entity with Taxa itself.

In contrast, DeltaAccess uses the first approach, creating a new set of tables for each project. This is done exclusively for practical reasons. The decision is based on the assumption that almost never a cross-project analysis will be performed (which would require a union query in the information model used by DeltaAccess. Letting the database engine handle the project management has two advantages. Firstly, a significant performance gain is achieved, since the engine organizes physical data storage and indexes by project. Secondly, it is possible to use queries ("views") in place of the tables to create projects that are partially or fully linked to other projects, with or without a subset condition. The feature to use dynamically updateable item or character subsets is unique to DeltaAccess, and very important if larger, cooperative projects are attempted.

It should be noted that the decision two use the first option on the client side in DeltaAccess does not preclude a different decision on the server side, if DeltaAccess is used in a combination with a SQL server. The server tables can be organized following the second option, adding a project identifier. To then link projects into DeltaAccess, one simply has to create a set of queries/views, analogous to linking tables, which contain a WHERE condition restriction the view to a single project. If the server allows updateable queries/views, the queries should be created on the server side. Otherwise they should be created within DeltaAccess.

Appendix 3: Table of Contents    [image] Main table of contents    [image] Next


 Data dictionary

	The data dictionary is part of the documentation of the information model. It contains a list of table or entity names, an overview list of entities with attributes, and a list of detailed description of most attributes. The overview table is largely identical with the documentation which Microsoft Access would provide if a table is opened in design mode
Appendix 3: Table of Contents    [image] Main table of contents    [image] Next


Table Names
Table names: Most of the project data reside in a set of 9 tables (see also the
overviews of link tables for n:m relations and accessory tables). In a project named 'X',
the main tables would be:

	X_CHAR	definition of characters themselves,
	X_CHAR_Heading	definition of character headings (including item subheadings, identification groups),
	X_CHAR	definition of characters themselves,
	X_CS	definition of character states,
	X_MOD	the basic, project wide definition of modifiers,
	X_DEP	list of characters dependent of controlling character state,
	X_ITEM	item definition, esp. names,
	X_DESCR	descriptions/data for each item, and
	X_RSC	definition of media resources, esp. illustrations for characters, character states, or items


Link Table Names
Link tables: A few additional tables provide links in the case of n:m relations.
These are necessary for technical purposes of the information model alone:

	X_CHAR_Heading_Link	definition of character groups for identification, each character may be member of several identification headings
	X_MOD_Link	the character specific association between modifiers and characters


Other Table Names
Accessory tables: (some are not always present)

	X_PROPERTY	Project wide information, like author, copyright, import file/date, see Editing project properties
	X_ID_DESCR	Exists only after project is compiled for identification; special version of X_DESCR
	X_ID_TXT, X_ID_Notes	Like X_ID_DESCR above; contain word-wise index for text (TXT attribute of _DESCR) and Notes, respectively
	X_CHAR_Subset	Exists only for character subsets.: CIDs defining the subset


List of entities and attributes
 List of entities and attributes    Go to: Main entities  Accessory tables  Link tables

The following table contains the entities of the information model and their attributes. For further information not present in this overview (e.g. default value, lookup definition, validation rules) you can open the tables in design mode in Microsoft Access. Use the entity overviews in the header of this topic to jump directly to specific entity description.

_ITEM	Name	Type	Size	Description
Attributes	IID	Number (Long)	4	Item ID
	ItemName	Text	255	Name or description of item (incl. taxon authors if necessary), link to taxonomic subsystem
	Notes	Memo	-	Item notes
	Abundance	Number (Single)	4	Abundance, relative importance (or weight) of item, 1-10, default is 5
	CollUnit	Text	255	Unit code in specimen collection, link into collection subsystem. NOT DEFINED IN DELTA!
	LitRef	Text	255	Literature reference (user-readable text form). NOT DEFINED IN DELTA!
	LitKey	Number (Long)	4	Literature reference (numeric link into literature reference subsystem). NOT DEFINED IN DELTA!
	LitRefDetail	Text	255	Reference detail, like page(s) of interest, specific figures, etc.
Indexes	Abundance	Abundance, Ascending
	CollUnit	CollUnit, Ascending		Ignore Nulls
	IID	IID, Ascending		Primary key
	ItemName	ItemName, Asc.
	LitKey	LitKey, Ascending		Ignore Nulls
	LitRef	LitRef, Ascending		Ignore Nulls
_DESCR	Name	Type	Size	Description
Attributes	IID	Number (Long)	4	Item ID
	CID	Number (Integer)	2	Character ID
	CS	Text	16	Character state of characters with defined character states
	Modifier	Text	255	Modifier phrase for categorical or numerical data, e.g. "mostly", "usually", "rarely"
	X	Number (Double)	8	Numeric value, defined by CS
	TXT	Memo	-	Text data
	Notes	Memo	-	Internal notes
	SEQ	Number (Long)	4	Sequence of character states for the item
Indexes	CID	CID, Ascending
	CS	CS, Ascending
	IID	IID, Ascending CID, Ascending CS, Ascending		Primary key
	SEQ	SEQ, Ascending
	X	X, Ascending		Ignore Nulls
_RSC	Name	Type	Size	Description
Attributes	IID	Number (Long)	4	ID of associated item (optional)
	CID	Number (Integer)	2	ID of associated character (optional)
	CS	Text	16	ID of associated character state (set to U or TE for text characters if resource belongs to char. in general)
	Resource	Text	255	Filename of illustration (photo/drawing/graph) or other media resources. See _HEADING properties MediaDefaultPath/MediaDefaultURL to set global paths
	Caption	Memo	-	Caption for the resource, e.g. a text to display while showing an illustration or a video
	Notes	Memo	-	Internal notes (perhaps also formatting commands for IntKey)
	ItemDefault	Yes/No	1	This image is a default image for the whole item, regardless of character association
	CharDefault	Yes/No	1	This image is a default image for the whole character, regardless of character state association
	MID	AutoNumber (Long)		Media ID (necessary, because either IID or CID may be missing)
Indexes	IID	IID, Ascending		Ignore Nulls
	CID	CID, Ascending		Ignore Nulls
	CS	CS, Ascending		Ignore Nulls
	Resource	Resource, Asc.
	MID	MID, Ascending		Primary key
_CHAR	Name	Type	Size	Description
Attributes	CID	Number (Integer)	2	Character ID
	CharName	Text	255	Name or description of character
	Unit	Text	255	If the character is textual or numeric, an optional measurement unit may be given here
	Notes	Memo	-	Character notes
	Type	Text	2	Type of character: Text, Ordered/unordered multistate, Integer/Real numeric, Picture/Illustration
	Mandatory	Yes/No	1	Setting this character is mandatory (required)
	MultiStateType	Number (Byte)	1	Are multiple states allowed and how are they interpreted?
	Reliability	Number (Single)	4	Reliability (or weight) of character for identification, 1-10, default is 5
	Availability	Number (Single)	4	Availability (or accessibility) of character for identification, 1-10, default is 5. This is an extension to the Delta standard.
	Fuzziness	Number (Single)	4	For identification: Item descriptions where only a single value (e.g. mean) is given are converted to ranges using this value (RN/IN/OM only)
	Fuzziness IsPercent	Yes/No	1	'Fuzziness' is a percent value (e.g. Fuzziness=10 -> Range=mean +/- 10% instead of +/- 10)
	KeyStates	Text	255	For use in a key: combine multistate char, into new combinations or define ranges for numeric char.
	NumStates	Number (Integer)	2	Number of states for this character, default is 2
	CharPhrase	Text	255	Wording to be used instead of CharName for natural language descriptions output, incl. special Delta formatting
	FormatString	Text	255	Define the formatting, esp. for numeric values (number of decimal places etc.). Standard Access formatting string
	OmitValues	Text	1	Natural language descript.: Omit lower ('-') or upper ('+') part of numeric character ranges
	NewParagraph	Yes/No	1	Natural language descript.: A new paragraph is inserted, starting with this character
	OmitFinal Comma	Yes/No	1	Natural language descript.: The final comma between character states is omitted ('1,2 and 3' instead of '1,2, and 3')
	SemicolonTo Comma	Yes/No	1	Natural language descript.: Linked characters in one char. group are separated by comma instead of semicolon
	CharHeading	Number (Integer)	2	Select a heading from picklist; inserted in char. def. output in front of the current character
	ItemSubheading	Number (Integer)	2	Select a heading from picklist; inserted in natural language descriptions in front of descriptions using this character
	LinkGroup	Number (Long)	4	Define linked characters, natural language output of each char. group occurs in single sentence
Indexes	CID	CID, Ascending		Primary key
	CharName	CharName, Ascending		Unique (= candidate key)
	Reliability	Reliability, Ascending
	Type	Type, Ascending
	CharHeading	CharHeading, Asc.		Ignore Nulls
	ItemSubheading	ItemSubheading,Asc.		Ignore Nulls
	LinkGroup	LinkGroup, Asc.		Ignore Nulls
	NumStates	NumStates, Asc.		[* necessity of index should be reevaluated! *]
_CHAR _HEADING	Name	Type	Size	Description
Attributes	HID	Number (Integer)	2	Character heading ID; determines sequence of headings when used in identification; change number to change that sequence!
	HeadingName	Text	255	Heading name, used for CharHeadings and Named character groups (identification)
	HeadingPhrase	Text	255	Optional phrase; preferred over HeadingName as ItemSubheading in natural language output.
	Notes	Memo	-	Internal notes (not exported to Delta format)
	AutoGroup	Text	255	Empty for user defined headings; else special code which is recognized during identification or a SQL query returning a set of character IDs. HeadingName may be changed as needed.
Indexes	HID	HID, Ascending		Primary key
	HeadingName	HeadingName, Asc.		Unique (= candidate key)
_CHAR _HEADING _Link	Name	Type	Size	Description
Attributes	HID	Number (Integer)	2	Character heading ID to be linked
	CID	Number (Integer)	2	Character ID to which the identification heading is applicable
Indexes	HID	HID, Ascending CID, Ascending		Primary key
	CID	CID, Ascending
_CS	Name	Type	Size	Description
Attributes	CID	Number (Integer)	2	Character ID
	CS	Text	16	Character state code, usually positive integer number, special codes for variable/unknown and for statistics
	CharStateName	Text	255	Name or description of character state
	Notes	Memo	-	Character state notes
	Implicit	Yes/No	1	Mark this state as a default which is automatically set
	CharStatePhrase	Text	255	Wording to be used instead of CharStateName for natural language descriptions output, incl. special Delta formatting
Indexes	CharStateName	CharStateName,Asc.
	CID	CID, Ascending CS, Ascending
	CS	CS, Ascending
_DEP	Name	Type	Size	Description
Attributes	CID	Number (Integer)	2	Controlling character ID
	CS	Text	16	Controlling character state
	InapplicableCID	Number (Integer)	2	Dependent character, i.e. inapplicable for any item where CID/CS combination above is used
Indexes	CID	CID, Ascending CS, Ascending InapplicableCID,Asc.		Primary key
	InapplicableCID	InapplicableCID,Asc.
_Property	Name	Type	Size	Description
Attributes	PropertyName	Text	255	The name of the project property (do not change!)
	TextValue	Memo	-	Text information. Use Shift F2 to zoom into larger window!
	DateTimeValue	Date/Time	8	Date or time information, e.g. of last update
	NumericValue	Number (Double)	8	Numerical information, stored as real number
Indexes	PropertyName	PropertyName, Asc.		Primary key
	NumericValue	NumericValue, Asc.		Ignore Nulls
_ID_Descr	Name	Type	Size	Description
Attributes	IID	Number (Long)	4	Item ID
	CID	Number (Integer)	2	Character ID
	CS	Text	16	Character state of characters with defined character states
	X	Number (Double)	8	Numeric value, defined by CS
	Reliability	Number (Byte)	1	Combines character and modifier reliability
Indexes	IID	IID, Ascending
	CID	CID, Ascending CS, Ascending IID, Ascending		Primary key
	X	X, Ascending
_MAP	Name	Type	Size	Description
Attributes	CID	Number (Integer)	2	Character ID of character which is mapped for identification purposes
	MappedCS	Text	16	Mapped character state code; positive integer number
	MappedName	Text	255	Name or description of mapped character state (= 'KeyState')
	Notes	Memo	-	Internal notes
	MinValue	Number (Double)	8	Numeric characters: The lowest value of X to be mapped to this state
	MaxValue	Number (Double)	8	Numeric characters: The highest value of X to be mapped to this state
Indexes	CharStateName	MappedName, Asc.
	CID	CID, Ascending MappedCS, Asc.		Primary key
	CS	MappedCS, Asc.
_MAP_Link	Name	Type	Size	Description
Attributes	CID	Number (Integer)	2	Character ID
	CSMapped	Text	16	Character state code in _MAP
	CS	Text	16	Character state code in _CS
Indexes	CID	CID, Ascending CSMapped, Asc. CS, Ascending		Primary key
_MOD	Name	Type	Size	Description
Attributes	Usage	Text	255	Type of characters for which the modifier is applicable, e.g. GENERAL. COLORS, FREQuency of occurrence
	Modifier	Text	255	Modifier phrase for categorical or numerical data, e.g. "mostly", "usually", "rarely". In current language!
	Reliability	Number (Byte)	1	Influence of modifier on data coded through categorical/numerical char. states. More (>5) or less reliable (<5); 5 is default
	Postfix	Yes/No	1	Checked = output after the character state phrase, unchecked = in front of it
	UseBlank	Yes/No	1	Checked = blank is added between the modifier phrase and the item data text, else modifier added compress
	Operator	Number (Byte)	1	Checked = The normal operator is omitted when such a modifier is encountered, e.g. for "TO"
	Notes	Text	255	Internal notes
Indexes	Modifier	Modifier, Ascending		Primary key
	Usage	Usage, Ascending
_MOD_Link	Name	Type	Size	Description
Attributes	CID	Number (Integer)	2	Character ID to which the modifier is applicable
	Modifier	Text	255	Modifier phrase for categorical or numerical data, e.g. "mostly", "usually", "rarely"
Indexes	CID	CID, Ascending
	Modifier	Modifier, Ascending CID, Ascending		Primary key
Appendix 3: Table of Contents    [image] Main table of contents    [image] Next


Information model, detailed attribute informationDetailed attribute information
 Information model: Detailed attribute information

The following is a list of attributes, sorted by entity. You can either read it sequentially (in the Windows help file you can use the Browse buttons) or jump directly to a specific attribute. Use the overview list of entities and attributes. In the Windows help file you can also use the Index button below the menu.

Character definition and related entities:
   Attributes of the character definition (..._CHAR)
   Attributes of the character state definition (..._CS)
   Attributes of the modifier definition (..._MOD)
   Attributes of the dependent character definition (..._DEP)
   Attributes of the character heading definition (…_CHAR_Heading)
Item definition and description:
   Attributes of the item definition (..._ITEM)
   Attributes of the item description (..._DESCR)
   Attributes of the resource list (..._RSC)

Appendix 3: Table of Contents    [image] Main table of contents    [image] Next


Attributes of the character definition (..._CHAR)

(Use the Browse buttons to read the entries sequentially, or go to the entity table following the link above)


CID (character definition attribute)
CID (character definition attribute):

The character identifier is a positive integer number which forms the primary key of the _CHAR entity. Each character must have a unique CID, by which the character can be referred to from other entities. For example, in the Character states entity (_CS), a CID reference determines to which character the current state belongs.

The CID determines the sequence in which the character list is displayed, unless an explicit alphabetical or other sorting is requested. To change the sequence, the number can either be edited manually, or the special Reorganize definition form can be used.

If you enter a new character in the CharEdit form, the CID will automatically be preset to the highest CID + 1. You can change the CID number at any time to any positive integer value, which is not yet used by another character's CID.

See also: attributes of the CHAR entity and CharEdit form.


Character name and Character Phrase (character definition attributes)
Character Name and Character Phrase (character definition attributes):

The definition of the DELTA format goes back to a time where it was prudent to be as parsimonious with computer resources as possible. One design decision taken at that time was to mix the function of a phrase that concisely identifies a character, with the function of a phrase that makes sense in natural language output.

Although this design works well in a large number of cases, it often generates oblique wording when a character set is used for interactive identification, and displays the strange DELTA comment brackets to the user. Many DELTA users therefore prepare a second version of the character list for compiling an interactive key.

DeltaAccess keeps the functions separate, and requires the CharName attribute to contain a unique value. It may not be missing, should be short and concise, and phrased for use in interactive editing and identification tools. The first letter may be capitalized or not, but capitalizing it usually improves the readability of the dialog boxes.

CharName is limited to 255 characters. You can use any characters you need, but if you want to export your data to a DELTA coded text files, the name may not contain a '# ' or '*'. You can use / or > as long as they are not followed by a space, and you can use < as long as it does not follow a space or come at the beginning.

The CharPhrase attribute may contain any text that leads to the desired natural language output in DeltaAccess or after export in some other DELTA program like Confor or Pankey. It can be up to 255 characters long, or missing. Because natural language output uses a capitalization mechanism, the CharPhrase should start with lowercase letters, unless the first word must always be capitalized. Comments can be entered in the "<>"-brackets here, and the multiple '/' used to separate phrases (defined in DELTA version 4) can be used. CharPhrase is thus an attempt to bridge the gap between the free-text formatting definitions of DELTA and a database. Note that comments in a CharPhrase are not used for natural language output by the programs mentioned, but they may be convenient if data are compiled for Intkey. Since DeltaAccess assumes for its own purposes that if CharPhrase is not used at all, CharName shall be used for natural language output, you may have to enter <> to output no information at all.

During import the comments after the DELTA character string are not moved to the Notes attribute! See What happens to the character name during import? for more information. Compare also the Units attribute.

To remain as compatible with DELTA as possible, the CharPhrase attribute will be preferred during export over the character name CharName. The character names are exported in a second directive to conserve them.

See also: attributes of the CHAR entity and CharEdit form.


Character Notes (= comments; character definition attribute)
Character Notes (= comments, character definition attribute)

The character name Notes are optional and can be as long as you like. You should not put the DELTA brackets (< and >) around your text. Usually, the character names contain development information, and are not exported to natural language descriptions. They are imported from and exported to the Character notes directive, i.e. they are not added in DELTA-brackets (< and >) after the character name.

See also: attributes of the CHAR entity and CharEdit form.


Measurement Unit (character definition attribute)

For numerical characters, an optional measurement unit like "cm", "mm", or "°C". It is allowable to use non-standard units like "times the width".

In DELTA format, a Unit is defined as text after the character name string and before the character states or the next character. It is thus delimited by the string literal separator (usually "/"). Example: "#69. ascospores/ µm long/". In DeltaAccess, you would enter "µm long" in the Units attribute.

DeltaAccess accepts Units for numerical character only. Units of categorical characters are appended to the character state names during import, see What happened to my units during import?

See also: attributes of the CHAR entity and CharEdit form.


Character type (character definition attribute)
DELTA distinguishes five character types:

Categorical (or qualitative) character types; intermediate states are logically impossible or can not be measured:

UM (Unordered Multistate): Nominal scale. A sequence of states is not meaningful. Example: "red", "green", "blue".

OM (Ordered Multistate): Ordinal scale. A sequence of states (ascending or descending order) is meaningful. Examples: "first, second, third" or "absent, rare, frequent". The distance between these states is either logically not defined or not measurable by the observer. No statistics like average, standard deviation, etc. can be calculated from such data.

The "M" stands for multistate. Normally you can add more than one state, but you may also define the MultistateType attribute as exclusive, in which case only a single character state for such characters is allowed in each item.

Using an appropriate categorical character type and multistate type greatly improves the possibility to properly analyze your data and improves their usefulness in the production of printed keys and interactive identification. In binary characters (two states, e. g. present/absent), there is no difference between nominal and ordinal.

See also Overview of categorical character types.

Numerical (or quantitative) character types:

IN (Integer Numeric): Typically used to enter the number (or count) of something. Values must not be fractional, i.e. they must have no decimal point. Since the distance between values is constants (as opposed to the ordinal OM characters), the computation of an average is meaningful.

Note: *** The current version of DeltaAccess does not support IN like other DELTA programs, in that only min/range/mean/max type values are supported, but not character state like multistate numbers combined with OR.

RN (Real Numeric): can be entered. For measurements which may have a decimal point (compare fractional/exponential values), such as "length of spore". Standard DELTA allows to enter a single or mean value, a range of values ("1.2-3.4"), or to add minimum and maximum in brackets ("(1-) 1.2-2.3-3.4 (-5)"). The meaning of the range is not defined in DELTA. DeltaAccess allows more statistical attributes, including sample size, standard deviation or error, and it allows to specify the meaning of the range used (e. g. 95% confidence interval). Compare Standard and Extended Numerical attributes.

Text character types:

TE: standard DELTA definition, any kind of textual information, including annotations and remarks. Currently used frequently for literature references as well, but see below. Text characters can not be used in the construction of printed keys. DeltaAccess does allow to include them in interactive identification, but using them is comparatively slow.

See also: attributes of the CHAR entity and CharEdit form.


Standard and extended numerical attributes
Standard and extended numerical attributes:

The DELTA standard defines the following statistical attributes for numerical values:

Mean	Mean (= average)
-Low	Lower value of unspecified range (could be µ-s.d., but not known)
+High	Upper value of unspecified range (could be µ+s.d., but not known)
Min	Minimum value
Max	Maximum value
In a DELTA coded import file, these statistical attributes are entered as a single string in the following format: "(Min-) LowerRange-Mean-UpperRange (-Max)", where Min, Max, and either Mean or both range limits, may be missing.

DeltaAccess defines numerical attributes as character states of numerical characters. You define them very similarly to the states of categorical characters, see the CharEdit form. The attributes listed above are called Standard or Minimal set of numerical attributes in DeltaAccess.

DeltaAccess offers a much wider spectrum of additional statistical attributes. Any desired statistical attribute can be added to the list of numerical character states during the definition of a numerical character. The following attributes are added if you select Extended set of numerical attributes during import of a DELTA file or from the add character states pick list in the header of the character state subform:

Median	Median
Mode	Mode
SD	Standard deviation of sample (df = n-1)
SE	Standard error of mean (= SD/Squareroot(N))
Val	Single value (i.e. sample size N=1)
N	sample size, number of measurements used to calculate statistics
+SD	Range: mean plus 1 standard deviation
-SD	Range: mean minus 1 standard deviation
-CI 95	Lower limit of 95% confidence interval for mean
+CI 95	Upper limit of 95% confidence interval for mean
-CI 90	Lower limit of 90% confidence interval for mean
+CI 90	Upper limit of 90% confidence interval for mean
+Q90	Upper limit of 90% quantile (= between 5 and 95 %)
-Q90	Lower limit of 90% quantile (= between 5 and 95 %)
+Q80	Upper limit of 80% quantile (= between 10 and 90 %)
-Q80	Lower limit of 80% quantile (= between 10 and 90 %)
+Q50	Upper limit of 50% quantile (= between 25 and 75 %)
-Q50	Lower limit of 50% quantile (= between 25 and 75 %)

Upon export, all ranges, quantiles, or confidence intervals will become unspecified ranges, and the distinction between mean, median, etc., will be lost. The sample size N and other extra attributes can not be exported because they are not defined in DELTA.

Also, DELTA does not specify whether a single numerical value is a single measurement, a mean, median, or mode. Import assumes that such values are means, but you can later change the attribute for each character separately within DeltaAccess.


MultistateType (character definition attribute)
MultiStateType (character definition attribute):

This attribute is available for categorical (UM/OM) characters only. It is used to define whether the states of a categorical character may have multiple states in a single item. Setting MultistateType to '0, Exclusive' prohibits this.

Multiple states may occur if an item is polymorphic (e.g. different states apply to young and old organisms), variable (phenotypically or genotypically), or if it is a class (e.g. a genus with different species). In these cases, MultistateType defines how the states shall be combined in natural language output. By default, DeltaAccess will set the MultistateType such that the 'OR'-operator is used for UM-type characters and the 'TO' operator for the OM-type characters. For some characters, it will be more logical to use an AND operator one.

The multistate type Exclusive is the equivalent to the DELTA EOM/EUM character types (which are converted accordingly during import). Currently the Exclusive restriction is not enforced during data entry. You can check for violations of this condition using the CS = exclusive-condition (Multistate=0) violated-analysis query. Presence/absence or yes/no data should preferably be coded as UM with Multistate = Exclusive.

See MultiStateType values for a table of possible values of this attribute. This attribute is proposed as a new DELTA directive. See also: character types, attributes of the CHAR entity and CharEdit form.


MultiStateType values (character definition attribute)
MultiStateType values (character definition attribute):

MultiStateType	Value	Description
Excl.	0	states are exclusive = only a single state may be present in each item
Or	1	combine states with OR operator (DELTA: '/')
And	2	combine states with AND operator (DELTA: '&')
To	3	states intergrade, e.g. '1 to 2 or 5 to 6' (DELTA: '1-2/5-6')
To/And	4	states intergrade, e.g. '1 to 2 and 5 to 6' (DELTA: '1-2&5-6')
With	5	states are a combination, e.g. 'green with some yellow'


Logic of the Multistatetype attribute
Why the preferred operator for a character may be consistently either OR or AND: Probably most languages make a difference between the assertion of attributes and the listing of objects. Although the same formal logical operator may be involved, the natural language equivalent will be different depending on what you are referring to. Most people will say: "The flower color is red or orange". The alternative "red and orange" is meaningful preferably if both colors are present in different parts of the flower (which should be specified), or if the colors form a pattern. On the other hand, most people will say: "The plant occurs in France, Spain, and Italy", although, using predicate logic, this really means that the plant occurs in "France or Spain or Italy". Note that when querying a database, you usually have to use this second version, although it might not sound intuitive in natural language. DeltaAccess defines the MultiStateType character definition attribute to allow this distinction to be recognized in natural language output.


Mandatory (character definition attribute)
Mandatory (character definition attribute): The character must be used (= "entered" or "scored") in each item. If the character can not be specified for some items, the special character state 'U' for unknown must be inserted to explicitly state this fact. If you set this attribute, the item description editor can help to avoid that you unintentionally skip characters that should really be readily available for all or almost all items.

DeltaAccess can not enforce the Mandatory attribute on the database engine level. Thus it will be ignored if you edit your data directly in tables or queries. Editing forms issue a warning when mandatory characters are missing.

* Note: The current version of the ItemEdit form supports this check only in the rarely used All character view. In By-character view, only the "!" symbol in the character list indicates that a character is mandatory, but entering it is not enforced.

See also: attributes of the CHAR entity and CharEdit form.


Introduction to Reliability, Availability, and character weights
Introduction to Reliability, Availability, and character weights:

The usefulness of a character for interactive identification purposes may be influenced by several factors:

•	How variable is the character expression? A high within species variability of genotypes, or variable expression in the phenotype lead to low reliability.

•	How well has the character been observed or measured by the author of the data set? Some characters may have been frequently misinterpreted in the literature, which may make literature based data unreliable. Other characters may be known to survive badly in preserved museum specimens, so that the recorded information is doubtful.

•	How well can the character be assessed by someone using the data set interactive identification? Some very reliable microanatomical, chemical, or molecular characters are difficult to observe, i.e. the information is generally unavailable. Such characters should be avoided in printed or interactive keys as long as possible, although the recorded information may be very reliable, e. g. when used for phylogenetic classification purposes.

In classical DELTA, all three factors are combined into a Character Reliability or Character Weight value. DeltaAccess uses character Reliability for the first two factors. It introduces a new character definition attribute, character Availability for the last factor, because it is relevant only during identification, and not in respect to the quality of the recorded data.

The impact of character Reliability on identification is modified by the following attributes: character Availability, modifier Reliability of the item description modifier, and item Abundance. See also: Calculation of combined reliabilities.


Reliability (character definition attribute)
Reliability (character definition attribute):

The character Reliability influences the choice of characters for printed keys or during interactive identification. See Introduction to Reliability, Availability, and character weights for a discussion of the different factors influencing the usefulness of a character for identification purposes. Character Reliability is further used by Confor, as a weighting value when exporting data to Nexus, PAUP, etc.

Reliability is a positive integer between 1 and 10. The default value is 5 (= average reliability). Fractional values (1/32 to 32) from the Character Weights directive preferred by older versions of Confor, are normally converted during import. Optionally they may be imported unconverted, but this may lead to problems when using the Identify module of DeltaAccess. The attribute is required, but the default value will automatically be set.

See also: attributes of the CHAR entity and CharEdit form.


Availability (character definition attribute)
Availability (character definition attribute):

Availability is a new character attribute introduced by DeltaAccess. It allows to specify the ease with which the character can normally be used for identification purposes. See Introduction to Reliability, Availability, and character weights for a discussion of the different factors influencing the usefulness of a character for identification purposes and the reason to introduce a new attribute Availability.

Availability is a positive integer between 1 and 10. The default value is 5 (= average availability). During Import, the values of Reliability are copied to the Availability attribute as well. Availability is exported only as a special DeltaAccess directive.

See also: attributes of the CHAR entity and CharEdit form.


Fuzziness, FuzzinessIsPercent (character definition attributes)
Fuzziness, FuzzinessIsPercent (character definition attributes):

Fuzziness is defined for numerical and OM type characters. It defines the error allowed during information retrieval. It is evaluated during Compilation of item descriptions for interactive identification, see interactive identification.

The DELTA directives Absolute Error and Percent Error are imported to and exported from these attributes. The values of both directives are stored in Fuzziness, while FuzzinessIsPercent distinguishes between the two directives. Standard DELTA (as implemented, e. g., in Confor and Intkey) restrict the use to numerical characters, the extension to OM type characters implemented here is specific to DeltaAccess.

See also:
  Definition of Fuzziness and FuzzinessIsPercent for numerical characters
  Definition of Fuzziness for ordinal characters
  and the attributes of the CHAR entity and CharEdit form.


The Fuzziness and FuzzinessIsPercent attributes and numerical (RN/IN) type characters
The Fuzziness and FuzzinessIsPercent attributes and numerical (RN/IN) type characters:

If no range is available in an item for a numerical character, but a mean (or single measurement) is available, ranges are created based on the mean plus/minus Fuzziness. FuzzinessIsPercent determines whether the value in Fuzziness is to be interpreted as an absolute or a relative (percent) value. Items which already contain a range remain unchanged.

Example: In a specific item a RN character contains the value 200, and Fuzziness is defined as 20. During the compilation of the item description for identification, the mean (or single value) 200 is not written into the compiled table (ID_DESCR), but the range 180-220 (for FuzzinessIsPercent = False) or 160-240 (for FuzzinessIsPercent = True) instead.

Note that the algorithm used by DeltaAccess differs slightly from the one IntKey uses. The Confor/Intkey documentation says: "A percentage error r applied to a value v produces a range 100v/(100+r) to v(100+r)/100". In contrast, DeltaAccess use the standard mathematical definition of percent and calculates: v*(100+r)/100 and v*(100-7)/100.

The reliability in the compiled item description of the added ranges is identical with the reliability of the mean from which they were derived.

Return to Fuzziness, FuzzinessIsPercent, or Compiling item descriptions for interactive identification).


The Fuzziness attribute and ordinal (OM) type characters
The Fuzziness attribute and ordinal (OM) type characters:

DeltaAccess allows the use of the Fuzziness attribute for OM type characters as well as for numerical characters. The value of Fuzziness must be an integer in this case.

Example: Fuzziness = 1, and a state 3 has been scored in a specific item. During the compilation of the item description for identification, the states 2 and 4 are added to the compiled table (ID_DESCR). No error occurs if a state is not available (e. g. 3 might be the highest available state), these states are not added. The current algorithm limits the highest evaluated Fuzziness value to 4.

The reliability in the compiled item description of the fuzzed states is reduced by 2, i.e. if state 3 had reliability 7, the fuzzed states have reliability 5.

Return to Fuzziness, FuzzinessIsPercent, or Compiling item descriptions for interactive identification).


Weights conversion during import
Weights conversion during import: Two different types of weight values are used in the DELTA definition: Values between 0.03125 and 32 (directives: Character weights and Item weights) as used in older versions of Confor, and positive integer values 1, 2, ..., 9, 10 (directives Character reliabilities and Item abundances) as used by Pankey. The latter definition is preferred by DeltaAccess and also in the new versions of Confor.

During import, you have the option to convert values from the Character weights and Item weights directives into Reliability/Abundance values, using the equation: Ln2(Weight)+5. DeltaAccess's export functions always use the reliabilities/abundances directives.


FormatString (character definition attribute)
FormatString (character definition attribute):

This attribute in the character definitions defines a format for the output. The DELTA directive Decimal Places is imported into this attribute, but FormatString is much more powerful. You can either use a format from the pick list, or use any standard Windows format string (like they are used in most Windows programs, including Microsoft Access). You must use the international/English formatting codes. If you have a localized (non-English) version of Microsoft Access, you should check the help file for the definitions of format strings in Visual Basic, since national format strings can differ. Note: Do not use the standard setting "Currency". This will change depending on the computer on which the data are viewed. For example, 100 SFr entered in Switzerland would be reported as 100 $ by someone using the same data set in the USA, without any respect to real conversion rates. Instead, create you own currency format to preserve the currency information.

See also: attributes of the CHAR entity and CharEdit form.


OmitValues (character definition attribute)
OmitValues (character definition attribute):

This attribute applies to numerical characters only and is used in natural language descriptions. *** Currently DeltaAccess imports/exports this attribute but does not use it in the internal natural language descriptions yet! ***

If you leave OmitValues empty (the default) no special formatting is applied to the numerical character. If the value '-' is set (for "omit lower"), the lower range and the minimum are omitted from the natural language description. Conversely, the value '+' defines that the upper range and the maximum are omitted.

This attribute is used together with characters which define a maximum or minimum limit for some measurement variable. Example: "Conidia at most x µm long". In such characters, setting the lower range is useful for later analysis, but it should not be used in the natural language output.

OmitValues is imported from and exported to the DELTA directives Omit lower for characters and Omit upper for characters. The latter directive is a new directive defined by DeltaAccess.

*** Note: It seems that Confor/Intkey. do not observe this attribute in the compilation for interactive identification. This does not seem to be logical. DeltaAccess might use the attribute for identification in a later version.

See also: attributes of the CHAR entity and CharEdit form.


NewParagraph (character definition attribute)
NewParagraph (character definition attribute):

Used in natural language descriptions: A new paragraph is inserted, starting with this character.

The attribute can be edited in the LinkGroup editor and in the CharEdit form. See also: attributes of the CHAR entity.


SemicolonToComma (character definition attribute)
SemicolonToComma (character definition attribute):

Used in natural language descriptions: Linked characters (see LinkGroup) are separated by a comma instead of a semicolon. Compare Dallwitz & al 1995 for further notes and warnings on using this feature. In the new Confor version this directive is planned to be replaced by a PUNCTUATE directive.

The attribute can be edited in the LinkGroup editor and in the CharEdit form. See also: attributes of the CHAR entity.


OmitFinalComma (character definition attribute)
OmitFinalComma (character definition attribute):

Used in natural language descriptions: The final comma between character states is omitted ('1,2 and 3' instead of '1,2, and 3'). Used to adjust the output to languages where putting a comma before the "and" or "or" would be a spelling error.

See also: attributes of the CHAR entity and CharEdit form.


CharHeading (character definition attribute)
CharHeading (character definition attribute):

If set, extra headings are written in front of a single or a group of characters. In contrast to the following attribute ItemSubheading, this one is used during output of the character definition, e.g. in the Character definition report.

Both the CharHeading and ItemSubheading attributes are links to the CHAR_Heading entity. In the character definition editor (CharEdit) you can only select headings already defined there. Use the heading editor (DeltaEditHeadings) to add, edit, or delete headings. See also: attributes of the CHAR entity.


ItemSubheading (character definition attribute)
ItemSubheading (character definition attribute):

If set, extra headings are written in front of a single or a group of characters in the item description output, esp. reports and natural language description. If you want to have a heading in front of a group of characters, esp. if the first character may not always be present, you have to copy the heading text to each character. If the characters are consecutive, the heading will be printed only once.

Both the CharHeading and ItemSubheading attributes are links to the CHAR_Heading entity. In the character definition editor (CharEdit) you can only select headings already defined there. Use the heading editor (DeltaEditHeadings) to add, edit, or delete headings. The HeadingPhrase is optional and will be used in preference of HeadingName during natural language output of ItemSubheadings. See also: attributes of the CHAR entity.


LinkGroup (character definition attribute)
LinkGroup (character definition attribute):

A group of characters may be defined to form a group using this attribute. The DELTA Link characters directive is imported into this attribute. All characters with the same number form a group. If the characters of a group are consecutive in a given item, the natural language description is changed: characters of the same group are output as one sentence, separated by ';'. The phrasing is shortened within a group by the elimination of all leading words identical with the first character.

A special editor is provided to edit LinkGroups more conveniently than in the CharEdit form, see Editing link groups.

Related attributes: SemicolonToComma, NewParagraph. See also: attributes of the CHAR entity


Attributes of the character state definition (..._CS)

(Use the Browse buttons to read the entries sequentially, or go to the entity table following the link above)


Character states (character state definition attribute)
Character states:

In classical DELTA, only categorical (UM/OM), non-numerical characters can have states. The minimum number of states is 2, and you can have as many states as you need (some programs might limit the number of states; e. g. DEdit/Pankey allows a maximum of 31 states).

The special states (U/V/-) are available without being defined in the character definition of a DELTA coded text file. DeltaAccess defines these states explicitly, i.e. they appear in the list of character states. Nevertheless, these special states are excluded from the count of states defined for a character (NumStates attribute).

DeltaAccess uses character states for additional purposes. The special state TE is used to enter text information instead of a categorical character state. For text characters (Type = TE) this is the only state allowed.

For numerical characters (RN/IN), DeltaAccess treats the different numerical attributes (or statistics) as character states; see Standard and extended numerical attributes above.

Character states can be entered and edited in the character state subform of CharEdit. See also the remaining attributes of the CS entity.


Character state name (character state definition attribute)
Character state name (CharStateName, character state definition attribute):

The name of a character state should be as concise as possible. Normally (i.e. if the CharStatePhrase attribute, which is not accessible from the user interface in DeltaAccess, is not used), it should be make an acceptable sentence when joined with its character name.

The CharStateName is limited to 255 characters. You can use any characters you need, but if you want to export your data to a DELTA coded text files, the name may not contain a '# ' or '*'. You can use / or > as long as they are not followed by a space, and you can use < as long as it does not follow a space or come at the beginning.

See also: Character state Notes, attributes of the CS entity, and character state subform of CharEdit.


Character state phrase (character state definition attribute)
Character state phrase (CharStatePhrase, character state definition attribute):

This attribute is currently not yet used. It provides a similar functionality to the CharName/CharPhrase pair for the character states. So far only the CharStateName attribute is accessible in the user interface.

See also: attributes of the CS entity.


Notes (character state definition attribute)
Notes (character state definition attribute):

Character state Notes (or comments) are optional and can be as long as you like. You should not put the DELTA brackets (< and >) around your text.

In DeltaAccess, character state notes are currently used for internal notes only. If the data are exported, they may be displayed by another DELTA program like Intkey. This can be used to display an identification hint to the user, e. g. "at least some" or "use a hand lens". In many cases where state notes are currently used (e. g. CharStateName = "small", Notes = "less than 2 mm"), it is questionable whether the additional information should not go directly into the character state name or phrase.

See also: attributes of the CS entity, and character state subform of CharEdit.


Implicit (character state definition attribute)
Implicit (character state definition attribute):

When a character state is marked as implicit, it is assumed to be the default state for any item where no other state (including a special state U/V/-/TE) has been scored.

Note that although this defines the state as implicit, most analyses will not immediately recognize the implicit state. The calculation of implicit states is very time consuming and an online calculation would be impractical for the very large data sets DeltaAccess is intended for. You must use the analysis option insert implicit states as explicit data before the implicit states are fully recognized in all analyses.

See also: attributes of the CS entity, and character state subform of CharEdit.


Attributes of the dependent character definition (..._DEP)

Introduction to character dependency: Sorry, must still be written [******]

See also: attributes of the DEP entity and the section on defining inapplicable characters of the CharEdit form.


Dependent character definition (..._DEP)
InapplicableCID (character dependency definition attribute):

Some characters depend on one another. For example, if leaves are absent, characters relating to leaf characteristics (overall form, size, form of tip, form of base, etc.) are logically impossible. The latter characters are inapplicable, if the controlling character/character state combination is scored in an item. Another way to say this is that leaf form etc. is dependent on leaf presence. Inapplicable and dependent are used as synonyms in this documentation. All three DELTA directives (Inapplicable, Applicable, and Dependent) are imported into this entity.

A dependent or inapplicable character is identified by the attribute InapplicableCID in the ..._DEP entity. The controlling character and state are identified by the attributes CID and CS, respectively, in the same entity. The inapplicable/dependent character can not be used in any item where the controlling CID/CS combination above is used (or scored).

DEdit/Pankey calls the controlling character a "parent character" and the dependent/inapplicable character a "child character".

See also: attributes of the DEP entity and the section on defining inapplicable characters of the CharEdit form.


Attributes of the character heading definition (..._CHAR_HEADING)
Attributes of the character heading definition (…_Char_Heading)

(Use the Browse buttons to read the entries sequentially, or go to the entity table following the link above)


HID (character heading definition attribute)
HID (character heading definition attribute):

Character Heading ID, a positive integer number. When entering a new heading, you must also enter a heading ID. If you enter a new heading in the Edit character headings dialog box, the HID will automatically be preset to the highest HID + 1.

If you import a DELTA coded text file data set containing heading directives, certain standard numbers are used in the import process. These numbers have no special significance beyond import. The HID number can be changed at any time to any positive integer value, which is not yet used by another character heading.

The sequence of HID numbers determines the sequence of the named character groups used in identification. Change the HID number to change that sequence. A convenient method to do this is to switch the Edit character headings dialog box to datasheet view. The HID sequence does not influence the heading sequence when used as CharHeading or ItemSubheading.

See also: attributes of the CHAR_Heading entityand Edit character headings.


HeadingName (character heading definition attribute)
HeadingName (character heading definition attribute):

Heading, used for character headings (see CharHeading) and identification character groups. Also used for item subheadings (see ItemSubheading), if no HeadingPhrase has been defined.

See also: attributes of the CHAR_Heading entityand Edit character headings.


HeadingPhrase (character heading definition attribute)
HeadingPhrase (character heading definition attribute):

Optional phrase; if available it is preferred over the HeadingName for the use as ItemSubheadings in natural language output.

See also: attributes of the CHAR_Heading entityand Edit character headings.


Notes (character heading definition attribute)
Notes (character heading definition attribute):

Character heading Notes (or comments) are optional and can be as long as you like. You should not put the DELTA brackets (< and >) around your text.

Use the Notes attribute for internal notes only. Currently, heading notes can not be exported to or imported from DELTA text files.

See also: attributes of the CHAR_Heading entityand Edit character headings.


AutoGroup (character heading definition attribute)
AutoGroup (character heading definition attribute):

Used for the definition of special Named character groups (which are used in identification).If the AutoGroup attribute is set to one of the predefined codes, the Identification will automatically form an group or switch to an alternative mode (e. g. entering ItemName conditions). The advantage of defining a group using this attribute is, that changes in the character definition are immediately reflected in the Named character groups. Therefore, the manual definition of Character groups is not available once AutoGroup is set.

Alternatively, a full SQL-query which returns a set of CID attributes can be entered in this attribute. Note that the length of the query string must less than 256. The SQL code can either be written for the current descriptor project, or for a project with the name "PRX", referring, e. g., to the character definition entity as PRX_CHAR. The latter makes the definition independent of the project name, which has advantages if the character definition is copied to a new project. Example: "Select CID From PRX_CHAR Where Availability>7;" would define a named character group consisting only of characters with high availability.

Note that the AutoGroup attribute is specific to this implementation of DELTA and is currently neither exported to nor imported from DELTA files. Predefined default AutoGroups will be added to each project during import.

See also: attributes of the CHAR_Heading entityand Edit character headings.


AutoGroup: Codes
Currently defined codes for the AutoGroup attribute are:

CODE	Description	Added during import
CATNUM	Categorical/numerical characters	Yes
CAT	Categorical characters (type UM/OM)	Yes
NUM	Numerical characters (type RN/IN)	Yes
OM	Ordinal characters (type OM)	No
UM	Nominal characters (type UM)	No
RN	Real numerical characters (type RN)	No
IN	Integer numerical characters (type IN)	No
TE	Text characters (type TE)	Yes
XNOTE	Search in item description notes	Yes
XITEM	Search in item name (e.g. specify a genus)	Yes
XN	Globally search Notes in all characters	Yes
XT	Globally search text (excl. notes) in all characters	Yes
XA	Globally search any text (incl. notes) in all characters	Yes
ALL	All characters (any type)	No
ILL	All illustrated characters	No
XSEP	-------------------------------------------------------------------	Yes
The XSEP AutoGroup provides a separation line. You can insert multiple separation lines to structure the list of named character groups presented during identification.


Attributes of the item definition (..._ITEM)

(Use the Browse buttons to read the entries sequentially, or go to the entity table following the link above)


IID (item definition attribute)
IID (item definition attribute):

The item identifier is a positive integer number which forms the primary key of the (..._ITEM) entity. Each item must have a unique IID, by which it can be referred to from other entities, e. g., to determine which item is currently described in the item description. Note that the ItemName is not necessarily unique, since the same item may be described multiple times, e. g., when collection information from different literature sources.

The IID determines the sequence in which the item list is displayed, unless an explicit alphabetical or other sorting is requested. To change the sequence, the number can either be edited manually, or the special (*** not yet implemented, will be added in later version of DeltaAccess***) form can be used.

If you enter a new item in the ItemEdit form, the IID will automatically be preset to the highest IID + 1. You can change the IID number at any time to any positive integer value, which is not yet used by another item's IID.

See also: attributes of the ITEM entity and ItemEdit form.


Item Name (item definition attribute)

The name of an item can be a taxon name or any phrases you wish. It can be up to 255 characters long and may not be left out. In contrast to the character name, it does not have to be unique. Examples: "Microbotryum violaceum", "Combea De Not. (1846)", or "CBS 123.99 (violet strain variant)". If you want to re-export your data to other DELTA programs, you may not use the special DELTA characters '#' and '*', and the combination of '/' followed by a space.

The item name should identify an item as well as possible. Ultimately, the item name should be the entry point to a taxonomic database subsystem. If the descriptor project is concerned with biological taxa, it may therefore contain a taxon name, with or without authors, place, and date of publication, depending on what information will be available in the taxonomic database subsystem.

Note that the ItemName is not necessarily unique, since the same item may be described multiple times, e. g., when collection information from different literature sources.

The current version of DeltaAccess is still limited in its handling of multiple items with the same taxonomic name. The necessary attributes to distinguish items, information about which was collected from different sources (e. g. literature references or direct data collection from different collection specimen), are already available in the item table, but not yet used in the user interface. The implementation of these attributes may yet change. You can either use the fields through the raw table or query interface of Access, or add such information after the ItemName and revise your data in a later version of DeltaAccess.

See also: ItemNotes, attributes of the ITEM entity, and ItemEdit form.


Item Notes (= comments; item definition attribute)
Item Notes (= comments):

The item name Notes are optional, and may contain any text you wish. They can be up to 64000 characters long. You should not put the DELTA brackets (< and >) around it. Usually, the item name notes contain development information, and are not exported to natural language descriptions. They are imported from and exported to the Item notes directive, i.e. during export they are not added in DELTA-brackets (< and >) after the ItemName. They may be imported from comments in brackets after the ItemName though, depending on the setting of Item Name comments are authors in the import dialog box.

See also: character notes, attributes of the ITEM entity, and ItemEdit form.


Abundance (item definition attribute)
Abundance (item definition attribute):

The Abundance of an item indicates how frequently this item will be encountered by a user using either a printed key generated from the DELTA data set, or an interactive identification program like Identify or Intkey. The abundance of items in nature can then be used to make the identification path for frequently encountered items shorter than that for rare items. See The operational concept of item abundance for further information.

DeltaAccess prefers a positive integer between 1 and 10, but fractional values as preferred by older versions of Confor, may be used as well, compare Weights conversion.. DeltaAccess requires a value in this attribute, but you can always leave the default value 5 (= average reliability) unchanged.

The item abundance is combined with character Reliability and Availability, and with the modifier Reliability; compare Calculation of combined reliabilities.

See also: attributes of the ITEM entity and ItemEdit form.


The operational concept of item abundance

To estimate the best sequence of identification questions in printed or interactive keys, one tries to find the shortest path for the average identification. The information about the frequency with which certain items will be identified ("abundance") can be used to weigh this path.

Abundance should be interpreted operationally, i.e. how often will the item be identified. Some items may be very frequent, but unlikely to be encountered. They are unlikely to be identified and should receive a low abundance value. For instance, some deep see fish species may be very abundant, but a key of fishes will profit more if abundance is interpreted as abundance in fishermen's catches.

Similarly, frequently encountered items may be relatively rarely identified using the software. A pathogenic organism which must be identified several times each day is probably immediately recognized even by technical personal, without consultation of either a printed, or a computer-aided identification tool.


Attributes of the item description (..._DESCR)

(Use the Browse buttons to read the entries sequentially, or go to the entity table following the link above)


IID reference
IID reference:

This attribute refers to the item identifier (IID attribute) of the (..._ITEM) entity. Such a reference or relation is used to link information from the current entity with information about a certain item. For example, in the item description the IID reference determines, which item is described by the current record. All further information about the item, including the name, can then be found in the attributes of the ITEM entity.


CID reference
CID reference:

This attribute refers to the character identifier (CID attribute) of the _CHAR entity. Such reference or relation is used to link information from the current entity with information about a certain character. For example, in the item description the CID reference determines, to which character the description in the current record belongs to. All further information about the character, e. g. its type or the measurement unit in which the values stored in the item description attribute X are recorded, can then be found in the CHAR entity.


CS reference
CS reference:

This attribute refers to the character state code. Together with the reference to the character identifier (CID attribute) it forms a relation to the character state (_CS) entity. Such reference or relation is used to link information from the current entity with information about a certain character. For example, in the item description the CS reference determines, to which character state the code in the CS attribute of the item description entity belongs. All further information about the character state, e. g., the character state name, can then be found in the CS entity.


Modifier (Item description attribute, DESCR)
Modifier (Item description attribute, DESCR):

A modifier entry modifies the meaning of a character state. Typical entries are "rarely", "frequently", "slightly", "very", etc. To avoid using synonymous modifiers and to facilitate a translation of the item description into multiple languages, only values from the associated pick-list can be entered into the modifier attribute of the item description. You can use the Modifiers subform of the CharEdit form to define which modifiers are available for which character. For more information on modifiers see the Introduction to the concept of modifiers and Modifier definition and attributes, overview.

See also: attributes of the DESCR entity and ItemEdit form.


TXT (Item description attribute, DESCR)
TXT (Item description attribute, DESCR):

Text information of text characters, or other character types used as a text character. Up to 64000 characters can be entered ("memo"-field). If the text becomes too large for the field on the screen, double-click to zoom the contents of the TXT attribute into a larger text-editing dialog box. In some situations you may have to use the key combination Shift-F2 for a similar dialog box.

TXT may be used only, if the character state is set to the special character state TE. The use of the TXT and the X attribute is exclusive. These conditions are observed on the database engine level.

Note that the more obvious name "Text" for this attribute can cause problems on some SQL server systems, because TEXT is a reserved word of SQL.

See also: attributes of the DESCR entity and ItemEdit form.


X value (Item description attribute, DESCR)
X value (Item description attribute, DESCR):

A real numeric number, into which the numerical values for the numerical/statistical attributes defined for this character can be added. This attribute is used both for real and integer numerical characters (RN/IN). See Standard and extended numerical attributes for a list of the predefined numerical/statistical attributes with which this attributes is normally used. The use of the TXT and the X attribute is exclusive.

See also: attributes of the DESCR entity and ItemEdit form.


Item description notes (Item description attribute, DESCR)
Notes (Item description attribute, DESCR):

Each use of a character or character state in a specific item (e. g., scoring a character state for an item) may be accompanied by a Note (or comment). In contrast to character notes or character state notes, these notes will be included in natural language descriptions. DeltaAccess preserves new lines (line break, "return character") in the text, but they will be lost during export to the DELTA format.

In classical DELTA, this attribute is frequently used to add estimates of frequency such as 'often', 'rarely', and other modifiers to the item description. In DeltaAccess you should use the Modifier attribute instead.

Note that when you have to translate a data set into multiple languages, each item description note must be translated individually, while the character and modifier definitions are translated only once for the whole project. Also, information added in the item description notes is not usually available during identifications. For these reasons, item description notes should be used as sparingly as possible.

See also: attributes of the DESCR entity and ItemEdit form.


SEQ (Item description attribute, DESCR)
SEQ (Item description attribute, DESCR):

Occasionally users are interested to record the sequence in which they have added multiple character states to an item description. The attribute SEQ stores a such a sequence as a long integer number.

Note that the import procedure usually creates a sequence global to the entire descriptor project, but that this is not required. The sequence may start in each item/character combination with 1.

The sequence can be changed either by changing the SEQ attribute directly, or using the controls on top of the item description table (right hand side) in the ItemEdit form.

See also: attributes of the DESCR entity.


Attributes of the resource list (..._RSC)

(Use the Browse buttons to read the entries sequentially, or go to the entity table following the link above)


Resource (Resources attribute, RSC)
Resource (Resources attribute, RSC):

The Resource attribute contains the name of the external resource. For an illustration, this would be the name of the file containing the illustration. The filename should contains an extension which identifies the type of the file.

Resource can optionally contain a path to the resource. The use of paths should be avoided if possible. Use the project properties ResourceDefaultPath and ResourceDefaultURL instead. If it is not desirable to keep all resources in a single folder (= directory), you can create multiple folders in the default path and enter the resource with a relative paths, e. g. "maps/guanacaste.gif".

Recommendation: UNIX filenames are case sensitive. Even though you are currently working on a non-case sensitive operating system, you might later want to move information onto a UNIX web server. You therefore should consider following a rule in the naming of your files, e. g., making them all lowercase.

See also: attributes of the RSC entity.


Default pathnames
Default pathnames to media resources are stored in the Property table under ResourceDefaultPath (compare Editing project properties). If no default pathname has been defined, the directory in which DeltaAccess is stored is used. It will only be used, if the Resource attribute or the RSC entity contains not a complete path or URL.

ResourceDefaultURL allows to define a second path, which is preferred for internet connections to the media-directory. Example: A local path "N:\users\xyz\internet\images" could look like "http:// www.organisation.domain.edu/ Syrphidae/Identify/images" when accessed through the internet. Note that both paths should point to the to same resources. This can be achieved by pointing to the same physical directory or folder, or by keeping identical copies of all resources in different places.


Attributes of the modifier definition (..._MOD)

Modifiers are a new concept introduced by DeltaAccess. The following information is available:

  Introduction to the concept of modifiers
  Modifier definition and attributes, overview
  Reliability (modifier definition attribute)

Appendix 3, Table of contents    [image] Main table of contents    [image] Next


Reliability (modifier definition attribute)
Reliability (modifier definition attribute):

For each modifier a positive integer between 1 and 10 can be defined. The default value is 5 (= average reliability). The reliability of a the modifier modulates the character reliability and availability; compare Calculation of combined reliabilities. Modifier attributes like "occasionally" can be defined to reduce the reliability of the character in this item, while optionally a modifier like "strongly" can be defined to increase the reliability.

See also: attributes of the MOD entity and CharEdit form.


 Introduction to the concept of modifiers

Descriptive data are commonly organized and analyzed using a character times item matrix. Most phylogenetic analyses packages use such a matrix (e.g. PAUP, Swofford 1990). If multiple character states are allowed for each item ("multistate characters"), the character states take the place of characters and the matrix becomes a character state times item matrix. For each character state either the presence or absence, or a probability value can be recorded.

DELTA in its current state supports only presence/absence of character states and not probability values. This was a major reason for the developers of LucID (@. @@@, pers. comm.) to develop a proprietary exchange format instead of using the DELTA data standard.

However, already in the original DELTA publication (Dallwitz 1980) the need for a modification of each character state x item instance was recognized, but at that time the provision of free-text comments were considered sufficient.  A proposed new version of DELTA (Dallwitz et al. 1995b) offers several additional mechanisms, but the current article tries to show that these are at most partial solutions to the problem and that a different approach would be more promising.

In addition to free-text notes as much information as possible should be collected and analyzed in a more structured format, called modifiers.

Modifiers add an additional dimension to the character/character states concept. Conceptually there are several, quite different kind of modifiers:

The first group is called frequency modifiers. Whenever more than a single object is described it frequently happens that a description does not apply to all of them. This is not necessarily related to the description of abstract objects like taxa, but can happen just as well if on a single herbarium sheet several flowers are present. In the current definition of DELTA the only way to express information about inconsistency is to add a note to the character state. This is not very desirable for several reasons: Notes can not be analyzed, esp. not used in an interactive identification (which is essentially a form of analysis). Note tend to use different, but essentially homologous phrases for the same situation, which can be confusing. Also, it is difficult to generate multilingual data sets with many item description notes, because each note has to be translated separately. If a consistent set of modifiers is used, which is not confounded with further notes, this translation can be produced just as automatically as the translation of the character names and character states descriptions. A database can store multilingual descriptions and generate the data in any supported language. People from, e. g., Australia, Japan, or France can concurrently work with the same database in the internet.

While the frequency modifiers are not covered at all by DELTA, the following modifiers could all potentially be integrated into the character state list. Introducing them is mainly done for practical reasons, to avoid an undue inflation of characters or character states in large data sets that cover very diverse organisms.

The second group is called location modifiers. You can use them to indicate the place where a character occurs. Frequently an object is inhomogeneous in itself, so that you need to express that, e. g., a plant is hairy at the base of the stem, but glabrous at the very tip. Alternatively it would be possible to create two separate characters for the base and the tip of the stem. The disadvantage is that for the majority of plants which are, e. g., homogeneously glabrous, two characters would have to be scored. Also, the character list during interactive identification becomes more confusing, and you would have to introduce yet another character if you ever find a plant, which is actually hairy in the middle of the stem only...

The third group are quality modifiers. Examples are "very", "weakly", "slightly", etc. These modifiers should be used with care, since often it may indeed be advisable to include them in the list of character states. The KeyStates-mechanism offers a possibility to map very detailed character state sets to a more coarsely grained set for use during identification. Yet, analyzing existing DELTA data sets I found that notes are frequently used to express fine quality modifications. It should be left to the researcher to decide which steps of a continuum to include in the character state definition and which additional information she or he wants to express using the modifier mechanism.

Sometimes quality modifiers may be abused to give a character state an entirely different meaning (e. g. "almost never"). Although this may work well in natural language descriptions, it will usually lead to undesirable results during data analysis and interactive identification and should therefore be avoided. In DeltaAccess, the effect on identification can be compensated to some extent by setting the reliability value for this modifier to zero. Also, using a modifier for such purposes will make a detection of such problems much easier than if this information would have been hidden inside free text notes.

In the current implementation of modifiers (see the following chapter Modifier definition and attributes, overview) these modifier types are merged for the sake of simplicity. I want to avoid the reaction that it is all so confusing, having so many fields to fill in (although you always can leave them empty). This is clearly a compromise, and I would like to hear your comments about it. You currently can not use a combination of frequency, location, and quality modifiers. Another option instead of defining different modifiers separately would be to allow several modifiers per character state.

In short, the advantages of formalizing the concept of modifiers, instead of using free text comments in their place, are: Modifiers are part of the character definition. This allows easy translation into multiple languages for a descriptor project as a whole, the definition of additional properties (formatting properties like whether they are to be printed before or after the states, a translation of frequency or probability wording into exact ranges, and a reliability value, which gives an indication of the influence of the modifier on the reliability of a given state in a given item. Since the modifier/character association can be defined, concise pick lists for modifiers are possible. A single set of color modifiers can be used for all color characters, but will not be visible in other characters. Pick lists are a considerable improvement of the user interface. Comments in contrast are specific to a single item/character(state) combination. The are necessary, whenever unstructured information, particular to this or only a few occurrences must be added. They should be used sparingly, because they are difficult to translate, and inaccessible to any form of analysis, including interactive identification.

Appendix 3, Table of contents    [image] Main table of contents    [image] Next


Modifier definition and attributes, overview

A new attribute Modifier is defined in item descriptions (_DESCR), which allows to mark item data with predefined modifications or indications of uncertainty. The concept of Modifiers is discussed in more detail in the previous chapter.

No modifiers are active by default. For each character, a list of applicable modifiers is defined. Only these modifiers are selectable when entering the item descriptions, thus 'Color'-modifiers are applicable only to colors. The list of applicable modifier-character definitions is defined in the _MOD_Link table.

The definition of Modifiers is part of the character definition. Each descriptor project has a global list of modifiers, which is initialized with a default list during creation of a project. The following attributes are defined for each global modifier:

•	Usage: (examples: 'General', 'Color', 'Frequency', 'Location')

•	Modifier: the language specific modifier phrase

•	Reliability: 5 = leave unchanged, greater 5 = reliability increased, less = less reliable than without modifier. [? Is it meaningful to define anything as more reliable than without modifier?]

•	Postfix: True = modifier is added after character state instead of in front of it. For example "?" would be Postfix = true.

•	UseBlank: False = modifier is added directly without a blank.

•	Operator: True = During natural language output the normal operator defined in MultistateType is suppressed. Used, e. g., for range indication in UM-type characters. Basically, this attribute offers the possibility to abuse the modifiers attribute for free, character state specific operator definition. Use such modifiers with care, since they depend upon the sequence of character states, which will create problems during analysis and interactive identification!

During "Export as DELTA", UseBlank and Operator are ignored, they are used only for the natural language output. The following rules are used for export: Notes are output always after the character state. If both a Postfix modifier and a Note are present, the modifier is output after the note. (*** Which makes sense with '?', but is it meaningful otherwise? Perhaps add second flag 'AfterNotes'?)

Appendix 3, Table of contents    [image] Main table of contents    [image] Next


 Literature references

Berendsohn, W. G. (1995): The concept of "potential taxa" in databases. Taxon 44: 207-212.

Berendsohn, W. G. (1997): A taxonomic information model for botanical databases: The IOPI model. Taxon 46: 283-309.

Berendsohn, W. G., Anagnostopoulos, A., Jakupovic, J., Nimis, P. L. & Valdés, B. 1996. A framework for biological information models. In: Valdés, B. & Silvestre, S. (ed.), Proceedings of the VIII OPTIMA meeting. Lagascalia 19: 667-672. [Preprint: http://www.bgbm.fu-berlin.de/cdefd/objects/]

Berendsohn, W. G.; Anagnostopoulos; A., Hagedorn, G.; Jakupovic, J.; Nimis, P. L. & Valdés, B. (1996): The CDEFD information model for biological collections. (HTML and WinWord 6 format). http://www.bgbm.fu-berlin.de/CDEFD/CollectionModel/cdefd.htm

Colless, D. H. (1985). On "character" and related terms. Syst. Zool. 34: 229-233.

Dallwitz, M. J. (1980): A general system for coding taxonomic descriptions. Taxon 29: 41-46.

Dallwitz, M. J.; Paine, T. A.; Zurcher, E. J. (1993-1995). New Features for the DELTA System. URL http://biodiversity.uno.edu/delta/standard/newdelta.txt [Dated 8. May 1995, last checked 21. April 98].

Dallwitz, M. J.; Paine, T. A.; Zurcher, E. J. (1995). User's Guide to the DELTA System: A General System for Processing Taxonomic Descriptions. Edition 4.02 (May). 140 pp. (CSIRO Division of Entomology: Canberra.)

Green, D. G. (1994). Databasing diversity – a distributed, public domain approach. Taxon 43: 51-62.

Inglis, W. G. (1991). Characters: the central mystery of taxonomy and systematics. Biol. J. Linn. Soc. 44: 121-139.

Louhivuori, Mikko (1996): DELTA data format and pottery classification. DELTA Newsletter 12: 5-6.

Pankhurst, R. J. (1991): Practical Taxonomic Computing. Cambridge University Press, Cambridge, UK.

Rambold, G.; Hagedorn, G. (1998): The distribution of selected diagnostic characters in the Lecanorales. Lichenologist 30 (4-5): 473-487.

Swofford, D. L. (1990): PAUP - Phylogenetic analysis using parsimony. Champaign, Illinois: Natural History Survey.

White, R. J.; Allkin, R.; Winfield, P. J. (1993): Systematic databases: The BAOBAB design and the ALICE system. In:  Fortuner, R. (ed.) Advances in computer methods for systematic biology. John Hopkins Univ. Press. Baltimore, USA pp. 297-311.

Appendix 3: Table of Contents    [image] Main table of contents    [image] Next


Dictionary of terms and procedures
 DeltaAccess –
a SQL interface to DELTA (Description Language for Taxonomy), implemented in Microsoft Access

Glossary of terms and procedures

The glossary contains short explanations which are used as popup topics in the Windows help file. This concept can not be simulated easily in a HTML file.

If you are reading the documentation sequentially, you should probably stop here. The following entries make little sense when used outside of their hypertext context.

Appendix 3: Table of Contents    [image] Main table of contents


DeltaAccess database size limit
DeltaAccess database size limit: Access imposes a limit of 1 GB for the size of the mdb database file. This is equivalent to ca. 150 MB import file size. You would have to store your data on a SQL-server and link the files back into Microsoft Access if your database grows larger than this. (Also, that could mean 25 h import time: I hope nobody is using DeltaAccess with such large data sets yet. The largest data set tested so far had 2500 items in a 3 MB item description import file.)


SQL (Structured Query Language)
SQL (Structured Query Language; pronounced 'sequel'): A standardized database language used by most modern database engines and servers. SQL consists of a Data definition language to manipulate the definition of tables, indices etc., and a Data manipulation language to retrieve or change data. The Microsoft Jet database engine SQL is generally ANSI-89 Level 1 compliant, although some differences exist. The most important difference is that more intuitive wildcard characters are used:

	Microsoft Jet SQL	ANSI SQL
Any single character	?	_ (underscore)
Multiple characters	* (asterisk)	%
See the contents of the Microsoft Access help file, Microsoft Jet SQL Reference, Overview, Comparison with ANSI SQL for more information.


*** Terminology: Used and Unused characters are synonymous to Scored and Unscored characters, as used by Pankey. I consider the Pankey terminology preferable, and will change the documentation accordingly in a later edition. **** Pankey examples: "Report on missing data", "List the unscored characters for each taxon".


Compatibility of character definition
Compatibility of character definition:

Two character definitions are compatible if the characters, as identified by their number (CID), have compatible character types and identical character state numbers or codes. If only the character or state names have changed, no problem will occur, as long as the meaning of the respective names remained identical. Example:

Character definition 1	Type		Character definition 2	Type
1. First character	TE		1. First character with different name	TE
2. Second character    1. First state    2. Second state	OM		2. Second character    1. First state with different name    2. Second state	UM
3. Third character    1. Small    2. Intermediate    3. Large	OM		3. Third character    1. Small    2. Large	OM
The characters 1 and 2 would be compatible, despite differing names and types (OM and UM are compatible). Naturally, the meaning of the characters or states where the name differs must be compatible. Due to character 3 the two definitions in the example are incompatible. It is possible to import data from definition 2 into definition 1, but not the other way round. Note that this would not make sense in the current example, since the meaning of state 2 differs (larger vs. intermediate).


Character type UM
	The character type UM is defined in the DELTA standard as Unordered Multistate character. It is a categorical (= 'qualitative') character on the nominal scale. In contrast to ordered characters, each state can directly be transformed into any other state. DELTA allows several character states in single character (= multistate). See also Overview of categorical character types.


Character type OM
	The character type OM is defined in the DELTA standard as Ordered Multistate character. It is a categorical or qualitative character on the ordinal scale. The sequence of states is fixed: To reach state 4 from state 1 one must go through the states 2 and 3. DELTA allows several character states in single character (= multistate). See also Overview of categorical character types.


Categorical character type overview
Overview: unordered and ordered categorical character types

(See also overview of character types)

	The normal case of an ordered character (type OM). In contrast to numeric types, only the sequence or order of states is known, but not the distance. Thus, states 1 and 2 and states 2 and 3 may have very different distances. The additional information that states are ordered is useful for identification and analytical purposes.
	The states are ordered, but branching occurs. This type is rare, but may occur where the phylogeny of a character is know, e.g. through fossil evidence. Sometimes colors or shapes could be viewed as branched ordered states.
	A special case of linear ordering. Most common example: months of a year. For phenological purposes (when does a plant flower, insect fly, etc.) it is important to know that January is next to December and February.  Implementation of this character type (as "CY") is planned for a future version of DELTA.
	Unordered categorical character. See character type UM. Each state can directly be transformed into any other state. Most structures and shapes are treated as unordered characters. Note that there is no real difference between ordered and unordered states if only two states are present.


Character types IN and RN
The character types IN and RN are defined in the DELTA standard as Integer and Real Numeric characters. Integer numeric characters are typical for counts and only take values of 0,1,2, ... while real numeric characters can take fractional values like 2.463, or 1.3e-4 (which is the way in Access and most computer programs to enter the number 1.3 x 10-4). Other terms for real numeric are floating point numeric, or interval scale.

Note that DeltaAccess does not restrict IN character type data entry to integer numbers, because the mean, s.d., etc. of IN characters can be a floating-point number. See also explanation of character types.


Real numbers
To enter a real numeric or floating-point number into DeltaAccess, the character type must be defined as RN or IN. You enter fractional numbers using the decimal separator (usually "." or ",") defined on your computer (as set in Windows control, international). This documentation assumes that your decimal separator is a period (".").

If your number contains decimal exponents, use the letter "E" in the place of the 10. Thus, you would enter '1.45E-3' for '1.45 x 10-3'. The range of floating-point numbers in DeltaAccess is -1.79769E308 to -4.940656E-324 for negative values and 4.940656-324 to 1.79769E308 for positive values. An over- or underflow error occurs if numbers are larger or smaller than these values.


Character type TE
The character type TE is defined in the DELTA standard as text character. You can enter any kind of text, plus additional notes. Note that searching of the text information is possible, but relatively slow. Information relevant for identification should normally not be put into TE characters. See also explanation of character types.


Special character states (U,V,-)
The DELTA standard defines several special character states, also called pseudo-values. 'U' stands for unknown. It is usually entered to indicate explicitly that the character was checked in the present item, but is unknown to the best of current knowledge; as opposed to: character not yet checked (in which case nothing is entered). Thus, in contrast to most databases which support only a single Null value for missing observations, DELTA allows to separate Null values.

'V' stands for variable and is an alternative to entering all possible character states. It does not explicitly state that all states are present, but that so many states may be present that the character is considered to be uninformative in the present item.

The dash ('-') stands for not applicable and is used where this is not already obvious through the definition of inapplicable characters in the character definition.

DeltaAccess further uses the special character state 'TE' to allow the entry of text data in the place of a numerical or categorical character. While this is default in DELTA, DeltaAccess requires this special state to be explicitly enabled in the character definition. For text characters, this state is the only state defined allowed. The special state TE is used exclusively by DeltaAccess for its internal operation. It will not appear in an export to a DELTA coded file.


Combined character states
Combined character states are used when a combination of states has a distinct quality from the states it consists of. Examples are combinations of colors as in multicolored flowers ('red with white spots'), as opposed to flowers changing color ('white, later reddish') or flowers with alternative colors ('red' or 'white').

Combined states can simple be added as a new state, but to preserve the relation with the states it consists of, it is recommended to use codes of the form <state code1>&<state code1> (e. g. "1&2"). In standard DELTA, as implemented, e. g., by Confor, you can create combined states ad hoc in any item description. You do this each time you use the "&" operator instead of the usual "/" operator. DeltaAccess does not support this. It purposely requires the deliberate definition of such a combined state, to increase the structure of the data and to avoid unwanted combined states. Analyzing existing data sets, it was detected that the majority of combined states were due to errors, rather than deliberate decisions.

If you use the recommended "1&2" codes, the combined state are more appropriately exported to other DELTA programs, and in a compiled item description for interactive identification the constituent states (e. g. "1" and "2") are added.


Modifier Templates
Modifier Templates are stored directly in the hidden template table USys_DeltaTemplates_MOD. You can edit these entries after you have made this table visible using the Microsoft Access options. Your new entries will be added to any new descriptor project you create. This is especially useful because, since DELTA does not support modifiers, the import process can currently only identify modifiers already present in this table. I appreciate it if you send me your comments and additions to the default list.


Link items with independent character definition
Manually link the item part of a descriptor project with an independent physical character definition

Creating an item link together with the copy option for character data makes it impossible to enforce referential integrity in the new character definition. This means that you yourself are responsible for the consistency between character definition and item descriptions. If for any reason you want to take that responsibility, you can achieve this manually: Create one descriptor project with Link/Link, and another descriptor project with Copy char. definition. Delete the item tables of the second project, the character definition queries of the first project, and rename the character tables of the second project to the names, the previously deleted queries have had. Example: First project X, 2nd project Y. Delete tables Y_DESCR, Y_ITEM, Y_RSC, and queries X_CHAR, X_CS, X_DEP, X_MOD, etc. Rename table Y_CHAR to X_Char, etc.


Integrating HTML forms or Natural language description documents into other applications
Integrating HTML forms or natural-language-description documents into other applications

If you want to integrate HTML form documents or natural language description documents created by DeltaAccess into other applications, e.g. into a web interface for interactive identification, you must know the rules by which the filenames of the HTML documents are formed.

The simplest solution is to use the item IDs (IID) as filenames. The IID attribute can be accessed directly from the ITEM table. If you want to use filenames based on item names, the integration is more complicated. Rules for filenames based on item names explains how the filenames are build. Instead of porting the functions used to create filenames based on item names, you can create a new query in Access, switch to SQL view, and insert the following query (replace 'PRX' with the name of your descriptor project):

SELECT IID, ItemName, ItemFileName("X.HTML", 3, [IID], [ItemName]) AS Filename FROM PRX_ITEM ORDER BY ItemName;

You can either use this query dynamically to look up the appropriate file name (use a where clause like: "Where IID=87"), or you can create a static table use a Insert-Into query, for example:

SELECT IID, ItemName, ItemFileName("X.HTML", 3, [IID], [ItemName]) AS Filename INTO Item2FilenameTranslation FROM PRX_ITEM;

Please contact me if you have any problems with this. Also note, that the procedure contains a method to deal with duplicate item names, which is not present in the query above. Thus, if you have duplicate item names in your descriptor project, you should rather base the filenames on the IID.


Rules for filenames based on item names (HTML forms or Natural language description documents)

Several problems exist, if you choose to use the item name as filename. The item name may be too long, it may contain characters not compatible with a file name, and it may not be unique.

To create filenames based on item names,

•	accented characters are converted to unaccented (e.g. á, à, â, and ä to a),

•	blanks, and the following punctuation characters: ". , ; : + < ( [ ] ) > / \" are replaced by an underscore ("_"),

•	the following characters are removed: " ! ? { } ` ' " ",

•	multiple underscores are replaced by a single underscore, and

•	trailing underscores are deleted.

After these replacements have been made, the item name is truncated to 40 characters. Should this item name not be unique, the IID number is appended to the second and following items. See also Integrating HTML forms or natural-language-description documents into other applications.


Close button: closes the dialog box without any further actions


OK button: executes the selected action


Action: Various management options are available, like create new, delete, restore, etc. Click on [image] to pick an option from a list.


Select All button: Selects all entries in the associated multiple selection list box


Deselect All button: Deselects all entries in the associated multiple selection list box


Complement button: Reverses the selection of all entries in the associated multiple selection list box: selected entries are deselected, not selected entries are selected


Select-Condition-button: Select entries in the associated multiple selection list box using a condition entered by the user. Examples how to specify the condition will be given in the dialog asking for the condition.


Edit Char ... button: Open the selected character(s) in the standard character editor (CharEdit). Useful to look up additional information about a character as well as to change part of the character definition if required.


Edit Items ... button: Open the selected item(s) in the standard item editor (ItemEdit). Useful to look up additional information on an item, as well as to change the item definition or item description.


Edit Headings ... button: Open the selected heading(s) in the standard heading editor (EditHeadings), where you can edit headings, create and delete headings, and change the association between headings and characters.


Zoom text button: Open the text of the field or control below or directly to the left of the button in a new window. The Zoom dialog box provides more space and uses a larger font for comfortable editing. Changes are written back to the original field. Clicking on this button is usually equivalent to a double-click on the field itself.


Zoom notes button: Open the associated Notes/Comments in a new window. To conserve screen space, Notes-controls are sometimes designed very small. The Notes-control itself is intended only to show whether Notes are present or not; always zoom the text to edit it.

The Zoom dialog box provides more space and uses a larger font for comfortable editing. Changes are written back to the original field. Clicking on this button is usually equivalent to a double-click on the field itself.


Zoom image button: Open the image associated with the button in a larger window. The size of the window can be further increased by resizing the border ( [image]).


Swap button: The characters or items on the left and right side are exchanged.


 Move button (Reorganize character states):

Move the selected character state definition (and all item description data where this definition was used) from the character on the left side to the character selected on the right side.


 Join button (Reorganize character states):

Join the definition and item description data of the character state selected on the left side with the character state of the identical code in the character selected on the right side. You can not select a character state on the right side. To join state 1 on the left side with state 2 selected on the right side, select 1 on the left side and enter '2' in the Rename CS field at the bottom of the left.


 Copy button (Reorganize character states):

Copy the definition of the character state selected on the left side to the character on the right side. Item descriptions using this character state are not copied!


 Delete button (Reorganize character states):

Delete the character state selected on the left side and all item description data using this character state.


Rename character state (Reorganize character states):

The character state selected on the left side is renamed while copied or moved to the character on the right side. Enter the code (usually number) to which the character state shall be renamed. To rename or join a state within a character, you can select the same character on the left and right side.


Select Used Items button: Select all items, which contain the character state (or states) currently selected in the multiple selection list on the left side of the dialog box. This can be a different state than the one you want to insert. See MultiItemEdit for further information.


Select Unused Items button: Select all items, which do not contain the character state (or states) currently selected in the multiple selection list on the left side of the dialog box (i.e. the state is absent, or "not scored" in these items). The character and state used for selection can be different from the one you want to insert. See MultiItemEdit for further information.


Identify button: Use the Identify dialog box to select items based on complex criteria. See MultiItemEdit for further information.


Cumulative checkbox (below the buttons on the right side of the item list): If this box is unchecked, all items are deselected before a new selection through the Used, Unused, and Identify buttons is performed.

If it is checked, the results of multiple selections through the Used, Unused, and Identify buttons will be added to the items already selected. The item set created is the union set of all selection steps done. This is equivalent to a combination of the selection steps with the OR operator. See MultiItemEdit for further information.


 Insert button: Insert the character states selected in the list above the button into the items selected in the list on the right side. If only a single character state is selected, you may optionally insert additional Modifier or Notes information.

For text characters you can insert text information entered in a field that appears in the place of the character state list above the button. See MultiItemEdit for further information.


 Delete button: Delete the character states selected in the list above the button from the items selected in the list on the right side. Additional Modifier or Notes information is ignored. If, e. g., a Note with a text other than the one currently set in the Notes field on the dialog box is attached to the selected character state in one of the selected items, the description is removed, including the Note. For text characters, any text information is removed from the selected items. See MultiItemEdit for further information.


 Move Down button: Move the selected entries down to change their relative sequence


 Move Up button: Move the selected entries upwards to change their relative sequence


Move Steps: Moving entries can be comparatively slow. If you want to move an entry, e. g., 6 steps up, you can set this field to 6, and the move buttons will move all selected entries 6 steps in a single operation


 Insert between button: Insert a new character, heading, or item above the first character, heading, or item selected. See Reorganize definition for further information.


 Delete button: Delete the selected characters, headings, or items. If you delete a character, the associated character states, and all item descriptions using this character are deleted as well. See Reorganize definition for further information.


 Copy to project button: Copy the selected characters, headings, or items to a second descriptor project. You can select the project in the pick list below the button. If the ID number already exists in the destination project, the definition is inserted under a new ID number. However, since character and heading names are required to be unique, the copy action will fail if another character or heading with the same name already exists in the destination project. See Reorganize definition for further information.


You can enter a character number or name. If you click on the [image] -button, you can pick from a list of available character numbers or names. If you select a number, the name will be filled automatically and vice versa.


Button to edit list of ID numbers
Button to edit list of ID numbers: If you click on the button [image], a dialog opens in which you can select one or several items, characters, or character headings. See extended multiple selection for more information on selecting multiple items in a list box.


AND-operator
Condition 1 AND condition 2 generates the intersection set:  of the result sets returned through each condition alone.


OR-operator
Condition 1 OR condition 2 generates the union set:  of the result sets returned through each condition alone.


Access 95
Microsoft Access 95 has several bugs, which are removed in Microsoft Access 97. One thing you may stumble upon is that modifiers can not be added in the CharEdit form. This is a documented bug in Access 95: checkboxes are incompatible with lookup queries. The form works fine in Microsoft Access 97, which has many other advantages as well: For example it is faster and less memory demanding than Access 95. I will no longer support Access 95 beyond the 1.0 beta version of DeltaAccess, which should be sufficient to give you an idea whether it is worth upgrading to Access 97.


Checkbox report, development note: Unfortunately it is not easy to produce an editing form in Microsoft Access which would be a simile to this printed report for entering your corrections. It may be possible using Visual Basic itself, but it would be a lot of work, which I currently cannot find the time to do. Also, although there are ways to generate reports with continuous text, you can not, to my knowledge, integrate checkboxes in such a text. Technical note: The checkboxes in the report are simulated using characters from the standard Windows font Wingdings. Access checkboxes would not be exported to RTF/Word in Access 97.


Context menu
Context menu: The floating menu which appears on the screen in many Windows programs if you click with the right mouse button is called the "context menu". It is usually context specific to the object on which you have clicked. Since only the relevant menu options are available, it can be a fast method to perform certain actions. The usefulness depends strongly on the currently selected object: Selecting an axis in an Excel Graph will result in a highly useful context menu, selecting any text in a Word document will result in a barely useful context menu.


The browse buttons below the menu in the Windows Help program ( [image]) can be used to read the help topics sequentially. Note that some pages may not be included in the browse sequence and will not be seen when you browse through the documentation.


A hypergraphic is an illustration that contains links to other information. When you move the mouse over an area for which additional information is available (e. g. a button depicted on the illustration), the mouse cursor changes to a hand symbol ( [image]). The area associated with a link is called a "hotspot".

When you click on a hotspot you will sometimes see a popup window on top of the illustration, and sometimes you will jump to another topic in the help file. The mouse cursor is identical in both cases.


The following contents topics directly access the main Microsoft Access help file. The copyright to these entries belongs to Microsoft Corp. You can only use them if you have a properly installed full version of Microsoft Access (i. e. not if you only have a run-time version).


To see the contents of the Access 97 help file, either click on the button labeled "Access Help" in the DeltaAccess help file, or select from the Access menu: Help, Microsoft Access Help or Contents and Index. The first tab ("Contents") of the help dialog box contains a list of all help topics. The symbols on the left side indicate whether the entry is a heading (book symbol) or a topic (leaf symbol). Double-clicking on a book symbol opens the book and displays the entries it contains.


By the use of a modified DELTA symbol, I want to express my reverence to the developers of the existing DELTA programs. At the same time I try to indicate that DeltaAccess tries to open up the DELTA standard, making it "accessible" to mainstream relational database systems. Most existing DELTA software is a closed system, which interacts with other software through import/export procedures alone. In contrast, DeltaAccess was designed to enable live data interchange with standard PC and WWW applications like SQL databases and webservers, using industry standard software interfaces (SQL, ODBC, DCOM), includes the source code and can be programmed in Visual Basic and other OLE capable software development tools.


DeltaAccess source code
Source code: To reduce the size of this application, I remove comments and formatting from the source code before distributing it. Thus, the normal version does contain the full source code, but is quite difficult to read. If you want to take a serious look at the source code or enhance some functionality, you can download a second version of DeltaAccess with full, commented and formatted source code. This version also contains additional forms, tables, etc. which are under development, may or may not work, and are not documented. Look for a ZIP file starting with SRC97_ followed by the version number (e. g. SRC97_151.ZIP for version 1.51) in the same directory from which you have downloaded the normal DeltaAccess distribution. Please contact me in case of problems.


 DeltaAccess

Copyright Gregor Hagedorn © 1995-1999. All rights reserved.
Institute for Plant Virology, Microbiology and Biosafety,
BBA, Federal Biological Research Center
Königin-Luise-Str. 19, 14195 Berlin, Germany.
email: G.Hagedorn@bba.de

See also Conditions of use


Printing the documentation
Printing the documentation:

Both the help version and the HTML internet version are somewhat difficult to print as a whole.

The Windows help function has only limited support to print parts of a help file. You can print each topic which you see on the screen. In the special Contents tree view of the help program (i.e. not in the tables of contents pages, which are displayed as help topics) you can also print a group of topics by selecting a first level entry ("book symbol", can be expanded to see the topic "sheets"). Still, each topic is printed on a separate page, which will waste a lot of paper. Also, many sub-topics of main topics are not included in the table of contents.

The HTML documentation is currently split into 22 files, each of which must be printed separately in the browser. Still, this is faster and wastes less paper than printing all topics of the help file. If you are reading this in a help file, point your web browser to the location from where you have downloaded DeltaAccess (www.bgbm.fu-berlin.de /projects /DeltaAccess/), select the link to "read the documentation directly in your browser", and go from the table of contents to the last entry ("Glossary", which contains this paragraph at the end). In your web browser, you can click on each of the following numbers and print each file: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24.

Some care has been taken to keep the documentation readable in printed form: internet URLs are added as visible text to hyperlinks, cross references often quote the title of the referred chapter. Still, some links to minor items or cross-references within the text might not be immediately obvious. Also, the width of some tables is optimized for screen display and may be too wide to print on your local paper format.


Version for printing
(Version for printing)

To make printing easier, a copy of the documentation in RTF format can be provided, through which the whole documentation can be printed as a single piece. (CURRENTLY NOT AVAILABLE, PLEASE REQUEST IT BY EMAIL)


Appendix 3: Table of Contents    [image] Main table of contents