Re: [Gramps-users] Suggestion: Aliases?

[Benny M. <ben...@gm...>]

2013/6/27 Jesse Meyer <da...@gm...>

> On Wed, Jun 26, 2013 at 2:18 AM, Benny Malengier <
> ben...@gm...> wrote:
>
>> Jesse,
>>
>> If all goes well, in 4.1, source title field will be gone and be source
>> name field. It will be generated automatically based on the bibliographic
>> data of the source, but in case of duplicates, user can edit it for viewing
>> in Gramps purposes only.
>>
>
> I'm looking forward to that.  Especially if a way can be made to list &
> sort on that field.
>
>
>>  As to your other suggestions to do something like that for other
>> objects. Not sure. Yes there are duplicates, but will alias make your
>> research easier?
>>
>
> I think it would reduce the chance of mistakes.  For example, right now in
> my not-too-big family tree, I have 5 Elizabeths, no known surnames, all
> except one without a birthdate.  That's not the worst cluster of
> "Elizabeths" I have - I have another 6 that all share the same surname!
>  (It was a family name.)  When trying to build up relationships with parish
> records or the like, it's a tad confusing.
>

Don't be afraid to put derived birth events. So with a date like:
Before 1800
Or:
Calculated before 1810
Gramps can still calculate with such dates, and the Calculated indicates
you derived this is some way.

Also, as said, and ID value of I0010_BJulia_dangling is not a problem for
gramps. You just need to devise a system that works for you, eg, if you
work with branches, BJulia to indicate it. Tags are another way to indicate
branches.

Benny



>
> Such a problem stems in part (I believe) to research styles.  I tend to
> build out occasionally for a variety of reasons - adding children,
> grandchildren, etc.  Sometimes its due to brick walls.  Sometimes its due
> to trying to see if a person fits in a family tree.  (Great grandma did
> label a few photos from the old country, but she wasn't that fond of
> writing down what the relationship was to her!)
> Anyways, it gets confusing.
>
> I suppose I could encode the information in the naming field, but that
> seems like I'm mixing up genealogy information with organizational data,
> and that doesn't seem like its anywhere near best practices.
>