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

Sign In or Register to comment.