ISFDB:Community Portal


(Difference between revisions)
Jump to: navigation, search
(Change ID: Not supported at this time)
(Proposed Software Changes)
Line 2,887: Line 2,887:
:::: P.S. I have added the above to {{FR|1238}} "Create an Edit History page for publications". [[User:Ahasuerus|Ahasuerus]] 11:04, 24 May 2019 (EDT)
:::: P.S. I have added the above to {{FR|1238}} "Create an Edit History page for publications". [[User:Ahasuerus|Ahasuerus]] 11:04, 24 May 2019 (EDT)
:::: This proposed HTML method is nothing where there is a chance of successful cooperation between you and me. It is much to complex to get it to work. Still my proposal is an option - a submission is stored as XML in the database. My proposal is to extend this XML at the moment of accepting the submission and store the old values for changed elements (and only these) in the XML. That way a diff can not only show new, but also old values of a change. That will help a lot to verify a change even if it does not cover all possibilities. This adaption needs only small modifications at submission acceptance and display of a change request and not a major new functionality. And it does also not conflict with any future plans. --[[User:Stoecker|Stoecker]] 04:34, 30 May 2019 (EDT)
== Magazine issue navigation ==
== Magazine issue navigation ==

Revision as of 08:34, 30 May 2019

ISFDB Discussion Pages and Noticeboards
Before posting to this page, consider whether one of the other discussion pages or noticeboards might suit your needs better.
Help desk
Questions about doing a specific task, or how to correct information when the solution is not immediately obvious.
• New post • Archives
Verification requests
Help with bibliographic, image credit, and other questions which require a physical check of the work in question.
• New post • Archives
Rules and standards
Discussions about the rules and standards, as well as questions about interpretation and application of those rules.
• New post • Rules changelog • Archives
Community Portal
General discussion about anything not covered by the more specialized noticeboards to the left.
• New post • Archives
Moderator noticeboard
Get the attention of moderators regarding submission questions.
• New post • Archives • Cancel submission
Roadmap: For the original discussion of Roadmap 2017 see this archived section. For the current implementation status, see What's New#Roadmap 2017.

Archive Quick Links
Archives of old discussions from the Community Portal.

1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 14 · 15 · 16 · 17 · 18 · 19 · 20 · 21 · 22 · 23 · 24 · 25 · 26 · 27 · 28 · 29 · 30 · 31 · 32 · 33 · 34 · 35 · 36 · 37 · 38 · 39 · 40 · 41 · 42 · 43 · 44 · 45 · 46


Merging illustrations

What's the proper procedure for merging this and this without having title variants? user:Rtrace has confirmed they are the same W&B illustration, and the "Tiffany on the Chalk" title is taken from Kidby's website. Circeus 10:37, 1 November 2018 (EDT)

Two options:
* Rename them to have the same title - then merge them. However, if the title of the picture is not in the book, it should not be named that way - we follow the naming inside of the book.
* If the names remain different, they need to be varianted. For art, varianting means: "it is the same picture (more or less - it can have changes in coloring and what's not) but it has a different title in different publications".
Names from the artist's site go into the notes; if the illustration is not named this way IN the book, the title is not used as a title here usually. Being interior art leaves some leeway but... I would still not name it based on a site.
Let me know if any more clarifications are needed or if you need assistance. :) Annie 11:49, 1 November 2018 (EDT)
Please don’t merge or variant those titles. One is an overall interiorart title for an entire book. It contains the other, but also contains the other artwork in the book. --Ron ~ RtraceTalk 13:36, 1 November 2018 (EDT)
They are both identical full-page illustrations. Why shouldn't they be merged? Circeus 13:40, 1 November 2018 (EDT)
Because (looking at Ron's page)the record in Ron's book is NOT JUST for that illustration but for all the internal artwork in the book. Annie 14:44, 1 November 2018 (EDT)
Precisely right. Sorry for the terseness of the previous comment, I was on my cell phone. We have three different ways by which we enter INTERIORART. Unfortunately, we don't have a good way of linking titles for individual artwork to a title that contains multiple artworks. You could certainly add a note on either or both of the title records explaining the relationship. I will note that the individual artwork can be linked with this title. It's a little complicated since one of the pieces is technically a translation. I do question whether the illustration French book really has an English caption. If so, would we still consider the language of that title to be French? Also, does the French book contain only that illustration and omit the headpieces and other decorations? If they are present, there should probably be an overall artwork title for the French translation instead of cataloging only the one illustration. Circeus, do you own or have access to the translation? If so, please verify what artwork exists there and we can figure out how to proceed. Thanks. --Ron ~ RtraceTalk 19:48, 1 November 2018 (EDT)

Three months later.
For what it's worth: In the Contents list for a publication that reprints multiple single illustrations from an earlier INTERIORART work --that is, selections from a previously published set of illustrations-- I would like to see us use titles such as

Alice in Slumberland [1]
Alice in Slumberland [2]

rather than omit disambiguation for the title of the first one. As an alternative, we might disambiguate that first single-illustration excerpt from the original work thus:

Alice in Slumberland (excerpt)
Alice in Slumberland [2]

As a less radical suggestion, we might add such a title disambiguator only if the entire original INTERIORART work is in the database. (Commonly that will be when the first publication of the latter is added to the database. Commonly too, however, we have many-a-record of a publication in which one set of illustrations is published for the first time, but our publication record does not report the illustrations. So the less radical change of title --for the TITLE that represents one illustration later reprinted from a set-- from "Alice in Slumberland" to "Alice in Slumberland [1]" would happen when we add the set of illustrations to our record of its first publication.)

Also less radical, we might assign to a single-illustration excerpt the date of its earliest known publication. "Alice in Slumberland (excerpt)" isn't first published when "Alice in Slumberland" (entire) is first published. --Pwendt|talk 16:56, 25 January 2019 (EST) --Pwendt|talk 16:56, 25 January 2019 (EST)

(re-word and mark-up, above, for clarity)
Either of the less radical suggestions will be adequate to ensure that Alice in Slumberland (1898) does not appear in the database as the title of both the 1898 set of illustrations and any later publication of one illustration from the set.
By the way, can anyone judge how commonly we do have one single-illustration title such as "Alice in Slumberland [2]" now in use for reprints of different illustrations from the original set? --Pwendt|talk 13:05, 26 January 2019 (EST)

Advanced Searche changes -- wildcards

The other day the ISFDB server experienced a temporary slowdown. It turns out that it was due to an attempt to retrieve a complete list of ISFDB authors using Advanced Author search. The offending user ran a search on "%", one of our wildcard characters. In order to prevent future performance problems, Advanced Search has been modified to disallow search values which are limited to "%", "*" and "_". Ahasuerus 15:15, 1 November 2018 (EDT)

EditPub and EditTitle -- changing author order

As Template:AllFields:Collaborations states:

  • If a work has multiple authors, it doesn't matter in which order you enter them. The ISFDB does not record author order regardless of how the authors are entered

The order in which authors were entered has always been ignored when filing data into the database. However, Edit Publication and Edit Title used to allow creating submissions which changed author order. It didn't actually do anything when the submission was approved, but it could be misleading.

The software has been updated to make it clear that changing author order doesn't create a meaningful submission. Ahasuerus 21:21, 1 November 2018 (EDT)

Jim McLeod

In the author record for Jim McLeod, is the artist who worked from 1970 to 1988 a different person than the horror reviewer who worked from 2011 to present (and who spells his name "Mcleod")? It seems like a certainty they must be different but I can't actually confirm it. --Vasha (cazadora de tildes) 16:19, 2 November 2018 (EDT)

I think the question should be the other way around. Unless there is something that indicates they are the same (and I'm not seeing it), they should be separated. The time periods and activities are different enough that we shouldn't assume they are the same person. There is nothing about artwork on the provided website link. -- JLaTondre (talk) 16:43, 2 November 2018 (EDT)
I have separated the two. -- JLaTondre (talk) 13:44, 3 November 2018 (EDT)
Thanks, but McLeod (I) should be spelled "Mcleod." --Vasha (cazadora de tildes) 15:46, 3 November 2018 (EDT)
Done. -- JLaTondre (talk) 15:49, 3 November 2018 (EDT)

Canonical name change: John Trevena

I suggest changing John Trevena's canonical name to Ernest G. Henham. It is as commonly found as Trevena (now that I have just added another title as by Henham) and this is the form used in SFE3. --Vasha (cazadora de tildes) 16:57, 2 November 2018 (EDT)

Looks like it was done. ···日本穣 · 投稿 · Talk to Nihonjoe 13:27, 4 November 2018 (EST)

Haunted Houses

Wanted to get some more opinions on a discussion ... it's about a book titled Haunted Houses, for which the publisher's description is "... discusses ten documented cases of ghosts and poltergeists from the past and present and suggests various theories to explain them." I think that it is outside the scope of this DB because it is a nonfiction book about real-life paranormal phenomena; however, the verifier, Auric, argues that it is fiction because "The LC Catalog puts it under 'Ghosts--Juvenile literature'. Also nonfiction is subjective, and depends on whether or not you believe in ghosts." Anyone else? --Vasha (cazadora de tildes) 18:26, 4 November 2018 (EST)

Sorry - jumped in on the conversation instead. The LC (sub)classification of Juvenile literature does not mean fiction. They have biographies sub-classified as such. For this particular title, they have a Dewey Decimal number of 133 which is non-fiction. As to the second argument - is the classification of religion as nonfiction subjective and depends on whether you believe in God? ../Doug H 10:08, 6 November 2018 (EST)
We typically determine whether a work is fiction by examining the way it is presented. Stories like:
  • "I Was Kidnapped and Experimented on by Aliens"
  • "Secrets of Creation as Told by an Angel"
  • "My House Is Haunted"
are considered fiction if they are presented as fictional, i.e. not real, stories. Otherwise they are considered non-fiction. ISFDB:Policy says "Psychic and extrasensory abilities, including but not limited to clairvoyance, levitation, precognition, telekinesis, telepathy and teleportation, when presented as real [are considered speculative fiction]".
We have occasionally run into a couple of issues with this definition. The first one is raised by works which facetiously claim that they are non-fiction. In some cases it's not immediately clear whether the author was being facetious or not. The second one is the publisher using the classic "Truth or Fiction? You Decide!" stunt.
When in doubt, we generally enter the work and add comments. Ahasuerus 12:42, 6 November 2018 (EST)
The phrase that the work "suggests various theories to explain them" does heavily point in the direction of nonfiction: it seems that also non-supernatural explanations are discussed. Stonecreek 00:24, 7 November 2018 (EST)
Are we agreed that this,one should go? --Vasha (cazadora de tildes) 13:29, 17 November 2018 (EST)
Am I misreading something here? The part of the policy, specifically ... when presented as real Ahasuerus cited above actually says to keep it?! MagicUnk 17:42, 17 November 2018 (EST)
The other way around: that's one of the things that is excluded from the DB. --Vasha (cazadora de tildes) 17:54, 17 November 2018 (EST)
No, it is not; it is currently under the inclusion section of the policy. The Haunted Houses case mentioned above is presented as real, so is included. MagicUnk 01:29, 21 November 2018 (EST)
Re-reading the Policy, I think it must be reworded to be clearer; instead of ...when presented as real, it should read ...when presented as if it were real [but is not]. That would correctly convey the intent of the rule, I think. MagicUnk 06:37, 21 November 2018 (EST)
Technically, all bullets in the "Inclusions" section are under "speculative fiction", so they only cover fiction works. However, since the "occult fiction" bullet clarifies that it's limited to fiction, we might as well do the same for "psychic and extrasensory abilities" in order to avoid confusion. I have changed "when presented as real" to "when presented as if they were real" -- thanks! Ahasuerus 12:47, 30 November 2018 (EST)

Amazon image cleanup

The post-submission pages associated with New/Add/Clone/Edit Publication submissions have been enhanced. They now display a warning if an Amazon image URL contains additional formatting like ".SY346."

A new cleanup report has been coded and deployed; the data (approximately 1540 publications) will become available tomorrow morning. The report is available to all editors. At this time the report doesn't support the ability to "ignore" records. If we find Amazon URLs that have legitimate "L._" formatting, we will re-evaluate our options. Ahasuerus 18:47, 5 November 2018 (EST)

Jeanne Cook/Gini Koch

Is there some reason why Gini Koch's canonical name is Jeanne Cook? Are we using her real name to avoid having to choose between her pseudonyms? She uses Koch most often by far, and as for it being better known ... two recent publications were billed as "Gini Koch writing as Anita Ensal" and "Gini Koch writing as A. E. Stanton." --Vasha (cazadora de tildes) 17:08, 6 November 2018 (EST)

IIRC, she used a number of pen names in 2009-2011. It wasn't clear which one (if any) would become dominant, so we used "Jeanne Cook" as a stopgap measure. At this point it's abundantly clear that "Gini Koch" has won the race and should be made the canonical name. Ahasuerus 17:56, 6 November 2018 (EST)
All edits have been submitted --Vasha (cazadora de tildes) 22:45, 7 November 2018 (EST)
All approved and I finished the mopping up. Should be all set. Annie 00:03, 8 November 2018 (EST)
Looks good, thanks --Vasha (cazadora de tildes) 00:16, 8 November 2018 (EST)

External ID Search enhancements

The External ID Search has been enhanced to support the following conditions:

  • is exactly
  • contains
  • does not contain
  • starts with
  • does not start with
  • ends with
  • does not end with

The publication table that it generates is currently limited to the first 300 matching publications for performance reasons. Ahasuerus 20:17, 7 November 2018 (EST)

Thanks! That is very useful in chasing identifiers that were set as the wrong type (for the ones that are not just numbers anyway). Annie 17:30, 8 November 2018 (EST)
The search logic has been further enhanced to redirect to the Publication page if only one matching publication record has been found. Ahasuerus 11:42, 14 November 2018 (EST)

Cleanup reports and invalid HTML lists in notes

The cleanup reports which look for bad HTML in notes have been enhanced to search for "li" tags without corresponding "ul"/"ol" tags. The new data will become available tomorrow morning. Ahasuerus 11:03, 8 November 2018 (EST)

Audio books and page counts

It turns out that we have 3K+ audio books whose page count is set to "0". "0" page counts are not displayed on publication pages or in publication tables, so the problem is currently masked.

Would anyone happen to remember if using "0" for audio books was a conscious decision? I can't find anything relevant in our SourceForge archives. Ahasuerus 11:58, 8 November 2018 (EST)

I seem to remember that at least some of the types were producing a bibliographic error when the field was left as 0 - and some people were adding 0 just to make it stop. Not sure how many of them came this way but that may account for some of them. Annie 17:29, 8 November 2018 (EST)

(unindent) Bug 716 has been created to address the fact that "0" page counts are not displayed. SR 144 has been created to blank out audio books' "0" page counts programmatically. Ahasuerus 14:28, 12 November 2018 (EST)

All 2,423 audio books with "0" page counts have had the field blanked out. We also have 1,432 ebooks and 119 webzine issues with "0" page counts. We may want to consider taking the axe to them as well. Ahasuerus 15:59, 14 November 2018 (EST)

Geoff Brown

For a while horror editor and publisher Geoff Brown used the name "G. N. Braun" on the fiction he wrote; we had that as his canonical name, assuming (I suppose) that fiction would be better known. However, the majority of his web presence and interviews are under the name "Geoff Brown," and this year he started republishing the "Braun" fiction as by "Brown" (two stories so far that I know of). Is it time to change his canonical name yet? I actually was thinking that "Brown" should be the canonical name even before he started republishing the stories, and suggested it a couple years ago. --Vasha (cazadora de tildes) 21:46, 8 November 2018 (EST)

Help currently says that "the canonical name is the most recognized name for that author within the genre". I suppose if a fiction author is "most recognized" as an editor (H. L. Gold, Howard Browne, John W. Campbell, etc), the canonical name would be his "editor" name as opposed to the "fiction author" name. We even use R. S. Richardson as the canonical name (as opposed to Philip Latham, the pseudonym that he used for his fiction) because Richardson was somewhat better known for his non-fiction essays in SF magazines.
In this case I think the case for "Geoff Brown" is strong enough to warrant action. Ahasuerus 13:43, 10 November 2018 (EST)

Newford (de Lint) reading order

I'd like to update the reading order for the Newford series to match the author's recommendation. Do I need reach out the PVers for any affected pubs, or can I just update the titles? Thanks TAWeiss 13:00, 10 November 2018 (EST)

Hm, that's a rather tangled web. Since the stories do not need to be read in a particular order (except for the trilogy mentioned by de Lint), one could argue that the publication order is our best bet. Then again, perhaps putting juvenile and young adult books in a separate sub-series may not be a bad idea. Ditto the horror/thriller books published as by "Samuel M. Key" since they are so different. Decision, decisions... Ahasuerus 14:26, 10 November 2018 (EST)
de Lint's recommendation would line up with the publication order, so I think that should be updated. I don't know whether adding a subseries for YA books makes the listing clearer, but I think making sure that the core books are linked makes sense. Based on my reading, "The Wind in his Heart", probably should be removed, and the three missing books from the author's list should be added to the numbered list. TAWeiss 10:23, 11 November 2018 (EST)
I am all for adding the missing books, of course. Re: "The Wind in His Heart" (2017), this Publishers Weekly review mentions "Leah Hardin, a Newford blogger", so I assume that it's at least set in the same universe. Perhaps de Lint hasn't had a chance to update the FAQ yet? (It's a very common problem with these kinds of lists.) Ahasuerus 12:25, 11 November 2018 (EST)

Possible new option for adding translations

As per this discussion on my Talk page, there is interest in simplifying the process of adding translated publications to existing title records. As JLaTondre wrote a couple of days ago:

We are having a lot of translations being entered now. When the translated title doesn't already exist, it is a two step process to add the new book and then variant the translated title to the original. At the title level, it would be nice to have an "Add Translation to This Title" button which would simply be the "Add New Novel" (or whatever one is the equivalent type as the parent) screen, but it would automatically variant the new container title to the original title.

I have poked around a bit and here is what I think. Suppose we have a title like this one and we want to add a translation. Normally, when you click Add Publication to This Title, the following fields are grayed out:

  • Title
  • Transliterated Title(s)
  • Author(s)
  • Pub Type

The proposed option, which we will tentatively call "Add Translated Publication to This Title", will look the same with the following exceptions:

  • title, transliterated title(s), and author(s) will not be grayed out
  • a new drop-down list, "Language", will be added
  • a new field, "title note", will be added. It will be used to capture the name of the translator(s) and/or any other translation-specific information.

The new data entry form will create a submission which, once approved, will create a new title record using the entered title/transliterated title(s)/author(s)/language/title note. It will also turn the newly created title into a variant of the original title. The new title will inherent the values of the "title flags" from the parent title.

Does this sound about right? Ahasuerus 15:26, 10 November 2018 (EST)

Sounds useful, yes. The form will be the same as Add New Publication except for lacking title flags? --Vasha (cazadora de tildes) 16:03, 10 November 2018 (EST)
It will be a cross between Add New Publication and Add Publication to This Title. Unlike the former, there will be no Synopsis field and no Series fields. We could add a "Web Page" multi-field since Web pages are valid for variant titles. Ahasuerus 16:19, 10 November 2018 (EST)
Yes, please :) MagicUnk 16:59, 10 November 2018 (EST)
This field would really be nice to have. Stonecreek 00:18, 11 November 2018 (EST)
That reminds me ... does anyone have bright ideas for how to not display Content field when editing titles except if they're OMNIBUS? I keep pasting web links in that field by mistake ... --Vasha (cazadora de tildes) 18:00, 10 November 2018 (EST)
The larger issue here is that certain title fields only apply to certain title types. Since the Edit Title form lets you change the values of multiple fields, including the title type value, it can result in inconsistencies. Here are some of the ways in which we currently handle these issues:
  • Disallow changing the title type. This is currently done for REVIEWs and INTERVIEWs because you can't easily convert them to other title types.
  • Gray out certain fields based on the title type. This is currently done for the two Series fields when editing CHAPBOOK titles. It's not a great solution since the fields remain grayed out even after changing the title type.
  • Add pop-up validation to prevent editors from creating invalid records. This is what happens when an editor enters a value in the Content field for a non-OMNIBUS title or a "Length" value for a non-SHORTFICTION title.
  • Cleanup reports. Lots and lots of cleanup reports.
One way to handle this issue would be to make the data entry form logic immediately gray out and "ungray out" relevant fields when the value of the Title Type field is changed. Changing the title type from OMNIBUS to something else would blank and gray out the Content field. Changing it to CHAPBOOK would blank and gray out the two Series field. Etc.
The problem with this approach is that blanking no longer relevant fields becomes a problem if the editor decides to change the title type again. The only way to get the zapped data back would be to hit F5, but then the rest of the new data would disappear. This is the reason why I originally decided to use pop-up validation instead of graying/ungraying fields on the fly. If there is a better way to do this, I will be more than happy to implement it! Ahasuerus 12:17, 11 November 2018 (EST)

(unindent) OK, FR 1222 has been created. Ahasuerus 14:23, 12 November 2018 (EST)

Cleanup reports: "HTML in Notes" tweaked

While working on another requested feature, I noticed that some Notes cleanup reports used incompatible lists of disallowed HTML tags. The lists have been consolidated and streamlined based on what's currently stated in Help:Using Templates and HTML in Note Fields#Supported HTML tags.

Once the nightly reports run overnight, the affected reports will include a few new records which mostly use the "small" tag. It's a harmless tag, so if we decide that it's useful, we can trivially add it to the list of supported tags. Ahasuerus 19:47, 10 November 2018 (EST)


Hi Ahasuerus, I just noticed that when I am clicking on the question mark next to the Graphic Format flag of a New Chapbook, I'm redirected to, which is empty, instead of to MagicUnk 06:00, 11 November 2018 (EST)

Fixed -- thanks for identifying the problem! Ahasuerus 10:22, 11 November 2018 (EST)

Mirandese Language

The software has been updated to add support for the Mirandese language. Ahasuerus 10:35, 11 November 2018 (EST)

Post-submission warnings -- HTML in notes and titles

Post-submission pages have been enhanced to display yellow warnings for HTML tags within titles and for invalid/mismatched HTML tags in Notes. The code is brand new and doesn't cover every possible permutation, but it's better than nothing. Ahasuerus 18:56, 11 November 2018 (EST)

Something is off when there is some more complicated HTML. this just decided to show me yellow and it is clean. Another one earlier had a similar problem. The change here is swapping a link with a templated OCLC and I checked 3 times that I did not mess up the only line I edited. Not sure what the parser is catching up on - the report never flagged anything and I do not see a problem either...Annie 19:13, 11 November 2018 (EST)
I think I see what the problem is. Let me see if I can fix it real quick. Ahasuerus 19:52, 11 November 2018 (EST)
If the guess is the "a" tags, this confirms it. No other HTML here... Annie 19:53, 11 November 2018 (EST)
Links and tables, basically. Hopefully the patch that I installed a couple of minutes ago took care of them. Ahasuerus 20:09, 11 November 2018 (EST)
Links don't alert anymore - will keep an eye for other anomalities. Thanks for adding this check! Annie 20:15, 11 November 2018 (EST)
Sure thing. No extra charge for the bugs! Ahasuerus 20:46, 11 November 2018 (EST)

(unindent) When you have a chance, can you see why this did not alert about the missing /a and the missing quotes around the href. These are two of the most common issues with html submissions so it will be great if we can see a warning for them. Annie 01:21, 15 November 2018 (EST)

The invalid HTML report does not catch it either (the missing quotes in href did) - so maybe the missing quotes are throwing off the parser - thus neither the report, nor the new warning system sees it. Annie 01:24, 15 November 2018 (EST)
Any ideas here? Annie 13:48, 16 November 2018 (EST)
Sorry, I missed the original question. I'll take a look when I am feeling better. Ahasuerus 15:05, 16 November 2018 (EST)
Sorry, did not want to nag. Feel better. Annie 15:24, 16 November 2018 (EST)
No problem. At the very least the problem needs to be documented. FR 1225 has been created. Ahasuerus 16:08, 16 November 2018 (EST)


Concerning The Treasure of the Isle of Mist T2215219, in a 1934 edition not yet in the database (AddPub is now in the queue as "to be continued"). Full view of this publication is available at HathiTrust, presumably because there is no 1934 copyright statement for the new illustrations. The text is pre-1923.

I diagnosed "plates included in the pagination" by reference to the numbered pages. For instance the 4-page span pp. 5-8 --two leaves on the usual use of odd and even numbers-- is represented by unnumbered pages that display a small drawing, a caption, a full-page drawing (listed by that caption in "Illustrations" as page 7), and nothing. See page 7 at HathiTrust, for one point of entry. Probably those are two plates, eh?

But another listed illustration corresponds to a span of 3 unnumbered pages only, pp. 171-173, which display small drawing, caption, and full-page drawing. See page 173. Relying on the usual use of odd and even numbers, one page of the text, p. 174, is printed on the back of that full-page drawing. --Pwendt|talk 19:09, 11 November 2018 (EST)

P.S. The Library of Congress has a record of this edition, LCCN: 34-27187, which reports "plates". That means leaves of distinct paper stock, right? And normally the text is printed on other leaves. (I say "normally" but I have previously taken it for granted as universal.) --Pwendt|talk 19:27, 11 November 2018 (EST)

Alternate Titles field

(copied from R&S) ... [Software improvements could help with ongoing issues]

  • Firstly, adding equivalency of capital/small letters in Cyrillic and other alphabets ... (and while you're at it, improved handling of non-Latin-1 characters in the Roman alphabet too).
  • Secondly, adding the ability to ignore punctuation when searching and checking for duplicates.
  • Thirdly (perhaps as a stopgap in place of the other two suggestions), following up on a suggestion which was made some while ago, to add a field for alternate titles which differ only in punctuation or accents; the alternate titles in this field wouldn't be displayed (they wouldn't be mouseover text like transliterations are) but would help with searching.

--Vasha (cazadora de tildes) 15:49, 11 November 2018 (EST)

Re: "adding equivalency of capital/small letters in Cyrillic and other alphabets", it's certainly desirable and important. However, it's not really "adding functionality", it's "upgrading/replacing the database engine". Think of it as replacing a gasoline engine with a diesel engine: doable but time-consuming and but has all kinds of ramifications for the vehicle. Given my other current responsibilities (Fixer, maintenance, e-mail communications with 3rd parties like SFE3 and MIT, Wiki, etc) and my less than stellar health/energy/ability to learn new things these days, big projects like that are a steep hill to climb. We could really use another developer or two. During the summer I helped a volunteer set up a separate development server, but I haven't heard back from him in a few months. I have other prospects as well, but nothing definite at the moment. Of course, a number of our active editors have development backgrounds, but for some reason they seem to be unwilling to quit their day jobs and concentrate on ISFDB development. Most peculiar! (Fixer tells me that it may have something to do with the rumor that humans like to eat.)
Re: "the ability to ignore punctuation when searching and checking for duplicates", the main Duplicate Finder has three modes: Exact, Similar and Aggressive. The last two ignore punctuation. On the searching side, I experimented with different approaches a few months ago, but it turned out to be significantly more complicated that I had expected. Apparently, the guys at Google are well paid for a reason... Ahasuerus 16:30, 12 November 2018 (EST)
Yes, I remember you've said before that these things aren't really feasible without some change in circumstances (like additional developers). Sorry for bringing them up again. But since real improvements are far off, what do people think of adding a field for this sort of variant titles? We are currently using the transliteration field for the purpose, but it's not the best practice to mix two kinds of data in the same field. --Vasha (cazadora de tildes) 16:49, 12 November 2018 (EST)
Agree re: "it's not the best practice to mix two kinds of data in the same field". The issue has been raised in the past, but no FR has been created (that I recall.) The proposed functionality, as I understand it, would be a subset of the functionality supported by Field 246, "Varying Form of Title", which exists to record "alternative form[s] of the title" in the MARC 21 standard. The linked Web page includes various examples. If you would like to pursue this line of thought, we may want to move the discussion to the Community Portal. Ahasuerus 20:39, 12 November 2018 (EST)

(unindent) The proposal is to add a field for the purpose of collecting together minor variations in the title (or other author name, etc.) which currently cause the software to not recognize them as the same title (author). Namely, things like non-Latin1 characters (people need to be able to find Helen Oyeyemi's story "Dornička and the St. Martin's Day Goose" even if they type "Dornicka"), and minor differences in punctuation like whether there is or is not an Oxford comma. There are also existing instances in this database of the Transliterated Title field being used to store other types of variation that are on the MARC 21 page Ahasuerus linked, such as entering "One Hundred Cats" as an alternate to "100 Cats." The proposed new field would never be visible to users (it wouldn't be mouseover text like transliterations are), but it would be used by the software in searching.

This would be just an ad-hoc thing as a stopgap until (at whatever future time) the software is improved. People would simply enter whatever variants they can think of. We have already put some of that into the transliteration field; it would be a moderate-size cleanup project to move it to the new field and leave Transliterated Title for just transliterations from one alphabet to another. --Vasha (cazadora de tildes) 21:45, 12 November 2018 (EST)

Easier solution is to use Google. Add a new search option on the Advanced Search that uses a Google search with predefined syntax that limits the search to ISFDB and with specific words (Title, Publication, Summary Bibliography, Publication, etc.) in the page title. For the Dornicka example, intitle:title Dornicka will search only ISFDB for pages that have Title in their title (i.e. title records), and matches Dornicka which correctly returns "Dornička and the St. Martin's Day Goose" (try it). It would consist of a single pull down to select page type and a text box. That would be a lot easier than adding new fields (which need to be added to the database, multiple forms, search options, etc.) and also then need to be populated. Search engines are great at fuzzy matches so let them do their thing vs. recreating it in a much less ideal way. It will search the whole page, not just a particular field, which can either be a downside or a plus depending on your goal. -- JLaTondre (talk) 07:35, 13 November 2018 (EST)
It would be easy to add a "Google Search" option to Advanced Search. We could even add a context-sensitive "Google Search" check mark to the main search box. (The reason it would have to be context-sensitive is because a Google search on "Year of Title = 1872" wouldn't work too well.)
However, keep in mind that Google's data is typically a few weeks behind, so it won't find any recently added/changed data.
I am thinking that the low-hanging fruit would be to add a "Google Search" section to Advanced Search, which can be done quickly, and see what happens. Ahasuerus 08:26, 13 November 2018 (EST)
Yes, Google search isn't the ideal solution. However, I think it's better than the suggested interim solution given the trade between work & benefit. Though my over all preference would be doing neither since there is other work I'd personally rate higher. So maybe I'm biased. ;-) -- JLaTondre (talk) 11:35, 13 November 2018 (EST)
That'd help. But would it allow the stuff that doesn't belong in the transliteration field to be removed, or would we still need that? There's an existing cleanup report that mandates entering an alternative to non-Latin1 characters --Vasha (cazadora de tildes) 12:26, 13 November 2018 (EST)
Well, if you work with Cyrillic titles, you may have a different bias - try to look for an author called Вежинов and then вежинов. :) For example. Now think about how often people hit caps lock or shift by mistake :) Another option is to use the transliterated fields to contain a "lower case only" version of the name amongst the other transliterations and add an explanation to the advanced search (and on the result screens) on how to search in case you cannot find what you are looking for). Thus NO real work (besides a few comments in the search pages) as we already search the transliterations by default. That would be similar to transliterating the kanji in kana for Japanese. Not elegant but... good enough stopgap until we can swap the encoding. And once it is swapped one day, deleting these will be easy (as they will match without case to the main title). And it is similar to the whole alternative title thing... (at least for the search problems) minus the work. Plus there is a case to be made that going to all smalls is a type of transliteration (from an alphabet of A-Za-z to one with a-z)  :) Annie 12:32, 13 November 2018 (EST)
Uh, no, that is not a transliteration. Someday (hopefully) we are going to have a real solution to the problem of fuzzy searches/capitals in Cyrillic/etc. and then the transliteration field will just be for one alphabet to another (one writing system to another, in the case of kanji-to-hiragana). Why shouldn't we start now with the process of cleaning up that field, putting everything that is not a transliteration into a different field? We have thousands of titles currently where the lowercase version or non-latin1 character or whatever is in the transliteration field, and it would take a few days to go through and move them all; in five years we will have many more thousands—why not enter them into a different field to start with, instead of putting them in the transliteration field where they will eventually have to be removed? --Vasha (cazadora de tildes) 13:13, 13 November 2018 (EST)
Because I would rather have non-transliteration there than spend 2 (or 5) more years waiting for this DB to become even remotely usable for the titles in my native language. And as they will be exact matches (minus letter size), they will be easy to remove when we have that fixed - so we are not facing a long project pulling them out. Let's be realistic here, shall we? Great ideas and what's not is great BUT spending time to build a solution that will be obsolete when we change encoding is worse than dealing with some additional values in some fields. And dumping all kinds of stuff in a new field would not solve the problem - it will just move it to a new field (what goes there? Small letters ones, kana ones for Japanese? Something else? Everything that is not a transliteration?) Call me pragmatic if you want but I would rather not stress the single developer with something that we live without and where we have a soft solution that does not really degrade the data. Annie 13:29, 13 November 2018 (EST)
"We have thousands of titles currently where the lowercase version or non-latin1 character or whatever is in the transliteration field" - huh? Noone had added "lowercase" specifically anywhere so I am not sure what you are talking about? Annie 13:29, 13 November 2018 (EST)
"Transliteration" has a pretty concrete definition. It is taking a word written in one writing system and coming up with an equivalent in a different writing system. Yes, writing the sounds represented by a kanji character as hiragana is a type of transliteration. I am arguing that the Transliterated Title field should only be used for transliterations in this sense. Up to now, we have needed a place to store ad-hoc typographic information like the fact that people may search for "č" by typing "c" or the fact that French "œ" is a typographic variant of "oe," and we have put it into the transliteration field, but it isn't the same type of data and shouldn't go there. --Vasha (cazadora de tildes) 13:40, 13 November 2018 (EST)
Your claim is that NOW we have "small letters" being added to fields - see what I cited from your post. That's the part I am asking about. Because it is not true - we do not use the field this way now. Even if that would have made the DB usable. I know what transliteration is - both from the Linguistics side and from the Math/IT side. As for what is a valid transliteration - A-Zaz -> a-z is writing the same title in a new "set of characters". Not in the linguistics sense but then a lot of things are not. And œ/oe and Б/б are comparable. Just because the letters set is in the same alphabet does not make it less of a transliteration. Technically speaking. :) And again - moving all that "stuff" to a new field does not solve the issue - it just moves it to a new field. Or are we going to keep adding fields ad-infinitum? Annie 14:44, 13 November 2018 (EST)
But anyway - the point I am trying to make is that building a solution that will be obsolete soon does not make sense - when we can just reuse what we have. It does not matter if it is "clean", in both cases we will need to deal with it once the real solution is in place. Add effort, time to execute and all that and as much as I like clean solutions, I would take any solution at this point. Annie 14:56, 13 November 2018 (EST)

Types of Alternate Titles/Values

Let me take a step back and try to list the different types of "alternate titles/values" that we are discussing here. (I prefer "values" to "titles" because the discussion also includes authors, publishers, etc.)

First, here are the scenarios that are currently supported by our implementation of "transliterated values":

  • Romanized versions of non-Latin values. The current implementation supports multiple versions per original value, e.g. "Arifureta Shokugyō de Sekai Saikyō 1" as well as "Arifureta Shokugyou de Sekai Saikyou 1" for "ありふれた職業で世界最強 1".
  • For languages which use multiple alphabets/scripts/writing systems, version(s) of the original title which use alternate systems, e.g. "ありふれたしょくぎょうでせかいさいきょう 1" for "ありふれた職業で世界最強 1".
  • English versions of Latin titles which use non-English letters, e.g. "Dornicka" for "Dornička" and typographic variants like "œ"/"oe"

Next, here are the new types of alternate values which are being proposed, either to be entered in the requested new field or as additions to the list above:

  • Lower case versions of non-Latin values to help with searches
  • Alternative forms of the original value like "One Hundred Cats" as an alternate to "100 Cats". It could include other alternative values like the titles found on book covers and spines which we currently enter in Notes (or omit.)

Re: lower case versions of non-Latin values, I think it will only get us so far whether we enter them in the existing Transliterated Values fields or in the requested new field. Adding "павел вежинов" to "Павел Вежинов" won't help users who type "ПАВЕЛ ВЕЖИНОВ". Without full Unicode support, it will remain a band-aid.

Re: alternative values like "One Hundred Cats", it's been discussed a few times. I don't recall any objections, but it appeared to be a low priority. Also, it will remain a valid separate request even after the upgrade to Unicode. If we can reach consensus re: its desirability, I would be in favor of adding it as a separate FR.

Am I missing anything? Ahasuerus 17:05, 13 November 2018 (EST)

Punctuation is mIssing. Right now typing "X - Y" into the search box won't find "X—Y" and vice versa, nor will "X, Y, and Z" match "X, Y and Z." Plus we had a debate a while ago as to whether it was acceptable to use the transliteration field to enter "X and Y" as an alternative if "X & Y" is printed in the book (who can remember which form to search for?). Finally, I don't agree that typographic matters like c/č and œ/oe properly belong in the transliteration field. --Vasha (cazadora de tildes) 17:25, 13 November 2018 (EST)
So what do you call the č -> c (or ch) transition? It is converting Unicode/ to Latin1 which is the definition of transliteration in the IT world. Looking at the linguistics level, it is a transliteration between two Latin standards (in the same way in which Э э get changed to an existing letter in the alphabets that do not have it; or й between the Cyrillic standards)... But the main question still stand - how adding a new field that contains all that funny stuff will be helpful at all and not just moving the problem from one field to another. Just so it is not in the transliterated field? What is the difference? Maybe we should revisit why we have transliterations to start with - assisting reading from non-native editors and users and facilitating search for users that do not have the proper keyboard to create the special characters (or copying from a source that does not have the correct characters when searching). Or is the second not part of why we have the field anymore? :) Annie 17:43, 13 November 2018 (EST)

(Unindent) OK, instead of arguing about what is or is not a transliteration, and what can or can not go in the "Transliterated Title" Field, how about we rename that field to "Alternate Form of Title"? And agree that you can enter anything into that field if you think it'll be helpful? That'll make sense of all the diverse stuff that already is in it. --Vasha (cazadora de tildes) 18:09, 13 November 2018 (EST)

I think the first step would be to update Help with a list of everything that this field currently supports. After all, there are things that are disallowed at this time, e.g. alternative forms of the main title like the "One Hundred Cats" example above and transliterations that use non-Latin non-native alphabets/scripts. Having the current practices explained in one place (a new Help template, I assume) would get all of us on the same page. With the current rules codified, we would be in a better position to decide whether to:
  • rename the field
  • expand its remit
  • do something else
Ahasuerus 12:49, 14 November 2018 (EST)
Results of a survey of current ways this field is used with titles whose language is English--Besides giving alternatives for non-Latin1 characters, there are the following sorts of uses:
1. Giving text equivalents of titles with symbolical or mathematical elements in them. There are about 50 of these I think; here are a selection:
Rendezvous 10¹⁰   |   Rendezvous 10 to the power 10
   |   e^h
Golem¹⁰⁰   |   Golem 100
⁵Limericks   |   5 Limericks
X ≠ Y   |   X does not equal Y
∞°   |   Infinity Degrees
The World of Ā   |   The World of A   |   The World of Null-A
fan•dom (fan´ dəm) n. a way of life   |   fandom (fandum) n. a way of life
◍   |   "Circle with Vertical Fill" Hex code
   |   Cancer
