* Multiple authors for sources?

[Rancher]

It is possible to add more than one author when entering a source (usually books and journal articles)?

[tatewise]

In a Generic GEDCOM based Source record, only one Author field is allowed, so you must enter a comma-separated list.

In a customised Templated Source record it should be possible to define multiple Author fields.

[Rancher]

In a customised Templated Source record it should be possible to define multiple Author fields.

That would be one Author field per author, I assume? So if there were 4 authors, you'd need 4 fields, correct?

[tatewise]

Yes, you would define the Source Template(s) with as many Author fields as you think may be needed.
Then if a source needs more, the Source Template(s) would need updating and resyncing.
When creating a Source Citation you would fill in as many Author fields as necessary for that book, etc.

BTW: Have you read and understood the implications of using Generic Sources versus Templated Sources and that it is not advisable to use both types in the same Project?

[AdrianBruce]

Perhaps slightly tongue in cheek, because the reader may not wish to go there, but I use a comma separated list for multiple authors (as Mike suggests) but also I also potentially add a role in brackets - e.g. "John Smith, Jane Doe (ed.), JL Picard (trans.)".

Given that, for generic sources (which I use), the whole Author item is just a text string that cannot be parsed or split in any other way, there's actually no point in worrying, at the moment, about what goes into it, so long as it's meaningful to a human reader.

[tatewise]

Adrian said the Author field was "a text string that cannot be parsed or split in any other way".
There are at least two FH v7 functions that can parse/split comma-separated text fields:
=TextPart(...)
Although designed primarily to help with the presentation of place information in reports and elsewhere, this function can however be used with any text fields. It returns one or more parts of any comma-separated text.
=Section(...)
This function is for use with text fields that are separated into multiple sections, using any series of one or more characters as separator characters to define the 'boundaries' of each section. It allows a specific section to be retrieved.

[fhtess65]

It is possible to add more than one author when entering a source (usually books and journal articles)?

Throwing this out as a librarian and cataloguer. In the case of a book/article with multiple authors, the first one listed is the ONLY one that goes into the Author field in a library catalogue. The rest are considered as Added Entries and have a separate field. In the updated cataloguing standards, we now also list all authors in a separate subfield at the end of the title.

100 $a SURNAME, FORENAME
245 $a TITLE ; $b sub-title / $c Forename Surname, Forename Surname, Forename Surname.

While I know we're not cataloguing per se here, but this might help to see how it's done in a library. In another way, we are cataloguing our ancestors, so I do use some library techiques when entering sources.

Please ignore if this isn't of interest.

OTOH, I just checked the Source template for Books and Pamphlets in the Essentials Collection and the prompt actually says to enter all authors if there are more than one.

See my screen captures below.

BookPamphletTemplate.jpg (88.65 KiB) Viewed 4809 times

BookCitationMultipleAuthors.jpg (231.01 KiB) Viewed 4809 times

[Rancher]

It is possible to add more than one author when entering a source (usually books and journal articles)?

In the case of a book/article with multiple authors, the first one listed is the ONLY one that goes into the Author field in a library catalogue. The rest are considered as Added Entries and have a separate field. In the updated cataloguing standards, we now also list all authors in a separate subfield at the end of the title.

100 $a SURNAME, FORENAME
245 $a TITLE ; $b sub-title / $c Forename Surname, Forename Surname, Forename Surname.

Ah, that is interesting that you put up a MARC record. I had not thought about that.

I used Endnote (and sometimes Zotoro) for my academic work. It dumps each author into a single field, but one on each line. Endnote will consider them, however, as separate entries in terms of the use of initials, family name first, where to put "and", &c. I was kind of hoping to do something similar in FH7 with the Source Templates, so I could cite things like this:

Hewins, Ian, David Webb, Sarah Gibson, and Robert McFadden. "In memoriam: Patrick Siler McIntosh, 1940–2016." Space Weather 15 (2017): 280–281. doi: 10.1002/2017SW001601.

I suspect I could achieve something similar with Author_Main, Author_Final, and Authors_Additional (anything other than 1st or last). I would need Author_Final so that "and" would be placed appropriately. Authors_Additional would contain a list, on a single line, of all the others, pre-formatted in terms of the order of the names.

[tatewise]

The pragmatic method is to put Hewins, Ian, David Webb, Sarah Gibson, and Robert McFadden in one Author field.

[Rancher]

The pragmatic method is to put Hewins, Ian, David Webb, Sarah Gibson, and Robert McFadden in one Author field.

If I do that, the Source Template will treat it as one name, with "Hewins" as the last name. This is a problem in footnotes then since they are formatted First Name Last Name.

[tatewise]

I don't see anything that treats the Author field as a Name with Last Name & First Names. Where have you got that idea?
Perhaps you have defined your own custom Source Templates?

The Essentials Collection of Source Templates all define the Author field as Text, not a Name, and the Prompt always says 'Enter all if more than one', and the Footnote & Bibliography formats simply reproduce the {Author} field as it is.

The Generic Source treatment of the Author field is essentially the same.

[Rancher]

I don't think that is correct.

I am using an Advanced Source Template ("Book: Basic Format"; others are similar). The Author field is naturally a Name field (not Text), where the Bibliography layout uses {Author:REVERSE}. Thus, books are sorted by last name in the Bibliography, but Given name Last name in footnotes. Dumping several authors into a single Author field for a book source will not be displayed properly in the Bibliography.

[KFN]

It has been a long while since I learned and actually cataloged a new document with multiple authors. However, if I recall correctly MARC only requires the use of 245 sub field “c” when there are more than three (3) authors.

That being said, the citation can say the following:
Hewins, Ian … [et al.]

[AdrianBruce]

