Hi Don,

I'll try to answer your questions as best I can here. Adapting a system as open-ended as CA to a project like yours is an iterative process, so please feel free to follow up... I may not give you all the right answers the first time around :-)

(a) Right now you can either tie an object directly to a storage location, or tie an object to a movement which is in turn tied to a storage location. The "movement" record is intended to capture the details of a literal shipment of material, whether it be across the hall or around the world. Art museums, for example, often want to record details of how works were moved (who did the move, how, why, when, insurance details, etc.) to a given location. Further, they often want to record this information for a group of objects. Movement records provide a configurable mechanism for recording whatever it is about the movement of many objects. Since they're full-fledged records you can set them up to have as many or as few fields as you need.

There is a third way which is not fully implemented yet in the form of "object events." An object event is a record that represents some event in an object's lifecycle, whether it is a movement, a loan, an inventory, a conservation event, etc. These object events apply to single objects only.

Although object events may sound really useful, in practice for many collections the one-event-for-one-object model isn't practical, and when it is practical the functionality can usually be replicated satisfactorily using repeating containers. Thus development of this feature, which is part of the original base design, has continually been pushed back because everyone seems to get on fine without them. However, they might actually be perfect for your project...

(b) Most terminology is set in the profile, but the names of the main item types (objects, places, etc.) are hard-coded into the UI and can be changed by modifying the locale file for your preferred language(s). These are in app/locale. You generally do not want to modify the existing locale file since doing so will complicate future upgrades. Thing thing to do is to make a copy of the locale you use (in your case en_US) into app/locale/user and then edit the copy. CA will use the version in app/locale/user in preference to the stock one, and pick up your revised terminology.

You can learn more about locales and editing here: http://wiki.collectiveaccess.org/index.php?title=Locales

(c) We haven't worked with SNOMED directly. However a generic "information service" metadata element type is being developed that supports various taxonomy and/or vocabulary services via a plugin-API. The focus right now is on supporting taxonomy lookups from ITIS, uBio, PaleoBiology Database and the NCBI taxonomy database (http://www.ncbi.nlm.nih.gov/taxonomy), but the larger idea is to allow all sorts of services to be supported without having to create new element types for each. Perhaps queries on SNOMED could be performed using this system. Otherwise, you'd have to look at processing and importing the text-based data they provide, and then manage any updates yourself going forward.

seth