*   |   asterisk   |   star
█████   |   {black bar}   |   [redacted]   |   redacted
Press Enter ▮   |   Press Enter []
<3/</3   |   less than three slash less than slash three
Foreword ((1⁴+2⁴+3⁴+4⁴+5⁴)+6⁴+7⁴)   |   Foreword ((1(to the 4th degree)+2(to the 4th degree)+3(to the 4th degree)+4(to the 4th degree)+5(to the 4th degree))+6(to the 4th degree)+7(to the 4th degree))
2. Giving "and" as an equivalent to &. Done 33 times with the "and" in the main title, & in the transliteration; twice the other way around.
3. Giving "plain" equivalents of titles that are written oddly. For example,
Channel Sk1n   |   Channel Skin
βoyfriend   |   Boyfriend
4. Multiple attempts at writing titles that cannot be entered the way they are in the book. Here is one I did myself: I represented "How Can I Help Hurt You?" as "How Can I Hurt You?" and "How Can I Help Hurt You?"
5. Punctuation variants (these are pretty rare). A selection of examples:
Perce Rock ▬ First Sighting   |   Perce Rock — First Sighting   |   Perce Rock - First Sighting
Little Green Men—Attack!   |   Little Green Men Attack
Never Fear: The Apocalypse   |   Never Fear—The Apocalypse
Interstellar Navigation, or Getting Where You Want to Go and Back Again (in One Piece)      |      Interstellar Navigation; or, Getting Where You Want to Go and Back Again (in One Piece)
6. Just plain alternate titles.
SciFan™ Magazine - 2017   |   SciFan Magazine - 2017
[a cover art title] Jump Point, Issue 02.03   |   Warned
The first of these categories, at least, seems pretty firmly within the existing mission of the field (the others may be extensions of the mission, and number 6 flat-out wrong). But "Alternate Writing of Title" or some such name seems to describe those text-equivalents better than "Transliteration." --Vasha (cazadora de tildes) 15:26, 14 November 2018 (EST)
Why isn't "™" in the first category? This is a special symbol, not two letters with weird formatting (in that writing anyway). Not much different from some of the others in category 1. I would not call that alternative writing - it contains a symbol that people may not be able to create... Just because it looks like letters does not make it letters really - not in a title. Annie 15:46, 14 November 2018 (EST)
Because SciFan Magazine is sometimes written with the TM and sometimes without, and I think this was intended as a way of putting both names in the same record. We should figure out which is the "real" title and/or make them variants of each other. (Not that easy because SciFan Magazine is now defunct and out of print, but ...) --Vasha (cazadora de tildes) 16:01, 14 November 2018 (EST)
It occurs to me: "and" is a text-equivalent of "&" so that one, at least, makes sense in the existing conception of the field. --Vasha (cazadora de tildes) 16:20, 14 November 2018 (EST)

(unindent) Attempt at codifying the use of this field (whatever it's called). Currently, it is chiefly for: 1. Transliterations from one writing system to another. 2. Providing Latin1 alternatives to non-Latin1 characters. 3. Spelling out mathematical expressions and symbols in words.

Proposal: As a logical extension of use no. 3, I would like it to be specified that it's acceptable use this field to spell out "&" as "and." Second proposal: spelling out numbers in words; this is also a logical extension of use no. 3.

Other possible uses: spelling out abbreviations? (e.g. vs./versus)? I'm undecided but I think maybe not.

We also have a few quirky miscellaneous uses at present, like the strikethrough example and the Channel Sk1n/Channel Skin example above. There are only a few of these, I don't see a better way to handle them, and as far as I'm concerned they can be left as is, ignored & not mentioned in the codification of the uses of the field.

It seems that this field should NOT be used for variant punctuation. The proposed Google search will take care of it instead (and much better).

Any thoughts on additions/subtractions to this list of uses? I think we are almost ready to write up a description of the field, and then we can debate its name. --Vasha (cazadora de tildes) 01:23, 16 November 2018 (EST)

Any further thoughts on this? --Vasha (cazadora de tildes) 16:27, 24 November 2018 (EST)
Thanks for researching the current patterns of use. One thing that comes to mind is that the proposed Google search functionality may also take care of certain other types of cases like "&" vs "and". It may be better to implement Google search first, see how much we can squeeze out of it, and then revisit this field. Ahasuerus 12:15, 27 November 2018 (EST)
It is true that Google can handle &/"and." But an argument in favor of entering the alternate text anyway (in just this one case) is the same as the argument in favor of keeping the Latin1-alternative uses of the field: why force people to switch to Google if you have a simple way of getting the direct search to find the desired result? The "and" situation is common (and annoying) and adding alternative text for it would be relatively easy. I don't think we should go hog-wild entering alternative text for all symbols, though. --Vasha (cazadora de tildes) 16:22, 27 November 2018 (EST)
Vasha, I saw you adding one of the &/and today. Let's wait a bit before we start changing things until we agree what we want to do. As annoying as it may be to you, just going ahead and doing something that may need reversal is losing everyone's time in the long run - and makes the DB even less consistent than it is. So let's agree first, then change in whatever direction we agree on. I know it is annoying and we all would love to have things happen faster but everyone doing what they want is not the path forward. :)
I would support adding & as one of the values that makes sense BUT... what about the other direction? Do we really want to add the opposite one for people that may search with &? I do not think so. So if it is one-directional, we need to make some notes on the result page around that. Annie 16:27, 27 November 2018 (EST)
I can think of a few additional issues with "and/&". For example, what should we do about non-English titles/values which use "&"? Should we use "und", "et", "en", "e", "y", etc depending on the language? Also, what should we do if there are multiple ampersands, e.g. "Linda & Daniel & Spike" or "Romeo & Julia — Innenansichten von Adam & Eva 2.0" or even "Filomena & Greg & Rikki-Tikki & Barlow & the Alien"? Ahasuerus 17:15, 27 November 2018 (EST)
Yeah, that's a good point... and then the other direction, combined with languages and what's not, gets even muddier. Thus my point - let's first figure out what we are doing before we start doing it :) Nothing is easy when you try to do fuzzy searches by hard-coding values... And that one may be solvable in a different way actually - less manual (details to follow when I work through them in my head). Annie 17:45, 27 November 2018 (EST)

Narrator Template

Can we add a Narrator template for publication notes? That will make it easier to find the books we have that are narrated/read by a certain person (and one day when we have "non-authors connected to books" fields, we can migrate easily. Annie 22:50, 12 November 2018 (EST)

It would be easy to add a new template for narrators assuming that the functionality is similar to that of the "Translator" template. Ahasuerus 08:53, 13 November 2018 (EST)
Yep, same idea. :) Annie 12:13, 13 November 2018 (EST)
What should we call it then? "Narrator"? Something shorter along the lines of "Tr"? Ahasuerus 15:35, 13 November 2018 (EST)
Narrator sounds good to me. Tr made sense but I cannot figure out how to make Narrator shorter without making it too cryptic :) "Reader" also works for me - although it should still be "Narrated by X" when on the page. Or maybe "Narrated/Read by X"... Annie 15:39, 13 November 2018 (EST)
Too long to type. Why not {{narr|...}}? MagicUnk 16:34, 13 November 2018 (EST)
Too cryptic if you ask me... But I can live with narr. Or maybe "read"? Annie 16:50, 13 November 2018 (EST)
Wellll, you could say that of "Tr" too. But once you know what it is, you won't forget. Narr has an advantage over read in that narr == narrated is easier to remember than read == narrator. MagicUnk 17:19, 13 November 2018 (EST)
"Tr. by X" is a standard bibliographical entry though :) Older books called those "readers", now the modern term is "narrator" although some books still say "read by". So they are interchangeable. So for some people the term is reader and not narrator so "narr" will be absolutely undecipherable. I can work with either - and we can always change if needed Annie 17:30, 13 November 2018 (EST)
I expect that "read" would be less intuitive than "narrator". Also, since I don't use audio books, I would probably find it hard to remember that "narr" stands for "narrator", but perhaps I would get used to it. Ahasuerus 12:33, 14 November 2018 (EST)
I still think that the one that will the least confusing is "Narrator" :) Annie 13:48, 14 November 2018 (EST)
That would be fine by me. Ahasuerus 15:00, 14 November 2018 (EST)
Sure, can live with that :) MagicUnk 16:59, 14 November 2018 (EST)

Narrator Template - Outcome

FR 1224 has been created. Ahasuerus 10:07, 15 November 2018 (EST)

Length for Audiobooks

On a related note, how long a book runs is comparable to page numbers. So should we add a new field to collect this information (audiobooks are more and more popular) or should we start using the "pages" field instead (as these will never have pages). I am more inclined to go for a new field (two separate pieces of data in the same field is a bad idea) but in this case as a book is either a paper one or an audio one, they are separate enough (and ebooks stay with the current policy of "no number of pages")Annie 22:50, 12 November 2018 (EST)

If a new field is added, it would be best if the software was smart enough to only display the correct field for the type of pub (i.e. physical books should page number, ebooks show nothing, and audio books show length) instead of always showing them. Or at least only make the correct one editable. Requires the edit form to be a bit smart as have to update the display when the format is changed while editing. -- JLaTondre (talk) 07:18, 13 November 2018 (EST)
I discussed some of the issues with dynamically changing the data based on the title/publication type here. Ahasuerus 08:33, 13 November 2018 (EST)
Field state (active/inactive, displayed/hidden) can be changed dynamically via JavaScript. Here is an example that displays a field when one option is chosen but not another. The value is not lost when hidden (in the example, change it to "Business use", enter text, change it to a different state, and the change it back). On the back-end, the submission logic would need to handle the fact there is a no longer needed value and toss it out. -- JLaTondre (talk) 09:18, 13 November 2018 (EST)
How about the same logic we use for "series" in variants? Annie 12:13, 13 November 2018 (EST)
That doesn't work the reasons Ahasuerus laid out in his above link. It works for series because you cannot make a variant a non-variant from the title edit screen. -- JLaTondre (talk) 12:45, 13 November 2018 (EST)
Yeah, missed that one when reading this morning. Oh well... I am not sure what is the problem with just having both and having editors just be careful plus a nightly report that finds values in the wrong field. Considering all the other problematic fields, that one is not even that challenging. I would love a software solution but if there isn't one that works across browsers and what's not, we can live with it :) Annie 14:47, 13 November 2018 (EST)
We could add pop-up validation that would disallow "length" values for non-audio formats, but first we would have to decide what to do with combined "paperback+CD" publications. Ahasuerus 08:33, 13 November 2018 (EST)
Any thoughts re: "paperback+audio" publications? I believe I have only one in my collection, but they have apparently become more popular lately. Their records should presumably allow both types of values. Ahasuerus 15:41, 13 November 2018 (EST)
Allow both fields to be populated for that case specifically. That should not be a problem, right? Annie 16:30, 13 November 2018 (EST)
There's an issue with adding fields at the front end: clutters the screen, losing oversight. Therefore, "smart" forms are the way to go. MagicUnk 16:55, 13 November 2018 (EST)
This is the part that I am not sure about. Back when we added context-sensitive drop-down lists to the Advanced Search page, some users commented that they didn't understand why values were changing as if by magic. I am concerned that dynamically adding and deleting fields based on the values of certain other fields (like the publication type field) would be even more confusing. Ahasuerus 12:40, 14 November 2018 (EST)
Really? Once upon a time I had something done very similar with an application I defined the functionality for (ie dynamically updating labels dependent on certain type values), and no-one ever complained that was confusing. Au contraire, I definitely got the impression they really ignored it altogether... MagicUnk 16:54, 14 November 2018 (EST)
A lot can depend on the user community, including things like their computer savvy, whether they are occasional users or regular users, etc. Ahasuerus 10:06, 15 November 2018 (EST)
(Adding more fields to the database isn't an issue. In fact, on DB level fields should never be used for multiple purposes). There's another way of dealing with using a single input field for two different value types: change the label only, and when saving, the backend logic determines in which field to save the entered data, dependent on title type. Only one field needed, so no keeping track of previously-entered data when switching type.That approach doesn't support the pb+audio though, but it might be useful approach somewhere else... MagicUnk 16:55, 13 November 2018 (EST)
Which is where I started - reuse the field we have now. Technically pb+audio is not different from a boxset where we do 300+300+300 for example... as long as we know what is first :) New field will make it less confusing for new editors BUT more convoluted for us (what do we show on pub lists under a title for example)? Annie 17:27, 13 November 2018 (EST)
Not sure we were actually saying the same; there's a distinction to be made between adding additional fields on the forms (and hence to the DB as well) - which is what you were proposing if I understood correctly?, as opposed to keeping the UI slick, keep changes and additions to a bare minimum, and only expanding the DB tables with additional attributes. MagicUnk 16:57, 14 November 2018 (EST)
My initial note had two proposals - keep one field for both (type determines what it means) or add a new one. How the DB is designed behind that is irrelevant really - and if we have a single field, doing separate DB fields and from there separate search options will be confusing (and can have performance considerations if someone tries to do a query weirdly) so if we stay in one field, we should just stay in one field if you ask me. :) Annie 19:39, 14 November 2018 (EST)

Changing data entry forms dynamically -- options

I have been thinking about JLaTondre's response above and, more generally, the options that we have when data entry forms end up with internally inconsistent data: CHAPBOOKs with Series data, non-OMNIBUS titles with "Content" data, and so on.

I will first list the options that I was aware of when I was writing this comment:

  1. Disallow changing the values of certain key fields to avoid inconsistencies. This is currently done in Edit Title for REVIEWs and INTERVIEWs: you can't easily convert them to other title types.
  2. Gray out certain fields based on changes to key fields like "title type". This is currently done for the two Series fields when editing CHAPBOOK titles. It's not a great solution since the fields remain grayed out even after changing the title type.
  3. Add pop-up validation to prevent editors from creating invalid records. This is what happens when an editor enters a value in the Content field for a non-OMNIBUS title or a "Length" value for a non-SHORTFICTION title.
  4. Dynamically gray out and blank affected fields whenever changes to other fields make them invalid, e.g. Series fields for CHAPBOOK titles. The problem with this approach is that blanking no longer relevant fields becomes a problem if the changes that prompted the blanking are reverted.
  5. Cleanup reports. Lots and lots of cleanup reports.

In addition, we have the following options when "key" values are changed:

  1. Dynamically gray out the affected fields, but do not delete their data. That way if the changes to "key" fields are reverted, "ungraying" the affected fields will restore their data. The problem with this approach is that it may confuse editors who won't understand what "grayed out" data means and whether it will be filed into the database upon submission approval.
  2. Make the affected fields invisible; if the "key" changes are reverted, make them visible again. Would new editors find disappearing fields confusing?
  3. Dynamically gray out the affected fields, delete their data and save it within the browser (probably using a hidden field, which is what we do in Advanced Search.) If the "key" changes are reverted, use the saved data to restore the affected fields' values.

From a purely technical perspective, it's all doable. Functionally, I think I prefer pop-up validation to the "gray-out"/"invisible" options. I suspect that (but can't be sure) changing the form layout and/or the field status dynamically has the potential to confuse new editors. Ahasuerus 16:19, 13 November 2018 (EST)

I am fine with popups. Annie 16:48, 13 November 2018 (EST)

Autobiographical titles acquisition

For our spec-fic authors, which of their publications about themselves should we include in the database? Any threshold on the author should be lower than that certain threshold (ISFDB:Policy#Included, point 4) over which all publications should be included.

For instance, in 1936 newspapers I find coverage of the new book A Long Retrospect as the autobiography of F. Anstey --see LCCN: 36-21029 and ASIN: B000857ECY at Amazon UK. And I find notice that Laurence Housman has nearly completed his own autobiography --not pursued.

One issue here is routine acquisition from secondary sources, as many works mentioned in SFE3 and The Encyclopedia of Fantasy biographical entries are routinely added. Knowing that the book is by Anstey about Anstey, say. Let me stop here. --Pwendt|talk 16:44, 13 November 2018 (EST)

I don't think we have a separate threshold for autobiographies of primarily non-genre authors. That said, as a collector of all things Anstey, I understand where you are coming from. He wrote a fair amount of notable speculative fiction starting with Vice Versa, a minor classic of the genre. Tourmalin's Time Cheques was an early time travel novel which preceded Wells's The Time Machine, etc. Even though we currently don't include his non-genre works, I agree that his autobiography should be included.
At the same time, I am not really sure how we could address this issue at the Policy level. Adding a new threshold for autobiographies would likely only complicate things, especially considering the nebulous nature of the current "certain threshold" for non-genre works. Perhaps we could include autobiographies as "books ABOUT speculative fiction"? Ahasuerus 12:26, 14 November 2018 (EST)

Question about Connection Security

HELP! I have joined ISFDB only on a temp basis because "The Connection is not Secure" is the WARNING I get when entering my Password. I tried using https:// before the URL, but this fails. And I searched high and low for a Contact Us address, but there is none! Only way to get this message to you was to join as a temporary member, pending improved security. Please advise, before the Russians start messing with my account... —The preceding unsigned comment was added by Temp Insecure‎ (talkcontribs) .

Answered on the user's Talk page. Ahasuerus 19:35, 13 November 2018 (EST)

Author names alphabetized

The way co-author names are displayed has been changed. In the past their order was random. Now they are displayed alphabetically based on their respective directory entries (typically family names) and the working names. If you come across any discrepancies, please post them here. Ahasuerus 20:33, 13 November 2018 (EST)

I don't understand "respective directory entries (typically family names) and the working names" and I may miss the point entirely.
Is this true for Title records only?
Selected title listings for series Gulliver's Travels:
  • Variant: The Wonderful Voyages of Gulliver (1909) [as by Jonathan Swift and Edith L. Elias]
  • Gulliver in Giantland (1907) [SF] by Jonathan Swift and Edith Robarts [only as by Edith Robarts and Jonathan Swift, D.D.]
  • The Adventures of Gulliver (1954) [SF] by Jonathan Swift and E. E. Ellsworth
  • Gulliver's Travels (1987) [SF] by Jonathan Swift and D. K. Swan and Michael West (II)
Those co-authors (commonly if not always, Swift and one or two who adapted or retold his work) are not listed alphabetically by family names. Spot check of author records shows correct directory entries such as "Swift" for Swift, D.D. and "West" for West (II).
In the latter case, with three co-authors listed non-alphabetically, the bibliography for author Michael West (II) lists twice, as chapbook and short fiction:
  • Gulliver's Travels (1987) with Jonathan Swift and D. K. Swan
There West's two co-authors are out of sequence, same as in the title listing as displayed for the series. --Pwendt|talk 17:19, 29 November 2018 (EST)
It looks like there are still display bugs on Series and Summary pages. Thanks for reporting them! Ahasuerus 17:40, 29 November 2018 (EST)
Series and Summary pages have been changed to display author names alphabetically. If you come across any other bugs, please post them here. Ahasuerus 19:55, 9 December 2018 (EST)

Title case cleanup - how?

(copied over from R&S): For the Dutch titles - and likely for other languages too - almost all titles hitherto entered in the DB follow the English capitalization rules. Now that we have made it clear language-specific capitalization rules are to be followed, titles need to be updated. What would be the best approach? Can we automate/manual excercise, cleanup reports,...? MagicUnk 17:30, 14 November 2018 (EST)

It is possible to create language-specific cleanup reports to look for titles with second/third/etc words capitalized. I expect that there will be a lot of false positives, so they'll need the "ignore" functionality from the get-go. Ahasuerus 18:29, 14 November 2018 (EST)
Would it work having a nightly job that automatically converts pub titles to the title title's case? Would be great not having to go through both title and pub titles. MagicUnk 02:21, 15 November 2018 (EST)
Originally, there was no requirement for publication titles to match the titles of their respective "reference titles". In fact, we had somewhat different data entry rules for them. However, the rules have been converging over the last few years. We also have a cleanup report which looks for significant discrepancies between publication titles and their reference titles. At the rate things are going, we may want to consider enforcing consistency in the foreseeable future. For now, though, they can be different.
In addition, any kind of automated processing that changes ISFDB records without human supervision is potentially dangerous. We don't have anything like that in place at this time. Ahasuerus 09:56, 15 November 2018 (EST)
As I recall, French and Russian titles have been using "sentence case" for a long time, so they should be in pretty good shape. I am not sure about other languages. I guess we could start by contacting the editors who have been working on major European languages to get a better idea of what the scope of the project(s) is likely to be. (And I see that Annie has already made a similar suggestion on the R&S page.) Ahasuerus 18:29, 14 November 2018 (EST)
From my OCLC cleanup and the language assignment one before that, French, German and Russian are indeed in a relatively good shape. Dutch is not looking too bad although it is a bit worse than the other 3 - there are a lot of titles with the wrong capitalization but from what I had seen a lot more that are added correctly. Spanish is a mixed bag (although I had seen a lot of updates going through), Italian is right there with it and Portuguese will give us a headache. The Western Slavic languages and Hungarian are mostly in the proper sentence case; so are Serbian, Romanian, Finnish and the Scandinavian ones. Bulgarian is clean :). Greek may be a bit of a challenge; the smaller ones should be easy enough to vet even if we go title by title. So as long as we decide on the rules, we may learn more.
Re. Dutch not too bad: I'm afraid that's not true. I did a search, and for the first few hundred results, all needed correction to sentence case.
The first hundred are stories with special characters and what's not which are relatively old records. It gets a lot better downstream - somewhere along the line Dutch editors started using the proper case. Although due to the volume of records, there may be more than expected... :) although looking a bit more into these, Dutch may need reclassification indeed - not sure which language I was thinking of. Oh well. That will be a very long project. Annie 02:43, 15 November 2018 (EST)
But point still stands - we need first to agree on the rules for a language before we start changing things in that language. Annie 18:54, 14 November 2018 (EST)
I'm confused?! Didn't we already agree on the case rule for Dutch? - true, not yet for punctuation but that shouldn't prevent us from cleaning up the ones that have no issue with punctuation. Or am I missing something here? MagicUnk 02:12, 15 November 2018 (EST)
You telling us that is the rules on a page is not an agreement - especially in a language we have multiple editors. Get the other editors to agree, we get closer. And when the official rules are changed, it is considered agreed on. Annie 02:43, 15 November 2018 (EST)
Btw, I'm asking because I'm going through a lot of Dutch titles atm. MagicUnk 02:18, 15 November 2018 (EST)
Then leave a few messages around so we can get the rules locked down? Annie 02:43, 15 November 2018 (EST)
Yes, let's get those rules locked down. We have agreed to language-specific capitalization, but we haven't touched punctuation. Seems like we really ought to talk about punctuation before starting cleanup so as not to have to make multiple passes through the same records?
As for the Spanish data, there are quite a few Spanish records that were imported by machine in the early days of automated imports and were never cleaned up, and they're often in bad shape in every field. I fix them when I see them but I haven't had time to go after them systematically. --Vasha (cazadora de tildes) 19:02, 14 November 2018 (EST)
Not just Spanish - a few more languages seem to have been imported the same way. Spanish is just the biggest offender. Plus we also have the translators to sort out so we can do 3 in 1 while editing for case, punctuation, subtitles and so on anyway. :)
So Title Regularization invites everyone to contribute so we can start clearing languages. Annie 19:10, 14 November 2018 (EST)

"0" Page Counts - Software Changes; Ebooks

While reading the code earlier today I finally recalled why we had special display logic for "0" page counts. Back in 2006-2009, when ebooks and audio books were not as common as they are today, we tried to come up with a standard for entering them. Both "0" and "unpaginated" were proposed as the preferred way of entering their page counts and the software was updated accordingly. That semi-standard was abandoned years ago and is no longer mentioned in Help.

Based on my findings, I have updated the software not to do any kind of special processing for "0" and "unpaginated" page counts. As of 15 minutes ago, the software simply displays whatever is in the "Pages" field, assuming that it's not empty. I have also removed "0" from the page count fields of all ebooks. Fewer than 2% were affected.

This leaves us with 119 webzines and 9 "other" publications which still use "0" as their page count. I left them alone for now in case anybody wants to look into them. Ahasuerus 17:52, 14 November 2018 (EST)

I will check the "other" ones and update as necessarily. I think that getting the webzines cleaned should not be a problem - they are not different either...
Any chance of adding the nice yellow warning when someone tries to add pages on non-text material? Annie 17:58, 14 November 2018 (EST)
Potential problem: theoretically ebooks don't have pages; however, PDFs, which do have pages, are lumped in with other ebooks --Vasha (cazadora de tildes) 18:19, 14 November 2018 (EST)
We can exclude ebooks for now - I am more concerned about audiobooks and the like at the moment. However - even for PDFs, our rules say not to record page. So... technically those should be empty. If we want to separate the PDFs, we need a separate discussion. But that opens the Pandora box of the old Fictionwise titles (remember those?) that you could download in more than one format, one of them being PDF - and recording all formats as separate books did not make sense. Thinking about that, there are a few publishers like that nowadays as well... Annie 18:26, 14 November 2018 (EST)
Although I unfortunately can't recall exactly what it was, I know I saw one book which was offered in PDF format with illustrations or ePub/mobi without illustrations. Really, PDFs aren't quite the same thing as other ebooks (more similar to a printed book in some ways). But I don't want to start a discussion about that on top of the other 20 ongoing discussions. --Vasha (cazadora de tildes) 18:43, 14 November 2018 (EST)
For some of them. But for a lot of publishers, they are basically the same - just a new format... When there are illustrations in one and not in the other, they should be separate records anyway. Although the current e-book formats support images so... the differences will be less and less. And converting between the formats is trivial. I do not dispute that there are e-books that have pages (from scanned copies of paper books to proper PDFs), we need to decide what we want to do about them before we start adding page numbers (as the current rules do not make a difference). Annie 18:59, 14 November 2018 (EST)
Keep in mind that a yellow warning is just that -- a warning that tells the approving moderator to do more digging. For example, Fixer submissions without a publisher generate warnings, but in many cases they are OK "as is". Ahasuerus 10:00, 15 November 2018 (EST)

SFBC question

I picked up an SFBC copy of Rift in the Sky. It has an SFBC number, 1275245, on the back part of the jacket. ISFDB has this record for DAW Books / SFBC which says "Catalog ID: 08-6848" and "Catalog #/price from the SFBC flyer."

My question is - do SFBC fliers, at least in 2009, have the number that's printed on the jacket? I'm wondering if I should edit the existing record, change the catalog #, and update the notes that that the catalog # in the SFBC flier is 08-6848 and that the publication states 1275245. Or should I create a new DAW Books / SFBC publication record for Catalog # 1275245. --Marc Kupper 02:54, 15 November 2018 (EST)

We have some data here. Just adding some notes - I did some digging when we started the "move the ID project for SFBC". My understanding is that 08-6848 should go back down in the notes (even if it is not your book) as it is catalog number and not an ID number (which is what we put in the catalog field). Cannot help much more I am afraid but I am sure someone will be along with more data... Annie 03:03, 15 November 2018 (EST)
I believe the printed 1275245 corresponds to the SFBC catalog number 12-75245, which I then think means it's a different edition from that of the existing record. --MartyD 07:01, 15 November 2018 (EST)
I do not think that the conversion is that clear cut - ID 1353404 has catalog ID 13-534046 for example and not the expected 13-53404 - the catalog always adds one more number at the end... But I would agree that this looks like a different book though... Annie 14:59, 15 November 2018 (EST)
Thank you. I'll go with a new record as the numbers are very different. --Marc Kupper 02:16, 16 November 2018 (EST)

The Witch of Blackbird Pond

Is this book really eligible for being here? As far as I can tell, it's not actually fantasy at all. Rather, it's historical fiction that has multiple people being accused of being a witch in early New England. We have quite a few publications of it listed. Thoughts? ···日本穣 · 投稿 · Talk to Nihonjoe 14:47, 15 November 2018 (EST)

All 3 verifiers are active so why don't we check if one (or more) of them read the book and can tell us if there is anything speculative? Annie 14:56, 15 November 2018 (EST)
Invited. I read it years ago, and I don't remember any speculative fiction content (as defined here) at all. It's just historical fiction. No fantasy, science fiction, or horror at all. ···日本穣 · 投稿 · Talk to Nihonjoe 15:06, 15 November 2018 (EST)
Ah, did not realize you read it. Let's see if someone else has an opinion (as it is a children book, I wonder if we are not looking at fairy tales kinda situation?). If it is indeed not speculative, I agree that it needs zapping. Annie 15:20, 15 November 2018 (EST)
You can read the summary over here, too. ···日本穣 · 投稿 · Talk to Nihonjoe 16:09, 15 November 2018 (EST)
Yeah, I did not see anything there but then half the magical realism sounds non-speculative to me as well (even after I read it) :) Annie 16:24, 15 November 2018 (EST)
I verified it because I had it, and because it was extensively listed on this site. I've been meaning to read it since I was knee-high to a grasshopper, but I still haven't gotten around to it. I'm assuming that it was added back in the early days of this site, and then people just continued to build on this submission. It was a popular book in its day, but to get the real deal on the content of this book you'll probably have to ask some other geriatric case besides me, who has actually read the book. If it has to go the way of the dodo, then so be it. Too bad you can't ask the general contributors of this site. Maybe on the "help" page. MLB 17:02, 15 November 2018 (EST)
Yeah, I have read it (a long time ago) and don't remember anything speculative. --Vasha (cazadora de tildes) 18:32, 15 November 2018 (EST)
Vasha's right, the "witch" angle is the xenophobia and superstition of the New Englanders and their persecution of the title character. Ofearna 23:14, 16 November 2018 (EST)

(unindent) So anyone opposing the deletion of the title (and all the publications containing it)? Annie 23:40, 16 November 2018 (EST)

I have no objection. It might be nice to copy-and-paste the verified pubs' data to their respective verifiers' Talk pages for reference purposes. Ahasuerus 10:22, 17 November 2018 (EST)
Delete away. That book was in a collection I bought, not a keeper or a read-me. Only entered because it was already listed. --~ Bill, Bluesman 13:50, 18 November 2018 (EST)
Deletion has been completed. Those who had verified any of them have the publication information on their talk pages. ···日本穣 · 投稿 · Talk to Nihonjoe 13:58, 19 November 2018 (EST)

Title checkboxes now appear on the same line

As per this discussion, title checkboxes now appear on the same line. The change affects all New Publication edit forms as well as Edit Title. Let's see if the new layout is an improvement.

P.S. You may need to do a full page reload (Control-F5 in most browsers) for everything to display correctly. Ahasuerus 18:56, 15 November 2018 (EST)

They should be a little farther apart: the labels need to be more visually separated from one another. --Vasha (cazadora de tildes) 19:24, 15 November 2018 (EST)
Good point; I have made the changes. Could you please do a full page reload to see if the spacing looks better? Ahasuerus 20:32, 15 November 2018 (EST)
Yes, that's an improvement. --Vasha (cazadora de tildes) 20:37, 15 November 2018 (EST)
Can we do something about the focus on these fields? At the moment it jumps from Content to Synopsis when you tab through it, skipping the checkboxes (both on addPub and editPub). When I am not working on a touchscreen, not needing to use the mouse to navigate the page is pretty useful. These are also the only ones that are skipped :) Annie 20:41, 15 November 2018 (EST)
Sure, let me take a look. Ahasuerus 20:58, 15 November 2018 (EST)
Done. Ahasuerus 21:11, 15 November 2018 (EST)
You are getting faster and faster in fixing these. Thanks! Annie 21:20, 15 November 2018 (EST)

Google search proposal

(copied from above) Re: lower case versions of non-Latin values, I think it will only get us so far whether we enter them in the existing Transliterated Values fields or in the requested new field. Adding "павел вежинов" to "Павел Вежинов" won't help users who type "ПАВЕЛ ВЕЖИНОВ". Without full Unicode support, it will remain a band-aid. Ahasuerus 17:05, 13 November 2018 (EST)

(moved from above) : No, it won't help the guys that write in caps only but combined with a note on the search result page that mentions that if you are using non-standard Latin characters, you should search in small letters, it will be a better band-aid than anything else we can come up with for the short term... I've never called it a solution - just a short term way to make the DB somewhat usable. Annie 17:43, 13 November 2018 (EST)
Well, if the proposed addition of all-lower case versions of titles/names/etc requires an Advanced Search note to be fully functional, wouldn't it be easier to display an Advanced Search note about the need to use the exact case for non-Latin-1 characters? Ahasuerus 19:25, 14 November 2018 (EST)
Yes but that will require you to know the capitalization rules of the language. Which will be ok for speakers of the language; not as good for a researcher that can read the script but has a shaky idea of the language... And then you have Легуин/ Ле Гуин. When we have all the titles, finding either will work but if you had never seen her name written the other way, that "Guin" will trip you. I am not saying that is a perfect solution - away from that. Just trying to find a workaround... If everyone thinks that this will be an overkill, then I am fine with just adding a note to ask "according to language rules" with a link to the new pages we are building. Either will be better than now :)Annie 19:34, 14 November 2018 (EST)
I had been thinking on that. While this will make our search a bit more manageable, it is really a bandaid. And considering the Russian titles, it will take a long time to update all of them. And a user that is not used to the DB won't really do a second search this way... So... why not use google to help us (someone already mentioned it above - I am just slowly warming up to it). Unlike us, it speaks languages and actually can do some level of autocorrect (which is helpful if you are not strong in a language). So... why not modify the search result page and just give the ability to search in google (with the site name added already and so on. So the built-in search is still there for direct matches but we have a viable way for someone to find something if they do not spell exactly as expected. Annie 22:02, 15 November 2018 (EST)
Yes, it was originally proposed by JLaTondre. I can think of a few ways to leverage Google Search:
  1. Add "Google Search" as a new section within Advanced Search [original proposal]
  2. Add a "Google Search" checkbox to the standard search box, which will alter the behavior of the search logic, redirecting it to Google [my original response to the proposal]
  3. If a search (regular or Advanced) fails, display the standard "No matching records found" message, then display a Google Search button with an explanatory note. If clicked, the button will execute a Google Search for the entered value and the appropriate search type.
  4. In addition to option 3 immediately above, even if a search succeeds, display the Google Search button in addition to displaying the standard results table.
My current thinking is that options 3 and arguably 4 may be our best bet. They wouldn't affect the current workflow and would provide additional functionality without interrupting anything.
The only partial failure scenario (that I can think of) would be the regular ISFDB search engine finding only one matching record and automatically redirecting the user to that record's page. That's what we typically want to happen except when we have other "imprecise" matches which our search logic doesn't find. Still, it appears to be a good compromise. Ahasuerus 23:18, 15 November 2018 (EST)
This is an excellent thought. I like your proposal 3. --Vasha (cazadora de tildes) 01:01, 16 November 2018 (EST)
I'd like to see the link as well when there are results - the more titles and authors we get, the more often we will be getting false positives (aka something matching but not you are not looking for...). Add also a checkbox in Advanced Search that allows the search to be done via Google instead of our search (so you do not need to fail a search first) and we should be all set. Annie 01:08, 16 November 2018 (EST)
(After sleeping on it) Modifying Advanced Search to work with Google may be tricky. We support a lot of different permutations ("Reviewed Author is not exactly Павел Вежинов") which may not directly translate to Google queries. We'll have to review Google's documentation to see which parts can be approximated. It may be best to start with our regular Search, which should be much easier to implement. Ahasuerus 09:06, 16 November 2018 (EST)
I think that my statement went away from me :) I was thinking more in the line of "where to put it so I do not need to fail a search first", the Advanced Search sounded as a nice place and I ran with it. I would agree that putting the whole advanced search out is not as easy. Annie 13:46, 16 November 2018 (EST)
Google is a page search engine, not a database field search engine. They are inherently different workflows. I would not do #3 & #4 with advanced search results. There is not a way to duplicate the field logic and the results could be confusing to users. I'm not even sure I would do it with regular search. I was envisioning adding a new section to the Advanced Search page, labeling it Google Search, providing a single pull down to pick the page type (All, Title, Author, etc.) and a single search box for people to enter terms. Could add some explanations regarding quotes for phrases and negatives for not. Why make it complicated? Most people are familiar with search engines already. Yes, it's more focused at the experienced ISFDB user who understands the limitations of the ISFDB search and why you'd want to use it. But I'm not sure #3 & #4 on the basic search help users who aren't. -- JLaTondre (talk) 10:12, 17 November 2018 (EST)
I think the main reason to add a "Google Search" button when the regular search logic finds no matches is to give less experienced users -- who may not realize that our software doesn't support approximate searches, what Advanced Search options are available, etc -- a simple way to recover. Currently, if they enter "павел вежинов" instead of "Павел Вежинов", the software tells them that we don't know anything about "павел вежинов" and that's it. The proposed "Google Search" button would give them the ability to retry the search near instantaneously. Of course, we'd need to add an explanatory note.
That said, I can see the value in creating a separate "Google Search" section within Advanced Search. I expect that only more experienced users will know about it, but hey, experienced users are people too!
It should be fairly easy to implement and tweak as needed, so I have created FR 1226. I am out of sorts at the moment, so it may be some time before I get to it. Ahasuerus 20:43, 17 November 2018 (EST)

New Template: Narrator

A new template, "Narrator", has been created. Help has been updated. Ahasuerus 10:44, 16 November 2018 (EST)

Haldeman's 'All My Sins Remembered' series

I propose changing the name of Joe Haldeman's series that we currently have under the name of 'All My Sins Remembered' to 'Confederación'. There are other 'Confederación' stories that do not appear in the 'All My Sins...' collection, such as the first four stories in Vietnam and Other Alien Worlds. They're usually/generally referred to as Confederación stories, also by Haldeman himself. Feedback appreciated! PeteYoung 02:40, 18 November 2018 (EST)

Yes, I'm all for it. It's plain better than to name it after one of its titles. Stonecreek 09:52, 20 November 2018 (EST)

Midsummer Century by James Blish and Planet of No Return by Poul Anderson

With just around 100 pages of text as a stand-alone publication and 95 pp. within the same-named collection this has to be correctly defined as a NOVELLA. If there's no objection, I'll merge it with the existing SHORTFICTION. Stonecreek 09:51, 20 November 2018 (EST)

The title record you linked to says:
Expansion of the version published in Magazine of Fantasy and Science Fiction in April 1972.
Have you done a word count to see if it's under 40,000 words? There are three hardcover editions.1 2 3. The word count, not the page count, is how the stories get classified.
The main support for novella is that it's also part of a collection, Midsummer Century, meaning at present we have a collection that contains a novel plus two other novelettes. --Marc Kupper 23:14, 20 November 2018 (EST)
I've done a word count for the German translation: it comes round 34,000 words. It would be good if it's remembered by whom the note was added, if it's based on an actual word count, or was put there because the publisher called the book publication a novel (anyway, even an expansion doesn't have to mean that it was expanded to more than 40,000 words). And the very most examples of publications in book form have shown that there have to be at least 120 pages of text to qualify it as a novel (sometimes even 140 pages are still a novella). Stonecreek 23:47, 20 November 2018 (EST)

The same transformation from NOVEL to SHORTFICTION (novella) seems to hold for the title by Poul Anderson. Are there other (higher) word counts? Stonecreek 15:05, 22 November 2018 (EST)

And also to Anderson's The War of Two Worlds, which is even shorter than Planet of No Return, here. I habe changed both to shortfiction (novella). Stonecreek 10:41, 30 November 2018 (EST)

Canonical name change

The writer formerly known as Joseph Allen Hill is now going by Violet Allen and has had 2 stories published and an award nomination with the latter name. I am going to be changing her canonical name tomorrow. --Vasha (cazadora de tildes) 18:58, 24 November 2018 (EST)

I don't think we reached consensus to do this. Shouldn't the canonical name be Hill with 11 titles published instead of Allen with only 3? --Ron ~ RtraceTalk 09:03, 25 November 2018 (EST)
That's right. No consensus was reached, so the data entry rules were not changed. Template:AuthorFields:CanonicalName still says:
  • the canonical name is the most recognized name for that author within the genre
