1. Depends entirely on support from the user base Many technical issues still need to be resolved Long term development horizon Proposal for a Simplified Structure for KE EMu Let’s get rid of attachments!

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

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

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

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

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

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

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

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

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

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

12. Options to control terminology Force attachment Must be attached to a record before you can save (e.g. Object links in Loans module) Attempt attachment Uses entered text to try to attach but allows save anyway (e.g. Taxon in Catalogue) Reference only Does not attempt to attach but user can choose to attach (e.g. Authors in Bibliography)

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

14. KE EMu Administrator [emu@museum.org] Barry Jones [Barry_Jones@museum.org] Notification Example

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

16. 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”

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

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