Betty currently allows users to map some types of values as they appear in Gramps to Betty plugins. For each of the following, could you confirm whether they (are supposed to) allow custom values or whether they are restricted?
Thanks! 
Gender is fixed at 4 valid values, no custom types.
The other 3 allow custom types.
You can validate with the Types Cleanup Tool addon that list custom types and allows their renaming/removal.
The tool only lists those items that support custom types. (This might be incorrect. Needs testing. It might also allow resetting type values from-standard-to-standard.)
I believe that the reason āgenderā does not support custom types is due to the features that compose conversational text and adapt pronouns based on gender.
There are features that let cultural bias be applied to the pronoun decision. So adding a new gender requires a lot of tweaking for all the supported languages/cultures.
Hi Brian, thanks for confirming my most recent findings!
The way I did it in Betty was just make gender a plugin, provide a few defaults (male, female, non-binary, unknown) and let the community decide which others they want. I may want to distinguish between sex and gender in the future purely because official documents may not reflect someoneās gender (at the time), but other than that there are no further implications, mostly because I aim to keep all translatable strings gender-neutral (regardless of the number of genders, that also avoids clunky and unpleasant things like āhe/sheā and āhis or hersā).
Anyway, this was just to confirm what Gramps does right now. I erroneously assumed genders were unrestricted like the others, and had added mapping support for that to Betty, but it seems I can now greatly simplify that.
Thanks again!
You could use a custom Attribute for the Person object as a Gender āmodifierā instead of a custom type for Gender.
The value for an Attribute is typically a single data point. But it could be an array, XML or JSON too.
Betty already does (The Gramps extension - Betty documentation). Thereās also a legacy gender mapping configuration that users can set, but I can remove that now.
Interesting! Those Betty link attributes should probably be integrated into the UID concept in WebSearch addon by @Urchello too. Likewise, whatever external ID schema that is used by Gramps Web (and Gramps Web Sync) by @DavidMStraub
Which means you and David should probably examine the WebSearch addon for irreconcilable conflicts before it is released via the Addon Manager. It will likely quickly achieve Critical Mass (too many users with too many Attribute records to change. So influencing change becomes difficult) as an external ID standard for Gramps. So you wonāt want a conflict there.
So the thing about these attributes is that, yes, theyāre Gramps attributes, but theyāre meant to map data to Bettyās own data model, which means that these specific attributes will not be useful outside a Betty/Gramps ecosystem. That said feel free to be inspired. I mostly use them to address āmissingā functionality in Grampsā data model, where Betty allows for more detailed information (such as privacy, which in Gramps is binary and in Betty is ternary).
I almost grok thatā¦ but not quite. (Which is why I hope external application developer will have a private discussion about internal IDs. Inserting myself will just expose my ignorance.) By my guesswork about web GUIs layered on the Gramps engine ā¦ or leveraging its import/export engineā¦ is that Persons, Families, Places, Sources will have URL patterns to invoke the Editor/Viewer for that data. And that pattern will probably need awareness of your internal identifiers to substitute into the URL.
Moreover, the Internal ID should be stored in the database in a way that the more mature Gramps Gtk-based gui can reference and edit. (So Syncing to Gramps Web and reuploading data to Betty can become more seamless.) The GrampsWeb addon could test/validate that the Internal ID could be called from the Gramps Gtk gui to the independently hosted Betty or Gramps Web site.
Yes, this was one of the places where the Gramps importer was ādingedā in John Cardinalās GEDCOM Assessment report. It had more flavors of āPrivateā than Gramps supported. They looked interesting.
Iāve also been thinking about how our web-based reportsāNarrated Website @SNoiraud, Dynamic Web Report, Gramps Web @DavidMStraub, and possibly Betty @bartfeenstra (I havenāt installed it yet)ācould be integrated with the WebSearch gramplet in a useful way.
The idea is that websites could allow access to person pages and other resources using Gramps handles. These handles can be stored as attributes for each person in the Gramps database. For example, I use a Supertool script that creates an attribute called _GRAMPS_ID with values like f7be4fcb5d74bca545e25f5d57a for every individual.
If a website supports opening person pages via these handles, we could then configure WebSearch to generate direct links to the relevant person (and not only person) pages. This would create a seamless bridge between local Gramps data and external web-based resources.
It may need to include a Tree ID/handle too in order for versioned data to be uniquely identified. Possibly also a Last Changed timestamp for the object.
If multiple users are collaborating through Gramps Web via Gramps for Desktops (Gtk gui) and Gramps Web Sync, then they probably have harmonized object handles. But their Tree handle and timestamps will probably differ.
so, maybe its time to have any unique and fixed Gramps identifier and import-export it everywhere like FS, MH?
While Iām fascinated by where the conversation has gone, Iām a little lost 
Do we want UUIDs/GUIDs in Grampsā? Arenāt the handles those already?
Only for external IDs as a way of facillitating collaboration.
Thereās no way that the trees of cousins will align fully. Each cousin will have one parent line and (probably) a spouse line that will be of little interest to the other cousin.
So the current Gramps Web Sync is probably going to have to evolve to sync more selectively in the future. (Thereās also no way that 16 collaborators will want to sync into what essentially becomes a āWorld Treeā on each local machine.)
And a Tree annotation is probably whatās needed to simplify segmentation.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
