Rules and standards discussions/Archive/Archive13

This is an archive page for the Rules and standards discussions page. Please do not edit the contents. To start a new discussion, please click here.
This archive includes discussions from January - December 2015‎.

Archive Quick Links
Archives of old Rules and standards discussions.

1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 14 · 15 · 16 · 17 · 18 · 19 · 20 · 21

Expanded archive listing

Currency standards

A question arose about how to enter Italian lira, and I was made aware that our current standard wasn't documented. So I went to update the Price field template, and saw that several currencies which are in the database have not been documented. It was searching for how euros are entered when I discovered that there are two different methods used in the database. Some editors leave a space after the euro symbol while others do not. (The differences can be seen here.) Was there ever a discussion and conclusion about how euros (and other currencies) were to be entered into publication records? Mhhutchins 17:30, 28 January 2015 (UTC)

There was a discussion that went nowhere. I restate my position : there is an ISO standard for currencies that is used in the banking system : ISO 4217. Except when there is an easier to use sign ($ instead of USD, € instead of EUR, £ instead of GBP, etc.), I don't understand why we have to reinvent the wheel and to create our own codes. As the official standard was seemingly rejected, it looks like the local usage (or even a personal approach) for each country had taken precedence (that's why I enter french prices as "F8.88"). Hauck 17:46, 28 January 2015 (UTC)

So do we enter a space or not? That was the question, not what symbol to use. Mhhutchins 17:52, 28 January 2015 (UTC)

Read the article. Hauck 17:54, 28 January 2015 (UTC)

As uncooperative as ever. The time you spent responding could have been used to type a single word. Mhhutchins 18:13, 28 January 2015 (UTC)

From the article: "The ISO standard does not regulate either the spacing, prefixing or suffixing in usage of currency codes." So back to square one. What was the point of linking to the article when it doesn't answer my initial question? Mhhutchins

I've always used (not only at the ISFDB but everywhere) the Rules for expressing monetary units by the European Publications Office, which is no world-wide standard but used for their publications, and which is mentioned in reference 5 in the ISO 4217 Wikipedia article. According to that there's no space after the € symbol ("€9.00"). However, if you use the letter ISO codes, there is a space ("EUR 9.00"). This is a European-Union-only rule, though. On the other hand, why complicate things and have different rules for different areas and sometimes spaces and sometimes not. What for? Why not simply say "currency before price and no spaces" and that's it, no matter if $ or € oder EUR or USD etc etc? I think everybody is capable of reading the price and currency correctly, even if its format doesn't stick to someone's local rules. Hitspacebar 19:06, 28 January 2015 (UTC)

Spaces in already entered price could then easily be removed by an SQL and filtered when making new submissions. Moreover, the display of the prices could be adjusted to what looks better or is better readable, e.g. by adding a space before the first number of a price on-the-fly (again, for display only). Hitspacebar 19:19, 28 January 2015 (UTC)

