Use of occurrences

remco

We are basically trying to eliminate the use of movements and loans by replacing them all with different occurrence types.

My basic question is: Am I missing some logic setting up the system like this.

My thoughts would be:

You have

ObjectsPlacesStorage locationsEntitiescollections

And then everything that occurs to either of those (mainly objects because they are the core of the "collection") would be managed by occurrences (of different types)

Is there a specific reason to use movements or loans, not covered by the possible use of occurences of the types movement and loan (for instance missing out on functionality)

I would think the system would be easier to maintain with only one type of "interfering" behaviour (being occurrences)

Or is the availability of movements and loand (and maybe tours too) for compatibilty reasons?

seth

Occurrences are meant to function as an authority for things that happen. It's a temporal authority. Events (historical and otherwise) are a natural fit for occurrences, as are works, productions, performances, exhibitions and the like. Bibliographic references are also often modeled as occurrences. Broadly speaking, authorities that aren't people, places or collections end up as types of occurrences.

Loans are meant to represent incoming and outgoing loans of collection objects.

Movements are meant to capture details about transitions of collection objects from one location to another. They are typically used in organizations with very specific and detailed workflow around location tracking of objects.

Since loans and movements are administrative it is generally desirable to keep them distinct from authority content such as occurrences. Using loans and movements as intended guarantees that they're logically kept apart even at the data storage level. Now, given that you can customize and rename fields with very few limitations it's entirely possible to use loans as occurrences and movements as loans (or whatever), but it's usually best to go with the grain of the model.

seth

remco

First of all, the nice thing about collective access is the possibility to chose your own approach. (altough that might cause compatibility issues in the future??)

I can see the argument for the use of loans. (instead of occurences)

For movements I had the impression they were on their way to being depreciated.

I cannot find them in the Collective Access demo system and my own test system with default profile.

Also the default setting in app.conf is: ca_movements_disable = 1

(line 199 in default app.conf version 1.7.11)

I think I read someting about movements being fased out around version 1.7.6 or 1.7.8.

That lead me to the start of using occurences for "movements" and that seemed to make sense to me.

(And it seems to work fine for me, also for location tracking)

seth

No movements are here to stay. Few users use them, but when they do they're important so we have to keep support for them.

remco

Good to know.

I will start fiddeling with them again in a test system.

Rafael

Movements are a very important feature if we want to track the history of an object in the institution.

As Seth said ocurrende have a diferent meaning. Keeping specialized classes it is easier to manage.

robc

Loans are meant to represent incoming and outgoing loans of collection objects.

Doesn't this largely duplicate the purpose of Object Lots? And would it make more sense to say that Loans represent incoming and outgoing Lots?

When a loan is returned, what is the intended way to indicate the loan or lot is no longer in/out? I didn't see an obvious spot for this after loading the dacs_heritage profile.

seth

It depends upon how your museum works. Just about every one I've even seen makes a very clear distinction between loans and accessions (aka lots).

robc

Right. Most importantly, I don't want to confuse the two by having objects related to a Lot and a Loan of the same meaning.

My situation is that a large number of Objects were loaned in for cataloging. I assumed this would fit nicely into the Lots table. The Objects will remain in the catalog after they are returned to the lender. There could be future loans/accessions of the same Objects if they are loaned or donated. It seems like I only need one lot, but might need many Loan (or Movement or Metadata?) records to track this. I'm still a bit confused about that last part.

saui

Hi everyone,
I’ve been following this discussion on Occurrences, Loans, and Movements, and I have a related question about modeling administrative records.
From what I understand, Occurrences work as temporal authorities (for exhibitions, productions, publications, etc.), while Loans and Movements handle administrative workflows and should stay separate from the authority layer.
Given that, I’m wondering:
– What’s the best way to handle other administrative or workflow-related records, like conservation reports or insurance checks?
– Would it make sense to break down Object Lots into other management processes (e.g. condition reports)?
– Also, could publications be treated as content records instead of Occurrences, depending on context?
Any advice or examples would be really helpful.
Thanks!

behindicebergs

saui Hey saui, in regards to your first question which is the only one I can really answer:
In my current CA configuration we use occurrences for conservation reports and internvention reports, associating them by relationship to an object. We do this because they are temporally situated and one object can have more than one report (in case for example that a work has been intervened or a damage has worsened its condition) associated to it. This is an easy way for us to check all reports that address an object. Since movements and loans can be configured to have a more in depth and complex workflow which we don't particularly need we set it up this way.

I hope this helps!

saui

Thanks for your reply, I'll follow your suggestion. Regards,