Rules and standards discussions/Archive/Archive15

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 2017.

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

Need help identifying book as spec fic

I'm unclear as to if the following book is spec-fic or not.:

Phantom Sun/White Needle by Carl Bowen

The book is about a special forces group called "Shadow Squadron" tasked to recover a crashed unidentified flying object from Antarctica. The object turns out to be a hunter-killer drone satellite, well in the zone of spec-fic. It was published by Scholastic, dos-a-dos with another book in the series. White Needle, not obviously spec-fic (Syrians and chemical weapons). The book is glossy and illustrated, first published by Stone Arch Books.

If one is spec-fic and the other isn't, can it still be included?--Auric 22:35, 7 February 2017 (UTC)

If one of the two stories is genre, then the publication is in. I think that given it's dos-a-dos, and the author has a bunch of spec-fic works, it would be ok to index the other story and mark it non-genre. Even if we don't consider Bowen "above the threshold", it's a pretty clear case that wouldn't necessarily open any floodgates. But I do have inclusionist tendencies.... --MartyD 02:45, 8 February 2017 (UTC)

Thanks. I've just submitted it.--Auric 13:01, 8 February 2017 (UTC)

Capitalization of "a.m." and "p.m."

I realize the English capitalization rules leave a lot to be desired, but I'll try to ask a simple, focused question and hope we can keep the discussion to just that: Should "a.m." and "p.m." be among the things that are always lower case? We are rather inconsistent, and to me "A.M." and "P.M." in mixed-case titles looks weird. I don't think that is my U.S. English handicap speaking.... --MartyD 11:48, 27 February 2017 (UTC)

As they are in practice abbreviations of words that would have been with capital letters, it is more logical to have them capitalized. At least for me anyway. Not that we follow the most logical rules all the time though :) Annie 18:28, 27 February 2017 (UTC)

A little googling finds the following quote (note the bad HTTPS connection) from "Common Errors in English Usage", third edition, 2013:

• ...in formal writing it is still preferable to capitalize them, though the lower-case “am” and “pm” are now so popular they are not likely to get you into trouble.

Ahasuerus 21:16, 27 February 2017 (UTC)

Well, Paul Brians isn't one of the most commonly cited authorities. The Chicgo Manual of Style, the AP Stylebook, and Garner's Modern English Usage go with a.m., all of them more respected sources than Brians. So I guess Marty has the majority behind him (to my surprise -- it's not what I expected to find when I started looking at stylebooks). --Vasha 22:50, 27 February 2017 (UTC)

For Title Case? I know that their recommendation for regular writing is to leave them small letters but last time I looked (I'd admit it was awhile), they were not on the exception list for Titles Case capitalization Annie 22:59, 27 February 2017 (UTC)

Ah, good point, I wasn't thinking! I really can't find anything about that. However, two letter abbreviations like vs. and e.g. don't get capitalized in titles (I think!), so I guess maybe not?? --Vasha 23:13, 27 February 2017 (UTC)

Yeah, I know. But something is bugging me for this case specifically - it had stuck in my mind as always getting capitalized because of their function (unlike e.g. for example). Bulgarian does not use title case (Titles use the same capitalization as standard writing) so the rules were a pain to remember and some of them had been stuck for awhile :) Annie 23:28, 27 February 2017 (UTC)

There are three widely used "style manuals" in the U.S. -- MLA, APA, and Chicago. MLA says to use "a.m." (lower-case, periods, no extra spaces). APA says to use "a.m.". The Chicago Manual of Style says to use either "a.m." or "AM" (small caps, no periods, no spaces). It's not clear that these rules follow over into titles, but the rules are surprisingly consistent for other uses. Chavey 06:18, 28 February 2017 (UTC)

Yes, and Garner (Oxford University Press) is one of the usual sources for the UK -- same again. The problem is I don't have an actual copy of any of them to search if they go into nitpicky details about titles. --Vasha 09:32, 28 February 2017 (UTC)

The Random House Handbook claims there is no consensus on capitalizing A.M./P.M. In any case, we should be consistent. I would vote for capitalization in titles, since it looks wrong to my eye not to do so.--Rkihara 18:19, 28 February 2017 (UTC)

(unindent)I have copied out some sections from the Chicago Manual of Style here. The book does not address this particular issue at all. However, the sections I copied address some issues which (I believe) have not been standardized here. If they're ever debated, the reference material is now available. I'm now off to check other reference books. --Vasha 18:48, 28 February 2017 (UTC)

Unsurprisingly, the other works consulted didn't answer the question of abbreviations either.

• The APA Publication Manual (5th edition) goes into very little detail, saying only "Capitalize major words in titles of books and articles.... Conjunctions, articles, and short prepositions are not considered major words; however, capitalize all words of four letters or more. Capitalize all verbs (including linking verbs), nouns, adjectives, adverbs, and pronouns. When a capitalized word is a hyphenated compound, capitalize both words. Also, capitalize the first word after a colon or a dash in a title." This is much too vague, and leaves open the possibility that there may be words other than "conjunctions, articles, and short prepositions" that are "not considered major words". One difference from the Chicago Manual of Style to note is that, where CMoS recommends not regarding words after a dash as a subtitle for capitalization purposes (their example is Chicago—a Metropolitan Smorgasbord) APA says "capitalize the first word after a colon or a dash in a title". In this case, at least, the APA makes more sense to me.
• I have copied some sections from the MLA Handbook (7th edition) here, for general reference. On the question of capitalization after a dash, they side with CMoS.

--Vasha 21:01, 28 February 2017 (UTC)

(later addition) Being as the books give no answer, we should just choose a practice and stick with it. I suggest "Always capitalize abbreviations unless they are a preposition like vs.; capitalize every initial before a period (A.M., N.B.)" --Vasha 00:33, 9 March 2017 (UTC)

Disambiguating "untitled" Interior art

We have a policy to disambiguate Introductions and similar items but it seems like we do not have one for Interior Art titles called "untitled". As a result, for example has multiple titles called like that (and in the same year look at 1953 for example). Which makes it meaningless in her bibliography. Shouldn't we follow a similar rule for these as we do with Introductions for example and mark where this generic title belong to? There are 208 entries like that in the DB now (list) so it should be easy enough to convert them. But we need a rule for that. Annie 20:31, 27 February 2017 (UTC)

It seems natural to extend the scope of "generic titles" treatment to cover this case. --MartyD 03:38, 28 February 2017 (UTC)

I agree. I've generally entered "Title of the Book" as the title and set the title type to "INTERIORART". ···日本穣 · 投稿 · Talk to Nihonjoe 19:22, 28 February 2017 (UTC)

That's what I would do for an untitled art - name it after the work it belongs to or if it does not belong to a specific one, use the book name. But there are a lot of Untitled ones out there. Thus the question :) Annie 20:44, 28 February 2017 (UTC)

Handling of suffixes on author names

It seems actual practice for the Legal Name field on authors deviates substantially from the help's: .... No suffixes or prefixes should be used; "Jr.", "Capt." and so on are not recorded in this field.. Some examples:

• Jr
• II + III
• III only

One problem I noticed from an editor's submission I processed is that if the author's actual name contains such a suffix, but the author does not use it (so no canonical name having it), there is nowhere in the author record to capture it.

Should we change the policy for this field to reflect practice, and, if so, what should the standard for position of the suffix be (at the end, or after the surname)? I included the III example because the first page of results illustrates the present inconsistent placement. --MartyD 03:45, 1 March 2017 (UTC)

As we are already forcing Last, First (which is not the usual way for a lot of countries), I am in favor of Last, First, Suffixes. The only issue will be if First contains commas which I am not sure happens often enough to worry about it. Annie 22:32, 1 March 2017 (UTC)

(unindent) There is definitely an issue where a suffix is part of the author's legal name and should be recorded. I propose we reword this portion of the existing Template:AuthorFields:LegalName text:

No suffixes or prefixes should be used; "Jr.", "Capt." and so on are not recorded in this field.

as follows:

No prefixes should be used: "Capt.", "Mrs.", "Sir", and so on, are not recorded in this field. Suffixes that are not part of the legal name -- for example, "Sr.", educational and professional designations such as "Ph.D." or "M.D.", ranks and orders such as "Col.", "K.G." -- also should not be recorded. Certain suffixes such as "Jr.", "II", "III", and so on, may or may not be part of the legal name. We assume they are not, unless we have reliable evidence to the contrary. If a suffix is part of the legal name, use the format "Lastname, Firstname Middlenames, Suffix".

I also think the existing text's "The format of the legal name should be" can be tightened up to "Use the format". The full result (with changed text highlighted here, but not in the final presentation):

Legal Name - This field should contain the most recent legal name for the author. For example, James Tiptree, Jr. was a pseudonym of Alice Sheldon, who was born Alice Bradley. Alice Sheldon is the most recent legal name for this author. Use the format "Lastname, Firstname Middlenames", with all names being given in full. The reason for this format are names like “Patrick Nielsen Hayden” where you can't readily tell whether the last name is “Hayden” or “Nielsen Hayden.” No prefixes should be used: "Capt.", "Mrs.", "Sir", and so on, are not recorded in this field. Suffixes that are not part of the legal name -- for example, "Sr.", educational and professional designations such as "Ph.D." or "M.D.", ranks and orders such as "Col.", "K.G." -- also should not be recorded. Certain suffixes such as "Jr.", "II", "III", and so on, may or may not be part of the legal name. We assume they are not, unless we have reliable evidence to the contrary. If a suffix is part of the legal name, use the format "Lastname, Firstname Middlenames, Suffix".

I suspect it might be useful to bold the two format strings to make them easier to pick out. Anyway, what do people think? Is it clear? Concise enough yet comprehensive enough? Acceptable? Oh, and an aside: Should "Lastname" be changed to "Familyname" to be consistent with the change we made (back in 2014) to the label for that separate field? --MartyD 13:25, 4 March 2017 (UTC)

The motion carries due to lack of dissent. --MartyD 13:12, 12 March 2017 (UTC)

Regularization of Publishers

As Bill and now Dirk are now discreetly (without notifying PVs) de-regularizing publishers (for example yesterday changing back "Coronet" to "Coronet Books", or "Magnum" to "Magnum Books") that were specifically regularized, my question is simple: "Do we still regularize publishers?". If this policy is officialy abandoned, it would be nice for the people that are coaching new contributors and try to teach them our idosyncrasies (regularizing publishers is one of them) to be informed of this fact (and so the corresponding cleanup report that I exploit every day be deleted). If it's not the case (we keep on regularizing), it would be similarly nice for every contributor to follow the agreed-upon rules.Hauck 07:55, 8 March 2017 (UTC)

And just in case my question is for NOW, so please do not deviate on a hypothetical future system of publisher's variants. Hauck 10:12, 8 March 2017 (UTC)

I prefer "as in the publication", rather than regularized, as I think it's easiest to follow and to explain (although it's also the most difficult for the moderators to notice errors). But it seems we'd need some sort of pseudonym-like, or other linking, functionality to allow one to find all publications by a publisher, independent of vagaries of name. Without that, it seems some amount of regularizing is the most practical approach. My understanding (and what I've been enforcing/allowing) is that we regularize. --MartyD 11:40, 8 March 2017 (UTC)

I like the idea above of creating variants. We'd have to carefully think out how to apply it in order to deal with publishers merging and splitting over the years, but we could likely come up with a good way to handle it. ···日本穣 · 投稿 · Talk to Nihonjoe 07:20, 20 June 2017 (UTC)

When I am adding, I always check how we have the publisher in the DB already and use that name. Going back to "as is in the book" will make all of the old regularized records incorrect... We may actually be better served with two separate fields - regularized and "as is" Publisher - one used for showing the lists, one used for completeness. But that is going off script so I will shut up. Annie 16:12, 8 March 2017 (UTC)

My preference would be to use "as in the publication", with a limited number of exceptions. For example, I don't see much value in including ", Inc." or ", LLC", but I do think there's a value in distinguishing between "so-and-so", "so-and-so and Company", and "so-and-so & Co.", since these variants sometimes tell us about particular year ranges for the publication, which then is useful for pubs without years. Chavey 03:47, 9 March 2017 (UTC)

For good reasons, I think, we regularized publishers: Like ", Inc." or ", LLC" the addition of Publisher, Books, Editorial, Editore, Verlag etc. not only doesn't tell us much, it also would devaluate the summary page for the publishers, as it would disintegrate with every slight change of name. In effect, the reasons are the same as for regularizing titles and author's names. And as Marty hinted at, moderating the publishers side, will be extremely more difficult! Christian Stonecreek 04:23, 9 March 2017 (UTC)

Notes on the book level (or even on a publisher level) can add all those details on the "used name at a certain time". Unless if we have a good way to connect the different ones (2 fields or the current over-regularized ways), we will start losing the connections inside of a publisher. I am all for complete "as is" record but if that makes it impossible to find all books published by a publisher in a year, the DB simply does not work :) Just thinking aloud... Annie 04:42, 9 March 2017 (UTC)

An interesting issue cropped up in a submission today. Tolkien: min vän Ronald och hans världar had a publisher credit of Atlantis, which is the German "Atlantis Verlag", while the book is in fact published by the Swedish "Bokförlaget Atlantis". "Bokförlaget" is the equivalent of "Verlag" (notice the förlag). So, which is better/worse? "Atlantis Verlag" and "Bokförlaget Atlantis" or "Atlantis (Germany)" and "Atlantis (Sweden)"? For now, I let the "Bokförlaget Atlantis" change through and did not touch the existing Atlantis, since some form of disambiguation is required, but that's clearly inconsistent, so one of the two should be changed further. --MartyD 10:39, 18 June 2017 (UTC)

In this case, I would personally prefer Atlantis (Germany)" and "Atlantis (Sweden)", since I think those are both more readable to those without extra language skills, and more likely to be usable to someone entering data from, say, WorldCat. In a random sampling of 30 books in WorldCat from "Atlantis" (Germany), 9 of them included the word "Verlag", but all 30 included the city from which it was published. Chavey 01:59, 20 June 2017 (UTC)

Stories initially published in non-genre media

We seem to have two separate ways to handle these cases:

• Note in the title record mentioning the first publication
• Adding the magazine/newspaper/book as non-genre and with limited content (as per the rules).

Is there any reason to have both ways and if so, what is the preferred one in which case? For the record - I prefer the second way - it allows the first publication to be visible in the publications table PLUS it allows to spot magazines/newspapers that print our stories often. So is this one of those "editor decision" things or am I missing a distinction and/or a rule here? Annie 00:27, 16 March 2017 (UTC)

I prefer the second way, and generally use it for the reasons you give. ···日本穣 · 投稿 · Talk to Nihonjoe 00:37, 16 March 2017 (UTC)

I prefer the second way, but additional factors come into play: There's no requirement that non-genre publications be entered, so some editors may choose not to do so. Sometimes the information comes from attribution/credits given in another publication that's being entered, so all the editor has available is that information. In both of these cases, we certainly prefer the note to nothing. And once the note is there, do we care if it remains, should the publication cited be entered (if we even noticed)? --MartyD 01:29, 16 March 2017 (UTC)

Yeah, for the stories where we do not know the exact issue/publication, the note is the only way anyway. I was really thinking about the ones where we do know all the details - they were just never used to create the parent record. Editors have a choice not to add them of course - but if it is noted already and someone stumbles on it, is there a valid reason not to add it? Annie 01:59, 16 March 2017 (UTC)

As a general rule I like having publication records because they can be verified. In addition, even if they can't be verified, they let us capture whatever bibliographic data we have about the title's appearance.

If I recall correctly, the main argument against creating pub records was that it could greatly increase the number of non-genre records in the database. I am not sure it's a significant concern at this point given the limited number of pub-less titles that we have on file. I may be forgetting some other arguments, though. Ahasuerus 02:13, 16 March 2017 (UTC)

Well, a lot of the Bulgarian first translations and stories were published in non-genre magazines (genre magazines did not develop until very late) - some of them similar to Nature - one story per issue; some of them doing one in a blue moon. It still is important information and as we are a DB, cross-indexing is important. Which made me wonder why the practice is as is. Thanks for the background. Annie 02:24, 16 March 2017 (UTC)

(discussion of the proposed cleanup project moved to this section of the Community Portal)

Author's wishes vs ISFDB practices

According to any rule we have (written or spoken), the canonical name for an author will be the most used one (or the most recently used one anyway - as it tends to become the most used sooner or later). Apparently this does not apply if an author prefers a different version to be their canonical ones. Can we have our help page edited to reflect this?