The only thing that changed based on that discussion was how the software treats alternative names. They used to be called "pseudonyms", now they are called "alternative names". Ahasuerus 10:18, 25 November 2018 (EST)
In the meanwhile, we are still behaving abominably toward transgender authors... It's unacceptable. We need to make the policy change. --Vasha (cazadora de tildes) 13:23, 25 November 2018 (EST)
Perhaps at some point we'll be able to reach a new consensus re: this issue, at which point the policy will be changed. Until it happens, moderators are expected to enforce the current policy. Ahasuerus 14:34, 25 November 2018 (EST)
The fact that moderators (as a community) can't summon up basic courtesy toward authors doesn't say very good things about the culture here, at all. This is an instance where indifference and inaction are affronts. --Vasha (cazadora de tildes) 15:18, 25 November 2018 (EST)
Except that this has nothing to do with courtesy or someone's gender, religion, changed marital status or whatever. We are a bibliographical database - not a biographical one. Our main source are the books - anything else is just supporting data to help us make the DB better. Which is why our definition of a canonical name is not "the name the author prefers or uses now" but "the most recognized" and by extension, "the one that is on most books". I respect the choice of someone to start using a new name for whatever reason but if most of their books still carry the old name, that old name is still the bibliographical name under which people recognize them. Add a note on the author page that as of this date they are using a new name if you want; keep an eye on their output and add anything new until the balance start shifting - but until the majority of books/stories one can read carry the old name, most people will look under that name.
Now... when we opened the DB for webzines and other web sources, that may change the equation a bit - because now the name on the record may change - and we may need to have a discussion around that. But this is not the case here. So let's not throw around accusation of lack of respect and what's not - the field does not record what you want it to - and if you want that to change, start a discussion. A bibliographical one if possible. Annie 17:21, 25 November 2018 (EST)
Blaming lack of respect on "simply following bilbliographic principles" is not a way to get out of responsibility. In fact, it's a classic ploy by people who have the power to chose public naming practices; we must use our power better. Be an ally for transgender people and create a new rule for canonical names that accepts and validates their identity. We would not be overriding any bibliographic data that way. People who look up the old name would simply be redirected to the new one. --Vasha (cazadora de tildes) 17:29, 25 November 2018 (EST)
So in your view a name change is important only when it happens because someone is transgender but not when someone changes their religion or marital status or just feels like it? Why would one require validating while the rest do not? How we record one's name does not depend on their gender, nationality, race, eye color, a change in any of them or anything else like that. We cannot have one rule for someone changing a name because of getting their gender aligned to their identity and a different one for a religion change (for example). If we decide to change the rules, it should not be because of a specific type of a change. And that change needs to go through changing what "canonical name" means in the DB - because it sounds like that is what you have an issue with (and you are conflating that with respecting people and so on). Are we still talking about books and their records here or did that conversation drifted somewhere again?
Yes, transgender people do need all the support they can get. So do a lot of other groups. But making special rules for that is not the way to go - not if you are really looking for normalization and respect. Start a new discussion about changing the meaning of "canonical name" to "preferred/currently used", come up with a plan on how we will follow changes (because otherwise we will end up with a lot of "you changed theirs, why not mine" kind of situations and we can change the rules. Or do we only care when we hear about the change? Annie 17:51, 25 November 2018 (EST)
Reopening a Rules and Standards issue on the Community Portal would only splinter the discussion, so I will limit my comments to the following.
Over the years, we have seen a number of requests to change our bibliographic practices based on their impact on publishers and authors. For example, at one point a user stopped by and argued that some of our practices were harming small presses by making major publishers unduly prominent. At another point an author was unhappy about the inclusion of her works and told us that she never asked us to list them.
To the best of my recollection, none of these arguments have been accepted. We are a bibliographic project. Our primary goal is to create comprehensive and accurate bibliographies. We are not in the business of allying with or validating anyone. We try not to let our personal esthetic, political, national, ideological, etc preferences determine the scope or the policy. If we did, the project would be harmed because we all have different preferences. Ahasuerus 18:34, 25 November 2018 (EST)

"Black Helicopters"

Opinions wanted: should the 2018 version of Caitlín R. Kiernan's Black Helicopters have a separate record from the 2013 version? It sounds to me like it should, based on it being described as "expanded and completed" (as a weaker indication, doesn't publish reprints so they must have thought this work was new in some sense). However, I've only seen the new version and would like to hear from someone who's seen both and can compare. --Vasha (cazadora de tildes) 15:15, 28 November 2018 (EST)

Sounds similar to Nina Allan's "The Race" case: here - the second edition added a new section which not only changes how the novel finishes (and shifts the understanding of some earlier sections) but also increases the size significantly. I would think we should have a variant for such significant changes (or even separate titles) but none of the two concepts match exactly (although if an abridgement is a variant, why not expansion?). Anyway... no real idea about what we should do here - just thinking aloud and throwing another similar case in the pot. :) Annie 15:26, 28 November 2018 (EST)
Typically, "rewrites" and "major changes" get their own titles while "revisions" and "minor changes" are documented in Notes. Unfortunately, determining the scope of the changes can be challenging. In this case my first reaction was "The Subterranean Press edition was only 89 pages while the edition is 196 pages, so surely it merits a separate title record." However, has been known to make novellas (<40K words) look like novels, so their page count doesn't necessarily tell us much. Ahasuerus 16:46, 28 November 2018 (EST)
As moderator, I 'voted' for keeping the title for both incarnations: the question for me was if there's a whole different story told, or if it's another title type (novel). It seemed both were not the case. So, the difference we know of should be covered in the title's note. Stonecreek 04:18, 29 November 2018 (EST)

Tasha Suri

Currently Natasha Suri is the canonical name with Tasha Suri as an alternate, but I think it should be the other way around. "Tasha" is on the cover of a novel which makes it more prominent than the other which is just used for one short story; plus all her web presence is using the name on the novel. --Vasha (cazadora de tildes) 13:57, 29 November 2018 (EST)

Okay when there's a second novel (or of another title type) with her name on the cover. Stonecreek 14:03, 29 November 2018 (EST)
Sorry, that makes no sense. You can't argue that the "best-known" name should be canonical and then not use "Tasha" which is what this author is called in 98 out of 100 references on the web, plus the novel which is a much better-known publication than the story. --Vasha (cazadora de tildes) 14:09, 29 November 2018 (EST)
When dealing with authors who have used multiple names, I usually give more "weight" to novels than to stories. OTOH, it can get tricky if a story is much better known than a novel. For example, Harry Stephen Keeler is probably best remembered for his story "John Jones' Dollar" even though a number of his once popular novels also contained speculative elements. To make things even more complicated, Keeler has experienced something of a revival over the last 20 years. With many of his novels now in print, it's possible that they have once again become as well known as "John Jones' Dollar". Luckily, he only used one name, so it's not an issue for us.
In this case I would use the "novel name" and keep an eye on the author. Ahasuerus 15:01, 29 November 2018 (EST)
OK, I will swap the names, then. --Vasha (cazadora de tildes) 10:28, 30 November 2018 (EST)

Searching books in a specific language

Does anyone have a trick on how to find all the books in a specific language (or all books filtered based on an author or any other element)? Not the titles but the publications - especially in cases where the filter is shared between languages or not always there for that language? I know that I can get to that through searching all titles in that language and grabbing all book under each title (and I know how to do that through the DB) but we do not have a way via Advanced Search, right?

If that is indeed so, how about adding that as an option (where a pub is in a language when its reference title is in that language OR when there is a title inside in that language - whatever makes more sense (dual language books are the ones that will be different based on what we decide; for the rest the results will be the same. Annie 18:15, 29 November 2018 (EST)

Re: "all books filtered based on an author or any other element", the Advanced Publication Search lets you specify the pub author's name, date/place of birth etc. For example, this search gives you a list of books by Павел Вежинов. Ahasuerus 09:53, 30 November 2018 (EST)
Yes but if the name is the same in more than one language, you get too many results - I am looking for the language being an available filter. With some languages there are filters that may help (if I makes sure that all Bulgarian books have prices even when they are just "Leva" or something, I can use that as a filter. But not all languages have single currencies or anything else that will make them unique. Annie 10:26, 30 November 2018 (EST)
"Books [i.e. publications] in a specific language" would be tricky because the search logic would have to find the "reference title" for each publication and then look up its language. Reference titles are not straightforward: magazines and fanzines use "EDITOR" while other publication types have matching title types. A couple of existing cleanup reports check pubs against their reference titles, but the queries are complex and they take a long time to run. I am not sure it would be feasible to add this functionality to the Advanced Publication Search. Ahasuerus 09:53, 30 November 2018 (EST)
How about "any title in the language" inside of the publication? Or any non-art title? I know that the DB is not set for that but... that's a pretty common question. Annie 10:26, 30 November 2018 (EST)
I have created FR 1229 to document the desired functionality, but I expect that it will require a fair amount of tweaking and research. Ahasuerus 13:04, 30 November 2018 (EST)
Thanks! I will look some more to see what else I can figure out as a possible way to filter in the meantime. Annie 14:34, 30 November 2018 (EST)
Maybe this could be a nightly report (or weekly, if nightly would be too much) that's created, in order to preserve server resources. ···日本穣 · 投稿 · Talk to Nihonjoe 14:43, 30 November 2018 (EST)
A report that lists all the books in all languages won't be very useful though and will frankly be an overkill - I am not looking for numbers but for data (which can be filtered)... Annie 14:48, 30 November 2018 (EST)
I meant reports for each language (other than English). If the big ones were spread out across the days of the week so each one was only run once a week, the small ones could be fit in wherever. This way, the information is available, and it doesn't use inordinate amounts of resources whenever someone tries to find them. They could be listed on a separate page like the cleanup reports. ···日本穣 · 投稿 · Talk to Nihonjoe 17:34, 30 November 2018 (EST)
Even for one language - that list won't be much better than what I can get going via the titles search for example with a few separate searches (or directly from the DB) - if you cannot filter it, it is just a list that does not help much but takes a long time to generate (and I really do not want to add another heavy report/computation at 1 am - we are doing much better now but the server is still very sluggish while the jobs run). I know where you are going with you but... it won't really do what I would expect it to. I know the limitation of our DB, I know it won't be trivial - just had to ask in case I was missing an obvious way. Annie 18:43, 30 November 2018 (EST)

Lemuel Gulliver and his famous Travels

Is there a principle by which we sometimes parse a title page so that "by Lemuel Gulliver", for instance, is part of the title of a work rather than its author credit?

For the first edition of Gulliver's Travels, and some others, we have T1719519

Title: Travels Into Several Remote Nations of the World in Four Parts by Lemuel Gulliver
Author: Jonathan Swift

Glasgow University Library "Book of the Month" January 2006 [1], which we link from the title record, displays the original title page of volume one, which shows (quote including horizontal lines):

Travels into several Remote Nations of the World.

In Four Parts.

By Lemuel Gulliver, First a Surgeon, and then a Captain of several Ships.

Vol. I.

At the moment we have only one author by the name "Lemuel Gulliver", credited with only two works: by Lemuel Gulliver. One is the spurious volume three, a 1727 sequel by unknown. The other is an 1812 variant title of Swift's work, with one 1812 publication only. Its internal title page (viewed at HathiTrust) displays "In Four Parts" below the credit to Lemuel Gulliver, First a Surgeon, etc.

P.S. There "into" should be "Into", or vice versa for some the first edition variant titles.

--Pwendt|talk 18:37, 29 November 2018 (EST)

Well, it should depend on naming Swift as the author also on the title page (which does the Glasgow University Library, for example). Stonecreek 00:10, 30 November 2018 (EST)
Am I misreading the title page cited? Neither the link to the Glasgow University image of the title page nor any of our title page images of 1719519 list Swift. Bleiler's Science Fiction: The Early Years describes the 1726 edition as "published anonymously". Bleiler78 lists it as published as by Lemuel Gulliver. Clearly that title record should either be uncredited with "by Lemuel Gulliver" in the title or the name should be removed from the title and these should be under the Lemuel Gulliver alternate name. If I were entering these from scratch I would take the latter approach. --Ron ~ RtraceTalk 21:01, 30 November 2018 (EST)
I'm with Ron here: consider what you would do if you had no foreknowledge. Then looking at the title page Gulliver is the author, and "by Lemuel Gulliver" not part of the title.
Additionally, Gulliver being an alernate name to unknown must be removed and changed into alternate of Swift. MagicUnk 03:20, 1 December 2018 (EST)
The two parent names for Lemuel Gulliver is correct. 1048233 is not by Swift and the actual author is not know. This situation sometimes occurs with house pseudonyms (e.g. Maxwell Grant). --Ron ~ RtraceTalk 08:40, 1 December 2018 (EST)
I'm going to go ahead and change the early editions that only mention "Lemuel Gulliver" to be by that alternate name. If anyone disagrees, we can move them to something else. I would like to ask for opinions on 2088244 I'm inclined to change that one as well. It appears to be one of a four volume set of Swift's works. However, Swift appears on the title page of the first volume as "J. S, D.D, D.S.P.D.". For the Gulliver volume, again "Lemuel Gulliver" is the only author listed. I'm inclined to change this one as well. Again, if folks object, we can change it to something else. --Ron ~ RtraceTalk 20:15, 13 December 2018 (EST)

Linking to the Library of Congress -- Help

As Annie pointed out the other day, Help:How to create a link to a US Library of Congress (Loc) record is out of date. We now use External IDs and a Note template to link to Library of Congress records by LCCN. Is there anything on that page that we can salvage? If not, I will zap it next week. Ahasuerus 17:14, 1 December 2018 (EST)

Wouldn't have created it these days, but since we already have it, I updated it to match current practice. There are a couple of cases that it doesn't hurt to explain for new users. I believe I captured current practice correctly, but people should review. I was going to include more specifics on the ebook example (like the actual LoC catalog field name), but the LoC catalog is down now. I will go back and do that at some point. -- JLaTondre (talk) 09:54, 2 December 2018 (EST)

Publication tags in advanced search

See this discussion for a fuller explanation of the matter. The short version is that advanced search allows you to search for "Tag" in publications and "Title Tag" in titles; however, as Ahasuerus explains, publication tags are not publicly visible anymore after software revisions. Proposal: remove "Tag" from the publication advanced search and rename "Title Tag" to "Tag" in the tile advanced search (which would match the sidebar search, where "Tags" searches titles). Question: does anyone here actually search for publication tags, or have other objections to the proposal? --Vasha (cazadora de tildes) 20:02, 2 December 2018 (EST)

FR 1231 has been created. Ahasuerus 16:13, 9 December 2018 (EST)
Done. Ahasuerus 18:50, 9 December 2018 (EST)
OK, great. --Vasha (cazadora de tildes) 20:31, 9 December 2018 (EST)

External IDs Data Entry

A frequent data entry error that I find myself making is when adding an External ID (usually OCLC/Worldcat or LCCN), I forget to change the type which effectively enters the ID as an ASIN. I correct these when I notice them and have hopefully caught them all. I was thinking that it may improve data quality to have a blank ID type as the default (as we do with the length pull down). Additionally, a client side edit could ensure that a value was selected before sending the edit to the server (like we ensure an author is entered). The only downside I can think of is that if someone enters a large number of ASINs, it's an extra step. Clearly, this wouldn't be urgent or a high priority. Do others feel such changes would be helpful? --Ron ~ RtraceTalk 18:17, 5 December 2018 (EST)

I’d support making the default an empty string thus forcing a selection. I tend to patrol the ASIN list for anything that does not start with B monthly. There are legitimate cases but most of those need moving elsewhere. Annie 18:23, 5 December 2018 (EST)
There was previously a proposal to add the option to add a Preferences setting for which external ID is at the top by default. I like that better than the blank idea but the blank is better than what we have now. --Vasha (cazadora de tildes) 18:29, 5 December 2018 (EST)
Another default will just move the issue - at least with a default in ASIN, we easily find the ones that are forgotten. You move that default to one of the number only IDs (OCLC, GR and so on), it gets exponentially harder. So the more we can do to minimize mistakes, the better... I know that there is the case with people using only one ID type but still... Annie 13:42, 6 December 2018 (EST)
From a purely technical perspective it would be easy to do what Ron proposes. Ahasuerus 15:03, 6 December 2018 (EST)
Why not make a combination of both proposals? Allow default setting per user, including blank. MagicUnk 15:31, 6 December 2018 (EST)
Different levels of effort I would think -- the adding of the blank is easy enough (add a new element, make sure it is not accepted during submissions on add/edit/clone pub); adding a new default will mean adding new element on the defaults page, changing the three pub pages to account for it and still have the other changes for the empty value. And then there are the priorities - do we really want that more than some other FRs that had been standing and waiting for years? Annie 13:47, 7 December 2018 (EST)
Right, we have two separate things here. The default blank can be implemented if no one objects (I don't); the option to override it if you're entering lots of IDs of the same type is a low priority idea to keep in mind. --15:40, 7 December 2018 (EST)
We already have an FR (FR 1163) to "Create a new User Preference for the default External ID type", so I have created a new one, FR 1230, for this issue. Ahasuerus 13:24, 9 December 2018 (EST)

External IDs Data Entry - First Change Made

FR 1230 has been implemented. Depending on your browser, you may need to do a full page reload (Control-F5 under most browsers) for the new functionality to take effect.

Once we determine that everything is working as intended, we can discuss whether:

  • we still want to implement FR 1163 (which shouldn't be as labor-intensive as I originally thought), or
  • whether the possible unintended side effects as described by Annie above would outweigh its benefits.

Ahasuerus 17:36, 9 December 2018 (EST)

I was just coming to say that this was quick - thanks for the change. EditPub is working as expected. :) Annie 17:39, 9 December 2018 (EST)
Wanted to say the same thing, but Annie beat me to it. Thanks. --Ron ~ RtraceTalk 17:51, 9 December 2018 (EST)
Sure thing. Actually, the change took a few days to code and test. In part it was due to the fact that I used this FR as a test case to get the kinks out of the development process on the new server. I also had to rewrite the way external IDs are validated on the server side because the original design was suboptimal. (Fixer tells me that it was "beyond suboptimal", but I think he is just being cranky because I haven't been able to spend much time with him lately.) Ahasuerus 17:56, 9 December 2018 (EST)
I just happened to be in the middle of yet another batch of OCLC identifiers that needed moving and the default changed on me. Thus finding out about it so quickly. And Fixer should stop being cranky - he just had a vacation while his house was getting repainted. Maybe he was just lonely...
Any chance we can add a JS based validation on the front end (in addition to the one we have on the backend) - if it goes down to the yellow warning and you have multiple IDs, all but the first are lost when you go back to reedit (at least in Chrome). Which may get annoying.  :) Annie 18:24, 9 December 2018 (EST)
The browser is supposed to display a pop-up message when an External ID value is entered for a blank External ID type. Did you get that yellow error message before you had a chance to do a full reload (Control-F5)?
P.S. The main reason why I use Firefox for ISFDB editing is that it does a much better job of preserving entered data when I need to go back a page or two. Ahasuerus 18:58, 9 December 2018 (EST)
Yeah, too many open windows - apparently I never reloaded the one - thought I did. Sorry about that. Tried again - works as expected.
PS: I use FF on my Windows laptop and vastly prefer it to Chrome; the Chromebook has Chrome as a native browser though and it performs a lot better than FF (that essentially runs as an app on the Chromebook). But even FF loses the multiple identifiers (at last the last time I had to back out from a multiple identifier edit). Annie 19:05, 9 December 2018 (EST)

(unindent) I'm in favour of having FR 1163 implemented. I believe it would not sit in the way of anyone that doesn't want a default. And those editors that want a personalized default are assumed to know what they are doing :) MagicUnk 16:42, 11 December 2018 (EST)

A "Redo" Button

Just wondering - has anyone ever requested a "Give me a redo" button on the edit confirmation page - something that would cancel the just-submitted edit and give you an edit screen with everything you just submitted? ../Doug H 08:18, 10 December 2018 (EST)

Yes, indeed -- see FR 21, "Ability to 'Edit' Proposed submission", requested back in 2009. Nothing has been done so far because it would be labor-intensive to implement. Ahasuerus 10:41, 10 December 2018 (EST)
You may already know this, but as a workaround (and using Chrome in my case), I just press the browser back button, do the necessary changes, (re-)submit, and then cancel the previous edit. Do be aware of one catch; multiple author, external ID,... records are not remembered beyond the first, so you'll have to re-add these. Works like a charm otherwise... MagicUnk 14:52, 10 December 2018 (EST)
Another issue with the "back" option, at least in some browsers, is that you may not retain any additional content items you added past the first nine, and if you're editing an existing publication, you may not retain new content items you added to the ones already there. In short, any part of the form that was added with an "Add Author/Title/External ID/etc." button will not be retained. --Vasha (cazadora de tildes) 15:07, 10 December 2018 (EST)
Or multiple transliterations if I remember correctly (basically the plus signs get a bit wonky using the back button. I tend to compare how much repair work is needed compared to how much time it will take to recreate from the wrong record. Annie 15:13, 10 December 2018 (EST)

(unindent) Yup, run into most of those, which is why I asked. So here's a slightly different take - could the Submit button be allowed to open in a new window/tab? ../Doug H 16:38, 10 December 2018 (EST)

That would get messy. It'd be even easier than it is now to submit multiple times (either identical or varying submissions) if you had several tabs open including an open form that you couldn't tell if you'd submitted yet or not. --Vasha (cazadora de tildes) 16:48, 10 December 2018 (EST)

(unindent) Here's a suggestion: How about putting a "cancel this submission" link on the page reviewing the submission. That way, if the editor needs to hit the back button and fix something, or if Doug's suggestion to open the review page in a separate tab is accepted, the editor can easily cancel the erroneous submission before doing the edit, which will make double submissions much less likely. --Vasha (cazadora de tildes) 20:49, 12 December 2018 (EST)

External Identifiers help updates

We really need to update this one - we had added a lot more of these so the list is a bit obsolete. As it is a live help page, I am reluctant to edit on my own - although if there are no objections, I can do some editing tonight. Annie 13:32, 10 December 2018 (EST)

Go for it! :) Ahasuerus 18:26, 10 December 2018 (EST)
Updated. Any updates/recommendations and so on are welcome. I added some notes where finding the ID can be tricky (or confusing) - hopefully that will reduce the number of weird IDs showing all over the place). Annie 20:18, 10 December 2018 (EST)

Interzone: Digest to Pulp

I noticed that the size of recent Interzone issues is 17 cm x 24 cm, which is pulp rather than digest. They should all be changed from 2012 onward. But before I submit these changes I want to make sure I'm not missing anything... MagicUnk 06:31, 11 December 2018 (EST)

'Pulp' certainly would be misleading (because of the connotations of a certain period of time and paper quality), though they are not digests either. The issues I have are tps and as this is nowadays an accomplished format for magazines, I'll begin to switch them to that. Would you like to do the same to your verified ones? Stonecreek 10:42, 11 December 2018 (EST)
Should we really change them to tp? Size of tps are ill-defined and is a bit of a catch-all if you ask me, whereas pulp is exactly the dimensions we're talking about. I understand pulp is associated with the cheap-paper periodicals, but should'nt we rather expand/clarify the definion instead? Or alternatively, add a new format - equivalent to pulp but with a different name? MagicUnk 12:34, 11 December 2018 (EST)
Well, tps are really well-defined and it seems the standard format for modern (post 2000) print periodicals that don't fit into other magazine standards, and are very similar or identical in format to Interzone. See the following examples: Clarkesworld, Apex, or On Spec. Stonecreek 13:19, 11 December 2018 (EST)
Christian, can you elaborate on why you state that tp's are well-defined? When I'm reading the Format field info, it states that its size can be whatever, as long as minimum dimensions are 19 cm tall or 11 cm wide. Not very precise if you ask me... MagicUnk 16:36, 11 December 2018 (EST)
Template:PublicationFields:Format says:
  • Print magazines
    • pulp - the common pulp size: 6.5" × 9.5" (16.5 cm x 24.1 cm). For ISFDB purposes this may also be used as a designation for the quality of the paper. There are some untrimmed pulps that are as large as 8" × 11.75 (20.3 cm x 29.8 cm)"
    • tp - trade paperback magazines, usually perfect-bound, i.e. periodical publications (often POD) which otherwise would qualify as trade paperbacks (see "tp" in the Print books section)
The parts that mention paper quality are a big vague: "this may also be used as a designation for the quality of the paper" and "usually perfect-bound", but the language seems to suggest that "tp" would be the preferred way of entering modern magazines. I can't think of a better term that we could use, but if there are suitable candidates, we could start a new Rules and Standard discussion. It would be easy to add a new value to the list of supported formats. Ahasuerus 14:36, 11 December 2018 (EST)
mm for modern mags, or modern for short? MagicUnk 16:39, 11 December 2018 (EST)
OK, changed. Stonecreek 06:11, 13 December 2018 (EST)

Nonstandard capitalization in a poem title

I'm having a slight disagreement with Christian. The title of this poem is printed "YUAN: the Origin of a Family Name" in the issue of Mithila Review that I catalogued. Christian thinks the capitalization should be standardized to "Yuan: The Origin of a Family Name" in the database. But I disagree because of the part of the ISFDB policy that states "Titles should have case regularized according to language-specific rules unless there is some specific evidence that the author intended certain letters to be in a specific case." I think it is clear that the author intends YUAN to be all caps because it appears that way not just in Mithila Review, but in its other publication in Manifest West: Transitions and Transformations.

On the other hand, Mithila Review prints the word "the" after the colon lowercase, but Manifest West prints it uppercase. I have no problem with standardizing that word to the usual uppercase. So, the result should be "YUAN: The Origin of a Family Name." What do you think? --Vasha (cazadora de tildes) 14:11, 11 December 2018 (EST)

Looking at Piers Anthony, you get "DoOon Mode" and "OX", which make sense in the context of the story, but you also get "SOS the Rope" followed by "Var the Stick" and "Neq the Sword" and the inconsistency looks weird. Is the capitalization consistent through the story/article? ../Doug H 22:27, 11 December 2018 (EST)
Read the poem here: it goes through the name letter by letter which makes Y-U-A-N a sort of acronym! --Vasha (cazadora de tildes) 23:19, 11 December 2018 (EST)
Hi, Vasha! If you'd stated something like that in the notes it would have been obvious why the capitalization was chosen. I'll change the title and add a note. Stonecreek 23:47, 11 December 2018 (EST)
OK, thanks. The thing is, though, a lot of poems use weird capitalization without such an obvious reason for it. You kind of just have to accept that what's in the publication is what is intended. I tend to standardize the capitalization of story titles but not poem titles.
Does anyone want to start a R&S debate over what constitutes "some specific evidence that the author intended certain letters to be in a specific case"? --Vasha (cazadora de tildes) 00:08, 12 December 2018 (EST)
Most moderators should be accustomed with all-small-letters for poems, but for cases like this one (or others that may deviate in other ways) it really seems better to add an explanatory note to the title: the next editor / moderator might think in the same way as me and change the title back again. Stonecreek 04:38, 12 December 2018 (EST)
Notes are always good :-) Ahasuerus 13:18, 12 December 2018 (EST)

New cleanup reports - External IDs

Seven new cleanup reports have been deployed as per FR 1232, which see for details. The data -- a couple hundred publications -- will become available tomorrow morning. Based on preliminary testing results, one of the reports may need the ability to "ignore" records added, but let's wait until everything else has been corrected.

I was going to start working on other recently requested FRs, but it looks like I need to take a break since I am not feeling well. Hopefully a short one. (Fixer says that he has a custom anti-virus program ready for me, so I am sure I'll be fine. If you can't trust Fixer, who can you trust, right?) Ahasuerus 23:21, 11 December 2018 (EST)

Some fun new reports turned out these to be. Some people might need to see an optometrician, if you'd ask me.--Dirk P Broer 11:38, 12 December 2018 (EST)
Well, we have a tad over 532,000 pubs and 220,000 external identifiers on file, so 200 problem pubs is around 0.1%. Even Fixer agrees that it's not too bad for carbon-based lifeforms :-) Ahasuerus 13:34, 12 December 2018 (EST)
0.1% is indeed very acceptable. Some of the titles are in the report by error too, e.g. Der Zeitagent.--Dirk P Broer 17:04, 12 December 2018 (EST)
Der Zeitagent's OCLC ID was displayed as "74965890", but the actual stored value was "74965890</". The angle bracket and the slash were not displayed because browsers interpreted them as HTML markup.
The 4 tagged Japanese pubs may require more digging -- I will ping Nihonjoe. Ahasuerus 17:24, 12 December 2018 (EST)
Fixed! Well, mostly. See my talk page. ···日本穣 · 投稿 · Talk to Nihonjoe 20:20, 12 December 2018 (EST)
Thanks! The NDL-specific logic has been adjusted to allow leading "b"s. Ahasuerus 23:33, 12 December 2018 (EST)
The LCCNs also seems to be able to have a few letters as a lead (a, ac, unk, tmp, ltf and war are the ones I saw today but there aren't too many of them so let's leave the LCCN report as is - we can just ignore them for now when they show up. I will keep an eye for some of them getting too plentiful. Annie 00:12, 13 December 2018 (EST)

ISFDB Statistics page

The ISFDB Statistics page has been updated to display External ID information. The data will become available tomorrow morning. Ahasuerus 20:18, 12 December 2018 (EST)

Google Search - Take One

As per FR 1226, Advanced Search has been enhanced. The new section, cleverly called "Search ISFDB Using Google", lets you select one of the currently supported record types:

  • name (default)
  • title
  • series
  • publication
  • publication series
  • publisher
  • award category

and then choose between "contains approximate word" (the default) and "contains exact word". I have tweaked the Google query syntax to approximate what I think users will expect to get. However, Google's search algorithms are somewhat mysterious, so the results are occasionally a bit odd, especially if you move to pages 2, 3, etc. Still, a search on "ПАВЕЛ ВЕЖИНОВ" (Annie's example from the original discussion) finds "Павел Вежинов" and, if you choose "approximate", also finds "Pavel Vejinov", which is more than we can currently do.

Please let me know what you think of the current implementation. If we have developers familiar with the way Google Search works, I'd appreciate their feedback.

If and when we determine that this is useful, we can update the regular search logic to display a "Google Search" button if a search fails to find anything. Ahasuerus 23:36, 13 December 2018 (EST)

I am not sure if it is just my security settings or a generic problem with Chrome but the forward to Google does not work (Ctrl + F5 did not clear it either). A right click to open in a new tab works - but not a straight click. Will check with FF and another Chrome tomorrow morning. Other from that - nice! Annie 00:25, 14 December 2018 (EST)
Curious. Here is what Chrome says:
We do have this CSP directive in place as part of our security framework. However, I don't think it should apply in this case because the code uses a server-side redirect rather than a direct submission. Firefox apparently agrees and processes the redirect seamlessly. I'll do more digging tomorrow morning -- thanks for the heads-up! Ahasuerus 00:42, 14 December 2018 (EST)
It turns out that this is a known issue. Firefox interprets one of the Web security standards one way while Chrome and Safari interpret it another way. I am currently in the process of trying to come up with a workaround that will work for all browsers. Ahasuerus 12:33, 14 December 2018 (EST)
And now I remember why I hate doing web development. Thanks for looking into this :) Annie 12:42, 14 December 2018 (EST)
The internet (and computers in general) have been growing so fast over the last few decades that half the time I am surprised that things work at all. On occasion I feel like Buster Keaton in The Electric House... Ahasuerus 13:26, 14 December 2018 (EST)
The software has been adjusted to work with Chrome and Safari. Ahasuerus 14:25, 14 December 2018 (EST)
Thanks! Appears to be working (on Chrome on Windows; will check the Chrome on the Chromebook tonight).
PS: Yeah and things change faster and faster these days. It is almost frightening when you are the one building what people need to use... Annie 14:50, 14 December 2018 (EST)

(Unindent) It works on Microsft Edge and the Samsung browser too. --Vasha (cazadora de tildes) 17:54, 14 December 2018 (EST)

Thanks for checking! Ahasuerus 20:10, 14 December 2018 (EST)

Cleanup reports - consolidation

We have 245 nightly cleanup reports. It's a good thing, of course, but the software was not originally designed to have that many reports and things have become unwieldy.

I am currently in the process of consolidating and streamlining the code. The first patch was installed a few minutes ago and will affect the nightly run in 2 hours. I expect more patches to follow in the next day or two. There should be no user-experienced changes, but if you notice anything strange, please report your findings here. Ahasuerus 23:04, 14 December 2018 (EST)

If you accept ideas for consolidation, all those language specific transliteration reports can be merged together. Same with suspected author languages and so on. They were huge when we started the transliterations and the title languages but these days they are either empty or very small... Annie 01:47, 15 December 2018 (EST)
The number of records that we were originally dealing with was one of the reasons why multiple language-specific "transliteration" reports were created. However, there was another reason: most of us are not able to add transliterated values across the language spectrum. I can do it for European languages, but Japanese is beyond me. On the other hand, Nihonjoe can handle Japanese, but not Bulgarian, Serbian, Russian, etc. Thus even though the number of records found by these nightly reports is low these days, segregating them by language still seems useful. If I look at the list and see that only Asian languages are outstanding, I don't need to drill down since I can't help anyway. Ahasuerus 13:44, 15 December 2018 (EST)
Except that the catch-all is not just Asian languages - Croatian ends up there for example. Or Bosnian. Or any number of other languages we do not see often. So I end up always checking it anyway - and seeing that it is an alphabet I do not know, I just skip these. :) But if you think they are useful as they are, no worries. I was just thinking aloud. Annie
Would it help to consolidate all of our "transliterated" reports based on whether the language's primary alphabet/script is:
  • Latin-based
  • Cyrillic-based
  • Other
 ? It wouldn't be perfect because of multi-alphabet languages like Azerbaijani, Serbian, etc, but it may be an improvement. Ahasuerus 15:25, 15 December 2018 (EST)
The way I work on these reports - yes. Make a decision for the multi-alphabet ones (stick them with the less-common one would be my vote- if you read Cyrillic for example, you can deal with the Latin forms of the same alphabet) and we are all set. Annie 15:34, 15 December 2018 (EST)

Some absent Theodore Sturgeon reviews

I've had a snail-mail enquiry from American fan John Hertz (he's never had email, ever, and never will) who has noticed that we include book reviews that Theodore Sturgeon did for Galaxy 1972-1975, Venture 1957-1958, but not National Review, The New York Times or, to be complete, Hustler (under Paul Krassner, ed. 1979-1983).

Unless I've missed it somewhere, I see nothing under the Rules of Acquisition the specifically prevents us from including reviews by a prominent genre author such as Sturgeon that appeared in non-genre periodicals – can anyone point to examples of periodicals where we do include such reviews? And if not, is there a reason for this exclusion or is it just lack of the necessary bibliographic data? A cursory look at The Kenneth Spencer Research Library shows such reviews are listed there, and maybe John Hertz knows of other resources. John's enquiry about our missing bibliographic detail shows this is obviously important to some people who would expect to find such information at our site. Input please! Thanks. PeteYoung 07:59, 15 December 2018 (EST)

