Benny Malengier wrote:
>
> 2009/7/3 guylinton <guy.linton@...>:
>
>> [trim]
>> So ideally, the solution should (where the event is used elsewhere)
>> emulate
>> such a shared event approach. Hence, in GEDCON export, each attribute of
>> the
>> person event should be output as an INDIVIDUAL_ATTRIBUTE_STRUCTURE with a
>> copy of the INDIVIDUAL_EVENT_DETAIL (you also need to pick up the age
>> attribute from the person event). On GEDCOM import, ideally one would
>> determine whether an event already existed with the same details (except
>> type), and if so,
>> (a) if the existing event is an INDIVIDUAL_ATTRIBUTE_STRUCTURE event, and
>> the new event is an INDIVIDUAL_EVENT_STRUCTURE demote the old event to an
>> attribute and insert the event as the event details.
>> (b) otherwise add the attribute as an attribute of the person event.
>>
>> I am not sure what one should do with person attributes (if they exist at
>> present) that are not linked to events. Possibly one should just export
>> and
>> import then as INDIVIDUAL_ATTRIBUTE_STRUCTURE without the event detail?
>>
>>[trim]
>> Regards, Tim.
>
> Your mail makes for some very difficult reading :-)
> I have a bit the impression you devise a system that works somewhat
> like you are entering data today in GRAMPS , but that that leads to
> inconsistencies.
>
Sorry, I didn't fire up Gramps, so may have used some of the wrong
terminology. Also, Sorry if I was unclear, but I tried not to be too
verbose, so may have skipped some points.
Benny Malengier wrote:
>
> If I understand correctly, the way you would do things in GRAMPS is:
> * leave attribute in GRAMPS as is, but do not consider it something
> that exists in GEDCOM
>
My particular concern was with attributes that appear in event references. I
want to leave those as attributes in GRAMPS. For output to GEDCOM, they
would appear as INDIVIDUAL_ATTRIBUTE_STRUCTURE. These are a particular
concern to me because of the use cases that involve them, as I described for
Occupation.
Benny Malengier wrote:
>
> * what are attributes in GEDCOM should be entered in GRAMPS as events
> of the specific type (like OCCU now, ....), and the user should put
> the value of the attribute in description or the attribute tab ? So
> somewhat the solution Gary proposes?
>
> This however waters down the distinction between an attribute and an
> event. It seems usefull to me that this distinction remains presents.
> I like what Julio said:
> ====
> Events are things that happen at some point in time (that we may not
> know precisely, though), at some place, may involve several people
> (witnesses, officers, notaries, priests, etc.) and may of course have
> sources, notes, media, etc.
> Attributes should describe situations that may be permanent or
> temporary (start at some date, end at some date, etc.), may be
> associated to a place (a position held, residence, etc.) or may not
> (eye colour, height, caste, profession, etc.). They may have sources
> and notes, maybe even media.
> ====
>
> One could have individual attributes just like events, but have the
> display different to indicate clearly the slight difference in
> meaning.
> For event:
> type | subtype | date | description
> | place
> Baptism Roman-Catholic 2007 Baptism of John Doe
> New York
> For individual attribute:
> type | subtype | value | date ....
> Trait Eye color Blue
> Occupation Tailor 2001 - 2004
>
>
>
As far as the attribute tab of the person (editor), there really is no
difference in GEDCOM between INDIVIDUAL_ATTRIBUTE_STRUCTURE and
INDIVIDUAL_EVENT_STRUCTURE, so it makes sense if they have the same (or very
similar) properties. Therefore I agree with Gary that these attributes
should be treated effectively as events. Whether you have two separate tabs
in the person editor, one for events and one for attributes or only a singe
tab is then a matter of taste. The things that are displayed on the display
are just an arbitrary selection from the reference object and the event
referred to. (The only difference in the GEDCOM is that attributes always
have a value, but events don't - except for the 'Y' attribute of Birth and
Death to confirm that they are known to have occurred when nothing else is
known).
My point was that if the attribute is truly associated with the event, then
from a data input point of view it is much simpler to have the attribute in
the event reference, even if it then has to be output to GEDCOM as an
attribute with a copy of the event, and has to be re-created on input.
I think I agree with your distinction between attributes and events. If the
source really refers to an 'event' then it should be input (by the user) as
an event (such as a census taking) and the attribute should be stored (by
the user) as an attribute of the event. Only if there is no real event
should the user input it as an attribute on the person. For example, if a
book says X was made a Baron on 15 Nov, then there is a clear event of
ennoblement on that date, and the TITL is an attribute of the event. Only if
the book just says 'he was a Baron' would it make sense to create an
attribute for the person, with a reference to the source.
Benny Malengier wrote:
>
>> It seems to me far more important to associate the attribute with the
>> event,
>> rather than to introduce a new way to get at an event through a person
>> attribute.
>
> but the solution you propose for GRAMPS does away with attribute and
> only leaves an event. If somebody wants to store: occupation: tailor,
> will he not find it strange to click on the events, press add, and
> enter that there.
>
I was trying out a genealogy application recently (no good for me as it was
MS Windows which I don't have) and it had a single tab under person (called
events) which held both events and attributes. Hence, in this application,
if you wanted to store 'occupation: Tailor', you would have to add an event
with the event type OCCU. This does not seem to be very strange, just
another way of looking at things. It is after all more or less how GEDCOM
looks at things.
Benny Malengier wrote:
>
> Important to note is that an attribute is not a shared thing, it is
> unique to the person, whereas events are shared. Well, looking at
> GEDCOM again, events are not shared there no? This is a GRAMPS
> extension. Nevertheless, we need GRAMPS to be consistent first,
> support for GEDCOM is very important, but should not result is an
> unusable application.
>
Well yes, in GEDCOM, events are not shared. It makes sense to handle
attributes of person in a similar way by having a reference to a shared
event.
Benny Malengier wrote:
>
> PS: About the many clicks, try to use CTRL+P/N Ctrl +Insert, alt
> hotkeys, ... Hiding the mouse really helps here ;-) Joking aside,
> there have been some ideas to make data entry faster, just no
> developers that implement it.
>
Yes, I know, and wholeheartedly agree, my excuse is that I am using Gramps
on a Mac, so some of the modifier keys are Mac and some are Linux, so my
muscle memory almost never gets it right!
Regards,
Tim.
--
View this message in context: http://www.nabble.com/Proposal-for-a-GEDCOM-change-tp24312547p24327186.html
Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
|