Attributes as an Information Service

I really like @bartfeenstra’s idea for Betty to create attributes to specify the behavior Betty should have regarding certain data that should be made private in the context of a publication.

It could be hijacked for all reports (and maybe more than reports, for some other gramplets too like my request for Historical Context Gramplet) to define more things than just the padlock: for example, for a given report, I want this information to be included or not regardless the padlock state, but for another report I don’t. I want specific information about Belgium in this Gramplet (Historical context, WebSearch…) because that person with that attribite is from Belgium… The competing version of Dynamic Web Report - DWR2? - also did this to some extent to define fields like a mini biography that appears at the top of the person’s page (with, from memory, the Why me attribute or a photo attribute).

Unless Betty, DWR2 don’t use a prefix for it’s atrribute’s name (but maybe it can be configured, I don’t remember anymore), so it could be difficult to not have its specific information elsewhere. Each report/addon/… could have it’s own series of attributes with its own prefix to atrributes name to handle data differently, or to add specific information in that report/addon, depending on the user’s choices. And, attributes with specific prefix should not use data from other, non generic, prefixed attributes.

A system of this type would probably require what @emyoulation proposed in the WebSearch discussion: to have these technical attributes (those, the various UID attributes, etc.) managed alongside the purely genealogical attributes so as not to be polluted by their volume (and maybe not exported into gedcom files ??)

1 Like

Hi! Nice to see Betty’s attribute use piqued your interest.

To expand on why Betty does this, the short reason is that the Gramps and Betty data models only overlap partly. To take privacy as an example, Gramps support binary values (public/private) while Betty supports ternary values (explicitly private/explicitly public/implicitly public and may be overridden by Betty or it’s extensions). Also Gramps does not support privacy at all on some object types. Finally, Betty allows attribute names to contain Betty project names, so the same attributes may be used more than once, with different values per project.

By using attributes, Betty allows users to use the “implicit public” value not present in Gramps at all, add privacy to objects Gramps does not collect privacy for, or override these values per Betty project (the attributes may have a Betty project specific machine name in them).

As you can see these are all really specific to the combination of Betty and Gramps, and while these attributes constitute a public API (they are stable and may be used by other software), they may not be optimized for anything other than Betty. The general approach has been working successfully for some years now, so I can recommend using custom attributes as a working solution to improved integration with Gramps’ already expansive data model.

2 Likes

Restrictions is an interesting topic.

John Cardinal’s discontinued GEDCOM Asssessment site outlined RESN Restrictions and where Gramps ignored, rejected or imported incorrectly the Private, Confidential, and Locked restrictions found in other GEDCOM databases.

2 Likes

From GA: Restriction :

For example, data from requested downloads of the Ancestral File may have individuals marked with ‘privacy’ if they are assumed living, that is they were born within the last 110 years and there isn’t a death date.

Interestingly, this is why Betty allows an undetermined privacy (implicitly interpreted as public during private/public tests). The Privatizer extension shipped with Betty will automatically try to determine if people and associated entities must be marked private explicitly based on a configurable lifetime threshold, but only for those entities with an undetermined privacy. This means that setting an explicit privacy (public or private) in the source data will prevent the Privatizer from making changes.

2 Likes

How closely does the Betty Privatizer parallel the “probably alive” in the Gramps Alive utility?

I had a very, very brief look through that code:

  • Betty has start-of-life (birth, baptism, etc) and end-of-life (death, funeral, burial, etc) events for this purpose (whereas Gramps only uses birth and death). This is old code and may need some tweaking because people can be baptized as adults, for example.
  • Betty does not yet fully use all ancestors and descendants to determine a person’s aliveness but there’s an issue to expand that which should result in a slightly lower percentage of people being marked private when they are in fact dead.
  • The Privatizer not only determines people’s privacy, but will also traverse private entities to make related entities private. E.g. if a source is private, so are all of its citations. If an entity is private, so are all of its directly associated files.
1 Like

Is this a part of the Gramps engine that you would recommend enhancing? Do you want to reduce redundant code between Betty and Gramps?

No.
look at the code for get_birth_or_fallback and get_death_or_fallback in gramps/gen/util/db.py

2 Likes