Help:Entering non-genre periodicals#Genre special issues has "even though we do not normally catalog non-fiction from non-genre magazines" which isn't definitive. It's been discussed a couple of times with no real conclusion. You will occasionally see non-fiction included when there is fiction, but non-fiction from a non-genre magazine without accompanying fiction is pretty much not done (though it wouldn't surprise me if some has made its way into the database). -- JLaTondre (talk) 08:55, 15 December 2018 (EST)
I'd vote for an inclusion of reviews that take on genre titles and such done by authors above-the threshold, regardless of where they were published: both cases are useful for completing our core business (genre authors, their works and how they are viewed). Stonecreek 07:41, 16 December 2018 (EST)
The rules of acquisition declare "works about speculative fiction" as "in" (Included #3). So I believe a review of a title eligible for inclusion is likewise eligible for inclusion, regardless of where it was published. But the rules of acquisition also limit inclusion of non-genre non-fiction by authors above the threshhold to that published "as a standalone book" (Included #4). So I believe a Sturgeon review of a non-genre title in a non-genre periodical is explicitly excluded. I don't have a strong feeling about it, but that treatment seems appropriate to me. --MartyD 10:02, 16 December 2018 (EST)
I've gotten the impression that that "works about speculative fiction" inclusion is also pretty much limited to stand-alone works. Not that there's a set-in-stone policy about it, just that several discussions over the past three years have shown the current group of editors to be unenthusiastic about cataloguing nonfiction and unwilling to interpret rules in ways that would allow much of it to be entered. Somebody (I unfortunately don't recall who) said that they thought nonfiction should only be entered in order to show what the complete contents of genre magazines are. That's an extreme position, but no one really disagreed with it in that discussion. For my part, though, I don't think it would do any harm to enter some non-genre periodicals if they have interesting contents. An exception here or there, in order to have the complete genre writings of significant authors included, not just their complete genre fiction. --Vasha (cazadora de tildes) 10:35, 16 December 2018 (EST)

(unindent) One of the problems that we have run into when discussing what types of non-fiction to include is the sheer number of different ways to categorize them. Off the top of my head:

  • Length: books vs. short works. Short works are further subdivided into:
    • Essays vs. reviews vs. interviews
  • Type of publication where the non-fiction work appeared: genre periodicals vs. non-genre periodicals vs. genre books vs. non-genre books
  • Type of non-fiction work: works about written SF vs. works about non-written SF (comics, films, TV, etc) vs. works about non-genre issues vs. works that are "sort of" related to SF (space exploration, history of myths, etc)

This segmentation makes it difficult to ensure that everyone is on the same page when discussing proposals that cover only certain "cells" of this multidimensional matrix. Perhaps a graphical (tabular?) representation may help clarify what our policy currently says and where we may want to go from here. Ahasuerus 16:44, 16 December 2018 (EST)

In memoriam -- magazines

It's been a bad, bad year in genre magazine publishing. Numerous long-lived, respected, and beloved magazines announced their closure: Space & Time after 52 years of operation, saying that the economics of the distribution system have changed so that it is impossible for them to stay in print; Mythic Delirium after 20 years, Shimmer after 14 years, SQ Mag after 8 years... Young adult spec fic lost a pro-paying market with the end of Cicada magazine. Other magazines struggle to stay in production: Cemetery Dance did not produce an issue this year, and Lackington's only delivered two issues instead of its customary four. The Strange Horizons fundraiser was not quite as successful as they'd hoped. Economic woes were everywhere. Although new magazines were launched, hope was greater than reality: the revived Omni, greeted with enthusiasm, lasted one issue. I very much enjoyed the first two issues of Eyedolon magazine, but since then their production of new content has been sparse.

Genre short fiction will still be published--it must be, since people will not stop writing and reading it. But the chances of writers being paid for their work continue to grow worse and worse. Magazine publishing as we know it is changing, and magazines are fewer. I don't know what form short fiction publishing will take in the future. I send respectful thanks to the magazines that have ended their run this year, and hopeful wishes to everyone who intends to keep publishing. --Vasha (cazadora de tildes) 15:43, 15 December 2018 (EST)

Unfortunately, I know very little about the short fiction market these days, so I can't venture any guesses as to what's going on. It would be great if we could mine our data for patterns, but all I can think of at the moment is "Titles by Year of First Publication", which has separate graphs for novels and short fiction, and "Publications by Year", which has a graph for magazines. They are not terribly illuminating, but they are better than nothing.
Since I am still recovering and can't do heavy duty development work, I have added a POEM graph to "Titles by Year of First Publication". The data will become available tomorrow morning. Perhaps we should add a graph showing the breakdown of magazine formats (pulp, digest, webzine, etc) to "Percent of Publications by Format by Year"? The "Space & Time" editor mentioned that:
  • As for going online only, there’s already a glut of high-quality genre publications vying for eyeballs — it’s simply not worth the effort required to assemble issues for so small a readership.
It may be useful to try to quantify this "glut", as she called it. Ahasuerus 21:32, 15 December 2018 (EST)
I realize that my ill-chosen headline makes it sound like I intended to say "The genre magazine is dead!" I did not mean that, I just meant to post an in memoriam and thanks to certain specific magazines that ended their run this last year. That led to reflecting that the general situation is in transition to who-knows-what. --Vasha (cazadora de tildes) 04:12, 16 December 2018 (EST)
In my experience, when a well-read genre fan thinks that the field has changed, there is a very good chance that he or she is right. However, determining the nature of the change may not be easy. Granted, in certain cases, e.g. during the "death of [US] science fiction" period in the late 1950s and early 1960s, it was fairly straightforward. All you had to do in 1962 was plot the annual number of SF magazines and magazine issues since 1953 and the picture was perfectly clear. Hence Alva Rogers' A Requiem for Astounding in 1964, although he also argued that, in addition to a quantitative decline, science fiction had lost its "sense of wonder", a much more difficult proposition to prove or disprove.
However, in most cases things are not that simple. Sometimes the relative popularity of sub-genres changes. For example, the recent flood of urban fantasy and paranormal romance works has done little for cyberpunk fans. Other times the underlying change is technological in nature: readers who are less willing to use e-books may have been negatively affected by the changes over the last 10+ years. Then there are generational and esthetic changes as was the case during the "New Wave" controversy of the late 1960s. And so on and so forth.
It would be great if we could use our data to quantify these changes. For example, in addition to the ideas that I mentioned earlier, perhaps we could update Titles by Author Age to show how the "age at the time of first publication" has changed over the years. Or we could show how the average magazine editor age has changed over time. We could also create a graph showing changes in the relative popularity of various title tags. More ideas are always welcome! Ahasuerus 15:29, 16 December 2018 (EST)


As per FR 1213, "Let all title types appear as series", the software has been modified to fully support REVIEW series. INTERVIEW, COVERART and INTERIORART series are still outstanding. Ahasuerus 19:22, 16 December 2018 (EST)

Support for INTERVIEWs has been added. You can now put them in a series and they will appear correctly -- see William Sullivan's Summary page for an example. Ahasuerus 19:59, 16 December 2018 (EST)
Support for COVERART and INTERIORART series has been added.
In most cases everything looks OK, e.g. see Alfons Figueras's Summary page. However, mixing COVERART and INTERIORART titles in the same series can lead to unexpected results. For example, if you pull up Virgil Finlay's Summary page and scroll down to the "Cover Art Series" section, you will note that the "Virgil Finlay's Poetry Series" series contains 22 INTERIORART titles and only 1 COVERART title. This is due to the fact that the Cover Art section is displayed before the Interior Art section: all INTERIORART titles that belong to a series with at least one COVERART title in it are displayed in the "Cover Art Series" section. This is the way all other title types work, so I don't think we need to change the software, but we'll want to keep it mind when adding series information to art titles. In certain cases creating two separate series may be a better way to organize our art records. Let's wait a few days and then we can discuss whether we need to create a cleanup report for "mixed art" series.
Finally, please note that I have moved the 2 art sections below "short fiction", "poems" and "essays". We are primarily a fiction database, so it makes more sense to display fiction titles before art titles. If this causes a problem, we can revisit the display order. Ahasuerus 21:04, 16 December 2018 (EST)

Interviews BY vs. Interviews WITH

I can't decide whether it makes sense to have them displayed in series on the interviewer page but not the interviewee page. It is definitely nice to have the interviewer displayed this way. Now it makes sense that we've been adding the Lightspeed and Nightmare author spotlights to series, because it looks good to have the recurrent work the interviewer did for this department displayed together on their page. In the case of author spotlights, some interviewees have been interviewed multiple times for Nightmare and Lightspeed, and it might look good to have those grouped together too; but in general, it makes rather less sense to have the interviewee displayed in series because often they've just contributed once to that series. --Vasha (cazadora de tildes) 20:53, 16 December 2018 (EST)

One thing to keep in mind is that the "Interviews WITH" section is very different from the other sections on the Summary page. It displays titles that the main author is associated with, but is not the author of. For this reason the software that displays "Interviews With" is completely different and not as robust as the rest of the software on that page. For example, it doesn't handle VTs -- see FR 1337, "Display VTs in the Interviews With This Author section of Summary pages". We can modify it, but it's a fairly big can of worms. Ahasuerus 21:12, 16 December 2018 (EST)
OK then, it's a good thing I decided I didn't want the "interviews with" displayed in series if it isn't possible anyhow! --Vasha (cazadora de tildes) 21:32, 16 December 2018 (EST)

The External IDs migration

Just in case anyone is interested, as of 5 minutes ago all external identifiers that were in the Notes fields as links had been either moved to the new fields or templated. Additionally all non-linked ones in predictable (and sometimes not so predictable patterns) had been also dealt with. All wrongly templated ones mainly from March-August 2017 (when we were still figuring out what we were doing) that should have been in the new fields were also checked and moved if needed. So if you are tired of your "Changed Primary Notifications" getting lighted up as a Christmas tree daily, that will stop happening. Until we have another cleanup project that requires that many publications edits that is. :)

If anyone finds a non-moved/templated ID, please move/template it if it makes sense (lccn that cannot be found in LOC for example stays unmoved and untemplated and so on). Or post here or on my wall so I can move it. If you find a pattern yielding more than one, I will be more than happy to work through them.

But for now, besides the 23 Japanese Audible ASINs that we are still researching, the moving of external IDs is completed. Annie 02:12, 19 December 2018 (EST)

Wow, that was a load of work. Great that you did this Herculian task, Annie! Stonecreek 02:15, 19 December 2018 (EST)
Congratulations on slaying the dragon! Don't look now, but there is another weyr right around the corner :-) Ahasuerus 08:01, 19 December 2018 (EST)
Ahasuerus, just the one? :) Christian, that one was a team effort - at different times in the last 18 months pretty much everyone chipped at these. Although a couple of weeks ago I did wonder briefly if I will ever stop finding more and more creative ways found by the editors to record these IDs in the Notes and if just giving up on patterns and opening every single publication won't be faster (nah, it would not have been - but those things just kept showing up). If anyone ever needs a proof on why we need more structured fields, this migration will probably be the example in the dictionary. :)
Onto the next project now. Annie 10:39, 19 December 2018 (EST)
Annie hunts IDs, she finds them where they lurk / Tireless editor, to you we say "Great work!" --Vasha (cazadora de tildes) 11:00, 19 December 2018 (EST)

(unindent) The cleanup report has been simplified to look for any and all occurrences of '" in the Note field. The new version of the report lets moderators "ignore" records. I expect that of the 19 records that the report will find when it runs overnight all (or almost all) will be "ignored" tomorrow morning. Ahasuerus 17:42, 19 December 2018 (EST)

Thanks for updating that one. Unless someone manages to smuggle a new one in, all 19 will be ignored as soon as the report manages to regenerate :) Annie 18:05, 19 December 2018 (EST)

New OCLC cleanup reports

Two new cleanup reports have been deployed:

  • Publications with an OCLC Verification, no ISBN and no OCLC External ID
  • Publications with an OCLC Verification, an ISBN and no OCLC External ID (first 1000)

The only difference between them is that the second one has an extra column for the ISBN. Displayed ISBNs are also linked to OCLC.

There is no way to "ignore" records at this point. We may need to revisit this issue once the bulk of the records has been processed: there are some unusual scenarios involving magazines and OCLC errors.

The data will become available tomorrow morning. I expect that the first cleanup report will have 397 records. The second report should find approximately 3,621 records, but the display is capped at 1,000 for performance reasons. We are getting ever closer... Ahasuerus 19:30, 19 December 2018 (EST)

I will make that case that if it does not have an OCLC record to connect to, it should not have been marked as verified... Verified means "there is a record describing THIS book" and I verified against it, not a book or series related to this book or containing this book (this is what templates are for)... Annie 19:40, 19 December 2018 (EST)
If all OCLC-verified publications end up with an OCLC ID, it will effectively make OCLC verifications redundant. At that point we will presumably want to consider whether we want to keep OCLC as an active verification source. Since some editors grow attached to their verifications, we may want to preserve their contributions on the Top Verifiers page, which shouldn't be hard to do. I guess we'll revisit this issue once the new cleanup reports have been processed. Ahasuerus 16:37, 20 December 2018 (EST)

(unindent) How do we look in the other direction - publications with OCLC number but without a verification? Some of those will be as easy as a click; some will need updated notes to note discrepancies, some may actually end up with us updating our records. Annie 10:22, 21 December 2018 (EST)

I guess it depends on what we decide to do with OCLC verifications. My tentative take on them is that OCLC IDs effectively supersede OCLC verifications. The additional information that secondary verifications provide -- the "N/A" capability, the name of the editor and the date of the verification -- doesn't seem to add much as long as we have OCLC IDs. If that's what we end up deciding, then we'll probably "freeze" OCLC verifications, i.e. disallow new ones and possibly stop displaying the existing ones. We won't be deleting them from the database in case we ever change our mind. They will also be displayed on our statistical reports. Ahasuerus 22:23, 21 December 2018 (EST)
That is a good plan. I also think there's likely no need to double-check the OCLC IDs that don't have verifications; although doubtless some of them are wrong, they're no more likely to be wrong than the verified ones. And although it's nice to note discrepancies between the WorldCat record and other sources of data, how high a priority is that? --Vasha (cazadora de tildes) 22:46, 21 December 2018 (EST)
Low priority for you is not the same as low priority for someone else. We are talking about editors' time here - everyone works on what they find relevant to them. So let's not make decisions for other people... And if data quality and proper notes are low priority, especially when we work from secondary sources, maybe we have a different ideas of what is important :) Annie 23:27, 21 December 2018 (EST)
Noted, my apologies. --Vasha (cazadora de tildes) 00:25, 22 December 2018 (EST)
I had found the name of the OCLC verifier useful - they are usually the source of a lot (if not all) of the information in the record and additional questions often find answers by asking them when there is no PVs or when they are inactive. So I will be reluctant to lose or stop recording this information... Annie 23:27, 21 December 2018 (EST)
Interesting. I recall occasionally using secondary verifications in a similar fashion, but I didn't realize that it was a common practice. Just goes to show how different different editors' workflows can be. I guess we'll revisit this issue once we wrap up these 2 cleanup reports.
It also raises a larger issue -- how do we make "publication history" available to editors? A while back we added "My Recently Changed Primary Verifications" to our toolset, but it's more of a notification mechanism. There was an early attempt to create a general-purpose "Edit History" system, but it failed because our submissions do not capture "before" and "after" states. There is an outstanding request to Create a history of changes to primary-verified publications by storing a snapshot of the way each verified pub looked like right before it was changed, but it's also limited to primary-verified pubs.
One possible "low-hanging fruit" that comes to mind is linking Publication records to the submissions that originally created and subsequently modified them. We can easily do it for "New Publication" submissions because we added a "New Record ID" field to the submission table a few years ago. Linking to "Edit Publication" submissions is currently impossible because submissions do not store the IDs of the publications that they modify in a structured manner. However, it should be possible to extract them from the body of each submission and create a new field. Food for thought. Ahasuerus 13:32, 22 December 2018 (EST)
I had been working on a lot of housekeeping tasks so I probably had edited a lot more publications I am not verifying than most editors had. Which is probably why I've need to discuss something with a secondary verifier (and not just OCLC - the whole board of secondary verifications). Not sure how common it is in a "normal" workflow... :)
For the publication history: That will still have the problem with tracking the editing of titles - a lot of the changes in a publication are not done from the pub page but in an underlying titles - and we still have a blind spot there. While tracking the pub changes will be useful, it will be incomplete in showing the full story of what actually did happen. And with titles jumping pubs occasionally, it can get progressively harder to track the history (although we do have timestamps so we know when something is moved in or out). But yeah, if we can see who edited, we do not need a name on the verifications... Annie 15:33, 22 December 2018 (EST)
Oh sure, a "publication edit history" limited to New/Add/Clone edits would be incomplete. Still, I suspect that it would be a significant step forward and shouldn't be too hard to implement. It would also be retroactive since we would be linking all 2006-2018 submissions to their publication records. On balance, it may be a cost-effective palliative solution. Ahasuerus 16:20, 22 December 2018 (EST)
 :) I agree, it is better than what we have now - and things get built step by step. Can we easily add import and removeTitle (both to the "Changed" list and to this? Those are always tied to the publication as well - it at least gives us one more of the actions. I know that merging and deleting may make these a bit hard to track but still... maybe even the ones that are around will be a good enough help... Annie 17:15, 22 December 2018 (EST)
Good point. FR 1237, "Enhance 'My Recently Changed Primary Verifications'", has been created. I have also created FR 1238, Create an Edit History page for publications. Ahasuerus 15:03, 26 December 2018 (EST)

Capturing Non-Linking Secondary IDs in a Structured Way

(Copied from ISFDB:Moderator_noticeboard#Capturing_IDs_in_a_Structured_Way -- see the sub-section at the bottom for my proposal.)

Original Discussion

One other advantage of having these [non-linking secondary] IDs in the database is that their presence makes it possible to check for gaps in our coverage. Since Reginald used sequential numbers (000001 through 37651) for first editions, we could easily create a cleanup report to look for gaps. Of course, it would be even easier to implement and display if we captured these IDs in a more structured way. Ahasuerus 16:49, 18 December 2018 (EST)

So are we back to "Let's have a non-linking External IDs" in their own list? And these will be extremely easy to move programmatically - they are very well (and predictably) structured in their notes - almost always alone on a line - so we can parse and dump the line...  :) Annie 18:31, 18 December 2018 (EST)
I can think of two different programmatic solutions:
  • Create a new set of fields that would be similar to the "External IDs" box but without the linking
  • Modify the logic behind External IDs to allow non-linking IDs
The second solution would be much easier to implement. I suspect that it would also be more intuitive for users and editors. Ahasuerus 22:00, 18 December 2018 (EST)
I'd vote for the second approach. It also has the built-in capability to switch non-linking to linking with a simple server edit (as opposed to some type of reclassification depending on the design). Annie 22:19, 18 December 2018 (EST)
In theory (I'm sure this isn't practicable) it'd be nice to have IDs associated with the secondary verification checkboxes. The numbers that people are defending the usefulness of are ones where the book itself was considered useful enough to add to secondary verifications. In the case of Reginald, it would be very nice to have the reference number displayed next to the verification; more complicated in the case of OCLC where there can be multiple numbers. We have many OCLC numbers without Worldcat verification checked and vice versa, and it's somewhat redundant to have both. --Vasha (cazadora de tildes) 18:33, 18 December 2018 (EST)
Interesting points, some of them in line with what I have been thinking. I will mull it over and respond tomorrow. Ahasuerus 22:44, 18 December 2018 (EST)
Most of the external IDs are defacto verifications anyway - just not against the usual American sources and we do not keep record of who added them... For a Russian book I am much more likely to trust and check FantLab than OCLC and most of the information will come from the Russian source. Same for SFBG for Bulgarian, DNB for German and so on. And most editors had treated these as verification sources - by noting differences between sources. Just saying... Annie 23:20, 18 December 2018 (EST)
I wonder how it'd look to have both external IDs and verifications in the same section. Some sources of data would be numberable, some verifiable, and some both; some numbers would be linking and others not. Would just need suitable design to be legible. --Vasha (cazadora de tildes) 23:32, 18 December 2018 (EST)
I have just deployed a couple of cleanup reports to look for discrepancies between OCLC verifications and External IDs. It's a good example of how the two types of data are related.
Having said that, the two sections currently capture somewhat different types of data. Obviously, the External ID section captures linked IDs, which is very useful. On the other hand, the Secondary Verifications section lets you choose "N/A", which the External IDs section doesn't support at this time. It also records the date of the verification and the name of the verifier, which can not be changed except by the verifier. Also, unlike External IDs, verifications can be added without moderatorial oversight. I have also noticed that some editors become attached to their verifications.
I think tighter integration between External IDs and secondary verifications is worth considering. We just need to figure out how to reconcile the differences that I outlined in the previous paragraph. Ahasuerus 19:48, 19 December 2018 (EST)
The two don't have to be "linked" in order to be displayed together; it could be more like two parallel columns --perhaps start the left column with external IDs that don't have verifications, then begin a column of verifications on the right, with matching numbers associated on the appropriate line on the left. Just a thought.
As for better data entry linking, one possibility would be to have a space to enter an associated number on the 2ndary verification form (OCLC having a "+" for multiple numbers). The numbers would be sent to a moderated submission but the verifications would just go through automatically. --Vasha (cazadora de tildes) 20:08, 19 December 2018 (EST)
I've been reading through the historical material (well, tried to), and it seems to me the current dispute could be solved by adding non-linking external ID's. Why not be pragmatic, and implement the 2nd proposal from Ahasuerus (ie Modify the logic behind External IDs to allow non-linking IDs)? It wouldn't really change anything from the current practice. After all, we're already adding oclc's and check the corresponding verification flag. I can't imagine that that would be a lot of effort (but what do I really know about coding the ISFDB, right? :)). Granted, that wouldn't all that be efficient, but hey, it would be a start and better than what we have now. As for the integration of verification and referencing, yes that could (should?) be done, but as a future enhancement as I'm sure that that would cost considerably more dev'pment effort.
Again, if this non-linking ext ID thingy can be implemented 'quickly', I believe it'd bring back tranquillity to the community (or at least has the potential to), don't you think? MagicUnk 06:27, 20 December 2018 (EST)
There is always a balance between:
  • going after the "low-hanging fruit" which can be done quickly but may have to be reworked later on, and
  • implementing a long-term solution which takes longer to implement but is more likely to be permanent
An important factor to consider is whether a short-term solution would require more work down the road once a permanent solution is put into place. For example, the way we handled non-English titles prior to 2011 required a complete revamp once language support was added.
In this case allowing non-linking External IDs for Reginald, Bleiler, etc appears to be a low-risk proposition. Even if we end up implementing a different solution at some future point, it should be easy to move structured IDs to a different field(s).
In addition, we may want to have support for non-linking External IDs for other reasons. For example, if an external database were to go off-line, our links would become dead and would need to be deactivated. We wouldn't want to delete the IDs in case the site is eventually resurrected, but there are examples of bibliographic sites getting merged (like Shelfari) or becoming frozen (like the European Library.) Conversely, it's possible that some secondary sources may become available online at some point in the future.
For these reasons I think it would be worth adding support for non-linking External IDs sooner rather than later. We currently have around 4,000 Reginald IDs in Notes. It would be better to migrate them to a separate field while the number is still manageable. I will copy this proposal to the Community Portal where more editors will have a chance to eyeball it. Ahasuerus 16:21, 20 December 2018 (EST)
Two comments:
1. The suggested cleanup report looking for gaps makes sense for the Reginald, though we wouldn't catch variant titles that have an alphabetic suffix, which the proposal seems to be aware of. For the Bleiler indexes, this makes less sense. Bleiler indexes both books (novels, chapbooks, collections and anthologies) and stories. While the stories generally give their first or first few magazine appearances, I don't think it would be appropriate to add the catalog number to the magazine. If we were to do so, there are some magazine issues that would need to hold several catalog numbers. Those numbers are more title based by our definition. Consequently, gaps in numbering from publication records would be expected. As would duplicates (for books), as sometimes several editions are listed under a single catalog number. --Ron ~ RtraceTalk 21:40, 20 December 2018 (EST)
Thanks for the clarification! Since different references have different numbering schemes, I assume that the projected cleanup reports will have to be reference-specific. Some will be limited to looking for duplicate IDs (and support the "ignore" functionality) while certain others will also look for duplicates. Ahasuerus 13:09, 22 December 2018 (EST)
2. The Bleilers that contain catalog numbers are Supernatural Fiction, The Early Years and The Gernsback Years. Neither Bleiler78 nor its precursor number their entries.
Thanks. --Ron ~ RtraceTalk 21:40, 20 December 2018 (EST)

Capturing Non-Linking Secondary IDs in a Structured Way -- Proposal

Based on the discussion above, I would like to propose that we add non-linking IDs like Reginald-1, Reginald-3 and (some?) Bleilers to the list of supported External ID Types. It would require some changes to the software, but I believe that it shouldn't be too difficult to do. Ahasuerus 16:55, 20 December 2018 (EST)

I strongly agree with the proposal. Annie 17:15, 20 December 2018 (EST)
Agree. MagicUnk 17:48, 20 December 2018 (EST)
Agree also. --Vasha (cazadora de tildes) 18:09, 20 December 2018 (EST)
I also support this. --Ron ~ RtraceTalk 21:20, 20 December 2018 (EST)
Yes, please. Stonecreek 01:25, 21 December 2018 (EST)
Agree. Rudam 08:28, 21 December 2018 (EST)
I support this. --Chris J 15:35, 21 December 2018 (EST)
Pile-on support. ···日本穣 · 投稿 · Talk to Nihonjoe 16:10, 21 December 2018 (EST)
Another yes from me. PeteYoung 20:17, 21 December 2018 (EST)

Support for Non-Linking Secondary IDs -- Outcome

Consensus reached. FR 1236 "Allow non-linking External IDs" has been created. Ahasuerus 13:05, 22 December 2018 (EST)

How to handle PODs?

Hi, I was wondering whether Open Road Media is a POD publisher? I have The Goblin Reservation from Clifford D. Simak, and on the last page there are the following codes: BVHW07s0858081018, and, 529577BV00001B/146/P. From the former I deduce a printing date of 2018-10-08, and the second indicates POD (it has the same structure as confirmed Amazon PODs). Correct? My second question is, how do we best enter and verify POD publications, as there seems to be no guidance available yet for PODs? Obviously, a pub per print date (when available) is impractical. Would we update a pub, and add printing info like the codes above in one single pub, referring to the PVer and his copy? MagicUnk 04:39, 25 December 2018 (EST)

Open Road is a POD publisher, yes. They are doing a lot of reprints (they started only as e-book publisher I think and then just branched out). The last time we had this discussion, we kinda decided to consider all printings of PODs the same publication as long as nothing but those codes and dates change (same cover, same author version and so on). Adding the codes in the publication does not make sense - there may be thousands of them for popular books... I think we are still waiting and watching the situation. When I am cataloging POD books, I mention in the notes that it is a POD book but that's pretty much it. Annie 04:56, 25 December 2018 (EST)
There's the remaining question of printing dates; do we want to capture the printing date, and other related info, of verified PODs, as the verified copies are limited in number (for now). It would have the advantage of gathering data and keeping it with the publication. We can always go back and clean up later when we settle on how to handle PODs, right? See also the Binti case below. MagicUnk 04:55, 27 December 2018 (EST)


There's also the Binti case (and maybe other TOR chapbooks too). So far, the following information is available:

  • Binti - chapbook with standard print runs (first, fifth, eight, tenth, thirteenth have been listed so far). No evidence of POD. Nihonjoe and/or Hitspacebar may want to chime in with additional info on their copies.
  • Binti: Home - chapbook, all seem to be PODs, but with different 'characteristics'. The following info is available:
    • POD with First edition: January 2017, and P1 on the copyright page, and date and sequence numbers and 'Printed in...' on the last page (MagicUnk and Bluesman's copies)
    • POD without any of the numbers, nor P1 on its copyright page, only 'Printed in the USA' on back cover (Hitspacebar's copy)
      I've asked Nihonjoe to check his copy.
  • Binti: Night Masquerade - novel, seems to be a mixture of standard print-runs, and POD. Following info available so far:
    • First printing, full number line, no POD info whatsoever (MagicUnk's copy)
    • POD info, such as "Printed by BoD in Norderstedt, Germany" on top and has a QR code on the lower left corner - not sure whether there's the date code and/or sequence number too (Hitspacebar's copy)

As stated by Jens, it looks like at least TOR does a mixture of regular print runs and print-on-demand. I would suggest to make that distinction in the pub records too: ie have at least two records to distinguish POD from regular printings:

  • a record for all PODs, and - as Jens put it "I guess we should record in the note of the current record that copies are maybe POD and, as long as we can't clearly distinguish the different prints, also add all information (like the "P1" and the long sequence of letter numbers on the last page) to the note. Jens Hitspacebar 07:17, 31 March 2018 (EDT)"
  • and a record for the regular print runs.

Does this makes sense? MagicUnk 04:55, 27 December 2018 (EST)

Performance - 2018-12-26

I am aware of the performance issues that we have been experiencing today. As near as I can tell, they are being caused by a number of robots (Google, Bing, SemrushBot, etc) crawling the site at the same time. I am working on it. Ahasuerus 18:46, 26 December 2018 (EST)

I have identified the culprit. A rogue bot was running a custom Advanced Title Search which was designed to scrape a subset of our titles. It was also hiding that it was a robot. A rather odd thing to do considering that our backups are publicly available, so there is no need to scrape Web pages.
I'll create an SR to restrict Advanced Search selection criteria. Sorry about the aggravation. Ahasuerus 20:27, 26 December 2018 (EST)
Advanced Search is visible from pretty much any page, you need to know about the archives (or search the wiki) to find them. So not really surprising that someone will decide to go with Advanced Search... Thanks for finding the problem quickly :) Annie 20:46, 26 December 2018 (EST)
Good point. It may be best to add a note to the Advanced Search Page. Ahasuerus 20:57, 26 December 2018 (EST)
Is it back to doing it again? It seems that some queries are slowish again - almost the same way they slow down when the nightly reports run and how it felt earlier today. Annie 21:43, 26 December 2018 (EST)
Yes, that robot is back and running the same search. It's up to record 131,000 now. I'l see if I can do something about it in the short run. Ahasuerus 21:59, 26 December 2018 (EST)
I have tweaked our access settings to ban this particular bot temporarily. Ahasuerus 22:33, 26 December 2018 (EST)

(unindent)Is the not so intelligent bot back? Annie 18:36, 28 December 2018 (EST)

It is. It's also using VPNs to avoid getting blocked. I am looking into. Ahasuerus 18:43, 28 December 2018 (EST)
P.S. The underlying problem is that our Advanced Search software lets users create almost arbitrarily complex queries which then require traversing and examining hundreds of thousands of title records. While a query is running, all title records are locked, which makes all Web pages that display titles pause for up to 10 seconds.
Ideally, we would change the Advanced Search software not to lock records while running. Unfortunately, our database settings do not support this functionality.
Alternatively, we could impose additional restrictions on Advanced Search selection criteria, but it would make Advanced Search less useful. I'll need to think about the trade-offs involved. Ahasuerus
Have a separate Advanced Search for logged in and non-logged in users? The non-logged ones limits the criteria and the logged in one doesn't? -- JLaTondre (talk) 18:54, 28 December 2018 (EST)
An interesting thought. Thanks. Ahasuerus 18:57, 28 December 2018 (EST)
I'm not fond of that idea--why should one bad actor force everyone to have to log in in order to search properly? --Vasha (cazadora de tildes) 10:54, 29 December 2018 (EST)
Several of the sites that I use regularly require a log in to use advanced search, possibly for the same reasons.--Rkihara 11:48, 29 December 2018 (EST)
Because it's better than everyone being impacted as is the current case. -- JLaTondre (talk) 12:28, 29 December 2018 (EST)
Plus our accounts are free and do not require an email or verification - anyone that really wants to search can create one in seconds. Google search does not require one, simple search and even some advanced search options will still remain open. And we do not have unlimited resources and allowing the server to go down just because we are trying to be nice is a bad idea. Annie 14:31, 29 December 2018 (EST)
Can bots have logins? ../Doug H 14:53, 29 December 2018 (EST)
Technically? Yes - which is why so many sites use CAPCHA and similar things (among other reasons). But most bad actors tend to move on when they are asked to have a login as opposed to coding a login into the bot. Although if they are really persistent, coding the bot to create a new account and then do the search is not going to be too hard (and it is being done daily on sites that require a login for everything). Annie 15:02, 29 December 2018 (EST)
Also can add a requirement to have a handful of approved edits before enabling the more complex features. -- JLaTondre (talk) 16:32, 29 December 2018 (EST)

(unindent)And it seems like it is a very persistent bot - the site is sluggish again... Annie 14:34, 29 December 2018 (EST)

It was active earlier today, around 8-9am EST, and kept switching IP addresses -- I had to play whack-a-mole with it for an hour. It's usually active a few times a day, usually in the morning and in the early evening EST. I suspect that it requires manual intervention to change IP address and the operator is only available sporadically. It seems to be on hiatus again. Ahasuerus 15:17, 29 December 2018 (EST)
Yeah, it is back to normal - the site was a lot slower a few minutes before I posted above (almost as bad as it was when you were chasing that bad cleanup report a few weeks ago - definitely slower than on the last 2 days - or I just happened to be on the same titles...). I just wish we could just point the guy/gal to the archives... Annie 15:24, 29 December 2018 (EST)
I need to add a link to the backups to the Advanced Search page. Too many balls in the air at the moment... Ahasuerus 15:28, 29 December 2018 (EST)
At this point, probably wouldn't be seen as they already have the parsing logic and probably not looking at the page itself. Though of course, you could always tweak the layout to break their parser so they would have to check. Can you tell from the queries whether they working their way through something that should eventually end? Or are they just being intentionally disruptive? -- JLaTondre (talk) 16:32, 29 December 2018 (EST)
The query says "Find all titles that are not ESSAY or INTERIORART and that were first published between 1900 and 1999; sort by date." They have scraped 245K out of 562K eligible titles, so they are almost 50% there. Of course, it's possible that they will then change their query to cover 2000-2019 titles. Ahasuerus 16:54, 29 December 2018 (EST)

(unindent) The Advanced Search page has been linked to ISFDB Downloads. Ahasuerus 15:44, 31 December 2018 (EST)

Rod Serling

(copied from Talk:Awards)

The Rod Serling Memorial Foundation issues annual awards (complete with plaque!) Whom would I petition to have this award added? Thank you! —The preceding unsigned comment was added by Galacticjourney (talkcontribs) .

According to the award page:
  • The Rod Serling Award for Advancing Social Justice Through Popular Media honors a contemporary media industry professional whose work shines the light on prejudice, inequality, and evolving social norms.
  • 2015/2016: David Simon, a TV writer/producer none of whose TV credits appear to be speculative. Not in the ISFDB.
  • 2016/2017: Kenya Barris, a TV producer/writer none of whose TV credits appear to be speculative. Not in the ISFDB.
  • 2017/2018: David E. Kelly, a TV producer/director none of whose TV credits appear to be speculative. Not in the ISFDB.
  • 2017/2018: Bill D'Elia, a TV producer/writer none of whose TV credits appear to be speculative. Not in the ISFDB.
  • 2018/2019: Norman Lear, a TV producer/writer. His media credits are extensive, but I can't find anything speculative. We have one essay (published in Omni) on file.
Considering the fact that this award is for media (as opposed to written) work and that it's not related to SF, I don't think it falls within the scope of the project. Ahasuerus 15:46, 28 December 2018 (EST)
I would have to agree with Ahasuerus. If anyone listed on ISFDB ever wins one, it could be placed in the bio notes on the author/artist page. ···日本穣 · 投稿 · Talk to Nihonjoe 17:24, 28 December 2018 (EST)
I think you may be looking at the wrong Serling Awards: 2016 and 2017 :) --Galacticjourney 22:55, 28 December 2018 (EST)
Oh, I see. Checking the lists of awardees, I see:
  • 2016:
    • A blog about the history of science fiction with an emphasis on The Twilight Zone
    • An abstract film
    • An album inspired by a Twilight Zone episode
    • A podcast inspired by The Twilight Zone
  • 2017:
    • An anthology collecting 22 stories in the tradition of The Twilight Zone, which we have on file
    • A documentary related to a Twilight Zone episode
    • A musical record inspired by The Twilight Zone
Of the 7 awards, 6 are for media works with links to The Twilight Zone and one is for an anthology of stories related to The Twilight Zone. Since only one of the awards is for written speculative fiction, I think the best approach would be to document the award in that record's Note field. Ahasuerus 08:41, 29 December 2018 (EST)

Galactic Journey

We have a new editor that would like to add the Galactic Journey as a web fanzine. It does not appear to me to meet our online periodical criteria. However, it was nominated for Hugo in the fanzine category this year. As such, I would like to get a wider opinion than basing it solely on mine. -- JLaTondre (talk) 20:42, 28 December 2018 (EST)

The good JLaTondre invited me to join the discussion. The Journey won the Serling Award in 2016 and was a Hugo finalist in 2018. There are some twenty staff associated with the organization, many of whom are professional SFF authors, and articles are published every other day. It is at least as notable as some of the fanzines currently listed on ISFDB. Thank you for your consideration! :) --Galacticjourney 22:06, 28 December 2018 (EST)
It seems this should be "in" under the Online publications available exclusively as a Web page, but only if: ... shortlisted for a major award clause. How exactly to fit a blog-style publication into our data model is a wee bit of a challenge. Maybe treat each post as an "issue", along the lines of how we'd treat a daily print periodical? There are post-specific links, and each post has a date and author credit. How we'd link awards that are for the entire "publication", I don't know; I suppose we could make a collection to represent the entire year and link the award to that. --MartyD 12:33, 29 December 2018 (EST)
That clause though is under the fiction heading. I'm not seeing any fiction for this site. Seems to be mainly reviews and commentary? -- JLaTondre (talk) 12:42, 29 December 2018 (EST)
There are a thousand articles at the Journey...that'd be a bit of a headache. :) Maybe just an annual entry with notations as to awards won that year? You are correct that there is no fiction, except that the whole thing is somewhat fictitious (it's a fanzine written as if by people living 55 years ago). I do greatly appreciate your stretching brains to figure out how to make it fit! :) --Galacticjourney 15:57, 29 December 2018 (EST)

As there has been limited discussion, I have released my hold on this record. I'll let another moderator make the decision. -- JLaTondre (talk) 19:13, 4 January 2019 (EST)

More Charles McCarry

I love the novels of Charles McCarry, a great thriller/spy/politico/alternate-universe writer. We currently have a listing for him with, I think, five "Christopher Series" works listed. There are at least another four and maybe five that fall within that description, plus at least one novel that is clearly science fiction. I'll start putting these in as I get around to it. Hayford Peirce 10:16, 29 December 2018 (EST)

The Italian edition of my novel Napoleon Disentimed is NOT a serial

For some reason this novel is listed as being a serial. See I just pulled down my copy from the shelves and it is exactly as listed here, Urania 1135, Complete Novel, etc., but it is a stand-alone issue, with no other stories or anything else in it. In other words, this edition looks *exactly* like the publication of an entire novel. As I've only just returned to this site after being away for a number of years, I'm not sure what to do about this, so I'm bringing it to your attention here. If there is some other place on the site that I should have used, please let me know. Thanks! Hayford Peirce 12:29, 29 December 2018 (EST)

You've just discovered one of the quirks of this database. It was decided long ago that we would never assign anything in a magazine the title type NOVEL--instead, when a novel appears in a magazine, it has the title type SERIAL, whether it is published in several parts or just one. See Help:Use of the SERIAL type#"Complete Novel" rule for a discussion of the reasons behind this decision. --Vasha (cazadora de tildes) 12:42, 29 December 2018 (EST)
Cross-posted with Vasha's much more succinct response above. In case any of this detail is helpful: If a novel is printed in a magazine, we consider it a "serial", even if printed in its entirety in a single issue, with no other content. That is still technically an issue of the magazine, containing the novel, rather than the novel's publication as a "book". We then make a variant of that "serialization" title to a non-serial title, which ultimately shows where the work was published in magazines and where it was published as books. You can see the result here. The presentation in the Fiction Series section here is a little clunky with the combination of Serialization: and Translation: and lack of indentation, but still seems to convey the proper information -- the Italian translation appeared as a complete novel in a magazine. It all looks ok to me. What problem is it causing? --MartyD 12:47, 29 December 2018 (EST)
Thanks for all the above info. Until now I had no idea that Urania was a magazine and not a book series. No problems involved, of course, at least not after knowing the above. Hayford Peirce 13:58, 29 December 2018 (EST)

Adding External ID for the Belgische Bibliografie?

I recently submitted a number of pubs of Belgium publishers to add price in Belgium francs and added the URL of the source (De Belgische Bibliografie) in the notes. It then occurred to me that that is rather stupid as we (well, that's Annie actually :) recently finished cleaning up the notes and moved OCLC links to the External ID field. Is it quick to do to add these permalinks for the De Belgische Bibliografie/La Bibliographie de Belgique? If so, I'll refrain from further updates until the External ID has been added. Example: The External ID is the number at the end of the URL. MagicUnk 15:02, 29 December 2018 (EST)

Adding a new External ID Type is fairly straightforward. Are we sure that the URL scheme is stable? Ahasuerus 15:31, 29 December 2018 (EST)
I's say, yes, it is stable. If you hover over the little chain link to the right of the example above, the tooltip text says permanent link (new window). MagicUnk 15:55, 29 December 2018 (EST)
That should be good enough for our purposes. FR 1241, "Create a new External ID Type for De Belgische Bibliografie", has been created. Ahasuerus 16:12, 29 December 2018 (EST)
Make sure we have a matching template - we missed that for a few of the External IDs. :) Annie 16:22, 29 December 2018 (EST)
Oh, right. What should we call it? Ahasuerus 16:43, 29 December 2018 (EST)
The official name (in two of the official languages) is "Bibliothèque royale de Belgique"/"De Koninklijke Bibliotheek van België. With the site being, we kinda have a choice. If noone else has a preference, KBR sounds good to me - thus not chosing between the language versions (BRB abd KBB)... Or we can go with BB which will be language agnostic but will be very very confusing with the other external identifiers (in my humble opinion). Annie 16:54, 29 December 2018 (EST)
(after edit conflict) Small tidbit of info. Since Belgium is a bilingual country the name of the bibliography is to be in Dutch and French, so it's De Belgische Bibliografie/La Bibliographie de Belgique (actually Belgium is trilingual as German is the third official language, spoken in the east of the country near the German border). There seems to be no official abbreviation. We could use BB, which would nicely fit both Dutch and French. MagicUnk 16:55, 29 December 2018 (EST)
After reading Annie's post, KBR sounds good too. While KBR references the Royal Library instead of the bibliography, it would solve the confusion with other Ext ID's when using BB. Or we could have BeBiBe ... :-) MagicUnk 17:00, 29 December 2018 (EST)
KBR works for me. If there are no objections, I will implement it once I wrap up Fixer's submissions for the month. 57 ISBNs to go... Ahasuerus 09:50, 30 December 2018 (EST)
Sure, np. MagicUnk 11:22, 30 December 2018 (EST)

(unindent) KBR has been added to the list of supported External Identifier Types. A matching linking template has been added. If you run into any issues, please let me know. Happy New Year! Ahasuerus 18:01, 31 December 2018 (EST)

Thanks Ahasuerus. Mosr appreciated! MagicUnk 04:06, 1 January 2019 (EST)
Thanks! 31 publications have the direct link. I will clean them out and move the IDs to their new house :) Annie 18:21, 31 December 2018 (EST)
30 converted, 1 remaining that is not like the others. I will look at it later unless someone can figure it out faster :) Annie 18:47, 31 December 2018 (EST)
You're too quick Annie, you beat me to it :). Thanks for the conversion. I'll have a look at the remaining one. If you could provide me with the pub reference? MagicUnk 04:06, 1 January 2019 (EST)
I just happened to be around :) The "31 publications" link in my previous message now points to the only remaining one but here is the direct link as well :) Annie 04:45, 1 January 2019 (EST)
Submitted the fix! MagicUnk 05:05, 1 January 2019 (EST)