The case that brought that is W. C. Roberts - ~65 titles, including all current ones under that name and yet, the canonical is set to Willis Couvillier. My attempt to reverse the pseudonym was rejected due to author wishes (no note anywhere on the account about it). If this is to remain this way, we need a few things to happen:

• A note need to be added to the canonical name in the effect that: "Despite ISFDB accepted practice, the canonical name is set to a name that is not the common name due to the wishes of the author". That will stop someone (me including in a few months when I forget) to try to "fix" it again.

and

• all those 64 remaining titles need to be varianted to go under the canonical.

Can someone confirm that this is the correct approach? :) Annie 22:19, 21 March 2017 (UTC)

If there is agreement on the author's wishes trumping standards, than that would be the best way to handle it. Personally, I don't care too much, but I think that is starting a slippery slope. However, whichever moderator accepted the original pseudonym and/or rejected your change should be the one that does the varianting. They should never have left it in that state. If they want to trump standards, they should do the cleanup and not leave it for others. -- JLaTondre (talk) 00:02, 22 March 2017 (UTC)

It's exactly why I stopped cleaning-up (except my own and the approved-by-me mistakes). Hauck 07:04, 22 March 2017 (UTC)

I don't recall a decision to make the author's wishes the decisive consideration when determining the canonical name. Granted, sometimes an author can provide additional information about the way he or she has been credited, which may help us decide which name to use as the canonical name. At the same time an author who is not an active editor may not even fully understand how we use "canonical names", so the ultimate decision needs to be made by editors and moderators. Ahasuerus 00:57, 22 March 2017 (UTC)

It was at some time a common phrase that we are an author-friendly site: that is, we do recognize and try to fulfill author's wishes, if possible. If that attitude should have changed, please someone should do a general revocation. (This may have in fact have changed with some of the moderators who were responsible in those far-away times are now absent). Stonecreek 21:20, 22 March 2017 (UTC)

I don't think we have ever had a general policy of trying to comply with author wishes. For example, when authors ask that their works be removed from the database, their requests are uniformly denied. There have been enough requests to warrant updating our Policy to say "the ISFDB doesn't delete publications/titles that are known to have been published".

At the same time, we do consider author requests and sometimes adjust our policy to accommodate them. For example, early on we received an author request not to add her pseudonyms which had not been made public at that point. That's when we amended our Policy to say that "only publicly available sources are used". Just this month we updated Policy to formalize the process of removing biographical data based on author requests.

So I wouldn't say that the general policy has been to comply with authors' wishes/requests, but we try to take them into account when formulating our policy and/or our data entry rules. In this case the rules say that "For authors who publish under multiple names, the canonical name is the most recognized name for that author." Of course, if there is a proposal to change this rule, we can start a discussion on this page. Ahasuerus 21:47, 22 March 2017 (UTC)

So the agreement is that there is no agreement? I do not like accepting author's wishes for something like that - it is different for personal information but if they are using multiple names, they cannot tell online bibliographies how to present their data if the two names are already connected. If we decide to do that, I will follow suit but I really do not like it. Just saying... Annie 18:24, 22 March 2017 (UTC)

It seems to me that everybody that gave an opinion think that WE (our select club of supreme bibliographers) should decide (so do I). Perhaps should the person that created the pseudonymistic link and rejected your changes express him/herself. IMHO the only situation where the author can have his/her say on the matter is when there are sex/gender changes (IIRC we've already had such cases). Hauck 18:52, 22 March 2017 (UTC)

I was the one who did the rejection, but I think (if I remember correctly) that I was only seeing the acceptance of the pseudonymous relationship now given as submitted by the author (if that was not the case, and I was in fact the acceptor, my apologies). The fact remains that the author himself did the organisation, and we should be indebted to the author's wishes, as this was what we set out to fulfil at some time. Stonecreek 20:14, 22 March 2017 (UTC)

So you think we should leave the works split between the two pages? That makes no sense in the context of how we organize data. I am sorry but I disagree with you here - we have a practice to put all works of the same person on the same page regardless of how they had been credited. If they need to be on split pages, then the pseudonym needs to be broken altogether, pages left as two separate entities (with no cross references at all in terms of variants and the like) and notes added on the reasons for this so they never get reconnected. Otherwise this whole thing will open a can of worms that will render the DB unmanageable. Annie 20:22, 22 March 2017 (UTC)

I don't know where you did get that idea from! I have varianted twenty or so items to the parent author, but will leave the others to variant to other editors. After all, it's a community effort. Stonecreek 20:33, 22 March 2017 (UTC)

No change in the accounts for a week after we initially talked about that kinda made me think that you are ok with the split pages. That's all. Sounds like we are on the same page regarding this. :) Annie 21:51, 22 March 2017 (UTC)

(unindent) All variants and the note for the account explaining why the pseudonyms are set that way are now submitted so that someone does not try to improve it later on. All it needs is a moderator to approve them all. Annie 18:40, 23 March 2017 (UTC)

Done. Hauck 20:08, 23 March 2017 (UTC)

Thanks! Annie 21:33, 23 March 2017 (UTC)

LibraryThing as an image source

I recently tried to replace a dead Author image with an updated version, and got a notice that LibraryThing is not on the approved link list. http://www.isfdb.org/wiki/index.php/ISFDB:Author_Images lists three authors with LT images, two of whom, Frank R. Stockton and Lord Alfred Tennyson also have non-functioning images. If LT is not approved, how were they linked in the first place?--Auric 09:39, 29 March 2017 (UTC)

I'm not sure that finding by who and/or why and/or if an eventual mistake was made is very useful. The reason is very likely that, at the beginning of times, there was less caution about what was included in the db. I've deleted the links. Hauck 10:42, 29 March 2017 (UTC)

Thanks for fixing that.--Auric 12:35, 29 March 2017 (UTC)

Nongenre works (Part I): editors

In accordance with this discussion, I've been adding a few issues of nongenre magazines when they contained the first publication of a genre story. Likewise, I've added nongenre anthologies. My question is, the same way that the magazine's editors are stated as "Editors of [Magazine Title]", is it the usual practice to list the anthology as by "Editors of [Anthology Title]"? The help page says "Any issues of any periodical containing works of speculative fiction can also be entered in the same way as a non-genre magazine. So can anthologies that have some SF content, but contain mostly general fiction." Does "in the same way" extend to the matter of editors? --Vasha 14:28, 4 April 2017 (UTC)

OK, since no one has an opinion, I am going to do it that way, with anthologies credited to "Editors of". --Vasha 15:30, 5 April 2017 (UTC)

Non-genre anthologies are credited to their actual editors. "Editors of" is only used for non-genre magazines. That seems reasonable to me as creating a single author record per anthology is overkill and many non-genre anthologies are by genre authors. -- JLaTondre (talk) 18:22, 5 April 2017 (UTC)

On the other hand, this would also prevent there from being author records for people with no genre work. Maybe only editor credit for "above-the-line" authors? Admittedly that would not be easy to implement.

As for the concern about having too many editors-of records, those are not intended to be used for anything anyway, and the nongenre anthology editors often only have one credit themselves. --Vasha 19:11, 5 April 2017 (UTC)

If an editor published a speculative fiction story once, they are more likely to do it again when they do a new anthology. So even if we will have a lot of individuals, we will see repetitions. Magazines are different because there are multiple editors or they change... Annie 19:18, 5 April 2017 (UTC)

I don't think that's a major concern... but I realize I may be the only person who feels this way! --Vasha 19:34, 5 April 2017 (UTC)

I think you're right, Vasha. If the anthology is edited by authors with at least one genre title, we should credit them by their name, but many don't show any tendency to publish in our area. If that's the case we shouldn't credit them by name. Stonecreek 19:37, 5 April 2017 (UTC)

That seems to create more complications. Take The Best American Short Stories as an example. Some editors are genre and some aren't, including within the joint editors of the same pub. Plus some editors are only in the database otherwise because of an essay (some not even really genre, like Martha Foley) and not a story. Crediting a pub as "Stephen King and Editor of Best American Short Stories" seems weird to me. Plus the complications if they do then publish a genre story having to know to go back and change the prior credits. Magazines make sense to me because of the volume of records. -- JLaTondre (talk) 19:48, 5 April 2017 (UTC)

I know it looks weird, but IMHO it's still preferable to amassing surplus entries by assumed genre editors; and there's really a vast bulk of non-genre anthologies out there that contain one or a few genre titles: they may even easily outnumber magazine titles, we just didn't have time to call them in.

Those special editors with effectively no genre titles then should be left out: it's a moderator's judgment in each case. Stonecreek 20:35, 5 April 2017 (UTC)

Full disclosure: I'd rather we recorded actual editors whenever we know them, even for non-genre magazines. So this thought is probably biased, but... I think a difference between anthologies and magazines is that someone doing research is more likely to look for an anthology by editor (vs. title), yet would be more likely to look for a magazine by title (vs. editor). So there may be some benefit to recording editors for non-genre anthologies, even if the editor is not "genre". --MartyD 01:05, 6 April 2017 (UTC)

Yes, but to many users it certainly looks weird that we don't list all titles by all featured authors (because some of them fall below the threshold): it's one of the idiosyncrasies of our little web site. But if the consensus is to list the editors for non-genre anthologies this should be made part of the guidelines of rules. Stonecreek 04:31, 6 April 2017 (UTC)

Another thought: couldn't anthologies (and especially series like The Best American Short Stories) illustrate our politics quite easily if we'd choose to credit the regular (non-genre) editors as 'Editors of'(for example Editors of The Best American Short Stories)? Stonecreek 14:57, 6 April 2017 (UTC)

Now that we have the notes for the authors actually showing on the page itself and not in the wiki, we can use the space to explain there why not all works are included for an author especially for the ones that are major authors but just not SF major ones... Annie 04:35, 6 April 2017 (UTC)

Nongenre works (Part II): Cover art

As I understand it, nongenre books are not supposed to have a cover artist specified because the database shouldn't contain records for nongenre art. But I know there are some. They should be found and removed. --Vasha 18:05, 5 April 2017 (UTC)

Only non-genre magazines are explicitly restricted from having cover art or cover artist credit. Not sure why it was limited to those, but a wider discussion should happen before implementing this. -- JLaTondre (talk) 18:24, 5 April 2017 (UTC)

OK, I don't understand that either. Isn't the idea that there shouldn't be art records for any art not associated with a genre work? If so, the help files should be updated. --Vasha 18:58, 5 April 2017 (UTC)

Which help files? The only help files that mention it (that I'm aware of) is the non-genre magazine one. -- JLaTondre (talk) 19:03, 5 April 2017 (UTC)

Right; one thing that's been bugging me for the last few days is that there isn't much said in the help about nongenre anthologies. It is left vague whether they should be treated exactly like nongenre magazines. Do we need a R&S discussion about this? --Vasha 19:26, 5 April 2017 (UTC)

That is just it, they aren't treated the same. If you want to change the status quo, yes, a R&S discussion should be had. -- JLaTondre (talk) 19:32, 5 April 2017 (UTC)

Cover art borrowed from previous artistic works

I don't know whether this topic has been discussed before : it might very well have, but in this case, this is just to request some enlightening. In the case of a book cover illustrated with the pre-existing work (or a detail thereof) of an artist, would it be possible (or could it be made possible) to variant all the concerned book covers to the original title of the work (+ date, if known), illustrated with the original painting ? I was particularly thinking of Hieronymus Bosch, whose paintings have been the source of so many cropped details that could all be easily varianted to the complete original. But I think that applying this system to all other cases might also be a useful way of clarifying sources. Any opinions about the matter ? Thanks, Linguist 10:06, 24 April 2017 (UTC).

I'm against this move, lest we start the slippery slope to being a kind of gallery of art, listing not only a bunch of paintings by Bosch or Magritte, but logically facing the obligation of extending this to all paintings of Foss, Hardy or Siudmak (this will nearly double the number of such records). Our "art" cannot be separated from the book it illustrates and doesn't "exist" outside of it. Hauck 10:36, 24 April 2017 (UTC)

Well, it would be only logical to induct such attempts: in fact, it has been done in some cases where re-used covers only display half (or a detail) of the original work. It may be looked upon as a sad fact, but at least with allowing interior art (if not already by allowing cover art) we also have become a kind of art gallery, and I feel we should handle it carefully and in a responsible way. This would mean that we should variant art details to their respective parent. Stonecreek 18:47, 24 April 2017 (UTC)

Where would we put the parent? We aren't actually an art bibliography, so I would be opposed to having a separate record just for The Garden of Earthly Delights. (Or we would risk the precedent to just start including every piece of art by a fantasy artist.) So do we try to find the book that has the "largest" chunk of that painting and variant to it? Or do we variant to the oldest book that used that? Almost any solution would seem to run the risk of having cover A be a variant of cover B, when those two books have NO actual overlap in the portion of art they're using! IMHO, the inherent conflicts that would arise speak against attempting to do this. Chavey 05:42, 25 April 2017 (UTC)

In the case of Bosch I think there's no reason to not include art books on or by him, so there is no reason to avoid a variant to The Garden of Earthly Delights, because this work will eventually pop up anyway. I think there's also no reason to avoid varianting full reproductions of other art.

As I understand it there wouldn't or shouldn't be varianting to covers but to the original art title. (As we list the occurences of art pieces, I'm afraid that it seems we actually have become an art bibliography (it was a can of worms when opened, we just didn't realize it, I think), and I don't see an actual reason to avoid applying our quality standards. Stonecreek 07:41, 25 April 2017 (UTC)

IMHO it's not a problem of quality standards (even if they would be better enforced if the cleanup reports were exploited by all non-self moderators), just of logic. We're a database of books (in a general sense, of course) not a database of paintings. In the case of "extracts" of a larger painting, if there is no book in the db that is adorned with the "full" painting, there is just nothing to variant to, except if we start creating publess records for such an usage which is not a good idea. Hauck 08:08, 25 April 2017 (UTC)

As said above: caused by the works of several editors we have become a database for art as well, at least that's the way users will perceive us, if we give so much emphasis on art: listing artist's biographical data, detailing the reproductions of art works etc. Stonecreek 09:07, 25 April 2017 (UTC)

(after edit conflict)

Just to make things clear :

1. I was mainly thinking of works that were not meant to be spec-fic illustrations, but were used that way — which limits the scope a bit.
2. In my mind, I was just considering this as an option, not something systematic, that could be occasionally chosen when particularly useful.
3. I don't see why, in the case of works that were neither book covers or inside art in the first place, we couldn't have the original piece as the parent, possibly with some indication like "(original artwork)" to make it clear it wasn't included in any publication in the beginning. I must say I don't understand the reason of Chavey's list of questions and remarks : we are already doing all that when dealing with such cases, and this is precisely to avoid these problems that I was considering the possibility of entering original works. What we are actually doing at the moment is "inventing" a parent which does not exist, because there is no original book cover in these cases.
4. It is agreed that we are a bibliographical database, but doesn't this mean we ought to be as thorough as possible as far as the origin of the illustrations is concerned ? And having the possibility to view at a glance the original and all the derived book covers seems to me to go that way.

But this being said, it was just an idea that had crossed my mind… Linguist 09:36, 25 April 2017 (UTC).

Right on to the point, I'd say. As much of our work it will have to be grounded in the will of editors to pursue such a task for their chosen works, so a systematic approach seems not to be achievable. But still we should try, I think. Stonecreek 17:29, 25 April 2017 (UTC)

Precedence of ISBN vs. SBN

I found a copy of The Early Asimov: Book Two. At present the pub record uses catalog # P2323. Prior verifiers, both retired from ISFDB, either missed or did not document that the publication also has an SBN on the spine. There's no ISBN/SBN on the copyright page. I've added a pub note about the SBN. It brought up an issue that's not covered on Template:PublicationFields:ISBN. Is there a consensus what to enter the catalog # field when a publication has both a catalog # and an SBN? Do we enter the catalog #, SBN, or translate the SBN to an ISBN and use that? I've been in the habit of translating the SBN to an ISBN and using that in the Catalog # (along with a pub note). That time though the pub record is already there and PVed which made me wonder if others believe the catalog # gets entered. --Marc Kupper|talk 08:33, 13 May 2017 (UTC)

As per Help:

• If a publication has more than one number, then enter the one that seems most reasonable in the ISBN field but then also add a comment to the notes field about the various numbers and where they are located in the publication. For example, a book may have both an ISBN and a catalog number. In this case the ISBN would go in the ISBN field and you would make a note, for example, that the ISBN is on the spine and catalog number is on the front cover.

Please note that, as per Roadmap 2017, the ISBN field will be revamped in the near future:

• ISBNs (mostly to support internationalization, but will also help in other cases):
  • Move catalog IDs to a separate field, which will help with pubs that have both an ISBN and a catalog ID, e.g. book club publications.
  • Support multiple ISBNs per publication
  • Add two checkboxes next to each ISBN: “derived” and “corrected”. The latter will let us capture two versions of invalid ISBNs, the stated one and the corrected one.

Ahasuerus 13:28, 13 May 2017 (UTC)

Thank you. I suspect I'd read that help before which is why I put ISBNs before catalog #s. In this case it's an SBN and catalog # which is not addressed in the help. Once that roadmap 2017 item is done then we'll be able to have all three values (Catalog #, SBN, and derived ISBN) meaning searches for any of them will work. For now I'll stick with the catalog # for that publication record on the theory that two previous verifiers saw it but did not seem to notice the SBN. Someone else with a copy of the publication will likely also look for the catalog #. I've already added a pub note about that it has a catalog #, SBN, and provided the derived ISBN. BTW, in my book list, which is a spreadsheet, I support entering "SBN 449-02323-125" in the ISBN field. There's logic that looks for the SBN prefix and then derives the ISBN from a variety of SBN formats. --Marc Kupper|talk 08:58, 14 May 2017 (UTC)

Titling conventions for magazine titles grouped by year

I have a question about naming conventions for series grouped by year. I know the grouped name changes if the editor(s) change, as can readily be seen by the Astounding/Analog series, but what about the EDITOR record title changes? For example, all of the titles in the EDITOR record for "Astounding Stories of Super-Science - 1930" match the grouping title. But then, in "Astounding Stories - 1931" the first title in the EDITOR records doesn't match (it retains the title of the previous year) but all the others match. Should it not be in this grouping because of the title change, or is it ok to have differing titles in the EDITOR record? The same thing happens again in 1938. In 1960 the same thing happens for the change from "Astounding Science Fiction" to "Astounding Science Fact -> Fiction", but then, also 1960, it changes to "Analog Science Fact -> Fiction" and it gets a new grouping. Is that because it's a radical title change? So if it's okay to have different titles for minor changes in the EDITOR record for a group, how is the name chosen? By which title has the most entries? Thanks for any input on this. Doug / Vornoff 20:20, 8 June 2017 (UTC)

It's usually decided on the spot. IIRC the grouping is not mandatory (it's just a way to avoid too much cluttering of the pages) so there are as many ways to proceed (in such complicated cases like Astounding/Analog) as there are editors and moderators. I personally find that Astounding/Analog's page was split too much (e.g. at the 1960 juncture) and so nearly unreadable for someone not aware of the specificities of the magazines and its title changes. If pressed, I would say that the EDITOR record at publication level should be the more precise and I'm ready to accept this kind of grouping. Hauck 06:14, 9 June 2017 (UTC)

I agree. I think the only situation where a split is "mandatory" is if the actual editorship credit changes mid-year/volume. Having the grouped name be sort of canonical, with variations in wording of the individual EDITOR records, seems acceptable. I do think a major name change, such as "Astounding" -> "Analog" can be worth splitting into two groups to make it easier to see when the change occurred. --MartyD 12:07, 10 June 2017 (UTC)

Definition of "juvenile"

It seems like we are using juvenile for both children's books and for young adult ones - effectively making it mean "not adult". Is that the desired effect? And if so, maybe we should change the name of it so it does not sound as if we call those books not serious or even too childish to be of any considerations(as much as I am fond of the word juvenile, it is not exactly used anymore in the context it was in Heinlein's days for example). So what is the intent behind the category? Annie 23:05, 9 June 2017 (UTC)

