• Depends entirely on support from the user base

• Many technical issues still need to be resolved

• Long term development horizon

Proposal for aSimplified Structure for KE EMu

Let’s get rid of attachments!

Background

• KE EMu is an object-relational system

• Information recorded about a specimen is “normalised” into a series of modules – catalogue, taxonomy, collection events, sites, parties, etc.

• Modules can be designed to reference other modules, records attach to other records

• Each module is a data resource –e.g. Taxonomy = nomenclature

Attachment Overview

Specimen Record

Taxon

Authors(Party records)

Collection Event Site

Specimen is added here

But name must be added here

And locality details here

Benefits of Modular Approach

• Not just object-centric view

• Results in other useful resources, e.g. nomenclature

• Aids in navigation to related information – e.g. from party record to specimens collected or papers published or taxa described, etc.

• Promotes data consistency and minimum data standards

Benefits of Modular Approach

• Reduces data redundancy – e.g. biography of person recorded only once

• Ensures updates need only be applied in one place - e.g. correction to spelling of author’s name

• Supports security over records in different modules, e.g. can see specimen but not its taxon

But there are problems:

• Complex model can be difficult for new users to understand

• Results in more steps in data entry thus making it slower

• Makes reporting more difficult

• Complicates data migration/import process

The Import Problem

Scenario: New specimen record contains a person’s name (Identified By):

• If new person, should it be added to Parties?

• If name matches more than one Party record (e.g. G. Smith), should KE EMu

• Choose one of the existing party records?

• Create a new party record?

• Reject the specimen?

Then there are the practical problems

• When entering a new specimen, how do you know if you should attach to an existing Party or Collection Event or Site ….?

• Practical reality is that duplicate records are being created now

A possible solution?

• Rather than being structural components of a record, consider the catalogue support modules as references or authorities

• Based on the way KE EMu’s thesaurus now works

How it might work

• Users can choose to attach to a record in the supporting module as they do now using drag-and-drop or

• Alternatively users could enter text directly into the “attachment” field but this would be stored locally

Behind the scenes

• Each existing attachment field would be changed to include:

• A local text field

• An optional IRN to an attached record (as now). Attaching to a record would automatically fill the text field

Options to control terminology

Force attachmentMust be attached to a record before you can save (e.g. Object links in Loans module)

Attempt attachmentUses entered text to try to attach but allows save anyway (e.g. Taxon in Catalogue)

Reference onlyDoes not attempt to attach but user can choose to attach (e.g. Authors in Bibliography)

Administration options

Alert on new termEnsures that designated terminology expert (e.g. taxonomist) is alerted to new terms used in records which are not in the attached module

KE EMu Administrator [emu@museum.org]

Barry Jones [Barry_Jones@museum.org]

Notification Example

Administration options

Display exceptions (report)Allows an administrator to periodically view terms used in records that are not in the attached module

Question

• Can an attachment field have both a local text string and an IRN?

Local text of “L.” but attached to record for

“Carl Linnaeus”

Advantages of new scheme

• Rapid data entry

• Simplified interface to data model

• Flexibility to control terminology only in areas that matter

• Improved options for data import

• Can import data into a flat (flatter?) model

• Can preserve controlled terminology lists

• Can address terminology exceptions after import

Other options leading from this

• We could remove the IRNs from the links and make them contextual.

• Ultimately these references/authorities may not have to be stored in KE EMu but could be web-based resources, e.g. ITIS, Alexandria Digital Library Gazetteer

• This takes us a step closer to the Semantic Web