(unindent) Now that the dust settled, can we add KBR to this report? Annie 16:09, 3 January 2019 (EST)

Done! Ahasuerus 17:49, 3 January 2019 (EST)

Belgium Francs - abbreviation?

Related question: what abbreviation should I use for Belgium Francs? I've browsed the internet, and a number of different options are available: the ISO code (BEF), or alternatively Bfr. ? I've also come across simply fr., or BFR, or BFr. ...? MagicUnk 15:02, 29 December 2018 (EST)

There's no real consistency. You should not use BEF (the ISO code). We intend that the "symbol" be used. I think for francs, this is "fr", although I know we have extensive use of "F". The "$" case provides precedent for applying a country-specific modifier on what would be an ambiguous symbol (e.g., "A$" for Australian dollar prices). So I'd be inclined to use "Bfr". And we include a space after any non-symbolic currency "symbol", so, for example, "Bfr 123". --MartyD 17:58, 30 December 2018 (EST)
Thanks. That makes sense. Would we benefit from keeping a list of currency symbols in the help text? We would then be able to, say, 'officialize' use of C$ for Canada, Bfr for Belgium, etc. Anyone else any thoughts? MagicUnk 03:53, 31 December 2018 (EST)
The list of the more popular ones (when the help page was written anyway) is already there - including the Canadian dollar. This is the help page for the price field - there is a lot of interesting information in these help pages even for fields taht appear clear. Adding some new currencies to the list is probably a good idea :) Annie 04:16, 31 December 2018 (EST)
Ah, yes... Would it be OK to add Bfr and ƒ (for Dutch Guilders) to the help text? MagicUnk 06:50, 31 December 2018 (EST)
Spanish peseta is Pta, Mexican dollar is Mx$. Question: since Argentinian peso is Ar$, should we change the Australian dollar to Au$? That is the form you always see in actual use, anyway. --Vasha (cazadora de tildes) 15:13, 31 December 2018 (EST)
Changing the Australian dollar is a bad idea -- we have thousands of publications with it and everyone is used to using it. So no, I will vote strongly against changing it. Otherwise we should change the good old US dollar to U$ or something :) Let's leave the established symbols alone. Annie 18:19, 31 December 2018 (EST)
Once we start working on adding support for multiple prices per publication (FR 1158), it will be a good time to revisit the issue of currency symbols. The proposed redesign will make them table-driven, so changing currency signs will require a single database update per currency. Ahasuerus 18:26, 31 December 2018 (EST)
True. I was commenting on the situation now when people need to remember how to write certain currency symbols. If and when we redesign the whole thing, we can discuss again what/how we want to be shown. But swapping a well-established symbol that is used a lot just does not make sense. :) Annie 18:30, 31 December 2018 (EST)
I went ahead and updated the help text with Bfr, ƒ, Pta, Mx$, and Ar$ examples. Let me know if it isn't acceptable.
Also, I have been thinking about pubs that have more than one price, and how we can ease the migration effort once FR 1158 becomes available. Currently we record the primary price (ie price in country of origin) in the price field, and the secondary prices in the notes field. Would it be a good idea to have templates for the most common currencies that show up in the notes, such as $, C$, A$, £, Bfr, ƒ,..., and also request editors to effectively start using them? If we would start using templates, I'm sure that the conversion would become much easier, no? MagicUnk 04:58, 1 January 2019 (EST)

a "known phishing site"

When I come to ISFPB from my destop screen, I go first to the Home Page. Then I click on ISFDB Wiki. From there I go to Community Portal, which is where I'm writing this. If I have just done this for the time, ie, starting with the Home Page from my computer desktop, a small box pops up on the lower right of my screen courtesy of Emsisoft, my excellent Anti-Virus program.

Its mysterious message is, more or less: " is a known phishing site and we have blocked it". After about ten seconds the box slides away and I am unable to get a screen shot of it to show you.

As far as I know, Emsisoft is an *excellent* AV program, one that is both alert and yet NOT overly intrusive.

Is there some reason that it seems to feel that some aspect of ISFDB is a phishing operation? It's very, very rare that I get a message like this. It's all very mysterious to me! Hayford Peirce 15:37, 30 December 2018 (EST)

There is a reference to in this discussion on the page. Your antivirus must be detecting the presence of links to the site. ../Doug H 15:56, 30 December 2018 (EST)
According to this review, Emsisoft offers "excellent" malware protection but "dismal" phishing protection. It detected only 18% of the phishing sites that PCmag tried in their October test.
Another thing to keep in mind is that the ISFDB allows links to arbitrary Web pages in notes and "Web Page URL" fields. Granted, all submissions are reviewed by moderators and are most likely safe at the time when they are approved. (Also, submissions by new editors are flagged.) However, the internet is a rapidly changing environment. Author-run sites are frequently abandoned and then purchased by third parties, some of them malicious. When it happens, our links can be affected. Ahasuerus 17:11, 30 December 2018 (EST)
Thanks for the lucid explanation. I have noticed before that Emsisoft doesn't seem to be up to speed with phishing in general. I THINK I can tell it to ignore this particular one, though. If I can, I'll do so. Hayford Peirce 17:28, 30 December 2018 (EST)

Support for non-linking External ID Types added

As per this discussion, the software has been updated to allow non-linking External ID Types. As expected, it was a fairly straightforward change.

The next step is to decide which non-linking External ID Types we want to add at this time. Here are the current candidates:

Anything else? Ahasuerus 18:42, 31 December 2018 (EST)

These look good to me for a start - and I cannot think off the top of my head of any other IDs that I had seen often enough to consider them eligible for pulling into an ID field. Annie 16:30, 1 January 2019 (EST)
OK, I have added the 5 non-linking ID types listed above. Here is an example of what a converted publication record looks like. If everything looks OK, I can create new cleanup reports to facilitate the conversion process. Ahasuerus 22:39, 1 January 2019 (EST)
Thanks for this. I don't know what I'm going to do with my templates now. --Ron ~ RtraceTalk 07:09, 2 January 2019 (EST)
Hey, they served their purpose! The new cleanup report that I deployed a few minutes ago takes advantage of the fact that these IDs were entered in a semi-structured manner to facilitate the migration process.
Once the cleanup reports are regenerated overnight, there will be 1,700+ publication records that will need to be updated. There are probably more since early on some IDs were entered in a non-structured fashion, but let's take care of the low-hanging fruit first. Ahasuerus 11:48, 2 January 2019 (EST)

(unindent) We probably should also add them to this report (with the Reginalds allowing a last alphabetical symbol) so we do not end up chasing them later when some typos happen. We probably will also want to have a check if it is in the proper range at some point (As these 5 are finite) but that is not as easy... Annie 16:11, 3 January 2019 (EST)

Do we know if the 3 numbered Bleilers use purely numeric record IDs? I have the Reginalds but not the Bleilers in my collection, so I can't check. Ahasuerus 18:10, 3 January 2019 (EST)
OK, the two Reginalds have been added to the cleanup report. Ahasuerus 18:55, 3 January 2019 (EST)
I suspect that Ron's books are out in the open and he can check easily - I do not remember seeing anything but numbers in either Gernsback, or the Early Years but both of them are in a box (and I have no idea which of the many boxes...) and admittedly I was not trying to verify if there is anything else there besides numbers. Annie 22:23, 3 January 2019 (EST)
Indeed they are. Bleiler numbers are all numeric for books. He does list the contents by letter within each anthology/collection by letter, but we wouldn't need to add that to a publication record, so a numeric test would be fine. --Ron ~ RtraceTalk 07:05, 4 January 2019 (EST)
Thanks for the confirmation. The cleanup reports have been updated. Ahasuerus 14:03, 4 January 2019 (EST)
I noticed something with this publication. Take a look at the first external ID which appears to have an extra space between the bullet and the number. It's possible that this is browser specific and I'm using Firefox. In any case, I fixed this by clearing an extra newline at the end of the notes. I put it back, for discussion. It's only a minor cosmetic issue, so not in any way urgent. Thanks. --Ron ~ RtraceTalk 07:28, 4 January 2019 (EST)
I have tried it under Firefox 64.0, Google Chrome 71.0, MS Edge 44 and IE 11 and I am not seeing the extra space. Could you please check which version of Firefox you are using? Ahasuerus 11:05, 4 January 2019 (EST)
I'm also running 64.0. A little additional testing finds that the extra space appears only from the View This Pub link from the SQL statements page. A refresh makes things appear correctly. Also no matter how I edit it, there appears to be one newline at the end of the note text, i.e. whether I remove the newline, or add a second one, when I go back in there appears to be a single new line at the end of the text. Given that the display rights itself on a refresh, I wouldn't worry about it. Also it seems that there may be some sort of cleanup of the notes field that puts a single newline in place of any trailing whitespace (I'm guessing). If this is by design or accident, it certainly seems reasonable. Sorry to have you chasing wild geese. --Ron ~ RtraceTalk 19:13, 4 January 2019 (EST)
Thanks for the additional information! I have been able to recreate the problem -- sort of. Under Firefox 64.0, the first displayed External ID is displayed with an extra space if the Notes field immediately above contains the "BREAK" template. The other tested browsers do not have this problem and even under Firefox it is somewhat inconsistent.
The underlying HTML code is valid as per the W3C validator, so I expect that it's an issue with Firefox 64.0. If the bug is not fixed in the next few versions, I may do more digging and try to come up with a workaround. Ahasuerus 21:25, 4 January 2019 (EST)

Performance - 2019-01-01

The bad robot is back. Working on it. Ahasuerus 12:13, 1 January 2019 (EST)

Can you figure out who owns the bot and contact them? ···日本穣 · 投稿 · Talk to Nihonjoe 12:57, 1 January 2019 (EST)
I am afraid not. All I know is that it claims to be a Firefox browser running on a Mac, but that's trivial to forge. When the bot started its quest for our data, the queries were coming from the Czech Republic. Once I blocked a couple of Czech IPs, the bot started using IPs from all over the world. It's possible that the original Czech IPs were also fake, so we really have very little to go by. Ahasuerus 13:10, 1 January 2019 (EST)

Proposal: Advanced Search and performance

The reason that the bad bot that we are currently fighting is affecting performance is that the Advanced Search lets you page through the whole database if that's how you formulate your query.

How about we limit the Advanced Search functionality to the first 100 pages? Are there real life scenarios where legitimate users may need more than 100 pages worth of Advanced Search results? Ahasuerus 12:48, 1 January 2019 (EST)

Absolutely yes. I've often had cases when I've paged through search results. How are the results being returned? Are they all being returned and then paged on the display side? Or are they being paged via MySQL limits? The latter is the better way for performance. -- JLaTondre (talk) 13:00, 1 January 2019 (EST)
Advanced Search pages are currently built using MySQL limits.
What would you say was the maximum number of pages that you had to page through? 300? 500? (500 pages is 50,000 records, which is a lot of records to process manually.) Ahasuerus 13:05, 1 January 2019 (EST)
Not more than a handful. I'm trying to think of a specific example and failing ;-). Usually when I'm doing clean-up and trying to find something. However, I suppose in many of these cases, I could probably have found ways to do it with a more restricted query. I've just gone with that is there. However, how are you thinking this would help? Wouldn't the bot simply change it's query parameters to return fewer results and then do more requests? Since the queries are already using limits, the performance gain from eliminating the built in paging and having the bot do its own is unlikely to be much, is it? -- JLaTondre (talk) 13:11, 1 January 2019 (EST)
I have on a few occasions pulled up searches containing hundreds of pages and gone through them in a spot-check way just to get an overview of what is there. Trying to get that overview from more focused searches would have been complicated, though not impossible. Can you display a message like "The query returns 654,399 results; only the first 20,000 will be displayed"? Twenty pages plus knowing the total number would have been good enough for me. --Vasha (cazadora de tildes) 15:36, 1 January 2019 (EST)
There is an FR (FR 882) to "Display the record count in advanced search results". It's doable, but it would slow down certain types of queries, in certain cases significantly.
Perhaps we should add a new button next to the "Next Page" button. Something like "Show the number of matching records". Also, it may be useful to add a "Previous Page" button. Ahasuerus 18:13, 1 January 2019 (EST)
"Previous Page" will be nice - although next puts the start parameter early enough in the string so it is easily visible.:) And being able to get a count before I see the results will also be very useful... And I like the two separate buttons idea - maybe even make the new button to return only the number of records (with the parameters you searched with above so you can see if you did a typo or something?) and the current search button working as before. Annie 18:25, 1 January 2019 (EST)
The first thing that comes to mind is that if the bot maintainer needs to rewrite the bot, then there is a good chance that he or she will notice the recently added note about our backups being publicly available.
Also, I have run a few versions of the queries that the bot is using on the development server. Better scoped queries -- e.g. "title date starts with 1981" instead of "title date starts with 19" do not affect performance nearly as much as the queries that the bot is currently running. I haven't done a lot of digging, but I assume that the temporary tables that the MySQL engine has to build are much smaller when using tighter selection criteria. Ahasuerus 13:24, 1 January 2019 (EST)
I'd say the same - the only case when I needed to go over more than the first 3-5 pages had been during cleanup (mainly keeping an eye on how many OCLC records are still there - the number of pages was the easiest way:)). But I could have used better search queries if we had a limit (the hard 1000 limit on the Notes search made me very creative :)
I wonder if some FULLTEXT indexing (see this) Annie 14:48, 1 January 2019 (EST)
At one point I started investigating the MySQL implementation of FULLTEXT indices. Different MySQL versions support different subsets of the functionality and I need to do more digging. Ahasuerus 18:07, 1 January 2019 (EST)
and probably even indexing on the date columns (I did not see one last time I looked at the DB but I was not looking for it specifically) in the DB won't help more than limiting paging. Annie 14:48, 1 January 2019 (EST)
Adding date indices to titles and pubs may help with certain types of Advanced Searches. However, it's unlikely to help in this particular case since the bot searches for "title date starts with 19", not something that having an index would speed up. Ahasuerus 14:55, 1 January 2019 (EST)
I have added date indices to titles and pubs. It may help speed up some types of Advanced Searches. Unfortunately, the process caused the server to freeze for over a second. Sorry about that -- I failed to consider the effect of fragmentation on the live server. Ahasuerus 18:57, 1 January 2019 (EST)

Advanced Search changes

Part 1: A "Previous Page" button has been added to all Advanced Search pages. Ahasuerus 15:51, 2 January 2019 (EST)

Part 2: Advanced Search results have been tentatively limited to 300 pages or 30,000 records. Ahasuerus 19:19, 2 January 2019 (EST)

Part 3: "Submit Query" in Advanced Title, Author, and Publication Search sections has been replaced with two new buttons. The first one, "Get Results", is functionally equivalent to the old "Submit Query" button. The second one, "Get Count" gives you a count of the records that match the entered section criteria. For example, clicking "Get Count" after entering "Title Year is exactly 8888" results in the following output: "Count of matching records: 514". Ahasuerus 20:05, 7 January 2019 (EST)

Can we reverse the Count and Results buttons? I keep hitting Count all the time when I am trying to get to the results... Annie 16:52, 10 January 2019 (EST)
It would be easy to do, but let's make sure that other users won't run into the opposite problem first. Perhaps we could move the new button further to the right? Maybe under the AND/OR buttons? Ahasuerus 16:57, 10 January 2019 (EST)
Maybe... my hand gravitates to whatever is on the right - but maybe putting some space between them will help as well. Annie 17:11, 10 January 2019 (EST)

Part 4: Error messages and informational messages have been consolidated and cleaned up. Certain invalid Advanced Search URLs should no longer generate Python errors. Ahasuerus 18:51, 8 January 2019 (EST)

Part 5: As per FR 1251, Advanced Search has been changed to allow only one "AND" or "OR" value per search. As noted in the FR:

  • Currently [Advanced Search] allows a mix of "ANDs" and "ORs", which results in unexpected behavior. This will become more important as we let users specify more selection criteria in Advanced Search queries.

Previously bookmarked searches should still work as long as they contain all "AND"s or all "OR"s. Ahasuerus 15:42, 10 January 2019 (EST)

Part 6: The number of selection criteria which can be simultaneously specified in Advanced Title/Author/Publication searches has been increased from 3 to 5. At the moment, each page section displays 5 blank lines. Once we confirm that everything is working as intended, I plan to shrink each section to 1 line and display the same "+" sign that other multi-fields have been using for the last year. Ahasuerus 19:53, 10 January 2019 (EST)

I don't know if it is related to the recent changes, but the Show All Titles link on author pages are producing a "Error: Invalid Advanced Search Parameters" message. --Ron ~ RtraceTalk 20:45, 10 January 2019 (EST)
Oops! Let me try to fix it real quick... Ahasuerus 21:50, 10 January 2019 (EST)
The bug should be fixed now. Sorry about that! "Show All Titles" and Advanced Search use the same code for historical reasons which no longer apply. It was a timely reminder that I need to separate them as part of this rewrite. Ahasuerus 22:10, 10 January 2019 (EST)
Thanks for being so quick! --Ron ~ RtraceTalk 22:23, 10 January 2019 (EST)
Also, I tried Tag (does not contain) "juvenile" AND Title Type (is exactly) CHAPBOOK AND Title Year (is exactly) 2018, and got only eighteen results -- what was wrong with that? --Vasha (cazadora de tildes) 20:50, 10 January 2019 (EST)
Vasha, keep in mind that if there are no tags at all, this query won't match either - "does not contain" means "exists and does not contain". Can that explain what is going on? (not too many people tag chapbooks I think - here are the ones that have the letter a - the ones that appear empty have private tags. Annie 21:06, 10 January 2019 (EST)
Ah, if the "empty" ones contain private tags, that makes sense. Ahasuerus, is changing the behavior of "does not contain" to also find nulls (or adding an "is empty" option) one of the things you have planned? --Vasha (cazadora de tildes) 21:19, 10 January 2019 (EST)
Yup, it's our old friend Bug 690; it also has cousins like Bug 571. I hope to address them as part of this rewrite once I get a bunch of other things sorted out and streamlined. Ahasuerus 22:18, 10 January 2019 (EST)

(unindent) The new fields (4 and 5) do not change their field type when you chose an appropriate field in the first one - Language list for example. 1-3 switches to the dropdown list; 4&5 remain as text fields. Annie 10:43, 12 January 2019 (EST)

Thanks, I'll take a look. Ahasuerus 11:24, 12 January 2019 (EST)
The bug has been fixed. You may need to do a full page reload (Control-F5 in most browsers) for the fix to take effect.
There is another, display-only, bug which can be reproduced by changing "Title" to "Title Type" on the first line. The drop-down list is displayed to the right of the AND/OR radio buttons instead of to the left. Ahasuerus 15:12, 12 January 2019 (EST)
OK, I think I finally got it to work correctly. Please let me know if you run into anything unexpected. Ahasuerus 19:14, 12 January 2019 (EST)

Lao added

The Lao language has been added to the list of supported languages. Ahasuerus 14:57, 3 January 2019 (EST)

Can we add the Canopus Award?

(Copied from the Help Desk)

Although it's not clear if it's still alive, it did make some relatively high profile awards for a couple years:

Previous awards:

—The preceding unsigned comment was added by Deepsettpress (talkcontribs) .

Checking their list of judges from 2015, I see a wide variety of backgrounds, including an Analog author (Juliette Wade), a former Communications Director for the SFFWA (Jaym Gates), a few PhDs/MDs, a former Wall Street Journal reporter and a major general. Looks like a legitimate award. Ahasuerus 20:51, 4 January 2019 (EST)
Can we add it then? Deepsettpress 19:12, 6 January 2019 (EST)
If there are no objections, I will add it tomorrow. Ahasuerus 20:19, 6 January 2019 (EST)
I have added the award and entered all professionally published fiction nominees. We may need to revisit it if and when the award is revived. Ahasuerus 12:30, 7 January 2019 (EST)

Valerie Nieman canonical name

I'm about to switch the canonical name of Valerie Nieman Colander to Valerie Nieman. She's been publishing under the shorter name since the late 1990s and has a new speculative novel coming out next year under that name. --Vasha (cazadora de tildes) 03:05, 5 January 2019 (EST)

Viewing submissions as raw XML

As per FR 1223, the software has been updated to allow viewing submissions as raw XML. In the past this ability was restricted to moderators. If you encounter any issues, please report your findings here. Ahasuerus 20:20, 6 January 2019 (EST)

Thanks, that'll be helpful sometimes. --Vasha (cazadora de tildes) 21:02, 6 January 2019 (EST)

Silas Weir Mitchell

The canonical name of Silas W. Mitchell clearly should be changed, but to what? On the one hand, we have lots of publications from his own lifetime in the database, all of them under "S. Weir Mitchell." On the other hand, he is in SFE3 as "Silas Weir Mitchell," and that's the name that editors nowadays are using the most when they reprint his stories (3 in this DB). Should we use the "Silas Weir Mitchell" form because it is currently the most familiar, or "S. Weir Mitchell" because it is the most numerous? --Vasha (cazadora de tildes) 05:09, 9 January 2019 (EST)

Update: I have used Google books to look into 10 other recent nonfiction books about science fiction, apart from SFE3, and all but one of them use "S. Weir Mitchell." That considerably strengthens the case in favor of "S." --Vasha (cazadora de tildes) 05:49, 9 January 2019 (EST)
"S." seems most appropriate to me, given our standard for canonical names. --MartyD 21:43, 9 January 2019 (EST)
Yep. And the change is now done. --Vasha (cazadora de tildes) 21:47, 9 January 2019 (EST)

Google Search and regular Search

The regular Search software has been updated to leverage the Google Search functionality which was implemented a few weeks ago. If a regular name, title, series, publisher or publication series search fails to find any matching records, the results page will let you re-run the same search using Google.

Somewhat surprisingly, Google's search logic isn't always very robust when searching a subset of Web pages hosted by a single site ( in our case), but it's better than nothing. Ahasuerus 19:02, 9 January 2019 (EST)

Galactic Journey, again

Hello, folks. I could use some assistance.

We determined earlier that, as a webzine with more than a hundred articles every year, it is too cumbersome to add Galactic Journey one article at a time. At the same time, it was apparently decided that its having been a finalist for the Hugo last year justified some level of existence at the ISFDB. Some kind soul accepted the 2017 entry of the Journey, listed at 15 pages (which is the number of pages it takes up when you put in the URL window).

So, great! The Journey is on the ISFDB.

There are three things I'd like to do now that it's here:

1) Give author credits since I'm not the only one who writes for it (including several folks who are published authors with works elsewhere in the ISFDB). I have tried putting the authors in the top and in the bottom of the edit dialogue; both options have been rejected. I have been told sternly to add each article individually. We've already determined that's not necessary.

2) Each year of the Journey get an omnibus entry, like the 2017 one. So, 2013, 2014, 2015, 2016, and 2018.

3) The Hugo Finalist page link to Galactic Journey (2017), and the Galactic Journey (2017) page indicate that the Fanzine was a Hugo finalist that year.

However you would like that to be accomplished, please let me know. :) Thank you for your attention.

--Galacticjourney 09:43, 11 January 2019 (EST)

I think that you are mixing two types of entries in your head. If you want the other contributors added, you will need to add the individual articles as essays (and reviews) inside of the main yearly publications. What we determined is that we do not want a separate PUBLICATION per article (so a new webzine for each article) but we still want a separate title - a content item inside of the Fanzine publication - so it looks similar to how we record Daily Science Fiction for example (over here - we do these montly due to the structure; if you have more than 100 articles per year, we may also need to go for an yearly title and monthly publications as well).
So if you want, you can start by using what you have now as a 2018 entry and start adding the separate posts as content elements (and rename it for the year you want it to belong to). Then we can make a series from the yearly records. Once we have the yearly record for the year you need, we can then add them to the awards properly. Let me know if that makes sense and if you need any assistance. If you want me to, I can also create the yearly records for you and make the series so that after that all you need to do is to add the contents titles. Annie 16:58, 11 January 2019 (EST)
Yowza! Well, if that's the way it has to be done. I'm just confused because underneath the link you have, there's a simple entry for 2017: -- this is what I was hoping to model rather than individual posts. As for yearly records, any assistance you're willing to offer is tremendously appreciated. Thank you so much for your quick and warm response. :) --Galacticjourney 17:16, 11 January 2019 (EST)
Again - two different concepts. :) What you will have will be 1 fanzine publication entry per year (for now); and then 1 EDITOR title inside (a special container title for magazines and fanzines). Then when you open the publication record, you will see the articles as content items - how you see them inside of one of those monthly Daily SF pubs (or how you see under a collection for example). I can setup your publications so you just need to edit to add the content - let's start easily with the year that will be getting the award connection (2017?) as it is the only year that is clearly eligible anyway - plus that way we can see how it looks and we can use that as a base for conversation. How many articles are there in that year? If we have more than 200, I think we should split in quarters or even months - but I need some numbers (and yes, I know I can check on my own but do not feel like counting just now :)). Once I know that, I will get the structure created.
We are a bibliography, not an index. Having an empty container with a gazillion names attached to it does not describe your fanzine - it just says "here, it exists". Well - not what ISFDB is all about. :)
Alternatively we can leave the only record you have now and connect that to the awards -- but then you cannot add other writers. :) Annie 17:24, 11 January 2019 (EST)

That all makes perfect sense. You really are fantastic, thank you. :) And yes, you shouldn't have to do more than the minimum work! There are precisely 150 articles published in 2017. --Galacticjourney 17:48, 11 January 2019 (EST)
OK. Here is the series where all the yearly records will go. This is now the record for 2017 - notice how the name is different for the publication vs the title (this has to do with the series view - both in list form and in grid view). Now you can edit the 2017 record and add articles. I would advice you to do them in batches (10-20 at a time) and you can use the pipe format to give them order (for example "|12" will be sorted before "|13". Or you can use a month/date notation for the page number (11.03 being the 3rd of November; you want the month first so they line up and you want the leading 0 so that 03 is sorted before 11). Keep in mind how we regularize titles (Title case with a bit of a twist: the first word is capitalized; all later words are capitalized except for "and", "or", "the", "a", "an", "for", "of", "in", "on", "by", "at", "from", "with", and "to"; hyphenated words have the first letter after the hyphen capitalized) and author names (spaces between initials, dots after initials and so on (see this for more details). How you capitalize in the fanzine itself is irrelevant - you need to regularize when adding here). Annie 18:06, 11 January 2019 (EST)
PS: And I linked the record to the award - see how you are connected now.
I think that we still need to discuss how to handle this specific case (being a non-fiction online only fanzine is a bit outside of the rules as was mentioned above but then nominations and all that...) so if you want to add content, go ahead and do it (for now). If the eligibility decision is reversed, well... :) Or you can leave it as is for a few days so we can try to restart the discussion. Up to you. :) Annie 18:06, 11 January 2019 (EST)
Thanks so much, again. I believe there are non-fiction Fanzines on ISFDB currently (for instance, FANAC). As for whether or not the Journey is fiction, there's definitely a fictitious element to it. After all, we don't *really* live in 1964. :) --Galacticjourney 18:59, 11 January 2019 (EST)
Non-fiction fanzines we have - they had been always in scope. Non-fiction web-only are a different matter - we did not accept anything web-only until a few months ago - if you do not have an ebook at least, you were not eligible at all. :) And if you look at the records of FANAC - they are here without publications - just an empty shell so we can link the awards. :) Annie 19:10, 11 January 2019 (EST)
Well, I think it's about time web-only Fanzines got included on the INTERNET Science Fiction Database. ;) Thank you, Annie! I hope you're going to Dublin. And/or Baycon, Loscon, etc. --Galacticjourney 20:15, 11 January 2019 (EST)
Speculative, not Science :) And it is a FICTION DB :) Non-fiction had always been secondary and supporting the Fiction. My current plans are to make it to Dublin but work can get a bit unpredictable sometimes so who knows :) Annie 20:48, 11 January 2019 (EST)

Advanced Search and dynamic/JavaScript-driven pages

FR 1142 "Lift the 3 search values per Advanced Search limit" says:

Instead of displaying three input lines per Advanced Search type, we should display just one line followed by a '+' button. It should be similar to the way '+' buttons work elsewhere and allow entering as many search values as needed.

I was about to start working on this FR when I realized something. If we were to implement the requested functionality, it would mean that advanced searches that use more than one selection criterion would require that the user's browser support JavaScript, i.e the ability to change ISFDB Web pages dynamically when the user clicks on buttons like "Add Author" or "+".

Up until now we have only required JavaScript when editing the data, but all of our display and search pages work with JavaScript disabled. You don't get to see some minor "quality of life" features, e.g. those dynamically changed drop-down lists on the Advanced Search page, but the core functionality is still available.

This was a conscious decision which we made back in the mid-2000s. The reasons were varied:

  • Some really old browsers like Lynx do not support JavaScript.
  • Many people browse the internet with JavaScript disabled by default (using NoScript or native browser controls) to minimize exposure to security issues.
  • Some "spiders" that crawl the Web and index our Web pages can be thwarted by JavaScript, although major spiders have gotten better at it.

Some of these reasons are probably no longer valid, e.g. Lynx's market share is currently 0.00%. On the other hand, security has become more important over the years, which means that many users browse the Web with JavaScript disabled by default. I certainly do.

I also find JavaScript-based code to be markedly more browser-dependent; there have been times when I had to rewrite previously deployed JavaScript code because it didn't work under some older browsers. Finally, JavaScript is more time-consuming to implement, although it may have more to do with my lack of JavaScript experience.

So I guess we have two decisions to make. The first one is whether we want to change the current policy:

  • JavaScript is only required for editing

to something like:

  • JavaScript it only required for editing and running Advanced Searches

If we decide to keep the current policy, then we need to decide what to do about various requested Advanced Search enhancements. For example, FR 1143 reads:

Create Advanced Search options for all ISFDB record types, i.e.:
  • Advanced Series Search
  • Advanced Publisher Search
  • Advanced Publication Series Search
  • Advanced Award Type Search
  • Advanced Award Category Search
  • Advanced Award Search
Some of these search types would be more useful than others, but it would be nice to add all of them simply to make things consistent across the board. They are not hard to implement, so the added effort wouldn't be significant. The only concern that I can think of at the moment is that it would make the Advanced Search page too busy. We could address this issue in a couple of different ways.
The easiest one would be to turn the Advanced Search page into a menu which would list all of the available search types. The user would then click the search type she is interested in and be taken to the Web page for that search type.
Another way to handle the issue would be to display a single drop-down list with all of the search types. Once the user chooses the search type, the software would display the appropriate input fields and drop-down values. It would be similar to how the software dynamically changes the drop-down values for different advanced search criteria. The second way would require a bit more work than the "menu" approach, but it should be doable.

If we decide to keep the current policy of "no JavaScript on search pages", then the second option is off the table and we are left with the first option -- see the bolded text above. Would that work? Ahasuerus 17:48, 13 January 2019 (EST)

P.S. In the meantime I am slowly rewriting the Advanced Search software to make it more maintainable. There should be no user-experienced changes for now. If you encounter anything unexpected, please let me know. Ahasuerus 20:33, 13 January 2019 (EST)
In the past, the Advanced Search used to interact badly with certain ad-blocking plugins, but I never bothered to mention this because, for one thing, it was no trouble to turn off the ad-blocker on the rare occasions that I needed to, and more importantly, you can't well take every single plugin in existence into account when you're coding. I think I will be able to figure out which future problems are due to plugins also and ignore them—but what sort of software interactions would you like to hear about? Any widely-used scripts that should be tested? --Vasha (cazadora de tildes) 21:05, 13 January 2019 (EST)
I expect that the most widely used third party tool that can affect Advanced Search behavior is NoScript. It allows or disallows JavaScript for individual sites. Chances are that the vast majority of our regular users who have NoScript installed have already marked as a trusted site, which enables the JavaScript used by Advanced Search to work. I use NoScript and haven't come across any issues, so we are presumably OK. Ahasuerus 09:15, 14 January 2019 (EST)

Fantascienza as an external ID

Can we add Fantascienza as an External ID and a template - most of our Italian titles are from there - and virtually all pre-2010 ones have entries there. They have permanent links (two of them actually: one via NILF (which stands for Numero Identificativo della Letteratura Fantastica): for example and one via the catalog itself I am working on resolving the Italian translators and variants so I may as well get some links added (because for some books, it requires some creative work to find the match). Annie 13:15, 14 January 2019 (EST)

Sure, we can do that. There are 46 references to "" and 151 references to "" in publication notes, but I assume that a review of our Italian pubs should be able to add a lot more.
Since the 2 types of URLs redirect to the same set of Web pages, I guess it doesn't matter which URL pattern we decide to use for this External ID Type. We can always change it later. Ahasuerus 15:34, 14 January 2019 (EST)
We have 3376 publications that mention the word fantascienza - and 99.99% (if not all) of them can have an ID added to them from what I had found :) So yeah - there are a lot more out there. And NILF is probably a good name for the identifier/template - and either link would work (that's why I mentioned both) :)
I will move to a different language temporarily until we decide and add that one - so I do not need to walk through the same titles again later :) Annie 16:29, 14 January 2019 (EST)
FR 1254 "Create an External ID Type/template for Fantascienza" has been created. Let's wait a couple of days in case we are overlooking anything. Ahasuerus 18:06, 14 January 2019 (EST)
One more reason to use the format - the template will be usable for referencing anything on the site - leads to an author page for example - the NILF numbers are used for anything in the catalog - books, stories, authors, publishers and so on. So we will have a single template covering everything easily. :) Annie 11:59, 15 January 2019 (EST)
Sounds good! Ahasuerus 13:34, 15 January 2019 (EST)

(unindent) NILF has been added as a new External ID Type and as a template. Do we know if the ID is always numeric? If it is, I can add it to the cleanup report. Also, do we need a new cleanup report to look for raw Fantascienza URLs in publication Notes? Ahasuerus 12:04, 16 January 2019 (EST)

It is always numerical. Let's hold off the raw report for now? I can clean the ones we have off search - I want to see what other patterns will show up (considering that NILF is used for other things). Then we can build the report so that new links are caught. Annie 12:38, 16 January 2019 (EST)
Or if you build the report, go for "" and "" thus catching all variations and we can precise later if needed. Up to you :) Annie 12:50, 16 January 2019 (EST)
Good point. I'll look for patterns in the database. You never know what kind of monsters are lurking under the surface! Ahasuerus 13:16, 16 January 2019 (EST)
I have created and deployed a couple of cleanup reports, one for "" and one for "". The data -- a couple of hundred pubs between the two reports -- will become available tomorrow morning. Ahasuerus 16:26, 16 January 2019 (EST)

(unindent) Can we add "Fantascienza" to the "Numero Identificativo della Letteratura Fantastica" description in the drop down help (Numero Identificativo della Letteratura Fantastica/Fantascienza)? That will make it easier for people to understand/connect the dots for that one. Not urgent but next time you are changing something on the page :) Annie 13:00, 16 January 2019 (EST)

Sure, I can do that. It's database-driven, so I just need to change the value of one field. Ahasuerus 13:07, 16 January 2019 (EST)
Done. Ahasuerus

(unindent)External IDs table is updated for both. I saw NILF in the templates list, are you planning to add NooSFere? Annie 14:56, 16 January 2019 (EST)

I thought I ha dadded both, but apparently not. Fixed now -- thanks for the heads-up! Ahasuerus 15:08, 16 January 2019 (EST)
The "Non-numeric External IDs" report has been updated to look for non-numeric NILF IDs. Ahasuerus 17:07, 16 January 2019 (EST)

Label changes to finish a previous change

Last year we changed the wording around the art titles to acknowledge that they are variants and not translations so now we call them variants in the contents or even when they are a variant in a different language for a cover. But we still call them translations in the other titles table. Can we change these labels so they all match (Call them "variant in another language" for example... Annie 17:20, 14 January 2019 (EST)

Makes sense. I have created FR 1253. Ahasuerus 17:52, 14 January 2019 (EST)

NooSFere as an external ID

One more for the external ID/template list - NooSFere. The URL is (the number can be positive or negative). We have some older links (like this one) but if you drop icarus from them, they still work (this is the same as this. And we have a few thousand cases where we use NooSFere as a source but without a link (so these can be added). I checked with Linguist (as I cannot find a statement that the URLs are stable) and we seem to be in the clear (and we have the links anyway so may as well move them). Annie 11:54, 15 January 2019 (EST)

Sounds reasonable. Unless there are objections, I will add two new External ID Types tomorrow. Ahasuerus 13:36, 15 January 2019 (EST)
NooSFere has been added as an External ID Type and as a template. I plan to update the cleanup reports later today. Ahasuerus 12:42, 16 January 2019 (EST)
A cleanup report has been created and deployed. The data will become available tomorrow morning. Ahasuerus 16:24, 16 January 2019 (EST)
I assume it looks both for the icarus/livres and the livres only links? Annie 16:31, 16 January 2019 (EST)
At this point it looks for everything that matches because there are a couple of broken links that a search limited to icarus/livres wouldn't find. There are a few other links in notes, but they shouldn't be publication notes.
At least that's the theory. We'll find out how closely it matches reality once we process the 1,579 pubs that the report will find tomorrow morning :) Ahasuerus 16:38, 16 January 2019 (EST)
The "Non-numeric External ID" report has been updated to look for non-numeric NooSFere IDs (one optional leading hyphen allowed.) Ahasuerus 17:08, 16 January 2019 (EST)

Ignore needed in report

We either need an ignore in Publications with direct Deutsche Nationalbibliothek links in Notes or we can template as {{DNB|gnd/107976218}} and then we will need an ignore option (or an extension to the check) in Publications with Invalid Non-numeric External IDs instead :) Thanks! Annie 17:15, 15 January 2019 (EST)

URLs like are for author records, right? If so, then should we move this URL to the author level? We could then create a human-readable name for "" URLs similar to the way we handle author pages hosted by WorldCat, the Library of Congress and BNF. Ahasuerus 18:18, 15 January 2019 (EST)
Yeah, the gnd ones are the author level records in DNB. The problem with this approach will be the cases where we need to link to one of those but we do not have the author in ISFDB (or they are not eligible yet because they are a translator only for "our" titles). Which is the problem here - we do not have Georg Altlechner in ISFDB under that specific pseudonym (the Axel Jeffers pseudonym is in the DB - so we can do that)... Let me think on how to rework the note so it works. But sooner or later, we may need to resolve the issue :)But for now, you are right, we do have a faster solution so I will fix it. Thanks for the idea! Annie 18:38, 15 January 2019 (EST)
Sure thing. The software has been updated to display "" URLs as "German National Library", e.g. see Adolf Sommerfeld. Ahasuerus 11:19, 16 January 2019 (EST)

Marion Zimmer Bradley's Atlantean cycle / novel

I do think that the way we have that cluster may be bettered by indexing the OMNIBUSes as NOVELs:

1) For the first 'OMNIBUS' edition, Locus observed that "This is the first hardcover edition as well as the first one-volume edition. The book was written as such but split in the U.S. for various profitable reasons.", so it seems to have been intended by MZB as one NOVEL, not two. (Also the five chapters are numbered 1-5 / I-V for the OMNIBUSes).

2) The OMNIBUSes don't seem to have the two separate novel titles listed, as can be seen here, here, here (a French edition), and here (a German edition).

Would somebody like to write some commentary on the matter? Thanks in adavance! Stonecreek 09:01, 16 January 2019 (EST)

Performance problems -- 2019-01-17

There is another bad bot sporadically sending hundreds of near-simultaneous queries to the ISFDB server. The pattern of abuse is different, but the end result (slow response time) is the same. Mitigation in progress. Ahasuerus 19:49, 17 January 2019 (EST)