I'm not sure about it. Nowadays many of them are also denominated 'all-age' literature, which contradicts to some degree 'juvenile'. Stonecreek 04:13, 10 June 2017 (UTC)

I've never used the "juvenile" label for the reasons given by Annie (it's IMHO quite meaningless), it's another can of worms that I don't want to open (tens of posts to arrive at the statu-quo ante). In fact, I find nearly all labels either useless (if it's "non-genre" it should not be in the db, if it's "graphic" it should not be in the db) or so arguable (What does "juvenile" mean? What constitues a "novelization"?) that we may be better without them. Hauck 06:32, 10 June 2017 (UTC)

Yeah, even Heinlein's original juveniles are read by and published as for adults; so, they aren't exactly juvenile anymore. Stonecreek 09:10, 10 June 2017 (UTC)

I would be happy to see it go, but I don't use it, so that's easy for me to say. It would be helpful to hear the thoughts of someone who does use it and finds it valuable. --MartyD 12:09, 10 June 2017 (UTC)

Actually, I do. For one thing, novellas and picture books both are in the database as "CHAPBOOK containing SHORTFICTION" and I do like having a way to tell them apart. As you probably know, I've made it my project this year to try to get correct information into the database about short fiction published in 2017; it'll come in handy next year when people are making up their awards lists, for one thing. It is harder to get info about children's books, which often don't have Amazon previews. The same goes for juvenile ANTHOLOGYs and COLLECTIONs as CHAPBOOKs. I decided not to concern myself with children's literature; people who want info about that probably have other sources, and if they are using this DB, well, I'm not the one helping them. So it is very useful to me to mark things as juvenile.

I find that cataloguing young adult books doesn't suffer from the same difficulties as children's. I think my dividing line for what is juvenile or not would be the stage at which they stop having special formats: middle grade books often are a different size, more often illustrated, may have larger type, etc. Whereas young adult books generally resemble adult books.

Just my two cents... --Vasha 17:52, 10 June 2017 (UTC)

That is not how juvenile is usually defined. Juvenile is typically defined as marketed for those under 18. These days, children's literature is a more widely used term that has replaced juvenile (as well as a tendency to divide such a broad category into more age targeted marketing terms, like young adult). I don't care if we keep the flag or not, but let's not create a site specific definition as that will just cause more confusion. -- JLaTondre (talk) 18:25, 10 June 2017 (UTC)

And in my non-English native ear (or it may be a combination of language and culture references), juvenile sounds like sub-standard. Annie 19:27, 10 June 2017 (UTC)

"Juvenile" can be used to mean "immature", "childish", etc, but that's not how it's used in publishing. Ahasuerus 19:37, 10 June 2017 (UTC)

Yeah, I know :) Did my digging when I encountered it here. Retraining my mind will take longer Annie 19:56, 10 June 2017 (UTC)

Which is what made me ask... Maybe we need a YA flag (for what Vasha is trying to do)... and a different one for pure children ones. Although I would not be too broken up to lose the flag altogether. I used it when adding some pure children books a few months ago - and it kinda made sense but had been thinking on it since. Annie 19:27, 10 June 2017 (UTC)

Sorry, but no, this is a slippery slope with potential multiple age categories to be defined and all the fun coming from debating to decide if a specific text is YA or juvenile or adult (who say Heinlein?). That's why I'm against all those unclear categories (or those nebulous definitions) that we're forced, because of history, to pull along. We're not marketers, we're just bibliographers (IIRC Dewey doesn't, for fiction, makes a difference between adult, young-adult, not-so adult, nearly-adult, not-at-all adult or really-not-adult texts). Hauck 19:46, 10 June 2017 (UTC)

I do not disagree with you - especially with publishers marketing books any way that will get them more sales... I was merely thinking aloud Annie 19:56, 10 June 2017 (UTC)

(unindent) I can think of a few reasons to keep the "Juvenile" flag:

• It facilitates searching the database, which is very helpful when performing tasks similar to what Vasha has been working on.
• It matches the data that other catalogs provide under "Material Type", e.g. see this OCLC record.

Anyone know where OCLC policy for defining this is? If there is one. We couldn't rely on them entirely, but at least using their classifications for new materials might speed things up. Vasha 20:17, 10 June 2017 (UTC) --Vasha 20:17, 10 June 2017 (UTC)

• Deleting it would discourage the editors who have turned this flag on for approximately 21,000 of our titles.

That said, these days I find that tagging is a better match for what we are doing here. For this reason I usually do both: flip the "Juvenile" flag and assign a tag like "juvenile sf", "juvenile fantasy", "young-adult horror", etc. Ahasuerus 19:48, 10 June 2017 (UTC)

So maybe we need a better definition of the flag so it gets a bit more consistently applies instead of every editor coming up with their own rules? And I need to remember to tag... Annie 19:56, 10 June 2017 (UTC)

The problem with using the tag instead of the flag is if you search for "tag does not contain juvenile", it only gives you other tagged records, not untagged ones. Vasha 19:58, 10 June 2017 (UTC)

In addition to, not as a replacement :) If we keep the flag, we just need consistent usage (and help update for that) Annie 20:03, 10 June 2017 (UTC)

I certainly can't disagree that the term should be defined, and I'll go along with any definition. --Vasha 20:09, 10 June 2017 (UTC)

The real fun will start here (although without me). Hauck 20:11, 10 June 2017 (UTC)

Also, if you flag a chapbook, please flag the contents too, and vice versa. Vasha 19:58, 10 June 2017 (UTC)

(unindent) The Library of Congress generally has MARC codes that they view as specifying the level of the target audience. That becomes a natural way to define what "juvenile" means: If the Library of Congress says it's juvenile, then we say it's juvenile. The MARC codes of interest to us are: "a" pre-school; "b" primary (K-3); "c" elementary and junior high (grades 4 - 8); "j" juvenile (through age 15 or grade 9); "d" secondary (grades 9 - 12). IMHO, "a" shouldn't be included here; "b" might be included, or might be rejected; "c" and "j" would be juvenile (to us); "d" might be "YA" to us. To find the MARC codes, go to the LCCN record, at the very top are two tabs: "Full Record" and "MARC Tags". Look at the tags for the "008" line. For example, with A Coalition of Lions, this line is:

008   020930s2003 nyu j 000 1 eng

The only thing important to us here is the "j" in the middle. That says we should tag that book as "juvenile". With A New Alice in the Old Wonderland that line gives us:

008   140520s2009 ie a j b 000 1 eng

That tells us that it's juvenile, and furthermore the "a" and "b" surrounding the "j" tells us that its target audience is pre-school to grade 3. This would qualify as "Children's", although for now we have no formal way to indicate anything about this other than that it's "juvenile", which we should have tagged (we don't). The advantage of this approach is that we are relying on Library of Congress judgement, and avoiding getting into our own definitions or debates. The disadvantage is that if there isn't an LCCN record, or if that record is old enough to not have MARC codes, then we still need to decide ourselves. But at least we have the Library of Congress definition of target audience. Chavey 23:06, 10 June 2017 (UTC)

That sounds really good to me! And if their dividing line for j is approximately age 15, that helps convert to other systems of classification. --Vasha 23:44, 10 June 2017 (UTC)

A couple of things about the MARC21 standard or, technically, family of standards. Although the Library of Congress is one of its maintainers, it's an international standard and used in a number of countries. The "target audience" codes that Darrah mentioned earlier are as follows:

• # - Unknown or not specified
• a - Preschool: "Intended for children, approximate ages 0-5 years"
• b - Primary: "Intended for children, approximate ages 6-8 years"
• c - Pre-adolescent: "Intended for young people, approximate ages 9-13"
• d - Adolescent: "Intended for young people, approximate ages 14-17"
• e - Adult
• f - Specialized
• g - General
• j - Juvenile: "Intended for use by children and young people, approximate ages 0-15. The code is used when a more specific code for the juvenile target audience is not desired."
• | - No attempt to code

In theory, a, b, c, d and j match the "juvenile" flag in our system. In practice, however, things can be rather messy. Back when I was coding the MARC21 module of Fixer, I examined hundreds of MARC records from different publicly available data sets. I found that the use of this field was inconsistent. Some catalog records had very good data while certain other ones didn't. When set, this field can be useful, but I wouldn't treat it as gospel. Ahasuerus 00:43, 11 June 2017 (UTC)

I think the MARC codes provide us with a good definition, but as you say, the implementation can be weak. In cases where there are several LCCN records (generally, when the title has had multiple US publishers), there are multiple records to consider for this classification, which would generally lead to a more reliable decision. There was an effort on the part of OCLC to try to make a major analysis of the target audience level where they combined evidence from the MARC records together with the libraries that held that book: E.g., if elementary school libraries held the book, it was likely targeted at a children's audience (or at least a juvenile audience). Their report on this effort is available here. But unfortunately, I didn't find any concluding data from this effort. They discussed having a service where you could enter the OCLC number and have it report the target audience based on this criteria, but I don't see that they did this. Chavey 01:17, 11 June 2017 (UTC)

Using spelled-out initials to disambiguate abbreviated author names

In the case of S. Dorman (Sonya Dorman) and S. Dorman (I) (Susan C. Dorman), where the ambiguity is due to use of initials, what do we think about using spelled-out initial(s) as disambiguator? E.g., "S. Dorman (Sonya)" and "S. Dorman (Susan)"? --MartyD 12:07, 17 June 2017 (UTC)

It will be clearer than the current (I) way. So I like the idea :) Annie 17:12, 17 June 2017 (UTC)

I think that's an excellent idea. Chavey 04:13, 18 June 2017 (UTC)

The Capitalization Post!

Help:Screen:EditPub contains guidance on standardizing the capitalization of titles. The current guidelines are a good attempt at providing simple information for editors, not all of whom are native English speakers. But they could be better. The biggest problem is the attempt to avoid having rules for capitalization by simply listing words that should not be capitalized. This list is too short. The results it produces don't correspond to any standard style. Also, it neglects certain exceptions that are found in all standard styles.

The basic principles of all standard English capitalization styles are that articles, coordinating conjunctions, and prepositions are exceptions to capitalization. There are three competing approaches to how to treat prepositions: Capitalize all those of four letters or more; all those of five letters or more; or none at all. There is a comprehensive list of prepositions on Wikipedia; people who want a definition of what they are can consult A Student's Introduction to English Grammar -- warning: like all grammatical questions, it isn't simple.

At this point I am going to quote MartyD: "One suggestion: Try to find an authoritative, semi-public standard for us to follow. Having our own only makes it certain that no one will know what to do without 'training'." I wholeheartedly agree with Marty. For this reason, I've been making a survey of various editorial style guides: For the US, the APA, MLA, and Chicago styles; for the UK, the University of Oxford Style Guide. By far, the most comprehensive, clear, and detailed one is the Chicago Manual of Style; it also contains copious illustrative examples. Choosing it as an external standard for this database would be natural, if not for the problem that its latest edition is available only in libraries: in hardcopy or online by subscription. However, I did copy out relevant passages; I hope my excerpts may be brief enough to pass for fair use. I also copied corresponding passages from the MLA handbook, which is the second-most-detailed guide. You will see that the two guides largely agree.

[These excerpts also contain considerable guidance on punctuation and such matters, which I think it would likewise be good to submit to an external guide; but let's stick to capitalization in the current discussion.]

Here follows a comparison of the current ISFDB guidance with summarized Chicago and MLA suggestions; with problems and options.

A. From Help:Screen:EditPub. Regularized case means that the first word is capitalized, and all later words are also capitalized except for "and", "or", "the", "a", "an", "for", "of", "in", "on", "by", "at", "from", "with", and "to".

Chicago: First and last words should be capitalized; all other words should be capitalized except for:

• articles (a, an, the);
• certain conjunctions (and, but, for, or, and nor);
• all prepositions (see Wikipedia list) except when they are not used as a preposition but rather as part of a verb (Turn Up, Help Out), as an adjective (The On Button), or as a subordinating conjunction ("Equal before the Law" BUT "We'll Hide Before He Returns");
• to when it is part of an infinitive; as in any grammatical function.
  

MLA: First and last words should be capitalized; all other words should be capitalized except for:

• articles (as above);
• certain conjunctions (and, but, for, or, nor, so, yet);
• all prepositions except when they are not used as a preposition but rather as part of a verb, an adjective, or a subordinating conjunction (see above);
• to when it is part of an infinitive
  

PROBLEM: Both Chicago and MLA expect people to be able to distinguish the grammatical function of the words on the list of prepositions and capitalize them or not accordingly. Even for me, a highly literate native English speaker, this is occasionally frustrating. For some users, it will be completely baffling. I see three possible solutions (anyone have others?)

1. NEVER capitalize the words on the preposition list unless they are the last word. However, this would depart from standard practice.

2. Adopt the style guide policy and have a capitalization help desk for people to ask about titles they aren't sure what to do with (I, for one, would volunteer to monitor it)

3. Adopt the style guide policy and don't worry about standardization. If people get it wrong, so be it.

B. From Help:Screen:EditPub. Hyphenated words have the first letter after the hyphen capitalized.

Chicago: Capitalize the first letter after the hyphen except if it is a word that would be lowercase anyway (article, conjunction, preposition), or if the word before the hyphen is a prefix that isn't a word on its own (Re-entry, Anti-establishment).

MLA: Capitalize the first letter after the hyphen except if is a word that would be lowercase anyway. [MLA does not mention anything about hyphenated prefixes.]

Have I gone on long enough yet? :-) --Vasha 19:45, 26 June 2017 (EDT)

