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    Main table of contents

  Recognized DELTA directives

  Limitations which will be removed

  Problematic limitations

  Limitations which have low priority

Appendix 2: Table of contents    Main table of contents

Overview over limitations    Appendix 2: Table of contents    Main table of contents

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    Appendix 2: Table of contents    Main table of contents

(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:

Overview over limitations    Appendix 2: Table of contents    Main table of contents

• 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:

• 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.

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    Appendix 2: Table of contents    Main table of contents

• 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:

• 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    Appendix 2: Table of contents    Main table of contents

• 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    Main table of contents

• 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    Main table of contents

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.

Appendix 2: Table of contents    Main table of contents

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    Main table of contents    Next