Forgot password? | Forgot username? | Register
  • Index
  • » Users
  • » iant
  • » Profile

Posts

Posts

A new topic has been added to the EMu Users Forum: "Thesaurus Enhancements in EMu"

To subscribe to the topic, receive updates and contribute to the discussion:

1. Select Thesaurus Enhancements in EMu in the "EMu Modules: Using, Development & Design" forum.
2. Select Subscribe from the Forum Tools drop list.

Details:

This post is for EMu User community discussion of an EMu development proposal for enhancements to the Thesaurus module and its interaction with other EMu modules.

KE would appreciate if comments could be made by 30 November 2013.

Thanks,

Ian Turnbull
Chief Operating Officer
KE Software.

This post is for EMu User community discussion of an EMu development proposal for enhancements to the Thesaurus module and its interaction with other EMu modules.

KE would appreciate if comments could be made by 30 November 2013.

A Thesaurus module has been part of the EMu system since the July 2001 release of EMu 2.0.001. A number of EMu customers have made extensive use of the EMu Thesaurus capabilities.
Through discussions with various EMu customers in recent years it has been apparent to KE there is strong support for enhancements to the Thesaurus offering within EMu. This impetus has come from a variety of customers but in particular:
•    Museum of New Zealand Te Papa Tongarewa (Te Papa)
•    Powerhouse Museum (PHM)
•    University of Pennsylvania Museum of Archaeology & Anthropology (UPMAA)
•    The Henry Ford (THF)

Will Scott, a museum consultant involved in a number of EMu implementations in North America, prepared a Thesaurus discussion paper on behalf of UPMAA which was submitted to KE in 2011.
In October 2012, at the North American EMu Users Conference at the Yale Peabody Museum of Natural History, Thesaurus discussions took place between KE staff and conference attendees from UPMAA, THF and other museums. KE undertook to prepare this Thesaurus development proposal for consideration by the EMu community. KE apologises that it has taken so long for this development discussion paper to be released. The many competing development possibilities for EMu, driven by many customers, have made it harder than anticipated to get this proposal progressed in 2013.

The proposal incorporates a fundamental structural change to the way that Thesaurus records are linked to other records. The result is that Thesaurus records will be linked using the same IRN based linking method used elsewhere in EMu. The IRN is the Internal Record Number (an integer value) assigned automatically to each record in an EMu module when it is created. An IRN is unique amongst all records within an EMu module. For EMu customers who have Thesaurus data embedded in other EMu modules this proposed change has data migration considerations. It is important that EMu customers understand these considerations.

Thanks,

Ian Turnbull
Chief Operating Officer
KE Software.


EMu-Thesaurus-Enhancements-IE-20131007.pdf

20-Sep-13 12:53:40
Category: Using EMu

Hi Heather,

Thanks for your feedback.
I have responded to each of your questions in turn.

My understanding from the proposal is that only the UUID Version 4 format generator will be provided at no cost; any other formats (as those listed on page 9) will require each institution to pay for customization to set up.  Would you confirm/clarify?

In this initial stage only automatic GUID generation in UUID Version 4 format will be included at no cost to customers. However we expect EMu customers will push KE to provide automatic generation for other GUID formats. As is often the case with standards there are numerous other GUID format possibilities. If support for another GUID format (or formats) gains broad consensus in the EMu community, KE would certainly consider embracing that development at no cost to EMu customers. If automatic generation of a particular GUID format has applicability for a small number of customers then that is more of a case for customer funded development. It is possible that some of the larger EMu customers will fund development for automatic generation in a GUID format used in their institution. Once support for automatic generation in a particular GUID format is incorporated into the EMu code base (whether funded by KE or by customers) then it would become available to all customers. KE has been very fortunate that many institutions in the EMu community have a civic minded approach to funding projects. They fund specific developments desired by their institution whilst knowing they are often funding new functionality potentially of use for the broader EMu community.

The GUID generation framework in EMu will be programmatically customizable and extensible. However the aim for KE is to provide sufficient (non programming) configuration capabilities to allow most EMu institutions to generate their desired GUIDs without further consulting by KE. But inevitably some customers will desire variations to the functionality which will require (server-side) programming and KE will evaluate that case-by-case and quote for consulting work as needed.

Will the GUID generation functionality be configured on a module-by-module basis (in other words, we could turn it on for Catalogue only)?