...and regarding the manifold rules for decimal and thousands separator and currency symbols I'd suggest to separate price and currency into two different database fields in the long-run, price becoming a float then and currency either a text field or, maybe even better, a drop down box. Then you wouldn't need a lot of these rules (and could display the values based on the user's locale information). Hitspacebar 19:44, 28 January 2015 (UTC)

I do enter Euro prices with a space ("€ 9.00"). I have no objection against dropping the space, but it arose from the german predecessor currency: DM 9.00 not only looks more comforting (at least to my eyes) than DM9.00, it also seems to have been the standard to enter a space on all german publications that I know of, so I would like to speak against dropping the space for all currencies. Stonecreek 20:45, 28 January 2015 (UTC)

I agree with Christian in this case. If a currency symbol is used, there is no need for a space. But in using alternate forms like "DM" or "Lit" or "Yen" a space is practically dictated. Mhhutchins 21:00, 28 January 2015 (UTC)

I agree with Michael. It's the same conclusion we reached four years ago. --Willem 21:28, 28 January 2015 (UTC)

Though I think my idea is better I'm fine with that. And I must repeat what I wrote above: the amount of a price is a number and should not be a text field but a separate float field. Refactoring the software that way would make a lot of the currency rules and discussions superfluous. Jens Hitspacebar 21:43, 28 January 2015 (UTC)

I agree with using the "Rules for expressing monetary units" on spacing: No space after a symbol; space after abbreviations and acronyms. I agree with Hitspacebar on creating a Feature Request to change the price to a pair of fields with one being a "number", which the user could see in the style their preferred language uses. Chavey 05:54, 29 January 2015 (UTC)

(outdent) I also agree with no space after a symbol and space after abbreviations & acronyms. -- JLaTondre (talk) 22:10, 29 January 2015 (UTC)

I agree with no space after a symbol and a space after abbreviations etc. Re: splitting the price field - I don't think that is a good idea. We enter the price of a book as a means for distinguishing different printings, not because we want to actually record a monetary value. That is the reason why the price is a text field that is left to human interpretation - for instance, it allows to enter stuff such as "3/6" or "5/-". Read the help text about the Price field, notably the information about old British prices. Patrick -- Herzbube ^Talk 09:40, 30 January 2015 (UTC)

It looks like there are two related feature requests (FRs) here. The first FR is to split the data entry field for the Price data element in two, one for the currency symbol/abbreviation and the other for the numeric price. I can see how it would be desirable if we could convert the first field into a drop-down list similar to our list of bindings.

The second FR is to force the "numeric price" part of the current Price field to be a number. As Patrick points out above, it won't work too well with "5/-" and similar non-decimal values. In addition, I don't think it would add value to our data. Numbers are needed if you want to add, subtract, multiply, etc, but we don't do any of that with our prices. Ahasuerus 15:23, 30 January 2015 (UTC)

If I thought my original post would lead to a discussion and a feature request to change the nature of the Price field, I'd never posted it. To space or not to space, that was the question. How that evolved into a discussion about the addition of a new field and changing the field from text to numeric is typical of the way rules and standards discussions go off into tangents. I will update the documented standards about the use of a space in the price field, because we've reached a consensus. As for the other part, maybe a new topic should be started. Mhhutchins 16:59, 30 January 2015 (UTC)

Well, if we create a new field for the currency symbol/abbreviation part of the Price field, then we can let the software handle spacing issues. I will need to examine what's currently stored in the database to see whether it would be viable. Ahasuerus 20:48, 30 January 2015 (UTC)

I hadn't thought about the "2/-" format issue. It may still be worth separating the symbol (or symbol/Acronym?) into a separate field with pull-down options. But I think what we would gain from having the second part be a numeric field (the user option of seeing 5.95 vs. 5,95) isn't worth the problems of dealing with "2/-". Chavey 06:08, 31 January 2015 (UTC)

It's also my opinion ISFDB should define its own standard: always a space between currency sign and value, dot as separating mark and currency sign before price: € 10.00, DM 10.00, $ 10.00 usw.. All is easy and consistent, no errors, no problems, like Hitspacebar wrote above.--Wolfram.winkler 15:52, 28 May 2015 (UTC)

Creating a standard for the Legalname field

This discussion was copied from an editor's talk page, because I felt it deserved a group consensus to arrive at a standard.

Please start a discussion to create a standard about how to enter the romanized version of Japanese names. I suppose this can also apply to other alphabets as well. Or there may already be a documented standard which I'm unable to find. It should be added to this help page template. I've accepted submissions today that do it differently, and it should be standardized before it gets more complicated. Thanks. (I left this same note on the talk page of the other person updating authors' data.) Mhhutchins 21:13, 31 January 2015 (UTC)

Hi, Mark (he means "Mike") left this note on my page too. I enter Japanese legal names as '大江健三郎 (Ōe, Kenzaburō)', while you do it as 'Iino Fumihiko / 飯野文彦'. My choice is based upon what I think the author would consider his/her legal name and than giving a translation in English of that name when it is needed to transcribe the name due to the different alphabet used. You may have perfect valid reasons to choose your method as well, but me must create a standard as Mark (he means "Mike") states above, so please let me here your arguments.--Dirk P Broer 23:41, 31 January 2015 (UTC)

And let me add that the format that I use was not invented by me, I mostly merely copy the content of Wikipedia about the legal name of (in this case Japanese) authors.--Dirk P Broer 23:49, 31 January 2015 (UTC)

I was doing it based on records I had already seen in the database (I did not want to invent anything but apparently even this is not formally accepted here yet). I too believe the native script format first is better (though I am not a fan of using parenthesis to delineate. Since Japanese names are traditionally presented '<surname><given name>' with no delineation between them (and with no other names), I believe '<surname> <given name>' is the best compromise (i.e., with a single space for delineation; this format can be seen in many native Japanese contexts too; e.g., Japanese Wikipedia typically has the page named in an undelineated format but uses a bolded space delineated format in the first part of the lead section). I believe the Western '<surnames>, <given names>' format was devised because there are cultures with multiple surnames and given names (Mexican comes to mind where I hear two of each is standard/commonplace). Even the NDL uses '<surnames>, <given names>' in their authority control. Uzume 00:25, 1 February 2015 (UTC)

What are we going to use as standard: '大江健三郎 (Ōe, Kenzaburō)' or 'Iino Fumihiko / 飯野文彦'? The parenthesis in the first are used to distinguish two type of alphabet (which in this case is more clear than in e.g. Romanic and Cyrillic). To avoid a tangle of standards I have taken the English Wikipedia as example, where '大江健三郎 (Ōe, Kenzaburō)' is used to make it easier for people not able to speak or read Japanese to comprehend what the name is, both in original language and transcribed. Yours truly, Broer, Dirk Pieter...--Dirk P Broer 20:49, 1 February 2015 (UTC)

I've copied this discussion to a community page. I've just accepted a submission that changed the Legalname field from "Tanaka Kōtarō / 田中貢太郎" to "田中貢太郎 (Tanaka, Kōtarō)". There must be a consensus reached by the group to avoid each of you changing the other's format. Mhhutchins 04:32, 2 February 2015 (UTC)

I asked the Japanese department faculty at my College. (Both are native Japanese speakers.) They wrote:

Ms. Ogino says: "I believe that 大江健三郎 (Ōe, Kenzaburō) is fine. Iino Fumihiko / 飯野文彦 is fine, too, but we need to put a comma after "Iino."

Ms. Furukawa says: The standard is to include a comma between last and first name when the person is writing/publishing in English but not to when they are publishing in Japanese. In the first case Darrah references, the choice seems to have been made to make it easier for a non-Japanese audience to determine which is the first and which is the last name. This isn't standard in Japanese studies, but, ultimately, as long as there is consistency throughout the referring source, either order is acceptable.

It seems to me that first format is more appropriate, although I personally prefer to use the "/" separator, as WorldCat does, than to use the parenthesis. Chavey 21:07, 2 February 2015 (UTC)

Thanks for checking, Darrah!

Another way to handle this issue would be to add a separate field for romanized/transliterated legal name. It wouldn't take long since legal names are only used in Author records. Ahasuerus 23:37, 2 February 2015 (UTC)

(unindent) That might be a good solution. I also asked the professors about a preference in ordering between Kanji and Romanji. They both said that there isn't a preference. One of them expanded:

I guess that it depends on a writer, a paper/book and a publisher. For example, if the major part of the paper/book is written in Japanese, a writer and/or a publisher expects his/her readers understand Japanese and would write his/her name in Japanese first. However, if the paper/book is written in English, a writer and/or a publisher may put his name in Romaji assuming that readers just want to know how to pronounce the author's name. Kanji supplies extra information to someone who understands Japanese.

Since the Kanji provides extra information, and since we are generally talking about writers who write primarily in Japanese for a Japanese audience, my take-away is that the Kanji should come first. Chavey 03:45, 3 February 2015 (UTC)

Don't forget we're talking about the Legalname field which has nothing to do with a publication. It's only displayed on an author's summary page. And the ISFDB standard is to enter it as LASTNAME, FIRSTNAME MIDDLENAME. That format shouldn't be changed regardless of the alphabet. That doesn't mean you can't include different forms of the name (preferably separated by a slash or pipe), but the format should remain the same. Mhhutchins 03:59, 3 February 2015 (UTC)

The concept of "LASTNAME" is ambiguous in languages which reverse the order of personal and family name. If by "Last Name" we mean the name that comes at the end when the person writes their name down, then that refers to the personal name of writers from Hungary, Japan, etc. If by "Last Name" we mean the family name, i.e. the part of your name shared with your parents, then by "Last Name" we would mean the thing that they write down FIRST when they write their name down. It appears that in previous discussions of this topic, "LASTNAME" has been interpreted to mean the Family Name, NOT the "Last Portion of the Name". But I haven't found any place that explicitly says that's what our standard is. Chavey 06:47, 3 February 2015 (UTC)

I don't think there's any confusion that LASTNAME means your family name or surname, FIRSTNAME is your first given name, and MIDDLENAME is your second given name. Based on those standards, the Legalname field of Haruki Murakami should be entered as "Murakami, Haruki" since Murakami is his family name and Haruki is his given name. The point of my question to the two editors who were entering names in the Japanese alphabet differently, and any other editor who wanted to participate in the discussion, was to come to an understanding of how to enter the author's name in Japanese, not the romanized name, which has already been established. So should Murakami's Legalname field be entered as "村上春樹 / Murakami, Haruki" or "Murakami, Haruki / 村上春樹" or "村上春樹 (Murakami, Haruki)"? It was an attempt to standardize the format for entering both the romanized name and the name used by an author working outside the Latin alphabet, and wasn't intended to change the established standard for authors whose legal name uses the Latin alphabet. Mhhutchins 08:02, 3 February 2015 (UTC)

Well, I gave my opinion on that. But I wish we used the terms "FamilyName" and "PersonalName" in our standards instead of "LastName" and "FirstName". Chavey 05:15, 4 February 2015 (UTC)

I recall that issue was brought up in the past, but nothing ever came of it. Of course, I'd never be able to find the discussion. (Is there a help page on how to search the Wiki? I can rarely can "find" anything using the "Find" box.) Mhhutchins 05:45, 4 February 2015 (UTC)

The name of the "Last Name" field was changed to "Family Name" in September 2014, but I don't recall a request to change the "Legal Name" field. Since it's a single field which is used to record first, middle, last, etc names, I suspect that whatever data entry standard changes we decide on will need to be enforced as a matter of policy rather than in the software. Unless, of course, we decide to break it up into multiple fields like "Legal family name" etc. It wouldn't be that hard to do, but would it be desirable? Ahasuerus 05:59, 4 February 2015 (UTC)

(unindent) I am sorry I have not had time to address such things recently (work has become oppressive lately). I fully intended to bring this topic here. I am not a fan of using parentheses and would rather use a single delimiter/separator (I am not convinced it needs to be a "/" but Worldcat's usage seems to be a good precedence). I also believe we need to adhere to "<family names>, <given names>" in both native/non-roman script and its romanization (I admit I was not doing this before with regard to Japanese author records). Since we are talking about including romanizations we need rules on the romanization method to be used as well. Perhaps we can look at something like ALA-LC romanization or what the NDL is using: e.g., Kenzaburo Oe (link labelled with the name from our DB). Notice they use more than one romanization format (dig around in the RDF and JSON links at the bottom): Oé, Kenzaburō and Ooe, Kenzaburo. It should be noted that even native Japanese cannot definitively pronounce kanji (Chinese characters). This is why even the NDL keeps kana (e.g., オオエ, ケンザブロウ for 大江, 健三郎) in their database so they can collate records. This means any romanization scheme needs to be based on the kana and not the kanji (even though kanji is often used, including in legal names). Uzume 16:04, 13 February 2015 (UTC)

I have been thinking about various romanization issues for the last couple of weeks. As previously discussed, one thing that makes agreeing on a single standard difficult is the sheer number of different romanization schemes and formats. As Uzume noted above, "Kenzaburo Oe" may also be transcribed as "Kenzaburō Oé" or "Kenzaburo Ooe". Cyrillic presents similar issues as discussed elsewhere.

Perhaps the best way to address this conundrum would be to follow Yogi Berra's advice: "When you come to a fork in the road, take it" ;-) In this case it would mean letting editors enter multiple romanizations for each canonical name, legal name, title, etc record. Eventually we would have "Kenzaburo Oe" and "Kenzaburō Oé" and "Kenzaburo Ooe" associated with "大江, 健三郎". It doesn't even need to be limited to "romanizations" -- it could be used as a more generic field to store other transliterations like hiragana/katakana ("オオエ, ケンザブロウ" above). From the programming standpoint, it wouldn't be that hard to implement, although we'll probably want to do it one record type (authors, titles, publisher, etc) at a time. And, of course, these fields will be optional. Ahasuerus 12:10, 18 February 2015 (UTC)

I think the original question can be addressed without dealing with the issue of multiple romanizations.... It doesn't matter to me, but it seems we have existing precedent in other fields/records to help guide us. If the native + romanized versions are two "values", then elsewhere we use "/" as a separator in similar situations. If the romanized version is explanatory (sorry, give me some leeway on that term) or otherwise "extra", then elsewhere we use parentheses in similar situations. My gut tells me it would be better in the long run to think of legalname as legal-in-the-person's country, avoiding trying to accommodate how that name's presentation varies when the person is referred to in different jurisdictions. That treatment would then imply that romanization here is explanatory/extra, suggesting we use parentheses. --MartyD 15:48, 18 February 2015 (UTC)

Was a consensus/decision reached? Perhaps I missed it. I agree this topic was originally just about legal names and I still want to do "<family names>, <given names> / <romanized family names>, <romanized given names>" (but I am open to parenthesis if necessary; I say "names" because there are situation where people have multiple both family and given names, e.g., this is not unusual in Mexico).

As for romanization schemes, though we can have them all (i.e., take the fork when presented), I do believe we need some standardization. For example, when I start putting in lots of Japanese material, one would hope those authors works would start to topple the "main" author name towards their native non-Roman script. Under this situation, how do we collate them? I doubt you could effectively have kanji in the author directory and even if you could figure out a way--native speakers would not find it that useful either as they depend on the pronunciation which is not specified in the common written kanji form but instead need kana for such things. So do we have author directories on a per language basis? Not a bad idea but we need to address the question. Uzume 01:39, 26 March 2015 (UTC)

Different editors are using different methods to entering data into the Legalname field. Until a standard has been established, I will not be moderating submissions to update this field when it is adding non-roman names. Mhhutchins 00:53, 27 March 2015 (UTC)

Example: Dirk uses this format: "京極夏彦 (Kyôgoku, Natsuhiko)" while another editor (Uzume, I believe) uses "Kyōgoku Natsuhiko / 京極夏彦" I don't want to get into the middle of an editing battle. Mhhutchins 01:06, 27 March 2015 (UTC)

If there is no objection, I will start working on upgrading the "Legal name" field to support multiple values similar to the way we support multiple email addresses and Web pages. It will be a useful test case for the larger issue of transliterations. It will also let us support multiple alphabets like kanji, hiragana and katakana as well as various special cases. For example, Pavel Amnuel was born in Soviet Azerbaijan and moved to Israel in 1990, so it will be nice to be able to give his legal name in Cyrillic, Hebrew and Latin. Ahasuerus 02:09, 27 March 2015 (UTC)

Shouldn't there still be a standard entry format, regardless of the alphabet or the language? Considering the conflict here is from the same alphabet and the same language, shouldn't they agree? I brought up this issue a couple of months ago, with a simple request to create a standard entry format and as it slowly devolved into a discussion about alphabets, I backed away. Can't we get back to the original issue? I don't think adding support for other alphabets is the issue here. Mhhutchins

To use the example that you gave above, we have the following unresolved issues:

Which transliterated form should we use, "Kyōgoku Natsuhiko" or "Kyôgoku Natsuhiko"?
Should "京極夏彦" appear first or should its transliterated form appear first?
For languages that put the family name first, should we separate the family name and the given name with a comma?

Once we implement the ability to enter multiple legal names, issue 1 will go away since editors will be able to enter "Kyōgoku Natsuhiko" and "Kyôgoku Natsuhiko". Issue 2 will also go away because different forms of the name will be entered in separate fields. Only issue 3 will remain and will need to be addressed at the policy level. Ahasuerus 05:04, 27 March 2015 (UTC)

I'm sorry that I just don't understand why we need to do all that you suggest before establishing an actual standard. Shouldn't the software be built around the standard instead of the other way around? Mhhutchins 04:05, 10 April 2015 (UTC)

I guess it depends on the standard. In many cases our data entry rules/standards were created as workarounds for pre-existing software limitations. As these limitations are lifted, one by one, the need for related standards goes away. Ahasuerus 19:39, 10 April 2015 (UTC)

At the moment, this does nothing to address the current situation with different editors offering their competing versions of what should go in the field. See this held submission. Can we at least decide on a temporary standard? It seems it would be easier to convert data after the software changes you suggest has been implemented if we can establish the standard now. If it cannot, I'm willing to drop the whole issue and just not handle any submissions that update the legalname field. Mhhutchins 04:05, 10 April 2015 (UTC)

I hope to wrap up these changes this weekend and then we can sort out the data. There are only a few hundred affected author names at this time, so it's not too bad. Ahasuerus 19:39, 10 April 2015 (UTC)

I have released my hold on the submissions, and will not moderator any future submissions of the sort until a clear standard has been created. Again, I see no reason why a standard can't be created before any software changes, but I'll let it go. I've already wasted too much energy on the matter. Mhhutchins 03:18, 12 April 2015 (UTC)

Well, choosing one side in a debate, even temporarily, can make the other side unhappy, so it's safer to paper it over :)

In related news, I am still working on the changes since I was distracted by the issues reported by Hitspacebar. I also had to change my design half way through, but the final result should be better for it. Ahasuerus 02:19, 13 April 2015 (UTC)

Clarifying Title Case

Concerning the regularizing of titles, please review the Title Heading for the content section, sub-heading Case. Currently it states: Regularized case means that the first word is capitalized, and all later words are also capitalized except for... When editing titles, I always make the last word capitalized as I'm sure must of you do, and this may very well be the ISFDB standard since this instruction infers it, but with the following list of words specified for lowercase only, this leaves the door open to interpretation of such (fictitious) titles as: A Body to Die for, or, Whence Are You from. I suggest rewording this instruction to: Regularized case means that the first and last words are capitalized, and all other words in the title are also capitalized except for... Wording it this way closes that loophole. Comments? Syzygy 19:11, 11 February 2015 (UTC)

You're correct. I'd assumed that was already documented. Maybe the person who wrote it thought it was implied. I'll make it explicit. Thanks. Mhhutchins 17:10, 12 February 2015 (UTC)

Clarifying the fate of into/Into

In a related subject as stated above, I have done a quick search of the word "into" in fiction titles and found that about half are capitalized and the other half is not, not counting situations such as First word, After a colon, etc. (Editors, please initiate your own searches since I am incapable of generating a proper link due to lack of skill.) Currently, this word is excluded from the list noted in the sub-heading Case. That means half follow the instructions capitalizing it, and the other half does not, leaving it in lowercase. I am guilty of the latter, since I am accustomed to doing it that way. Apparently I'm not alone. I find that the word "into", being a preposition and closely related to the prepositions "from" and "with", should not be capitalized. Since ISFDB follows no particular form of style, this is open to debate. I am for the inclusion of the word "into" into the list of exempted words for capitalization in titles. Comments? Syzygy 19:11, 11 February 2015 (UTC)

Here are the main rule options used in the U.S., slightly simplified:

Associated Press rules: Capitalize the first word of the title, the last word of the title, and all “principal” words (nouns, pronouns, verbs, adverbs, adjectives, and subordinating conjunctions), and all words longer than three letters (which includes most prepositions).
Chicago Manual of Style: Capitalize the first word of the title, the last word of the title, and all nouns, pronouns, verbs, adverbs, adjectives, subordinating conjunctions, and a few conjunctions. Lowercase articles (a, an, the), coordinating conjunctions (and, but, or, nor, for, yet, so), and the "to" in a verb infinitive. Prepositions are (essentially) never capitalized, regardless of their length.
US Government printing office: "Capitalize all words in titles of publications and documents, except a, an, the, at, by, for, in, of, on, to, up, and, as, but, it, or, and nor." Notice that this means that all words of length 4 or more are capitalized.

I recommend that we go with one of the standardized rules, instead of constructing our own and modifying it at will. IMO, the Chicago Manual of Style is not the best of the "standardized" rules to use. We're fairly close to the US Government printing office, but we disagree with them on lowercasing "from" and "with" and uppercasing "up", "as", "but", and "nor". Chavey 22:28, 11 February 2015 (UTC)

Thanks for your input, but perhaps I didn't make myself clear in my ramblings above. My intent in posting this section is to get clarification and consensus on the word "into" in fiction titles, not to adopt a particular form of style. The argument is simple: Keep the word "into" exempt from the lowercase list which means it should be capitalized in titles, or add the word "into" to the lowercase list, which means it appears as lowercase in titles. I prefer the latter because to me it appears more aesthetic when displayed. Sorry if this sounds like an attack on your suggestion, it's not, chalk it up to my lack of good communication skills. I just want to stay focused with the issue at hand, which is "Into", or "into". Either way, about half the titles with this word will be nonconforming. Syzygy 21:01, 13 February 2015 (UTC)

I believe it should not be added to the exception list, meaning that it should be capitalized anywhere in the title. Since that's the current standard, if anyone sees "into" in a title, it should be updated to capitalize it. There are probably other four-letter words that have confused some editors. For example, I see "than" quite often. It should be capitalized as well. Thanks for bringing this to the group's attention. Since there's been little response from the group, it's probably an unspoken belief that we continue using the current standard. Mhhutchins 07:42, 14 February 2015 (UTC)

I agree that "Into" looks better than "into". Ahasuerus 17:32, 14 February 2015 (UTC)

To clarify my earlier remark, they included my preferences that all words of length 4 or longer should be capitalized. Including "Into". I just thought I should give some documentation about my preferences. E.g., I don't like "Chicago". Chavey 01:46, 15 February 2015 (UTC)

Okay, 'Into' it is. Guess I'll just have to break myself of the habit of making it lowercase:) Syzygy 17:21, 16 February 2015 (UTC)

Is Tumblr a valid source for cover art credit?

This post is because of a discussion on my talk page copied below:

The Best of Henry Kuttner - Cover artist

Hi, I found the cover artist for The Best of Henry Kuttner. It is Dean Ellis.--Dirk P Broer 07:49, 18 February 2015 (UTC)

No. You found a tumblr page which sources another tumblr page which sources another tumblr page which credits the work to Dean Ellis. I could create another tumblr account and credit it to myself. IMHO, there should be a more reliable secondary source before adding this credit to the ISFDB record. But I'll let the PV editors debate that point. Mhhutchins 18:07, 18 February 2015 (UTC)

Well, someone has changed the record, so my post was a waste of time. Time for me to open a tumblr account. I could add a lot of publishing credits to my resume. Mhhutchins 17:04, 20 February 2015 (UTC)

I think the question is, do we trust a tumblr post as source of cover art credit. The link above seems sure, but another post on flickr by our fellow-editor Horzel states "Cover art probably by Dean Ellis, obviously for "The Proud Robot".". I think in this case we should not credit Dean Ellis, but add the suspected credit to the notes. Opinions? --Willem 20:09, 20 February 2015 (UTC)

No. Mhhutchins 22:34, 20 February 2015 (UTC)

Ditto. Blogs can't be trusted. The bane of social media: anyone can pretend to be anyone. [ ... and I didn't change the record in question]. --~ Bill, Bluesman 15:29, 21 February 2015 (UTC)

Since Tumblr is basically a collection of personal Web pages, micro-blogs etc, I think it would be best to evaluate their reliability on a case by case basis. For example, if Dean Ellis' son maintained a Tumblr page with images of his father's works, we would consider it a reliable source. On the other hand, a random Tumblr page of uncertain origin would at best deserve a passing note in the Note field. Ahasuerus 23:11, 20 February 2015 (UTC)

I agree with Ahaseurus. With the default assumption being "We don't trust a Tumblr page unless there's a good argument for it." Chavey 06:29, 21 February 2015 (UTC)

I had my information from http://70sscifiart.tumblr.com/post/111354226801/dean-ellis-the-proud-robot-1975-proud-robot via https://www.facebook.com/70sscifiart?fref=nf, searched further for mentionings of Dean Ellis connected with this illustration and managed to find those in above mentioned sites. As no other verifier objected to my message "Hi, I found the cover artist", I changed the records.--Dirk P Broer 08:59, 21 February 2015 (UTC)

BTW: Dean Ellis died, leaving behind a wife Lois and a daughter Tracey, but no son.--Dirk P Broer 11:26, 21 February 2015 (UTC)

This pub also gives a tentative "Ellis?". On the wider subject of the reliability of Tumblr there is IMHO no definitive rule. Hauck 16:56, 21 February 2015 (UTC)

Because Ellis rarely if ever signed his covers and because there is no reference of any kind, I didn't credit obvious Ellis covers dozens of times. IMHO this is Ellis. He had several stylistic clues that make a identification easy.Don Erikson 20:09, 21 February 2015 (UTC)

Reviews of audiobooks

Don D'Ammassa reviewed quite a few works in audio format for Science Fiction Chronicle, and specified this format in his review titles. I'm vague on the standard for entering reviews of audiobook editions: is the standard to enter it as a normal review, or as a separate ESSAY "Review of the audiobook..." record? (as I've been doing for instance in this issue, page 48.)

The Help is not specific on this, and it could do with some clarification. Thanks. PeteYoung 05:59, 9 March 2015 (UTC)

An audiobook is a publication format, analogous to hardcover, paperback, trade paperback, ebook, etc. Reviews of titles which are eligible for the database are entered as REVIEWs, regardless of their publication format. Reviews of titles which are not eligible for the database are entered as ESSAYs, regardless of their publication format. Mhhutchins 06:09, 9 March 2015 (UTC)

This standard comes from the "Reviews" subsection of the What to Include section of the ISFDB Policy page. Mhhutchins 06:14, 9 March 2015 (UTC)

BTW, Locus has had a regular column which reviews audiobooks for a number of years now. Look at the summary page for Locus columnist Amy Goldschlager. Mhhutchins 06:17, 9 March 2015 (UTC)

OK, thanks for the clarification. We'll need to go back and revise a few entries. PeteYoung 06:33, 9 March 2015 (UTC)

SERIAL titles

Help:Use of the SERIAL type currently says:

Title. A parenthetical statement such as "(Part 1 of 3)", preceded by a space, is appended to the title. When a novel length work (generally over 40,000 words or so) is published in a single issue of a magazine or other periodical, the parenthetical statement "(Complete Novel)", preceded by a space, is appended to the title.

Of the 9,268 SERIAL records that we have on file, over 9,000 follow this rule. The remaining 229 SERIALs do their own thing. I was going to create a cleanup report to find these miscreants, but then I took a closer look and decided to start a Rules/Standards discussion to determine what to do with the following unusual cases:

SERIAL titles that record the title as is appears in the magazine, e.g. Newton Braddell and His Inconclusive Researches into the Unknown: In the Mountain of Sanity or Butterflies in the Kremlin, Part Eight: As the Bear Turns.
Composite SERIAL records meant to represent all parts of a serialization whose details are not known, e.g. the note field of The Flying Boys; Or, Three Thousand Miles on Wings (10 Parts) says "First appeared in the April 18 through June 20, 1891 issues of "Golden Hours"."
Oddball cases like Incontro su Tuscarora (Complete Collection), which was used to represent a collection of linked stories subsequently published in an Italian magazine. Normally I would argue that the magazine pub should list individual stories, but this was an unusual case in that the stories were not given separate titles and appeared as "a novel, but composed of separate parts".

The first case listed above is the most common, so I guess the first question is whether we want to amend the SERIAL title rule to be similar to the way we treat introductions, e.g.:

If the title of a SERIAL part is unique, e.g. "Butterflies in the Kremlin, Part Eight: As the Bear Turns", then use the full form of the title. If the title is shared by all SERIAL installments, append a parenthetical statement such as "(Part 1 of 3)", preceded by a space, to the title.

Ahasuerus 02:51, 10 March 2015 (UTC)

Sounds like a reasonable change to comply with the current practice for #1. The records entered as #2 are the inevitable exceptions that must be made to avoid creating multiple MAGAZINE records, and I can live it. But I would argue that #3 should have been typed as a COLLECTION instead of a SERIAL. Even if there were no individual titles given in the translation for the stories (we have plenty of COLLECTIONS that show no contained titles), typing it as a SERIAL and varianting it to a COLLECTION rubs too much against ISFDB rules. It should have shown up on the clean-up report that finds mismatches of types between variants, but was probably dismissed. (I'm assuming that the script finds SERIALs varianted to anything other than NOVEL, but I could be wrong.) Mhhutchins 04:14, 10 March 2015 (UTC)

At this time the "Variant Title Type Mismatches" report looks for SERIALs varianted to anything other than NOVEl, SHORTFICTION or COLLECTION. We could certainly tighten it up if we decide that SERIALs whouldn't be made into variants of COLLECTIONs, but then we would need to change the cleanup logic to allow COLLECTIONs within MAGAZINEs. Ahasuerus 05:52, 10 March 2015 (UTC)

There are already COLLECTIONs contained within MAGAZINE-typed records, such as this one. (There are even ANTHOLOGYs like this one.) Not ideal, but it was the only available option when it was determined that certain publications (mostly European, like Urania) should be typed as MAGAZINE instead of ANTHOLOGY series. If these ever appeared in a cleanup report, I missed them, or perhaps they were "ignored". They're relatively rare so that an exception should probably be made. Mhhutchins 06:23, 10 March 2015 (UTC)

(unindent) So, any objections to the proposed change? Here it is again:

If the title of a SERIAL part is unique, e.g. "Butterflies in the Kremlin, Part Eight: As the Bear Turns", then use the full form of the title. If the title is shared by all SERIAL installments, append a parenthetical statement such as "(Part 1 of 3)", preceded by a space, to the title.

Ahasuerus 18:06, 13 March 2015 (UTC)

None here, as that seems to be the current practice. Is there a way to find any in the database that do both, i.e. have unique titles and disambiguation? Mhhutchins 18:18, 13 March 2015 (UTC)

Sure, I can create another cleanup report to find them. Ahasuerus 18:53, 13 March 2015 (UTC)

Done and done. The new cleanup reports will be accessible once I finish the current ad hoc run of the nightly job. Ahasuerus 01:23, 14 March 2015 (UTC)

Help for the Transliterated Legal name field

Based on the recent discussion on the Community Portal, I have put together a draft version of the Help template for this field. I know very little about Chinese, but hopefully I got the Chinese example right. Ahasuerus 01:16, 19 April 2015 (UTC)

Fan-published books

One of Linguist's recent submissions would add a Russian translation of Max-André Rayjean's Le zoo des Astors. The issue here is that this 1966 translation was apparently never published and circulated privately in manuscript, i.e. in "Samizdat". There is an online catalog of these fan/Samizdat translations, which lists hundreds of titles, so we need to decide whether they are "in" or "out" -- see this discussion for details. Some of them were published by regular publishers in the 1990s, but some remain unpublished.

My tentative take on it is that these fan translations should not be added unless they have been published as books. I note that even the Russian site FantLab shows 1991 as the year of first Russian publication of Asimov's Foundation even though the previously linked catalog indicates that a Samizdat translation was available in the 1980s. Ahasuerus 17:14, 26 April 2015 (UTC)

Out. Hauck 18:08, 26 April 2015 (UTC)

Out. (Or I can find an old mimeograph machine and fill this database beyond capacity.) Just because it exists, doesn't mean it was "published". (That's been the argument why ARCs shouldn't be in the database.) Mhhutchins 18:39, 26 April 2015 (UTC)

Request for making an exception in the current rules concerning webzines

Copied from the user's talk page:

ISFDB's inclusion policy on webzines

As stated in our Rules of Acquisition:

Works published in a web-based publication (webzine) and available only as an HTML readable file are not eligible for inclusion with the following exceptions:

It is published by a market which makes the author eligible for SFWA membership (listed here).
It has been shortlisted for a major award. (This last may include works which are self-published by an author on their own website. Otherwise such works are not eligible.)

Under this policy Perihelion Science Fiction doesn't qualify for the ISFDB. If you'd like to present a case in changing this policy please start a discussion on the Rules and Standards Discussion page. Thanks. Mhhutchins 18:13, 30 April 2015 (UTC)

Ezines: Perihelion Science Fiction

With respect, you are citing Rules of Acquisition that apply to stories. From what I read, those rules have long since been amended and online magazines, eZines, webzines, are currently acceptable.

So, having read everything I can find here concerning ezines, I would request Perihelion Science Fiction[1] be reconsidered for inclusion. The Internet is a formidable means of communication now, perhaps even eclipsing print media. I understand the earlier questions concerning the impermanence of cyberspace. However, I religiously maintain every issue of Perihelion that has ever been produced. I'd be more than happy to work with ISFDb staff making my archives available in some fashion. The ezine version of Perihelion has an ISSN, has been regularly published on a monthly basis for close to three years, and pays semi-professional rates. We have published stories from many award-winning authors. I believe any concerns over the "reality" of ezines has long since passed. They are as popular, stable, and accessible as print magazines ever were.

Furthermore, Perihelion was established by the same editorial staff in 1967 as a print periodical and is listed in the ZineWiki pages[2]. The current ezine is the resurrected online version of the magazine upgraded to semi-professional status. EdPerihelion 20:28, 3 May 2015 (UTC)

We make a distinction between a webzine and an ezine with the latter being available offline (thus more stable) in electronic form, and having the ability to be read on an ebook reader. While I understand you feel that your webzine may be exceptional enough to be allowed under the current rules, I can't see how allowing the exception would prevent other webzines from making the same claim. Perhaps you can suggest a change to the current rules that would allow Perihelion SF into the database, but continue to exclude most webzines. It would go far to help your case. Or perhaps your point is that we're being provincial in the exclusion policy toward webzines, that no distinction be made with web-based publications, and that the standard be removed entirely?

BTW, I could find no issues or an archive on your website which goes beyond the past four months. Are issues removed after a certain period? Mhhutchins 23:03, 3 May 2015 (UTC)

Due to contractual policy, links to issues older than six months are removed. But the issues still exist! My first point is that I would be more than willing to work with ISFDb for access, perhaps limited exclusively to this site. My second point is that the Internet is rapidly replacing print altogether. I don't see eBooks as viable options for eZines because they require two distinctly separate production models (unlike eBooks and print books) which can be cost prohibitive for the small publisher. If I may be frank, your current rules favor the big publishers with deep pockets. Electronic media have opened the door to the small presses that afford opportunities for many good, new writers to get a start. I should think ISFDb would want to help here, not hinder. Magazines, whether print or electronic, come and go all the time. I do understand the "ephemeral" nature of eZines might be scary; anybody can create an eZine for one or two issues. I might suggest that professionalism and dedication be two criteria: has the eZine been regularly published for a specified number of years; is the eZine more than a vanity website; does the eZine publish work by "established" authors; does the eZine pay something at least; does the eZine have an ISSN number; does the eZine have a basic reputation in the science fiction community. All of these points are easy to verify and can go a long way toward qualifying an eZine listing in ISFDb. EdPerihelion 01:46, 4 May 2015 (UTC)

You're asking that the policy be changed so that essentially all webzines (again, distinguished from ezines) are allowed into the db based on quite subjective criteria, which different moderators could possibly interpret differently. How many works creates an "established" author? Does "pay something at least" mean a quarter-cent per word? How would one measure a webzine's "basic reputation in the science fiction community"? Anyone can obtain an ISSN who takes the time to complete the application. What worries me more than anything about allowing Perihelion into the database is that any issue older than six months no longer exists. (Or have I mistaken what you're saying?) What's the point of creating a database record of a publication that is no longer in existence? It was the ephemeral nature of webzines that was the rationale for the creation of certain concrete rules for inclusion in the db. If you wish to create records for stories by major authors and award-nominated works which were first published on the Perihelion website, there is a method of doing that, and I will gladly step you through that process. I wish other moderators and editors would join the discussion to provide opinions that could possibly disagree with mine, or to provide further evidence that backs my interpretation of the standards.

Also, I have to respectfully disagree that our "current rules favor the big publishers with deep pockets". Most of, and perhaps the overwhelming majority of the publishers in this database are small press. I would wager that more than half of the publishers in this db have less than 10 books. Mhhutchins 02:50, 4 May 2015 (UTC)

Well, it does seem that the back issues older than six months do exist, but possibly only on some unavailable (to the public) storage medium. That would mean, in effect, that those issues don't 'exist' anymore regarding our rules of acquisition. If there are contractual reasons for removing the back issues, would there really be a back door to make them publicly available though ISFDB? Stonecreek 03:59, 4 May 2015 (UTC)

To be short, I'm against this inclusion, mostly for the same reasons given by Michael (permanence, access, subjectivity of the criteria).Hauck 07:35, 4 May 2015 (UTC)

(unindent) In general I agree with Michael and Hervé, but let me comment re: some other issues raised above:

The first thing to keep in mind is that our goal is to catalog SF works rather than to influence ("help"/"hinder" above) the field or to anticipate where it may be moving. This means that we are usually a bit behind and have to tweak our rules to catch up from time to time. For example, 10 years ago e-books and self-published books were not eligible for inclusion, but now they are.
There is an enormous amount of self-published and fan-published SF out there that we are simply not in a position to process. There are over 440,000 ISBNs on our development server alone that are not in the ISFDB database. They are eligible for inclusion, but we simply don't have the manpower to process them, e.g. the ERB reprints published by CreateSpace on a daily basis. Although this fact doesn't affect the issue of webzines directly, it helps explain where we are coming from.
"...current rules favor the big publishers with deep pockets." Since the current rules make an exception for "market[s] which make[...] the author eligible for SFWA membership", they favor professional markets. Not all of them are run by big publishers, but while almost all (with a few exceptions -- see Hydra from Random House) big publishers are on the list, not all small publishers are. I don't see it as a problem in and of itself since, as per above, we have to draw the line somewhere. Basically, SFWA does all the heavy lifting for us, including determining what constitutes a "professional rate". However, I am concerned that the resulting list is necessarily US-centric. Perhaps we could expand it if we could identify similar lists in other countries, assuming they exist. Fodder for another discussion, I guess.
"... work with ISFDb for access, perhaps limited exclusively to this site". Given our structure and available resources, I don't think we are in a position to enter into an exclusive arrangement, especially as it relates to providing access. Also, from the bibliographic perspective the important thing is a listing of each issue's contents rather than the contents itself. One thing that you may want to consider is making all tables of contents for prior issues available online. Many online publications do that and, bibliographic considerations aside, it can be a useful marketing tool even if it may not necessarily get your webzine listed by ISFDB. Ahasuerus 19:50, 4 May 2015 (UTC)

I'm not entirely clear on this whole "issues that exist" subject. Are you saying that you have links to every issue of F&SF that ever existed? Or Analog? If you merely have them on a spreadsheet with appropriate data, I can supply the same for Perihelion. In fact, I am going to be making all tables of contents for prior issues available online, with links to stories that the authors have already requested be maintained. Perhaps it would be a good idea for me to get back to you after this database is up and running. EdPerihelion 16:23, 5 May 2015 (UTC)

Well, F&SF/Analog issues exist as physical objects and our editors have verified almost all of them. When dealing with online publications, we have occasionally captured and saved their tables of contents for the reasons outlined above. Ahasuerus 21:46, 9 May 2015 (UTC)

(unindent) I'll second what Mhhutchins, etc. has written. EdPerihelion, it would help a great detail if

If the table of contents for all back issues much like what Perihelion has the main page for the January 2015 issue were available. The contents don't need to link to the stories. We just need to know the story title and author names.
If Perihelion is not allowed to retain the full size cover art then could a reduced-size version be retained? Within ISFDB we have been using 600 pixels as the standard when scanning book covers. However, as the Perihelion artwork does not contain a price or other bibliographic information we likely could use 200 pixel high images. The February 2015 cover was painful to view at 200 pixels but worked in terms of a bibliographic record.
That the editorial credit be stated if it's not always Sam Bellotto Jr.
That the story titles, author names, and word count be available for the content published in the "Shorter Stories" section. The word count helps us code it as a shortfiction, novellette, novella, etc. per Template:TitleFields:Length. Perihelion might as well document the actual word count as other databases may have different rules for what counts as a novellette versus novella, etc.
If Perihelion ever publishes poetry, essays, fiction that is not speculative fiction, or is non-fiction either in the full length or short story sections then identify these. (I know Perihelion currently does not accept poetry but I see that Perihelion has been tweaking the wording of the submission guidelines from issue to issue (much like how we tweak the ISFDB rules periodically) and also Perihelion has "there are always exceptions to every rule" in the guidelines.)
We normally do not index graphic novels unless they were drawn/written by someone who mostly written speculative fiction. I suspect we would document Perihelion's "Comic Strips" section in the publication notes but not in the database/contents. In that case we need to know who to credit each comic strip section to. For example Comic Strip "Gory & Roddy in 'A Space Oddity Part 3'" by John Waltrip". We don't need to be able to view the comic itself.
We index reviews on ISFDB and so for each review need to know:
- Title and author of the work being reviewed
- Reviewer name
If any story or other item is accompanied by artwork then the artist name(s) and the stories they go with. We don't need copies of the artwork.
If there is any loose artwork then the artist name(s). We don't need copies of the artwork.
If an artwork has a title then the title.

In summary, we index the following information for every story, article, essay, review, artwork, etc.:

Title.
Author name(s).
Type per Template:TitleFields:EntryType.
Length per Template:TitleFields:Length.
We document the original date and place of publication if the appearance in Perihelion Science Fiction is not the first. I know Perihelion's submission guidelines says they only accept "original science fiction" but also noticed that Perihelion never mentioned the word "original" in the remainder of the guideline and end it with that rules can have exceptions.

If Perihelion Science Fiction starts charging for issues then the original list price per issue. We don't document back-issue prices.

I suspect the above would be quite workable for Perihelion Science Fiction and the authors/artists as we have no need to see or index the content of the stories nor any of the interior artwork. The cover artwork is an exception where it would be nice if a reduced size image was available. If a reduced size image involves negotiation with the artists, one at a time, then I suspect we can live with no cover images. We display the covers on ISFDB under fair use using Template:Cover Image Data (see the sections the bottom about "Fair Use Image Data" and "Fair Use Image Rationale").

The main issue with not having access to the content for older issues is that many titles are ambiguous. Per the submission guidelines Perihelion is looking for science fiction but also wants "carefully researched articles." I could not tell if Ecology by Kurt Heinrich Hyatt was science fiction or an article until I started reading it. A title such as A Taste of Oranges by Jacey Bedford could well be an article about an aspect of the tongue, nose, and brain that most people had not thought about. --Marc Kupper|talk 07:29, 11 May 2015 (UTC)

Marc, your detailed response would be fine . . . if the subject publication were eligible for the database under the current rules. But, it's clear from the discussion that Perihelion would not be eligible without changing the rules. EdPerihelion should only go to the effort of entering publication records as you have outlined if the Rules of Acquisition for webzines are changed. Mhhutchins 00:32, 14 May 2015 (UTC)

We have since added a publicly available database of all stories, artwork, articles, reviews, etc., published in "Perihelion." This database is at www.PerihelionSF.com/db/issues.php The database includes Title, Author, issue date, category. The database will be improved over time with more features, but it should be quite usable as is. We have also added an archive of every issue, complete. Due to contractual obligations, this archive is not openly accessible, but we will grant temporary passwords to qualified individuals for browsing/research purposes. All cover artwork has always been available from the cover page, and can be reproduced under "Fair Use" policies. Let me know if this helps. Thanks.EdPerihelion 21:04, 5 July 2015 (UTC)

Leave the publication price field blank for ebooks?

An editor made a suggestion of "I think prices from amazon or b&n for e-books should be left blank -- unless you're buying the book from the publisher, the price can vary and there is never a price "printed" on the book."

Leaving the price blank has some merit to me as the data file that's delivered to a customer is exactly the same regardless of what the list price is at the time someone purchases a title.

The publication under discussion seems to have a list price that ranges from $10.99, $12.85, and $12.99 in the past two years.

There's also the issue in that it seems we are needing to do considerable sleuthing to discover what the list price of an ebook is. Please see an earlier Rules and standards thread about this.

One thought I had would be to leave the price field blank and in the notes to document the list prices over time. --Marc Kupper|talk 05:04, 9 May 2015 (UTC)

To me, price is merely information that helps differentiate different versions, not a bibliographic detail of interest on its own. In that sense, I would be fine dropping prices for ebooks. However, I don't mind keeping them either but think they should be limited to the original list price (which the previous discussions shows can be determined if at times with difficulty). Subsequent price changes should be ignored as I see no difference than a discount sticker placed on a physical book. I don't see any point of recording them in the notes as they can vary considerably over time and sellers. -- JLaTondre (talk) 12:13, 9 May 2015 (UTC)

There is nothing wrong with adding the publisher's list price to ebooks for their original publication, even if the prices not "printed in the book". There are already thousands of records in the database, even for print books, which don't have a printed price. Almost all POD books aren't priced. Almost all Australian printed books aren't priced. I'd say even a considerable number of non-English language publications aren't priced.

The user just has to understand that the price given in ebook records are the publisher's list price at the time of publication. Just like print books, publishers have the option to change their prices. We are not in a position to monitor and record such changes. When Subterranean Press has a half-off sale on their print books, should that be noted in the records? Why should ebooks be handled any differently when a publisher changes their prices? Mhhutchins 15:32, 9 May 2015 (UTC)

I am also in favor of keeping list prices for e-books for the reasons outlines above. We just have to be extra careful when dealing with them. Sometimes, when different sources show different list prices, I leave the field blank and document what we know in the Note field. Ahasuerus 21:51, 9 May 2015 (UTC)

Slightly resurrecting this topic.... How do you determine the 'List Price'? Is it the First Price offered? Is it the 'Intended to be price, but only after an introductory sale'? What if the teaser price was 'free'? Some ebooks these days release with a teaser price for the first day or two, then jump up. I'm more and more of the opinion that since the price cannot help identify an ebook version, that it's not useful data to catalog. Kevin 01:48, 21 August 2015 (UTC)

Many publishers state their e-books' "digital list prices", which are generally available either directly from the publisher or from Amazon/Barnes & Noble/etc. For example, consider Amazon's listing for On Monsters: An Unnatural History of Our Worst Fears. See where it says:

Digital List Price: $11.99
Print List Price: $17.95
Kindle Price: $7.79

? Ahasuerus 03:14, 21 August 2015 (UTC)

Out of 20 or so I looked at tonight from Fixer's queue, I only recall one that had that feature enabled. In those cases, it's relatively straightforward. It's the ones that Fixer is submitting with a price of $1.99, that Amazon shows a price when I check it as $8.99, $9.99, etc. (On those I took the more realistic price, not the teaser price.) I was just looking to see if there was any consensus on the proper handling of those situations. Kevin 03:33, 21 August 2015 (UTC)

Let me explain how Fixer determines book prices. First, he queries Amazon's back end database, which is not the same as the database used to display Amazon Web pages. Amazon's response contains a "ListPrice" data element or, to be technical, a number of ListPrice data elements which use different display formats. This data was originally reported to Amazon by the publisher as the book's "list price" and is generally reliable. In many cases ListPrice remains unchanged even after 10-20 years. If ListPrice is available, Fixer uses it and performs no additional checks.

If ListPrice is not available, as is often the case with e-books, Fixer checks other sources, including W. H. Smith for UK books and Barnes & Noble for US books. He also checks Amazon's Web pages for "listprice", "priceLarge" (used by Baen), and "Kindle Price". If Fixer finds a suitable price, he adds it to the about-to-be-submitted record and also indicates the source of the price information in Notes.

If the approving moderator doesn't think that the price submitted by Fixer is correct and decides to change it, he should document the source of the new price data in the Note field. Ideally, he should also document any discrepancies, which is what I usually end up doing for older Canadian publication where the list price is frequently unavailable.

Another thing to keep in mind is that e-book prices have skyrocketed in the last few years as publishers realized that e-books are not only a popular alternative, but, for many readers, the preferred alternative. It's not uncommon for an e-book whose price was $1.99 in 2009 to be sold for $7.99 in 2015, but it doesn't change the fact that its original list price was $1.99. Ahasuerus 04:18, 21 August 2015 (UTC)

OK, thanks. I went back and undid the correction I did to the submissions I accepted yesterday when the price was a normal looking price ($1.99, $4.99) but the price shown at the time of acceptance was markedly higher. I've set all those back to the price that was in Fixer. However, it seems to me that the casual observer is going to misunderstand our data. We have records that state "Data from amazon as of 20 August 2015", but the price in our system as 'price' is not the price as it was listed for sale at Amazon on that date. What do you recommend/prefer for items with unusual prices submitted ($5.63 for example), when Amazon has a price today of $5.99 or $6.99, and BN.com concurs with that price today? (Recognizing that within the last 5 months, most major publishers have gone back into psuedo agency pricing agreements with Amazon and BN, etc. which makes the current price 'more official' and 'set by the publisher' than previous pricing) - Thanks Kevin 22:32, 21 August 2015 (UTC)

Hm, yes, I see the problem. When Fixer says "Data from Amazon.com as of 2015-08-22", he means that the data is derived from Amazon's back-end database. However, most people will assume that it comes from the ISBN's Amazon Web page, which may have a different price.

I am not really sure what we can do about this issue aside from documenting any discrepancies in Notes. Ahasuerus 07:16, 22 August 2015 (UTC)

I personally prefer to keep prices bibliographic if possible. I do not usually add prices for my primary verifications if that data is not present on the printed publication itself. I thought we were only picking up prices from Amazon, etc. in cases were we did not have primary verifications hoping the data pointed to potentially useful information for bibliographic uses. I would prefer it to be removed later if a primary verification comes along (effectively stating that such information is not present on the publication; it might be less useful to state it is not there but it is a statement nonetheless and can be used to eliminate publications where such is present when comparing). Since ebooks do not in general have such within their publications, it makes sense to me to, by default, not capture such (exceptions can be made when such identifying values are within the publication itself). Uzume 10:19, 22 August 2015 (UTC)

I completely agree with this. The only prices that should be entered in the "price field" are, IMHO, those physically present on a publication. I know some editors and/or moderators that do add prices (variable with time) culled from a variety of internet sources to PVed publications that haven't got any. Hauck 10:44, 22 August 2015 (UTC)

[unindent] There is great value in recording the publisher's list price at the time of the book's publication, regardless of whether that price is stated in the publication itself. I see no problem with using reliable secondary sources for data that is not stated in a publication. To feel otherwise would mean that much data, even in fields such as the publication date and the cover artist, would never be recorded. And that's a shame. As long as the editor notes the absence of the data from the book itself and provides the source of the data as entered into the ISFDB record (the current standard), we should continue allowing it. Otherwise, literally thousands of records already in the database would have to edited, purging MUCH valuable data from the ISFDB. I can't imagine anyone wanting to do that (and remain editing the ISFDB.) Mhhutchins 15:33, 22 August 2015 (UTC)

Very much so. Just think how many cover art credits we wouldn't have if we could only rely on what's stated in pubs! (Of course, the source of the data needs to be carefully documented.) Ahasuerus 15:49, 22 August 2015 (UTC)

Graphic Novels

Probably opening a can of worms here as I have been told that their inclusion is "frowned upon." If so then why include something like this but not something like this or this (just two examples). --Mavmaramis 07:04, 9 May 2015 (UTC)

Samuel Delany is "above the threshold" and the second author may not be (I've never heard of Enki Bilal in my 40 years of reading SF, but I'll admit to knowing very little about non-English language authors.) If the author has a considerable reputation in the spec-fic field, all of his/her work is eligible for the database regardless of its genre. If the author is known primarily within the comic/graphic novel/illustration field, with only a few (if any) credits of texted fiction, his/her work would not be eligible for the database. About the Michael Moorcock graphic novel: if another writer adapted Moorcock's work into a graphic format, without any input from the original author, its eligibility into the database is based on the adapter, not the author of the adapted work. In this case James Cawthorn is "above the threshold" so the work you cite would be eligible for the database. It would be entered as a separate work and not under the title record of the adapted work. Based on its length (if it has less than 40K words of text), it would very likely be typed as a CHAPBOOK. It would have at least two content records. One for the text (as SHORTFICTION) and one for the artwork (as INTERIORART). Mhhutchins 15:21, 9 May 2015 (UTC)

Since it should be flagged as GRAPHIC FORMAT, wouldn't it be just the SHORTFICTION record? Seems a bit redundant to have both. It's not a story with separate art work. -- JLaTondre (talk) 15:32, 9 May 2015 (UTC)

Sorry, the story and the art are separate. And the overwhelming majority of graphic novels credit them separately. What if the artist and the author are two different people? Would you create one record crediting both as the "author" of the SHORTFICTION and have that appear on the artist's summary page under a fiction category and not an art category? The purpose of the graphic format flag is to label fiction presented in a graphic form. Shouldn't we also credit the illustrator? Mhhutchins 16:06, 9 May 2015 (UTC)

In most graphic novels, the story and the art are NOT separate. They are a single work that is jointly created by the writer and the illustrator. Speech bubbles, etc. are not distinct from the artwork. Seems to me it should be a single record credited to both and flagged as a graphic form. Where is shows up on the artist's summary page isn't really relevant since it will be labeled as being a graphic format. Most of graphic novels were entered before we had the graphic form flag. -- JLaTondre (talk) 16:36, 9 May 2015 (UTC)

If you believe that art and story are inseparable (I disagree) then you should be pushing for a new TYPE for the graphic format and not just a flag. Leaving the ISFDB and its software out of the question, why do graphic novels separately credit art and story if they "are NOT separable"? Someone's making a distinction between the roles in creating the work. I would bet that most of the artists and authors would disagree with the idea that their contributions to a work shouldn't be individually acknowledged. Mhhutchins 17:44, 9 May 2015 (UTC)

An interesting question. I agree that a graphic novel is a joint work -- much more so than in the case of an illustrated novel -- but OTOH we can identify each person's contribution, i.e. text vs. art. For this reason I would be inclined to credit them separately, which will make it clear what each person's role was. Ahasuerus 22:26, 9 May 2015 (UTC)

(unindented) Perhaps someone could explain the phrase "above the threshold" to me as to who or who does not qualify ? Phillipe Druillet 'wrote' this and illustrated this and I note that this is given an entry but not the follow up Rogue Planet. Not to mention Moebius. --Mavmaramis 10:34, 10 May 2015 (UTC)

I would advise extreme caution when entering the domain of European graphic novels, particularly the franco-belgian "Bande dessinée" with lots of authors that are writers and drawers and huge problems of printing identification. Hauck 10:49, 10 May 2015 (UTC)

Fortunately I don't have any European graphic novels. GNs in general don't feature high on my collecting radar tending only to get those that are of interest (like the ones published by Dragon's Dream) and all of the ones that I do have are UK or US publications. However that being said I'm not about to break the ISFDB by creating records for them. --Mavmaramis 12:58, 10 May 2015 (UTC)

If you have a question about whether a specific author is "above the threshold", post it on the ISFDB:Moderator noticeboard or ISFDB:Community Portal. In most cases, it will be obvious and you will get a definitive response. In a few cases, it may have to be debated among the group. Mhhutchins 00:21, 14 May 2015 (UTC)

Slipcased books

It seems odd to me that if you have a book that has been published in an illustrated slipcase there isn't a way to depict both the book's art and the slipcase's art. Case in point this book where the artwork on the book has no text at all but the slipcase does. What (if any) are the rules concerning which artwork you should upload in these case ? --Mavmaramis 13:04, 10 May 2015 (UTC)

While the software only supports displaying one image, you can manually upload additionally images and link to them in the notes. See this example which includes links to a pre-publication cover and back cover in the notes. Additional images are uploaded via the wiki's 'Upload file' option in the 'Toolbox' on the left of the screen. When using this method, a couple of things to take into account:

You will need to manually assign the name. Convention is to use the software's auto generated name for the cover and add additional letter(s) that is an abbreviation of the image. Hence the DSTNWIN81PP.jpg (pre-publication) and DSTNWIN81B.jpg (back) in the example publication.
You will need to manually apply the licence template. Typically Template:CID1, but there are others depending on the circumstances.

As for which cover, I would go with the actually cover in the cover field and the slipcase in the notes. -- JLaTondre (talk) 13:56, 10 May 2015 (UTC)

Thanks for your suggestion. I'll probably leave it for the time being since both the book and the slipcase are bigger than A4. --Mavmaramis 14:15, 10 May 2015 (UTC)

Or you can just scan the fronts of both the book and the slipcase in one image, like this one, this one, or this one

Capital letter in bibliography page

For example here: Series Number, User Rating, Current Tags, Variant Titles, Bibliographic Warnings. The second word is written with a capital letter. I don't know the English rule where this is allowed.
For example: Add quick tag. The second and third word is written with a lower case letter? What is right?
Are these terms headlines? Then it must be written with a capital letter.
Before I enter more submissions, I would like to customize my last 14 entries, but I don't know how.--Wolfram.winkler 08:09, 12 May 2015 (UTC)

I hope the following section from the help pages concerning the spelling of titles may help you:

Case. Titles should have case regularized unless there is some specific evidence that the author intended certain letters to be in a specific case. For example, if the title is "EXTRO" in all caps, the title should be entered as "Extro". This applies to the titles of short stories as well as books. Typesetting style is not important; for example, Fantastic Universe typically printed story titles in lower case, but these titles are regularized for the ISFDB. Regularized case means that the first and last words are capitalized, and all other words are capitalized except for "a", "an", "and", "at", "by", "for", "from", "in", "of", "on", "or", "the", "to", and "with". Hyphenated words have the first letter after the hyphen capitalized.

If not the titles are the problem (for example in the notes) please stick to the General lower case, with known exceptions. Christian Stonecreek 13:18, 12 May 2015 (UTC)

Wolfram, regarding your question why a text label like "Series Number" has all first letters capitalized and is not displayed as "Series number", whereas the text label "Add quick tag" has only the first letter of the first word capitalized: don't worry about the first letters of these text labels. It's pretty common on English websites that the labels for input fields and links/actions (for example "Add New Novel") have a character case like this. I guess the fact that "Add quick tag" is displayed like this is just a small 'character case inconsistency' in the ISFDB software. The rules for the data that you enter are the ones posted by Christian above. Jens Hitspacebar 18:50, 12 May 2015 (UTC)

This is true, but it wouldn't hurt to spend a few hours of development work to make these labels more consistent. I'll go ahead and create a Feature Request. Ahasuerus 19:40, 12 May 2015 (UTC)

Hello Christian, I know the generally rules of English orthography (recently), but this was not the problem, but the inconsistency of ISFDB how Jens has talked above.

In my notes I want to reach a standard as below, for example: Additional Page[s]: 2 unnumbered pages with "thanks". In this case "Page" with a capital first letter. My opinion is, all words before the double point are considered as a title (or text label), after double point as normal data text with the English orthographic rules (with lower case letter). Thanks for your efforts.

Hello Jens, your explanation was quite right and helpful for me, exact this has confused me. Thanks.

Hello Ahasuerus, I'm positively surprised by the quick response of the moderators. Thanks. --Wolfram.winkler 07:23, 13 May 2015 (UTC)

AE: The Canadian Science Fiction Review

We've received a couple of submissions from Pgowen (one rejected, the latest on hold), plus an earlier as-yet unanswered request at our Help Desk a few days ago, that is asking for AE: The Canadian Science Fiction Review to be added as a webzine to the database. It's not known (at least by me) if Pgowen and "Roger M." are the same person. AE have been publishing genre micro-fiction in PDF format annually since 2010, and all are still available from their website. More recently, they have been publishing web-only fiction not included in the PDF issues, and it is one of these (here) that is the subject of the latest submission, which contains in the Note to Moderator the following (the request is formed around the pay rates AE offers):

"AE: The Canadian Science Fiction Review - quarterly (weekly updates) webzine; all sf (fic/flash/nonfiction (query)/art/comics). Pay: fic/flash=CA7¢/word; Nonfiction=CA$20-40; art=CA$20-100; comics=CA$20. Words: ½k-3k. RT: <90 days. Reprints: no. E-subs: ONLY. D.F. McCourt, Editor (Q). SFWA"

and in the Note field:

"AE: The Canadian Science Fiction Review meets the requirements for SFWA. The current pay rate is CA7cents"

Under Point 2 of the Rules of Acquisition the story is not currently eligible, although we owe it to Pgowen to have the discussion about AE's eligibility (similar to the one we had about Perihelion last month). I have put the submission on hold for now (so as not to discourage), at least until we have made a decision about AE's inclusion or otherwise. I have also left messages for Pgowen and Roger M. to join the discussion here.

Aside from this, I believe AE's downloadable PDFs do qualify for inclusion. PeteYoung 06:29, 11 June 2015 (UTC)

I don't know if the AE issue has been further discussed elsewhere, but in the event it is declared eligible (it's on the SFWA eligibility list), the next thing to worry about is the way it's archived. While AE does have "issues" in the sense that a specific number of stories are released each publication period, the stories from the back issues are merely a big list under the "fiction" tab on the website. Furthermore, (unless I'm blind), there's no date or datestamp on any of the past stories, nor even a blog-style numerical date hidden in the URL. So while AE may be in on SFWA grounds (and I'm agnostic on this), someone's in for a heck of a time figuring out how to organize the stories. On the occasions when I've had to determine the date of publication for an AE story (such as when it's reprinted, or adapted for an audio podcast), I've had to either check with the author directly (and all too often they have no idea**) or scroll back through the AE twitter feed to find out when they announced publication, which is imprecise but at least gives me the month of publication. Madness!

[**] Which is why one piece of advice I give beginning writers is to compile a bibliography that's as detailed as possible, and to maintain it regularly. You think you'll remember all your publications, but you won't. Dwarzel 22:21, 7 August 2015 (UTC)

It hasn't been further discussed elsewhere. I left an invitation to Pgowen to join this discussion back in June, but perhaps he/she expects a decision to be made on the scant information already provided without any further input. But as you have detailed, we really do need more information regarding online publication dates at the very least, and if that information is not forthcoming I don't think we can proceed.

Pgowen, if you are reading this, the matter is still open for discussion so please contribute to it here – we don't bite (much). PeteYoung 03:10, 8 August 2015 (UTC)

Allow uncredited cover art in case where it's required

There exists a rule not to credit "uncredited" to cover art. Usually that's a good idea, as there is no advantage in having lots of useless cover art title entries.

But situation changes a bit when cover's are reused. I have at least three covers for German books, which reuse earlier English releases, but due to missing original artist it is impossible to variant these titles, as there is no title entry for the original cover.

In these cases I would like to add uncredited (or whatever) to the original and the reused books and then variant them properly. In case someone later finds the artist for one of the books, it's easy to fix all of them. Currently with only notes in the description it is impossible to find the reuses again later. --Stoecker 21:39, 9 July 2015 (UTC)

You can add an HTML link in the Note field of matching COVERART title records without compromising the standard. A link works just as well as a variant in connecting two uncredited records. Making an exception to the standard would lead to editors assuming "uncredited" is a valid entry without doing further research into the extenuating circumstance that allowed it. Flawed reasoning. Mhhutchins 22:38, 9 July 2015 (UTC)

If there were matching COVERART title records, then there would be a credit that could be added to the publication. The scenario Stoecker is describing is one in which there is not a credit so there are no COVERART title records. Putting links in the publication notes is not the best (many reprints, etc. plus not really publication specific). Short of the developers making software changes, I think this is a reasonable compromise and so would support this change to the rules. -- JLaTondre (talk) 00:50, 10 July 2015 (UTC)

You're right. I overlooked the fact that COVERART records are only created when the field is populated. How about a better compromise? Come up with another way of crediting them. There are too many records on the summary page for "uncredited" and it takes quite some time to load even with a fast connection. At least having a unique way of being credited will keep the author summary page manageable, and will allow other users to look at the covers to try to identify the artists. Any suggestions for a credit? Mhhutchins 00:56, 10 July 2015 (UTC)

Perhaps "unidentified"? Ahasuerus 00:57, 10 July 2015 (UTC)

Yes, a very apt alternative. The documentation of the standard should make it clear that the credit will only be used for uncredited artwork which is known to have been used more than once. Mhhutchins 02:38, 10 July 2015 (UTC)

I'm against this move. This will only create confusion or abuse. A mention in the notes of the concerned publication is enough ("uncredited artwork also used for XXXX"). There is also the fact that the number of covers that are a) uncredited to this day and b) used on multiple books is probably in the thousands range (think of all the SF lines in non-english countries that re-used US or GB artwork). This will result in an unmanagable author page. Hauck 13:03, 10 July 2015 (UTC)

Those are the exact reasons I mentioned above, and why I suggested that we compromise and come up with a different method of entering such cover art records. This means that a publication record can not be created giving "unidentified" as the artist credit. It can only be done after it's determined that there is a matching cover art by an unidentified artist. Mhhutchins 17:42, 10 July 2015 (UTC)

I was specifically thinking of the final size of the "unidentified" author's page with the added potential of separate "pairs" for the same artwork only partially identified. Hauck 18:13, 10 July 2015 (UTC)

In my eyes the fact whether the final authors page is manageable or not should not change anything: It's easy to prevent showing that page at all in source code when it really gets too large or find another solution (but I doubt that really is an issue). It's always a bad idea to base the logic of data on current (or assumed) restrictions of the interface, as interface can change easily, the data not. Giving some numbers: From my about 500 books ATM 3 have such a situation (and one other I found during the process). For most books with reused art the original artist is known. --Stoecker 18:31, 10 July 2015 (UTC)

Well, it's probably a question of sampling size and constitution. From my 18.000 books, there is much more than your 1% that are not credited or where the original artist is not (yet) known. There are whole ranges of titles (early 1980 Fleuve Noir, Rocs, 60 & 70's Aces, Orbits, "photographic" Panthers, Rayon Fantastique, Coronets, Albin Michel etc...) where data on the book is absent . Hauck 10:00, 11 July 2015 (UTC)

We're only talking about reused uncredited. I also have more uncredited artwork. But as it's even legally much harder to reuse artwork when the original artist is unknown I'm sure that the subset of uncredited and reused is much much smaller. --Stoecker 16:55, 11 July 2015 (UTC)

I was also talking about this subset (except for Rayon Fantastique and Panther/Sphere -even if I saw some photographic compositions reused http://www.isfdb.org/cgi-bin/title.cgi?913908 like this one], the other publishers reused or "licensed" artwork), but our samples are not really comparable (in size and typology).Hauck 17:01, 11 July 2015 (UTC)

I don't understand that example. It has credits. --Stoecker 20:09, 11 July 2015 (UTC)

I know this, who do you think found this pair? I was evoking the re-use of photographic covers. Hauck 20:15, 11 July 2015 (UTC)

I see your point, but it can't be nearly as bad as the "uncredited" page is now. I can think of no better way to recognize these re-uses of cover art. Especially since we've lately become the Internet SF Art Database. :( Mhhutchins 18:26, 10 July 2015 (UTC)

We already have uncredited, unknown, untitled, various and probably others. I think unidentified can be a useful addition. :) --Willem 19:09, 10 July 2015 (UTC)

Well, we can also add "I've seen this cover somewhere", "It's what's-his-name", "I can't read the signature", "It looks a lot like XXXX", "F... signature is in gothic script", "It rings strictly no bells", "Close to some of my kid kindergarten's drawings", "My memory is not what it was", "I've read it on Ibiza's beaches in 1990", "My magnifiyng glass is not powerful enough", etc... More seriously all this stems form the fact that the cover is not credited. Even if I apply the rules, I think that simply "uncredited" should be allowed for cover art as it is for other forms. "Unidentified" is too vague and is not automatically perceived as meaning "uncredited-at-the-time-but-present-on-diverse-books-with-hopes-of-finding-the-artist-and-saving-us-some-work". There will be covers by "[blank]" and covers by "unidentified", it will be a lot of fun to explain all this subtilities (but it'll be just some more added to our idiosyncrasies). Hauck 10:00, 11 July 2015 (UTC)

So when I submit changes for these pubs with "unidentified" will they be accepted? --Stoecker 11:46, 10 July 2015 (UTC)

No, not until it has been discussed, we've arrived at a consensus for the actual method, and it has been documented in the help. That's how changes are made here. Mhhutchins 17:42, 10 July 2015 (UTC)

One option that doesn't seem to have been mentioned is a numbering system: e.g. "uncredited-23" for a particular set of reused covers. That "artist" would then have only a single item on the author page, but there would still be a COVERART record to which you could link reprinted covers. Doing a name search for "uncredited-" would quickly tell you numbers that hadn't been used yet. Chavey 01:13, 1 August 2015 (UTC)

Would there be a way to easily and quickly find out which number we are on for the next one? Perhaps a list of all of them? Otherwise, going through numbers until you find one unusedwould take a long time. ···日本穣 · 投稿 · Talk to Nihonjoe 16:18, 1 August 2015 (UTC)

Yes, it's easy and quick. Do an author search on "uncredited". If we've done this for a couple of situations, we might have "uncredited", "uncredited-1", and "uncredited-2". So to create a new relationship, you would use "uncredited-3". Chavey 03:00, 6 August 2015 (UTC)

Sorry, I can't go along with this method. It's too much work for the average editor, and too confusing as well. I can see people using it just for any work that isn't credited. Any moderator dealing with new editors would have their hands full trying to explain it. Mhhutchins 05:25, 6 August 2015 (UTC)

I agree with Michael that "uncredited-N" would be unwieldy. That said, we need to do something about the Summary page for "uncredited": it takes a very long time to load and puts an extra load on the server. It's on my list of things to look into. Ahasuerus 17:57, 6 August 2015 (UTC)

I think 'unidentified' is a good alternative (provided it is used for variants, not single records). It has happened from time to time that in reviewing or moderating one can identify a piece of cover art. Stonecreek 05:29, 7 August 2015 (UTC)

Publication/title dates and future publications

An editor left a note on my talk page about "This publication is more than five months away from being published and should not have been entered into the database. ... That's the reason we've set the 3-month limit." Template:PublicationFields:Year is silent on this aspect. The software did not show any warnings on data entry nor moderator approval. There is a previous discussion at ISFDB:Moderator noticeboard/Archive 10#How far ahead...? where it was noted that Fixer limits its submissions to publications that are three months or less out. It appears from that discussion that human-submitted records should be less than six or twelve months out. ISFDB's Future Books page shows the next 12 months of upcoming titles. Edit-pub and Edit-title's validateDate() function do not allow dates past the year 2020 (now 5.3 years in the future) other than the 8888-00-00 and 9999-00-00 special cases.

I am proposing that we update Template:PublicationFields:Year and Template:TitleFields:Date to include

If the publication date is twelve months or more in the future then please enter the date as 9999-00-00. ISFDB will display 9999-00-00 as "forthcoming."

That will both define a limit for how far in advance we should have records and also documents the use of 9999-00-00. --Marc Kupper|talk 00:38, 5 August 2015 (UTC)

The ISFDB is a database for published books and periodicals. The only reason we allow records for future publications is because we have a robot that can find these and create records for them, making it much easier for us humans to verify them when they are actually published. If I had my druthers I'd say no human-created records for unpublished books should be in the database until the month of their publication (the only exception being periodicals which can appear more than a month before the stated publication.) But I'm willing to agree to a compromise if the group decides that three months pre-publication is a good cut-off. I would not personally want to see records for any publications which are more than three months away regardless of whether they're human- or robot-generated. Mhhutchins 01:44, 5 August 2015 (UTC)

Unfortunately, a lot (as in "hundreds and thousands") of ISBNs get canceled prior to publication. I know it all too well because identifying them is the most time-consuming and uncertain part of running Fixer. Based on my experience, allowing anything more than 2-3 months out would significantly increase the risk of our information becoming unreliable, so I think the 3 month rule is a reasonable compromise. Ahasuerus 02:27, 5 August 2015 (UTC)

That makes sense though it's ironic that we don't want more speculative publication records! --Marc Kupper|talk 06:09, 5 August 2015 (UTC)

Where did you get the idea "that we don't want more speculative publication records"? What we want is more reliable records and to maintain the integrity of the database. We want records of books that have been published, not those that might be published. Or at least that's that way I read it. Mhhutchins 06:56, 5 August 2015 (UTC)

I think "speculative publication records" was a pun ;-) Ahasuerus 07:12, 5 August 2015 (UTC)

Now that you point it out, that's very funny. Sorry for being too literal. This db has practically killed my sense of humor. :) Mhhutchins 14:10, 5 August 2015 (UTC)

Same as Michael here : I'd compromise for a three month limit, but basically I think that strictly NOTHING in the future should be entered. Hauck 08:24, 5 August 2015 (UTC)

I agree with the three month limit. Documenting it on the suggested pages above will be very helpful (as will documenting the use of 8888-00-00 and 9999-00-00. ···日本穣 · 投稿 · Talk to Nihonjoe 20:08, 5 August 2015 (UTC)

(unindent) I'm fine with three months. As we may end up with more 9999 records I tested searching for them. Publication and title searches for the year 9999-00-00 return nothing. You need to use 9999 without the -00-00. Title searches validate that you use the YYYY-MM format and for the month 9999-00 fails as the year must be between 1 to 2020. --Marc Kupper|talk 06:14, 6 August 2015 (UTC)

Related to this would be to add to the help a request that a note be included with the scheduled publication date. For example:

If the publication date is three months or more in the future then please enter the date as 9999-00-00 and include a note that looks like "Publication scheduled for 2020-01-23 as of 2024-04-24". ISFDB will display the date 9999-00-00 as "forthcoming." The 'Publication scheduled for' notes help the editors who check on upcoming titles and publications.

--Marc Kupper|talk 06:36, 6 August 2015 (UTC)

If the consensus we've arrived at is to limit records for future publications to no more than three months ahead, (or at least it seemed that the majority of the participants in the discussion agreed), why did you add a publication record for a book that won't be published for nine months? Mhhutchins 06:50, 7 August 2015 (UTC)

I had thought the discussion was consensus was about adding publication dates in the Year field that were more than three months ahead. Today is 2015-08-10 meaning we generally would not add publications or titles with a date of 2015-11-11 or later in the Year field. If someone wants to add such a publication and/or title then they would enter the date as 9999-00-00. The use of 9999-00-00 seems to be a flag that indicates we are dealing with a proposed publication or title. Once we get within three months of a proposed publication date then we can put that in the publication and title's Year field.

The ISFDB mission statement at the top of http://www.isfdb.org includes "forthcoming books". Initially there were no restrictions on how far into the future we could have a title. For the first few years entry of proposed publications or titles was rare simply because we were busy with cataloging our existing publications. In December 2000 the code updated to add Forthcoming Books which allows for viewing proposed titles up to 12 months into the future.^[3] The Fixer robot did not show up until eight years later. In December 2010 the code was revised to not allow entry of dates past the year 2020.^[4] At the time that meant we could add title/pub records intended for publication up to ten years in the future. The value 2020 is hardwired in the code meaning at present dates up to 5.4 years into the future are accepted.

In my mind it's of bibliographic interest to have a well sourced record of proposed specfict titles and/or publications. If a title or publication becomes reality the data we collected can be moved to the title or publication notes in the database or wiki. If something never comes to fruition then ideally we'll have a decent explanation of what happened. Someone hunting around with Google for the title should find our record and ideally what we have will be good enough that they can stop looking other then double-checking our sources for more recent updates. Most of the resulting phantom titles and publications would end up being documented on the author bibliographic information wiki pages rather than in the database as 8888-00-00 records.

In the past, human entry of proposed titles and publications has been rare. I suspect even if we were to allow entry of dates 12 or more months in the future that they would continue to be rare. --Marc Kupper|talk 21:32, 10 August 2015 (UTC)

BTW, did you know there were clean-up reports which automatically generate lists of all 9999 publication records and title records? Persons who create 9999 records should be held responsible to seeing if the finished book ever appears and if any of the data has changed. Otherwise, they shouldn't be creating such records. Mhhutchins 06:54, 7 August 2015 (UTC)

Is there a way for regular people to see these lists? That way we can make sure things get handled. ···日本穣 · 投稿 · Talk to Nihonjoe 00:36, 9 August 2015 (UTC)

At this time only moderators have access to the cleanup reports. There are two reasons for it. The first one is that these reports were originally regenerated on demand and some were resource-intensive. In 2014 all of them were migrated to the nightly job, so this reason no longer applies. The second reason is that some cleanup reports allow the user to mark potentially troublesome records as "ignored". "Ignored" records no longer appear on cleanup reports, so we wouldn't want a naive user to tell the system to "ignore" records.

It occurs to me that now that "reason #1" no longer applies, it may be feasible to let all editors access all cleanup reports but reserve the ability to use the "ignore" functionality to moderators. Ahasuerus 02:31, 9 August 2015 (UTC)

That sounds like a good idea. You may even get some "gnomes" (as they are called on Wikipedia) who will help out with fixing issues highlighted by the reports. This may free up moderators to do things that can't be done by others. ···日本穣 · 投稿 · Talk to Nihonjoe 06:30, 9 August 2015 (UTC)

OK, FR 818 has been created. Ahasuerus 03:57, 10 August 2015 (UTC)

That's a good move. At least they'll be able to access this list. Whoever suggested it isn't doing much to reduce the number of records on it. Maybe the non-moderating editors will fix their own primary verified records if they know which ones to fix. Mhhutchins 22:10, 15 August 2015 (UTC)

I too agree. I sometimes try to "kill off" these authors (by looking for evidence of their deaths and updating their records): http://www.isfdb.org/cgi-bin/oldest.cgi Uzume 12:12, 23 August 2015 (UTC)

"And" vs. "&"

Where do we stand "and" vs. "&" with respect to variants? The database has a mixture of cases where they are listed as variants and where they are not (pubs with a single title record, but the pubs listed have both forms). Is there a standard on this? -- JLaTondre (talk) 17:15, 29 August 2015 (UTC)

The standard states "The title should appear exactly as published, even though this may be different from the canonical title." Notwithstanding an editor's personal interpretation of this standard, the usage of "and" or "&" is an actual variant. This has been the basis for creating variants too many times to change it now. Mhhutchins 17:36, 29 August 2015 (UTC)

<agree> I'll just add that one of the reasons for the "appear exactly as published" rule is to make it possible to search for minor variations. (Of course, Google, Microsoft, Yahoo and other search engines have more sophisticated searching algorithms, but then they have slightly bigger budgets.) Ahasuerus 18:01, 29 August 2015 (UTC)

That's what I would have thought, but I've come across quite a few exceptions recently that I was wondering if I missed a conversation. Perhaps a clean-up script to find pubs that use "&" where the title is "and" (and vice versa)? -- JLaTondre (talk) 18:32, 29 August 2015 (UTC)

I have been thinking about this very issue for the last 30 minutes :-) It occurs to me that it is a subset of a larger problem, i.e. title/pub mismatches where the publication title is not "TITLE TITLE: ..." or "TITLE TITLE (...)". Ahasuerus 18:46, 29 August 2015 (UTC)

Yeah, but it can get more complicated than that. There is also "SERIES: TITLE" and "SERIES: TITLE: SUBTITLE". It would be a good clean-up report to have. -- JLaTondre (talk) 19:07, 29 August 2015 (UTC)

Such a script would have to be very fine-tuned, otherwise it would return thousands of hits. Say the difference is more than 50%, for example, before a mismatch is returned. Is that possible? If so, it wouldn't find uses of "&" and "and", but it would return cases where a publication is under the wrong title. Now I would want a clean-up report like that, but not one that would find minor differences. Mhhutchins 21:33, 29 August 2015 (UTC)

Yes, there are algorithms that do "similarity" searches. Unfortunately, they tend to take a long time to run, which is why "Suspected Duplicate Authors" takes 12 (!) hours every time it is run. A compromise solution may be possible, but I will have to experiment. Perhaps a multi-step process would work, e.g.:

Find all pubs whose "reference" title doesn't contain the pub's title
Calculate the two strings' similarity
Add the pub to the cleanup report if the calculated similarity value is less than 50%

Ahasuerus 21:42, 29 August 2015 (UTC)

Of translators and variants

Hello. Quite a few times, I have been confronted with the same problem : in the case of different translations of the same text under the same title by different translators, some moderators consider that these translations are distinct variants of the original text, whereas some others don't, and don't accept such variants. I personally hold the first view, and would treat different translations as distinct variants. As there doesn't seem to exist any clear rule about this (either requesting or forbidding to create such variants), I would appreciate it if the community expressed themselves about this, and if such a rule was eventually written down somewhere. A related discussion was started some time ago here, but nothing came of it at the time. Linguist 16:15, 17 July 2015 (UTC).

My position is the following : I strive for consistency. Let's take the case of the english author Joe Writer who wrote the novel "Lord of Space". He rewrites it and republish it under the same title. In our usage, even if the texts are different, we do not variant the title and have one title that covers both versions. Hauck 18:10, 17 July 2015 (UTC)

It depends on the scope and the nature of the changes. If an author expands a novella to novel length, we create two records even if the title hasn't been changed. To use a more convoluted example, David Wingrove's changes to the Chung Kuo books were so significant that we had to separate the original (1989-1996) and the "recast" versions of the books. (Some titles were changed, some weren't.) Ahasuerus 02:03, 18 July 2015 (UTC)

Yes, but in the case of a translation, it's the job of the translator (IMHO) to be as faithful as possible to the original text, so there's really no reason for intensive changes (or simply reasons to deviate from the text).Hauck 04:57, 18 July 2015 (UTC)

I am afraid this is not always the case. A few years ago Michael and I ran into a truly bizarre case -- two different translations of the same Russian story appeared in two consecutive issues of a US anthology. The translations were so different that the editor apparently didn't realize that he was about to publish the same story (!!) I have these anthologies in my collection, so it was easy for me to check. Sure enough, they were very very different. Ahasuerus 05:45, 18 July 2015 (UTC)

Let now imagine Jean Ecrivain a French writer who sees his novel "Maître du temps" translated twice, the first time by Jules Traducteur under the English title "Lord of Time" and the second time by Juliette Traductrice under the same title. Accepting to differentiate the translators would lead to have two similarly-titled variants which is exactly the opposite of our present usage: "no variant based on textual changes". In fact, the second option would make the translator a kind of co-author, which is, IMHO not a good idea. Please note that as a sometimes professional translator myself, I'm perhaps belittling my work but I conceive my duty as translator to be as invisible as possible. To be short, I think that the future "translator" field should be located at publication level and not at title level. A last remark (less important): to accept variants based on translator will hugely and artificially clutter the display for those (like me) who like to see all the different publications of a work. Hauck 18:10, 17 July 2015 (UTC)

Unfortunately, if we decide to create a single record for different translations (as long as the title is the same), it will make it difficult-to-impossible to add translator support. The latter was much discussed a few years ago and is described in Feature Request... um, I can't link it right now because the site that hosts our FRs is current down due to storage failure.

The problem is that a translated title record will need to be associated with a translator (or multiple "co-translators"), which won't be possible/feasible if the same record is used to record multiple translations. Ahasuerus 02:03, 18 July 2015 (UTC)

Your argument will be valid only when the translator field will be added and under the present database structures. IMHO this is not the point of the debate.Hauck 04:59, 18 July 2015 (UTC)

Well, yes, but if we merge these translated titles now, then we will have to identify and unmerge them once the software has been changed. That's an awful lot of extra work. Ahasuerus 05:45, 18 July 2015 (UTC)

And this is exacly what I wanted to avoid, by a) unmerging already similar titles with different translators and b) creating variants for each translator. May I insist upon the fact that we need a formal rule as soon as possible, whichever way it may go. Linguist 06:55, 18 July 2015 (UTC).

(unindent) Spot-checking popular books, I see that some editors have already done the requisite work. For example, see The Odyssey record, which has more than a dozen English translations entered as separate VTs. There are estimated 502 notes which says "DO NOT Merge" and list the translator(s).

It would be very bad form to wipe out all of this work, so I suggest that we make "one translation = one VT" an explicit rule. Ahasuerus 04:37, 31 July 2015 (UTC)

I still disagree, not on the matter of the rule itself (although the page above shows, IMHO, the cluttering effect that I fear) but on grounds of consistency (we're starting to allow vts based on textual changes). The point about work already done is moot as it has been done by some people without discussion beforehand (the subject has been already evoked about a year ago IIRC and I've indicated at the time that no rule was fixed, a fact that didn't deter some contributors). Hauck 06:54, 31 July 2015 (UTC)

It is precisely the absence of fixed rule that is a problem. I'm all for "one translation = one VT", but if there was an explicit contrary rule, my mind would be at rest in that respect. Linguist 08:42, 31 July 2015 (UTC).

I agree with Hauck that we shouldn't be creating variants based on text. That's been one of the basic tenants of the variant function. If an author completely rewrites his own work, the ISFDB standard has determined that the new version shouldn't be varianted to the original one. So why should it be any different when it comes to different translations of the same work?

But that basic tenant of the variant function was broken when it was decided that it would be used for translations, regardless of whether the translations were different texts. An entirely new function should have been created to handle translations and other textual relationships like adaptations, revisions, expansions, and serializations. It was decided to take the easiest and fastest course because so many editors here were in such a hurry to get translations into the database. After more than a decade which excluded translated works, no one could wait for a larger discussion about how translated titles should be handled by the ISFDB. So the variant function was modified to include translations. It's a hole we've dug for ourselves, and one that we're not likely to be able to climb out of without extreme effort.

With that in mind, and for the time being (a time that may be decades long), I believe we should continue the de facto practice of creating a separate varianted title for different translations, and it should be documented. Mhhutchins 16:03, 31 July 2015 (UTC)

So far, I'm not really convinced in either direction. I created most of those VT's of The Odyssey that Ahasuerus mentions, and I don't think I'd particularly object to merging them. (I was told by a senior editor to make different translations different variants, so I did.) Merging those English variants would involve moving translator statements from the title record to the publication record, which is a non-trivial amount of work, but not really a big deal. If we eventually get a system with a translator field, we're going to have to search all title recs and all pub recs for "translated by" statements anyway. If we keep the translator with the VT, it means there are fewer records to move -- e.g. 17 Odyssey title recs vs. 35 Odyssey pub records. However, that task is so far in the future that I'm not convinced we should structure our current presentation based on that future task. On the other hand, I'm not convinced by Hauck's argument about a consistency with other "text variations". As Mike says, we've kinda stomped all over any consistency aspects of the VT's in a variety of ways. Hauck argues that putting the translator into the title field is like promoting him to the same importance as the author. I don't think a new title rec should be viewed as honoring someone in any particular way. We give the same single title rec to a writer with a letter to an editor of a fanzine as we do to someone who publishes a 500 page novel! Giving a new title rec to a translator isn't really a big deal. I am more convinced by Hauck's argument about the simplicity of the presentation of an author's work. There aren't a lot of books with as many translations as the Odyssey (which will get even longer as I continue slowly to enter them), but a modest number of these do happen. (E.g., for Dr. Jekyll & Mr. Hyde we have 12 Spanish, 5 Dutch, 4 French, and 2 German translations.) If the translation VTs were listed with translator (e.g. [English, by Alexander Pope]), there would be value in listing multiple translations as separate VTs. But since we can't do that (without that to-appear translator field), these multiple translators are just confusing. As I said, I don't have a strong preference, although with Linguist and others I'd like a decision, but my feeling is that the simplicity of the current presentation favors putting the translator in the publication record, and the extra work involved for the eventual addition of a translator field is not sufficient to overcome that. Chavey 02:39, 1 August 2015 (UTC) (writing from his hotel room at a Math conference)

(unindent) I guess the first thing that we need to determine is the "end state" of translator support. Do we want translations to appear on Summary pages? E.g., do we want Brian Stableford's Summary page to list the works that he has translated? If we do, then we will need to capture translator data at the title level. Ahasuerus 18:04, 6 August 2015 (UTC)

I'd like very much to have translations appearing on summary pages. And yes, I do think that a different translation is a different variant of the original text. Stonecreek 05:20, 7 August 2015 (UTC)

I also think translator data appearing at title level would be a good thing. The bad side of it of course is the time-consuming effort necessary to update the records concerned. Linguist 08:44, 7 August 2015 (UTC).

I concur that different translations (even if by the same translators) should in general be different entries (arguments could be made against this for small editorial fixes between editions, etc.). In some cases the same translator(s) have made a translation with considerable license (poetic license) as well as a translation that is highly precise (and often with sidebar explanations and other notes). Obviously the finished product would be very different for these two cases. This is precisely why I really want to see translators added to our DB and rules (translators heavily influence the content of translations as as such ought to be accurately credited be this blame or praise). Uzume 23:05, 8 August 2015 (UTC)

I'd also prefer variants for each translation (again as above, except for minor text corrections between editions of the same documented translation). I am also looking forward to the day when the 'translator' field becomes a reality, and translations appear on the summary pages. In the meantime this seems like a reasonable step in that direction, without requiring any software or structural database changes at this time. Kevin 04:34, 11 August 2015 (UTC)

I too very much look forward to translator credits. There are people with entire careers within the genre that have no author page here strictly because all their work is in translations, e.g. ja:黒丸尚 (Kuroma Hisashi) Uzume 21:21, 14 August 2015 (UTC)

(unindent) Some suggestions above say that translators should be handled at publication level. Actually that's only possible for novels. For Omnibuses, collections and anthologies, the translators for each entry can be and are different, so handling that on a publication level is impossible. --Stoecker 11:49, 15 August 2015 (UTC)

I always imagined it as a clone of the current variant implementation. That would hook it in at a title level (as you note is required). I imagine it would display as "'A Short Story' by ORIGINAL AUTHOR [as translated by TRANSLATOR PERSON]". I mean it is a variant, but one that needs to be displayed with the translator instead of the pseudonym. The worst case would be a pseudonymous work, that is translated by a a pseudonym. "A Short Story" by ORIGINAL AUTHOR [only appeared as by FAUX AUTHOR][as translated by CANONICAL TRANSLATOR][Only appeared as translated by PSUEDO TRANSLATOR]." (Ok.. there is one more complex case.... I'm working on an anthology now that has contents translated to English from the French anonymously, while the French was translated from the German anonymously, and the original German was published under a pseudonym.... but that is an extreme case that the software should not be tailored to handle. In this case (as in variants, with no sub-children) I would link the database translation to English back to the original German, and note that it stopped in French along the way in notes. Kevin 15:16, 15 August 2015 (UTC)

Don't forget co-translators, especially pseudonymous co-translators! For example, the Note field in this record reads "Russian translation by "S. Berezhkov" and "S. Vitin", who were later revealed to be Arkady and Boris Strugatsky's pseudonyms -- see http://www.rusf.ru/abs/trans.htm". Once translator support has been added, here is what the Contents area of this pub will look like:

Саргассы в космосе • [Solar Queen • 1] • novel by Andre Norton (trans. of Sargasso of Space 1955 by Arkady Strugatsky and Boris Strugatsky as by S. Berezhkov and S. Vitin)

And the Summary page will look like:

Sargasso of Space (1955) also appeared as:
[...]
Translation: Саргассы в космосе [Russian] [tr. by Arkady Strugatsky and Boris Strugatsky as by S. Berezhkov and S. Vitin] (1969)

Actually, it will probably say "Аркадий Стругацкий and Борис Стругацкий" (with a mouse-over bubble for "Arkady Strugatsky and Boris Strugatsky") since I hope to implement full romanization support prior to translator support. Ahasuerus 21:05, 15 August 2015 (UTC)

yay! I am looking forward to non-Latin canonical author names (I just had some submissions for records with Japanese kanji author names rejected last month even though that is what is printed in/on the publications). I still wonder how these will be handled for author directories (we should probably have different ones based on the working language of the author records). Uzume 11:32, 22 August 2015 (UTC)

(unindent) Counting the votes, I see 7 editors favoring the proposed rule change/clarification, 1 opposed and 1 on the fence. If there is no further objection, I will adjust Help on Monday. Ahasuerus 04:13, 6 September 2015 (UTC)

Majority rules. Hauck 07:56, 6 September 2015 (UTC)

ISFDB rule changes are generally made based on consensus, which is interpreted as "overwhelming majority". If it's a more even split like 3-2, the discussion usually peters out, which can be frustrating, but what can you do?.. Ahasuerus 18:32, 8 September 2015 (UTC)

This also means that the addition (and population!) of the "translator" field is urgent lest a casual user finds for example this title with its three same italian titles and its peculiar logic (the two in german should be merged and the french one should -IIRC- probably be splitted) puzzling. Hauck 07:56, 6 September 2015 (UTC)

Yes, enhanced support for recording translators is definitely on my list of things to do. For now, Help:How to enter foreign language editions has been updated. Ahasuerus 18:32, 8 September 2015 (UTC)

Thanks for doing that, and to all those who participated. And my sympathy to the one whose views did not prevail (but who knows the value of persistence ;o) …). Linguist 09:56, 9 September 2015 (UTC).

Interviews of non-authors

I suggest that we enter interviews by persons who are not authors (and not likely to ever be) as ESSAY-typed records instead of INTERVIEWs. Doing the latter creates publess "authors" like this, this, and this. This list would include non-writing celebrities, scientists, actors, and other performing artists. (I'd done this in the past for many of the interviews in Twilight Zone magazine which became very media-oriented in its final years.) This standard could also apply to non-spec-fic authors whose work isn't eligible for the database. Mhhutchins|talk 16:18, 10 September 2015 (UTC)

I agree, I've even requested such moves from some contributors. Hauck 17:06, 10 September 2015 (UTC)

I don't support such a change. If we were to do this we would lose any cross referencing when multiple interviews of the same subject occur. We would also lose any award data or biographical information about the subject of the review which may have been added to the "author" record. Personally, "author" records without publications do not worry me in the slightest and I can't see how they are a problem. Additionally, if this change is implimented, I foresee arguments about who does or does not merit an interview and who gets an essay, whereas now the decision is clear cut, i.e. the proposed change makes the data entry rules more complicated. I expect I'll be in the minority with my inclusionist opinion. If I am, I would ask that at a minimum we include editors, publishers, bookmen, fans and artists to who is allowed an interview. I'd also like to ask that if we decide that the current interviews must be corrected, that a script be developed to take care of these. Otherwise I would prefer that records that have been entered under the current standard be officially grandfathered. Ultimately, however, I would prefer the current standard stay as is. --Ron ~ Rtrace^Talk 01:19, 11 September 2015 (UTC)

Responses to Ron's various issues with the proposal:

a) "multiple interviews of the same subject" This shouldn't make a difference if it's determined that the subject isn't eligible for the database. Mark Hamill could be interviewed dozens of times and still be ineligible.

b) "We would also lose any award data or biographical information about the subject" Can you given an example of any such non-authors currently in the database? I would be hard-pressed to think anyone winning a spec-fic award and not be considered eligible for the database, whether they're an author or not.

c) "arguments" Aren't there always such discussions on borderline cases? And don't we always side on inclusion in most of them?

d) exceptions for "editors, publishers, bookmen, fans and artists to who is allowed an interview." Of course. Nothing in my proposal suggests changing the rules for such people. I re-iterate: "celebrities, scientists, actors, and other performing artists" and "non-spec-fic authors".

