Hi,

The MHM profile was Missouri's attempt to create a gentle migration path from their old Access database system to CollectiveAccess. It's designed around a lot of MHM assumptions, and while it might be interesting to look at I doubt it would be of much use to an archaeological collection.

I'm not sure why your newly created user can't do anything, but my bet would be on the account not actually having all of the requisite actions assigned to it via roles.

As for how to get started, you'll probably want to precisely enumerate what types of materials you're cataloguing, what the fields are for each type and finally how they will map to the general CA model. Then you can develop an installation profile that will set up all of the various types of records, fields, drop-down lists, user interfaces, etc. It may well be that there's a profile that will work for your collection in the distribution, but it's much more likely that you'll need to take something relatively close to what you want and modify it to suit.

The CA data model provides several kinds of "items":

Objects - these are collection objects
Entities - people and organizations, most often. These are called "actors" in some archival standards.
Places - Hierarchical lists of geographic place names.
Occurrences - A "catch all" item used to model "things", usually temporally limited. Eg. events, film productions, bibliographies
Collections - collection-level records
Object lots - accession-level records
Storage locations - Hierarchical authority list of locations where collection objects are stored
Loans - museum loans, both incoming and outgoing
Movements - movements of single objects or groups.
Lists and vocabularies - Hierarchical concept lists used both for system configuration and controlled cataloging.

Each of these items are subdivided into types, and the list of fields (as well as the layout of those fields on screen) can be key'ed to the type. For example, an audiovisual archive might create object types "film", "video", "audio" and "document." While all four types of objects will share some fields, video will have certain fields that will not apply to "film" (eg. video system, tape format). Similarly audio will have fields not present for documents, video and film. CA can handle these sorts of differences; you need only see the the field relevant to the item at hand.

Something to keep in mind: with a few minor exceptions you can configure whatever fields you want for the various item types. You can add as many fields as you want to an entity record, for example, or remove a lot of superfluous fields from a place record.

All of these different kinds of items can be interrelated with typed relationships. In your collection question, you create the collection and object records and then relate them as required. The editing user interfaces for each type of record are configured with "bundles" (information units) that display, amongst other things, the list of related items (objects from the collection point of view, collections from an object's point of view). The editors are configurable and you can arrange the bundles that constitute your user interface in whatever manner you wish. Getting a list of related items for an existing record simply entails opening the relationship screen in CA (Assuming your profile defines one - it's a habit not a requirement to have one).

Another way to get a list of objects in a collection (or a list of anything related to something else) is to browse for it. In the objects-in-a-collection example, you'd choose "Objects" in the "Find" menu, then click on "Browse" on the menu on the left-hand side of the screen and then browse on collections. Choose the collection name from the browse list and you'll receive a list of objects in the collection. This list can be exported as a delimited file for use in a spreadsheet or, if you create metadata mappings, as a standard file format such as EAD or DC.

You can also customize which fields display in the list, and in what order, by defining a "display" (under the "Manage" menu). A display is simple an ordered list of bundles (aka fields) used for display.

This is just the tip of the iceberg. There are lots of details. But I hope this is enough to get you started.

seth