There’s currently no way to make the Repository the associated with a Person or Place object rather than at an address. (Repositories have no Associations nor user-definable Attributes secondary objects.)
Those addresses are not mappable nor filterable. So you can’t find all the Repositories in a 50 miles radius. And repositories lack the ability to track the provenance of a souce through the generations.
And using the Source/Repository model means a duplicate object for every relative that inherited something. (Which could be MOST of the relatives.) Then there’s the hassle of having to do duplicate data entry to sync the addresses of a faux Repository & Person because you can’t “share” addresses.
Would Catalogue be a mandatory or optional object inserted between a Source and a Repository?
While I understand the reasoning behind the approach, that seems like a lot of work for someone who simply wants to record who owned a hope chest or piece of china or something that was passed around the family over four generations as an example.
With a top level Item entity that could be added to events they would create the item for the object and then the four events for who owned it. Adding the items to the timeline or reports for the user is straight forward as is generating a timeline or report for the item.
That seems much simpler and more intuitive than having to create 4 repositories, associate them with the corresponding people, possibly create a catalogue under each, and then add the source to each catalogue. And then to add it to the user timeline you now have to back track through all that.
Stepping back a bit @Nick-Hall, this idea of Item is really about that of introducing a top level research subject that represents any inanimate physical object of possible genealogical or historical interest. Perhaps it is a ship several of your ancestors immigrated on and you want to research the history of when the ship was built, when it was decommissioned, and so forth. Perhaps it is a house a few generations of your family lived in and you want to trace the history of it and perhaps the owners to the present day.
In that same vein, I would like to see a similar top level Group object as a research subject as well. A Group might be a church many of your family attended, a fraternal organization or benevolent society or trade guild some of your ancestors belonged to, a household on a census with multiple families living in it including one of yours where the others might be relatives but you simply do not know yet. And of course in the end Family is just a special case of a Group.
Yes these things can be documented in notes, but I think there is benefit in being able to treat them as top level research subjects in their own right and I think many of our users would find them useful. Can you please give this some more thought?
This is why I repeatedly have asked for Places as subjects for Events (or events for places) and main-/sub-events.
That way you at least could have registered a vessel as a place and created a chronological history by adding events directly to that place and linked your relatives to that place. AND if there also was sub- /main events, you could have linked your relatives to the relevant sub-events of the vessel’s history (e.g., one of its journeys).
This would also be true for houses, farms, businesses and other similar entities.
As a workaround if this was implemented, artifacts/items/objects could have been registered as sub-objects of a “place”, e.g., a farm, house, vessel etc. with a custom type, and you could have created a full chronological history of that object.
The usual way to represent a house would be as a place object. We can already create events to record ownership.
A ship is a more interesting case. As @StoltHD points out, a ship can also be represented as a place. This is useful to record events that happened on board a ship, but its precise location at the time is unknown. However, when the location of the ship is known, for example when it is in a port, it would be useful to record both “places”.
Maybe a new top level object could help here?
As mentioned previously, documents and artifacts should normally be recorded as sources. However, a source cannot be the subject of an event, and I think that it would be confusing if we made this possible.
I have previously suggested introducing a Group object myself. A Gedcom Family combines two concepts: a relationship between parents and their children, and also a family group. With the current structure it is impossible to know exactly who is in the family group at any time. Also family events really only apply to the parents.
This topic is worth discussing further. Please start a separate thread for it though.
I have tried that many times, but there were so much extremely negative comments telling me that I was demanding and that I could fork Gramps and do it myself, that I deleted the topics… and after you mentioned that you didn’t think “events for places” was a thing anymore if dates were added to attributes, I gave up on both topics… sorry.
That can easily be recorded in Gramps today, you just create a new “Enclosed by” for the new area the building was moved to and add a date to that entry with type “After”.
and instead of adding the geo location to the house you add it to the embedding place (old/new address or land plot, real estate etc.)
If there was Events and Sub Events for Places, you could have recorded the whole moving Event as a Project, with all the different parts of the moving as sub-events under the main “moving event”… and each of those sub-events could have its own “embedded by” place, so not only could you plot your chronological history of the house, but you could also plot the geo location history with dates…
Not an answer but trying to register all kinds of things. Project is beginning (even if i’ll reuse already done things). Ill see if I’ll success without new category or object type in Gramps
We need to consider users who wish to maintain Gedcom compatibility. The existing “Property” type should probably be used instead of creating new types for “Acquired”, “Transferred” and “Disposed”. Extra information can be placed in the event description or users can create custom types if they prefer.
The event types of “Arrival” and “Departure” don’t appear to have Gedcom equivalents. My only concern here is that people may use them when the “Emigration” and “Immigration” types are more appropriate. I don’t see this as in issue though. In the future perhaps “Arrival” and “Departure” could be sub-events of a “Voyage”.
@cdhorn How do you plan to represent these new Item objects in Gedcom?
Are you using an event reference object to connect the Item to an Event? If so, have you thought about what roles you may need?
An heirloom such as a family bible may be both an Item and a Source. Can we use the same object for both purposes in this case? A similar situation occurs with a ship that may be both an Item and a Place.
It might also be helpful to consider how you want to display these new objects in the GUI and on any other visual output (reports, generated web site, etc.) which will need to be enhanced to support them. Not to say that should totally drive the database design, but it should certainly inform it.
Maybe we should look for a few Provenance Report examples? (Hmmm… “Provenance” might make a good category name?)
“Provenance is listed in chronological order, beginning with the artist and date of execution and moving forward to the present day. The date range of ownership precedes each name followed by, if known, birth and death dates and the location(s) of owners.” https://museum.cornell.edu/provenance-guidelines-resources
Provenance Guide - International Foundation for Art Research (IFAR)
Examples of secondary objects that might be attached:
“A signed statement of authenticity from the artist or an expert on the artist is ideal. An original gallery sales receipt, receipt directly from the artist, or an appraisal from an expert in the era are also good options. Unfortunately, anything can be copied or falsified, but these are generally good options.”
Enumerated events or attributes in Gramps that are not supported as such in the Gedcom specification can always be exported as generic events or facts with the EVEN or FACT tags just as custom ones are.
Having a wider array of non-Gedcom ones predefined in Gramps would have some advantages I think are worth consideration:
Standardized translations would be available for them.
As a result their recording would be more consistent across the Gramps user base over time so if Gedcom someday adds support for them they are already categorized and can be reliably mapped in exports.
Some non-Gedcom events like Circumcision or Brit Milah can be used as birth equivalents in certain calculations the way Baptism and Christening are used.