ADDENDUM: A couple of more-extreme solutions to the capitalization problen:

1. Capitalize every single word. This is legible enough, but amateurish-looking.

2. Follow the style of Worldcat and most academic bibliographies: Sentence-case.

--Vasha 20:40, 26 June 2017 (EDT)

Re: "except when they are not used as a preposition but rather as part of a verb (Turn Up, Help Out)", I think our current de facto standard is to capitalize postpositions, i.e. prepositions which appear after the verbs that they are related to. Ahasuerus 23:09, 26 June 2017 (EDT)

Actually, those are what Chicago/MLA call "prepositions used adverbially," or some people call verb particles. Postpositions, on the other hand, are simply prepositions that occur after their noun: two years ago, two miles away. Be that as it may, both the verb-following ones and the postpositions are standardly capitalized. And editors who've internalized standard practices have been doing it even though the Help doesn't say to. --Vasha 05:39, 27 June 2017 (EDT)

It sounds like all we have to do in this particular case is change Help from:

• except for "and", "or", "the", "a", "an", "for", "of", "in", "on", "by", "at", "from", "with", and "to".

to something like:

except for "and", "or", "the", "a" and "an". "For", "of", "in", "on", "by", "at", "from", "with", and "to" should not be capitalized unless they follow the verb that they modify, e.g. "Get Up".

Ahasuerus 11:44, 27 June 2017 (EDT)

The easiest way to tell if the preposition is by itself as part of one of these verbs, and not part of a preposition phrase, is to see if it can be moved to the end: "Bring in the newspaper" Yes: "Bring the newspaper in". "Swim in the pool" No: "*Swim the pool in." (asterisk being a linguist's way of marking a wrong sentence). I think it would actually be easier to specify that prepositions be capitalized everywhere EXCEPT if they form a phrase with a following noun. The cases where they ARE capitalized are so numerous: "The On Button", inverted constructions ("Where Did We Come From?") and so on and so on. So, only phrases (which are usually used to indicate things like relationships of location, time, agent, etc.): "sit on the chair," "a calm after a storm," "written by me," "a gift for him," etc. The only exceptions then are to in infinitives ("The Way to Go") and (maybe) as in comparisons ("As Hot as You Like", if we decide to use that rule).

The current list is too short, though. At the very least it should include the commonest prepositions, which is the current list plus as; wouldn't it be better to simply not capitalize all prepositions of four letters or less (a very common practice) or all prepositions whatsoever (the practice recommended by Chicago and MLA)? --Vasha 12:54, 27 June 2017 (EDT)

Not so easy to see if you can move the preposition somewhere if English is not your native language though (especially if in your language prepositions work a bit differently). We need a rule that does not require a degree in English to be understood. It is great to follow a standard guide and all that but if the rule becomes too complicated, we will end up with people ignoring it and moderators needing to correct a lot of entries. :) Annie 13:10, 27 June 2017 (EDT)

If your proposal is to "simply not capitalize all prepositions of four letters or less", I am not sure why you posted all the long winded explanation above :) So what IS the proposal - follow the manuals or go for anything under 4 letters? Annie 13:10, 27 June 2017 (EDT)

I agree with you Annie, standard English capitalization rules are not very good because they DO require strong knowledge of English to follow correctly. That's what I said in the section marked PROBLEM above, and that's why (not very seriously) I proposed the two extreme alternatives in the addendum.

The rule would be "Do not capitalize any preposition of four letters or less ONLY WHEN it forms a phrase with a noun or pronoun following it; do not capitalize to when it is used in an infinitive." That is short to say, but not necessarily easy to put into practice. In the examples I gave above, would it have been clear to you that the phrase structure was "[bring in] the newspaper" and "swim [in the pool]", so that only the second one would have in not capitalized? --Vasha 13:31, 27 June 2017 (EDT)

English grammar used to be a hobby of mine for awhile so recognizing a phrasal verb is not a problem. And I've done some writing under the Chicago rules - overeager teacher and all that. So I can follow just fine :) However, trying to explain the intricacies of the phrasal verbs to someone without a firm grasp of the grammar is a tiny bit hard (the good old example of "go on" vs "go to") :)

I know we need an update of the current rule but having a definitive list makes it easy to understand and less prone to each editor having their own interpretation. I just wish that English was like Bulgarian or Russian in that regard (sentence case in the titles in both):) Annie 14:17, 27 June 2017 (EDT)

The list of 2/3/4-letter prepositions, omitting some particularly rare ones, is: amid, as, at, but, by, ca. (abbreviation of circa), down, for, fore (or 'fore), from, in, into, less, like, mid (or 'mid), near, of, off, on, onto, out, over, past, per, post, re, save, than, 'til, till, to, up, upon, via, vs., with. That's 36. I bet I can find an example in the database using almost any one of them. --Vasha 14:39, 27 June 2017 (EDT)

Probably you can. And 36 is fine I think :) It is a definitive list. Add "a", "an", "the", "or", "nor" and "and" and we have a list. Although "save", "past" and "post" are used more often in their non-preposition roles and having them on the list is going to confuse people. I would leave those to get capitalized in all cases if I was making the rule. Annie 14:56, 27 June 2017 (EDT)

Well, past is a very common preposition and should be included. It is not hard to distinguish between save used as a preposition (All Is Lost save Honor) and as a verb. But I would omit fore/'fore, less, mid/'mid, pre, and post as rare and confusing. Leaving us with 31. And it really would help to divide the list into sections: articles, conjunctions (and, but, for, or, nor) and prepositions. --Vasha 15:08, 27 June 2017 (EDT)

I do not have issues with splitting into categories but you added "but" in your initial list of 36 so sounded like you do not want to split them. :) Agree on "less" - not sure why I did not add to the 3 above. But I still disagree on "past" and "save". They can be normal prepositions but their other grammatical roles are a lot more prevalent adn quite honestly, leaving them capitalized won't hurt anything (and will eliminate the confusion). We are looking for a rule that is easy to explain, right? Annie 15:22, 27 June 2017 (EDT)

But is a preposition as well as a conjunction -- "I worship no god but Yog-Sothoth!" I agree that save could easily be omitted; but I don't see what is controversial about "The unicorn ran past the hunters." How could that be confused with "Unicorns were more common in the past"? —The preceding unsigned comment was added by Vasha (talk • contribs) .

(unindent) Here's proposed language for the help, if we decide not to go with an external source:

Regularized case means that the first word is capitalized, and all later words are capitalized except for the following: articles (a, an, the); coordinating conjunctions (and, but, for, nor, or); the to of infinitives; prepositions of four letters or less IF they form a prepositional phrase with a following noun or pronoun (amid, as, at, but, by, ca., down, for, from, in, into, like, near, of, off, on, onto, out, over, past, re, than, 'til, till, to, up, upon, via, vs., with) prepositions of two or three letters (as, at, but, by, ca., for, in, of, off, on, out, re, 'til, to, up, via, vs.) plus from and with IF they form a prepositional phrase with a following noun or pronoun [Amended 06-28]. The same rules apply to the word that follows a hyphen.

I just don't see how to be simpler than that and still be correct and complete. --Vasha 15:46, 27 June 2017 (EDT)

I guess I would like an up-or-down vote on changing to sentence case. It would be unusual, and surprising to visitors, but SO much easier to do. --Vasha 17:41, 27 June 2017 (EDT)

"Ca.", "re", "via" (when used as a preposition) and "vs." seem like natural additions to the list. The rest feel kind of awkward. Ahasuerus 18:06, 27 June 2017 (EDT)

I don't know about you, but I think it is far easier to remember "all preposit'ons of four letters or less" than a specific list of 15 or 19 allowed prepositions. I would tear my hair out if I had to be always checking "is 'into' on the allowed list?" or having a moderator say "I can't approve that submission because 'into' isn't on the allowed list." --Vasha 18:20, 27 June 2017 (EDT)

Hm... Come to think of it, if we were to add the four words that I listed above, then our exclusion list would be effectively "all prepositions of three letters or less plus 'from' and 'with'", right? That should be fairly easy to memorize. Ahasuerus 18:30, 27 June 2017 (EDT)

Yes it would be, and semi-justifiable since "from" and "with" are vastly more common than other four-letter prepositions. Any sort of rule is better than memorizing a list. --Vasha 18:39, 27 June 2017 (EDT)

I like the "all prepositions of three letters or less plus 'from' and 'with'". I think we should still list them just so people do not need to check what a preposition is at 2 am in the morning but for memorization, this will work beautifully. Annie 19:03, 27 June 2017 (EDT)

Are we agreed then, to adopt the above amended description of English capitalization in the Help? --Vasha 20:03, 28 June 2017 (EDT)

Such a big change will require a lot more editors to at least chime in. And not everyone is around every day or has the time or the will to read the long explanations. Annie 22:03, 28 June 2017 (EDT)

True. Let's wait until after the weekend. Is there anyone in particular who should be pinged to ask for an opinion?

Also, I thought of another addition. We should probably add "the as of comparisons" so as not to produce titles like "An Ogre As Big as a Mountain" -- that would look better with both as's lowercase. --Vasha 22:18, 28 June 2017 (EDT)

I'd say take the weekend to get the proposal cleaned up with all the changed. Because it is English, we are looking at about 1.6 mln records influenced between titles and publications. Then post it - short and to the point and give it a week or two for people to comment. Dunno. It is the curse of the language that everyone edits in. Up to you - I am just posting an opinion. Annie 23:07, 28 June 2017 (EDT)

We should keep the rule simple. I don't care that much what we capitalize or not, but it should be a simple consistent list. It should not be a complex thing that makes it difficult on causal users (and users for who English is not a first language). Also, maybe I missed it, but I don't see anything above about how punctuation effects case. Our current help doesn't address that either, but it should (i.e. "Title: A Subtitle" should remain as such). -- JLaTondre (talk) 08:56, 2 July 2017 (EDT)

I wish with all my heart that the rule could be kept simple... but unfortunately English "title case" is not simple (it was devised by printers who didn't care whether mere laypeople could use it), and it absolutely cannot be described in a single line... unless that line is "Words belonging to certain parts of speech are lowercase at times, depending on where they fit into the structure of the title." It's a case of "Brief, precise, or correct-- pick two, because you can't have all three." My proposal 1A below is my very best attempt at being precise while also fairly brief and nearly completely correct. --Vasha 10:55, 2 July 2017 (EDT)

There is no such thing as 'correct' title case. There are multiple, conflicting standards. -- JLaTondre (talk) 11:47, 2 July 2017 (EDT)

Absolutely... and NONE of them can be summarized in one line. The suggested new language follows the standard from the Chicago Manual of Style because the CMoS is widely used and well-explained (in several pages). --Vasha 11:54, 2 July 2017 (EDT)

Our current one can be. Adding complexity for the sake of compliance to something that is not truly a standard is pointless. -- JLaTondre (talk) 12:01, 2 July 2017 (EDT)

Now *There* is a sentence I can completely agree with! ^^^ Chavey 02:49, 3 July 2017 (EDT)

SUMMARIZED PROPOSAL

As we know (to the frustration of many of us) the rules of standard "title case" capitalization in English are quite complicated. And as many of us have noticed, although the paragraph in Help:Screen:EditPub dealing with "regularized case" is a brave attempt at describing the principles of title case in a short and simple manner, its advice isn't actually sufficient to produce correct results. It states:

Regularized case means that the first word is capitalized, and all later words are also capitalized except for "and", "or", "the", "a", "an", "for", "of", "in", "on", "by", "at", "from", "with", and "to". Hyphenated words have the first letter after the hyphen capitalized.

Currently, users achieve nearly-correct results by filling in the gaps in these instructions from their own knowledge and ignoring them when they conflict with their knowledge of standard practices. Therefore, there'a a lot of variation in the database. Consider the following existing titles: Where to, Please?; Letter (Planet Stories, Fall 1940): They Always Seem to, Don't They?; Who You Talking To, Zone?; I Just Have To, Baby. The first two accord with the instructions given by Help; the last two are actually standardly correct.

Therefore, I'd like to propose modifying Help. There are two main options for doing so, I believe:

1A. Describe title case capitalization more completely. This has been the subject of the discussion above; the result was wording which essentially compresses the stylistic recommendations of The Chicago Manual of Style into a single paragraph, with the important difference that instead of leaving all prepositions in lowercase as per the CMoS, it mandates that only a subset of them should be lowercase (nearly the same subset as those specified by the existing wording):

Regularized case means that the first word is capitalized, and all later words are capitalized except for the following: articles (a, an, the); coordinating conjunctions (and, but, for, nor, or); the to of infinitives; the as of comparisons; prepositions of two or three letters (as, at, but, by, ca., for, in, of, off, on, out, re, 'til, to, up, via, vs.) plus from and with ONLY IF they form a prepositional phrase with a following noun or pronoun. The same rules apply to the word that follows a hyphen.

1B. On the help page, simply say that titles should be in title case, and link to a page that explains title case in detail, with examples.

2. Switch to using sentence case capitalization for titles. This is what Worldcat and most academic bibliographies do (and what nearly all languages other than English do). It would be a radical change, and initially surprising to casual users of the site; but it would be an easier standard of regularization for editors to use.

What are your thoughts on which proposal, if either, to adopt? --Vasha 22:48, 1 July 2017 (EDT)

Neither. Remain with the status quo. -- JLaTondre (talk) 11:47, 2 July 2017 (EDT)

I see no advantage to any of these three proposals over the current rule. I vote for the status quo. Chavey 02:52, 3 July 2017 (EDT)

I suspect that one of the issues here is the scope of the proposal. It covers a number of different areas and would necessitate reviewing and potentially changing hundreds of thousands of records. It's a daunting proposition.

I think it may be safer and easier to handle things piecemeal. For example, the proposal would add "ca.", "vs." and "via" to the list of prepositions that should not be capitalized. Checking the database, I see that we have 327 titles with " ca. " and only one title with " Ca. ". Similarly, we have 461 titles which use " vs. ", 48 titles which use " Vs. " and 1 title which uses " VS. ". If we were to change the data entry standard not to capitalize them, it would be in line with the current usage and require minimal changes to the existing data. On the other hand, " Via " and " via " are more evenly divided: 59 vs. 41 with some of the former having a different meaning as in "La casa in Via del Cimitero". Ahasuerus 11:56, 3 July 2017 (EDT)

Actually, I think that the fact that title case does NOT have those words lowercase in all circumstances is a bigger problem than exactly which words are on the list (as needs to be added too BTW). The list-based approach only gives a very weak approximation of title case. The reason that the data currently looks as good as it does is that people who know the full rules have been going beyond the list-based approach when they work. --Vasha 12:36, 3 July 2017 (EDT)

For reference purposes, we currently have 2,118 titles with " as " and 553 titles with " as ". Ahasuerus 13:31, 3 July 2017 (EDT)

The advice from one web site on choosing case was: "So, should you use sentence case or title case? If your school, college, or business has a house style guide, that decision has been made for you. If not, simply pick one or the other (flip a coin if you have to), and then try to be consistent.". That would mean sticking with title case. Given the number of forms for title case, I see nothing wrong with being more explicit in the Help. What I wonder is: if we achieve "nearly-correct results", how big is the problem really? If the rules are clear (albeit nearly impossible to follow if they depend on precise parsing of the title) then let people get it nearly correct (as they do pretty much everything they enter) and allow a few 'experts' clean up periodically. Doug H 14:41, 3 July 2017 (EDT)

You would get somewhat closer to right (though still not covering all cases) if you said that the words on the list are only capitalized when they are the first or last word or before a punctuation mark.

I diffidently suggest a variation on Doug's proposal: What about saying, "Titles should be in title case. Approximately speaking, this means that all words in the title should be capitalized, except that the words on the following list should only be capitalized when they occur first, last, or before a punctuation mark. For a fuller description of title case, see [page]." And allow people to use either the approximate or the expert version. In case of disagreement, the expert version takes precedence. Not good to have two conflicting standards, but I think this could be worded to make it clear that one is the real standard, the other is an acceptable way of getting close to it if you don't understand it... --Vasha

And what is "right"? That is the whole problem here, isn't it? There isn't one "right" thing. Annie 17:09, 3 July 2017 (EDT)

That is a good reason to cite an external authority such as the CMoS (which particular authority? That is essentially an arbitrary choice.) --Vasha 17:39, 3 July 2017 (EDT)

And how is that better than our home-grown system besides the "it is not standard" and "I do not like it"? The standards were never created with non-native speakers in mind - I would make a case that they are there partially to help with the grammar and mainly to cut on weird clauses and make things uniform in publications. Which our standard already does. There is a reason why there are multiple standards and a lot of in-house ones - there is no real right and wrong. Annie 22:42, 3 July 2017 (EDT)

I've been thinking on that whole thing in the last days. I will voice my problem with this again: "explain "prepositional phrase" in 2 sentences that do not rely on "but it is obvious that "go to the hospital" and "go on dancing" are different"" - if you can do that, every ESL teacher in the world will love you. That will end up with the moderators needing to explain grammar to contributors (or contributors just ignoring the whole thing because they cannot even understand when to capitalize). We can add a few more words to the list but having a list is easy to understand and to follow. Plus a list allows computers (and bots) to capitalize properly as well - allowing better consistency. I believe that consistent usage is more important than being correct according to one standard or another... Annie 17:09, 3 July 2017 (EDT)

Computers would be able to follow the first/last/punctuation rule too. Are you opposed to that amendment? --Vasha 17:39, 3 July 2017 (EDT)

Punctuation is tricky in titles (because it does not follow the standard rules). Commas (or their lack) should not really have any bearing on the capitalization. Annie 17:40, 3 July 2017 (EDT)

The punctuation part of that sentence is meant to deal with examples like "Where To, Please?" and "I Just Have To, Baby", which are capitalized the same as "Where To?" and "I Just Have To", and with all of the titles in this search; and to avoid having to explain that "last" also means the last word of the main title before the colon that marks the subtitle. --Vasha 22:11, 3 July 2017 (EDT)

You know that. Someone reading the sentence does not. It is again complicating a rule just because some authorities say so. Keeping it simple makes it easy to understand and implement. Annie 22:42, 3 July 2017 (EDT)

All but two of the titles in that search already do follow the "capitalize before punctuation" rule. Do you want to change thousands of existing titles just to leave five words out of a definition? It is really not a long or difficult rule. --Vasha 22:54, 3 July 2017 (EDT)

Plus allowing two different versions of the rules based on editor's choice is probably the worst we can do - it will lead to editors wars - I want it exact, the other PV on the title wants on the relaxed rules and both of us are adamant that if we PV, the titles follow the rules - now what? Saying that the expert one takes precedence brands the other as what? The lazy one? The one for the people that do not care? Let's not open that door. Or a contributor that prefer the relaxed way but makes a mistake and a moderator converts all to the complete because there were 2 fixes needed to get there and that is what they prefer. And we will end up with stories in the same anthology with different capitalization because they were entered at different times by different times and just imported... So yes, I am against any change that will officially allow two different standards. We either go with the punctuation/first/last rule at all times or never at all. Annie 17:40, 3 July 2017 (EDT)

I feel an instinctive aversion to adopting a rule that would say that the capitalization of "Go On Dancing" is wrong... Maybe I am just too hung up on following professional editing standards because that's my profession :-) If having the titles in this database capitalized differently than the way other people do it is the price of avoiding edit wars and wrangling, then it's a price worth paying. So yes, I think the list plus first/last/punctuation would be close enough. --Vasha 17:53, 3 July 2017 (EDT)

And if you need to edit for a paper/school that had adopted a different standard compared to what you are used to, would you turn down the job and/or try to tell them that their standard is not good? :) If anything, the current status quo (with a very small list of what we do not capitalize) is easy to implement and use. Adding a few more to the list to cut the confusion is workable. Something bigger? Changing to one of the standards won't improve the data here, will not help with simplifications - it will just confuse people and cause a lot of work that will need to be done to bring the current DB to that standard. Can you give one argument about how changing the rules will make the data better? Search is case insensitive for Latin-1, the titles now are consistent (kinda), the reading is not impeded from the current system. And it is very easy to explain and implement it.

And... all those standards are US-based. UK has their own. So do Australia or any other English speaking country. Why use a US-based standard as a base? :) Ours do not care about the country; it only cares that the title is in English. Annie 22:42, 3 July 2017 (EDT)