... The Author field is naturally a Name field (not Text), where the Bibliography layout uses {Author:REVERSE}. Thus, books are sorted by last name in the Bibliography, but Given name Last name in footnotes. ...

Ah - that I had forgotten - or never twigged, given that Templated Sources aren't feasible for me. So there is some degree of processing that can be carried out on the data, contrary to my earlier belief. And the processing even recognises the // convention for family names, which will presumably mean that a suitable // would allow "Fred /Bloggs/ (Ed)" to be sorted with all the other Bloggs, not with the "Bloggs (Ed)" family. (At any rate, "Major /Kira/ Nerys" got put into the Bibliography as "Kira, Major Nerys" in my test file.)

[tatewise]

Sorry, I had not realised that the Essentials and Advanced collections treated the Author fields differently.
Presumably, if you use a mixture of Essential and Advanced collection Source Templates then the Footnote and Bibliography entries starting with Authors will be in an 'interesting' order?

[AdrianBruce]

Sorry, I had not realised that the Essentials and Advanced collections treated the Author fields differently.
Presumably, if you use a mixture of Essential and Advanced collection Source Templates then the Footnote and Bibliography entries starting with Authors will be in an 'interesting' order?

The conversion from a basic Essentials template is easy enough as I found out earlier when experimenting with Major Kira's name.
1) Alter {Author} to read {Author:REVERSE};
2) Sit there wondering why nothing happens;
3) Realise that the Essentials Author is a Text item whereas :REVERSE operates on a Name item;
4) Convert the {Author} to be a Name item vice Text.

Of course, the optimum order for that sequence is actually 4 then 1.

[tatewise]

I don't doubt that conversions are possible, but then they are not the original collections but Custom collections.
Do you convert Essentials to match Advanced or convert Advanced to match Essentials?
If you already have a body of Sources based on the standard Templates, I suspect the converted Templates will not sync with them if you have changed the Author data type.
Such conversions are 'easy' for experiments, but the practicalities may not be so simple if the user does not discover those two different Author strategies until after a great deal of data has been captured.

[AdrianBruce]

Indeed - this was just an experiment.

Yes I guess it is a Custom Collection but in my head I'd classed it as a variant of the Essential.

Do you convert Essentials to match Advanced or convert Advanced to match Essentials?

Whichever is the optimum way round, which presumably depends on where you start from.

Yes, changing the Author in midflight resulted, IIRC, in the loss of the Major's name from the Author item - I had to refill it, which I forgot to mention. As you say, it's not the sort of thing, therefore, that you want to do some way down the line. (Wasn't there a plugin dealing with changing stuff, mind you? It's not something that I committed to memory being stuck with generics, though).

[ColeValleyGirl]

Wasn't there a plugin dealing with changing stuff, mind you?

Change source template (19143)

[tatewise]

Yes, as Helen says, there is a Plugin to help with such changes and the relevant caveats for the Author fields are:
- when mapping from NM to TX the slashes (/) are removed;
- mapping from TX to NM is allowed with standard FH last name conventions (i.e. last part of multipart name is last name);

So if converting Essentials Author (TX) Text fields to Author (NM) Name fields, the slashes inserted around the 'last part of multipart names' may not always be what is desired, especially if multiple names have been entered. Therefore, the Author names will probably all need to be reviewed.

In some respects, the Essentials textual Author (like the Generic Author) is more flexible, as it allows the user to enter one or more authors in whatever format and sort order they prefer. It is perhaps more likely to export to other products or exchange with other FH users with the least problems.

[AdrianBruce]

Thanks for the reminder, Helen. Taking a swift look at it, it seems to cope with changing a source-record from Template A to Template B. Also for moving data from Field 1 in Template A to Field 2 in the same template. It doesn't appear to be designed to change a single field from one format to another (e.g. Text to Name, as per my example). That would presumably have to be done by setting up a new field so the mapping would be (say) from Author (type Text) to AuthorName (type Name).

The question, however, as I'd realised before looking at your replies, is the one that Mike raises, which is basically - is this sort of conversion likely or a good idea? Especially if you have packed multiple authors' names into a Text type field such as the one in the Essentials collection? Having said that, it's not immediately obvious to me why the Author in the Essentials collection is a Text and in the Advanced is a Name. It's kinda suggesting life can get a bit difficult if you're too far down using one Collection and you want to convert???

[ColeValleyGirl]

It's kinda suggesting life can get a bit difficult if you're too far down using one Collection and you want to convert???

Well, as always it depends... some templates will convert easily, some won't. But I'm not sure it's a real issue -- most people will adopt the Essentials collection and possibly customise it somewhat. Dyed-in-the-wool ESM users and people who have migrated from products that already had ESM templates will adopt the Advanced collection (or a subset of it). I suspect converting between the two sets of templates is going to be a rare occurrence.

[AdrianBruce]

... I suspect converting between the two sets of templates is going to be a rare occurrence.

I think you're probably right. But there's a nagging frustration here that may or may not be justified. Firstly, for all sorts of practical reasons, those of us with any serious investment in generic sources are unlikely in the extreme to be able to convert to templated sources - even adding new sources as templated seems impractical for all sorts of reasons. Secondly, the example of these Author issues mean it's now far from clear to me that it's practical to convert from Essentials templates to Advanced. That may be unfair, especially as I imagine that if I were using Essentials templates, I'd probably just introduce the odd Advanced template at a time.

Nonetheless, migration between generics and templated, or even between Essentials and Advanced seems harder work than I'd hoped for last year.

PS - yes, issues of unravelling composite generic items such as a generic Published item for a source with a source-of-the-source mean it's never going to be possible to automatically split those into templated items. But the issues of using (new) templated sources alongside (existing) generics do seem to make that choice pretty much impractical as well.