Notes from OpenKey Meeting, January 13, 2003

Manning  Hall 304

Members present—Jane Greenberg, Evelyn Daniel, Sarah Reuning, Bryan Heidorn


1.  Bryan reviewed the features required in Interactive Visual Polyclave Plant Keys:

Ø       Select characters/values in any order

Ø       Error tolerance (when user gets something dead wrong, system should not care)

Ø       Approximate matching (matrix has examples)

Ø       Characteristic priority; dynamic reordering

Ø       Differentiating characteristics

Ø       Diagnostic characteristics


Our grant says that we will produce polyclaves and we should design our key with the features above that are most important to identification. These features will help us determine which software to use. For example, SQL does not allow error tolerance, the user can chose incorrect characters or be wrong in Intkey, and DELTA does not allow for approximate matches as well.  No existing software has all of the features listed above, but Bibe has several.


Bryan demonstrated Bibe.  It has automatic query expansion by gathering synonyms.

Using Swish-eX, the software does full text searches on XML documents.  It has algorithms to weight how well things match and it creates a wide net to gather many results. However, some team members worry that the interface is not intuitive.


DELTAAccess was not listed on our software comparison. The two WWW softwares are partial implementations of Intkey, which was written over DELTA. DELTA is good at data compression—less of an issue since memory is increasing—but it is heavily coded, impossible for a human to read, and not documented well. Also, DELATAQ was dropped as an international standard two years ago.


Action Item—research DELTAAccess—Sarah


2.  Data needs: We need a controlled structure and controlled vocabulary. We can put data in database or use XML. Bryan believes that XML is better since databases are proprietary and can't be shared, whereas XML is designed for sharing.  Additionally, databases can't be searched in the polyclave way, anything but an exact match is hard to do in  a DB.  We need to have:

Ø       Structured descriptions of plants—Which is being done. Character definitions are close to being completed.

Ø       Way to display these descriptions—We need to choose software(s)


4.  UNC’s work plan: The team decided

Ø       Where our data is going to be stored (pros and cons//database, XML document)

o       Databases can’t handle fuzzy matching

o       It is harder to share info between DBMSs

o       XML is designed to be shared


Bryan provided examples of four types of data that we will need to store :

§         These 3 types of data can be XML or put in a database

·        Plant description (taxon) (UNC is focusing on species, UIUC is focusing on family, genus, and species)

·        Character descriptions

·        Image information

§         JPEG, GIF, etc.

·        Image (visual instance of a plant OR illustration/photograph of plant characteristic)



Action Item—Bryan and David will meet to discuss XML documents for UNC data