* [Wish List entry 599] Allow citation fields in bibliography on sources

[jnunnally]

Correct, I was using the equivalent of {access_date:YEAR} in some bibliographic entries. I can't imagine how software would generate a range of access years. That would involve some very sophisticated analysis of the citations included in the document.

Certainly this "need" would not apply to ALL bibliography entries, but certain sources do seem to warrant it.

[jnunnally]

I apologize for splitting my response over two postings...

I would not include an access date in the bibliography for a parish register. Although they may appear on a web page, the data is fairly static.

Many people cite on-line family trees in various forms. Without debating how good a source that might be, if such a web page is going to be cited, an access date makes a great deal of sense. Such pages will likely go through many revisions. For books, there is little argument that "3rd edition" should be part of the bibliography. Although a book is a much more static source, the fact that there are revisions over time is considered significant.

[AdrianBruce]

... I can't imagine how software would generate a range of access years. ...

I presume that the current sensible way would be to hold the range of access years against the Source-Record (not the Citation) and update the item manually as required.

Correct, I was using the equivalent of {access_date:YEAR} in some bibliographic entries. ...

Then I would suggest that one possibility would be to hold an Access-Year against the Source-Record, not the citation. If your access were to go into a second year, then you'd need to create a second Source-Record, with a different Access-Year.

It's not ideal and I think it's messy, but if full adherence to an ESM format is necessary then at the moment that's the only possibility that I can see.

I guess that the thing is - how many Citation level items need to appear in a Bibliography / Source List?

Access Year is the one that I know of so far. I wonder if Calico Pie could create specific handling for that? Something about writing some specific handling for Access Date in the Citations, in order to generate Access Date or Access year in the Bibliography / Source List? It sounds messy but it may be less messy than ripping apart the data model that they have in-place already.

Online Trees - certainly an access date is needed at the Citation level. Presumably with the Year at the Bibliography / Source List level again.

Re "3rd edition" etc - surely that's always put into the Source Record (along with the publication year, etc.), not the Citation? If so it's not an issue.

Any other specific items welcomed...

[cwhermann]

To address this issue, I elected to create a source level field titled YEARS to capture the years I access the source. By using a text field, I can enter a single year or 2011-2013 or even 2020-present. Easy to update, if needed, when entering a new citation from the source.

I have done the same thing for URLs when citing digital images. At the source level I have a field called SITE URL where I enter the home page of the website. In the citation I use a field titled LANDING URL where I enter the link directly to the image I am citing.

[Gary_G]

Adrian;

I think you will find that Shown Mills shows examples of year-range being used in some of her examples of citing city directories. One tends to have references to several years worth of those as one traces a persons residence. So, yes, the "Source List" or "Bibliography" does use simple ranges of years and the poster could mimic this in a Lumper database by putting a <{Years_Consulted}> field in the Source portion and referencing that in the "Source List" or "Bibliography". One could then update it before publishing and supply the range of dates used. It might even be possible to automate the process. As the source change would affect all instances, the bibliographic entry should only be printed once in the report. Does that help?

Note: I just noticed that a previous poster has suggested something similar. :>)

[jnunnally]

I appreciate all of the insights and adding a date at the source is the obvious solution. Without looking at every instance in my database, I imagine it will address them all adequately. I don't use them very often. It becomes a work flow adjustment which is "do-able" but it also requires a memory which is becoming a more precious commodity every day! Thanks again to Adrian, Gary, and cwhermann specifically for picking this topic back up.

[ColeValleyGirl]

It has been suggested (Unblocking the Wish List process (21942)) that this (combined with Field codes for Source Template Definitions (20743)) be reduced to a request to "permit citation level fields in Bibliography".

This wouldn't include the 'Extended Bibliography' which we've discussed here (to distinguish it from the well-defined term 'Bibliography') but we aren't the genealogy police.

How does the following sound?

Proposal

