repositories and locators are about the researcher
Jul 20, 2024 22:41:26 GMT -8
Post by Uncle Buddy on Jul 20, 2024 22:41:26 GMT -8
I was almost finished with the 3rd rewrite of the repositories and locators feature when I realized that this data does not belong in UNIGEDS.
Repositories are collections of sources. Locators are codes that lead directly to a source or citation even if you don't know anything else about the source or citation. For example, if the repository is a website, the locator is a URL. If the repository is a library, the locator is a call number. If the repository is a cemetery, the locator is a plot number or something like that.
Where a source was found is almost always irrelevant to casual genealogists who are doing it for fun. Obviously it can be very relevant to someone who takes genealogy more seriously. That doesn't make it primary data. Repositories are about the research results, not the history. Repositories are a secondary element of genealogy. One thing that's wrong with GEDCOM is that it has never limited its scope in a meaningful way. GEDCOM should have never included tags for data that's about the app, the researcher, or the app's creator or vendor. According to the "don't start something you can't possibly finish" principle, this is a mistake that will turn what could have been a useful tool into a fruitless waste of energy, like a guy on a horse trying to herd a pack of hyenas. An example of missing this principle is when GEDCOM starts making tags for events instead of just using EVEN.TYPE for all events, which is simpler and better and serves the same purpose without jumping into a rabbit hole or doing one thing in multiple ways.
Treebard's main script--the code that you run to start and run all the other code--is a python module called treebard_root_040.py. Removing repositories and locators from Treebard and UNIGEDS will be done in treebard_root_041.py, which will probably be the end of it for me. Anyone who wants can continue the project since all the code is public domain and will be made freely available as a .zip file and an .exe. Here are my notes on this decision:
In 041, all traces of repository and locator elements will be removed from all modules. I realized that repositories are one level removed from being a primary element of genealogy and locators are two levels removed. In Treebard, repositories can be saved in a source or citation note if desired, and locators can be saved in the same place or in a citation. A little research gave me the impression that it's common to include a URL in a citation and uncommon to include a call number in a citation. This sort of inconsistency makes the topic a can of worms. According to the "don't start if you can't finish" principle, genieware should not build code for something can't be defined and limited to fit into a simple, self-containted, self-explanatory data structure. Personally as a genealogist I've found it an extra unwanted step to keep track of repositories and locators, not because I didn't have a place to put them, but because it's too much trouble since I've already saved a copy of the information in my files. In the rare case when I need to know where I found something, I can go to my files and figure it out, or do another search. When you start building a data structure to store repositories and locators, the details blossom, they seem to be self-replicating, the possibilities are endless, the cardinality of the relationships is muddy and subject to interpretion. All this is not in proportion to the repository's usefulness. I'm not saying that genieware should not keep track of repositories and locators, but I'm saying that this doesn't belong in UNIGEDS because it's about the user's research and not about the primary historical data being recorded. The genieware vendor can add tables to his genieware's copies of unigeds.db to track this researcher data if desired, but all I'm going to do in Treebard is to add a place in the sources tab where the user can link a note to a source and/or citation. My GEDCOM import program will save data about repositories in notes. As for exporting to GEDCOM, notes linked to sources and citations can be manually gleaned for repositories if they're so important. It's interesting to note that GEDCOM does nothing particularly sensible with repositories, in fact some of GEDCOM's most misbegotten features are in regards to repositories. I now see why: GEDCOM has mis-identified repository as a primary element of genealogy. (While not doing anything like that for obviously primary elements such as place, name, citation, and event.)
Something else that comes to mind is that the genieware cannot tell the user how to write or format a citation. This belongs firmly in the category of "don't start what you can't finish". Others will want to include a dedicated GUI for saving repositories and maybe locators, but Treebard doesn't need that feature because Treebard is only for primary features plus anything else I feel like doing, UNIGEDS is strictly for primary features only, and I don't feel like writing a hair-splitting GUI for this. A muddy category like this can't be done "right", so I'm leaving it open and notes are one way to do that.
Repositories are collections of sources. Locators are codes that lead directly to a source or citation even if you don't know anything else about the source or citation. For example, if the repository is a website, the locator is a URL. If the repository is a library, the locator is a call number. If the repository is a cemetery, the locator is a plot number or something like that.
Where a source was found is almost always irrelevant to casual genealogists who are doing it for fun. Obviously it can be very relevant to someone who takes genealogy more seriously. That doesn't make it primary data. Repositories are about the research results, not the history. Repositories are a secondary element of genealogy. One thing that's wrong with GEDCOM is that it has never limited its scope in a meaningful way. GEDCOM should have never included tags for data that's about the app, the researcher, or the app's creator or vendor. According to the "don't start something you can't possibly finish" principle, this is a mistake that will turn what could have been a useful tool into a fruitless waste of energy, like a guy on a horse trying to herd a pack of hyenas. An example of missing this principle is when GEDCOM starts making tags for events instead of just using EVEN.TYPE for all events, which is simpler and better and serves the same purpose without jumping into a rabbit hole or doing one thing in multiple ways.
Treebard's main script--the code that you run to start and run all the other code--is a python module called treebard_root_040.py. Removing repositories and locators from Treebard and UNIGEDS will be done in treebard_root_041.py, which will probably be the end of it for me. Anyone who wants can continue the project since all the code is public domain and will be made freely available as a .zip file and an .exe. Here are my notes on this decision:
In 041, all traces of repository and locator elements will be removed from all modules. I realized that repositories are one level removed from being a primary element of genealogy and locators are two levels removed. In Treebard, repositories can be saved in a source or citation note if desired, and locators can be saved in the same place or in a citation. A little research gave me the impression that it's common to include a URL in a citation and uncommon to include a call number in a citation. This sort of inconsistency makes the topic a can of worms. According to the "don't start if you can't finish" principle, genieware should not build code for something can't be defined and limited to fit into a simple, self-containted, self-explanatory data structure. Personally as a genealogist I've found it an extra unwanted step to keep track of repositories and locators, not because I didn't have a place to put them, but because it's too much trouble since I've already saved a copy of the information in my files. In the rare case when I need to know where I found something, I can go to my files and figure it out, or do another search. When you start building a data structure to store repositories and locators, the details blossom, they seem to be self-replicating, the possibilities are endless, the cardinality of the relationships is muddy and subject to interpretion. All this is not in proportion to the repository's usefulness. I'm not saying that genieware should not keep track of repositories and locators, but I'm saying that this doesn't belong in UNIGEDS because it's about the user's research and not about the primary historical data being recorded. The genieware vendor can add tables to his genieware's copies of unigeds.db to track this researcher data if desired, but all I'm going to do in Treebard is to add a place in the sources tab where the user can link a note to a source and/or citation. My GEDCOM import program will save data about repositories in notes. As for exporting to GEDCOM, notes linked to sources and citations can be manually gleaned for repositories if they're so important. It's interesting to note that GEDCOM does nothing particularly sensible with repositories, in fact some of GEDCOM's most misbegotten features are in regards to repositories. I now see why: GEDCOM has mis-identified repository as a primary element of genealogy. (While not doing anything like that for obviously primary elements such as place, name, citation, and event.)
Something else that comes to mind is that the genieware cannot tell the user how to write or format a citation. This belongs firmly in the category of "don't start what you can't finish". Others will want to include a dedicated GUI for saving repositories and maybe locators, but Treebard doesn't need that feature because Treebard is only for primary features plus anything else I feel like doing, UNIGEDS is strictly for primary features only, and I don't feel like writing a hair-splitting GUI for this. A muddy category like this can't be done "right", so I'm leaving it open and notes are one way to do that.