Guess I’ve used Rootsmagic too long. RM allows you to use a title for both sources and citations that can be anything you want as it doesn’t show up any report with another field with the source name. I use it to differentiate between the different databases I use with Ancestry or FamilySearch by putting a "- Ancestry) at the end of the source title as Ancestry and Familysearch have databases with the same names. For citations I use a reverse naming system followed by a short description of citation to make it ease to find the citation. I could use the search to find them, but I find this easier.
1 Like
“Title” could be useful for newspaper or magazine articles. I use the name of the newspaper or magazine as the Source’s Title, and the Date, Volume/Page to identify the particular issue and the location within it. Having a Citation Title for the title of the article would be nice.
1 Like
My current method is to store “Shawnee County, Kansas; population schedule; Topeka; ED 5,” in the Source’s Title, and “sh 1A, dw 23, fm 45” in the Citation’s Volume/Page (though I format each of those differently). Having a Citation Title to store “John Doe household” could be nice.
I use the reference of the document as title. Example:
Latillé - 5 MI 0321 - 9 E 147/12 - Naissances 1883 - 1892
Latillé is the town in france
5 MI 0321 is the old document ref
9 E 147/12 is the new document ref
And we have the title of that book.
This is sufficient for me. I know the repository, the book and the page.
My 2p worth.
I would like to see improvements in the ability to enter and analyse data in context and report data/conclusions.
I fully support the initiative to expand the capability of ‘forms’ to create multiple events. There is also the need to retain that context when reporting. The patch to Narrated Website in order to report roles is a start and ought to be extended to include all actors and attributes in the associated events (per marriage event).
As current reports appear to rely on event descriptions to identify reported events, it would be desirable to automate the event descriptions to avoid having to re-enter data.
As forms are based on sources, extensions to support evidential analysis and conclusions about a person/event would be very welcome. Currently, I’m test driving Evidentia as my research has moved beyond low hanging fruit.
Reporting research conclusions or just autobiographical data in context, often seems to be the poor relation to data entry in all genealogical s/w. Some limited attempts at narrative reports have been made, but I’m wondering whether consideration of AI driven narrative reporting should be considered. MyHeritage are already offering AI produced autobiographies.
2 Likes
Regarding the latter point, do you mean something like this feature request? I would find that very useful, especially for censuses.
1 Like
Yes. That feature request illustrates the idea quite well.
Obviously a feature like that will have to be discussed first and then someone would have to come up with a suitable design. It won’t be included in v5.3, but we can start a discussion.
Replying to myself.
Just discovered the ‘Extract Event Description’ function which achieves the automatic creation of an event description. The function name is misleading. A more meaningful one is needed. How about ‘Event Description Creator’.
Is the ‘Extract Event Description’ tool actually useful anymore?
Before we added a participants column to the event view, it was useful to include the main participant in the event description. Now we can generate such a description automatically.
The event description field is mainly used to qualify the event type and is exported to Gedcom in the TYPE tag.
I actually need a tool to UNDO the effects of this tool. The ability to generate such a description automatically is so much better.
I was exploring tools and this particular Evil tool did not warn that it is about to do en masse changes nor that those changes cannot be Undone.
It seems to properly warn now
1 Like
That is another one I would like to see come from the Form straight to
the Event
I use this to differentiate between the England, Wales, Scotland Census
so typically “1891 England” or “1891 Scotland” because these are unique
and different Forms
phil
Yes, it is! I, for one do not want to enter data twice. The event description is needed for certain reports (e.g. Detailed Descent, Complete Individual & the Web Narrative Report) to make them intelligible.
Are we referring to the same tool. Extract Event Description certainly does mass changes, but they are editable and does not overwrite what is already there.
Yes. We are talking about the same tool. I consider what it added to be redundant “noise” since Gramps generates it from compositing other data entered in descrete fields that are typically shown at the same time. Worse changing those fields does not update the description.
My objective it to migrate data that was stored in an unstructured description into structured data fields … so analysis is possible. This “noise” just hides data that still has needs to be migrated.
For the 5.3 roadmap, could you add inclusion of the “Isotammi project on GitHub” to the default project list?
But it should be deselected by default since many of its add-ons are marked as “Expert” so an “opt-in” is more appropriate. (Users “opting in” are a bit more likely to check the documentation. The “Other Projects” listing for the Isotammi project on GitHub in the Wiki will need to be improved and moved to the “Projects” section.)
No problem. I’ll add it to the list.
2 Likes
Over at the Zotero forum, they mark all the beta topics with [Beta Zotero 7] and then a description…
Could we maybe you something like that here also?
e.g.
“[Roadmap 5.3] - Citations, Sources and Repositories”.
“[Roadmap 5.3] - Performance issues”
“[Roadmap 5.3] - Enhancements of Types”
I would like to be able to assign locations (from the locations tree) to images. Photos always include the location where they were taken. Don’t they?
2 Likes
Adding the Photo to the Gallery for a Place pretty much does that.
Also, it seems like the standard metadata is the proper data record for that specific data elements as text.
As an example, see a 2018 Adobe Lightroom question
I know I’m repeating myself but from my viewpoint the most urgent problem to be resolved in v5.3 is the performance problem. Without that all users with large databases will be stuck in v5.1.6 with BSDDB as backend.