Yes you will be able to set GUID generation just for the Catalogue. The GUID generation capabilities will be configurable module-by-module. Customers will be able to designate which modules should have automatic GUID generation and what GUID formats should be generated for records in that module. Auto generation will first check to see whether the record has a GUID in the desired format, and if not generate one. A few low level core EMu modules will be permanently excluded from GUID generation (Audit, Registry, possibly others).

Within a module, would it be possible to generate one format of GUID for some records, and another format for others?  I'm thinking of biological vs. archives records, etc.

Yes this will be possible but it will require local server-side program customization. Customization to switch GUID generation on/off based on values in key fields would be quite small scale. Whether KE would have to quote for such work would have to evaluated case-by-case. KE believes we will be able to provide some localization templates that illustrate how simple field value inclusion/exclusion can be wrapped around the GUID generation. Please note the EMu GUID infrastructure would allow these localizations to be retained through later upgrades to EMu (which is standard EMu policy).

Also, if GUID generation functionality was turned on for a module, would it still be possible for us to populate additional GUIDs via import?

Yes. The GUID setup uses regular EMu fields which can be populated via any EMu method. Access to the GUID fields is controlled in the standard way by the EMu registry.

Regards,

Ian

Ian Turnbull
Chief Operating Officer
KE Software

Hi all,

This topic will be of interest to EMu customers who capture Latitude/Longitude values for collection event and/or site data.
In the EMu 4.0.01 release changes were made to precision handling when converting between latitude/longitude values in DMS (degrees / minutes / seconds) format and DEC (decimal) format. The changes are documented in the "Lat/Long Precision" section of the EMu 4.0.01 release notes at:
http://www.kesoftware.com/index.php?opt … ;Itemid=38
The specifications for this work came via a discussion group of EMu Natural History customers.

As part of the work calculations for EMu generated centroid values added one degree of precision greater than the least precise latitude/longitude value in a group of values. The specification implied treating a point (one pair of Latitude/Longitude values) the same as a line or an arbitrary polygon.
So a user entered point value resulted in a associated centroid value with one degree of additional precision.

A request has been for a minor variation to the way centroid values are calculated.
For a point no extra precision should be added to the calculations.
For a line or polygon the calculations shall remain as is.

KE believes this is a reasonable adjustment to make and intends to proceed with implementing the change in the next EMu release.
Installation of the change will require an EMu upgrade and running of a KE supplied maintenance script to adjust affected data.
If there are any concerns with such a change please respond prior to 8 January 2010.

Regards,

Ian Turnbull
KE Software

Hi all,

Attached are screen shots and brief commentary for the new EMu conservation module. Work is well advanced in incorporating these changes into EMu. We will very soon begin trialling these changes with one customer and once through that phase the changes will become available to all.

As always, comments/suggestions are welcomed.

I expect the changes will be formally released as part of the upcoming EMu 3.2.03 release.

Customers with a sub-class of the existing Conservation module please note that use of the new Conservation functionality will be on an opt-in basis. If you choose to stay with what you already have then that is fine.

Regards,

Ian Turnbull
KE Software

Attachment: 11022334239971.zip

Hi all,

Many thanks to all who have contributed to this forum.
A lot of excellent information has been discussed and shared and KE Software is appreciative of the time and effort given by all contributors (and by all readers).

We believe the discussion has reached a point where KE can use the content to build a new EMu Conservation module.
In fact we have already begun doing so and anticipate having a first draft available in EMu in October this year.

The broad aims of our development are:

- Accommodate as many suggestions as possible from the discussion in the core design.

- Build the new module such that a reasonably simple upgrade from the existing EMu Conservation module is possible. We believe this can be achieved without need for data export from the old Conservation module for re-import to the new module.

- Support the existing "one conservation record to many catalogue objects" approach. But also provide a simpler "one conservation record to one catalogue object" view so that customers may choose (and enforce) use of the module in that way if that is more appropriate to their business rules.

- Structure the module so that local customisation for particular clients can be accommodated. Pushing data from conservation to catalogue or catalogue to conservation will not be part of the new Conservation module. Customers can sub-class if this functionality is required.

I will submit new Conservation module screen shots to this forum as development progresses.

A number of EMu customers already have in place customisations of the existing EMu Conservation module.
Each of these customers will, in due course, need to consider whether all or part of the new Conservation module supercedes their existing customisations and what adjustments may need to be made.

Regards,

Ian Turnbull
KE Software

  • Index
  • » Users
  • » iant
  • » Profile