Prices and weird currencies - reading verification needed...

Our current help is very specific: "Enter a single price, preceded with a currency symbol... For books priced in other currencies, use the appropriate symbol or the accepted alphabetical alternate.". In my reading it means that a price field can never start with a number. Had that changed for non-standard currencies? I had seen some of the Bulgarian and all of the Croatian books (I let a few in as well because all the previous ones were like that...) go with numbers first (15 leva, 10 din and so on). There are probably more than these. Before I go and fix that, I want to make sure I am not overreacting. Thanks! Annie 18:23, 30 June 2017 (EDT)

I wonder if it might be good to create a drop-down with currencies next to the field for the actual price? It would require some cleanup beforehand, perhaps (a lot of it), but it might be good in the long run as the database becomes more international. ···日本穣 · 投稿 · Talk to Nihonjoe 18:29, 30 June 2017 (EDT)

That actually is a great idea. We will need a "Other/Not listed" that will require a note in the Notes but having a drop down may be very very useful. Allow a user to have a default (as with the language) and that should eliminate a lot of funny errors. My only worry will be that this list can get very long when we add international books... so we will need some filtering on what an editor see in a specific book - if the list has 200 entries, it is worse than not having a list):) Annie 18:40, 30 June 2017 (EDT)

Maybe make it default to the 5-10 most common currencies in the database, and allow the editors to got to a settings page where they can check boxes to add (or remove) additional options to the list if they wish. That should cover 90%-ish (or more) of those entering items. ···日本穣 · 投稿 · Talk to Nihonjoe 02:56, 1 July 2017 (EDT)

Additionally, this might add the opportunity to add multiple currencies to publications (so those can be moved out of the notes, too). ···日本穣 · 投稿 · Talk to Nihonjoe 02:57, 1 July 2017 (EDT)

The other day I was thinking about the changes that will need to be made to add support for multiple prices as per Roadmap 2017. Standardizing currencies was on my radar screen. However, we have almost 400,000 pubs with prices, so we'll have to do quite a bit of analysis first. For example, we have a few thousand "old UK" prices which look like "4/6". The good news is that the number of purely numeric prices is low, a bit over 100, and most of them are "0.00". Ahasuerus 11:32, 1 July 2017 (EDT)

And they are probably US dollars. Can you run a query on how many we have that start with a number - back to my original question? :) And am I misreading or do they need fixing? 14:06, 1 July 2017 (EDT)

Spot checking the 100+ "purely numeric" prices suggests that all of them are likely in error. The superset of prices which "start with a number" are a different story, though. There are 12,445 of them and they belong to different subcategories. 7,584 are "old UK prices" like "2/6" and "9d". The rest mostly have the currency abbreviation appended rather than prepended: "24.00 FF", "8,000 Lire", etc. We also have a number of oddball cases like "1 ruble 60 kopec" and "15$00".

We already have a cleanup report that checks for invalid prices, but it's currently limited to a few common errors like "$CDN" instead of "$C". We should probably expand it to look for other oddities as well. Ahasuerus 14:47, 1 July 2017 (EDT)

I've seen something in that report probably 3 times so I did not even remember we have it. And I forgot about the old shilling ones not having a symbol at the start (I think I am blanking their existence from my mind at all...). I can fix all the Bulgarian ones before I start adding the rest to be "Lev XX" and consistent and then we will work on the other languages. And the oddballs will need cleanup (R 1.60 looks so much better than 1 ruble 60 kopec :). Annie 17:05, 1 July 2017 (EDT)

It looks nicer, but I am not sure how many users will be able to tell what the "R" in "R 1.60" stands for. Spot checking the database, I see "100 Pts", "10.50 FB", "299 Kč", "48.00 元", "149 UAH", "9.90 RON" and any number of other abbreviations and symbols. Ideally, we will want to have mouse-over Help bubbles available for all currencies just like we do it for transliterated names. We'll need to make all currency symbols table-driven first, though. Ahasuerus 17:28, 1 July 2017 (EDT)

Oh, I did not mean just R 4.50. It falls under the less-known currencies so it will get also a "Price is in Russian Rubles" note in the Notes. :) I was just talking about the field itself. On the other hand anyone that cannot decipher R in a Russian language book price will be even more confused by "kopec" :) Annie 17:49, 1 July 2017 (EDT)

Well, a Google search on "kopec" finds this Wikipedia disambiguation page in two clicks. OTOH, a Google search on "R currency" suggests that "The currency code for Rand is ZAR, and the currency symbol is R."

The more I am thinking about it, the more I like the idea of making currency symbols table-driven... Ahasuerus 18:03, 1 July 2017 (EDT)

But if you are looking at a Russian book and you are interested in the price, the R will be obvious. If you need to google it, chances are that you need to google rubles as well anyway. I do see your point but I would prefer consistency when possible... And having a table will be awesome - but in the meantime the notes in the Pub notes will need to do. Can we get a template "Price is in "currency""? So we can find those and clean them up when we switch to another system? Not too many editors are adding a lot of non-major for the DB languages books as it is and getting them to use a template should not be that hard. Annie 18:09, 1 July 2017 (EDT)

IIRC, we already had a heated discussion on the subject years ago. My suggestion was quite simple: there is an ISO table of currencies (I used it when I was in the banking field, you can skip the bit about the position) that we can use instead of creating another custom one. The major drawback is that a "$6.99" price would in this case be transformed to "USD 6.99" which seemed at the time to annoy some anglocentric major contributors. Hauck 01:55, 2 July 2017 (EDT)

The ISO table will also solve the whole issue of everyone picking up the name for their currency any way they want and needing to put a note explaining what that might be. And if people's biggest issue is USD 6.99, it won't be that hard to code a few currencies in a special way I suspect (the ones that are now character based maybe?) and leave the exotics to follow the ISO. Actually the more I think about that, the more I like the idea - fully ISO or ISO for all except a handful of currencies. And it will be a lot easier for international editors. Annie 03:25, 2 July 2017 (EDT)

That's such "solutions" that I profoundly dislike. Why should we be making an exception for "a handful of currencies"? It's ISO or not, it's as simple as that. As a moderator, you'll find that it's exactly such idiosyncrasies (rules that are "generally" followed, but not always -who say regilarization of suffixes?-) that are the less easily understood by new contributors. Hauck 04:29, 2 July 2017 (EDT)

Most new contributors work in one language (or a handful anyway). My point is that if that is needed to convince the anglo-centric world to use the ISO table, then so be it. It gets us one step closer to a generic ISO based rule - and will be a vast improvement over where we are now. Small steps sometimes work where the big ones don't - and then the gap is closed a lot more easily :) I would rather leave the USD to be an exception and get all the rest fixed than have everything in a mess because we cannot convince everyone to adopt USD. Annie 04:46, 2 July 2017 (EDT)

The issue of prices can get complicated, e.g. see this 2011 discussion and this 2015 discussion. Creating a drop-down list of currency codes and/or symbols (a big can of worms in itself) may help address some of these issue, but further discussions will be needed. Ahasuerus 10:57, 2 July 2017 (EDT)

As usual it will go nowhere (space vs. no space, comma vs. period, before vs. after, USD vs. $, and I spare you the "space if it's DM, no space if it's €" juicier bits). Either we propose something and we vote or we wait for another two years to have another soul-searching round of discussion. As we're an english speaking outfit, the ISO norm is quite clear (even if didn't please Michael), and boils down to "XXX<space>888.88" where XXX is the ISO code.Hauck 11:14, 2 July 2017 (EDT)

Adding a drop-down list would address many of these issues if we were to add a table defining the formatting of each currency: spacing, "before vs. after", etc. It would eliminate the need for complex data entry rules. Or at least most of them anyway. Ahasuerus 11:39, 2 July 2017 (EDT)

IMHO it's here that we err. The entry standard (before/after, space/no space) should be the same for all currencies and set once for all. We're a bibliographical outfit and strict adherence to national typographical norms of price writing is not our problem. Hauck 11:50, 2 July 2017 (EDT)

Well, once we make currencies software- and table-driven, it will be easy to change the display component any way we want, including standardizing the formatting if that's what the majority prefers at some point.

My main concern is the data entry side: with 400,000 prices in the price field and another (estimated) 100,000+ prices in the Note field, manual changes become prohibitively labor-intensive.

My current thinking is that the project that will add support for multiple prices per publication will need to add support for a drop-down list of currencies at the same time. If we do it as a two-step process, we will have to re-do 100,000 prices, which will be unnecessarily painful. Ahasuerus 12:03, 2 July 2017 (EDT)

(unindent) (because my phone started making the letters above very small so it can show me more than 2 letters per line) Not all 400 000 prices will need manual touching - most of them are standard and will just get a conversion. We are looking ta the 12K or so that are non-standard. And even in them there are some patterns (the Croatian "XX din.", the Bulgarian "xx leva", most of the shilling prices and so on. The Notes ones will need a manual moving no matter what we do (some may be better formatted than others but from I had seen, it is editor preferred note) but as long as the first move is done to a standard, the second, if you go for 2 steps, will be automatic. I am with Herve though(albeit in a bit softer position - I will allow for a few special cases) - we do need to have the options for every single currency - go ISO (currency at the start) and we are all set.

And if we do not change it now, we will have even more entries in 2 years. Problems in consistency of data do not disappear, they just get worse as we all know. Annie 18:43, 2 July 2017 (EDT)

I am sorry, my formatting may not have been clear. When I wrote "manual changes become prohibitively labor-intensive", I didn't mean to imply that we didn't want to make currencies table-driven. It was an argument in favor of a single-step conversion rather than a two-step conversion. I should have kept it as a single paragraph, but the extreme indentation threw me off.

As far as the implementation details go (ISO 4217, currency symbols vs. currency codes, etc), there will be various issues that we will need to discuss before we finalize the design. For example, ISO 4217 only covers current and "recent historical" currencies while we need to support older currencies as well: the ducat, the livre, the real, etc. Some editors prefer currency symbols like £, $, €, and ¥ to currency codes, but it may be less of an issue if we add mouse-over help. Ahasuerus 21:09, 2 July 2017 (EDT)

So let's start discussing? :) I understand that there are some complications because of older currencies but then we implement ISO+ (ISO for where it exists; custom table otherwise). And I am not sure that $3.12 is any better than USD 3.12 but I won't argue that one... Annie 21:13, 2 July 2017 (EDT)

I find that it usually works best when we start discussing the details of Change B while Change A is being coded. If we have too many balls in the air at the same time, I start running out of bandwidth, especially when there are Fixer-related issues that require my attention. I hope to wrap up the current Amazon emergency (one way or another) in the next few days, then I will need to implement the security fixes that I have been working on, then we can separate catalog IDs from ISBNs, then we can add support for multiple ISBNs and then we can handle prices :-) Ahasuerus 22:10, 2 July 2017 (EDT)

Well - this started with me asking "do I misread the rules or should we always start with the currency on non-standard currencies?" and sounds like I do not misread the thing so I will proceed accordingly for now. :) Annie 22:59, 2 July 2017 (EDT)

(unindent) Why do I keep finding things to fix instead of working on adding my books? :) Annie 17:05, 1 July 2017 (EDT)

It's part of the standard progression:

• Read SF
• Collect SF
• Catalog your SF collection
• Catalog SF in general
• Help design software to catalog SF
• Write software to catalog SF
• Create and maintains robots which will catalog SF on your behalf
• Wonder how you ever had the time to actually read the stuff!

Ahasuerus 17:36, 1 July 2017 (EDT)

You are forgetting "contemplate learning a new language so you can read the books noone wants to translate in one of the languages you know". I almost learned French so I can read Brussolo (and a few more guys whose names I do not even remember anymore) once upon a time. Russian came to the rescue though so I was spared that fate. :) Plus if that is the progression, I am working on it in a weird order (which is not very unusual for me). :)Annie 17:49, 1 July 2017 (EDT)

Personally, I like seeing symbols in the currencies with which I am familiar. They're more quickly recognizable than ISO codes. But it seems to me that the natural thing is to have everything stored internally as ISO codes and allow the user to set preferences for symbols. Chavey 03:03, 3 July 2017 (EDT)

It's been my experience that any coding system designed by humans is likely to change over time. In this case, we have the Russian ruble, whose ISO code was changed from "RUR" to "RUB" in 1997. For this reason I try to use integers as unique identifiers in ISFDB tables and then I put human-assigned codes in separate fields.

