If we were to decide that attributes should have a place and a date, that wouldn't
conflict with the current implementation. Gramps should only assume attributes
from older versions have an empty place and date.
On Wed, 03/17/2010 at 3:44pm, "Benny Malengier" <benny.malengier@...> wrote:
> 2010/3/17 Julio Sánchez <julio.sanchez@...>:
>> 2010/3/15 Benny Malengier <benny.malengier@...>
>>> Hey, but I use the occupation as an event !!! :-D
>>> Kidding aside, was this not one of the weak points: occupation as
>>> attribute or as event. Don't we have it predefined for both at the
>>> Gedcom is also strange in this respect
>> I think Gedcom has it right here, it is Gramps not believing that dates and
>> places pertain to attributes that creates the confusion. From Gedcom 5.5:
>> Some attributes of individuals such as their EDUCation, OCCUpation,
>> RESIdence, or nobilityTITLe need to be described using a date and place.
>> Therefore, the structure to describe the attributes was formatted to be the
>> same as for describing events. That is, these attributes are further defined
>> using a date, place, and other values used to describe events.
>> Since Gramps only wants dates in events, these things have to be coerced
>> into events. Then people complaint that they are not "events". Of course
>> they aren't. They're attributes.
>> The following paragraph from the never approved 5.5.1 makes this much
>> As a general rule, events are things that happen on a specific date. Use the
>> date form ‘BET date
>> AND date’ to indicate that an event took place at some time between two
>> dates. Resist the
>> temptation to use a ‘FROM date TO date’ form in an event structure. If the
>> subject of your
>> recording occurred over a period of time, then it is probably not an event,
>> but rather an attribute or
>> I cannot agree more with the above.
> I agree somewhat too, but is it worthwile in Gramps to add place/date
> to attributes as a non-shared object, like event was before they
> became sharable objects?
> In other words, in the past some design decisions where made, and now
> we are stuck with them. How do we move forward with this issue that
> keeps coming back? Do we aim at making attributes like events, or do
> we aim at making attributes like non-sharable events (so nothing like
> eventref), or is there another way to migrate to something different?
> And if we change, will users not find it strange that something like
> 'eye color' can have a date and place?
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> Gramps-devel mailing list
Powered by the 6zap. Sign up at http://www.6zap.com for an account that provides advanced e-mail, calendar and contacts capabilities.