e) "grandfathering" non-standard records: If the proposal is accepted, then these records are obviously in error and should be corrected when found. I don't propose that someone make an effort to go through thousands of interviews to find the non-standard subjects, but if an editor comes across them in a routine search for something else, they shouldn't be prevented from making the corrections. If the entries are wrong, they're wrong, regardless of when they were entered into the database. There have been dozens of changes made in the standards since I've been here and no one has ever suggested that we only apply the new standard for new records.

Even if it doesn't bother some editors, I think it would be puzzling to some users to see an "author" page for John Lithgow or Scatman Crothers. (I entered those interviews as ESSAYs.) I would like to hear other editors thoughts on the matter. Mhhutchins|talk 20:26, 14 September 2015 (UTC)

Help section on "Tables of content"

Re this help section: I propose that the wording of the current standard be clarified from:

Tables of content: These are not included. However, a good rule is that anything listed in the table of contents should be included.

to:

Tables of content: Do not create a separate content record for a table of contents. The contents shown in the table are included if they meet the individual criteria as explained in other areas of this help section.

This should avoid the recent situation in which a new editor took "anything listed in the table of contents should be included" to mean indices, acknowledgments, and other peripheral matter. This would also prevent someone from creating individual records for the contents of NOVEL-typed publications which have a contents page for titled chapters or parts. Mhhutchins|talk 19:47, 14 September 2015 (UTC)