There are other permutations to consider. For example, the ISO standard assigns a new code when a currency is revalued, so the code for the Mexican peso changed from "MXP" to "MXN" when the peso was replaced with the "new peso" ("nuevo peso") in 1993. In 1997 the word "nuevo" was dropped, so it's now back to just "peso". However, the ISO code has remained "MXN". If we were to use ISO codes, what should an editor do when entering an undated Mexican books whose price is listed as "100 peso"? Depending on whether it was published prior to 1993 or after 1996, the correct ISO code should be either MXP or MXN, something that most of us couldn't determine without a fair amount of digging.

To go back to the Russian example, the ISO code for the Soviet ruble was "SUR". When the USSR was dissolved at the end of 1991, the code was retired. It was replaced with "RUR" (later "RUB" as per the discussion above) for the Russian ruble and "BYB" for the Belarusian ruble. The latter was replaced with "BYR" in 2000 and then with "BYN" in 2016.

I am sure we can sort it out and come up with a design that will work for our purposes, but it will require a fair amount of bandwidth. Ahasuerus 11:23, 3 July 2017 (EDT)

And how important it is to know which peso it was? I know it is a piece of information but unless if we get a Mexican contributor that really knows how to determine that without spending hours digging, it will be peso anyway. We can use a blended MXP/MXN and when one of them is verified, it will be fixed. As for the Belarusian, using the current BYN will not lose any information (as using RUB for the SUR and RUR won't). If we know which one it is, then fine - safe it. But in the current rules, all the rubles will be just R. So nothing lost. And a system can be amended and improved.

There is a thin line between finding a good design and getting stuck because we are looking for a perfect design. I am not saying not to try to find something that catches everything but sometimes good enough is better than trying for perfection. Even the ability to add free text ones that land on a report for manual inspection will probably work good enough - do we really expect a surge of thousands of non-standard currencies in a week? Annie 17:28, 3 July 2017 (EDT)

I am not proposing a design yet, I am just contemplating requirements :-) We'll need to have a good working understanding of what the challenges are before we come up with a design. For example, we'll need to keep in mind that currency signs/symbols are sometimes duplicative, e.g. the "naked" dollar sign ($) is used both for US dollars and for Mexican pesos. Or, as we discussed earlier, the abbreviation "R", which we have been using for the Soviet/Russian ruble, is also the official sign for the South African rand. Ahasuerus 19:14, 3 July 2017 (EDT)

Still - trying to think of all special cases will never work - there will always be that one country that has messed up their monetary system so badly that no rule can catch it. Anyway - I guess will pick up that again when the current projects are done. :) Annie 21:41, 3 July 2017 (EDT)

Yup! 👍 Ahasuerus 22:30, 3 July 2017 (EDT)

Obvious settings might be "Always use ISO; Use symbols for the most common currencies; Use symbols for every currency we know symbols for; Use symbols for currencies I have checked in my preferences." Pushing this a bit further (Currency v. 2.0), one can imagine a preferences setting that allowed US $ and Australian $ to be seen as ($, AU $) by an American and (US $, $) by an Australian. Or allowed a Nigerian visitor to specify that their currency symbol be "₦", at least for them, even if we didn't have that entered in our table yet. (Ok, so far that would only apply to one book. But our Nigerian visitor might add some more!) Chavey 03:03, 3 July 2017 (EDT)

I too considered this approach at one point. It would take some work, but it's certainly doable. However, my concern is that it would result in our bibliographic pages appearing differently to different users. We already have User Preferences to suppress certain data elements, but displaying the data differently for different users would mean opening a different can of worms. Ahasuerus 10:31, 3 July 2017 (EDT)

Aside: A fundamental principle of software systems, which I try to teach to my students, is that the system for storing data for manipulation by the computer is generally completely separate from the system that is most convenient for the user to see and read. You should not try to force the computer system to deal with what looks nicest to the human; and you should not try to force the human to read what is best for the computer. Assume early on that you will have a conversion layer that turns one viewpoint into the other. That also makes it easier to change how things are presented to the user, without having to mess around with internal details. (In fact, I just gave that lecture to my research students last week.) Chavey 03:13, 3 July 2017 (EDT)

In a way, we have had this separation for as long as we have had machines. Consider a 50-year-old car. It had no computers in the modern sense of the word. However, its dashboard, which was designed to "look nice to humans", was only indirectly related to the way the car operated. It also required conversion layers between what the human operator saw and did and what the actual machinery did.

Of course, we have a lot more flexibility when implementing conversion layers in the software. The "conversion layer" of a WWII-era battleship consisted of things like 4-foot-long levers :-) Ahasuerus 10:46, 3 July 2017 (EDT)

I am horribly late to this conversation, and I have no strong opinion about the formatting (symbol before or after, space or no space, etc.)... I'm happy to let the dust settle and have those with stronger opinions tell me what I should be doing and enforcing.

That being said, one thing that has always troubled me about the price field is that in many cases it doesn't reflect what's printed on the item but attempts to translate it into a standard, but the standard is rather loose and has perhaps more exceptions than actual rules.

In my dream database there's a field where you can record each price directly as it's listed on the pub, then a separate field (or fields) where you can enter a proper amount and identify the currency for sorting and comparison purposes; the conversion layer could work on the latter two standardized fields.

Just my USD 0.02 Albinoflea 23:17, 3 July 2017 (EDT)

I agree with this idea. I work in a world of compiling information from disparate sources where there is no uniform reporting standard, and we have found it best to capture and preserve as-reported and to maintain normalized/computed separately. --MartyD 09:26, 4 July 2017 (EDT)

A semi-aside about the "15$00" mentioned above. It means 15 escudos, and the "$" should really be the cifrão symbol (an S with two vertical lines through it), but there's no Unicode character for that. --MartyD 09:26, 4 July 2017 (EDT)

We could use a PNG of the symbol. I grabbed one from Wikimedia Commons. We'd just need to specify an appropriate size for it: Image:Cifrão symbol.png. ···日本穣 · 投稿 · Talk to Nihonjoe 14:45, 4 July 2017 (EDT)

PNGs in the middle of a text field make a real mess of the view on smaller screens (I work from my phone a lot) or when you need to make the letters a lot bigger because of failing eyesight. Annie 15:24, 4 July 2017 (EDT)

Okay, what about this: $? It's messier, but produces the correct symbol. ···日本穣 · 投稿 · Talk to Nihonjoe 15:55, 4 July 2017 (EDT)

An interesting point. Suppose we have two books and each one says "$100" on the cover. In one case it may mean "100 pesos" while in the other case it may mean "100 dollars". Of course, an English language book would be more likely to be priced in dollars and a Spanish language book would be more likely to be priced in pesos, but it's not dispositive since there are many Spanish language books being published in the US.

If you think about it, we already make this distinction ("as-reported" vs. "normalized") for authors and titles. We capture authors/titles as they appear in publications and then create variants if needed. In addition, we plan to start capturing "stated" vs. "corrected" vs. "derived" ISBNs as per RoadMap 2017. There have also been preliminary discussions re: this issue as it applies to publishers and imprints.

That said, we do some normalization of the captured data even when we aim to enter it "as is". For example, we normalize capitalization and some (specifically Latin-1) accented characters as in the case of Philip José Farmer. We'll have to think about these issues when tackle price changes. Ahasuerus 13:23, 4 July 2017 (EDT)

Not only do we "normalize", but we also practice some outright changes to the data. I'll always remember my disappointment when I was forced to change the "Kurt Vonnegut Jr" that I was seeing on the title page of the book just before my eyes into "Kurt Vonnegut, Jr.". It's from this day that the promised magic of "as is" disappeared for me. Hauck 13:44, 4 July 2017 (EDT)

Out of curiosity but is the author name normalization from the days before pseudonyming? It always made the Latin alphabet languages a bit weird in cataloging here (you cannot apply the rule in the Cyrillic alphabet languages because that format does not exist and there are no shortened versions of words like Junior (and adding it in Latin will be... weird) - so we are much closer to As Is there). I am not challenging the practice, I am just curious. Annie 15:24, 4 July 2017 (EDT)

VTs and pseudonyms were part of the original ISFDB 2.0 implementation which was beta'd in 2006. (Pseudonyms couldn't be deleted until late 2009, but it was an unrelated headache.)

The reason why the issue of "name regularization" originally came up was that some publications, especially magazines, were using unusual forms of author names which many editors felt didn't deserve a VT/pseudonym. For example, if a magazine issue credits Heinlein as "robert a heinlein" on the title page, should we create a new author record? Once we decided that the answer was "no", we kept finding more and more oddball cases which had to be addressed. Hence the current rules. Ahasuerus 12:38, 5 July 2017 (EDT)

Thanks for the background. It just works a bit weirdly now that we allow non-Latin author names - because there is effectively no standardization there. I am coming from the LT system where we just combine the authors and it does not matter how many different versions are there (although no varianting so translations are not caught) - whoever is the main author ends up with the list of all combined ones and that is it. Different systems, I know :) I was just curious. Annie 15:21, 5 July 2017 (EDT)

Preferences for image source?

The Image URL section of the add/modify pub provides rules for what is acceptable for links. It does not provide any guidance as to preference or order. For example this pub is unverified and has an image from Bookscans. I will be making a transient verification and wondered if I should replace the image with an actual scan? Are ISFDB hosted images preferred to all others? I know that Amazon can change an underlying image, so there is a preference for ISFDB hosted scans over Amazon. If such preferences exist, can they be added to the help, please. Doug H 21:03, 6 July 2017 (EDT)

ISFDB-hosted images are generally preferred because we have more control over them. They are also more stable and they are publicly available as part of our public backups. Of course, quality also matters: we don't want to replace externally-hosted high quality images with ISFDB-hosted low quality images. Other than that, I don't think there is a hierarchy of external sites. Ahasuerus 23:35, 7 July 2017 (EDT)

ASIN for printed books with ISBNs

Amazon's rule is that for printed books with ISBNs, their ASIN is their ISBN-10 number (Wikipedia and links from there show that as well). E-books and audio-books get proper B-starting ASINs even when they have ISBN; no-ISBN items get a B-ASIN. So my understanding had been that the new ASIN field is only for cases where the ISBN-10 is not also an ASIN (as we already have the ISBN on the page) and I had been acting accordingly (edited one out today). Am I mistaken or do we want to make that part of the rules? Or do we want to leave that to every editor idea (I think having the number in 2 places is an overkill). Thoughts?Annie 22:53, 7 July 2017 (EDT)

As described in Bug 660, some Amazon records use a "B0" ASIN even though an ISBN is available. And, of course, 979 ISBN-13s can't be converted to ISBN-10s, so that's another scenario where we have to link by ASIN. I wouldn't enter an ASIN that is the same as the book's ISBN-10, though. Ahasuerus 23:38, 7 July 2017 (EDT)

Right - which is what I was saying above albeit a bit too complicated I think - if the ASIN is not ISBN-10, we record it (And all of those are B-ASINs). Otherwise, we do not need it. :)

And now comes the big question - do we leave the editor to decide if they want to repeat the ISBN-10 when it is the ASIN or do we make the rule (and try to enforce) that we only record as ASIN if it is not the ISBN. Annie 23:49, 7 July 2017 (EDT)

I would discourage editors from re-entering ISBNs as ASINs unless there is a specific reason to. Did the editor(s) who have done it have additional thoughts on the subject? Ahasuerus 00:08, 8 July 2017 (EDT)

The one today did not know that ISBN-10 was used for ASINs so not really(here is the discussion). The reason I brought it up here now is because a second one has 2 pubs in the queue now like that. I will put them on hold and go talk to the editor to ask her to come chime in here (of course I have misgiving for those two anyway because they are graphic novels but one thing at a time). Annie 00:13, 8 July 2017 (EDT)

I thought the whole point of the new field was so the links would work... ? so ISFDB gets the link credit? Susan O'Fearna 00:58, 8 July 2017 (EDT)

If you have the ISBN, the link is already there (on the left under other sites) :) The idea of the ASIN external identifier is to allow ISBN-less books to have an identifier (and while we have it, we throw the links in there because most e-books are available on all sites) and thus to allow them to be automatically submitted from our friendly neighborhood robot (as he does for books with ISBNs). The rest of the templates are indeed for the links mainly - so we do not have 20 versions of them, half of them not working. Ahasuerus can comment more - but that is my understanding. Annie 01:03, 8 July 2017 (EDT)

That's right, books with ISBNs already have links to Amazon and many other places under "Other Sites", so adding the same ISBN to the "External IDs" field would create a duplicate link. Ahasuerus 09:21, 8 July 2017 (EDT)

pb or tp

For books as tall as 7.25" (19 cm) or as wide/deep as 4.5" (11.5 cm) use "tp". So I can read in the rules, but I've a discussion about pb/tp with Stonecreek, we have different opinions about this. here is a publication with a width of 115 mm, this is a tp or not? I mean yes.--Wolfram.winkler 04:58, 9 August 2017 (EDT)

Well, I've sometimes classified books as pbs even if their dimensions were a bit off (like the first two of this publication series). IMHO, in addition to the strict "metrologic" data, the intentions and usages of the publishers are to be considered. In your case, if most of the books in the same publication series are classfied as pbs, I'd vote for pb in order to lessen the confusion that may be created in casual users.Hauck 05:07, 9 August 2017 (EDT)

We should not weaken the rules or we must change the rules. All tolerances are already used. BTW where come the other measured values from? My submissions are really measured by myself. I don't believe that everyone does it, too.--Wolfram.winkler 13:05, 23 August 2017 (EDT)

For the book that you mention, width is exactly on the threshold value (11.5 cm) and height (18 cm) corresponds to a pb (less than 19 cm), I've no problem with classifying it as a pb. We're not yet arrived at the point where we should have rules precise to the millimeter (or worse to the picometer) and special guidelines for books that happen to have one dimension on the threshold value. Human interpretation and decision is also an integral part of our system. Hauck 13:46, 23 August 2017 (EDT)

