Forgot password? | Forgot username? | Register

Address History and Multiple Addresses

Address History and Multiple Addresses

Hi folks.

I'm looking into how the National Gallery of Australia use the Parties module, and I’m coming across a few problems. To solve this I am drawing up a spec for changes to our Parties module, but I think I'm addressing issues that might be faced by other organisations too. Thus I'm keen to find out who else has these problems and how they address them.

1. Address history.

There is no address history function in EMu. But there is a need in our organisation to keep record of address history in an easily discoverable way. One example is Loans records - we need to be able to see the address a loaned artwork was shipped from or to at the time, not the current address for that party record.

Our current practice whenever a party changes address is to create a duplicate party record, change the address to the new one, and retire the previous one.

How do you handle changing addresses in your organisation?

2. Multiple addresses.

We have many parties who have more than a physical and a postal address. For example artists who have home, studio, gallery, agent/dealer etc. To cater for this we need to create several parties records, and this can make searching for and attaching to those records confusing.

So any other EMu users have this same problem? And if so, how do you keep it simple for the end user?

Any discussion welcome.

mark.bradley at nga.gov.au

Edited by: - 01-Jan-70 09:00:00

Mark Bradley – Assistant Registrar, Documentation (EMu)
National Gallery of Australia

Mark Bradley
Assistant Registrar (EMu Guy)
useravatar
Offline
147 Posts
Male  Website 
Administrator has disabled public posting. Please login or register in order to proceed.

Re: Address History and Multiple Addresses

Hi Mark,

1.Address History
The issue of retaining the history of the association of a person with an institute or address extends across all aspects of data management. Loans is a good example and is crucial for ensuring you get the material back, but a person maybe a donor whilst at address 1, a borrower whilst at address 2, a collector whilst at address 3. All these associations need to be retained.

The Natural History Museum, London has yet to have this discussion at a cross-dept level, as 3 out of the 5 science departments are pretty much pre-occupied with the migration process, however it would seem best practice to have a separate Party record for each address, despite the fact that the person is the same. If you include Organisation in your summary data, this will help distinguish one record from another. This makes much more sense to me than using the Biography Tab to record the address history, since summary data for the Party record will show the most upto date organisation/address info. wherever it is attached (even the historical records) and thus the association between a person at an historical address and an event is less clear.

From some of the other threads on the Forum, it is clear that other institutes have different procedures for using the Party Module. The important thing is to decide on a standard practice and ensure consistency.

Multiple addresses
I can't say I've really come across this problem yet, but that's not to say our data doesn't reflect this issue (we've got a lot of tidying up to do!!). In the example you give, I can see it being quite a headache.
Off the top of my head, a solution might be to have a nested grid for addresses. In the same way that the Task Tab or the Categorised Notes Tab consists of a read only grid summarising data entered in fields above, you could have any number of addresses condensed onto a single tab. However, one must be careful about going down this route as it does offer complications for reporting and for defining the summary data for the record.

I don't know if this is any help, but I've had my 'twopeneth worth'.

cheers

Dave

Dave Smith
Earth Sciences Data Manager
Natural History Museum, London

David Smith
Earth Sciences Data Manager
useravatar
Offline
52 Posts
Male  Website 
Administrator has disabled public posting. Please login or register in order to proceed.

Re: Address History and Multiple Addresses

For #1, I have to chime in with a me too! me too! I also wouldn't mind having the date of the address be available. When we're reconciling records, I have a lot of the same donors with different addresses over the span of 40 years. Being able to see them all chronologically would be wonderful.
Perian Sully
Judah L. Magnes Museum
Berkeley, California

Administrator has disabled public posting. Please login or register in order to proceed.

Re: Address History and Multiple Addresses

Hi Mark,

Some of us at The Field Museum have had very preliminary discussions about this. One of the ideas we're tossing around is modifying the Modules where historic addresses are preferable to current ones (e.g. Loans.) We are considering adding fields, either auto-fill from Parties or manual text to those modules to forever associate the addresses of people and institution at the time the record is created. Auto-fill fields might work well for future records, but might become problematic for retrospective data capture.

Adding a multi-value table to the Parties module will allow you to keep a history of addresses but won’t necessarily allow you to associate a specific address with a record in another module. (If someone knows how this could be done easily I’d really be interested in hearing about it.)

We’d be interested in any future discussions about this topic.

Janeen

Administrator has disabled public posting. Please login or register in order to proceed.

Re: Address History and Multiple Addresses

Hi Mark,
We've been grappling with this issue at Museum Victoria for some time as well and it has been one of those things we were hoping to see advance in an upgrade for all users.

Currently we face what everyone else does when as a rule we create a new Parties record to cope with Historical and/or recent variations to address. We encounter the same problem with which Party to select without having to slow down the work flow. We've instructed users who do this frequently to define a List View for selecting from multiple parties where the Party name is the same person or Organisation but the potential for different addresses is likely and relevant. We have the additional issue for multiple collection institutions - Parties sharing accross the various collection departments...it just doesn't happen on the scale that it could, though technically there is no reason why it cannot, each department has rules that tend to exclude the others way of working.

There are issues once multiple addresses are enabled within the same Party as Janeen points out and we've not quite thought through yet. So how do you ensure that you align the correct version of address with the same person/org name if it is to display forward upon linking? That is probably the main problem with how we then want to use histories, not one I'm sure can possibly be solved by a linked grid history table alone. It may need something along the lines of how Movement Histories(?) work; Once a change is made to the address fields of a party and it is save, this Imaginary module record auto creates a record and this 'referencing' record is then linked where required, the originating Party record retains the full info changes in the history table, not sure if I'm dreaming what is possible here just free ranging.

I wonder also, how do you cope with changes to a person's name eg: through marriage? Is Other Names field adequate?

We'd be happy to contribute where possible.

cheers,
Lee-Anne

Lee-Anne Raymond
DAMS Manager (Acting)
useravatar
Offline
21 Posts
Administrator has disabled public posting. Please login or register in order to proceed.

Re: Address History and Multiple Addresses

My mind spins out of control after the first 5 minutes of tryign to thnk this stuff through. It's a real doddle.

One thing that I think we need to rule out is adding a nested table a la Movement History feeding off Internal Movments module. The concept is sound: each new address entered creates a new "sites" or "addresses" record, with a date range, and this is enterd into an Address nested table in Parties. BUT... and it's a big BUT ... as David Smith mentioned above, to do this would cause some serious issues for reporting. For example: a Loan record has an attached Object record, and that has an attached creator Party record, and that Party has attached multiple addresses. Loans -> Catalogue -> Party -> Address is four layers of attachments, which would require a subreport within a subreport to work effectively in Crystal. And we all know that's not possible.

The front-runner solution at this stage seems to be the one Janeen suggests, where new fields are created in Loans module (for example) which are auto-filled from the address at the time of the party selected for the loan. This would be a bare minimum solution though, as there is nothing in the parties module to store any ties to this historical address if needed later on.

Hmmm... This is quite the problem, isn't it?

Mark Bradley – Assistant Registrar, Documentation (EMu)
National Gallery of Australia

Mark Bradley
Assistant Registrar (EMu Guy)
useravatar
Offline
147 Posts
Male  Website 
Administrator has disabled public posting. Please login or register in order to proceed.
There are 0 guests and 0 other users also viewing this topic