Maybe we could implement a CAPTCHA for queries?--Rkihara 02:42, 18 January 2019 (EST)
I am sorry, I wasn't clear. When I wrote "queries", I meant all kinds of browser requests for random ISFDB URLs: title look-ups, author look-ups, author directory views, attempts to edit random pages and so on.
Unlike the last bot, which was at least trying to do something meaningful (download ISFDB data using Advanced Search), this one was all over the place. It's not clear whether it was a malicious attempt to overwhelm the server or whether the bot operator was particularly inexperienced/incompetent, but the effect was the same. Ahasuerus 11:00, 18 January 2019 (EST)

Art detectives needed

Does anyone recognize any of these covers:

? Or if you do not recognize the image, any ideas of who the artist may be so I know where to start digging? I managed to match 3 of teh covers in the same series, these 2 are getting on my nerves :) And as I will have a lot of those going forward, if you are interested in helping track down covers, let me know and I will ping you personally when I cannot figure out any of them. Thanks in advance! Annie 17:41, 18 January 2019 (EST)

The second one is the same as the first Avon printing of Zelazny’s Trumps of Doom. I’d link it, but I’m posting from my phone. --Ron ~ RtraceTalk 18:28, 18 January 2019 (EST)
I knew I had seen it before! No worries - it needs a note change and all that anyway. All connected. Thanks! Annie 18:55, 18 January 2019 (EST)
Cover1 I found created by Fred Gambino. --Zapp 13:26, 27 January 2019 (EST)

Double novel covers

It came to a discussion on ISFDB:Help_desk. But it should further to be discussed here. Since the books of the series Armchair Fiction Double Novel usually have a second cover artwork on the back, I wanted to know how those ISFDB records could get an unitary and standardized appearance. There is no common sense for this. Are the second cover artworks on the back valid for "Cover2" or "Interiorart"? Do the image titles need to get the particular single novel title or both of them the double title of the book? Looking on the pub titles of this series one can find all variations. So I'm confused. And I got rejected some contributions out of different reasons. --Zapp 13:19, 27 January 2019 (EST)

(copying some parts of the Help Desk discussion:)
I don't think entering cover art as INTERIORART is allowed under the current data entry rules. Help:Screen:NewPub says:
  • Add Cover - If there is more than one COVERART record associated with this publication, use this button to create an additional record. This typically happens when dealing with "dos-a-dos" books.
  • Interior artwork: Works of art published inside the publication are entered into the "Regular Titles" section of the data entry form and typed as INTERIORART. For more information, see INTERIORART. Note: Cover art credit is entered into its own separate section of the data entry form. (Ahasuerus 19:35, 25 January 2019 (EST))
Except that same help page also says "Artwork on the back cover of a publication is treated as interior art" (under Regular Titles, Title, Artwork). So it conflicts with itself. -- JLaTondre (talk) 20:14, 25 January 2019 (EST)

(after sleeping on it) Let me take a step back and provide more background information.

Back when version "2.0" of the ISFDB software was being designed (2003-2005), the "titles" table was set up to support 3 types of art records: COVERART, INTERIORART and BACKCOVERART. The last one is still defined at the database level -- see Schema:titles -- but it's not supported by the software. I don't know/recall why Al, who was the ISFDB developer at the time, chose not to implement BACKCOVERART. If he mentioned his reasons in 2006-2008, I must have forgotten them.

Since we could have only one COVERART title record per publication between 2006 and 2016, the assumption was that "COVERART" always referred to the publication's front cover. The only way to capture background covers was by using the INTERIORART title type. Once the software was changed to support multiple COVERART records, more options became available. It was no longer immediately clear whether COVERART records referred to front cover art or whether they applied to back cover art as well. Hence the current discussion.

I guess at this point we have the following options:

  1. Use the COVERART title type for all works of art that appear on publication covers.
  2. Use the INTERIORART title type for works of art that appear on back covers.
  3. Implement BACKCOVERART as a separate title type. It would be handled just like the COVERART type: multiple BACKCOVERART titles would be supported per publication and multiple artists would be supported per title.

Although it would be possible to add BACKCOVERART to our menagerie, there are a few things to consider. First, it would be fairly time-consuming to do. Second, we would need to decide how to handle various unusual scenarios. Off the top of my head:

  • "Wraparound" covers with the same image used on the front cover, back cover and possibly spine.
  • Publications with multiple covers where it's not clear whether the book has two front covers (dos-a-dos) or a front cover and a back cover.

I suspect that these scenarios would make it difficult to decide what is COVERART vs. BACKCOVERART, so adding support for BACKCOVERART may create more problems than it would solve.

P.S. We may want to move this discussion to the Community Portal since it involves possible software changes as well as Rules and Standards changes. Ahasuerus 14:04, 26 January 2019 (EST)

Zapp's question above is specific to Armchair Fiction Double Novels. The Help Desk discussion was a bit more general.
  • From a general perspective, I don't see a need for a separate BACKCOVERART type. In addition to the issues you mention, what constitutes a front vs back cover for a dos-a-dos? Simply recording multiple COVERART as we have been doing is sufficient. For any odd cases, use pub notes to document.
  • From a Armchair Fiction Double Novels perspective, as a cover case, they are equivalent to dos-a-dos cover. Two separate covers, each illustrating one story, with a unique title and author credit. As such, they should be treated as dos-a-dos. That means: 1) each cover is entered as a separate COVERART record; and 2) each cover is titled to the specific work it's the cover for (the "TITLE / TITLE" of the overall pub is not present in the pubs themselves; they are individually titled).
-- JLaTondre (talk) 14:44, 27 January 2019 (EST)
Except that this will lead to more complications and arguments (see below) and that it was declared to me when I was a beginner here, that the only exception for a second cover entry was the dos-a-dos (back-to-back) binding specific to the Ace doubles. The Armchair Fiction publications don't have that binding; instead, front and back are clearly differentiable. And, as stated in the initial discussion, precedencing this will lead to many, many additionals arguments if art on the back of publication is to be regarded as worthy as cover art: there are numerous cases in which there is only a smaller fraction of the back or a vignette as artwork, accompanied by other information, like blurbs or price information (as with the Armchair pub.s). There's also the difficulty of art on the back of magazines, which should - in my opinion - in no way be regarded as cover art. So, the way it is right now stated in the help (to regard art on the back of publications as interior art), seems the most logical and the most easy path to follow. Stonecreek 02:33, 28 January 2019 (EST)
Double novels (whether bound dos-a-dos or not) are a unique case. They have individual covers for each story with one title and one author on each cover. The only difference from dos-a-dos is the binding. Treating Armchair Fiction Double Novels like we do dos-a-dos is not going to create any more difficulties, exceptions, etc. than dos-a-dos does. They both have the same clear criteria that can be easily written up in the help. That it would somehow open the gates to minor artwork is a red-hearing. -- JLaTondre (talk) 07:34, 28 January 2019 (EST)
No, it clearly is not. This are - in most cases - not double novels; instead these are for the most part ANTHOLOGIES, and many of them that still are indexed as OMNIBUSES have to be reexamined for their contents. The bulk of the texts don't fill the word count of 40,000. So, it is in fact a different case: dos-a-dos does mean the binding is back-to-back. The argument at the time was that there's no way to decide which is the front, and which is the back. That is not the problem we do encounter here. Stonecreek 09:11, 28 January 2019 (EST)
Content is irrelevant. Many dos-a-dos are anthologies & collections. For this question, the only thing that matters is the covers. This and this are significantly (and easily quantifiable) different than this and this. -- JLaTondre (talk) 09:45, 28 January 2019 (EST)

Covers - Definitions

Let me see if we can first agree on the basic definitions. (I will limit the following discussion to paper-bound books and magazines because audio- and e-publications can organize their data in many different ways. Although e-pubs mostly try to emulate traditional physical books, it's due to their readers' current expectations and may change in the future.)

  • Paper-bound books and magazines have two physical covers. They are typically made of paper or cardboard with an optional dust jacket.
  • There are two types of covers: front covers and back covers. Front covers are adjacent to the point where the text in the book begins and back covers are adjacent to the point where the text ends.
  • Most books have one front cover and one back cover. Some books, which we call dos-a-dos, have two front covers because there are two points where text starts.
  • Cover art is a single (sometimes composite) work of art which appears on a cover. It can occupy a part of or all of one cover. It can also appear on both covers, which is known as wraparound cover art.
  • A single cover may have multiple pieces of cover art appear on it, although it's uncommon.

Are we all on the same page so far? Ahasuerus 12:51, 28 January 2019 (EST)

Yes, we are (well, at least I am :-) )
I recommend breaking this discussion up into several sub-discussions. As discussed, the dos-a-dos and Armchair cases are trivial, so let's agree that we want to update (upgrade?) the rules for these cases first. As pointed out by Stonecreek the original rule pertained to dos-a-dos only. This, however, does not imply we'll have to stick to that original rule indefinitely.
Once that one's settled - and the rules updated/clarified accordingly - we can have a go at the other cases that have come up. Whaddyallthink? MagicUnk 13:09, 28 January 2019 (EST)
Me too (on the same level, I mean). As pointed out, the matter is not one of content, but one of binding (JLaTondre brought up the term of double novels). I could live with a rule of exception for the Armchair titles, but I do still fear of a precedence for other publications that have art of any kind on their back. The most dangerous can of worms would be magazines.
On the whole, it has proven to be best for us to keep the number of exceptions as low as possible, and there really is no need to make one in this case. The Armchair Fiction publictions publish normal anthologies that only take advantage of the previous Ace Doubles, but still are quite different from them. Stonecreek 14:14, 28 January 2019 (EST)
Eh, I'm not a 100% clear on what you're saying here; are you implying that Armchair is covered by the dos-a-dos case, so no rules update required? (other than removing the statement that back cover is to be treated as INTERIORART- see above). But then you go on to say that Armchair is quite different from dos-a-dos; which I interpret as the rules need an update for Armchair after all. MagicUnk 11:52, 29 January 2019 (EST)

(unindent) It sounds like there is no desire to add BACKCOVERART as a separate title type, so we just need to decide when to use COVERART and when to use INTERIORART. Ahasuerus 17:27, 30 January 2019 (EST)

I agree that we don't need an additional type for back covers. I'm fine with ordinary back covers being treated as INTERIORART. I'm also fine with dos-a-dos books having two front covers. I do have a couple of other monkey wrenches to throw into the discussion. I have used a second COVERART title to represent the artwork on a slipcase when it differs from that of the cover. I have also used a second COVERART title to represent artwork from the dust-jacket when it differs from that printed on the cover itself. Is this different than how others understand these? --Ron ~ RtraceTalk 18:53, 30 January 2019 (EST)
I would also record a dustjacket and a slipcase as a separate COVERART in these cases with a note on why I have two covers added (and which one is which). Annie 19:06, 30 January 2019 (EST)
Agreed (and there's also the case when multiple earlier artworks are shown on the front of, for example, an OMNIBUS). But, since Armchair Fiction publications are not dos-a-dos, there's no need to make an exception: the back is clearly separable from the front; most pub.s show as a bonus an associated piece of art on their backs, and the publisher chooses wisely which one to show on the front. Considering the art on the back also as cover art only would IMHO lead to endless discussions if a given artwork is to be considered as full-grown cover art or not for other publications. Stonecreek 03:47, 31 January 2019 (EST)
Ah, but here I have to disagree. The Armchair examples given by Zapp are clearly cover art - front and back, so we should record both as cover art in the DB. MagicUnk 07:48, 31 January 2019 (EST)
We could variant the artwork on back even when it is called INTERIORART to the parent cover anyhow. I prefer Stonecreek's point of view since "cover" means usually the front cover not the back. --Zapp 14:04, 31 January 2019 (EST)
No, no, we can't do that. It's not because you -can- do something, that it's also a good idea to do. INTERIORART for COVERART is counterintuitive (not to say its plainly wrong). We have a perfect, easy-to-understand solution, and that is to treat cover art as cover art. What's not to like? [and by the way, I always read my books 'from cover to cover' :)] MagicUnk 14:27, 31 January 2019 (EST)
Sounds like any time there's more than one COVERART, there needs to be a note specifying which cover corresponds to which part of the book (slipcases, jackets, art-in-art, back cover). It addresses the immediate problem and we can monitor the books with more than one to see how it's used. A template to document in the note might make searching the notes easier in case we want to add comments to the publication - coverart relationship in the future. ../Doug H 20:23, 1 February 2019 (EST)
Yes, that to me is a simple solution. One thing though, what would such a template have to convey? Can you come up with a proposal? MagicUnk 14:36, 2 February 2019 (EST)
I'd rather not overthink it. I'd think a word or two three would suffice (e.g. Front, Back, DOS-A, Slipcase). The template would take this value and reiterate it with a wrapper of Cover( ... ). Give it a year or three and we could generate a report to see what people are finding to put in. Standards could be set based on some experience. ../Doug H 20:00, 2 February 2019 (EST)
That's actually a good idea. Could perhaps be a parameterized template or some such. Anyone else? Ahasuerus? Annie? MagicUnk 10:39, 3 February 2019 (EST)
Unfortunately, I am under the weather at the moment and I am not sure I understand the proposal correctly. A new template would be easy enough to add, but what kind of parameters do you have in mind? At the moment Notes templates (unlike Wiki templates) support only one parameter per template. Something like {{MULTICOVER|Front}} or {{MULTICOVER|Back}} is possible, but {{MULTICOVER|Front|12345}} is not. Ahasuerus 14:19, 3 February 2019 (EST)
Could a cover art location template such as {{CALOC | ''phrase''}} be used to reiterate the text phrase, where phrase may be one or more words? For example "Front", "Slip case" and "Art in art". The purpose would be simple to identify references to locations for cover art that could be easily parsed. ../Doug H 14:46, 3 February 2019 (EST)
I think Stonecreek oversimplyfies the present situation stating that 'only Ace doubles' are (to be) entered with two covers. I can think of at least two other publication series (e.g. Tor Doubles) where both artworks are also entered as cover art. In the case of Armchair the back cover artwork is also very much associated with the seond title of the anthology/omnibus/collection.--Dirk P Broer 19:13, 3 February 2019 (EST)

(unindent) I think making it really simple is best. Something like "If there are two covers (such as with dos-a-dos, Ace Doubles, Tor Doubles, and so on), create a second cover art entry by clicking Add Cover to add the second cover." Then for any interior art, something like "Any art appearing between the covers should be entered into the "Regular Titles" section of the data entry form with a Type of INTERIORART." ···日本穣 · 投稿 · Talk to Nihonjoe 23:42, 3 February 2019 (EST)

If my understanding is correct, the main concern with entering all works of art that appear on back covers as COVERART titles is that back cover art is frequently limited to a small picture. I can see how small pictures can be viewed as fundamentally different from regular front cover art.
However, it's been my experience that -- in most cases -- small pictures that appear on back covers are not credited and are rarely entered into the database. Does this match everyone's experience? Ahasuerus 00:24, 4 February 2019 (EST)
Sorry, but no! First, the main concern is not only one for 'minor art' (meaning size), but a general one, and especially extended to magazines:
A smaller sized art is quite often credited or creditable because the art is known.
The magazines are a special can of worms, I'd think, since the back is per definition interior space. And since anthologies / magazines of today are quite often transformed into the other type, we would have to have a third eye on the back of those. Stonecreek 02:29, 4 February 2019 (EST)
Rereading your comments above, I think that the last point may be the root cause of the disagreement. You believe that "the back is per definition interior space". On the other hand, the definitions that I proposed above -- see "Covers -- Definitions" -- suggest that back covers, just like front covers, are exterior rather than interior space. Would you like to expound on why you think that back covers are best classified as interior space? Ahasuerus 10:29, 4 February 2019 (EST)
Well, the rules for magazines state to give the whole page count, regardless of the pagination, so the back is part of the interior per definition. Stonecreek 11:05, 4 February 2019 (EST)
Template:PublicationFields:Pages tells us to count both front covers and back covers:
  • For magazines, the rule is to use the actual page count - including the cover. For example, early issues of Fantastic Universe numbered the interior pages from 1 to 192, not counting the front or back covers. This would be entered into the ISFDB record as "196".
If we were to take it to mean that back covers are "interior", then it would also make front covers "interior", which wouldn't make sense. Ahasuerus 11:36, 4 February 2019 (EST)
I'm afraid I don't know the Tor Doubles, but there seems a need for dealing with them anyway: part of the lot is listed as 'pb', the other one as 'dos'. Which one would be correct? Stonecreek 02:29, 4 February 2019 (EST)
Some Tor Doubles were dos-a-dos and some weren't. To quote SFE3:
  • Towards the end of their existence as a line, Tor Doubles began to appear with the two titles presented sequentially
I have most of them in my collection, but it would take a fair amount of time to dig them up and analyze their evolution. Ahasuerus 10:14, 4 February 2019 (EST)
And thinking back, the reason for the passage of treating backs of publications as interior space can't have been that we formerly had only one field for cover art, since the entry for the Ace Doubles was of the form 'Title 1 / Title 2' by 'Artist A' and 'Artist B'. The good reason for this really must have been the simplifying of decision. Stonecreek 02:29, 4 February 2019 (EST)
I don't remember all the details, but prior to 2016 the software handled COVERART records with multiple artists inconsistently. Depending on how the data was entered/edited, sometimes the software created a single COVERART title with multiple artists and sometimes it created multiple COVERART titles. (Once the software was upgraded, I created a cleanup report to look for potential problems.) In any event, when entering multi-cover publications like Ace Doubles, we just had to pray that things would come out OK. Ahasuerus 09:29, 4 February 2019 (EST)
While the discutants will (hopefully) be informed about the matter, the non-discutants and all the new editors will be not. This way we will have more discussions and corrections on a matter that really is not ISFDB's first concern. We decided at one time to include artwork, but we still aren't the ISADB: our concern is the speculative fiction, and there's a huge lot to with that! Stonecreek 02:29, 4 February 2019 (EST)
And there's some other problem I have encountered: one of the Armchair Fiction publications had the artwork on the back as cover, while the actual cover artwork was not credited, because it was not creditable (the original artwork was known, but uncredited). We would encounter this scenario on a regular basis, and this would pose another can of worms that has nothing to do with our core business! Stonecreek 11:05, 4 February 2019 (EST)
Sorry, but your last arguments are irrelevant to the discussion imo. How we choose to count pages for magazines has nothing to do with how to treat art that appears on the outside of the magazine (aka the covers), and, it is not because it isn't the core business of the isfdb to record coverart that we shouldn't discuss it further. It is also irrelevant that not everyone participates in this discussion, since if it would, not a single change or improvement (to the rules). Could ever be allowed.
Concerning your last remark, I 'm afraid I don't understand the issue. We do allow 'uncredited' art, don't we? MagicUnk 01:41, 5 February 2019 (EST)
You seem to have not read my remarks: the concern is not that we index artworks, but that it's not our core business to waste time on discussing and reviewing them, and that is what invariably would happen. And no, we don't index uncredited cover art, and not necessarily uncredited interior art (that depends on an editor's preference). Stonecreek 04:16, 5 February 2019 (EST)
I beg to differ. We do index artwork, so, it is our business to discuss - either what we're doing now, or when we have to go and lecture an editor he/she's not following the rules. And I do not share your fear we'll be opening endless discussions. In practice, it'll be glaringly obvious what cover art is and what is not. No need to come up with hypothetical worst-case scenarios; no-one is going to add artist information of 'vignettes' appearing on magazine back covers... Again, the way Nihonjoe phrased it above, makes the most sense to me and is understandable to editors.
Sorry, but as a relative newby you really don't seem to know what's possible, and what the amount of clean-up was and is going to be. Indexing artwork is mandatory: this train has left the station long ago, but altering the definition of cover art also would mean to review ALL items that have art on their back, a task that is of no value to our goal. Stonecreek 13:43, 5 February 2019 (EST)
Can you enlighten us and give examples of what review work you are thinking of? As far as I can see the work that needs to be done anyway is to review ace doubles & armchair pubs and clean up the mess that's already there, cfr. Zapp's examples. That would not be additional work, as it needs to be done irrespective: either remove all information related to the back cover for Armchair pubs that you suggest should not be there, or regularize and make sure that there are two COVERART records (for as far as they are credited) and consistently and uniformly applied as per the rules clarification suggested by Nihonjoe below. Either way, work to be done... MagicUnk 14:06, 5 February 2019 (EST)
Quite easy: each piece has to be reviewed if it would be to considered as a worthy 'cover art' or not. Or are you suggesting just a 'lex Armchair Fiction'? Stonecreek 14:22, 5 February 2019 (EST)
Eh, sorry, I have to admit I don't understand what you mean exactly? The vast majority of pubs in the DB are standard novels and the like and don't have problems at all. We're talking about specific cases such as, indeed, the Armchair fiction series, no? Admittedly, reviewing and updating with both cover art records (when available) will take some time but surely not unsurmountable? And doesn't have to be done immediately, right?
And can we actually get an idea of how much records we are actually talking about? Surely less than the current cleanup round going on to get the Bleilers and Reginalds in their won ExternalID field I'd guess? MagicUnk 15:56, 5 February 2019 (EST)
As experience has shown many times it's best to keep the number of exceptions as small as possible. The problems we'd encounter with them have been adressed above, and any unnecessary exception will invariably lead to questions of the kind: "when it's here allowed, why not there?". Stonecreek 02:41, 6 February 2019 (EST)
You're misrepresenting the proposal, I'm afraid. It is actually intended to eliminate exceptions, not create more of them. MagicUnk 06:46, 6 February 2019 (EST)
Concerning uncredited art; that's a valid point you're making - looks like there's an undefined rule, leaving choice to the editor in question whether to add uncredited cover art or not... MagicUnk 13:23, 5 February 2019 (EST)
I thought of a modification, just to make things clear: "If there are two covers (such as with dos-a-dos, Ace Doubles, Tor Doubles, and so on), a second cover art entry can be created by clicking Add Cover to add the second cover. If the back cover is an advertisement (which often happens with magazines, and occasionally with older books), that is not considered cover art and should not be documented." Thoughts? ···日本穣 · 投稿 · Talk to Nihonjoe 13:38, 5 February 2019 (EST)
I'm all for it. Makes perfect sense to me. MagicUnk 14:06, 5 February 2019 (EST)
Your proposal adresses none of the problems that are already there and the ones we're going to encounter. Please make some responsible suggestions how to deal with those! Stonecreek 02:36, 6 February 2019 (EST)
What Nihonjoe proposes is actually to solve the problems that are already there by making it clear what to do when there are two covers with cover art on them. Clearly the mess we're seeing now is caused by inadequacy of the current rules, doesn't it? To be honest, I have yet to read convincing arguments, preferrably supported by factual evidence, that when we update the rules to allow front- and back coverart to be treated equally we inevitably will run into numerous problems. They just aren't there. The magazine case is moot, as it is clear that the 'vignettes'/ advertisements aren't going to be considered as cover art.
Nothing - under the circumstances that there are dos-a-dos publications - can be more easy than the current rule of art-on-the-front-of-a-publication --> cover art; art anywhere else in the publication ---> interior art. If you still think there are no problems coming up then you have to reread the paragraphs above.
Also, something else to keep in mind is that the majority of editors and moderators that have chimed in on this discussion are expressing preference to varying degrees (or are impartial) for updating the rules to unequivocally allow front-and back coverart records both entered as COVERART (and not INTERIORART). After all, why else did Ahasuerus update the software in 2016 to accept multiple COVERART records if not to allow exactly that? MagicUnk 06:46, 6 February 2019 (EST)
Can't you read? This step was to ensure that different pieces of cover art on the front can have their respective own entries. There is no other solution for this problem as easy and elegant as the existing one! Allowing your proposal will lead to unnecessary problems that are already solved (at least in principle) and endless fiddling. The artwork is represented at ISFBD and that's all that is of business to us! Stonecreek 09:39, 6 February 2019 (EST)
I quote: between 2006 and 2016, the assumption was that "COVERART" always referred to the publication's front cover.. 1) it is an assumption, and 2) this definition was only valid between 2006 and 2016. MagicUnk 11:02, 6 February 2019 (EST)
Yes, and the assumption is still correct in 2019, so what? It says something that you don't try to argue with the simplicity of the current rule: in the other cases one would have to define what a genuine cover is made of or what it has to fulfill; what's to do when there's creditable art only on the back? (it would be displayed - totally misleadingly - as the one and only cover art), and so on, and so on. You'd have to think of all dangers and try to figure a way out of them, which would all be futile work. Stonecreek 11:18, 6 February 2019 (EST)
Well, that's where we disagree, obviously. As to your case how do address if there's only backcover art (does that actually exist?); the solution has been suggested somewhere in the text above: use the notes to disambiguate, as we're doing everywhere else we need additional clarification.
Now, all that said, and as we're the only two that keep discussing, I'll propose to put the discussion to an end (for now) since it's obvious we'll not be reaching agreement anytime soon... MagicUnk 11:32, 6 February 2019 (EST)

(unident) Sure it does exist, and shuffling notes around would change nothing for the obvious gap between the displayed cover art (the one that's not creditable) and the text right near it, which would be for a totally different piece. And there are more cases that eventually will pop up: mutltiple artworks on the cover and/or multiple artworks on the back came to mind without stretching my mind. The thing is that - although some things seem to be quite easy & intuitively right - they get rather complicated to define and difficult to maintain in the complex ISFDB environment. Stonecreek 13:43, 6 February 2019 (EST)

Summarizing the Arguments for and against

I have been trying to wrap my brain around all the arguments and counter-arguments, but I don't seem to be making much progress. If I am feeling OK tomorrow, I will try to query the database. It may help us determine what types of cases we are dealing with and what the scope of the problem is. Things like the number of INTERIORART titles whose page number is "bc" and so on. Ahasuerus 00:06, 7 February 2019 (EST)

I'll try to summarize (I'm sure Stoncreek will chime in if I've been incomplete). The question is: do we record cover art that appears on the front and/or back of a publication of any type? Is it allowed per the current rules to do so or not? If it is, how?
Arguments against, voiced by Stonecreek:
  • It is not our core business to index backcoverart, except for dos-a-dos
  • Additional cover art records are currently created as INTERIORART, let's stick to current practice or we'll have to update a whole bunch of pub records
  • If multiple coverart records would be allowed, it would lead to all kinds of questions & discussions. For example:
    • A single cover art picture is uploaded, either showing only one cover or two, and two records exist for front and back; which record refers to which part of the picture? You don't know unless you add notes to clarify.
    • A cover art picture is uploaded showing front-and backcover, and only artist for frontcover is credited (the other one is unknown), so only one coverart record; again to what part of the picture does that record refer to?
    • A back cover (of a magazine) shows small art that is recognizable, the so called 'vignettes', who's to prevent editors from entering a coverart record for each 'vignette'?
    • Allowing back cover art in general would require a massive update of currently existing records, eg the ones that have backcoverart as interiorart --> This is where the question of how many records are we talking about is coming from.
Arguments for, voiced by MagicUnk and other editors:
  • The rules allow it. Nowhere in the rules it says that entering front-and back coverart as COVERART records is forbidden, there is no restriction on pub types mentioned (that I could find), dos-a-dos is mere mentioned as an example, not an exception, where it is relevant to have two records - but there are serveral other cases - eg see Armchair above.
  • Allowing multiple coverart records per pub makes the rules simple and easy to understand (actually the rules already explicitly allow for this - we only have to make them clearer and more explicit that the multi-coverart case is also covered
  • It is very unlikely 'vignettes' will be considered as coverart, and moderators will catch them quickly; and we can add clarification that it this kind of art is not to be entered)
  • Disambiguation has to be done in the notes irrespective - cfr. cases against. Either you add notes to describe front-and back cover, or you use multiple coverart records and notes as needed.
  • There is no definition that restricts COVERART to mean front cover art only
Applicable rules
These are the ones I've found, with relevant excerpts
  • Cover Art
    • If the cover art is credited to more than one artist, use this button to create a second artist field.
    • If there is more than one COVERART record associated with this publication, use this button to create an additional record. This typically happens when dealing with "dos-a-dos" books.
  • Contents always included: interior artwork
    • Note: Cover art credit is entered into its own separate section of the data entry form. If there is a significant reproduction of the cover art inside the publication, it can also be entered as a separate INTERIORART record. That you COULD interpret as "enter backcoverart as interiorart" - but that's really stretching the rules imo., and it really means that for a significant reproduction of the cover you enter an additional INTERIORART record (next to the coverart one).
    • This section has no explicit rules about cover art, except perhaps (but I doubt it) for Rules for including artwork. If artwork illustrates a particular story, it should be included. If it does not, but is a significant piece of artwork, or is signed by or credited to a well known sf artist, then it should be included.
From the preceding discussion it has become clear that further clarification of the rules re. COVERART definition and data entry is in order since there's clearly two different interpretations given to current ruleset. And BTW, I've reread the rules & current discussion carefully, but of course I could have missed something. Let me know if I have. MagicUnk 06:44, 7 February 2019 (EST)
WRONG! The help pages clearly state that it is forbidden to enter art on the back as coverart: I cite what JLaTondre has found and posted somewhere at the beginning of this thread: Except that same help page also says "Artwork on the back cover of a publication is treated as interior art" (under Regular Titles, Title, Artwork).
Don't shout please. That's rude.
Sorry, I didn't want to be rude; it was just that I couldn't believe you had overlooked that prominently featured rule. Stonecreek 11:58, 8 February 2019 (EST)
Somehow I missed that piece of text that you pointed out. It must be removed as it is inconsistent with all the other helptext. MagicUnk 15:14, 7 February 2019 (EST)
We are now in a situation where it is quite easy to deal with the title types COVERART & INTERIORART, and this is precisely because of this rule. It seems most likely that it was written down because someone thought of the difficulties we would get into otherwise. We have encountered publications where the COVERART is not creditable. Allowing the art on the back also as COVERART will lead to the absurd situation that the title of the then 'cover artwork' has nothing to do with the displayed cover image (including the artist). Also we will encounter the situation where there are multiple artworks displayed on the front and/or the back, which will only lead to more confusion. Stonecreek 09:37, 7 February 2019 (EST)
I propose a couple things:
  1. Change the rule mentioned by Stonecreek so that coverart is never treated as interior art. It's counterintuitive and will only continue to confuse people in the future.
  2. Add some way to mark a COVERART entry as the back cover. This could be a checkbox next to it that makes it display as "Back Cover Art", or adding a BACKCOVERART type that does the same thing.
This will alleviate the "absurd situation" Stonecreek mentions. As for the situation where multiple artworks are used on a front cover, those are fairly rare, and can already be handled by adding additional artists for whichever cover. So, if you have a front cover that has art by both Michael Whelan and Bob Eggleton, you simply have both artists listed on the single entry since we treat each cover as a single work. ···日本穣 · 投稿 · Talk to Nihonjoe 14:07, 7 February 2019 (EST)
Hmmm. Makes me think a checkbox wouldn't be needed as disambiguation by appending either '(front)' or '(back)' would work equally well. MagicUnk 15:28, 7 February 2019 (EST)
We'd only need "(back)" because the default assumption is that it's the front cover. ···日本穣 · 投稿 · Talk to Nihonjoe 16:19, 7 February 2019 (EST)

(unindent) So how about this:

  • For COVERART: "If there are two covers (such as with dos-a-dos, Ace Doubles, Tor Doubles, works with back cover art by a different artist than the front cover, and so on), a second cover art entry should be created by clicking Add Cover to add the second cover. If the back cover art is a wraparound work (meaning the front cover picture wraps around to the back cover), do not create a separate back cover entry. If a front or back cover has art from multiple artists or the art was collaboratively created by more than one artist, click Add Artist to add an additional artist for the cover. If needed, add a note to the Pub. Note field to clarify which entry is the back cover. If the back cover is an advertisement (which often happens with magazines, and occasionally with older books), that is not considered cover art and should not be documented."
  • For INTERIORART: "Any art appearing between the covers should be entered into the "Regular Titles" section of the data entry form with a Type of INTERIORART."

I tried to address the concerns expressed by Stonecreek. Hopefully, I did so. Thoughts? ···日本穣 · 投稿 · Talk to Nihonjoe 17:18, 7 February 2019 (EST)

With the addition of not allowing uncredited COVERART, it nicely summarizes the proposal. Thanks. MagicUnk 01:18, 8 February 2019 (EST)
I'd think it is really vice versa: COVERART does mean the art on the front: it is the one displayed in bookstores of any kind (and it's also here at ISFBD in very most cases); the art on the back always is a gimmick on the plus side, just the way it is with INTERIORART.
And I'm afraid that your proposal does in no way deal with the problem of 'minor' art (small size, art somewhat hidden under the cover blurb or price/EAN information (like here, etc.). Stonecreek 04:09, 8 February 2019 (EST)
Why would it be a problem to have two COVERART records that refer to the same art? In these cases we simply variant the back to the front. Or we explicitly add " not create a COVERART record for the back cover if it is a variant of the front cover art" if we really don't want these cases recorded. MagicUnk 06:46, 8 February 2019 (EST)
That wasn't an example for a doubled piece of coverart (though that would be pretty useless), it should emphasize an example for 'minor' art.
I think I understand. Let's review what we mean by COVERART. I believe that when you refer to 'minor' art appearing on the cover you focus on the individual pieces of art that together make up the cover art, right?
Whereas you can also look at COVERART from the whole, and not the individual parts. Now, for the sake of argument, we can record a composite cover (ie a cover composed of individual pieces) in two ways:
1) have a single art record with multiple artists, ie referring to the whole and listing contributing artists, or
2) have multiple art records with a single artist, ie each record referring to the individual parts.
Do you refer to the second case when you point out the issues with multiple art or other types of composite art covers? MagicUnk 12:26, 8 February 2019 (EST)
The proposal also still doesn't explicitly distinguish the publications the rule is thought for (all with art on the back, also magazines, even pamphlets?) Stonecreek 11:58, 8 February 2019 (EST)
And the rule Artwork on the back cover of a publication is treated as interior art is not 'inconsistent with all the other helptext' as you stated above. What gave you this idea? Stonecreek 00:01, 9 February 2019 (EST)
Well, Cover Art says it is allowed to enter multiple coverart records (and merely refers to dos-a-dos as an example). It is clear that there are other cases where multiple cover art records are relevant, including the case that started all this, namely Armchair. So, back cover art as we're currently discussing is imo included and can be treated as a second coverart record as per this rule. Then, indeed, the rules go on to say that backcoverart is to be treated as interiorart. That, to me, seems an inconsistency in the rules. (PS. could you provide an answer to my question above concerning 'minor' art whether I've understood what you're saying?) MagicUnk 08:45, 9 February 2019 (EST)
No! The rule just clarifies that art on the back of a publication is treated as interior art (like with Armchair Doubles), but when you have two fronts (like with Ace Doubles or in the case of dustjackets & corpus of a publication both bearing art) then it is allowed to add a second COVERART title). That's really the most easy & elegant solution. I really'd like to see another relevant site that treats or announces the art on the back of a publication as COVERART. (Even the rules you found mention This typically happens when dealing with "dos-a-dos" books., because it is the most common & relevant case.) Stonecreek 23:55, 9 February 2019 (EST)
I'm beginning to suspect that we are more or less saying the same (but not quite). Let's first discuss definitions - see below. MagicUnk 06:46, 10 February 2019 (EST)

What Is Currently in the Database

Thanks for trying to summarize the arguments! I have run a few queries and here is the current breakdown of titles that appear on the back cover of a publication and are entered as "bc":

  • 79 ESSAY
  • 45 POEM

There are no COVERART titles. It doesn't address the issue of Help inconsistencies, but at least now we know what the current scope of the problem is. Ahasuerus 14:10, 7 February 2019 (EST)

There will be more records that'll need attention though, such as Armchair records that could be revisited to improve data quality, which can be done gradually over time. Note the 'could' as I don't want to imply a 'must'.
What must be done though is to remove the helptext inconsistencies, either way. MagicUnk 15:14, 7 February 2019 (EST)

An Alternative Software-Based Approach

Now that I have read all the arguments and reviewed the data, it occurs to me that there may a different way to approach this issue. Let's take a step back and consider why the New/Edit/Add/Clone Publication pages have a separate "Cover Art" section. The reason is that we capture different data elements when creating COVERART titles vs. regular types of titles, including INTERIORART titles.

First, the following fields -- "Title", "Date", "Title Type" and "Length" -- are not displayed when creating a NEW publication or editing a publication without a COVERART title. A new COVERART title record automagically uses the title and the date of the publication. It's just a data entry shortcut because the resulting COVERART records end up with the same fields as INTERIORART title records: Title, Artist(s), Date and Title Type.

The second difference, however, is more fundamental. The "Cover Artist" section doesn't have a "Page" field because the original assumption was that COVERART titles would always appear on the front cover and because we didn't consider other scenarios like separate dust jacket or slipcase art. The result is that, because we don't capture page numbers for COVERART titles, there is no easy to way to distinguish between the art that appears on:

  • front cover
  • dust jacket
  • slipcase
  • back cover
  • wraparound cover

Hence the need to use Notes and the various proposals above to add support for "back cover" checkmarks, a new BACKCOVERART title type, etc.

On the other hand, INTERIORART is a regular title type which is entered in the "Regular Title" section, so it can have page numbers associated with it. That's what makes INTERIORART so attractive when deciding how to enter art records -- it lets you easily capture the art work's location, including "bc" for "back cover".

Now then. If we were to add a "Page" field to the "Cover Art" section, it would address a whole bunch of issues. If left empty, there would be no changes to the way the "Cover" line appears on Publication pages. For dos-a-dos publications, we could add a code like "afc" which would then be displayed as "alternate front cover" on the "Cover" line. Ditto "dj" for "dust jacket", "slip" for "slipcase", "wrap" for "wraparound cover" and "bc" for "back cover". It would take some work, but nothing insurmountable.

So, what do you think? Ahasuerus 17:31, 7 February 2019 (EST)

I have an objection to treating back cover illustrations as COVERART. The current rules disallow COVERART when the artist cannot be identified. Changing this has been discussed before and the consensus was to not enter uncredited COVERART. I don't know how many of the 1170 INTERIORART bc records are uncredited, but by our rules, this conversion would necessitate their deletion. This could include other artwork that appears on the back covers of magazines that is reflected with the actual page number rather than "bc". Aside from the expansion of COVERART to include back covers, I support this software approach. --Ron ~ RtraceTalk 19:27, 7 February 2019 (EST)
I guess you mean to say you don't support back cover illustrations as uncredited INTERIORART? But you do support back COVERART if they are credited? If so, that can/should be added to Nihonjoe's proposed wording, as he mentions below. MagicUnk 01:11, 8 February 2019 (EST)
No, uncredited INTERIORART which occurs on the back cover, is legitimate today. I don't want to decrease the scope of what can be entered and I especially don't want to delete data that has already been entered. --Ron ~ RtraceTalk 02:31, 8 February 2019 (EST)
Right... why wouldn't we remove obsolete and/or inconsistent data? On one hand we argue that we don't want to record coverart that's uncredited. But then we go on to say that it's fine to record coverart that's uncredited as long as its an interiorart record?
Because, the illustrations on back covers which are entered as INTERIORART are not currently obsolete nor inconsistent. They would be made so only As a side affect of this proposal, wiping out decades of data entry. Is there an argument that these titles that have been legitimately added now should be prohibited based solely on location? --Ron ~ RtraceTalk 07:42, 8 February 2019 (EST)
Now, there's another solution to the coverart-as-interiorart-credited-to-uncredited, and that is to allow uncredited coverart records and then move the interiorart uncredited ones to their proper place in the DB. MagicUnk 07:00, 8 February 2019 (EST)
I would support allowing uncredited COVERART to be included. However, it has been litigated before and the consensus was not to do so.--Ron ~ RtraceTalk 07:42, 8 February 2019 (EST)
Well, situations change and I wouldn't mind reverting that earlier decision and start including uncredited coverart. It then of course begs the question what were the criteria of the editors to include or not include uncredited coverart as INTERIORART? We could add all uncredited coverart, but I don't think that'd be a good idea, so what were/are the particular criteria editors use(d) to decide whether to do so or not? Now, for me, what's important is that we can come up with a rock-solid rule that is simple, elegant and has as few exceptions as possible (preferably none at all). MagicUnk 08:36, 8 February 2019 (EST)
I don't support adding back cover art (or front cover art) if we can't identify the artist, and none of my suggestions included that. We don't generally enter INTERIORART if we don't know who the artist is, either. I do, however, find it confusing and unintuitive to enter art found on the cover as INTERIORART. Perhaps if we changed INTERIORART to ILLUSTRATION instead? ···日本穣 · 投稿 · Talk to Nihonjoe 20:37, 7 February 2019 (EST)
We have 11,833 INTERIORART titles with the author as uncredited. It's always been my understanding that this is permissible. --Ron ~ RtraceTalk 21:00, 7 February 2019 (EST)
Sure. It is permissible because it conveys there is contents on a particular page that is art, not text. I would not generally enter uncredited interiorart myself, but I would add a clarifying note. MagicUnk 01:31, 8 February 2019 (EST)
Regarding what to enter for the type of INTERIORART, perhaps add a drop-down (like the one for story length) with the options you mention:
  • front cover
  • dust jacket
  • slipcase
  • back cover
  • wraparound cover