We real calculate with millimeters (11,5 cm = 115 mm), measured parameters can not be the subject of calculations. There are many books with these dimensions, not only one. So I can not say, that it is an exception. I think, I use the data in the rules with the accuracy in mm, that is exact. BTW 11.5 cm is already rounded! The max. level for pb is 11.43 cm (4.5"*2.54).--Wolfram.winkler 12:01, 26 August 2017 (EDT)

There are also cultural differences, e.g., I usually try to mark Japanese bunko as pb even though the sizes are not exactly the same (bunko is basically a mass-market paperback binding in Japanese markets). Uzume 15:23, 9 June 2018 (EDT)

How to handle author credit of traditional stories

I am copying a discussion from my user page. Any comments? Seems like a sentence may need to be added to Help. --Vasha 21:13, 22 August 2017 (EDT)

I am a bit confused what to do about traditional oral tales, actually. (Although this is not relevant to us, Goodreads recommends giving the author of traditional tales as "Anonymous.") Sometimes such stories have no credit, sometimes the credit is something like "Navajo." Sometimes they are "Retold by..." in which case I put the reteller as author. But sometimes they are in this database with the translator/reteller as author even though the credit on the story itself was given as "Traditional Norwegian" or whatever. What is to be done...? --Vasha 13:01, 22 August 2017 (EDT)

I don't think there is anything in Help about retellers. In my experience, there are three options depending on how much rewriting/editing was done:

• A significant amount of rewriting. The book is entered as a COLLECTION. The reteller is entered as the author of the collection as well as the author of each collected story.
• Some amount of rewriting/massaging/rearranging. The book is entered as an ANTHOLOGY. The reteller is entered as the book's editor. Individual stories (if known) are entered as by "uncredited".
• Very little or no rearranging/editing. The book is entered as an uncredited ANTHOLOGY. Individual stories (if known) are entered as by "uncredited". This is not very common but has been known to happen, e.g. here.

It may be beneficial to raise this issue on the Rules and Standards page to see what other editors have seen. Ahasuerus 16:27, 22 August 2017 (EDT)

That sounds good in theory, but it may not be very easy to determine how much the editor/translator/reteller contributed. --Vasha 21:13, 22 August 2017 (EDT)

Per our policy, it would seem the second and third cases shouldn't occur. "Fairy tales with no known author" are supposed to be excluded. -- JLaTondre (talk) 21:48, 22 August 2017 (EDT)

Indeed, I wouldn't include an entire collection of them, but what about when one is in an otherwise spec-fic anthology? Doesn't seem right to mark it non-genre. --Vasha 21:56, 22 August 2017 (EDT)

I ran into this sort of problem many years ago, with Lord Halifax' collections of ghost stories. Based on discussion with moderators at the time, I ended up recording Lindley as the "author" but then noting the additional information he provided about the sources. One thing that was not clear there is even if he says it was written by someone, did he reproduce that verbatim or retell it? See Lord Halifax's Ghost Book and Further Stories from Lord Halifax's Ghost Book. I'm not saying this is the way it should be done, or that what's there for these shouldn't be improved/changed; just offering the examples. --MartyD 07:37, 23 August 2017 (EDT)

Epic poems: NOVELs or POEMs?

so, would the Aeneid http://www.isfdb.org/cgi-bin/title.cgi?1661902 be a novel, or a poem? thanks. gzuckier 23:59, 25 August 2017 (EDT)

Most people consider it a poem, specifically an epic. ···日本穣 · 投稿 · Talk to Nihonjoe 01:34, 26 August 2017 (EDT)

That's right, it's an epic poem. At this time we don't have a separate title type for epic poems, so our choices are "NOVEL" and "POEM". If we enter them as POEMs, then their standalone publications will have to be classified as CHAPBOOKs, which doesn't seem quite right. For this reason I find "NOVEL" to be a somewhat better (although imperfect) choice for epic poems. Ahasuerus 10:12, 26 August 2017 (EDT)

I'm holding the edit. Before an edit conflict, I was about to make the same point about the need to change the pubs into chapbooks. One of the translations is into prose which is arguably still a novel. Personally, I think epic poems are properly POEMs and not NOVELs, but if we do decide to proceed with that change, we should certainly inform the verifiers of the affected publications before proceeding. --Ron ~ Rtrace^Talk 10:34, 26 August 2017 (EDT)

How difficult is it to add in a new EPICPOEM (or just EPIC) title type? ···日本穣 · 投稿 · Talk to Nihonjoe 23:35, 26 August 2017 (EDT)

Well, we would first have to agree on the desirability of this addition. As I recall, the last time the question came up, there was a spectrum of opinions. Ahasuerus 14:00, 27 August 2017 (EDT)

As before, NO. Hauck 14:05, 27 August 2017 (EDT)

Is there a specific reason you oppose it? ···日本穣 · 投稿 · Talk to Nihonjoe 22:02, 27 August 2017 (EDT)

I've developped my arguments in a previous round, but in a nutshell: 1) problem of quantity: this category will likely contains only a few tens of records so why bother as we already have POEM (shorter works) or NOVEL (longer), 2) problem of definition: what's an EPICPOEM? and how can it be defined in such a way that we'll avoid interminable discussions about one precise work, 3) problem of "explainability" (don't know if this is really english): such a concept, its definition and its use may prove difficult to convey to new contributors, 4) problem of "opening the floodgates": half-jokingly (but only half), why not the following categories: HAIKU, VIGNETTE, SPOOFESSAY, TVSCRIPT, FILMSCRIPT, PLAY, FICTIVEESSAY, BOXEDSET (a quick look at the end of any Contento will convey my meaning), IMHO we have enough categories for the present usage. Hauck 02:16, 28 August 2017 (EDT)

The problem with adding more categories is trying to fit things into them after that - especially across languages. Our current types are very clear (in English) - count the number of words and put it in the category. Most of the old epic poems have both verse and prose translations - do we really want to have a prose translation marked as poem just so it fits the original and the new type we added? Not to mention that the main reasons those are not novels to start with is what prose and poetry were used for at these times - if they were written after the romances and at the times when novels were getting written, they would not have been poems. As for the modern ones... a novel in verse is still a novel; an epic poem is either a normal poem or if long enough - a novel. We have notes all over the place - using them for this kind of data ("the text is in verse" or "considered an epic poem" or whatever makes more sense than splitting the types again. (Just see how many issues we already have splitting pbs and tps and we have rules there - for this we won't even have proper rules short of "internet says"). Annie 21:20, 28 August 2017 (EDT)

If we do agree to add this title type, it will be moderately labor-intensive to actually add it because title types are currently mostly hard-coded in the software. I will need to change the code to make it table-driven, which will facilitate adding other title types and publication types in the future. Ahasuerus 14:00, 27 August 2017 (EDT)

How many epic poems are there, and how many are speculative fiction? I can think of this one, Beowulf, Gilgamesh, Paradise Lost, and a few others. Are there enough of them to justify making it a separate title type? Regardless of that, I think it would be good to change the database in order to make it more flexible in the future. ···日本穣 · 投稿 · Talk to Nihonjoe 22:02, 27 August 2017 (EDT)

There's a list of epic poems on Wikipedia. That may help the discussion. ···日本穣 · 投稿 · Talk to Nihonjoe 22:04, 27 August 2017 (EDT)

(unindent) While I agree with those who don't think a new title type should be added. I'd like to get back to the original question. I see that we have several other epic poems entered as NOVELs in the project. My opinion is that novels are by definition written in prose. Epic poems being written in verse seem to me to be a better fit as POEMs. I appreciate the concern that putting such long works in a CHAPBOOK, that is a peculiarity of our structure. Our use of the term CHAPBOOK does not match the common definition of the term. We already have large CHAPBOOKs and hardcover CHAPBOOKs, and CHAPBOOKs for single poems of various sizes. I don't feel that including epic poems published individually differs from these other uses of the container type. To summarize, I'd rather have one term (chapbook) that is used outside its common definition than have two (chapbook and novel). If we do decide that epic poems are novels by our definition, we should probably document the fact and also define at what length we consider a poem to become a novel. Regardless of the outcome, I'd like to try to come to a consensus so that I can either approve or reject the held edit. --Ron ~ Rtrace^Talk 10:44, 2 September 2017 (EDT)

Since epic poems are so few in number and mostly in public domain, it should be fairly easy to check their word counts. Perhaps we could use a threshold similar to the one that we use for the SHORTFICTION/NOVEL divide: anything under 40K (?) words is a POEM, anything over the threshold is a NOVEL? Ahasuerus 16:06, 2 September 2017 (EDT)

In which language? Most of the epic poems are not originally in English. So if we count in English, which translation?

They are the precursors of novels so I consider them novels logistically. But if the community decides they should be poems, that's fine. But the number of words will be a bit weird to count. Annie 17:05, 2 September 2017 (EDT)

I don't think we've had enough participation for there to be a consensus. I'm going to reject the edit to change the Aeneid from a NOVEL to a POEM, leaving it as it was before this discussion. However, since we haven't agreed, I won't be changing any epic poems that are listed entered as POEMs. --Ron ~ Rtrace^Talk 21:36, 18 September 2017 (EDT)

Title Series: Collection vs. Chapbook

Why do we allow Collection to be in a title series, but not Chapbook? Consider Adventures in the Liaden Universe, where some of the publications contain only one short work, others more than one. I realize there are other ways that series could be organized, but it nonetheless seems inconsistent that one of the two containers would be allowed, while the other is not. --MartyD 07:39, 23 September 2017 (EDT)

Back in the day, we had a lot of issues with less experienced editors adding CHAPBOOK titles (instead of their contained SHORTFICTION titles) to series. At that time it was decided that the number of legitimate scenarios requiring adding a CHAPBOOK to a series was low and that there were other ways to handle them, e.g. by using a publication series. Hence the decision to change the software to disallow CHAPBOOKs in series even though it introduced the inconsistency that you mentioned. Ahasuerus 09:05, 23 September 2017 (EDT)

By logic it just seems reasonable to allow also chapbooks for title series: in cases like the one mentioned or in big franchises like Star Wars or Perry Rhodan where chapbooks do begin to clutter author summary pages I really think it'd be better to have them stored with the other titles. Maybe it would be possible to have them separated in a sub-series (for example something like 'Star Wars chapbooks')? Stonecreek 10:33, 23 September 2017 (EDT)

Many series seem to contain both numbered and non-numbered items. It seems to me (in my admittedly limited experience) that the numbered ones tend to be pubs and the non-numbered ones SHORTFICTION. This is certainly the case for Adventures in the Liaden Universe that Marty cited above. It also holds true for another series I recently worked with, the John Grimes series of A. Bertram Chandler. So I think it makes more sense to allow chapbooks titles to be inserted into series, particularly as numbered items, rather than the SHORTFICTION contents of those chapbooks. Bob 10:51, 23 September 2017 (EDT)

But if you add only the chapbook, the story won't show up as part of the series when it get translated or when it is added to a bigger collection. Annie 15:32, 23 September 2017 (EDT)

Right. This is the issue that we faced early on and why we decided to disallow CHAPBOOKs in series in the first place. Ahasuerus 15:40, 23 September 2017 (EDT)

In this particular case, at least, that is not a problem. There is another series Liaden Universe short stories that would contain the contents of the CHAPBOOK. Right now that the story in the chapbook does not appear there because it's in the Adventures in the Liaden Universe list. Furthermore, all of the numbered items in that list, including the chapbook, actually have subtitles like "Adventures in the Liaden Universe No. xx". In other cases, the CHAPBOOK would fall under the numbered items under the series, and the contents under the non-numbered items, exactly as the stories in the collections do now. Bob 16:55, 23 September 2017 (EDT)

O.K., since the CHAPBOOKs in the "Adventures in the Liaden Universe" series cannot be placed there, and since they are subtitled as belonging to that series, I've suggested that the subtitle be added to the chapbook title, and the story in that chapbook be put into the "Liaden Universe short stories" series where they belong instead of standing as substitutes for the chapbooks. This avoids leaving the short story list without some of its proper contents and leaves simple some missing numbers in the "Adventures" list, but those "missing" pubs are easily identified in the list of chapbooks. Bob 13:15, 27 September 2017 (EDT)

Again: what about the possibility to place CHAPBOOKs into a subseries of a given title series, as the content does belong to this series, the CHAPBOOK being only the cup that holds the content. Though the same would be true for COLLECTIONS and ANTHOLOGIES, I think that the CHAPBOOKs are the real problem because of their sheer number. Stonecreek 02:21, 4 October 2017 (EDT)

Psychic abilities: In or Out?

This discussion has highlighted the fact that our project scope policy doesn't mention psychic abilities. I have always assumed that they are within the scope of the project and we have hundreds of "psychic ability" titles in the database, but it's not stated explicitly.

I propose that we update the "Inclusions" list to include psychic abilities. Something like:

• Psychic and extrasensory abilities, including but not limited to clairvoyance, levitation, precognition, telepathy, telekinesis, and teleportation, when presented as real

How does it sound? Ahasuerus 15:54, 28 September 2017 (EDT)

Sounds good to me. I've always considered them science fiction. ···日本穣 · 投稿 · Talk to Nihonjoe 18:29, 28 September 2017 (EDT)

Or fantasy, if one (the reader or the author) doesn't believe in a scientific foundation; but that'd be speculative as well. Stonecreek 18:36, 28 September 2017 (EDT)

I would say that whether they are science fiction or fantasy depends on how they are handled in the text. For example, the psionics stories which Campbell promoted in the 1950s were science fiction because they were treated as science. (Some fans disagreed at the time, but they were outnumbered.) On the other hand, we also list many fantasy stories which feature psychic abilities. I think it would be best to add "Psychic abilities" as a separate Project Scope item as opposed to putting them under either "science fiction" or "fantasy". Ahasuerus 17:07, 29 September 2017 (EDT)

I agree - they are in scope except when the author actually believes themselves (aka real stories about psychic abilities)... Similar to how we deal with magic - we do not catalog all the "real magic" books. Annie 19:39, 28 September 2017 (EDT)

Why is Dion Fortune's fiction in the DB then? She considered mediumship and spirits to be factual, and said that some of her stories were fictionalized versions of actual occult experiences she's seen. --Vasha 16:40, 29 September 2017 (EDT)

Likely due to being fictionalized. ···日本穣 · 投稿 · Talk to Nihonjoe 16:49, 29 September 2017 (EDT)

That's right. What matters is the presentation -- i.e. whether the text is presented as fiction rather than as non-fiction -- not the author's intent. Richard S. Shaver believed in Deros, but we list his works because his accounts were fictionalized prior to publication. (Apparently Ray Palmer had quite a bit to do with it, but that's a whole different story.) Ahasuerus 16:57, 29 September 2017 (EDT)

With respect precognition, I would prefer some caveat to it being a major plot point or a significant element. Plenty of mundane works with characters that have a flash of precognition. However, I agree with the overall idea. -- JLaTondre (talk) 20:52, 28 September 2017 (EDT)

I agree that a mundane work in which a character has a "bad feeling" about something and then it comes to pass is outside the scope. I am not sure how we could best describe the difference, though. Perhaps something like precognition is "in" while vague premonitions are "out"? Ahasuerus 17:00, 29 September 2017 (EDT)

Also cases where characters or the author are convinced that ordinary coincidences are due to the hand of God don't count. There have to be blatant miracles. --Vasha 17:21, 29 September 2017 (EDT)

I agree, since IMHO the very existence of psychic abilities is speculative.--Rkihara 12:14, 29 September 2017 (EDT)

(unindent) Given the general consensus, I have updated the Policy page with the proposed text. I wasn't sure how we could best address the borderline cases discussed above, so I left it "as is" for now. We can further tweak the wording once we come up with a more precise definition. Ahasuerus 09:25, 2 October 2017 (EDT)

Murray Leinster Anthologies

There are 4 pubs shown as ANTHOLOGY that are called "double novels", one of which was written by Murray Leinster. Should these be more correctly be OMNIBUS items? Bob 10:30, 2 October 2017 (EDT)

I'd say so, if they really incorporate NOVELs. Stonecreek 10:46, 2 October 2017 (EDT)

Got it. They contain shorter fiction! Thanks. Bob 17:12, 6 October 2017 (EDT)

Format pb vs. tp

Recently, the problem of differentiating paperbacks from trade paperbacks as discussed nearly one year ago again popped up in the classification for European publications, see the second half of this discussion item. The European pocket books ('Taschenbücher') are the synonym for paperbacks; look at the Wikipedia article on 'Taschenbuch', then click on the left link bar of that essay on the English version and see that it leads to 'Paperback'. The philosophy of publishing is very similar (though not identical): both are published to fulfill mass market needs, but the pocket books on the average are a bit wider than paperbacks. I think there is no need to introduce more categories, but only to change one word in the rules:

The current rule for tps reads

For books as tall as 7.25" (19 cm) or as wide / deep as 4.5" (11.5 cm) use "tp"

The proposal is to change it to

For books as tall as 7.25" (19 cm) and as wide / deep as 4.5" (11.5 cm) use "tp" .

This seems to be enough to solve the problem, I'd think. (If some unusual book formats should exist [extraodinary tall but pb wide, or vice versa], another passage to use "tp" for publications as tall as 8" or as wide as 5" could be added, for example. Stonecreek 15:48, 17 October 2017 (EDT)

This will make the tall mass market paperbacks inconsistent in the DB (and probably other formats as well) - they are added as tp now, the new rule will make them pb. I am not against adding a format but changing the existing ones will create a mess. Annie 23:08, 17 October 2017 (EDT)

The limiting value of 8" was only an arbitrary proposal. I think there's no problem to change the limit tallness for unusual formats to 7.6" or 7.5". Stonecreek 23:36, 17 October 2017 (EDT)

Or even 7.25".

Since it's not the tallness but the width that is the problem, I'll make a new proposal:

For books as tall as 7.25" (19 cm) use "tp"; use "tp" also for books below this limit, but as wide / deep as 5". Stonecreek 08:42, 18 October 2017 (EDT)

Let me make sure that I understand the functional need correctly.

Historically, the limiting factor for US-published "pocket size" paperbacks, which we call "mass market paperbacks", was the size of the racks/bookshelves which retailers used to shelve them. For this reason their length had to be no more than roughly 7.1" (many 1950s and even early 1960s paperbacks were 6.3"-6.4") and their width had to be no more than 4.3". Anything taller or wider than that and your book couldn't shelved and therefore wouldn't be carried by retailers. UK-published "A format" paperbacks were roughly the same size.

So, if I understand the proposal correctly, the goal is to basically say "A mass market paperback is a paperback that fits inside a 7.24" by 4.4" box". Is that about right? Ahasuerus 12:16, 18 October 2017 (EDT)

Sorry, but no, I'd think that a mass market paperback is a paperback that has to fit inside some displaying box or shelf, without making a previous assumption about the sizes involved, except that it must not be too great, and we try to establish a limit that fits other mass market paperbacks (see Jens' commentary below); there's also the aspect of paper quality involved; the paperbacks or pocket books in Europe also started with pulpy paper, and are for that reason even more similar to American or British paperbacks. Stonecreek 14:21, 18 October 2017 (EDT)

In short, it's the idea of publishing easy portable, light & cheap books with thus a high print run that binds the mass market paperbacks of several nations. Stonecreek 16:31, 18 October 2017 (EDT)

As for Annie's remark that changing the existing rules "will create a mess": we already have a mess with lots of German paperbacks (Taschenbuch), because according to the current rules they should have been entered as trade paperback here but have been entered as paperback and are in fact a paperback. From my point of view these data are correct and the current rules simply don't fit German soft cover formats. So, instead of trying to fit everything into one rule for "tp" wouldn't it be better to add rules for each deviation from the current rule? Which means: leave the current rules as they are but add a rule for the German sizes for "pb" and "tp". "tp" would then mean the same for German publications and publications from other countries semantically but would take differences in production between countries into account. The same would be done for any other country with deviations in publication formats. Jens Hitspacebar 13:34, 18 October 2017 (EDT)

I still would prefer a rule that would fit all paperbacks, but if a rule of exceptions is preferred, then it shall be. Stonecreek 14:21, 18 October 2017 (EDT)

As we do really need a solution for the problem adressed, I'd like to change the rules according to the proposal

For books as tall as 7.25" (19 cm) use "tp"; use "tp" also for books below this limit, but as wide / deep as 5".

I don't see that this will lead to a mess since with it the 'tall mass market paperbacks' are well enclosed, aren't they? Stonecreek 16:37, 18 October 2017 (EDT)

That's a description of mass market paperbacks, not trade paperbacks. Trade paperbacks are larger, often the same size as most hardcovers but with a softcover instead. Mass market paperbacks = "pb", not "tp". ···日本穣 · 投稿 · Talk to Nihonjoe 16:50, 18 October 2017 (EDT)

You're right, let's make it For books at least as tall as 7.25" (19 cm) use "tp"; use "tp" also for books below this limit, but at least as wide / deep as 5. Stonecreek 08:42, 18 October 2017 (EDT)

I wonder if we could avoid some of the linguistic problems with "paperback" by changing this category from "pb" to "mm" or "mmp", as various other sites do, to emphasize that we are talking about the mass market paperbacks, and not other forms of "pb". (That, at least, could be done in a simple script substitution, and wouldn't result in hundreds of existing books being misclassified.) Chavey 21:21, 18 October 2017 (EDT)

Thanks Darrah! That sounds like a good idea, but wouldn't that need a change from the existing definition to one more in the lines of wikipedia's thoughts (taking paper quality into account)?

But are their actually hundreds of books being misclassified? Stonecreek 23:40, 18 October 2017 (EDT)

Well, thinking about it, there likely would be a lot of misclassified publications. So, it seems much better to create a 'rule exceptionnel' (or more) for other countries with their own definitions of mass market paperbacks, this would be 'For books at least as tall as 7.25" (19 cm) and at least as wide / deep as 4.5" (11.5 cm) use "tp". I'd also like to add a passage to mark paperbacks as tp, if their width equals (or is higher) than their height. Any objections to these steps? Stonecreek 14:53, 19 October 2017 (EDT)

I think I see what the goal of the proposed changes is, but we may want to find a way to phrase it that would be easy to understand. Perhaps we could start by listing a few sample dimension permutations whose classification would change? That way we would all have a clear view of the "before" and the "after" state of the data entry rules, which would help avoid ambiguity. Ahasuerus 00:11, 20 October 2017 (EDT)

It would be something like this: "Since the histories and dimensions for the mass market paperbacks are slightly different for different countries, there are the following exceptions:

German paperbacks / trade paperbacks:

1) 'For books at least as tall as 19.01 cm (7.25") and at least as wide / deep as 11.5 cm (4.5") use "tp" '.

2) 'For books as tall as 19 cm generally "pb" should be used'. except:

2a) 'For books as tall as 19 cm, but with a width equal or higher than the height "tp" should be used'. Stonecreek 00:27, 20 October 2017 (EDT)

