Re: [Gramps-devel] Relative dates & Name-usage periods

[Luke-Jr <lu...@da...>]

On Friday 04 March 2005 00:54, Alex Roitman wrote:
> On 03/03/2005 04:18:55 PM, Luke-Jr wrote:
> > Many times, information on the dates of events may be unknown. In this
> > case, GRAMPS is unable to sort events by date properly. Is there any
> > interest in a special date that is defined as being 'before EventList'
> > and 'after EventList'? Not quite sure how it would be implemented, but it
> > shouldn't need too much of a complex change...
>
> This sounds interesting. Few thoughts:
>
> 1. In STABLE version, the events belong to people. In other words,
>    they cannot be shared. So even if the event is common for several
>    people, each has to be entered to a person.
>
>    In HEAD (and in the upcoming 2.0), events are first-class objects.
>    Events exist independently of people, and can be shared. However,
>    we haven't compe up with a good way of editing the events. At the
>    moment, one can create event, but not delete it, nor change references
>    to an existing event. So the events are effectively used as
>    the second-class objects so far.

So, this feature would probably only be possible with HEAD... Do you mean that 
HEAD does not allow editing or deleting of events at all??

>    Both ways have pros and cons. The difficulties I see with defining
>    date by event are these: what if the event is deleted? does the date
>    reference disappear? What if the event has the date, which in turn
>    is defined by that same event? We get an infinite recursion.

Well, I purposely proposed before/after event *lists* so as to allow multiple 
events to be defined as before and multiple as defined as after, so hopefully 
there would be a fallback. I would suggest having such references be fully 
refcounted along with person references to an event, and simply mark the UI 
(event editors & validators) when an event is referenced solely in relation 
to other events.

If EventA is defined as before EventB and EventB is defined as being after 
EventA, I don't see the problem... it might confuse humans, but it should 
still sort perfectly fine. In fact, if EventA is defined as before EventB, it 
might even make sense to have a loose-reference (auto-deleting) in EventB 
stating that it occurs after EventA. 
The problem comes in when you have something like this:
EventA occurs before EventB
EventB occurs before EventC
EventC occurs before EventA
Obviously, this is impossible (until some form of timetravel is invented, if 
ever or even then). The only thing GRAMPS could then do is have validation 
errors and sort all three events ignoring their relation to each other.

> 2. If we work out some rules to overcome these problems, we would still
>    need to come up with some meaningful ways of editing the events.
>    Some sort of Event view. The problem with that is that there can be
>    too many events, and no good way to name or label them for some kind
>    of list/tree view. Any thoughts on this would be appreciated.

When browsing for an event, just have a person/family selected before you even 
list events.

> > Another thing I was thinking about is associating time-periods with name
> > usage.
>
> Do you mean to provide a date (or range/span) for a name? This should
> be useful, and not so hard to do.

I suppose it could be phrased that way.

> > ... Associating time periods (eg Birth-1990;
> > 1990-Death) might help this problem. Another possible (but not as
> > flexible) solution to such a problem could also be having name types
> > implemented in a way that instead of selecting either TypeA or TypeB, you
> > could select both or more. Then, one could select both Birth and Maiden
> > types or Other and Maiden types.
>
> I don't quite see how more than one name at the same type can be useful.
> Am I missing something?

A name might be a Birth name, but not a Maiden name if the name was changed 
between birth and marriage. Likewise, a Maiden name is not necessarily also a 
Birth name.