Benny Malengier wrote:
> 2008/2/17, Dave Walton <email@example.com <mailto:firstname.lastname@example.org>>:
> Also, an Address has a field for a phone number. One phone number.
> Plenty of people in my family have two lines at home, so I'd have to add
> a second Address to enter their second line. And then there are cell
> phones, which aren't tied to an address anyway.
> Thinking about it now, addresses, phone numbers, email addresses, web
> sites, etc are all ways of locating someone, in one way or another. So
> the current Addresses and Internet tabs could be combined into a single
> tab (still called Addresses? or Contacts? or ?). That tab could
> contain a list of entries of all those types, each with a date range,
> source and notes (which Internet tab items currently do not have).
> Gramps is a genealogy application, not a PIM suite, so I suggest you use
> one of the many good addressbooks out there ;-)
On the contrary, one might argue that as a genealogy app, Gramps is the
ultimate PIM. :)
A PIM lives in the now. All it cares about is the current details for
people, and has no concept of sources or history. I'm simply observing
that things like email addresses and web pages apply to a certain period
of time, like addresses. Which leads me to wonder why Gramps has them,
but doesn't allow for either source references or historical placement
for them. Also, phone numbers and addresses no longer have a 1:1
relationship, or even matching timespans. I've had the same number at
multiple addresses, and I know people who have had several different
numbers at one address.
So my point is that, for different reasons, Gramps is unable to capture
the timeline aspects of things like phone numbers and email addresses.
And while I expected someone might point out that Gramps isn't a PIM,
and agree with that distinction, I think you'll also agree that a PIM is
a poor genealogy application.
> Apart from that, read:
That's an interesting article. Thanks for the tip. It makes a good
argument for me to go change my Address records to Residence events
(which I previously didn't pay much attention to).
One of the things that has bugged me about Address, and I suspect was at
least partly Gerald's motivation, is that it uses its own data fields
instead of referencing a Place. After reading that article, I realize
that if you change Address to reference a Place, you've turned it into a
Residence event. So what's really been bugging me is that I've been
using Addresses instead of Residence events. :)
The article mentions that the disadvantage of using Residence events is
that alternate locations for a Place don't have date spans. Note that
one of Gerald's suggestions was to add a date span to alternate
locations. I suspect that if that were done, most of his points would
be satisfied by using Residence events instead of Addresses.
But now I'm puzzled... Why does Address exist?