Use of occurrences

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

  • Objects
  • Places
  • Storage locations
  • Entities
  • collections

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?

Comments

  • 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

  • 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)

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

  • Good to know.

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

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

Sign In or Register to comment.