Hallo Christian, Dein Vorschlag erscheint mir ausreichend um die Einstufungsprobleme zu beenden. Ich habe mir die beiden Diskussionen noch nicht genau durchgelesen, werde es aber noch machen, daher jetzt nur ein Hinweis zu den Umrechnungsfaktoren von Zoll in cm. Nach meinem Wissensstand ist 1" = 2,54 cm! Das heißt 7,25 Zoll sind 18,415 cm und nicht 19 cm. Alleine durch solche groben Ungenauigkeiten bei den Definitionen der Buchmaße kann es zu Unstimmigkeiten kommen oder ist es ein Schreibfehler?.

Google Übersetzung: Hello Christian, Your proposal appears to me sufficient to end the classification problems. I have not read the two discussions yet, but will still make it, so now only a reference to the conversion factors of inches in cm. To my knowledge, 1" = 2.54 cm, that means, 7.25 inch is 18.415 cm and not 19 cm, and there may be inconsistencies due to such gross inaccuracies in the definitions of book dimensions or is it a typo?.--Wolfram.winkler 03:19, 25 October 2017 (EDT)

No answer, sadly?

Format/binding - proposed software change

I have been rereading the "tp vs. pb" discussion and thinking about it for the last couple of days.

My tentative conclusion is that the root cause of our current problems is that we are using a classification system originally developed to catalog the realities of the US market (as it existed in the 1950s-2000s) to catalog books published in many different countries during different time periods. If you are familiar with US paperbacks published by print on demand internet-only publishers like Ramble House, you know that they can have unorthodox dimensions: the publisher doesn't have to worry about having them fit retailers' requirements. Add the fact that different countries can have different standards and it becomes clear that we are trying to "fit a square peg in a round hole".

The most obvious way to address this problem would be to add support for additional binding formats. However, it raises another issue. Currently we use codes like "hc", "pb" and "tp". The reason we use them instead of full descriptions is to make our Web pages more manageable. Some of them, like "audio CD", are self-explanatory. Some, like "ph" or "dos", are not. If we were to add even more codes to account for different permutations, it would make our pages even harder to read. It would also make it harder to use binding codes in Advanced Publication Search.

I'd like to propose the following solution to the problem. First, we can add mouse-over Help bubbles to all binding codes. We already use them for editing help and transliterated values, so our users are already familiar with them. It shouldn't take much too much time to implement the change.

Second, we can enhance the Advanced Publication Search page. Currently the search value field accepts arbitrary text. It works well for fields like "Author" and "Title", but it doesn't work too well for fields which allow only a small subset of values, e.g. Title Type, Binding, or Publication Type. We can change the software so that selecting "Binding" in the drop-down list on the left would make the right column display a drop-down list of all supported bindings. (Ditto title types and publication types to be consistent.)

Once we have made these software changes, adding new binding codes will become much more viable, at which point we should be able to revisit this discussion.

What do you think? Ahasuerus 14:40, 20 October 2017 (EDT)

I like the idea of making the binding abbreviations more self-explanatory and readable, but I think it's better if these abbreviations are replaced by their full description on the publication page if possible. If you open the drop down box in the editor you'd see "hardcover", "trade paperback" instead of "hc" and "tp" and so on. No "hc" and "tp" any more (similar to the change for story length some time ago when the items were changed from "ss" to "short story" and so on). The mouse-over bubbles could then be used for additional info like the max/min size of the chosen binding. Jens Hitspacebar 16:02, 20 October 2017 (EDT)

I agree that the Publication page has enough space for full descriptions unless we make them very wordy. However, the majority of bibliographic pages, which use the same "publication table display" software, are not so lucky. This includes the Title page, publisher pages, publication series pages, etc. Ahasuerus 01:12, 21 October 2017 (EDT)

I just tried and replaced the abbreviations on a title page in the "Format" column cells in my browser with labels like "hardcover", "trade paperback" and "German Paperback" and it looks good (16:9 monitor and browser in full width). "hardcover" is only a bit wider than the column header's label and the others word-break at the space. It only starts to look ugly if the browser window's width is too low or if there is a longer word without space. The solution might be to use the full description on the publication page only and a shorter description in the tables where the "Format" column appears - the same way it's done with the "type" column which uses "coll" and "non-fic" instead of the full word. Hitspacebar 03:57, 21 October 2017 (EDT)

An interesting thought. I guess we can start by adding mouse-over bubbles to all pages. Once they are available, we'll be in a better position to decide whether to expand the format codes on the Publication page. Ahasuerus 12:47, 21 October 2017 (EDT)

On a side note, there's a discrepancy in the field's label: it's "Binding" on the publication page and in the wiki but "Format" on title page, publisher page and so on. Jens Hitspacebar 03:57, 21 October 2017 (EDT)

Oh, I see. I think it was originally "binding" throughout. Once we added values like "ebook", "webzine" and "digital audio download", "binding" became too narrow and was supposed to be replaced with "format". I'll have to go back and find all remaining occurrences of "Binding". Unfortunately, it will have to stay "Binding" on all post-submission/moderator approval pages due to technical limitations. Ahasuerus 11:55, 21 October 2017 (EDT)

As for the original topic and your suggestion to add binding formats: I like the idea even more than the suggestion to add exceptions to rules. It's more self-explanatory than sticking to a catch-all binding like "tp" which would probably end with half a dozen exception rules for several countries. Additional bindings could also take language-specific differences better into account (e.g. the confusing use of the term "Paperback" - without "trade" - in German for trade paperbacks) and add this information directly to the item in the drop down box (e.g. German Paperback (Engl.: 'trade paperback')).

The list of bindings to choose from might become longer and longer due to this, maybe too long for some tastes. The software could, with the help of some JavaScript, make each drop down list searchable so that you can easily find the desired binding by starting to type it (something also nice-to-have for the "language" drop down list). Jens Hitspacebar 16:02, 20 October 2017 (EDT)

Re: "making each drop down list searchable", isn't that the standard browser behavior when displaying drop-down lists these days? Or are you perhaps suggesting using JavaScript to change the browser behavior from "find the first value which starts with the characters that I type" to "find the first value which contains the characters that I type"? Ahasuerus 12:34, 21 October 2017 (EDT)

It's the latter - finding anything that contains the typed-in characters. The standard browser behaviour is ok, but making a drop down box really searchable like this adds a lot of usability if you have long lists. There are out-of-the-box solutions like Select2, see here for a basic usage demo. It also on-the-fly shrinks the list of all items down to the items found in the list. Jens Hitspacebar 13:15, 21 October 2017 (EDT)

Thanks! Ahasuerus 12:44, 22 October 2017 (EDT)

I'm all for this enhancement. Did I get it right in assuming that we would in fact have some category like 'german paperback', and this special rule could be added to the help pages? Stonecreek 00:12, 21 October 2017 (EDT)

Well, the proposed software change will make it easier to add new formats. Once it's in place, it will be up to us to decide which ones to create and what to call them.

I am not sure names like "German paperback" would be ideal -- what if the same format is also used in another country, e.g. Austria, Switzerland or Luxembourg? And what happens if a different format becomes popular in Germany in a year or two? Perhaps we could find a different, more country-agnostic term. Ahasuerus 11:32, 21 October 2017 (EDT)

I don't like it either, it was just an ad hoc name; as some of the books are (or at least were) dependant from the European paper norms it is even likely that some countries will have similar formats. 'Pocket book' would come to my mind right now. Christian Stonecreek 11:58, 21 October 2017 (EDT)

(unindent) OK, so it looks like the outcome is that we will add mouse-over bubbles to all occurrences of the "Format" field and then revisit the issue. I am currently working on Fixer (Amazon's constant changes to their API throttling mechanism are a pain) and then I need to migrate our software from CVS to SVN. Once that's out of the way, I can start working on formats. Ahasuerus 12:47, 22 October 2017 (EDT)

When will it continue?--Wolfram.winkler 03:18, 13 June 2018 (EDT)

The software was changed to display mouseover bubbles for formats in November 2017. There was a follow-up discussion in April 2018. It introduced some new ideas like adding a field for "dimensions", but it was all very tentative and inconclusive. More ideas are always welcome! Ahasuerus 10:50, 13 June 2018 (EDT)

Once again an old suggestion is the distinctive feature softcover/hardcover and in the second step the dimensions length/width/thickness. With these data a format of a written book ist exactly described and everyone should be able to fill the database with these data.--Wolfram.winkler 03:23, 27 June 2018 (EDT)

Boxed Sets

Template:PublicationFields:PubType currently states that boxed sets should not be entered as their own record if the individual books have their own ISBNs. However, we have lots of these in the database so this no longer seems to be the practice. What are peoples thoughts on this? Especially if the box set has its own ISBN? -- JLaTondre (talk) 09:14, 11 December 2017 (EST)

I am not 100% sure that I remember the original rationale correctly any more, but I seem to recall that one of the examples given at the time was as follows:

Suppose a publisher miscalculates and prints too many copies of a trilogy. The management sells the leftover copies to another company for $0.10 on the dollar. The other company bundles the trilogy as a box set and sells it that way. Should we enter the box set as a separate publication?

I can understand the reasoning, but at the same time box sets can (and usually do) have a number of additional data elements that their constituent volumes don't:

• Price
• Cover art URL
• Cover artist
• ISBN

My tentative take on this issue is that when additional data elements are present, it makes sense to create a separate publication/title record. Ahasuerus 13:19, 11 December 2017 (EST)

Additionally, I'd say that if a box set contains items that were never available separately in that form (even though they each have their own ISBN) but only as part of the box, it should also be eligible for inclusion (this is an example) Jens Hitspacebar 13:32, 11 December 2017 (EST)

I don't have strong feelings about boxed sets, but I think especially if the boxed set has its own, separate ISBN, it definitely ought to be "in" as a publication in its own right. --MartyD 08:10, 12 December 2017 (EST)

Just curious how you would handle elements like page numbering? If you could link publications to a specific box set, you could define a container for them. Currently, omnibus implies a single binding. What publication type would this be?TAWeiss 09:03, 12 December 2017 (EST)

And Marty's view is the same with me.

The publication type would be OMNIBUS, what else?

And here's an example of a meaningful way to enter a boxed set / omnibus. Stonecreek 09:06, 12 December 2017 (EST)

I was looking at this pub. It contains four unknown printings of different publications. Other box sets could have different combinations of printings with the same ISBN. Would we track which publications are with a given box set? I would think it would be helpful to track that information as well. A box set with a different combination of printing would then be treated as a separate publication? TAWeiss 14:30, 12 December 2017 (EST)

I agree that they should be entered as separate OMNIBUS publications associated with the same OMNIBUS title. Ahasuerus 16:40, 20 December 2017 (EST)

(unindent) The consensus appears to be that we want to create separate OMNIBUS publication records for box sets which contain additional data elements, especially if the boxed set has a separate ISBN. How about the following wording:

"Boxed sets which have data elements that are not present in individual books that they collect (ISBNs, cover art, etc) should be entered as OMNIBUS publications. Boxed sets which do not have additional data elements and are merely bundlings of pre-existent books should not be entered"? Ahasuerus 16:40, 20 December 2017 (EST)

I'm good with that. Though I suggest moving "(ISBNs, cover art, etc)" after "data elements" in the first sentence so it's clearer what is meant. -- JLaTondre (talk) 17:31, 20 December 2017 (EST)

Yes, that part should be moved. Apart from that I agree with the wording, too. Jens Hitspacebar 18:21, 20 December 2017 (EST)

Good points. I have cleaned up the grammar a bit more and updated Help. Ahasuerus 21:37, 22 December 2017 (EST)

"Non-genre speculative fiction" in ISFDB:Policy

The "Inclusions" sub-section of the Contents/Project Scope Policy section under ISFDB:Policy is primarily a list of genres that our project covers: science fiction, fantasy, alternative history, supernatural horror, etc. However, one of the bullet points, "non-genre speculative fiction", is not an SF genre and may be confusing.

The original intent was to indicate that the database would include speculative fiction published by mainstream and other non-SF publishers. When the Project Scope Policy was first defined (May 2006), we didn't have the "non-genre" flag at the title level, so the meaning seemed clear. Now that the "non-genre" flag exists, I suspect that the phrasing may be confusing.

Since the next section of the Policy page, "Rules of Acquisition", already says that we include all works of speculative fiction "regardless of whether they are published within or outside the genre", I would like to propose that we simply delete the problematic bullet point. Ahasuerus 15:06, 23 December 2017 (EST)

Agreed that this would clarify things. --Ron ~ Rtrace^Talk 16:08, 23 December 2017 (EST)

Sounds good (and necessary). PeteYoung 04:59, 24 December 2017 (EST)

Sounds good to me Annie 00:47, 25 December 2017 (EST)

Sounds good. Jens Hitspacebar 04:27, 25 December 2017 (EST)

Approved by acclamation. Happy holidays! Ahasuerus 15:24, 25 December 2017 (EST)