That way, a new editor (or one just unfamiliar with thing) wouldn't have to try to figure out what abbreviation to use. ···日本穣 · 投稿 · Talk to Nihonjoe 20:40, 7 February 2019 (EST)
I propose to first determine what we want and only then to discuss best way to implement. That said, treating COVERART data entry mechanisms much the same way as INTERIORART does has its merits, provided they do not stánd in the way of rules implementation as suggested by Nihonjoe (including the rule to not allow uncredited coverart). By the way, not allowing uncredited COVERART makes perfect sense to me since it wouldn't convey any additional useful iinformation in my opinion. MagicUnk 01:11, 8 February 2019 (EST)
One question regarding the idea of not allowing uncredited COVERART - would this mean I couldn't upload a cover image if I didn't know who had produced it? ../Doug H 11:03, 9 February 2019 (EST)
I don't think so. COVERART records are titles. Cover scan URLs are fields in publication records. Multiple editions of the same book can share the same COVERART title (i.e. art) yet have slightly different cover scans due to different prices, blurbs and so on. At this time we can and do upload cover scans regardless of whether we know who the artist is. Ahasuerus 14:33, 9 February 2019 (EST)


Apologies for starting another section, but I couldn't figure out where to put some random thoughts in the various sub-threads above. --MartyD 09:00, 9 February 2019 (EST)

I don't have any strong feelings about this, but I think we're missing a key consideration, which in my software product development world would be "user requirements". The arguments above seem to be focusing on how best to describe the publication and its full complement of artwork but do not seem to be considering how that information will be used. If the ISFDB is meant as a public bibliographic resource, then we should identify how the non-ISFDB bibliographic world thinks about publication artwork. For example, to my layman's eye (I am definitely not a bibliographic expert), it seems to me there is a somewhat universal concept of "cover" and "cover artist" that, when used in non-ISFDB places, is restricted in scope to the front/"main" cover (which might be the dust jacket). So to support non-ISFDB bibliographers using the ISFDB as a resource, I see these requirements:

  • Provide a way to identify the artist(s) for the front cover
  • Provide a way to find front covers (or publications having front covers) by an artist
  • Distinguish an artist's front cover works from any other works by the artist
  • Identify, and distinguish among, multiple possibilities for "front" cover (e.g., dos-a-dos, dust jacket vs. physical front cover beneath the jacket)

Perhaps there are some more. (One thing that occurs to me to ask: Is there any standard/common bibliographic need for doing anything in the list above with a "back cover" context? I sort of doubt it, but I am definitely not an expert.) So how do we do that, and how do we do it in a way that is most natural for ISFDB users to work with?

I think we're a little hung up on the literal meanings of "COVER" in COVERart and "INTERIOR" in INTERIORart. COVER might mean front/main or might mean the entire physical wrapping (front and back). INTERIOR sure sounds like it means "inside", which in the vernacular would be "between the covers", in which case it is counter-intuitive to apply that term to artwork on the exterior. I.e., if our terms were FRONTCOVERART and OTHERART, would we be having such an extensive debate? Yes, there are still some tricky nuances, but perhaps by considering each situation in terms of: "Ok, it's not what an ordinary person would think of as the front cover, so how should we document what it is and where it is?" we might be able to come up with something, and we could probably have some clear treatments for, and explanations of, the few ambiguous situations that remain. --MartyD 09:00, 9 February 2019 (EST)

You're making a very good point there. Along the way I have come to realize that we may not be talking about the same thing - indeed, what's the definition of COVERART? And what definition is the ISFDB using?
Is it art located on
  1. the front cover, and only the front cover? If it is, we then need to answer questions like: 'Can a pub have two front covers, and consequently no back cover'? (see dos-a-dos (two front?) vs. Armchair (front - and back?). What with dust jacket? etc etc., or,
  2. the exterior of the pub, irrespective of whether it's the front, back, slipcase, etc...
And does it mean
  1. to reference the whole only, ie meaning a composite cover treated as a single piece of art that can have multiple artists credited? or,
  2. we treat the individual pieces as individually distinct pieces of cover art each with their own artist credit?
Defining cover art as meaning front cover only seems to be too narrow to me, and consequently requires explanation of exceptions such as dos-a-dos, dust jacket,... Defining cover art as meaning appearing on the front and/or back, and treated as a single piece (even when composed of multiple art) makes the most sense to me - and I suspect that that is also what our customers would expect as well. It would still require clarification re dos-a-dos, dust jacket... Of course, if we take these as requirements (or another set), then the detailed specifications and subsequent implementation still needs to be fleshed out... MagicUnk 11:23, 9 February 2019 (EST)
An interesting angle. Another way to put it is that we currently segregate art titles into two categories:
  • "Privileged" art titles which appear at the top of the Publication page. At this time they are called COVERART titles and are displayed on the "Cover" line.
  • All other art titles which appear in the Contents section of the page. At this time we call them INTERIORART titles and they are displayed slightly differently compared to non-art titles.
So I guess the first question to answer is whether the rest of the bibliographic world draws the line between different types of art pieces in the (substantially) same way even though the terminology may be somewhat different. Ahasuerus 14:26, 9 February 2019 (EST)

Definitions - Redux

  • Cover: Definition from Wikipedia: A book cover is any protective covering used to bind together the pages of a book. Beyond the familiar distinction between hardcovers and paperbacks, there are further alternatives and additions, such as dust jackets, ring-binding, and older forms such as the nineteenth-century "paper-boards" and the traditional types of hand-binding. The term "Bookcover" is often used for a book cover image in library management software.
  • Cover art: From Wikipedia: Cover art is a type of artwork presented as an illustration or photograph on the outside of a published product such as a book (often on a dust jacket), magazine, newspaper (tabloid), comic book, video game (box art), DVD, CD, videotape, or music album (album art).
  • Front cover: No definition found online, but workable definition can be: The cover that is closest to the start of the text when you begin reading a publication.
  • Back cover: The cover closest to the end of the text when reading a publication

From these definitions it is inferred that

  • A publication can have multiple covers at the same time (front, back, dustjacket,...).
  • Any art on the covers of a publication is cover art.
  • A publication can have two front covers, and no back cover - a workable definition to capture dos-a-dos type books could be if you have to flip a pub upside down to be able to read all of its contents, that pub has two front covers (might not be all that accurate, but you get the gist, I hope :))

These are the definitions that our customers most likely will have in their mind when looking for specific information related to cover art. So, can we come up with user requirements and rules that are in line with the definitions as listed above? MagicUnk 07:42, 10 February 2019 (EST)

That there's no differentiation to be found can be interpreted either way, it's just as reasonable that by 'cover' the term 'front cover' is meant implicitly. Our closest associates for bibliographic purposes would be SFE3 (and its offspring, the Fantasy Encyclopedia) and, also, Wikipedia. The latter only seldomly credits or depicts covers, the first regularly names artists for first editions, but when they do, all of them speak only of front covers. Also comic dbs name the artist of the art on the front cover. So, where are the examples of major bibliographies that would do otherwise? Stonecreek 10:13, 10 February 2019 (EST)

"Percent of Publications by Format by Year" updated

The statistical report "Percent of Publications by Format by Year" has been updated. It now displays two graphs, one for magazines/fanzines and one for books. The new layout will become available tomorrow morning. Ahasuerus 17:25, 30 January 2019 (EST)

I don't see Green-hc (have only red, orange, black, yellow)? I'm using chrome. MagicUnk 07:51, 31 January 2019 (EST)
And I don't see Blue-digest on the magazine graph either (an issue with first graph not displayed?) MagicUnk 07:53, 31 January 2019 (EST)
Could you please do a full page reload (Control-F5 in most browsers)? I added new CSS colors and it's possible that your browser is still using the previous version of the CSS file. Ahasuerus 13:58, 31 January 2019 (EST)
Unfortunately, ctrl-F5 didn't do the trick. Andeh, it's not only Chrome, but IE11 and Edge as well. MagicUnk 14:24, 31 January 2019 (EST)
Logout, look at it while not logged in and login again (or clean your browser data I guess - the out/in was faster) - that's what got the green to show up for me. No amount of Ctrl+F5 did anything :) Annie 14:32, 31 January 2019 (EST)
Thanks for experimenting and sorry about the aggravation. Unfortunately, I find it hard to test color-coded graphs because I am colorblind. Perhaps I should use different varieties of dotted lines in addition to colors to make life easier for me and the colorblind part of our user base. Ahasuerus 15:39, 31 January 2019 (EST)
The pink and yellow is hard to see against the white background. I don't see the blue in digest/magazines either. Did a reload in both Safari and Firefox.--Rkihara 16:40, 31 January 2019 (EST)
The Blue in magazines is indeed missing but we have two greens - one across the whole period (look at the spike in the 20s - webzines cannot even exist that early) and a second one starting in the late 90s and staying low there (they actually even cross a little after 2000). I think that the big green in magazines should be blue. Annie 16:48, 31 January 2019 (EST)
Thanks, I'll take a look. (It's really hard to test this stuff since I can't tell them apart :-( ) Ahasuerus 18:46, 31 January 2019 (EST)

(unindent) I believe I have found and zapped the bug. Could you please do a full page reload and let me know if it looks better? Ahasuerus 19:08, 31 January 2019 (EST)

And we have blue :) Looks good now. Annie 19:23, 31 January 2019 (EST)
Great, thanks! Ahasuerus 19:24, 31 January 2019 (EST)

Advanced Search revisited

With the latest tranche of Fixer-identified ISBNs out of the way, I am back to working on Advanced Search.

The first patch was installed a few minutes ago. It made a number of internal changes which should't be visible to the naked eye. If you encounter any problems, please post here. Ahasuerus 18:13, 1 February 2019 (EST)

Part 2 has been installed. The changes include:
  • Each search types has a separate Web page now
  • Asterisks are now fully supported as wild cards (except User search which requires an exact match)
  • User name searches are now case-insensitive; the downside is that they take longer because of the way the Wiki software (which we have little control over) works
It was a fairly big patch. Depending on your browser, you may need to do a full page reload (Control-F5 in most browsers) for the drop-down lists to work correctly. If you run into any issues, please post here. Ahasuerus 20:12, 2 February 2019 (EST)
Thanks very much for that load of work! It took only a short time to adapt, but now it appears to me much more user-friendly! Stonecreek 12:02, 4 February 2019 (EST)
Excellent! :) Ahasuerus 12:24, 4 February 2019 (EST)
Awesome! ···日本穣 · 投稿 · Talk to Nihonjoe 16:44, 4 February 2019 (EST)

New Web page - Numeric External Identifier Ranges

As we discussed a couple of months ago, it would be nice to be able to see the gaps in our coverage of the Bleiler/Reginald IDs. I have created a new Web page, Numeric External Identifier Ranges, which display tables with currently entered ranges for the 3 supported Bleilers and the 2 Reginalds. A link has been added to the bottom of the Cleanup Reports menu.

I am not sure the current layout is optimal. Perhaps it would be better to display one External ID Type/secondary verification source per Web page. Let's give it a day or two and see what we all think. Ahasuerus 20:31, 4 February 2019 (EST)

Thanks for this. I've already discovered and corrected several errors. --Ron ~ RtraceTalk 21:15, 4 February 2019 (EST)
I actually like it as it is - it is not too much data for a single page. Most of the others won't have ranges anyway so we won't be adding more of those pages all the time. :) Annie 13:03, 5 February 2019 (EST)
Well, if it works, it works :-)
In the meantime I have improved the display a bit and made the data retrieval logic ignore alphanumeric IDs. The latter may make Reginald-3 ranges a bit more manageable. Even so, I suspect that Reginald-3 IDs will be difficult to represent as numeric ranges because of the way records are numbered. I guess time will tell. Ahasuerus 18:24, 7 February 2019 (EST)

Forgotten Worlds (Scotland)

I have a book in hand which has stories that are credited as being first published in "Forgotten Worlds (Scotland)". Issues 3 and 8. Anyone ever heard of it? We have nothing and Google searches find the Japanese game and the Forgotten Realm books. ../Doug H 17:41, 8 February 2019 (EST)

Might be this. Seems to be defunct. ···日本穣 · 投稿 · Talk to Nihonjoe 18:36, 8 February 2019 (EST)
In the meantime, go ahead and enter the stories. We can merge them later if we find info on the magazine. ···日本穣 · 投稿 · Talk to Nihonjoe 18:55, 8 February 2019 (EST)
Galactic Central appears to have a skeleton record for it. It's not in FictionMags nor Miller/Contento. --Ron ~ RtraceTalk 19:26, 8 February 2019 (EST)
I found some info and added these issues. I'm also checking with a few friends in the UK fandom scene who may know about it. ···日本穣 · 投稿 · Talk to Nihonjoe 19:39, 8 February 2019 (EST)
The issues and stories I was looking for were included in your assistance. Now I can link them up and get rid of the book. ../Doug H 19:48, 8 February 2019 (EST)
Okay, I found information on all nine issues and added it. ···日本穣 · 投稿 · Talk to Nihonjoe 20:22, 8 February 2019 (EST)
If there is someone in the UK who can visit the British Library, they have all nine issues in their collection. They are in "General Reference Collection ; ZK.9.a.10066". We are still need verification of the months in which they were published (I extrapolated based on information from one issue) and who edited each volume. ···日本穣 · 投稿 · Talk to Nihonjoe 15:28, 10 February 2019 (EST)

Multi-Series and Multi-PubSeries templates

Back in October we added two linking templates: "S" for regular/title series and "PubS" for publication series. We also discussed adding two more templates, one for multi-series titles ("MultiS") and one for multi-pubseries publications ("MultiPubS".) The discussion petered out because we couldn't decide what kinds of parameters the proposed templates should take.

Perhaps a tentative solution would involve the creation of 2 "Multi" templates without parameters. They would simply expand to something like:

  • MultiS: "Note that this title belongs to multiple series. Because of software limitations, only one of them currently appears in the Series field."
  • MultiPubS: "Note that this publication belongs to multiple publication series. Because of software limitations, only one of them currently appears in the Publication Series field."

If and when we add support for multiple series/pub. series, we should be able to search Notes for these templates and update the data. In the meantime we could use these templates in conjunction with "S" and "PubS", which support linking. Something like:

  • {{MultiS}} The other series is {{S|A Modern Witch}} (volume 4).

which will expand to:

  • Note that this title belongs to multiple series. Because of software limitations, only one of them currently appears in the Series field. The other series is A Modern Witch (volume 4).

What do you think? Ahasuerus 14:06, 9 February 2019 (EST)

Seems like a good way to handle them until the functionality is added to the database. ···日本穣 · 投稿 · Talk to Nihonjoe 12:16, 11 February 2019 (EST)
FR 1262 has been created and the functionality has been implemented -- see Servant of the Shard for an example. Ahasuerus 13:11, 16 February 2019 (EST)

New Advanced Search options

ISFDB Advanced Search has been updated to include ISFDB Advanced Publisher Search. The new functionality is similar to what is supported by the other record types.

Also, please note that the URL of the main Advanced Search page has been changed from to . If you have it bookmarked, you will want to re-point the bookmark to the new URL. Ahasuerus 15:49, 9 February 2019 (EST)

Advanced Publication Series Search has been added to the menagerie. Ahasuerus 17:13, 9 February 2019 (EST)
Advanced Series Search has been added. Ahasuerus 19:31, 9 February 2019 (EST)
Advanced Award Type Search has been added. Ahasuerus 19:51, 10 February 2019 (EST)
Advanced Award Category Search has been added. Ahasuerus 12:51, 11 February 2019 (EST)
Has one of the new Award search changes perhaps caused problems with the Award Directory link. I'm getting a Python script error using Firefox. I can provide more details if you are unable to recreate. Thanks. --Ron ~ RtraceTalk 18:59, 11 February 2019 (EST)
Oops! Let me see if I can fix it real quick... Ahasuerus 22:19, 11 February 2019 (EST)
OK, I think I got it. Sorry about that. Ahasuerus 22:46, 11 February 2019 (EST)

(unindent) Advanced Award Search has been implemented. You can't specify "Award Level" at this time, but I hope to add it shortly. Ahasuerus 20:36, 12 February 2019 (EST)

"Award Level" has been added. Nominations are a bit clunky, but there isn't much I can do about it because they are stored as "9"s in the database. Ahasuerus 15:49, 13 February 2019 (EST)
The Advanced Award Search results table has been modified to display award authors when available.
At this point the redesign of the Advanced Search is mostly finished. I plan to make a few quality of life enhancements and fix a bunch of bugs related to the way AND and OR work with Notes and third party URLs, but the main functionality is in place. How does it look? Anything you would like to see adjusted or changed? Ahasuerus 16:26, 14 February 2019 (EST)

(unindent) As per FR 1229, "Language of an Included Title (list)" and "Language of an Included Title (free form)" have been added to the Advanced Publication Search. Ahasuerus 14:08, 16 February 2019 (EST)

"Title Type" has been added to the Advanced Award Search page. Ahasuerus 18:55, 18 February 2019 (EST)
"Title (for title-based awards)" has been added to the Advanced Award Search page. Ahasuerus 18:55, 18 February 2019 (EST)

A. Williams / Arthur F. Williams

I've seen an enquiry on Facebook questioning our bibliography for the Astounding artist A. Williams, stating that it is possibly incorrectly shared with the British fanzine artist Arthur F. Williams of the same period and whose bio at Fancyclopedia makes no mention of providing art for Astounding. Is it possible they are two different artists, and can any editor shed any light? Thanks. PeteYoung 02:03, 15 February 2019 (EST)

I poked around earlier today, but couldn't find anything definitive. However, it looks like Arthur F. Williams was very active in fandom ca. 1940. Perhaps some digitized fanzine articles from that era may mention his Astounding work -- assuming it was him. Ahasuerus 20:19, 15 February 2019 (EST)

Award Category enhancement

The "category" column in the table that displays awards for an author/title/advanced search request has been enhanced. It used to link to the "Award Category" page which displays all awards for one category, which can get overwhelming for certain award categories, e.g. many Locus categories. It now links to a new Web page which displays all wins and nominations for one year.

For example, if you access John Brunner's The Squares of the City, the "Awards" table will tell you that it was a Hugo finalists in 1966. If you click the "Best Novel" link in the "Category" column, it will take you to Award Category: 1966 Best Novel (Hugo Award), which displays the 5 novels which were nominated for the Hugo award in the Best Novel category. The page is linked to the main Award Type page for Hugos as well as to the full award category page. Ahasuerus 18:45, 15 February 2019 (EST)

A different multiple COVERART question

Hopefully a simple one. This is based on some 19th Century volumes, so how it extends to today may not be relevant. If a book is published with different coloured covers, would it be reasonable to record a single publication with multiple COVERART entries? It might if you could associate a different image with each, but I don't think that's how it works. ../Doug H 09:29, 16 February 2019 (EST)

We have come across this scenario before. For example, the first edition of Patrick Rothfuss' 2007 name The Name of the Wind had two different dust jackets. One had the full version of Donato Giancola's painting while the other used a small portion of the painting as the cover image. We entered them as two different publication records.
One reason to create separate publication records for books with differently colored covers is that the color may have additional meaning. For example, to quote this record:
  • Four-hundred and thirty-three copies have been prepared ... Six copies, bound in red leather, not offered for sale. Twenty-eight copies, bound in blue leather of which twenty-six have been lettered A through Z ... One-hundred copies, bound in blue cloth and numbered ...
Ahasuerus 09:58, 16 February 2019 (EST)

Awards revamped

The software that handles awards behind the scenes has been revamped. The changes were internal and shouldn't have affected what is displayed on any Web pages -- or at least that was the idea. Please let me know if you run into any bugs. Ahasuerus 20:36, 16 February 2019 (EST)

Publication series enhancements

"Publication Series" pages have been enhanced to display their contents faster. Long pub series pages like Perry Rhodan and Ace Double should take significantly less time to load. Ahasuerus 19:39, 23 February 2019 (EST)

Improving casual users' experience

(copied from my Talk page)

Most users would start with the home page. Once they get there, they have to wade through a lot of choices in small print that are useful only to editors. Enlarging the text in links, expanding the search capabilities and moving the links that are useful only to editors elsewhere or make them visible only to editors, would be a big help, IMHO, to casual users.-Rkihara 11:58, 26 February 2019 (EST)

It would be easy to restrict editing links to loged-in users. I should note, however, that displaying editing links for anonymous users was -- back at the dawn of time -- a conscious decision. The idea was that a casual user would see them, realize that he or she could help improve the data and click one of the links. The software would then tell the user that s/he needs to create an ISFDB account and things would develop from there.
Perhaps we overthought it. Another way to accomplish the same goal without displaying a bunch of irrelevant links would be to modify the message that anonymous users see at the top of each page. Currently it reads:
  • You are not logged in. If you create a free account and sign in, you will be able to customize what is displayed.
If we were to add "and edit the data" to the end of the message, we should be able to remove editing links for anonymous users without losing functionality. Ahasuerus 13:03, 26 February 2019 (EST)
I think that would be a good change. ···日本穣 · 投稿 · Talk to Nihonjoe 15:20, 26 February 2019 (EST)
FR 1283, Do not display editing links unless the user is logged in, has been created. Ahasuerus 13:45, 24 May 2019 (EDT)

Performance issues -- 2019-02-27

As some of you may have noticed, the server was slow for about 10-15 minutes earlier this morning. The slowness was due to an apparent attack by a "botnet", i.e. a network of robots programmed to do malicious things. It's not clear whether they were trying to overwhelm the site with an excessive number of connections or whether they were probing it for security vulnerabilities, but they appear to be gone now. There was a somewhat similar incident a few days ago when a robot was probing the site looking for security vulnerabilities. Ahasuerus 12:01, 27 February 2019 (EST)

The botnet is back. It must have taken a quick break to munch on electronic cookies. Ahasuerus 12:04, 27 February 2019 (EST)
And it's back yet again. Ahasuerus 16:02, 3 March 2019 (EST)

Server downtime - 2019-03-07

The server will be brought down for maintenance at 2pm server time (North American Eastern Standard Time). I expect it to be back up by 2:15pm. The downtime will be used to improve performance and to add support for transliterated series names. Ahasuerus 13:16, 7 March 2019 (EST)

The server is back up; patch notes to follow shortly. Ahasuerus 14:18, 7 March 2019 (EST)

Transliterated series names

The software has been modified to support transliterated series names. The new multi-field is very similar to the other "transliterated" multi-fields that we have had for the last few years -- see Help:Screen:EditSeries for details.

A new cleanup report has been deployed. The data will become available overnight. I plan to create additional language-specific cleanup reports to look for non-Latin series with Latin names. For example, the Japanese series Sword Art Online: Progressive presumably needs to have its Japanese name added. Ahasuerus 14:35, 7 March 2019 (EST)

Language-specific cleanup reports have been deployed. The data will become available tomorrow morning. I expect that around 100 Cyrillic series and approximately 300-400 Japanese series will require attention. Ahasuerus 18:03, 7 March 2019 (EST)
Awesome! How do we want to handle the series that have two languages in the current title? I ask because the English title is not the same as a transliterated title, so it can't be put in as a transliteration. ···日本穣 · 投稿 · Talk to Nihonjoe 19:40, 7 March 2019 (EST)
I have been transliterating the non-Latin parts of series names and ignoring the Latin parts. Since we don't have a "variant" mechanism for series, some names are kludgy, but it's the best we can do for now. Ahasuerus 20:07, 7 March 2019 (EST)

Advanced Search Enhancements: The Next Generation

I am starting the next sequence of Advanced Search enhancements. The first patch was installed a few minutes ago. It fixed a Python bug that was causing certain Advanced Award searches to error out.

I expect that the next patch or two should have no impact on user experience. If I mess up and some parts of Advanced Search get broken, please post the affected URL(s) here. Ahasuerus 20:36, 9 March 2019 (EST)

Patch #2 has been installed. The URLs of record-specific Advanced Search selection criteria Web pages have changed. If you have them bookmarked, you will want to update the bookmarks. Ahasuerus 16:20, 10 March 2019 (EDT)
Patch #3 has been installed. The only user-visible change was the increase in the maximum number of supported selection criteria from 5 to 6. Ahasuerus 11:24, 13 March 2019 (EDT)
Patches #4 and 5 have been installed. Search results pages have been modified to display the selection criteria that were used to create the results. Ahasuerus 21:07, 15 March 2019 (EDT)

Date of Project Gutenberg ebook publication

For two Project Gutenberg ebooks we have publication records (linked here) with apparently spurious 1st-day-of-the-month publication dates. The official release/posting data are complex and I quote them here for reference.

Posting Date: September 19, 2014 [EBook #8180] Release Date: May, 2005 First Posted: June 26, 2003
Posting Date: November 23, 2011 [EBook #9956] Release Date: February, 2006 First Posted: November 4, 2003 Last Updated: November 14, 2015

Is it the official "Release Date" that we should enter as publication date? That is, in these two cases, simple correction to 2005-05-00 and 2006-02-00? --Pwendt|talk 14:43, 18 March 2019 (EDT)

See R.39 from their FAQ. For books with catalog id < 10k, they had a scheduled release date and an actual release date. They ended up being significantly ahead for awhile. So for example, in the first case, they scheduled to release in in May 2005, but actually released it June 26, 2003. -- JLaTondre (talk) 17:18, 18 March 2019 (EDT)

The Author and The Earl

1. If I understand correctly, the Directory Entry for an Author record should never begin with "The" (nor with "A" as an indefinite article, nor other cases?). And the name, or Author field value, should begin with "The Editor(s) of ..." only where that appears on the title page of a book, but for a magazine always "Editors of ...".

Thus "The Editors of the Saturday Evening Post" is probably correct here T1645902, as a variant of canonical author "Editors of the Saturday Evening Post".

That is, a variant of our Author name for publication records of non-genre magazine The Saturday Evening Post. Right?
Template link repaired (t, not p). --Pwendt

But the Author search report for "The Editor" [2] is mainly a list of mistakes. Right?

See #The Editor, below. --Pwendt|talk 14:04, 27 March 2019 (EDT)

2. Directory entries for (The) Author(s) of ... and (the) Editor(s) of ... should begin with "Author(s)" or "Editor(s)", evidently from the great preponderance entered thus. "Author" alone is the majority choice, but we also have many entries such as "Author of 'Our Neighborhood,' ".

The same should be true for (The) Publisher(s) of ..., I feel sure.

3. What about "(The) Earl of ...", and others of his ilk? --Pwendt|talk 18:11, 20 March 2019 (EDT)

SFERA award

Hi everybody! Is it possible to add SFera award. It was was established by SFera in 1981, Croatian SF comunity from Zagreb.

list of winners since 1981 Debolestis 07:18, 24 March 2019 (EDT)

It looks like a legitimate award. Most -- perhaps all -- categories should be eligible for inclusion. Ahasuerus 07:56, 24 March 2019 (EDT)
Great, I am not sure what is a procedure with this. Debolestis 08:14, 24 March 2019 (EDT)
If there are no objections in the next couple of days, I will create the new award type. Then we can create its award categories, enter the awards/nominations, etc. Ahasuerus 13:33, 24 March 2019 (EDT)
Sorry, I got distracted while working on Fixer. I will create the award type tomorrow. Ahasuerus 23:44, 28 March 2019 (EDT)

(unindent) The new award type and its categories have been created. Hopefully the current "display order" of the categories is reasonable. They seem to be fairly straightforward, but I would appreciate it if you could check that I didn't mess anything up. For example, I assumed that "Roman za djecu", "Dječji roman" and "Roman za mlade" were just successive names of the same category ("Juvenile Novel"), but it's possible that their scope may be different.

Other than that, I think we should be ready to start entering awards. The one that I have entered seems to look OK. Ahasuerus 11:05, 29 March 2019 (EDT)

This is great, thank you a lot! I'll start entering awards this week. Your translations are all good. Debolestis 18:18, 30 March 2019 (EDT)
One more thing, until 1991 it was awarded for Yugoslavia, from 1994 only for works published in Croatian. Debolestis 18:18, 30 March 2019 (EDT)
Updated, thanks. Ahasuerus 19:27, 30 March 2019 (EDT)
Do I enter awards such as "comic book" or "illustration" when it was not given to a specific illustration? Do I use untitled award in this case? Debolestis 18:38, 30 March 2019 (EDT)
We have a number of "comic book" and "illustration" award categories on file -- see this list and this list. I would suggest following the same format and consulting Help:Screen:AddAward for the specifics. Ahasuerus 19:27, 30 March 2019 (EDT)
P.S. One category name that I wasn't sure about is "Povelja". The word is supposed to mean "charter", but awards in this category are apparently given to fanzines and articles. What would be a good way to translate it? Ahasuerus 19:37, 30 March 2019 (EDT)
"Povelja" means "charter", that would be good translation. "Protosfera" is given to best new young author. Debolestis 11:29, 31 March 2019 (EDT)
Updated -- thanks again. Ahasuerus 12:34, 31 March 2019 (EDT)

The Editor

Looking again at works we credit to The Editor(s), it occurs to me that it may be our policy to distinguish genre and non-genre magazines thus:

  • for genre magazines where possible, credit particular editors (Author names) and publishers by name;
  • for non-genre magazines, credit "Editors of [title]" even if the editor is a known person and optionally leave publisher field empty.
Three years' issue of The Pall Mall Magazine have been handled differently. The magazine is non-genre (although not all years' issue have been so tagged). The named 1899, 1908, and 1914 editors have no other works in the database and, I surmise or propose as necessary, they should not be named (except in Notes: series, annual Title records, or perhaps Author: Editors of The Pall Mall Magazine). --Pwendt|talk 16:27, 27 March 2019 (EDT)
This is allowed per these instructions: "If the actual editor is known with reasonable certainty, you may optionally enter the name(s) of the editor(s) as co-editors, but leave "Editors of PERIODICAL NAME" as one of the editors in any case." --Ron ~ RtraceTalk 21:18, 27 March 2019 (EDT)

Anyway, sometimes we do name the editor(s), as Hugo Gernsback alone for Wonder Stories, or Roger Dobson and Mark Valentine for Aklo (eg, ESSAYs linked below). In those cases, we may credit ESSAY contents of the magazine publications to that person or those people, regardless whether the work is uncredited or credited to The Editor(s) singular or plural. And we may do that directly, rather than by variant Author names such as "uncredited" and "The Editor ...". Should we always do that?

For instance, 1934 ESSAY "Our New Policy" by The Editors of Wonder Stories T2198828 should be credited to directly to Gernsback alone. And for clarity of the Gernsback bibliography, it should be in Series: Editorial (Wonder Stories) S26754. Right? (At the moment that series contains two titles as by "uncredited", all others as by Hugo Gernsback. There may be other Gernsback ESSAYs that belong in the series --perhaps everything credited to him as editor of Wonder Stories.)

For instance, 1988 ESSAY "The Arthur Machen Society Appeal" T2279843 should be credited directory to Dobson and Valentine jointly. And for clarity such ESSAYs should be segregated from others in their bibliographies, using an editorial Series. --Pwendt|talk 14:41, 27 March 2019 (EDT)

The idea behind treatment for non-genre magazines is to avoid creating Author records for people not associated with the genre. So the policy is to credit Editors of XXX always in such situations. If there's an author record for any of the editors, they may be added so that the magazines are listed in their bibliographies. --MartyD 21:58, 27 March 2019 (EDT)

Windy City Pulpcon

If anyone here is attending the Windy City Pulpcon on April 12-14. Let me know if you'd like to meet up.--Rkihara 13:18, 1 April 2019 (EDT)

As usual, I'll be there. It's practically in my back yard. I'd be happy to meet up if you're interested. Bob 17:43, 1 April 2019 (EDT)
Sure, I'd like that. I'll be registered at the Westin as Ron Kihara and will be arriving Thurs. evening. I usually drive down I-80 from the Bay Area, so it's possible the weather might prevent me from making it.--Rkihara 19:20, 1 April 2019 (EDT)
Great, Ron. I'll get there about 11 a.m. Friday when the dealer room opens. I'll hang around the entrance for a while, then wander through the ballroom. I'm Bob or Robert Lumpkin. If we somehow miss on Friday, I'll be there about 10 am on Saturday with my adult son. I'll hang around with dealers like Greg Ketter (Dream Haven Books), Lloyd Currey, Andy Richards (Cold Tonnage Books), Graham Holroyd, and Bill Cavalier. There are usually a bunch of friends from the Robert E. Howard community as well. Bob 20:06, 1 April 2019 (EDT)
I'll be going into the dealer room about the same time. I'll be easy to spot, I'm Japanese, wear glasses, bald, and I'm told I look like a Kung Fu villain. The dealers I usually spend time with are; Steve Hafner, Larry Hallock, Craig Poole, Dave Kurzman and Steve Spilger. I'm also in and out of the hospitality room.--Rkihara 22:39, 1 April 2019 (EDT)

Template that can be used in the wiki

I've created Template:Notice float right for anyone that wishes to use it. If you visit the template page, it gives an example of how to use it. You can also see it in use on my user page. Enjoy! ···日本穣 · 投稿 · Talk to Nihonjoe 16:15, 5 April 2019 (EDT)

Changes to ISFDB links

The way ISFDB links -- including links to author, title, series, etc records -- are displayed has been changed behind the scenes. The new linking format is supposed to be supported by all browsers going back to Internet Explorer 6, so the change should be completely transparent to all users.

Still, given the variety of browsers out there, you can never be 100% sure. If a link doesn't work as expected, please post the offending URL and your browser version here. Ahasuerus 16:11, 6 April 2019 (EDT)

Does this address the issue of Facebook adding the "&fbclid=" bit onto URLs? ···日本穣 · 投稿 · Talk to Nihonjoe 12:08, 8 April 2019 (EDT)
I am afraid not. It's a different change addressing a different issue. Ahasuerus 14:02, 8 April 2019 (EDT)
Some users report issues under certain versions of Safari. Investigating. Ahasuerus 11:31, 14 April 2019 (EDT)
Unfortunately, there wasn't anything that I could do to address the Safari bug(s). For now, I have reverted the software changes to enable Safari users to access our data. Ahasuerus 11:57, 16 April 2019 (EDT)

Canonical name Thomas Blot or William Simpson (I)

In relation to the 1891 pseudonymous NOVEL The Man from Mars, as by Thomas Blot T1013407:
This week I added the 1900 Third Edition, Revised and Enlarged, by William Simpson (I), and the 1893 stated second edition, identical to the first but also under the author's real name. --both of those as publications one NOVEL by William Simpson (I) T2536737, although 80 of 280 pages are new in the Third Edition, a 60-page Preface and a new chapter. Most information on how the 1900 differs from the earlier eds. is now in the 1900 publication record P710623.

That is: 1893 change in credited author name; 1900 change in contents --but not so great that we should treat it as a new NOVEL, in my opinion. Right? If so, then one NOVEL title should be variant of the author, depending on which should be the canonical author name.

Neither Blot nor Simpson (I) is likely to enjoy a growing bibliography here. SFE3 knows the writer as Blot, from the 1st edition. Library of Congress doesn't know him at all.

Thomas Blot or William Simpson (I)? That governs the (re)location of all Author data and much NOVEL data to the appropriate parent record, and whether the Novel by Simpson should be dated 1891 or 1893? --Pwendt|talk 16:53, 6 April 2019 (EDT)

(fix template links, rewrite and expand) --Pwendt|talk 17:52, 6 April 2019 (EDT)

Arthur C. Clarke Award - Categories

The Arthur C. Clarke Award is currently set up to have the following categories:

  • Winner
  • Runner-Up
  • Shortlist
  • Honorary Award

It would appear that the first tree categories as they are currently defined in the database are actually different "award levels" of the Best Science Fiction Novel "award category". My guess is that the editor(s) who originally created these categories were trying to get around the fact that -- the way the software currently works -- an award category has to be either a "Poll" or "Not a Poll". As luck would have it, the Best Science Fiction Novel category doesn't fit this mold. In 1987-1996 there was one "winner", one "runner-up" and a number of nominations every year, but "runner-ups" were eliminated in 1997. Whoever originally entered the date presumably tried to get around this problem by creating additional categories.

It occurs to me that there may be another way to organize the data. We could merge the three categories into one, "Best Science Fiction Novel", and set it up as a "Poll". Winners would then be entered as "Award Level 1", runner-ups as "Award Level 2" and regular nominees as "Finalists" (a supported "special award level".)

What do you think? Ahasuerus 19:54, 9 April 2019 (EDT)

Sounds good. It also looks like there were 3rd place winners announced in 1989 and 1990, per the SFADB. The Award's site lists only winners and shortlist for all years. --Ron ~ RtraceTalk 06:58, 10 April 2019 (EDT)
Done! Ahasuerus 15:46, 14 April 2019 (EDT)

Wiki page elimination

Moments ago I made three submissions related to the ISFDB wiki page Author:Jonathan Scott. That page gives a medium-length quotation from the British DNB.

  1. As the DNB quotation concerns Scott's edition of the Arabian Nights alone, [1] I copied all of it (typography unmodified) as a Note on Title 1340796.
  2. I copied most of the first sentence (typography modified) as a Note on Author Jonathan Scott.
  3. On the Wiki page I added a note, with signature and timestamp, explaining how the page is now redundant (entirely).

I have wondered about the procedure for wiki page elimination. I don't work on it systematically but I have added some Notes to the database that make some Author, Bio, and Publisher wiki pages redundant. Is it desirable to annotate the wiki pages as I have done here? Alternatively, is there another place to report that a page is now redundant?

The Author page is entirely redundant (pending approval of these submissions) in that all of its content is available in the database. Perhaps I should have included a link or some instruction in the Author Note --as I would have done for someone with a medium or long bibliography. For instance, minimally

  • "In 1811 Scott published the work by which he is chiefly known, his edition of the Arabian Nights" in six volumes (the 1811 work listed below).

--Pwendt|talk 14:39, 10 April 2019 (EDT)

When content from a wiki page has been moved to the database, add the following to the top of the page: {{Page transferred}}. That will tag the page for deletion and it will (eventually) get deleted. You can also use {{Deletion candidate|your reason here}} (filling in your reason) for pages that are not a simple transfer case. I have deleted the author's page. -- JLaTondre (talk) 16:06, 10 April 2019 (EDT)

New Help page organized

I created Help:How to (wiki) (which previously only existed as a list of pages in a category). I organized the pages by what they discussed. ···日本穣 · 投稿 · Talk to Nihonjoe 15:01, 12 April 2019 (EDT)

SFE3 Reconciliation - New Report

The way our author URLs are reconciled with SFE3 has been changed. A new cleanup report has been created and deployed. The new functionality includes:

  • All editors have access to the report (only moderators can "ignore" SFE3 URLs)
  • The cleanup report is now updated nightly with the latest SFE3 data
  • The software analyzes SFE3 article names and tries to guess what the corresponding ISFDB author should be

If everything goes smoothly, the new data will become available in a couple of hours when the nightly process runs. Ahasuerus 23:15, 13 April 2019 (EDT)

The nightly process ran successfully and added 4380 SFE3 URLs to the report. I have cleaned up the first 10 and the process seems to be working correctly. Things are looking up. Ahasuerus 11:33, 14 April 2019 (EDT)
Thanks!--Dirk P Broer 06:34, 2 May 2019 (EDT)
Glad it's useful :-) Ahasuerus 06:48, 2 May 2019 (EDT)

Inconsistent category names on Locus Poll Award in 2007, 2009 and 2010

I notice that there are a few instances of categories for the Locus Poll Award not being prefixed by "Best". This is visible at , but a rough list of the offending categories/years is:

  • Collection (2010)
  • Fantasy Novel (2007, 2009, 2010)
  • First Novel (2007, 2009)
  • Nonfiction/Art Book (2010) - note that the "Best" category is "Best Nonfiction/Art", no "Book"
  • Novelette (2010)
  • Novella (2007, 2010)
  • Short Story (2010)

Anyone know if there's a good reason for this? It certainly seems less than ideal from a UX point-of-view. I'm a newbie here, so I dunno how easy it would be to merge these back into the more common "Best..." categories - it looks like there might be enough records for some sort of SQL bulk UPDATE to be better than multiple updates via the UI?

(FWIW, Wikipedia has them all as "Best Whatever", SFADB just has "Whatever". Locus' site uses "Best Whatever", at least for 2010:

In a similar vein - but it is at least consistent within the award - the Nebulas are just categorized as "Novel", "Novella" etc, whereas on the SFWA site they are "Best Novel", "Best Novella" etc. e.g.

--ErsatzCulture 19:19, 14 April 2019 (EDT)

I can think of two possible explanations:
  1. The person who created the additional categories overlooked the fact that related "Best" categories were already on file
  2. The person who created the additional categories was working with what s/he considered an authoritative source -- perhaps Locus issues? -- and s/he wanted to be as accurate as possible
Normally, a minor name change doesn't result in the creation of a new category, so my inclination would be to merge them and to document any discrepancies that we may find in the Note field. Let me check submission history to see who created these categories first... Ahasuerus 20:07, 14 April 2019 (EDT)
I have scanned the submission table looking for clues. Here is what I think is happening with these categories.
Originally, award types and categories were handled differently. Award types used to be hard-coded using two-letter abbreviations -- see "award_ttype" on this Wiki page. Award categories used to be manually entered every time an award was entered -- see "award_atype" on the same Wiki page.
It was very messy and I ended up rewriting the whole thing in 2014 -- see Development/Archive/2014 for details. I then migrated previously entered award categories to the new table structure. I think I tried to merge near-duplicates where feasible, but it looks like I missed quite a few.
I think it should be safe to merge these categories. Roughly 200 awards will be affected, which shouldn't be too hard to do manually. Ahasuerus 21:22, 14 April 2019 (EDT)
OK, I think I have merged everything that could be merged without losing specificity. Please let me know if I missed anything. Ahasuerus 21:30, 17 April 2019 (EDT)

Fantasy and Science Fiction mentioned ISFDB

I forgot to mention it back on April 4. See this post. ···日本穣 · 投稿 · Talk to Nihonjoe 20:08, 16 April 2019 (EDT)

Nominating Biomassbob as Moderator

I would like to nominate Biomassbob (talkcontribs) for moderator. He has been an editor for seven years and has 44530 edits as of this date, covering the full range of the database. I have always found his edits to be detailed and complete. I believe that he is highly qualified to be a moderator and he has accepted the nomination.


  1. Support, as nominator.—Rkihara 10:41, 20 April 2019 (EDT)
  2. Support. No concerns; I can't remember the last time I had an issue with any of his plentiful and varied submissions. p.s. Thanks for making me feel old, Ron. --MartyD 17:05, 20 April 2019 (EDT)
  3. Support. About time :) Annie 17:55, 20 April 2019 (EDT)
  4. Support. I have no concerns. ···日本穣 · 投稿 · Talk to Nihonjoe 19:38, 22 April 2019 (EDT)


  1. I haven't done a lot of moderating lately, so I'll abstain. Ahasuerus 19:16, 23 April 2019 (EDT)
  2. I can't remember having moderated enough of his submissions to make a judgement, therefore I stay neutral. Jens Hitspacebar 13:21, 25 April 2019 (EDT)


The nomination was successful; the moderator flag has been set on the account. Congratulations! Ahasuerus 11:29, 27 April 2019 (EDT)

Cropping Amazon images

Dirk Stoeker has identified a way to crop Amazon images:

However, the way our software is currently configured, an Amazon image URL that contains "L._" generates a yellow warning ("Extra formatting in an Amazon URL") on post-submission pages. It also generates an exception on one of the nightly cleanup reports.

That said, it would be easy to modify the software to accept "L._CR" URLs, so the question is whether we want to allow them. On the one hand, "cropped" URLs can come in handy when dealing with unusual Amazon images. On the other hand, Amazon URLs are not always stable and this particular method has been apparently changed in the past. Here is what an overview of Amazon images says about it:

  • This crops the image, trimming away everything but a selected rectangular area. The first two numbers indicate the upper left-hand corner of the selection area (the first is how many pixels from the left, the second is how many pixels down from the top). The next two numbers are the width and height of the selected area, in pixels.
  • Note: this was a great way to trim away the excess white space left by other commands,,. which other commands used to create, although that was greatly reduced sometime around July 2007. You have to take the time to crop precisely for a given image. If you set the crop area to go beyond the edge of the image, the image will merely be resized with white space added.

Based on this history, I wonder if it may be better to create a cropped image on your computer and then upload it to ISFDB. What do you think? Ahasuerus 19:26, 20 April 2019 (EDT)

Amazon tends to change their formatting when it suits them and relying on it may end up with some weird side effects when they do in a few years. If the Amazon image is not good as is, then we either should live with it or find another one or fix it -- but relying on an undocumented and non-guaranteed external formatting is just asking for trouble. Annie 21:46, 20 April 2019 (EDT)
Downloading, cropping and uploading to ISFDB is not an valid approach, as there still can be copyright on the images (even if it is debatable if copyright can exist for a mere photo of a book). As far as history of Amazon shows they simply ignore old parameters when they change, so in this case the result would be an uncropped image again. --Stoecker 04:17, 21 April 2019 (EDT)
Copyright is irrelevant for this discussion. We use non-public domain cover images under fair use criteria. -- JLaTondre (talk) 08:32, 21 April 2019 (EDT)
Not for me. Even if the use of the motive is ok, modifying the photo taken by somebody else is a minefield I wouldn't want to step into, especially with the upcomming copyright changes in Europe. --Stoecker 11:58, 24 April 2019 (EDT)
Amazon covers are not always reliable, especially for older works. I'm not thrilled with the idea of locally uploading Amazon images, especially for works that were verified without a cover. If the cover is actually for the wrong edition, it creates a false record where it is harder to see that the image is not correct. Especially since uploaders are incredibly poor at properly changing the source field in the fair use template. The crop functionality has been around for sometime. If change were to occur, it would probably be that Amazon deprecates it, in which case, it would go back to showing the whole image so not much of a risk in my opinion. -- JLaTondre (talk) 08:32, 21 April 2019 (EDT)
While I don't care for relying on specifying the cropping in the URL, I don't see any harm in allowing it, and it does seem a little better to me in terms of preserving the provenance of the image than we might get if we recommend downloading and cropping and uploading. --MartyD 09:57, 21 April 2019 (EDT)
It looks like we have 3 editors in favor of allowing "L._CR" URLs, 1 opposed and 1 neutral (me). Would anyone else like to share his or her thoughts? Ahasuerus 11:06, 25 April 2019 (EDT)
If everyone else is in favor of it, I am not going to block the decision - so ignore the opposing editor. :) It is an easily reversible one if Amazon managed to make it a disaster with an update - because of the format, we can always strip those programmatically later. Annie 13:20, 25 April 2019 (EDT)