I'm in favor of this change; I've always found that "anything listed in the table of contents should be included" statement to be problematic. Albinoflea 18:51, 15 September 2015 (UTC)

I agree. --Willem 20:00, 15 September 2015 (UTC)

<AOL>. Ahasuerus 20:30, 15 September 2015 (UTC)

I agree, too. --MartyD 10:53, 16 September 2015 (UTC)

Ich auch. (I couldn't bring myself to just say "Me too".) Chavey 16:38, 18 September 2015 (UTC)

これはいいと思います。···日本穣 · 投稿 · Talk to Nihonjoe 07:43, 19 September 2015 (UTC)

Deleting an author profile

(copied from the Community Portal)

My apologies if this isn't the best place to ask, but is it possible to remove an author listing from the ISFDB completely? I'm listed in the ISFDB from a story I had published online several years ago, but I'd rather not be, as I'd prefer not to be listed in any databases if possible. And if I can't remove it, can i at least delete the Date of Birth from my profile so this isn't listed publicly? —The preceding unsigned comment was added by MrFiction15 (talk • contribs) .

I don't see why we couldn't accommodate a request to remove birth month and day, however without knowing your name, it will be difficult to accomplish. You are welcome to email me at kevin.pulliam@gmail.com with the pertinent details and I will make the requested changes. We can also put a note in the record stating your objection to a detailed DOB. I recommend that you allow us to retain your birth year in order to let us disambiguate you from any later authors with a same or similar name. Thanks Kevin 17:28, 28 September 2015 (UTC)

I just responded to the same request on the Help page. Kevin, I'm not sure how we can note this on an author's summary page. Can you explain how to do it? It can be done on one of the Wiki comments pages, but no moderator checks those pages when working on edits to author data edits. (Or I don't.) Mhhutchins|talk 17:58, 28 September 2015 (UTC)

I abused the webpage field and added a webpage of "Author_Requests_No_DOB_and_No_Website_Links.com". It's abnormal enough it should catch any Moderators attention. I see that the DOB has already been removed. Due to the visibility and relatively modern publication where the work appeared, and the follow-on Anthology Reprint, I'm afraid that's the best we can do with the current architecture. Kevin 23:58, 28 September 2015 (UTC)

There was no question that we would ever consider removing the fiction record from the database. I'm not sure if the method you've chosen is sufficient to keep a moderator from accepting a change in the author data. It wouldn't show up in a submission to add data. I see that Hauck accepted an earlier submission editing this author profile. I wonder if it had a year of birth, which in my opinion should have been retained in the record. That is insufficient data to cause a security issue, and enough to create disambiguation if necessary. Mhhutchins|talk 01:25, 29 September 2015 (UTC)

Yes, it had. MrFiction15 expressly asked for the deletion of his DOB. I complied with his wishes. As in France it's a legal obligation to do so, it didn't strike me as an excessive demand.Hauck 14:26, 29 September 2015 (UTC)

No, MrFiction15 asked that you remove the DOB of Michael De Kler. There's a difference there. How would anyone know that the requester is the author? Mhhutchins|talk 18:51, 29 September 2015 (UTC)

On the internet, nobody knows you're a dog.Hauck 06:03, 1 October 2015 (UTC)

I agree in general regarding deleting a fiction record in traditionally published material. However I think that some cases, we might be able to accommodate an authors request for total removal (reviews, essays, etc particularly if they were in a one-shot fanzine or similar, with out republication. The title might have been kept, with the authors name changed to 'uncredited' and a publication note that it was 'by request of author of TITLE'. Regardless it's a case by case question at best, and in this case there was no room for wiggling. Kevin 13:36, 29 September 2015 (UTC)

Kevin, do you seriously think this could ever be considered an option? Mhhutchins|talk 18:51, 29 September 2015 (UTC)

(unindent) Given the number of diverging opinions expressed above, I think we need an explicit policy re: this issue. I have copied this section to the Rules and Standards page and added my thoughts below. Ahasuerus 16:43, 29 September 2015 (UTC)

My overall take on the issue is that our data is and should be based on publicly available primary and secondary sources. We should aim to document where our author data comes from just like we aim to document where our publication/title/publisher/etc data comes from -- see Bio:Catherine Asaro for an example. This is one of the reasons why I am currently working on enhancing Notes, a prerequisite for moving Bio and Author pages to the database proper.

Re: legal issues, as long as our data is accurate, its sources are properly documented and the server is located in the US, I don't think we should have any exposure under the current US law. It's similar to the situation with Project Gutenberg. Their US-based repository and their Australia-based repository house different texts because US/Australian laws re: copyright are different. If and when the relevant American laws change or the ISFDB server is moved to another jurisdiction, we may need to revisit the issue.

Re: policy issues, I believe we should never remove or obfuscate stated author credits for publications/titles. For undisclosed pseudonyms, our policy for creating VTs has been not to do "original research", i.e. not to try to determine the real author(s) based on circumstantial evidence. Thus, we create VTs based on "special thanks" notes on copyright pages, but we don't do it based on analyzing and comparing different Web pages (we had this discussion with Marc years ago.)

I am less sure about author data. For paper-based sources like Contemporary Authors (see the Asaro example above), I think their existence should be an absolute defense. Internet sources, on the other hand, are a gray area. Suppose an author posts her date/place of birth and e-mail address on her Web page. A couple of years later she decides that it was a bad idea, deletes the information and asks other sites like Wikipedia and the Wayback Machine to remove it. The Wayback Machine allows site owners to remove their pages from the archive, but doesn't allow removing individual statements. Wikipedia uses the following policy for living people:

Wikipedia includes full names and dates of birth that have been widely published by reliable sources, or by sources linked to the subject such that it may reasonably be inferred that the subject does not object. If the subject complains about the inclusion of the date of birth, or the person is borderline notable [note that Wikipedia's policy for public figures is different], err on the side of caution and simply list the year. In a similar vein, articles should not include postal addresses, e-mail addresses, telephone numbers, or other contact information for living persons, though links to websites maintained by the subject are generally permitted.

My tentative take on this issue is that it may be best to follow Wikipedia's lead and "simply list the year" if the author objects. For e-mail addresses, I think it's OK to simply remove them if requested. It will simply mean applying the current data entry standard ("If the author's email address is public") retroactively. Ahasuerus 17:38, 29 September 2015 (UTC)

I agree with Ahasuerus. We should NEVER remove records for published works from the database, regardless of how the author feels. That's not our job. Nor should we hide the author credit as published. That's against ISFDB policy. About author data: we should only remove specific author data if the requester has proof that they are the author: date of birth and city/state of birth. But we should retain the year of birth and country of birth. That doesn't compromise a living person's security or privacy (unless their vanity is such that they don't want anyone to know their age.)

But, (and a big but), if the data is publicly available, such as in an "About the Author" bio, or on a public website, and the author is a public figure, we should respectfully deny the request to remove it. In other words, I like the Wikipedia policy and don't see a problem with the ISFDB having the same. Mhhutchins|talk 18:45, 29 September 2015 (UTC)

Hopefully, the result of this discussion will create a policy in which the source of the data must be provided by an editor before changing or updating an author's data. Mhhutchins|talk 18:54, 29 September 2015 (UTC)

I've got no wish to hold an extended debate on this topic as I believe the situation is rare enough to be simply handled on a case by case basis. However I do feel there could be cases where someone could reasonably request they be removed completely (or minimally hidden) from the database. Those instances would be rare and difficult to describe in advance. My best example is a one shot / con fanzine, with a 'poorly titled' piece of poetry, etc. Especially if that one-shot is in limited existence and there is little concern for it's use as a point of identification. In particular my mental example is something that had limited original distribution, has never been republished, and it's not unreasonable to accept that the original publication was an ill-thought out exercise and there is little value for a public documentation of the effort. Kevin 23:18, 29 September 2015 (UTC)

Imagine a Future Attorney General, at the state level, who his freshman year in college wrote a poem title "Lawyers Can Suck Vacuum and Die On Mars" perhaps with a few more curse words attached at 2 AM on Friday night and it was published in a one shot / post-con fanzine on Sunday morning. 20 years later, that's his only published credit, he is a lawyer or a high profile public figure. Exactly no-one benefits from the [public] documentation of the errors of his youth. Kevin 23:18, 29 September 2015 (UTC)

I also never implied that 'we' couldn't keep an archive of the few and limited cases and store that info in a non-public but moderator accessible location. Many Many Libraries, Archives and record sets have limited access information that has little public value, or has implications on a living persons livelihood. Most don't destroy the information... they simply hold it aside until an undetermined later date when it's deemed reasonable to release it. Kevin 23:18, 29 September 2015 (UTC)

Again... I'm stretching to find a situation where it would be acceptable to me.... and I found one. Maybe this isn't convincing to you folks. (shrug). It's a rare request, and I expect even more rare event that someone would qualify under the limitations I've imagined above. When I saw this request arrived, I gave it the benefit of the doubt that it might/could fit into that window of acceptability. Once I learned more, I easily concluded that the record was far to well distributed, and far to well documented for us to seriously consider expunging this particular publication. Kevin 23:18, 29 September 2015 (UTC)

I am concerned that modifying the rules/policy to allow this level of data alteration/deletion would be opening Pandora's Box. I think it would be better to keep a tight lid on it. Ahasuerus 04:55, 1 October 2015 (UTC)

I think allowing the option of removing even a long-ago fanzine article listing to be removed, without a court order, is a bad idea. Consider the following (true) scenario. An author publishes a short story in a 1970s fanzine, which is published with a co-author. Many years later, they publish it in a journal, without listing the co-author. The author later becomes embroiled in a case where a second author accuses them of plagiarism -- they had been collaborating on a story, the collaboration fell apart, and author 1 then published it on their own without attribution to author 2. The existence of that earlier discrepancy could be relevant to those charges. If author 1 knew about that fanzine listing and asked us to remove it, would we want to be part of that? I think not. I think we should be striving to be an authoritative source, one that folks can rely on. (Aside: I realize that some of you may recognize the author I'm talking about. You won't find the fanzine I'm referring to in their bibliography, because we do not currently index that fanzine. But someday we might.)

I do think it's possible to have an acceptable policy on "data removal". I would suggest something such as:

The following data may be removed from the ISFDB database at the author's request:

(1) Data that is not publicly available outside ISFDB, and sites that use it for their data, or that is only available via the Internet Archive;
(2) day and month of the author's birthdate;
(3) an email address;
(4) web links to non-authoritative pages;
(5) an author's photo;
(6) statements in the wiki pages (biographical or bibliographical) that are not written from a neutral point of view, or that would otherwise not be acceptable in a Wikipedia article.

No other data will be removed. As a community database, we cannot guarantee that once data has been removed, someone might not put it back in, and suggest that authors re-check their data occasionally.

I have previously removed an author's email address at their request, not thinking that such an action required discussion. I think removing web links that they don't like is reasonable: my understanding is that these were originally implemented for an author's formal web site, or for a semi-official fan page. If we link to a "fan" page that the author doesn't approve of, I think we should be willing to delete it. I'm not sure about deleting a photo at their request, but this has never been a central part of what we do, so I think we should probably be willing to delete it if asked. The rest of the "deletable" data is, I hope, reasonably agreeable. The "nothing else" sentence might be more contentious. Chavey 16:21, 1 October 2015 (UTC)

Response to Darrah's suggestion:

(1) We don't do original research so this would be unnecessary. Also, the Internet Archive gives website owners the option to not be archived.
(2) I agree.
(3) I agree.
(4) I have to disagree about "fan" sites. Some of the best websites for an author's work were created and maintained by fans, and never officially sanctioned by the author. I know of at least two major bibliography websites for major sf authors that never received "authorized" recognition. In one case, where the author was uncooperative, but I don't think would be so hostile to ask that any links to it be removed. I think such requests should be judged on a case-by-case basis.
(5) Another judgement call. If an author is a public figure, they should expect their photo to be posted. I wouldn't object to an author requesting an unflattering photo be replaced, but not a removal of all photos.
(6) I agree.

Mhhutchins|talk 17:04, 1 October 2015 (UTC)

A couple of thoughts:

It may be useful to make it explicit that the data removal policy only applies to living people, which would be similar to the way Wikipedia handles the issue.
Regarding Websites, I recall an incident when an editor added a link to" a Web page/post which described a certain author's controversial behavior at a social gathering. After discussing the issue with the editor, the link was removed since it wasn't biobibliographical in nature. I think it would be a reasonable standard to apply to all links. It should also help avoid problems with living authors. Ahasuerus 01:12, 4 October 2015 (UTC)

I pretty much agree with everything you two are saying. Mike, I don't disagree that many of the better unofficial "fan" sites are excellent sites to link to. But if a (living) author objected to linking to one of them, I think we should give serious consideration to dropping the link. Probably not automatically, it would depend on what the author's complaint was. But I wouldn't want "web site"s to be included in the "Nope, we're not dropping this" category of data. Ahasuerus gives one such example; I can imagine several others. Chavey 15:06, 5 October 2015 (UTC)

Perhaps you missed the last sentence in my response: "I think such requests should be judged on a case-by-case basis." I choose my words very carefully before posting them, and I always find it disconcerting when some of them just don't make my point clear. I'll try better. Mhhutchins|talk 16:54, 5 October 2015 (UTC)

We're in agreement on this with respect to web page links. We should probably have 3 categories: (a) We'll drop this if you request it (e.g. email addresses); (b) We won't drop this without a court order (e.g. your published works, regardless of how much you regret them); and (c) We'll consider this on a case-by-case basis. But it may be that writing up policy that actually speaks to those three categories would be clunky, and it might be simpler to combine (a) and (c) into a single description. Chavey 03:17, 6 October 2015 (UTC)

(unindent) A bare bones/preliminary version of the "Data Deletion Policy" has been added to ISFDB:Policy. Ahasuerus 02:53, 30 January 2016 (UTC)

Premium paperback size - time to revisit?

There was a discussion back in 2009 of a new pub format earlier and the gist was that we would wait and see if the new 7 1/2 inch tall format was a passing fad or here to stay. I sort books for a local charity and seem to be seeing more of these. I have in hand two copies of Jim Butcher's "Grave Peril" to enter - one in each format. The pb is 17th printing, the premium is 24th. The other books I own in that format also seem to be Penguin based (Penguin, Roc). Do we need something other than anecdotal data? Doug 16:09, 13 October 2015 (UTC)

I have been processing a lot of "$9.99" paperbacks lately and most of them appear to be using this format. It may be interesting/informative to visit a physical (gasp!) bookstore and see what the ratio is. Ahasuerus 03:24, 16 October 2015 (UTC)

Another reference source: W.R. Cole's Checklist of Science Fiction Anthologies

I'd like to suggest we add W. R. Cole's A Checklist of Science Fiction Anthologies to the Reference: Verification Sources. Although much of the info it contains for the 227 books it catalogs is also available in Tuck, Cole documents more precise publication dates than Tuck. Also, I've found one publication (so far) where Cole has a different price ... which is useful info, because I've seen more than one instance where Tuck documents the price of a later edition rather than the first edition. In any case, I realize this would require work by the Moderators to setup, so it's your call. Thanks. Markwood 02:04, 5 November 2015 (UTC)

With only 227 publications, it would be fairly easy to give Cole as a source in the Note field of each of those records. Listing it as a possible reference source on every single publication record in the database seems like overkill. Mhhutchins|talk 02:32, 5 November 2015 (UTC)

OK. Markwood 03:02, 5 November 2015 (UTC)

Publication series vs. regular series - anthologies

I think we need to create more precise definitions for a regular series and a publication series, in order to be more consistent in how they are used in relation to anthologies. The way I look at it, a publication series is a series of publications that are grouped together by the publisher, but which are otherwise not directly related. For example, Tales of Mystery & The Supernatural is a publication series containing mysteries and supernatural stories which are only related because they are mysteries and supernatural stories. They otherwise would have nothing to do with each other. The Moon Singer / Free Trader / Moon Magic series, on the other hand, is a regular series because all the stories are directly related to each other (in this case, all set in the same world, with some characters continuing throughout the series).

According to Ahasuerus, there are currently 4,288 anthology titles that belong to regular series and 2,853 anthology publications that belong to publication series. The way I see it, if a series of anthologies is collecting "The Best X of the Year" or "Topic Y Stories", it should be a publication series because the stories are not otherwise related to each other. They were simply picked based on whatever arbitrary criteria was established for that series. On the other hand, if the anthology is collecting stories all set in the same world, that is more than an arbitrary connection and it should belong to a regular series.

Ahasuerus asked me to bring this here for discussion, so please share your thoughts. ···日本穣 · 投稿 · Talk to Nihonjoe 17:30, 11 November 2015 (UTC)

I tend to assimilate our (ISFDB) "Publication Series" concept with the (european publishing) concept of "collection". Broadly speaking, it's a set of books (usually but not always by the same publisher) with a similar packaging, its distinctive aspect is that it's an attribute of the publication. A "regular" series (or so I suppose from your description) is a group of texts set in the same universe (or eventually sharing a similar aim like here), its difference from the previous type of series is that it's a attribute of the title. So, for me, this is more a publication series than a regular one. There are cases where both notions merge, like this publication series which in theory contain only texts part of this regular series. Hauck 18:00, 11 November 2015 (UTC)

I guess the biggest advantage of the current method of handling anthology series is that it makes it easy to find them on their respective editors' Summary pages. If we were to convert them to publication series, they would be scattered throughout the Anthology section of each Summary page. Ahasuerus 18:04, 11 November 2015 (UTC)

P.S. I should also note that we handle magazines as regular series even though they contain largely unrelated texts. Ahasuerus 18:05, 11 November 2015 (UTC)

It's perhaps possible to have both concepts activated (as they're at different level, publication and title). This publication series may be seen as being made of titles belonging to the same regular series (sharing the same philosophy or being part of the same project). I don't know how it may look on display. Hauck 18:15, 11 November 2015 (UTC)

Sorry, but it's quite obvious, I'd think, that a publication series belongs usually to one publisher (it may occasionally be published in a parallel or later edition, or continued by another publisher). The question we have to ask is if a series could be published by another publisher without having to change the title. This obviously is the case with 'Binary Star', and it'd be nearly impossible to reorganize a similar series like Pohl's Star Science Fiction. At least for those series there's a certain policy or character, impersonated by the editor(s). Stonecreek 19:37, 11 November 2015 (UTC)

If we change anthology series from title series to publication series, this will happen: 1) They will not be displayed as series on the editors' summary page. 2) All of the publications (reprints included) will have to be updated to add the publication series data which may make the display of the series very messy and unorganized. 3) A user will have to go one level deeper to see them all displayed together, but will never get a clear picture of each title in the series, only a gathering of publications. 4) As Christian points out, the contribution of the editors of these series will be diminished.

I believe anthology series are title series, because there is a connection beyond the design and packaging of a publisher (which is one of the defining characteristics of a publication series). The connection between the various volumes of these series may not be textual but it is spiritual, and that is controlled by a single personal vision, not a corporate entity. Would it not be of better service to our users to see all of Terry Carr's "Universe" and Dozois's "Best of" volumes under a title series? Mhhutchins|talk 21:30, 11 November 2015 (UTC)

Is it possible to adjust the display of pub series on editors' pages so that it isn't "messy"? Maybe as a feature request? ···日本穣 · 投稿 · Talk to Nihonjoe 06:24, 12 November 2015 (UTC)

Author/editor/artist pages only display titles. No author/editor/artist pages display publications. Publication series are not author/editor/artist-defined. That's the whole point. They're all about the publication. Changing the software to display publications on people pages is probably not even possible without making drastic changes to the database structure, and, in my opinion, ill-conceived. Mhhutchins|talk 08:43, 12 November 2015 (UTC)

(Returning to the original question) My rules of thumb:

Could the SAME publisher realistically take any two of the works in the series and publish them as part of two new, different series and have that make sense? To me, the answer with regard to the Binary Star and Best of... examples is NO, so that indicates to me a title (a.k.a. "regular" series).
This one is more of a stretch, but... Could another publisher realistically take any one of the works in the series and publish it under the same series name, while the first publisher is still publishing the same work/series combination? Say, for example, one publishes hardcovers and the other paperbacks or e-books. If the answer is YES, that also indicates to me a title/regular series.

I see anthologies as very similar to magazines. The single work is assembled by the editor for whatever purpose (Michael's "spirit"). If the same editor does more assembling for the same purpose, or if another editor comes along and does similar assembling for the same purpose, ANY publisher could take that assembly and publish it, without having any impact on that underlying purpose. To me, that's the essence of a title series. --MartyD 12:06, 12 November 2015 (UTC)

Very well put. I think it is too restrictive to limit the title series designation to those works which have common settings and/or characters. Mhhutchins|talk 19:51, 12 November 2015 (UTC)

I agree with Marty, and think something like his description should be essentially our definition. Chavey 03:09, 14 November 2015 (UTC)

variants by author's middle initial?

Subject of my concern: "Night Chills" by Dean (R.) Koontz.
This has spun off two variant title listings, http://www.isfdb.org/cgi-bin/title.cgi?3988 and http://www.isfdb.org/cgi-bin/title.cgi?1467205, apparently based only on the presence of Mr. Koontz's middle initial; and in fact, the former seems to also contain all the publications listed on the latter title page, despite the slight difference in author's name.
Given that these are unquestionably the same book with apparently no other change than the R., should the second title page be deleted?
Thanks. gzuckier 18:20, 11 November 2015 (UTC)

No, in fact the page of the "canonical" title (here the one with the "R." i.e. the books with the canonical name) always contains all the variants (like here with a really different pseudonym). The page of the variant (non-canonical) only lists itself. Hauck 18:42, 11 November 2015 (UTC)

Ahhh, very educational. Thanks.

oh, btw, does one update both pages, or is it automatic? gzuckier 18:48, 11 November 2015 (UTC)

It depends what you mean to update: if you want to change the date, for example, you'd have it to do for both entries; if you'd like to add a note it's enough to do so for the canonical entry. Stonecreek 19:15, 11 November 2015 (UTC)

page count

On a related note; I'm unclear regarding the standards for page count.
In particular, if there are 8 pages of nonnumbered blank, title page, etc., then a 2 page introduction with the second page numbered x, then the numbered pages starting at 1, would that be x + [2] + 369, or viii + [2] + 369, or other?
Thanks gzuckier 18:47, 11 November 2015 (UTC)

From your example it sounds that both would be wrong (which would be the [2] pages in the first, and what's happened to the x in the second?). Following your description it likely should be x+369. Stonecreek 19:19, 11 November 2015 (UTC)

Here are our stated standards concerning the Page Count field. (This question would have been better posted on the ISFDB:Help desk, unless you know the standard and wish for a discussion about changing it.) Thanks. Mhhutchins|talk 21:36, 11 November 2015 (UTC)

Cover image titles on a dos-a-dos work

Re: this title. Should I leave both as "Cover: Firstborn / Defending Elysium", or change them to "Cover: Defending Elysium" and "Cover: Firstborn" to match which artist did which cover? Or just put a note on it stating which one did which cover? Thanks! ···日本穣 · 投稿 · Talk to Nihonjoe 07:51, 16 December 2015 (UTC)

Change the title of each COVERART record to match the title of the work which it represents. Mhhutchins|talk 08:14, 16 December 2015 (UTC)

That's what I was thinking, but I wanted to make sure that was fine. Thanks. ···日本穣 · 投稿 · Talk to Nihonjoe 17:28, 16 December 2015 (UTC)

N/A - correcting an unused standard

An odd documented standard was brought to my attention by a new editor, a standard which I'd never seen before, and one that has never come up before. As stated here:

If a work by its nature has no author or editor, use "N/A"; this applies to unedited letter columns.

In the cases of uncredited letter columns (not sure what "unedited" means in this context), I was told to use "various" as the author eight years ago and continue to do so, as do most other editors. Shouldn't the documentation reflect that de facto standard? Especially since there are hundreds of title records for letter columns already credited to various? Mhhutchins|talk 06:14, 11 December 2015 (UTC)

I'm not sure, because the letter column should have been edited by a certain person (whose identity we might know or not), so it should rather be 'uncredited' than 'N/A', whereas the contributors to the column, i.e. those whose letters got selected by the editor, can be subsumed under 'various', I'd think. Stonecreek 07:18, 11 December 2015 (UTC)

I believe a letter column is a collection of works written by variously credited authors, just as a story in the same periodical is written by the credited author. All of the works in the periodical are edited by the editor, who is not credited as the author of the works which he/she edit. The ISFDB editor has the option to a) create a single record for the column or b) create records for each letter credited to its author. A letter column can't be "uncredited" if it credits the individual letters which make up the column. Mhhutchins|talk 08:51, 11 December 2015 (UTC)

In most cases there is an invisible but quite active editor at work: it is most common to print not the whole letter but only a part of it. That is the case for everly letter column (and often there are some kind of comments or answers, of which the readers / writers of letters can't be held responsible. It's just the same as a reviews section of reviews authored by different persons is or should be handled. Stonecreek 10:36, 11 December 2015 (UTC)

I credit "various" to a review column when there is more than one reviewer. And like letter columns, the individual reviews are credited to the author of each review. Many other ISFDB editors do the same thing. Take a moment to look at the page for various. My point is that review columns and letter columns should be credited to the authors, not the editor. Surely, you're not saying the periodical's editor should be credited as the author of everything in the publication. The editor brought together the works of different authors to create the column. He didn't write it. That's why they are credited as the EDITOR of publication records typed as ANTHOLOGY and MAGAZINE, not as the AUTHOR of the publications. The reason for starting this topic is to correct a documentation for a standard that nobody uses, and to change it to the de facto standard. Just look at how these letter columns and review columns are credited will show what editors have been doing. Even in publications which you, Christian, have primary verified. Mhhutchins|talk 21:13, 11 December 2015 (UTC)

I have never seen, or used, "N/A" for this purpose, and the description from the help doesn't make any sense to me. Unless a work was randomly generated (or randomly drawn) by a computer, SOMEONE wrote it, so how could the concept of author be n/a? I agree that "various" is the de facto standard for letter/review columns and should be documented (replacing that text about "N/A"). --MartyD 12:04, 12 December 2015 (UTC)

I agree that "N/A" shouldn't be listed as an option in Help. I seem to recall that it was used in the ancient past, but only in a few records and they have all been corrected since. Ahasuerus 15:54, 12 December 2015 (UTC)

I also agree "N/A" shouldn't be used. -- JLaTondre (talk) 23:10, 12 December 2015 (UTC)

I don't understand your example (which may be caused by a misreading on your side, Michael): the letter column is titled Perry Rhodan Leserkontaktseite and is edited in this case by a credited person. The single letters are written by 'various' persons (and sometimes by people that are relevant to ISFDB). So, this example in fact emphasizes what I wrote: the column is edited by a known/unknown person that may be credited/uncredited; the letters in turn are written by different writers, and are edited (selected, abridged, commented on) by the editor of the letter column. Stonecreek 08:37, 16 December 2015 (UTC)

(unindent) I have removed the reference to "N/A" as per the discussion above. As far as "various" goes, the Help template doesn't mention it at this time. We may want to start a separate discussion to decide when to use "various" vs. "uncredited". Ahasuerus 00:48, 14 January 2016 (UTC)

Date of an INTERVIEW title record

According to this documentation, the date of an INTERVIEW record should be "the date the interview is conducted." That has never been the basis of dating an interview in the 8 years I've been here. It's always been the first date of publication, a standard that applies to all titles. It's very likely in the majority of cases, the date that an interview is conducted isn't stated and can't be determined, so I'm not sure why this was ever documented as the standard. Is there any objection to my changing this section of the help documentation? This was brought to my attention by a new editor. Looks like we need some fresh eyes to point out all of the discrepancies in our help documentation. I wish I had the time to go over our help pages to find such discrepancies. But I don't have the time to argue with editors who want to nitpick about changing the stated standard to the de facto standard. Mhhutchins|talk 22:39, 12 December 2015 (UTC)

It should be date of first publication. -- JLaTondre (talk) 23:12, 12 December 2015 (UTC)

I agree that Help should be changed to "the date of first publication". Ahasuerus 23:19, 12 December 2015 (UTC)

Never realized it was supposed to be anything else! :-) --MartyD 03:43, 13 December 2015 (UTC)

(unindent) Change made. Ahasuerus 00:43, 14 January 2016 (UTC)

Sculptures

I'm uncertain how a work typed as INTERIORART can be credited to one artist but is actually sculpted by another. Can you set me straight? Thanks. Mhhutchins|talk 21:08, 10 December 2015 (UTC)

Michael, I've been doing the same thing for all the dimensional art in the Spectrum books. As the notes for each pub says, the photographer is shown as the artist when a separate photographer is credited, and the sculptor is shown in the note for the artwork. Bob 23:15, 10 December 2015 (UTC)

So if I take a photograph of Michelangelo's David, I would get credited as the artist in an art book? I don't think so, and neither should I be credited in the ISFDB. Adding the actual artist in the Note field makes it impossible to find the credit on the ISFDB for the creator of the art being honored in a collection of the year's best art. Don't you think? Mhhutchins|talk 01:26, 11 December 2015 (UTC)

No, Michael. Not unless you're a much better photographer than I suspect you are. But my approach wasn't so simplistic. Some sculptors who created the artwork didn't take photos of their own work. Why not? Many obviously did so. But some didn't think their own talent at photography was sufficient, and wanted the photos to show their work in the best possible way. They asked for help from talented photographers. I noted that in these pubs, only dimensional art credited people who created the reproduction. Does that mean that the dimensional art was judged from photos, and was not itself present at the judging? I suspect that was true (although I don't really know). Had the sculptures been available, the publisher could have used a professional photographer to reproduce all of the art work for publication, but clearly didn't. So the professional or talented amateur photographers who took the photos created their own works of art, and those I credited because they are actually what we see in the publication. You may not agree, but my choice was rational, and I think the right one. The only alternative I can see is to credit both the sculptor and photographer, but that seems confusing. Bob 19:55, 14 December 2015 (UTC)

We obviously disagree, so I'll copy this to the rules discussion page to get other editors' views. Thanks. Mhhutchins|talk 20:08, 14 December 2015 (UTC)

As there wouldn't be a catalogued work of art without the sculpture, the initial artist clearly should be credited. I personally wouldn't credit the photographer, but there may be circumstances when one would allow for a co-credit of the photo taker. Stonecreek 08:45, 16 December 2015 (UTC)

In a traditional art book, there are lots of photos of different pieces of art. The original artist is credited at the picture; the photographer gets a footnote or an endnote acknowledgment. I'm on the editorial board of the Journal of Math and the Arts. We use that policy as well. I believe that's what we should do here also. Chavey 02:27, 17 December 2015 (UTC)

I agree. Except in rare cases where the photographer is creating a work of art through how they are photographing something, I have always seen the creator of the work being photographed get the credit. ···日本穣 · 投稿 · Talk to Nihonjoe 01:00, 14 January 2016 (UTC)

Record Numbers from Secondary Sources

For a few years now, I have been adding the record numbers from secondary sources in the publication notes (e.g. here). I recall seeing that other editors follow this practice as well. Bluesman has objected to this practice arguing that including these numbers in publication notes would "add no bibliographic data" (see this discussion). He seems to imply that adding such numbers be prohibited, but I'll invite him to this discussion and ask him to further explain his position. My thoughts are that such numbers are a useful cross reference and I do recall seeing them in both Worldcat and Library of Congress records occasionally. Further, some booksellers add such numbers in their listings and database users might find it useful to match a listing to our records to know exactly which edition of a book is being offered. Does anyone else have an opinion on whether record numbers from secondary sources should be allowed in publication notes? Thanks. --Ron ~ Rtrace^Talk 21:10, 28 December 2015 (UTC)

There is a Feature Request to add:

... support for external identifiers at the Publication and Title levels. Publication identifiers can include LCCNs, Worldcat IDs, British Library Ids, Goodreads IDs, etc. Title identifiers can include "Work" identifiers used by LibraryThing, Goodreads and other social cataloging Web sites.

The key difference is that all the above, with a link, are accessible online. Such identifiers from print sources are completely worthless. If, someday, such catalogs [Tuck/Reginald/Clute] are accessible through cyberspace, then one could actually see the 'record'. I agree with Hervé, that as-is these numbers are just clutter. The fact that some booksellers cite them doesn't mean anything, just a pretentious selling 'trick'. And I 'implied' nothing, just voiced a requested answer. Cheers! --~ Bill, Bluesman 21:53, 31 December 2015 (UTC)

Once this feature has been implemented, we'll be able to move third party identifiers out of the Notes field. For now, I suspect that the recently added "{{BREAK}}" functionality could be a reasonable compromise as long as these identifiers appear at the end of the Note field. Ahasuerus 02:46, 29 December 2015 (UTC)

IMHO, in your example, it tends to noticeably clutter the note field. I'm more in favor of Ahasuerus FR. Hauck 13:45, 29 December 2015 (UTC)

I see nothing wrong with entering the catalog number of non-internet secondary sources, if they were used as a source for the record's data. I don't understand why some editors enter (and link) secondary sources in a record for data that has been primary verified! To say "Such identifiers from print sources are completely worthless" seems somewhat odd from an editor who updates other editors' primary verified records with links to secondary sources. Now that's a practice which I call cluttering a record's Note field!

Also, I wish editors would use the documented standard (here and here) when entering external identifiers in an ISFDB record's Note field. Enter the name of the source followed by a colon and space, and then the identifying record number, e.g. "LCCN: 12345" and "OCLC: 12345". Even after bringing this to the attention of longtime editors, some still insist on using another format. Using the standard format will make it easier to make a universal change without manual editing if we ever get a dedicated field for external identifiers. Mhhutchins|talk 01:14, 14 January 2016 (UTC)