Allow citation level fields to be used in the Bibliography format of Source Templates. This would help users migrating from other products, but also new users who choose to adopt some level of 'lumping' when creating sources but want a more granular 'bibliography'.

[AdrianBruce]

Err - surely you can't include Citation Level items in the Record Title of a Source Record, given that there are potentially many different values of that Citation Level item for the one Source Record? Or am I missing something?

[ColeValleyGirl]

Err - surely you can't include Citation Level items in the Record Title of a Source Record, given that there are potentially many different values of that Citation Level item for the one Source Record? Or am I missing something?

Fair point. Proposal edited.

[AdrianBruce]

OK then

[fhtess65]

Looks good to me

<SNIP>
How does the following sound?

Proposal

Allow citation level fields to be used in the Bibliography format of Source Templates. This would help users migrating from other products, but also new users who choose to adopt some level of 'lumping' when creating sources but want a more granular 'bibliography'.

[jnunnally]

How does the following sound?

Proposal

Allow citation level fields to be used in the Bibliography format of Source Templates. This would help users migrating from other products, but also new users who choose to adopt some level of 'lumping' when creating sources but want a more granular 'bibliography'.

Thank you for this proposal.

After participating in this discussion earlier, I did a detailed review of RootsMagic source templates and bibliography formats. To my surprise 105 of RootsMagic's 415 built-in source templates use a citation level field named "Access Date" in the bibliography! I didn't check for any other citation level fields being used, but I have not encountered any.

RM does not allow modifications to their built-in source templates. There is a provision for making a copy of a source template that can be customized, but then there is no function available in RM to move existing sources from the built-in template to a new, custom template. (It can be done with SQLite, but most RM users are not SQLite users.) This leaves most RM people with little choice but to import those built-in templates to Family Historian as they are, but then there is no clear way to make these templates acceptable to FH after the import.

For RootsMagic users considering the move, this is a bigger problem than just an occasional, haphazard construction of bibliographies. It is a rather systemic problem.

[cwhermann]

I moved from RM and addressed this issue within RM before importing. Although RM allows the [access date] citation level field in the bibliography template, it does not work correctly when you generate a report, if you access the same source on multiple dates.

RM allows user to create a copy of the built in templates and then customize the copy. To get around the bibliography issue, I created customized RM templates to include a separate source level field [access years]. All these templates imported to FH just fine.

[jnunnally]

Yes, I agree with all you said and even pointed out the ability to copy the built-in RM templates. However, I doubt the average RM user, including myself, had the foresight to not use the built-in RM templates when getting started. Those people may have hundreds of sources with associated citation details that are based on the built-in templates with no reasonable approach for repairing their existing data.

The issue is really not whether there is a better way things could have been done in the past or even going forward. The issue is what do people do with their existing data when they are caught between restrictions in RM and FH?

I fixed my existing templates with SQLite, adding a source level field, but that solution is not practical for most RM users.

In a previous post, I suggested the implementation of this proposal include a warning about using citation detail fields in the bibliography is not advised and I still believe that would be a good compromise.

[fhtess65]

I'm hoping not to have to return to RM and am redoing my citations as I work (not sure I'll ever finish, but better than not trying!) Still, there's always an outside chance I might be forced to return to RM for some reason, so yes, a reminder/warning might not be a bad idea. Though my experience at work tells me that people will click through anything to get to what they want and just ignore the pop-up...

The issue is really not whether there is a better way things could have been done in the past or even going forward. The issue is what do people do with their existing data when they are caught between restrictions in RM and FH?

I fixed my existing templates with SQLite, adding a source level field, but that solution is not practical for most RM users.

[Mark1834]

If it is something that could be a major blocker for RM users, it’s worth raising with CP to see if they can do anything on import. They modified the way FH imports RM alternate names to give a better fit, so they are open to such discussions.

Modifying an RM template is probably beyond the limited abilities of FH plugins to write to RM directly.

[ColeValleyGirl]

Wish List entry 599 has been raised.