(unindent) OK, we have a consensus or as close to it as we are likely to get. I have changed the software to ignore "._CR" in Amazon URLs and updated Template:Image Host Sites with Dirk's instructions. In addition, the new cleanup logic is somewhat more robust than the old logic, so I expect it to find 30 new "problem" images tomorrow morning. Ahasuerus 19:59, 26 April 2019 (EDT)

Cleanup completed. Ahasuerus 14:14, 29 April 2019 (EDT)


There doesn't seem to be anything specific in the Help pages about abridgements, specifically what constitutes an abridgement, how to credit additional 'authors'/'editors' or note them if unspecified, varianting to the original title, effects of translation (e.g. abridgement of a translation vs. translated and abridged vs. abridged then translated) and distinguishing abridgements of an oft-abridged title. Are there rules or even consensus for these topics? If this turns into a discussion of actual rules, it should be moved to that forum, but for now I'm wondering about where we stand. ../Doug H 12:05, 29 April 2019 (EDT)

In my experience, it depends on the nature of the abridgement. If the differences are minor, they are documented in Notes. If they are major, a new title record is created.
If the person who performed the abridgement is known and a new title needs to be created, s/he is credited as a co-author -- see William Shakespeare's bibliography for examples. If the text was rewritten so extensively that it qualifies as a separate work (typically retellings for young children) then the original author is sometimes only credited in Notes. Ahasuerus 18:10, 29 April 2019 (EDT)
If we stick with crediting per the pub and it doesn't list the abridger on the title page, then it should be entered as by the author alone and varianted to as by the author and the abridger. We are inconsistent in doing that though. -- JLaTondre (talk) 18:45, 29 April 2019 (EDT)
If you variant to the title with the original author and abridger, then you can't variant that in turn to the original. Does that mean abridgements aren't supposed to be varianted to the original? Is there any way to keep track of the relationship? ../Doug H 19:37, 29 April 2019 (EDT)
Variants are the same work under a different title (or translations). They are not for variance in the work itself (other than translations). If an abridgment is different enough to be considered a new work, then it would not be varainted to the original work. If the changes are minor enough to not be considered a new work, then there would not be a separate title & it would be simply captured in the notes (as Ahasuerus referred to above). If it's different enough to have its own title record, then you would need to use the notes to link it back. The only exception would be if it's a minor abridgment and a title change (then a variant would be appropriate). -- JLaTondre (talk) 20:03, 29 April 2019 (EDT)

New External ID type for Science Fiction-Leihbuch-Datenbank?

The German SF database Science Fiction-Leihbuch-Datenbank has a fairly limited scope, but their data is solid and well organized. Their publication-specific pages can be accessed using "permalinks" like, which should make it easy to add the site as a new "External ID" type. Can anyone think of a reason not to add it? Ahasuerus 15:34, 3 May 2019 (EDT)

No reasons I can think of. --Ron ~ RtraceTalk 11:02, 5 May 2019 (EDT)
Me neither. Stonecreek 13:33, 5 May 2019 (EDT)
OK, FR 1274 has been created. Ahasuerus 14:12, 5 May 2019 (EDT)
A new External ID and a matching linking Notes template have been added -- see this record for an example. Ahasuerus 14:17, 6 May 2019 (EDT)

The Lord of the Rings / The Lord of the Rings (Boxed Set)

Hi, everybody! I just wonder why we have different titles for these: it seems to be somewhat illogical by our internal logic. After all, as for the titles involved in the respective OMNIBUSes, they should be identical; the form of publication shouldn't be reflected in the title, only in the publications. Am I missing something? Stonecreek 09:57, 5 May 2019 (EDT)

Agreed. It might relate to this discussion (at one time the single volume Lord of the Rings was apparently considered a novel). However, since they are both omnibuses, they should be merged. -- JLaTondre (talk) 10:10, 5 May 2019 (EDT)
Yes, I dimly remember that discussion. If no one objects, I'll do the merging: in any case, I'll wait until Tuesday before beginnin with it. Stonecreek 13:38, 5 May 2019 (EDT)
Can't find the original now that they're merged (without an long manual search), so a question - was the entry for the box itself, which had a separate ISBN and cover image than the books it contains? Should the other boxed sets be dealt with the same way? Two contrasting examples - James Blish Cities in Flight has a single publication for the set like Lord of the Rings, but A Game of Thrones: 5-Book Boxed Set will (hopefully) never see a single omnibus publication. ../Doug H 08:53, 8 May 2019 (EDT)
Re: GRRM. You never know, I think, though a printed one-volume edition will take a long time (and some muscles to carry home), there'll likely be an ebook someday.
Re: LotR. There were several boxes, some with one ISBN, some with separate ISBNs. I remember that there were several around the movie(s) release(s), apart from the one mentioned in the title note. Ideally, the page count should be split into three portions (XXX+YYY+ZZZ), though there was one (unverified) set that had only one number.
And yes, this was one example of the underlying principle, I should think. I have merged the Blish OMNIBUSes: thanks for pointing them out. Stonecreek 09:58, 8 May 2019 (EDT)
Lots more where those came from. Just pulled them from the list of 200+ titles with "boxed set" or "boxset". Didn't even try other variations. ../Doug H 19:29, 8 May 2019 (EDT)
To be merged, they would have to have the same contents and same title (minus the artificial box set disambiguation we add). If they had the same contents and different title, they would be varianted. There may be a few more cases out there if someone has the patience to go through them all, but I randomly poked through a bunch of the results from doing such a query and only found one. -- JLaTondre (talk) 21:58, 8 May 2019 (EDT)
So if there is no existing omnibus with a matching title when you enter the box set, the generated TITLE title would also include "box set", until such time as someone entered the matching omnibus without a "box set", at which point the box set should be merged with the second omnibus title? The inclusion of "box set" is acceptable as long as there isn't an existing non-boxed omnibus? In the case of Asimov's Foundation Trilogy, the box set title entry explicitly states it is not to be merged with the single volume omnibus. So it sounds like someone had a different opinion that a moderator agreed with. No verifications, so no names or dates. And a question for Stonecreek - what do you mean "by our internal logic"? And as a final observation - I thought box sets were different and were put in as OMNIBUS because that was the closest thing without coding a new type - which is the only reason I keep picking at this, I don't yet understand. ../Doug H 22:53, 8 May 2019 (EDT)
No, it seems that (box set) wouldn't belong to the title in general: it crept into our database just because vendors such as Amazon have that title, which only belongs to a specific publication, and is not to be found anywhere in or on the publication itself. Stonecreek 00:26, 9 May 2019 (EDT)

Crediting cover scans - proposed design changes

Here is how cover scan credits work at this time. When we link to a cover scan, we credit the organization operating the server that hosts the scan. The credit line reads "Cover art supplied by X", where [X] is the name of the organization (Amazon, Galactic Central, etc) linked to the organization's home page. Clicking the image takes you to the raw image hosted by the third party. Here is an example of how it currently works.

There are two partial exceptions to this rule. First, images hosted by the SFE3 Picture Gallery are handled differently. Due to SFE3 requirements, clicking an SFE3-hosted image takes you to the Gallery Web page that hosts it as opposed to the raw image. For example, if you click the cover of this publication, you will see its Gallery page, not the raw image. This was done in order to support SFE3 requirements -- see Template:Image Host Sites, which reads, in part, "all SFE3-hosted images must have a link to the associated "Gallery" page added after a "pipe" ("|") character", for an explanation of the technical details. (Ignore the fact that the linked publication page currently credits "Encyclopedia of Fantasy" instead of SFE3. It's a recently discovered bug which needs to be fixed. The bug has been fixed.)

The second partial exception is ISFDB-hosted images. As expected, clicking an ISFDB-hosted image takes you to the raw image. However, clicking the word "ISFDB" on the "Cover art supplied by ISFDB" line takes you to the ISFDB Wiki page for the image as opposed to the ISFDB home page. Here is an example of how it works.

This is inconsistent design because seemingly identical links behave differently depending on whether the cover scan is hosted by ISFDB, SFE3 or another party. To make it worse, recent discussions with the administrator of Science Fiction-Leihbuch-Datenbank have identified additional requirements for linking to their cover scans. They would like "Cover art supplied by" lines to link to their publication-specific pages the way they currently link to ISFDB Wiki pages for ISFDB-hosted scans. We could modify our software to accommodate their requirements, but it would further muddy the waters. Besides, who knows what kinds of additional linking requirements other sites may have in the future?

An e-mail discussion of this issue with the administrators of Science Fiction-Leihbuch-Datenbank and SFE3 ultimately resulted in the following proposal:

1. Change the software so that clicking a cover scan (including SFE3-hosted cover scans) should always take the user to the raw image file.

2. Modify the credit line to have two links instead of one. The first link will continue to be a link to the site's home page. The second, new, link will be to a publication-specific page (if defined.)

3. The new wording of the credit line will be "Cover art supplied by X on this Web page" where:

  • "X" will be the name of the organization hyperlinked to its home page, and
  • "this Web page" will be a link to a publication-specific page, specifically:
    • for SFE3-hosted images it will be the cover scan's Gallery page
    • for ISFDB-hosted images it will be the ISFDB Wiki page of the cover scan
    • for Science Fiction-Leihbuch-Datenbank-hosted images it will be the publication-specific page associated with the cover scan
    • all other cover scans won't have the words "on this Web page" displayed because there is no page to link to

For now we will keep the current way of entering links to publication-specific pages, which uses "|" to separate the cover scan URL from the URL of the publication-specific page. If the current proposal is accepted and implemented, I expect that we will revisit this issue at some point in the future and probably create a separate field for the data that is currently entered to the right of "|", but that's another discussion.

So, what do you think? Ahasuerus 13:56, 5 May 2019 (EDT)

Sounds overall very good to me! Stonecreek 13:45, 7 May 2019 (EDT)
To me as well. Jens Hitspacebar 14:50, 7 May 2019 (EDT)
Me three Annie 19:53, 7 May 2019 (EDT)
Sounds good to me. ···日本穣 · 投稿 · Talk to Nihonjoe 20:22, 7 May 2019 (EDT)
Thanks, folks. FR 1277 has been created. Ahasuerus 20:47, 7 May 2019 (EDT)

(unindent) The deed is done. (Hopefully without messing up anything else.)

BTW, there is another site that requires that we link to the underlying page -- Smashwords. We have a cleanup report that hunts invalid Smashwords links, but we need to add a yellow post-submission warning. I'll take care of it when I add Science Fiction-Leihbuch-Datenbank. Ahasuerus 17:53, 8 May 2019 (EDT)

Couldn't we get something similar for Amazon-linked cover art? I regularly get into a situation where I want to check out the actual page, so it'd be nice if I could click on a link and it'd bring me directly to the actual pub instead of to the frontpage where I then have to search for the pub I'm looking for...
Additionally, could it be done to have a link to any one of the Amazon sites, depending on which site is used to link to? For example, linking cover art from Amazon UK (or DE, or...) would link to instead of to MagicUnk 14:00, 9 May 2019 (EDT)
Publications with ISBNs display links to the supported Amazon stores under "Other Sites" in the navigation bar on the left. Publications with ASINs link to the supported Amazon stores in the External ID section.
Having said that, we could add an explicit Amazon link to the credit line for Amazon-hosted images. Unfortunately, there is no way of telling which Amazon store the image is associated with because all Amazon images use the same URL structure (at least to the best of my knowledge.) I guess it means that we will have to link to Ahasuerus 14:55, 9 May 2019 (EDT)
Ah yes, I could have found out myself if I'd paid attention. My apologies. Regards MagicUnk 17:56, 9 May 2019 (EDT)

Linking to SF-Leihbuch

SF-Leihbuch has been added to the list of third party Web sites that we are allowed to link to.

The software module responsible for post-submission warnings and cleanup reports has been rewritten to handle the three Web sites that require additional links for images -- SFE3, Smashwords and now SF-Leihbuch -- consistently. If you encounter any issues, please post your findings here. Ahasuerus 21:33, 9 May 2019 (EDT)

Crediting third party sites - Part 2

Now that the dust has settled and various queued up software tweaks have been implemented, I'd like to revisit the issue that I raised a week ago.

At this time there are three third party Web sites that require us to link to a particular Web page when displaying their images: SFE3, Smashwords and SF-Leihbuch. The way we do it is by entering the URL of the image, then the "pipe" character ("|"), then the URL of the third party Web page associated with the image -- see Template:Image_Host_Sites for site-specific details. In the future, we may be given linking permissions by other sites that have similar requirements.

I don't think the current design is a good long term solution. It's not consistent with how other data entry fields work, it can mess up Advanced Publication Searches and it makes the software more convoluted than it needs to be.

I propose that we create a new field for these links. Instead of entering something like "|" in the "Image URL" field, we would be entering "" in the "Image URL" field and "" in the new field. The new field would be optional, but we may be able to add pop-up validation to make it mandatory for the sites that have this requirement. Post-submission warnings and cleanup reports would be adjusted accordingly. Existing data would be migrated automatically.

I am not sure what a good name for the new field would be. Something like "Web page of the image"? Any reasons not to add it? Ahasuerus 18:39, 11 May 2019 (EDT)

Breaking it out into a new field seems reasonable, but it needs to have a name that is not confusing. Most users (especially new ones) will not be familiar with the unique requirements for this field. The name should be something that makes it clear it's only needed in certain cases (or another option, though more complicated, would be to use JavaScript to only make the field displayed when an URL for one of those sites it entered). I'm struggling to come with an good option, though. -- JLaTondre (talk) 10:50, 12 May 2019 (EDT)
Unfortunately, I can't think of a good name either. For now, I have created FR 1282, Create a new publication field for crediting 3rd party sites. Based on the limited feedback, I assume that it's relatively low priority. Ahasuerus 13:35, 24 May 2019 (EDT)

"SF Calendar" added

A new Web page, SF Calendar, has been added as per FR 998. It is accessible from the "Other Pages" section of the navigation bar on the left. After selecting a day, you are taken to the list of authors who were born and who died on the selected day.

Let's wait a few days to let everyone get used to the new functionality and address any page layout issues that may arise.

Once the layout is stable, we can revisit the discussion which prompted the creation of this FR in 2017: what do we want to appear at the top of the home page? Now that the birth/death data is available on a separate page, can we remove it from the front page? Pare it down? Replace it with a link to "SF Calendar"? Should we display other links at the top of the home page, e.g.:

  • Author Directory
  • Award Directory
  • Publisher Directory
  • Magazine Directory
  • Statistics/Top Lists

? Ahasuerus 17:01, 13 May 2019 (EDT)

Enhancing the "Chronological Bibliography" page?

A new Feature Request, FR 1280, "Create a noncategorized-chronology page for authors?" has been created on SourceForge. It reads:

I frequently want to view all of a given author's works in a single chronological list, rather than a set of categorized chronological lists. Is there already a way to do that? (When I click "Chronological", I get categorized lists.)

Currently, "Chronological" author pages ignore series groupings. However, they display novels, collections, anthologies, magazines, short fiction, essays, etc in separate sections. "Alphabetical" pages use the same approach.

The proposal, as I understand it, would add a new Web page for author bibliographies. The new page would display all titles chronologically without regard for the title type. I can see how it could be useful in certain cases, e.g. if it's not immediately clear whether a short novel appears in the NOVEL section or the SHORT FICTION section. At the same time I suspect that combining reviews, chapbooks, EDITOR records, etc in one long list may be confusing. Perhaps displaying the title type next to each title would help? Ahasuerus 14:58, 20 May 2019 (EDT)

That's a nice feature. The title type should definitely be displayed. Moreover, information about language and variants are quite helpful. The display format could be a mixture of the way titles are displayed on the author page and in the "Contents" section on a publication page, which would also include title series and alternate name information. For example, the line for the German translation of Iain M. Banks' Consider Phlebas could look like this:
  • "Bedenke Phlebas [German] (1989) • [Culture • 1] • novel (trans. of Consider Phlebas 1987) [as by Iain Banks]"
Also, the list could be organized into a separate section per year. Then the year could be omitted per line:
  • "Bedenke Phlebas [German] • [Culture • 1] • novel (trans. of Consider Phlebas 1987) [as by Iain Banks]"
Jens Hitspacebar 15:43, 20 May 2019 (EDT)
I would love to have a "All fiction in order" section - but if you add the collections and anthologies and magazines and reviews and interviews, it will become way too long to be useful. Maybe if you can chose which types you see? I assume that variants will remain filterable in that new view as well? Annie 16:49, 20 May 2019 (EDT)
We could have multiple different Chronological" pages, e.g.:
  • "Chronological by Title Type", which would be the same as the current "Chronological" page
  • "Strict Chronological" -- or whatever we decide to call it -- which list everything chronologically
  • "Fiction (Chronological)", which would be limited to novels, short fiction and poems
  • Possibly more, at which point we will probably need an intermediate menu page for different options
That being said, it looks like Jens may be proposing an additional layer of layout changes that would apply to all "Chronological" pages. Is my understanding correct? Ahasuerus 09:14, 21 May 2019 (EDT)
No, my layout proposal was for the "noncategorized-chronology" feature request only, not for the already existing chronological summary author bibliography. But now that you mention it, making the layout per title more consistent across all chronological pages could be a good idea. Or maybe not, I'm not sure yet. The existing chronological author summary bibliography puts the kind of variant at the beginning:
  • Translation: Bedenke Phlebas [German] (1989) [as by Iain Banks]
which, if used the same way on the new "Strict Chronological" page as well, could probably make the list hard to read if many lines would begin with Translation: or Variant:. On the other hand, changing the existing chronological summary author bibliography to also use "(trans. of ...)" instead of Translation: doesn't make sense there because it's obvious that it's a "translation of" due to the way parent and variants are formatted using the bullet lists.
Jens Hitspacebar 16:15, 21 May 2019 (EDT)

Notifying Primary Verifiers

Where do we stand on notifying primary verifiers of changes to their pubs? The "My Changed Primary Verifications" will show what field changed, but not what the change was (both columns show the new value). When that feature was implemented, the community was still saying that primary verfiers should be informed of what the change was. Since the "Note to Moderator" is displayed on the change page, that became the more frequently used method over posting to the verifiers' talk pages (as the moderator's note is easier and remains with the edit history, that makes sense). There is the added complication that not all changes (title level, import/remove) are shown in the changed verifications report. We used to be pretty stringent on the notification requirement. However, a recent conversation has indicated this is no longer the case. What are people's opinions on this? It doesn't help editors for moderators to be inconsistent so we should update practice and/or our documentation based on the community's current position. -- JLaTondre (talk) 17:37, 20 May 2019 (EDT)

Let me try to address the technical side. FR 1237 says:
  • Enhance "My Recently Changed Primary Verifications" to capture Import/Export and Remove Title submissions associated with the user's primary-verified publications.
Once it's been implemented, the report will become more comprehensive and more useful. Also, Roadmap 2017 says:
  • Create a history of changes to primary-verified publications by storing a snapshot of the way each verified pub looked like right before it was changed.
It will take more time to do, but it will make the report much more useful.
Both features are close to the top of my list, but I need to code and deploy the new Amazon interface first. Fixer takes so much of my time these days that making at least some of what I do publicly available (and thus freeing up more development time) is my top priority at the moment. It's kind of a Catch-22: working on other features means that I can't work on the Amazon interface, which means that I have to spend most of my time working on Fixer, which means that I don't have time to work on other features... Ahasuerus 09:06, 21 May 2019 (EDT)
Yes, I wasn't looking for a technical solution (though that will be nice when it arrives), but rather how we deal with it before the full technical solution comes. I appreciate the enhancements you have been giving us. -- JLaTondre (talk) 19:43, 21 May 2019 (EDT)
I am sorry, I didn't mean to come across as defensive, but I guess I did. Too many balls in the air and not enough productive hours, especially these days :=\ Ahasuerus 21:31, 21 May 2019 (EDT)
I do not notify when I am doing what I consider house-keeping actions (moving identifiers, adding transliterations, editing any of those elements, fixing typos in Notes, fixing a broken HTML or a formatting issue, updating a title or an author name to comply with the capitalization policy and so on) - but I always add a moderator note (and if I am replacing, I tend to add the old and new value in that note). Outside of that, I do notify - one by one if needed; as a group when I am working on a bigger project (swapping a canonical name for example). I also try to notify when making a big change on a title level that impacts a PV'd publication - with a note of what changed to what so we can backtrack if needed. Import/export also causes a notification in my book. For any big changes (changing an author name, fixing page numbers and so on), I try to discuss before I do the change. Annie 19:55, 21 May 2019 (EDT)
Annie's approach may be a viable compromise solution, at least for now: minor changes are listed in the Moderator Note field while significant changes require a note on the Talk page. Approving moderators get to decide what qualifies as a "significant" change and make sure that the Moderator Note includes the "before" version of the data for "minor" changes (since it would be lost otherwise.) Ahasuerus 21:05, 21 May 2019 (EDT)
Edit: On second thought, we probably need to create at least some standards re: what is considered a "minor" edit. Annie's list -- typos, transliterations, HTML fixes, etc -- would be a good start. Ahasuerus 05:44, 22 May 2019 (EDT)
One of the problems when approving someone else's update is that if they do not add the note, you cannot add it. In a lot of cases, the record has at least one more thing that needs fixing but now with most of the identifiers out of the way, we start running into no-issues publications. If I see something else needing fixing, I would fix it and add both edits to the moderator note - so the PV does not wonder what happened. Any chance of making the moderator note editable during the approval? That will also help with the other two issues we have - the fact that the moderator note is visible (a moderator will be able to clean up the private data if any) and the inability to add anywhere any notes when you approve something that at first glance looks weird. Add the ability to add the change if the original submitter had forgotten and we will have a much better system. :) Annie 22:40, 21 May 2019 (EDT)
Letting approving moderators change Moderator Notes would be possible although non-trivial. However, I am not sure it would be optimal. There would be potential for confusion re: who wrote what.
It may be better to create a new field and call it something like "Approval Note" or "Note by the approving moderator". We could then display the Moderator Note and the Approval Note side by side on submission history pages. We may also want to change the name of the "Moderator Note" field to "Submission Note", "Comment about the Submission" or something similar to avoid confusion with the new field. Ahasuerus 05:57, 22 May 2019 (EDT)
Sounds great! "Submission note" is fine, I'd think: it's short and right on the head of the nail. Stonecreek 08:35, 22 May 2019 (EDT)
That works as well :) Annie 17:19, 22 May 2019 (EDT)
I also like "Submission Note" and "Approval Note". ···日本穣 · 投稿 · Talk to Nihonjoe 17:31, 23 May 2019 (EDT)
OK, FR 1281, Add an "Approval Note" field; change "Moderator Note" to "Submission Note", has been created. Ahasuerus 11:12, 24 May 2019 (EDT)

I've gone ahead and approved the submissions I had on hold over this. I'll encourage the submitter to add moderator notes in the future, but given the low level of participation in this discussion, I don't feel it is appropriate to reject their edits when other moderators have been approving them. Thanks. -- JLaTondre (talk) 19:07, 22 May 2019 (EDT)

Sorry to be late to the party. I have not been paying attention to what others do. I don't worry about moving of identifiers or correcting of minor deviations from capitalization standards, but otherwise I would have done as you did: put on hold and ask that the PV(s) be notified. But I also prefer to avoid rejecting and losing work, so sometimes I will notify and/or check with the PVs myself and accept and remind the submittor to follow notification protocol the next time. It is a bit tough to be strict about notifications with so many inactive PVs and PVs with special notification instructions. --MartyD 22:30, 23 May 2019 (EDT)

Proposed Software Changes

Ahasuerus: As these "describe again what is obvious" type of requests is constantly causing me useless trouble: Would you accept a solution to this issue as patch? My solution would be to add the existing values at the time of accepting a request to the stored request, so that a historic view could show the accepted difference situation (That still can differ from the actual value at submission time in case of inbetween changes). --Stoecker 13:39, 23 May 2019 (EDT)

[P.S. later] I'd really like to have such a feature, because even moderators create request without any comment like this and even moderators can be totally wrong. In this example the price was correct before with €15.00. It seems it is now €18.00, but I payed €15.00 as stated on the website at that time (plus €11.00 delivery) for that one Foster story (and the remaining useless contents :-) --Stoecker 13:55, 23 May 2019 (EDT)

We had a fairly extensive discussion of this issue in early 2017. Let me copy-paste the relevant parts of my comments:
Re: "a snapshot of all OLD values". Unfortunately, it would require a significant effort. Granted, it would be easy to do for fields like "ISBN" and "Price". However, consider publishers. The way the database works, we store publisher numbers (1, 2, 3, etc) in publication records. Then, when we display a publication, we retrieve the name of the publisher, including its transliterated name(s), from other parts of the database and display them.
This works well when displaying current data. However, suppose we were to save a verified publication record as it existed prior to submission approval. We would store publisher ID 12345 in the saved record. Then, a few months later, publishers 12345 and 12346 are merged, so publisher 12345 no longer exists in the database. When the original verifier goes back to check this pub's history, there is no publisher 12345 to display. The same thing can happen to publication series, authors and titles. Actually, it can get even more complicated with authors and titles if we want to preserve the pseudonymous/VT/series relationships as they existed at the time.
The ultimate way to address this issue would be to build a snapshot of the then-current version of each about-to-be-changed Publication Web page and store it in a separate database location prior to submission approval. We could then have a list of snapshots for every publication and display them on demand.
We'll need to add a warning about potentially broken links, but the textual part should be very close to what the data looked like as of the time of the edit.
[comments about the impact of this change on disk space omitted since testing has shown it to be manageable, especially if we compress the data]
[related comment:] We started work on a "history" system -- basically a log of changed data -- in 2007. However, we quickly ran into the problems outlined above and more. I spent many man-hours trying to get it to work in the early 2010s, but eventually had to give up because the underlying approach was flawed. Ahasuerus 18:42, 10 January 2017 (UTC)
As far as I can tell, the summary above is still our best bet.
I guess the first step would be to rewrite the software that displays Publication pages. Currently it displays the data as it retrieves it from the database, mostly one line at a time. We would need to change the code so that it would retrieve all of the data first, then build the Web page and then display it. Once it has been done, the next step will be to modify the submission approval process. For primary-verified pages, it will invoke the part of the Publication display code that retrieves and formats the data. It will then compress it and file it in a "history" table within the database. [Need to run, may post more later]. Ahasuerus 15:05, 23 May 2019 (EDT)
Having a complete version history like Wikipedia including the chance to revert edits and show history would be fine, but from my current perspective this would be impossible to do. My proposal only includes a small subset. At the time of a change request acceptance I'd simply add for changed fields the old and new information, so that the changes can be displayed with proper information. Maybe there could even be a cleanup process to drop that additional space wasting information after some time. --Stoecker 15:29, 23 May 2019 (EDT)
I agree that implementing Wiki-like "version history", including the ability to revert changes, would be time-consuming and not feasible at this time.
However, what I outlined above is more modest in scope. The filing software would simply capture the HTML version of each about-to-be-changed primary-verified publication record. It would then compress the HTML "blob" and store it in some table. Each "blob" would be linked to its publication ID and its submission ID. That way the HTML would be accessible from View Submission pages as well as from Publication pages. That shouldn't be too difficult to implement, I hope. Ahasuerus 17:00, 23 May 2019 (EDT)
P.S. I have added the above to FR 1238 "Create an Edit History page for publications". Ahasuerus 11:04, 24 May 2019 (EDT)
This proposed HTML method is nothing where there is a chance of successful cooperation between you and me. It is much to complex to get it to work. Still my proposal is an option - a submission is stored as XML in the database. My proposal is to extend this XML at the moment of accepting the submission and store the old values for changed elements (and only these) in the XML. That way a diff can not only show new, but also old values of a change. That will help a lot to verify a change even if it does not cover all possibilities. This adaption needs only small modifications at submission acceptance and display of a change request and not a major new functionality. And it does also not conflict with any future plans. --Stoecker 04:34, 30 May 2019 (EDT)

Magazine issue navigation

How easy would it be to implement the "Previous ← Current → Next" issues navigation as a database feature, as shown in the Notes field here? Could it use the existing database table information used to create the issue grid, so any missing issues would be skipped? And maybe indicate that one or more issues were skipped (if it can easily see that)? Just curious, as it would benefit browsers of the site so they wouldn't have to visit the issue grid between each issue. ···日本穣 · 投稿 · Talk to Nihonjoe 21:05, 20 May 2019 (EDT)

How would you determine "next/previous" in the cases where we do not have months in the date field? Finding missing issues will be even more problematic - some magazines have 2 issues in some months, some are irregular... and not all magazines have nice numbers on all their issues. Not a bad idea but just wanted to make sure we cover all the logistics... :) Annie 22:19, 20 May 2019 (EDT)
That's why I asked. There's some sort of sorting happening in the issue grid, so that's why I suggested that as a possible method, if it can be used for that. ···日本穣 · 投稿 · Talk to Nihonjoe 02:28, 21 May 2019 (EDT)
Let's consider Science Fiction Quarterly (UK), which has 6 issues whose months of publication are known and 4 issues whose months of publication are unknown. January 1952 through August 1953 should be doable since all of the issues have months. However, what should we do about December 1953 and later issues? A human can figure out that the sequence should be:
  • December 1953
  • #6
  • #7
  • February 1955
  • #9
  • #10
but it would be difficult to replicate the logic programmatically. Ahasuerus 07:14, 21 May 2019 (EDT)
To add to that: The grid does not really do well if it needs to stick more than one issue in the same cell (the no month one for example for a specific year) - it does its best but... it can get a bit wonky and it does look weird for some magazines. Which is not a problem on a grid (you see them all, the slightly off order is not that problematic) but becomes a problem on a straight list. Annie 16:06, 21 May 2019 (EDT)
Perhaps a way to turn it on for magazines that have all the issues entered? Or some way to enable it on a per-issue basis? It could then be left turned off for any that don't line up correctly. Or, program it to display the out of order issues according to which was entered into the system first? Just tossing out ideas. :) ···日本穣 · 投稿 · Talk to Nihonjoe 17:27, 23 May 2019 (EDT)
We could use publication record numbers to determine the order in which issues were entered. However, there is no guarantee that magazine issues are necessarily entered in the order of their publication.
Having said that, it may be possible to piggy back on FR 1202, "Add fields for magazine issue numbers to pub records":
  • Add the following new fields for magazine issue numbers to publication records: Volume, Issue, Whole Issue. On the data entry side, we could have a single line for capturing this information, e.g.:
  • Volume: [field] Issue: [field] Whole Issue: [field]
For example, the proposed "Whole Issue" field could support the "|" format, which we currently use for page numbers. The first part of the value would be displayed to our users. The part after the "|" character would be a "sorting" value used to create "Previous" and "Next" links. Ahasuerus 10:45, 24 May 2019 (EDT)

Change ID

Good evening. I am sure this is covered somewhere but cannot for the life of me find the article. How can one go about changing their username on this site? Thanks in advance. Zybahn 23:22, 28 May 2019 (EDT)

I am afraid the ability to change user names is not supported by the ISFDB software. Ahasuerus 00:03, 29 May 2019 (EDT)
Personal tools