Rules and standards discussions/Archive/Archive18

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

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

Clarify how to deal with unverified data added after primary verification

It repeatedly happens that we add, change or remove non-trivial data which doesn't come from a copy in hand to records which are already primary-verified, i.e. that an editor who isn't the primary verifier adds unverified (non-primary-verified) data to a primary-verified record. Possible use cases are:

The primary verifier is no longer active and external data sources now indicate that the primary verifier entered wrong data. An editor who isn't a primary verifier corrects the data based on these external data sources.
The primary-verified record's quality can be improved by additional data from external data sources, but the current primary verifiers don't care. Another editor who isn't a primary verifier adds the data based on external data sources.

After edits like this, and if there's is no hint in the publication note about unverified data, it appears that all data of the record are primary-verified. However, they are not: the data added or changed later are not primary-verified. In such a case, the record will be displayed as if everything is primary-verified and users will not be able to see that it contains unverified data. The PV system becomes a bit meaningless in cases like this.

I suggest that we add a rule to Help:How to verify data that the note must contain information about non-primary-verified and non-trivial additions, changes or deletions if the change is done by an editor who is not a primary verifier. I don't think it's possible to come up with one single phrase or template for that because of the many different ways the data can change. Therefore the rule should be like this:

If you are not the primary-verifier of a publication and make non-trivial changes to it, you must:

Supply detailed information about these changes in the submission note.
Add information to the publication note which must be phrased in a way that a regular ISFDB users will be able to distinguish which data is primary-verified and which unverified data was added or changed later. This information can be removed later if the record's data are checked by a primary-verifier again.

Example for the publication note: "The following data were added after the primary-verification was done and were taken from external data source xy: translator, cover artist"

Jens Hitspacebar 06:15, 28 December 2019 (EST)

I agree with the intent. We already have the requirement to document secondary sources scattered throughout the editing pages, but it would be good to also consolidate. I think though it would be better placed in Help:How to update a publication as that is more likely where people learning ISFDB would come across it. It can than be referenced in Help:How to verify data. I would also quibble with some of the wording. Non-trivial & detailed should be more specific. The secondary source should also be stated in the pub notes. It should also address cases where the changes are made by a subsequent primary verifier as we currently have no way to see the differences between edits. My recommendation is as follows:

If you are changing a primary verified publication (see Help:How to verify data):

In the "Note to Moderator" field, state what data has changed and why (examples: "corrected price based on publication", "added cover artist based on artist's website", "corrected misspelling"). This is needed as ISFDB's history function does not currently show the the pre- and post- edit versions of fields.

If you are adding data that is not from the publication itself, in "Pub Note" field, specifically state what information is from a secondary source. This must be phrased in way that makes it clear which data is not part of the primary verification and where that data came from (examples "Cover artist credit from first printing", "Price from publisher's website", "Publication date from Amazon").

Thanks. -- JLaTondre (talk) 09:33, 28 December 2019 (EST)

I also agree with intent. My 2 cents is that we (with this or later) cover the opposite - when you 'Primary' verify an existing unverified entry that contains information without source that is not evident from the copy. How should one identify the anonymous content? Do we sign any of these notations to allow traceback? Do the existing automatic loaders (e.g. / i.e. Fixer) provide their source(s) in the notes now? And as a final note, setting this as a standard will hopefully prove a) annoying enough, b) valuable enough and c) inconsistent enough that automatic logging becomes an obvious update of priority and value with a clearer guideline for implementation. ../Doug H 11:35, 28 December 2019 (EST)

I tend to follow the intent of Jens proposal when I update pub records. One of the things I'm doing lately (albeit not yet in a standardized nor rigorous way) - and which could be(come) helpful when formalized - is adding a note with either ' ...(added yyyy-mm-dd) ' or ' ...(modified yyyy-mm-dd) ' appended to it. In addition, I also tend to add ... as of yyyy-dd-mm. Adding a date will highlight that the data was added/modified either earlier or later compared to the PV date(s).

So you may want to expand the help text along the lines of

If you are changing or adding data to a primary verified publication append either ' ...(added yyyy-mm-dd) ' or ' ...(modified yyyy-mm-dd) '.

As to Doug's concern, and generally speaking, when I PV an as-of-yet not PV'd publication, I do away with what is already there and replace with what's actually on or in the book. While not covering the case Doug is describing, my experience is that the majority of 'old', unsourced/undated data, can be simply removed. MagicUnk 15:11, 28 December 2019 (EST)

Re:Fixer. He is not an automated loader - all his submissions are manually approved and notes adjusted if some of the data is not coming from the main Amazon record. So yes - in a Fixer originated pub, the details are sourced (and dated).

For the rest - good ideas above. They codify what some people are fully or partially doing anyway and describe the spirit of the project. Annie 15:34, 28 December 2019 (EST)

As for Doug's question regarding unsourced data: If I can't primary-verify them I usually try to keep them by checking with the data source mentioned in the pub's note, or by finding another external data source. If that yields no results I'll remove them. Jens Hitspacebar 10:47, 2 January 2020 (EST)

(unindent) JLaTondre's proposal is a lot better than mine, and, yes, Help:How to update a publication is the correct page. I like MagicUnk's idea as well. Compiled into one proposal it could read like this:

If you are changing a primary verified publication (see Help:How to verify data):

In the "Note to Moderator" field, state what data has changed and why (examples: "corrected price based on publication", "added cover artist based on artist's website", "corrected misspelling"). This is needed as ISFDB's history function does not currently show the the pre- and post- edit versions of fields.

If you are adding or changing data that is not from the publication itself, in "Pub Note" field, specifically state what information is from a secondary source. This must be phrased in way that makes it clear which data is not part of the primary verification, when that data was added or changed, and where that data came from. A date stamp in the format "yyyy-mm-dd" has to be appended to that data. Examples:
- "Publication date from Amazon (added 2020-01-02)".

Once feature request Make Moderator Note field required when editing PV'd publications is implemented it will help enforce bullet point #1. Jens Hitspacebar 07:37, 2 January 2020 (EST)

We should also be adding something along the line of

If it's an online secondary source, add the URL into the publication's Web Page multifield.

MagicUnk 13:57, 2 January 2020 (EST)

I also agree with the intent of the proposed change. However, it looks like the latest version of the proposal omits the original qualification that it only applies "if the change is done by an editor who is not a primary verifier". I would further qualify it as follows:

"If you are changing a primary verified publication and you are not its only primary verifier [snip]"

This language will require that you enter an explanation in the Submission Note field if the pub has other primary verifiers. Ahasuerus 18:44, 11 January 2020 (EST)

Yep, I agree. Providing notification of what has changed & source of the data & note + date is a very good rules enhancement. MagicUnk 19:06, 11 January 2020 (EST)

Clarify how to deal with unverified data added after primary verification -- Outcome

As per FR 1321, the software has been changed to make "Moderator Note" a required field when editing publications that have been primary-verified by users other than the submitter.
Template:ModNote has been updated to reflect the new functionality.
Help:How to update a publication has been updated based on the discussion above.

Ahasuerus 18:04, 12 January 2020 (EST)

Great, thanks! I had planned to bump the (unresolved) topic next weekend to see if we can get an outcome, but now we have one already! :) Jens Hitspacebar 16:27, 13 January 2020 (EST)

Ph.D., Dr.

We currently have 134 Author names with Ph.D. appended, 385 Dr. records,108 M.D. records, and 1 Ms. record! I don't think it belongs there, and propose to remove all titles from name records. If we want to keep titles, They should get their own field, no? Thoughts? MagicUnk 16:15, 4 January 2020 (EST)

If this is how people are credited, why would we remove it? Should we also remove Jr., Smith or III and how are they different from Ph.D.? Or should we ignore pseudonyms as well and just use legal names? We credit people per publications, not per legal name. If an author uses Ph.D. as part of their name, it belongs here as much as any other part of a name. Don't think of it as a title (as it is when they ask for your name on a form), this is part of the author name as used in a publication and we treat is as any other suffix. In case you had missed it, we do support quite a lot of suffixes: listed here :)Annie 16:27, 4 January 2020 (EST)

Ah, I did miss that one indeed :) But still, I find it quite strange to have a title considered part of a name (and the difference is that Jr. is not a title but part of the name proper, unlike titles - except if your name's Mr. T, of course :) MagicUnk 17:13, 4 January 2020 (EST)

Well, if someone credits themselves that way, who we are to tell them not to? We record what is on the book (With some minor formatting), we do not decide what it should be - and if it is there, we should not be ignoring it. That is why we have the legal name - that's where we insist on having the actual name but for the author name, "The author of X" and "Test, Ph.D." and "Potato Head" and "Colonel T" are all valid names if that is what had been used by the publication. Think of the whole name as one unit, not as a collection of a given name(s), last name and titles and what's not. :) Annie 17:23, 4 January 2020 (EST)

Annie's list is inaccessible for us non-moderators, but I'll offer Sir Arthur Conan Doyle as a reason to keep titles. ../Doug H 10:22, 12 January 2020 (EST)

Here's the list: "The list of currently recognized suffixes includes .com, .co.uk, B.A., B.Sc., D.D., D.Sc., Ed.D., Lit.D., Litt.D., M.A., M.B.I.S., M.B.I.F., M.D., M.E., M.S., Ph.D., P.J.F., R.I., U.S.A." ···日本穣 · 投稿 · Talk to Nihonjoe 02:00, 13 January 2020 (EST)

Prices in (Soviet) rubles?

So what was the outtake of Rules and standards discussions/Archive/Archive15#Prices and weird currencies - reading verification needed...? SUR 2.00 (the few examples in help suggest that SUR 2 would not be enough)? With the proliferation of Soviet SF last years, they would warrant explicit inclusion in Template:PublicationFields:Price, I think (as well as the issue of compulsory trailing zeroes). --JV jr 12:10, 14 January 2020 (EST)

I would rather keep all rubles as RUB regardless of the era they are coming from. And I would also prefer complete prices - so "RUB 2.00" for example. :) Annie 12:15, 14 January 2020 (EST)

Tall paperbacks

I've read all the archives I could find about this question, and I know the matter has been settled several times, but I'd like to raise the issue again. I feel that tall paperbacks should be classified as PB and not TP. I would be in favour of a separate classification for them, but that has been beaten to death several times and while some of the reasons (e.g. There aren't enough of them) seem to be dated, changing the maximum height of a PB seems to me to a reasonable solution to the problem. The primary reason for doing this is that publishers call them "Mass Market Paperbacks" and not "Trade Paperbacks". There is one listed on today's ISFDB.org home page, see this. The book is forthcoming, so no one has verified it yet, but when it's verified it will have to changed from PB to TP, using the current rules. We are going to see more and more of these books, since I suspect publishers are making more money selling a slightly taller book for $9.99 than a standard sized MMPB for $7.99.

Changing the maximum height for a PB from 7.0" to 7.6" looks fairly easy to me. Finding them in the database should be straightforward, as you can search for TP books costing $9.99 (and perhaps those costing $10.99).

I've read the recent discussion on sizes of European books, and noticed this issue mentioned in passing. I can't comment on the effect on those books since I don't own any of them. Sjmathis 13:40, 26 January 2020 (EST)

While changing the number is easy indeed, these had been added as tp (when someone was paying attention anyway) until now so the data will get even more inconsistent... And they had been around for at least a decade at this point. I am fine either way -- but if we decide to change, we may want to think about the existing records as well. One thing to be very careful about is thinking of ISFDB terms in terms of the external world. While a lot of things may have started with the idea to parallel them, the things had shifted and a lot of the terms are now our own only... And even a small change in that direction will send a lot of non-US books into new categories as well.

Other from that - I would agree that if there is one category we may want to make a special exception for, it is the tall mmpbs. Maybe even call them that way in the help page and just ask for a note to be added to the notes that it is a tall one when using pb for them... Although a tp of 10.99 and 9.99 is not necessarily a tall mmpb :) Annie 14:58, 29 January 2020 (EST)

PS: And that one did not have a size reported when I added it last year - I even looked because of the price... I've changed it to tp based on the now published size and added a note for now. Annie 14:58, 29 January 2020 (EST)

PS2: And then you have this - $9.99, regularly sized mmpb (for now). It's.... complicated :) Annie 16:16, 29 January 2020 (EST)

Which is why this needs to be addressed now, since the inevitable increase in prices will muddy the water even more. Amazon presumably gets book dimensions from publishers, and I don't recall seeing dimensions given very often. At the moment, while I don't think finding tall mmpbs in the database is very hard, as prices spread it will get harder. Some of us add a note to TP books that are actually tall mmpbs, so that will help, even if nothing else is done.

I'd be interested in hearing from non-US folks on the impact of such a change. Sjmathis 10:29, 2 February 2020 (EST)

Magazine Editors

I've been encountering submissions for magazines where the editor isn't specified in the pub, where the author is given as "The Editors of magazine name". The section for authors in New Pubs doesn't address this possibility, but I would prefer "uncredited" instead. What is the correct way to address this situation? Bob 11:51, 29 January 2020 (EST)

Genre or non-genre magazines? For non-genre ones, "The Editors of" is the expected format per the help page. :) Annie 11:58, 29 January 2020 (EST)

I do think you may mean for example this. I'd like to think it's okay to credit the editors with "The Editors of magazine name". To use 'uncredited' would mean that the editors are not credited, but it seems they are just unknown. Stonecreek 13:07, 29 January 2020 (EST)

But wait ... The editors are actually credited in the notes, that is strange! Stonecreek 13:08, 29 January 2020 (EST)

Yeah, the latter is an example of what I'm asking about. I understand the problem with non-genre 'zines. Thanks for the input! It seems to me that if the same form for non-genre is more generally acceptable, the New Pubs section should say so. Bob 14:42, 29 January 2020 (EST)

I wonder if the note does not mean that these are the editors of the magazine as a whole but it is unclear who of them edited this specific issue - not uncommon in the Eastern European magazines (and books) of the past - there is always a "editorial board" of a type on everything. Or maybe someone just did not feel like copying the names all over the place :) Annie 14:48, 29 January 2020 (EST)

I suggest adding the following to the New Publication Help Page as the third bullet under Authors: "Magazine and Fanzine Authors. Sometimes a magazine or fanzine, particular a non-U.S. publication, will not credit the editor or editors. The publication may have multiple editors, but not all of them are involved in one particular issue. Two options are permitted: “uncredited” may be used, or “The Editors of PUBLICATION NAME” can be used. If the editors are known, but none are credited on the title page, they should be listed in the notes if their names do not appear as “Editor”." Any thoughts? Bob 19:51, 10 February 2020 (EST)

The editor field cannot be left blank. The s/w requires it. -- JLaTondre (talk) 20:08, 10 February 2020 (EST)

Thanks. Noted and changed. Bob 12:01, 11 February 2020 (EST)

I would not make it optional. Ether the editors are not credited in the pub, or they are (in whatever format). For the former, uncredited is the way to go (since we record what's on or in the pub). For the latter case, I'd formulate it so that if it's clear that it's the editorial board that is listed in the publication (i.e. the editor(s) that did the actual work are not identified, but the board as a whole is), only then is it allowed to use The editors of 'magazine name' . If the actual editors are credited in the pub, then all should be listed, even if it's a boatload of them... Now there's still the case where there's a (large) list of editors listed in the pub and where you can't distinguish whether they're the editorial board members, or whether they've actually all contributed to the editing of the pub. I guess there you could go both ways...

And in any case, if editors are known but not printed, then the editor field should be 'uncredited' and it's left up to the ISFDB editor to list them in the notes (or not). Just my 2cents MagicUnk 13:46, 11 February 2020 (EST)

Thank you for your input. I understand and appreciate your points (I don't like options either), but I'd like to frame things clearly and concisely. How about this: "Magazine and Fanzine Authors. Sometimes a magazine or fanzine, particular a non-U.S. publication, will not credit the editor or editors. In that case, "uncredited" should be used. Or the publication may have multiple editors or an editorial board, but they are not credited on the title page. In that case, “The Editors of PUBLICATION NAME” should be used. If the editors are known, then they should be listed in the notes. If it is clear that all editors of the publication are not always involved with each issue, that fact should also appear in the notes."?

Welllll...no. Only if the editorial board -is- credited "The Editors of PUB..." should be used. If not, uncredited is still the way to go imo. So. I would phrase it something like this: "Magazine and Fanzine Authors. Sometimes a magazine or fanzine, particular a non-U.S. publication, will not credit the editor or editors, nor the editorial board. In that case, "uncredited" should be used. If the publication lists multiple editors, all should be recorded. If an editorial board is credited, or it is clear the listed editors are members of an editorial board and did, in fact, not all contribute to the issue, then “The Editors of PUBLICATION NAME” should be used, and the editors listed in the notes (if known). If it is clear that all editors of the publication are not always involved with each issue, that fact should also appear in the notes." MagicUnk 17:15, 19 February 2020 (EST)

I like your suggested working. Now all I need is to figure out how to enter it into the New Pubs section. Bob 20:10, 2 March 2020 (EST)

How to deal with multi volume publications

Regarding a recent rejection (I hope everyone can see this, it was discussed here). I was wondering why this was rejected. Our help screen only mentions boxed sets, not books sold together as a set, and the first volume of the set was accepted without discussion. Other sets like The Chronicles of Amber volume I and volume II (sharing the same BC number, and also published as a set) have never raised questions. It can't be true that such edits are accepted without discussion by one moderator and rejected by another. I would like some opinions on these questions:

How should we treat sets of books that are not in a box
How can we prevent the seemingly random treatment of submissions, depending on which moderator handles them

--Willem 15:21, 19 February 2020 (EST)

Good question. I recently had a similar situation where novels of a trilogy were sold separately, each with their separate ISBNs, and later sold as a set that got its own, new, ISBN. This was briefly discussed with Annie, and consensus was that case should be recorded as an OMNIBUS - so treating this case identical to how we treat a boxed set as being an OMNIBUS, next to having the individual novel pub records too. The case mentioned above differs in only one aspect in that (if I understand correctly) this particular edition of the distinct novels that make up the set do not have a separate ISBN each, but all share the same ISBN - making it in effect equivalent to the ISBN of an omnibus. So, Die Flußwelt der Zeit should therefore preferrably have been treated as part of a set and thus recorded as part of an OMNIBUS. But having it recorded as a novel on its own is perfectly legitimate per the rules afaik. However if I knew they were only ever sold as a set, I wouldn't do it myself. If the rules are to be clarified, it should be updated to make it clear that any combination of works sold together (whether bound in a single publication or separate as a (boxed) set doesn't make a difference), are to be treated as an OMNIBUS. I wouldn't object having the consituting novels recorded separately as well - even if they were only ever sold together. After all, that's not so much different from boxed sets that contain volumes with separate ISBN's that are oftentimes also recorded separately, whether they have been previously separately published or not (see this and this example). Do note that novels split in multiple volumes are treated differently; currently we're varianting the individual parts to the full, original novel - whereas they should be SERIALized (and yes, I do know that this is not currently allowed per the rules), but that's another discussion ... MagicUnk 16:55, 19 February 2020 (EST)

As I rejected this one, here are the reasons: the books were initially sold as a set (most likely sealed into a foil, but a box still seems possible). There is only one price for the set of four books (if accepted singularly, we would have four books with a price of DM 39.90, implicating a total price of DM 119.60 for all four publications, when it was in fact only the lower one). And - as stated above - the set only has one ISBN.

I take that we do record what was initially published, not what was afterwards plucked apart and sold separately by second hand vendors. Stonecreek 23:26, 19 February 2020 (EST)

Let me add some background information to clarify why Template:PublicationFields:PubType says:

Boxed sets which do not have additional data elements and are merely bundlings of pre-existent books should not be entered.

This sentence was originally added to account for the following scenario. Sometimes retailers take separately published books, put them in a cardboard box (or just tie them together with a string) and sell them as a single unit. This can include:

Books in the same series, e.g. Star Wars or Asimov's Foundation
Books by the same author, e.g. unrelated books by Stephen King
Books with the same theme like space opera or vampires

The idea behind the current Help text was that we didn't want to create OMNIBUS records for these types of artificially created bundles. There are millions of ways that books could be combined at bookstores and it can be completely arbitrary.

I think the idea still has merit in 2020. I don't think the recent proliferation of electronic "boxed set" affects the logic: the decisive criterion is whether a boxed set was created by the publisher or by a third party. That being said, if we can clarify the Help sentence, I am all for it. Ahasuerus 11:47, 20 February 2020 (EST)

Yes, so the rules do tell us that a "publication may be classified as an omnibus if it contains multiple works that have previously been published independently" - exactly what is the case here. A publication like that containing two or more novels is an OMNIBUS for our little database. Stonecreek 02:41, 21 February 2020 (EST)

So the arguments in support of making this (and similar) book sets an OMNIBUS, as I understand them, are:

They were published as a set, although whether it was originally a boxed set is unclear
They have the same publication date and the same publisher
They have the same ISBN
They were not priced separately; only the whole set had a price associated with it

On the other hand, the argument on the side of making them 4 separate NOVEL publications is:

Similar sets have been treated as separate NOVEL pubs in the past, at least in certain cases

Any other arguments in support of the second approach? Also, if we adopt the first approach, then where do we draw the line? For example, what if the books are published as an "unboxed" set, but have separate ISBNs and/or separate prices? Finally, do shrink-wrapped sets count as "boxed" sets for our purposes? Ahasuerus 11:42, 21 February 2020 (EST)

My main purpose for raising this subject was to avoid random treatment of submissions, which is confusing and annoying to the submitter. Clarification of the rules is for me the first priority.

If we do treat shrink wrapped or string tied sets of books as type OMNIBUS, just because the books were sold together as a set (on the same date, with one common ISBN), this will lead to very complex situations and practical problems. The "Chronicles of Amber" set I mentioned above, would be an OMNIBUS containing two OMNIBUS titles (which is now forbidden), and I can imagine the 44 volume Vance Integral Edition being reprinted as a single set someday. Also editors who own only one of the pubs in the set can't do a primary verification (again see the "Chronicles of Amber" set, volume 1 was verified by Dragoondelight, volume 2 not. Obviously I'm in favor of treating these as individual publications.

Also I find it disappointing that so few editors/moderators express their interest in subjects like this. It may lead to a "consensus" of two against one... --Willem 16:53, 21 February 2020 (EST)

If they got an ISBN as a set (and not just shared ISBN across books), they are an omnibus for us - regardless if they were tied with a bow or put in a box or just published in one single paper body. If they were published as a set, we treat them as a set. It can get tricky separating "published separately but marketed as a set" from real sets but... I would rather opt on the side of inclusion. And there is a special case where multi-volume editions share ISBN but each book is priced separately and they were never sold together until the last volume was out. E-books are kinda easier for that - one file comes in - it is an omnibus; multiple files - it is not.

So for these above? If I am not sure, I would rather have them than not - noone says we cannot add both the set AND the individual novels if we know they were sold both ways and add notes to both with an explanation. :) Annie 17:05, 21 February 2020 (EST)

I couldn't have said it better :) I too think it is best to record both the individual novels, as well as the OMNIBUS for a 'set' they belong to provided the novels of that set can be identified as intended to belonging together. The cases we've identified so far are:

A set of previously separately published novels with individual ISBN's (and prices), and an ISBN for the later published set; the set can be boxed, or not boxed (this and this example)
A set of novels not previously published, having all the same ISBN (the Die Flußwelt der Zeit case)
A set of novels not previously published, with different ISBN, and the set having a separate ISBN (I -think- this is an example)

The bundling and thrown together stuff that Ahasuerus is referring to above is still excluded because just being eg shrink wrapped together is not sufficient proof of the books belonging to a set. For these to be eligible to be entered as an OMNIBUS, you'd have to have additional evidence they are published as a set, for example when stated by the publisher (borderline, but still...). It's actually nicely formulated above: sets which do not have additional data elements and are merely bundlings of pre-existent books should not be entered. Additional data elements can be 'member of a set-with-ISBN', stated by the publisher,... MagicUnk 17:48, 21 February 2020 (EST)

Agreed. Keep the exclusion for bundling of pre-existent books without separate identifying data. But otherwise, we should enter both a true set and the individual books. If someone has a book in hand, they should be able to find it in the database. This is especially true in the case when the books have individual ISBNs. Notes can be used to explain the relationship between the records and handling of issues like the individual books not having prices. -- JLaTondre (talk) 19:44, 21 February 2020 (EST)

The perfect solution for me! --Willem 15:22, 22 February 2020 (EST)

Let me make sure that I understand how the proposed approach would work. In the case that prompted this discussion, we would have 5 publication records with the same ISBN: 1 OMNIBUS pub record and 4 NOVEL pub records. Only the OMNIBUS record would have a price associated with it (?) The Notes field would explain the details. Is that about right? Ahasuerus 18:06, 22 February 2020 (EST)

Well, this seems to be nearly the consensus, but not exactly. The one all have agreed to (including me) is the one that Annie formulated, meaning publications that we know were sold both ways (as a bundle/omnibus and as single volumes). The case that prompted this discussion was (as far as we know) issued only as an omnibus. Stonecreek 18:19, 22 February 2020 (EST)

Consensus to date has been individual volumes are always allowed and sets are only allowed if they have an unique identifier. That consensus is clearly seen in practices to date (it is why we have individual records) and that the only exclusion in the rules is for sets without unique identifiers. Your decision to reject an individual publication (which is what started this discussion) does not unilaterally create a new consensus. If you want to restrict individual volumes, you need to show consensus for that and there is clearly not that. Annie and you appear to be the only two arguing for that. -- JLaTondre (talk) 08:21, 23 February 2020 (EST)

Well, all of the comments following Annie's proposal (which is, by the way, in perfect consensus with the rules written down, and was as such in no way questioned by me), applauded her wording. And if you read carefully: the set in question has only one unique identifier (the ISBN), and only one price for the set of four novels. Stonecreek 08:54, 23 February 2020 (EST)

Say what? Ahasuerus, MagicUnk, Willem H., myself, & you were the only subsequent commentators. Ahasuerus has not expressed an opinion. MagicUnk and Willem H. have expressly agreed with my opinion. Also, editing my statement to introduce a typo[1] is incredibly poor etiquette. -- JLaTondre (talk) 11:04, 23 February 2020 (EST)

[unindent] Why not make it simple, and allow for both the individual novel, as well as the omnibus exist next to each other, even in the case where they have ever been sold together? I refer to JLaTondre's statement ...If someone has a book in hand, they should be able to find it in the database..... After all, there's no guarantee that these books will stay together indefinately, and an editor that have only one novel of the set in hand may honestly believe it's a single pub. How would he know, unless editors that do know have already added the novel and the omnibus, and provided sufficient info in the notes field to make the connection. And besides, if not in the rules per se, it's the most common practice today anyway, i believe. MagicUnk 05:01, 23 February 2020 (EST)

You likely mean that someone wants to find a novel she/he owns. That's quite easy, I'd say (at least as easy as we can guarantee in the rather complex world of publishing).

We are a publication-based db, and we record just that: publications. Recording things that never were published would counter our founding idea. Christian Stonecreek 07:11, 23 February 2020 (EST)

No, it is not easy. Especially for an average user (which is what should be considered here, the majority of our users are not familiar with our odd cases). If I have a book from a set, it has it's own ISBN (separate from the set's) and it's own cover (where the set has it's own slipcase, etc.), under your approach it will be impossible for the average user to find. An ISBN search will come up blank. If the user goes to the title record for the novel, they won't see the artwork. The user would have had to known the volume was sold only as a set which is not always clear. Your proposed change would make this much more difficult for the average user. Publication is an overloaded term. It can refer to the act of publishing or an individual book. -- JLaTondre (talk) 08:21, 23 February 2020 (EST)

Repeat (see above): the books in question don't have their own ISBN! Stonecreek 08:54, 23 February 2020 (EST)

Irrelevant. We have to deal with both cases (as this discussion has been doing). Users still should be able to easily find their books in the database. You appear to be advocating for a position that does not take into account whether the books have an ISBN (and only as to whether a publisher sold them individual or not) so trying to sweep this case under the rug is misleading. -- JLaTondre (talk) 11:04, 23 February 2020 (EST)

On the contrary: looking for the book in question per ISBN one would not find a single but four of them (each of them priced DM 39.90, which was in fact the price for the whole set)! The hypothetical user would thus be puzzled even more, and not informed that what she/he has in hands was in fact only published as part of an omnibus. Stonecreek 11:11, 23 February 2020 (EST)

It would help the discussion if you actually engaged with the opinion of the other side[2] instead of using scenarios that in no way reflect the other person's position. -- JLaTondre (talk) 11:18, 23 February 2020 (EST)

It would be helpful even more if you'd keep to the jurisdiction you ststed before: I do cite from the reactions on Annie's proposal: I couldn't have said it better, Agreed. (you may remember that one) and The perfect solution for me! Stonecreek 11:22, 23 February 2020 (EST)

You may wish to reflect upon the fact that you are now at the point of trying to tell me what my own statement meant. Indent levels matter (i.e. my response was not to Annie) as well as the whole post instead of cherry picking one word. Willem H. can confirm his intent, but his response was indented under mine so the default assumption is it was to my post. MagicUnk's subsequent post[3] re-iterated what I stated. -- JLaTondre (talk) 11:48, 23 February 2020 (EST)

(Unindent) This is starting to get ridiculous. Will having the individual books and the omnibus here harm anything? No. If someone has only one of the volumes, would they expect to find it here? Yes. So include them. Apparently everyone but Stonecreek understood my comment above - the “if sold both ways” qualifies when to add the box set / whatever - not the individual books. My comment makes it clear that I am on the side of inclusion and if read completely even says that we can always add both. I am Stil to see a single argument of why we should not allow both. Annie 14:09, 23 February 2020 (EST)

I wonder how my statement (perfect solution) can be read to be about anything else than JLaTondre's proposition (enter both a true set and the individual books). Ahasuerus summed it up perfectly, right below my comment. --Willem 14:12, 23 February 2020 (EST)

(Unindent) Annie, you'll have to concede that the formulation if we know they were sold both ways has to lead one to the assumption that they have to be sold both ways (as single volumes and as an omnibus) to have both versions included! And Willem, because of the use of indentions you'll have to concede it may be difficult to decide on which statement you refer. Okay, let's include the whole lotta of the volumes. Christian Stonecreek 02:45, 24 February 2020 (EST)

Reading through all the comments, there's something that I still don't understand; why would a novel that has been published as part of a set is only a publication if it has at some time in the past (or future) been published separately? And why would it not be a publication if it never had been published separately? (and what if it would be separately published in the future?). I really don't understand the reasoning behind that; I look at the set, I see three books that have been published by the publisher... MagicUnk 12:02, 24 February 2020 (EST)

The initial publication as single volumes was with a different publisher: Heyne bought the rights and published them in its series 'Heyne SF & Fantasy'. Bechtermünz later decided to (or was licensed to) publish them as a set, with one ISBN and one price for the four of them. At this time (or in the then future) there hasn't been a separate publication by Bechtermünz of the single novels. (But if so, this would mark a different publication that would have to be treated in a different way). The only thing we don't know about the publication was its form: has there been a box, or were they bundled in a different way, e.g. plastic foil or paper wrapping)? Hope that helps. Christian Stonecreek 00:09, 25 February 2020 (EST)

Ah, I see what you are doing. You are only considering the set, not the constituting novels, which is incorrect and too limited an interpretation of publication. It's not because they've been published together that they are not publications. Look at the individual novels as child publications of the set; they are still publications eligible for inclusion. MagicUnk 11:56, 25 February 2020 (EST)

But that's not the correct definition of publication: what else should a publication be then that what a publisher decides to publish. And Bechtermümz published only a set of four novels. What do we do if we find out that the four novels were issued in a box? Then we set out to revert the whole process? Also, we'll still have one ISBN for four different novels (and one, incorrect price for a single copy). Christian Stonecreek 12:22, 25 February 2020 (EST)

No no, the individual boxed novels should remain as a separate entry - no need to revert anything. And no, the price should not be recorded at the individual novel's records, but only on the set (OMNIBUS) level. MagicUnk 12:25, 25 February 2020 (EST)

To answer Stonecreek, the four books were NOT released in a box. They were in plastic foil, but that is long gone! --Rias Zlan52 19:41, 25 February 2020 (EST)

Thanks for that info! You might want to add it to the entries: that would be helpful! Christian Stonecreek 02:54, 26 February 2020 (EST)

Having the same ISBN for sets of books is not uncommon - even when they were sold only separately (or only as a set or anywhere in between). Having the individual novels won't harm anything and when someone finds just one on the secondary market, they will find them here - as opposed to needing to know that they were a set so they can track them down. Add the set, add the novels. Price go to the set (if the novels are not priced separately), ISBN goes to all of them, notes go to the publications notes (about the ISBN and price situation) to explain the case. Problem solved. Let's not make that more complicated than it is or should be.

The guiding idea should be to make it possible for someone using the DB to find whatever they need here; hiding information 3 levels deep is counterproductive and against the spirit of the DB. :) Annie 20:02, 25 February 2020 (EST)

I do think it's more complicated / puzzling to have five publications instead of one. It may be true that an owner of a single book may find it here, but so would he also with one entry (searching either by title, publisher, or ISBN), what the owner is likely not to be made aware of that it's in fact part of an OMNIBUS (at least with a superficial look - you will have to dig deeper to get a correct picture). Christian Stonecreek 02:54, 26 February 2020 (EST)

Not true if you ask me. It's no different than having to dig deeper into a regular omnibus if you want more detail (for example when you are curious in what other publications that novel has appeared). For the current case, having both novel & omnibus pub records, clicking on the novel title (from the pub record) will show the OMNIBUS pub record, whereas in your example (not having the actual novel) would not allow a user to find the novel and start from that pub record (would have to go to the title record first) (granted, not a big difference). The notes in both the novel and omnibus records will explain the particular relationship between novel and omnibus, and vice versa. So, in practice it's not an issue at all. In fact, it's easier for the user to find what he/she is looking for if both levels are present. MagicUnk 04:39, 26 February 2020 (EST)

Some of you talk about adding the set. Question, under what title? There is no omnibus title, only four books with their own titles. In the notes of the four individual books comes information about the set of four, the price, and the ISBN. --Rias Zlan52 04:48, 26 February 2020 (EST)

Argh... good question. Two thoughts: it reinforces the need to have the separate novels as pub records in the DB; secondly, we'd have to 'invent' a title if we want to have the OMNIBUS record to tie them all together - but bleh, that's messy :( MagicUnk 12:30, 26 February 2020 (EST)

We do have a rule for naming editions which contain more than one book but do not have a common page (the dos-a-dos books for example): "Novel 1 / Novel 2 / Novel 3" and so on. So if added as an omnibus, we know what title to use.

The rule in question: here: Omnibuses. If the book you are entering is an omnibus, it may have multiple title pages, one for each novel it contains. In these cases, if there is an omnibus title, such as "SF Special No. 33", enter that. Otherwise enter the individual titles, separated by a slash between spaces, like this: "Conan the Conqueror / The Sword of Rhiannon". :) Annie 13:30, 26 February 2020 (EST)

Right. Should have remembered that :) Perfect solution. Thanks Annie! MagicUnk 03:54, 27 February 2020 (EST)

Okay, the discussions seems to have died down :) rereading the above discussion, I conclude that there is a consensus to allow sets (both boxed & unboxed) to be recorded as OMNIBUSes, as well as their constituent novels. I propose therefore to rename the Boxed sets entry in the publication type help text to just plain Sets, have an extra level with two entries: boxed set and Other sets, and expand the clarification as discussed above. Anyone objecting against me having a go at the help text and come up with a proposal? MagicUnk 05:12, 28 February 2020 (EST)

(Unindent) Uhmmm, very sorry, but yes. There still does remain one aspect not considered until now: we also have some statistics to care for (here: the publication statistics). Those may not be of much interest for the general user, but are for the background picture and for those that rely on us on dependable figures (some of those lurk among us, I fear).

In the case that ignited the above discussion we would count not two publications (because of two set printings in 1996 and 1997) but ten (two OMNIBUSes and eight NOVELs); if you think of the physical book you have in hand as publication (which it ain't - it's a copy) you will count it two times. And for the years in which some publishers specializing in sets are more active than in other years this will seriously distort the figures for those years. Christian Stonecreek 12:28, 28 February 2020 (EST)

We do not have every single book in the world, we record only some printings (if I am adding printing 46, we rarely have the previous 45)... so the numbers while useful are not complete anyway and are not usable for comparisons. And if that is such a problem, we can solve it by deciding how we do the counting instead of not adding books we want here and which make the DB more complete. How we display/calculate data and how we collect data are two very different things and making decisions on how we collect it because of how we show it is not a proper DB usage -- we are not just a site somewhere - we are first and foremost a DB. Just saying :) Annie 12:53, 28 February 2020 (EST)

Not to mention all the 0000-00-00 reprints which already distort our data immensely - even when we have a year range, we will use 0000-00-00 because we do not know exactly. The stats number show what we have recorded for a specific year; not what was actually in this year. And again - visualization can always be changed. Annie 12:56, 28 February 2020 (EST)

0000-00-00 reprints don't go into the statistics at all (and that's correct if we don't know the year for sure).

My believe is that we strive to get all the printings, it's an ultimate goal that we try to achieve. That we still haven't met this end and that we have publications without a known year should IMO be no reason to introduce an unnecessary deformation. Christian Stonecreek 13:09, 28 February 2020 (EST)

And yet everyone else in this discussion believes that these will be useful for the DB. You may want to stop and reflect on that and think on why that may be - believe it or not, you are not the only one who cares about the data around here or had thought about the repercussion of allowing these in - both to the stats and to other numbers we calculate. Your main argument was "the publisher will look more active in certain years". I pointed out why this does not change what we have now -- and the 0000-00-00 not being counted distorts how "active" a publisher is in a year more than these. :) Annie 13:36, 28 February 2020 (EST)

Other voices only seem to have taken into account a possible benefit for the average user, not the implicated disadvantage in the overview. At the level of complexity we have achieved, it ain't easy to have all the perspectives in view (I for one hadn't in this case). Christian Stonecreek 14:50, 28 February 2020 (EST)

Well, here's a voice that thinks the effect this will have on the statistics is close to zero. The benefits of being able to find the publications are way bigger than this slight disadvantage. --Willem 15:58, 28 February 2020 (EST)

Proposal

It looks like the high level proposal that has come out of this discussion was, as per MagicUnk's comment above:

to rename the Boxed sets entry in the publication type help text to just plain Sets, have an extra level with two entries: boxed set and Other sets, and expand the clarification as discussed above.

Would anyone like to come up with the new Help language and post it here for review? Ahasuerus 12:38, 29 April 2020 (EDT)

Under this new level, will digital box sets count as box sets or as other sets? They are often indistinguishable from regular omnibuses (they arrive in a single file). Annie 13:28, 29 April 2020 (EDT)

Please ensure the wording covers pre-ISBN scenarios. ../Doug H 09:58, 30 April 2020 (EDT)

'Split' Omnibuses

In this record, the 'split' novel concept has been applied to omnibuses. Is this something we want to do? I can understand the desire to group and bring some order to the multitude of omnibuses in a series like this. But unlike the split novel case, the final omnibus (the one containing all volumes) was published last, not first so this just seems odd to me. We have a lot of series with differing omnibuses size so we should be consistent in how we handle them. Either do it for none or for all. -- JLaTondre (talk) 09:09, 22 February 2020 (EST)

I recently ran across the same thing for a set of Jules Verne works. I used a publication series to bring them together. But then again, the volumes were printed in about 8 different editions so the Edition d'Amiens will have siblings someday. ../Doug H 10:00, 22 February 2020 (EST)

Doug, this may be problematic: per our rules A Publication series is a group of publications marked out by the Publisher in some way, meaning that if the publisher didn't mark this series, it should not be in our system. Christian Stonecreek 19:21, 22 February 2020 (EST

Just to close this loose thread - the publisher states these volumes are part of the "Edition d'Amiens". There are eight different named editions, with different binding and number of copies printed. I've used the publisher's edition name as a publication series name. They titled all the volumes the same way, the volume number is buried on a different page than the title page, so I used their title and added their volume number to distinguish them. If I find and enter another edition, each volume will be another publication under the same title with a different publication series. I don't think this has any bearing on the discussion below, except that it begs the question of whether every Verne omnibus should be a variant of this masterwork set? ../ Doug H 21:35, 25 February 2020 (EST)

You mean in the similar way how using a rule specifically for novels is problematic when applied to omnibuses? :) Or does establishes practice count as a practice only when you want it to? If anything, using a pub series here is useful, harms nothing and does not create confusion and has enough precedences in being used that way. Extending the novels rules does make a mess of our organization principles. Please do not delete the pub series that Doug created. Annie 21:59, 22 February 2020 (EST)

Looks like another Stonecreek solo adventure, judging by this discussion. I'm getting very tired of this changing other peoples work behind their backs. Needless to say I don't agree with this. --Willem 10:55, 22 February 2020 (EST)

The split rule applies only to novels for me - and is written that way as well. If we apply to collections and omnibuses, we will end up with all of them in one title for some authors. Which will make our title record essentially useless. Annie 12:04, 22 February 2020 (EST)

Sorry, but this ain't true per our established standard. We have many anthologies and collections that for example were published first as hardcovers and split for paperback publications into two or more parts (but - out of your general attitude towards our project - you, Willem, will likely be tired of this idea also, and, needless to say, don't agree with it).

The idea for this 'super omnibus' was analogous.

Odd as it may seem at first glance, we also have some cases where a book-length title was first published in more than one part (each also of book-length) and afterwards in one volume. And for an overview of the series this organization of the series seems more pleasing to the eye than it was before with a non-existant organization of the omnibuses. That said, another way of organizing them would be a numbering, but this seems to be a more difficult task to me (for example which no. the 'super omnibus' should be assigned). Stonecreek 18:43, 22 February 2020 (EST)

It is in direct contradiction to the written rules (they are specifically for novels) and any logic though. It may be the accepted practice in your practices but it goes against the policies and established usage of the site. The rule is for novels because the work there is one work. Collections and omnibuses already have parts and the variants should be based on contents, not collection/omnibus titles. And lumping them this way does not make sense - the first 5 volumes omnibus is as much half of the full 10 novels as it is an omnibus of the omnibuses that contain the first 2 and then novels 3-5 fro example. Would you advocate to make all those variants? Because this is where your logic leads. If a Bulgarian publisher decides to publish the first 5 novels together and then split the rest in 2 more books, why should the 5 novels one be a variant under the 10 novels one while the other 2 not? Because the 5 volume omnibuses should be together - they are the same content. That makes our dB useless - you need to dig 3 levels to find out what you actually have - needing to dig 3 levels down to find what you need is not a way to organize things. :) Annie 21:52, 22 February 2020 (EST)

Well, I said that I see another possibility - and it may even be bette::::::::::r if one can work out a more pleasing way of organization.

If the rules are viewed as only valid for novels (which I doubt: a specification is exactly that, it doeesn't rule out other, similar possibilities - in this case because split novels seemingly irritated many new editors) would mean we have to discuss how to deal with the other title types that were split for different publications & verified by a mass of editors. Christian Stonecreek 07:01, 23 February 2020 (EST)

Please read the last bullet of Template:PublicationFields:PubType and this section of the FAQ. The rules clearly only address novels. As for omnibuses, they not are split works. They are grouped works. The individual items were first published individually and then grouped in different amounts as more items were added to the series. I'm not seeing how your approach for omnibuses helps the average ISFDB user. -- JLaTondre (talk) 08:34, 23 February 2020 (EST)

Repeat: if that's so, what do we do with the many cases like this one? Stonecreek 08:57, 23 February 2020 (EST)

Because practice and the written rules do not always agree. If you want to open a discussion about collections, then you are free to open a new discussion talking about them. This discussion is about omnibuses which are not "published as a single volume, and then republished ... as two or more separate volumes" so even if we accepted the split rule applied to non-novels, it would not apply to the omnibus case. -- JLaTondre (talk) 11:09, 23 February 2020 (EST)

Just wanted to make clear that the specification for novels ain't making this a possibility that only is valid for novels. You somehow have got to decide which statement is valid. And as stated above, if somebody has a better idea of organzizing this series, I'm all open ears (or: eyes). Stonecreek 11:27, 23 February 2020 (EST)

The biggest problem here, is that if you Christian think of something that's not in the rules (be it the dating of variant art titles or a new way of organizing omnibuses or whatever) you start acting without sharing your insight with the community. How dare you question my "general attitude towards our project". You are the cause, time and again, of these unnecessary discussions, because you refuse to seek concensus for anything before acting and your stubborn behavior forces people to spend too much of their valuable time convincing you that you'te wrong. --Willem 14:27, 23 February 2020 (EST)

Well, at least this was discussed with MagicUnk (see above at your own post), so it's misleading to state that this wasn't discussed. And as stated above: if an approach (splitting titles for different publications) is used for nearly any kind of book-length title (NOVEL, COLLECTION, ANTHOLOGY, NONFICTION), and is outruled nowhere, why should one assume it has to be discussed firsthand in the community for OMNIBUSes? The reason for my action on OMNIBUSES in both recent cases were just the written rules. There's nothing in them for not-singly published books not to be handled as OMNIBUS (the phrasing in them makes no difference for the form of publication), and the reason for establishing a parent OMNIBUS I just have decribed. Christian Stonecreek 02:57, 24 February 2020 (EST)

Be aware that the discussion that is being referred to is two years old, at the time I just started out not knowing anything... just sayin' MagicUnk 12:15, 24 February 2020 (EST)

Your attitude I refer to, Willem, is the impression one gets that you start a major project and cop out of it, that you are seemingly got out of the daily businesses of moderating other people's submissions and bettering the data quality in our core business of speculative fiction (and instead criticize people who are active in both fields). If that's a false impression (for example because of limited time on your side), I'd like to apologize. But it's also not so easy for me to get accused of not communicating (a two year old case that was communicated with MagicUnk), or implicating I weren't following the rules with OMNIBUSes (when the splitting was used in nearly any kind of book-length title and there's nothing outruling this possibility).

Artwork is only a side aspect of ISFDB and the rules for it are (or were) more loosened: for example it's possible to credit artists that aren't credited within a given publication. My action on it was carried out in the same spirit (when was a work of art first published) and in the assumption that art isn't done in language but in colour and black & white. Christian Stonecreek 00:48, 25 February 2020 (EST)

BUREAUCRAT NOTE: I think this discussion has veered off in a damaging direction. A certain amount of controversy is probably inevitable when discussing policies and procedures, so I try not to interfere when ideas are freely exchanged here. However, questioning other editors' commitment to the project is crossing a line. Let's stop it before it further damages relationships between editors.

A few months ago I promised to pay more attention to Wiki discussions. This is my first attempt to find a better balance between a "hands off" approach and stifling discussion. Hopefully, we can get the balance right. Ahasuerus 12:56, 26 February 2020 (EST)

Thank you Ahasuerus. I had decided not to comment on this subject anymore. My opinion is clear enough. --Willem 14:11, 26 February 2020 (EST)

You're right. It's really better to keep accusations of a personal kind out. I am more than willing to do so. Christian Stonecreek 23:21, 26 February 2020 (EST)

As the consensus was against applying the split novel concept to omnibuses, I have broken these back out. I grouped them under a sub-series (Amber Omnibuses). -- JLaTondre (talk) 13:48, 8 March 2020 (EDT)

That's fine with me: after all, it was just one idea to have the omnibuses set apart. This one is better. Christian Stonecreek 14:14, 8 March 2020 (EDT)

Extending the "Content" field to collections

Now this field is only for omnibuses. But more and more series consist of only novellas and shorter works (called novels occasionally but falling under the 40K words count) and that is even more pronounced with the children books. So I propose to extend the usage of the field to collections as well - for the collection which are de-facto omnibuses for their series - except that their series don't contain novels. The other option would to be extend the omnibus definition for these cases - but there is a thin line between a real collection and a collection which would be omnibus if the works were novels... Thoughts? Annie 19:34, 5 March 2020 (EST)

I don't follow - COLLECTIONS and ANTHOLOGIES have Regular Titles that show up in the Contents section in the display. ../Doug H 23:05, 5 March 2020 (EST)

This is about this field. I would like to see it used for titles like Penric's Progress and A Knight of the Seven Kingdoms, but indeed, there's a thin line. Restricted to only numbered series of shortfiction titles? --Willem 05:13, 6 March 2020 (EST)

That may work as a separator. There are two separate cases with numbered series:

A series of novels (and/or collections/anthologies) which has some stories in between - these stories are part of the series but they are not in the main sequential numbers (see the half numbers in In Death for example.
Series where the stories are in the place of novels (such as Cracked Classics

The second one would have been an omnibus if the books were longer; a collection of the .5 stories of the In Death one is really a collection. I think that for both cases having the Content filled in is helpful though (non-mandatory as always). See A New Dawn for example. Having the Content on this view means that when I was adding the 1-6 or a new 1-6 omnibus, I do not need to import the 6 books individually and open all omnibuses to figure out what is inside so I know where to merge/variant and if I can import from another book as opposed to tracking down all title one by one. This series is novels only - so the numbering is there. But if these were shorter and end up with collections instead, we lose that visibility. Example: Soldiers of Fame and Fortune. Annie 11:45, 6 March 2020 (EST)

As I recall, I submitted a similar proposal a few years ago. There wasn't much support for it at the time and we didn't go into all the pros and cons. I still think that it's worth exploring, but there are a few issues which we may want to address first. For example:

If we allow the use of this field when editing collections, should we do the same for anthologies? Although it's somewhat less common, they can have similar issues.
This field supports two different formats. As per Template:TitleFields:Content:
- For omnibuses that contain numbered titles belonging to the same series, enter their respective numbers within the series, e.g. "1,2" or "4-6"
- For other types of omnibuses, enter the count of included titles, e.g. "3N" or "2N+2C" where "N" stands for "Novel" and "C" stands for "Collection"
If we were to follow the same logic, a collection which includes 23 unrelated stories could be entered as "23SF". Is that desirable? Also, how should we use this field when a collection contains multiple works belonging to different series? I guess we could only allow the use of this field for collections/anthologies when they contain fiction set in the same universe.

Finally, the software currently prepends the value of this field with "O/". Should we make it use "C/" and "A/" for collections/anthologies? Ahasuerus 12:56, 6 March 2020 (EST)

The different universes/series problem exists in the Omnibus world as well so it does not make it different here -- the 3-6 makes sense in a single series; when it is cross series, it is useless. Anthologies are probably a good idea for the cases where the series is multi-author one (I am seeing more and more of these...). I am thinking that for C/A, the easiest is to allow it for the first case (3-6) but not the second (2N). That will effectively be the same as numbered series only. But I have no troubles with 23SF either EXCEPT that people tend to merge collections which contain 23 stories with ones which contain 24 (expanded with a story for a reprint). I wish we were keeping these as separate titles but as we are not, that will be a problem. So single numbered series A and C only? (first option for omnibuses). And yes on the C/A instead of O. They are already marked as C or A anyway :) Annie 13:15, 6 March 2020 (EST)

(unindent) Let's try this again... I was sorting out yet another series (Judges) and thought I should reopen this discussion again. If the 6 novellas were novels, the 3 anthologies at the bottom would have been omnibuses and would have 1-3, 1-4 and 4-6 next to their names respectively thus making it clear at a glance what they collect. So I propose (again) to allow the "Content" field to be filled in for Anthologies and Collections for cases where these containers collect works from the same series. Thoughts? Any reason not to? Annie 16:31, 19 May 2020 (EDT)

I think this functionality would be useful when entering collections/anthologies which collect numbered SHORTFICTION works set in the same universe as in the example above. It will require some software changes, including changing the pop-up validation logic and the cleanup reports, but nothing insurmountable. Ahasuerus 09:09, 22 May 2020 (EDT)

Different ASINs: when to create a new publication vs when to add another ASIN to existing pub?

(Apologies if this might be better asked in Community Portal or some other page.)

I've been doing some s/w development work with a local copy of the database, to try to address one of my personal bugbears, which is the omission in ISFDB of some UK publications - especially ebooks - or sometimes even UK-only titles e.g. Neal Asher's imminent The Human, which is getting published a few weeks earlier in the UK than the US. (I guess Fixer will pick up the US publication before its pub date, but I think it'd be nice to have had the UK one already?)

I'm experimenting with a couple of different ways to resolve this problem, and one method I'm currently working on takes a bunch of ISBNs and/or ASINs and looks in my local copy of the database to see if they are known. If not, it tries to work out if it's a case of:

A title being completely unknown to ISFDB - rare, but not impossible, as per the above example
The title being known to ISFDB, but that particular publication not being in ISFDB
The publication being known to ISFDB, but not that particular identifier e.g. my tool picked up that http://www.isfdb.org/cgi-bin/pl.cgi?651898 is currently lacking an ASIN, which I'll add at some point.

A variant on the latter two cases that I'd like anyone's opinion/feedback on, is where a publication exists in ISFDB, but has a different ASIN to the one I've picked up. I think this is where a publisher operates globally, and puts the same product out in different national markets - I *think* Angry Robot, Titan Books, Solaris/Abaddon and Tor.com all do this - but Amazon has decided to give it different ASINs.

Example: The ebook of Echo Cycle is in ISFDB with an ASIN of B07VD1TW8P (and a USD price). The ASIN on Amazon UK for this is B081J3MZMY however. (Curiously, if I click on the link to Amazon UK on ISFDB's publication page now, Amazon gives me a "Page Not Found" error, but I'm sure when I tried it earlier today, it showed me a page with the UK paperback and ebook, but neither formats were selected by default.)

Given that the publisher in both the UK and US is Titan Books - and not having a copy that I can PV - it strikes me that it might be better to fix this problem by adding a second ASIN to the existing ebook publication, rather than creating a new publication? Having multiple ASINs per publication is supported by ISFDB (example) but there are very few of them - 53 in the latest database dump - which makes me wonder if that's maybe not a preferred solution? One downside of having UK and US ASINs in the same publication is that you can only have a single price value, so the second one loses out, or gets relegated to notes.

(NB: none of the work I've done is anywhere close to the state that I'd consider it usable for doing ISFDB submissions via the API - so far I've only used it to point me towards books that I already own and can PV the details for any edit I submit, and that state won't change any time soon.) EDIT: Belated signature several hours later: ErsatzCulture 15:44, 23 March 2020 (EDT)

The same ebook sold on Amazon US and Amazon UK is still the same ebook (i.e. there should only be one record). If they have different ASINs, than multiple ASINs can be added to the one pub record (I recommend adding a pub note explaining the situation). As for different pricing, I'd use the price from the publisher's country and put the other in the notes. The reason there is not many records with multiple ASINs is that, as far as I know, this has not been an issue to date. Usually Amazon uses the same ASIN in both stores. -- JLaTondre (talk) 15:58, 23 March 2020 (EDT)

That's right, an ASIN is usually unique across countries. If we start seeing more "multi-ASIN" publications, we may need to revisit the issue. Ahasuerus 16:24, 23 March 2020 (EDT)

Books get reissued with new ASINs often -- and Amazon is not great at showing correct dates lately (ebooks being tagged with the first ebook date is common...). So if I see different ASINs, that usually means different books - either an reissue or a region-specific changes (different extras?). If they are indeed the same, then multiple ASINs it is - they happen but not often. Notes can be used for the second price and we do have a long standing "one of those days" item to allow multiple prices :) Annie 19:27, 23 March 2020 (EDT)

In this case, comparison of the two via Look Inside shows the same versions (as far as can be seen). I checked that before responding. ;-) -- JLaTondre (talk) 20:06, 23 March 2020 (EDT)

FWIW, I don't (yet) have enough data to make a reasonable guess as to how common this might be, but I've identified at least three 2020-published titles that have different ASINs: Light of Impossible Stars and Echo Cycle published by Titan Books, and Sixteenth Watch published by Angry Robot. (For anyone *really* interested, there's some not-very-easy-to-read output from my script at User:ErsatzCulture/SamePublisherDifferentASIN; most of the books listed in those logs have different publishers in the US vs UK, so are reasonable to have different ASINs, but not the aforementioned three.) ErsatzCulture 20:38, 23 March 2020 (EDT)

How to deal with parent/variant titles of different length

I have asked for a new cleanup report for Variant Title Length Mismatches, since recently I found a number of short stories, novelettes and novellas as variants of each other.

If this cleanup report is realised, there will be 1,765 mismatches to deal with (thanks Ahasuerus), and of course there will be a number of variants that actually have a different length (A German title contains 18,000 words while its French translation is only 17,000 words, a novella is just under 40.000 words, it’s translation is just over etc.) The question is, how should we deal with these, which i.m.o leads to the following options:

1/ The length of the parent title is always leading 2/ The actual wordcount of the variant determines it’s length (and the cleanup report needs an ignore option)

1/ is of course the easiest way, but I would prefer option 2/, with the restriction, that if an exception is needed, it must always be explained in the title notes. Opinions or other options please? --Willem 16:16, 29 March 2020 (EDT)

When the length crosses the novel/novella line, we go with the original - regardless of the length of the variant. I think we should follow the same rule here. With a note added when the variant should have been a different length based on word count alone. Otherwise we are going to have a lot of moving up and down when the Slavic languages are involved for example. Or Japanese I would think. Annie 16:21, 29 March 2020 (EDT)

I do think along the same line: a translation from English to German will take about 10 % more words if carried out thoroughly (or so I've read somewhere) - to French it would be even more. This fact would not merit a change of title length in my opinion. And an abridgment also should not be a reason. Christian Stonecreek 00:05, 30 March 2020 (EDT)

I also think that it would be better to keep VTs' and parents' length values in sync the way we keep their title types in sync. Ahasuerus 22:36, 6 April 2020 (EDT)

An interesting point was raised - abridgements. Some Jules Verne translations were abridgements - cutting out scientific details or anti-whatever bias. I.O. Evans is famous for his abridgements, including of earlier translations. And there have been numerous abridgements and edits since ranging from modernization to reducing to picture books. Forced title lengths for abridgements really shouldn't occur though, since abridgements are not supposed to be varianted to the source. And where the abridgement is incorporated into the translation, it makes as much sense as the more precise translations. ../Doug H 08:59, 7 April 2020 (EDT)

A lot of the older translations are abridgements (even when not called so) so if we go down that rabbit hole, we can never connect anything - it is a very thin line between "abridged to fit 180 pages" and "removed 2 sentences" and "removed a paragraph because we did not like the message in them (the old Russian translations had that happening a lot". If it is abridged into a story or for juvenile audience or something, that makes it a different work. Slight abridgements during translations are... part of the translation process in a way. The first translations of a lot of works in any direction was almost always abridged... So depending on what we are looking at here, we may just be looking at what is considered a normal translation for the time - in which case the type should stand IMO. Annie 11:21, 7 April 2020 (EDT)

Not disagreeing at all - translations keeping the type/length in synch. Abridgements do not variant, so the question here is irrelevant. So to Christian's last point, I think it is unnecessary. However - a discussion of abridgements / edits to clarify ROT (Rules Of Thumb), especially with regard to translations would be in order at some point. ../Doug H 16:24, 7 April 2020 (EDT)

(unindent) FR 1339, "Create a cleanup report to find title length mismatches", has been created. Ahasuerus 13:55, 9 April 2020 (EDT)

Done. Ahasuerus 23:19, 10 April 2020 (EDT)

Outcome

Template:TitleFields:Length has been updated to say "For variant titles, including translations, use the length value of the parent title". Rules and standards changelog has been updated. A new cleanup report has been created. Ahasuerus 11:57, 18 April 2020 (EDT)

Suffix normalization?

I've run across a situation where an older book uses "Senr." and "Junr." as suffixes in the author credits (see this pdf). The help does not quite address this situation. The relevant bits of text from help on the Author field are (bolding is my emphasis):

The name should be entered exactly as it actually appeared in the publication.
Ranks, suffixes, prefixes. If an author is given as "Captain Robert L. Stone" then that should be entered in the database. Abbreviated versions of the rank should be entered as given, rather than expanded. For example, during World War II, on at least one occasion Amazing Stories printed an issue of stories from active service members, giving their ranks as part of the author attribution. These ranks should be included in the author names, and made into alternate names for the relevant authors . Suffixes such as "Jr" should follow a comma and space, and be followed by a period if they are abbreviations. This should be regularized if they are not presented this way in the publication, e.g. "Sam Merwin Jr" should be entered as "Sam Merwin, Jr."; similarly, it's "Edward Elmer Smith, Ph.D."; "Frederick C. Durant, III"; and so on.

So there's explicit instruction to capture ranks exactly as given (oddly, with no discussion about a trailing period on abbreviated rank designations), and there is some mention of regularizing suffixes, but that only seems to be considering use of the trailing period when an abbreviation is used. The discussion of abbreviations and expansions is limited to rank, although the suffix discussion's ... if they are abbreviations. seems to imply the instructions for capturing rank exactly as provided -- without expanding abbreviations -- apply to these as well.

Questions:

Should this be reworded so that all of these designations are to be captured exactly as stated, except with normalization of capitalization and periods on any abbreviations?
Should we add some statement of our preferred "canonical" form for ranks and/or suffixes? Using the example above, I rather doubt any of our current users would think to use "SENR" or "JUNR" in a search, and are most likely to use "Sr" and "Jr".

Thanks. --MartyD 08:58, 18 April 2020 (EDT)

My first reaction was to say that SENR and so on should be standardized - mainly for search purposes. On the other hand, I vastly prefer recording any author name as it is on the publication... So I am not sure here. I lean towards collapsing these into Sr./Jr. for consistency... Annie 11:51, 22 April 2020 (EDT)

I see a few different issues here. The first one is that the discussion of prefixes in Template:TitleFields:Author is limited to ranks. It doesn't cover other types of prefixes -- consider the case of The Hon. Mrs. Greene. I think Marty's proposal:

all of these designations are to be captured exactly as stated, except with normalization of capitalization and periods on any abbreviations

would be a step in the right direction.

The second issue is whether the "add periods to abbreviated suffixes" rule should also cover prefixes, including ranks. I think it should.

The third issue is whether we want to normalize the spelling of suffixes like SENR"/"JUNR" as well as, presumably, the spelling of prefixes like "Capt.", "The Hon.", etc. in addition to the current practice of normalizing their case and punctuation. I think that would be a step too far. I would rather create alternate names for them the way -- see S. P. Meek's list of alternate names for an example of how various versions are currently entered. Ahasuerus 12:32, 22 April 2020 (EDT)

Sorry, I have had some other recent demands on my time and am only getting back to this now. No problems with any of the comments. If there are no objections, I will reword the help to cover all prefixes and suffixes, using as-presented-in-the-publication with the exceptions of normalized capitalization and punctuation. --MartyD 09:58, 2 May 2020 (EDT)

Sounds good to me! Ahasuerus 10:19, 5 May 2020 (EDT)

Multi-Volume Page Counts

We should have a standard for how to represent multi-volume page counts. Currently, they are entered in a variety of formats:

Slashes: 184/182/627, xxxiii+174/xiii+399+[34]
Semicolons: 238; 254, xviii+405; xvi+536
Parenthesis: (xx+402)+412, (xi+203)+([x]+204)+220
Commas: xv+221, 268, 272, iv+318, iv+277
Pluses: 238+234, xx+718+xx+742

The rules only discuss dos-a-dos formats which are supposed to use pluses (i.e. 256+320). However, dos-a-dos is typically the simple case without roman numerals & unnumbered pages. Once those are included, I case see why editors have felt a need for more differentiation. Thoughts? -- JLaTondre (talk) 10:31, 22 April 2020 (EDT)

we use plus inside of the same counter per book so using it here may be a bit confusing. I like commas personally but ; also works. Annie 10:56, 22 April 2020 (EDT)

Hmmm, I would, indeed, use two different separators: one to discriminate between independent volumes, eg '/' or ',', and if page count is needed for an indelible single volume, I'd use '+'. Thus the given examples would become

184, 182, 627 --- xxxiii+174, xiii+399+[34]
238, 254 --- xviii+405, xvi+536
xx+402, 412 --- xi+203, [x]+204, 220
xv+211, 268, 272 --- iv+318, iv+277
238, 234 --- xx+718, xx+742 (this last one is ambiguous)

Cheers! MagicUnk 11:13, 22 April 2020 (EDT)

It looks like there are two separate issues here. The first one has to do with the fact that Template:PublicationFields:Pages currently says:

Books in dos-à-dos format, such as Ace doubles, have two sets of page numbers, one for each half of the book. This is entered as "256+320" for example.

Dos-a-dos books are not the only ones that can have multiple sets of page numbers. We should change "Books in dos-à-dos format, such as Ace doubles" to "Some publications, e.g. dos-à-dos books and certain omnibuses".

The second issue is the fact that Template:PublicationFields:Pages doesn't say anything about multi-volume publications. I think we should reserve the plus sign for different sets of page numbers within a single volume and use a different separator for multiple volumes. Commas appear to be the best bet. Ahasuerus 11:36, 22 April 2020 (EDT)

Correct. This also relates to the unfinished disussion on multi-volume publications. As Zlan52 pointed out elsewhere, we should try to finish that discussion too and reach a consensus (as basically, re-reading the text, we all agreed but never summarized the conclusions in a rules update proposal - I wanted to do that, but real-life™ keeps interfering :)) -MagicUnk 15:59, 22 April 2020 (EDT)

I have posted a summary and a request for new Help language in the linked section. Ahasuerus 12:40, 29 April 2020 (EDT)

The downside to using a plus sign in a single volume with separate paginations is that a pub like this one would be "xxxiii+174+xiii+399+[34]" which is a bit hard to parse out. It also leads to ambiguities because is "100+[2]+100" two unnumbered pages at the end of the first or the start of the second? While notes could be used to clarify, it would be nice to be able to tell by just looking at the field. -- JLaTondre (talk) 12:07, 25 April 2020 (EDT)

I understand what you're saying, but I believe there is just no nice way codifying what you want, I'm afraid. For these cases, you could use another symbol, say colon or semi-colon or slash signifying 'single volume, titles are separately numbered'. Then your examples would become "xxxiii+174/xiii+399+[34]", and "100+[2]/100", whereas for two separate volumes they would be "xxxiii+174,xiii+399+[34]", and "100+[2],100", respectively. Unfortunately, it is not immediately apparent which is which, especially not for the casual editor. Therefore, I would stick with the aforementioned standardization, and clarify in the notes as needed. MagicUnk 14:01, 25 April 2020 (EDT)

I wasn't suggesting three options. I was only suggesting two. The current plus for single pagination ranges and something else (the suggested comma would be fine) for multi-pagination ranges (whether single or multiple volumes). Also, I have restored the indent level of my comment which you changed. I was responding to Ahasuerus' comment, not yours (which did not mention separators). Indent levels matter for following conversations. -- JLaTondre (talk) 15:33, 25 April 2020 (EDT)

(unindent) It sounds like there is general agreement that we want to change "Books in dos-à-dos format, such as Ace doubles" to "Some publications, e.g. dos-à-dos books and certain omnibuses" in Template:PublicationFields:Pages. We also seem to agree that a volume with a page count which contains multiple independent sequential ranges of page numbers should be entered using plus signs, e.g. "xiii+235+[iv]". The page counts for multiple volumes should be separated using commas, e.g. "xxxiii+174,xiii+399+[34]".

What's less clear is how to separate page ranges when a volume has what amounts to nested ranges. Edgeworks.1, the publication linked earlier, is an omnibus publication reprinting the contents of a COLLECTION title and a NONFICTION title. The titles associated with the COLLECTION section have two ranges of page numbers: xxxiii+174. The titles associated with the NONFICTION section also have two ranges of page numbers: xiii+399+[34]. It can become even more confusing when it's a multi-volume publication. The options listed so far are:

xxxiii+174+xiii+399+[34] -- concatenate all ranges within a single volume using pluses regardless of nesting
xxxiii+174/xiii+399+[34] -- use pluses to separate individual ranges belong to the same contained work and then use slashes to separate composite ranges
xxxiii+174, xiii+399+[34] -- use pluses to separate individual ranges belong to the same contained work and then use commas to separate composite ranges

All of the listed approaches assume that the page counts/page ranges for multiple volumes will be separated using commas. (Hopefully I got everything right.)

My main concern with approaches 2 and 3 is that there may be omnibuses with additional page ranges not associated with the constituent works. For example, the latter may have ESSAY titles (with a small page range of their own) inserted between them. Something like "xxxiii+174, 13, xiii+399+[34]" (where the bolded number 13 is the page range in between the two main works) could be confusing. I also tend to think that reserving commas for separate volumes would be a more effective way to convey the idea that there are multiple volumes involved. Ahasuerus 17:33, 29 April 2020 (EDT)

Outcome -- Help updated

Template:PublicationFields:Pages has been updated as follows:

The use of pluses for two sets in dos-a-dos publications was expanded to cover all publications with multiple sets of page numbers
A new rule was added: "*For multi-volume publications, use commas to separate the page counts for each volume, e.g. "vii+387, xii+422"."

Rules and standards changelog has been updated. Ahasuerus 15:23, 5 May 2020 (EDT)

P.S. The recently added cleanup report has been adjusted to allow commas in the page count field. Ahasuerus 16:29, 5 May 2020 (EDT)

Eligibility of NONFICTION about non-written SF

(Summarized and expanded based on a recent Moderator Noticeboard discussion)

ISFDB:Policy first defines speculative fiction. It then states that the database includes only published works of speculative fiction, which are defined as:

paper books and periodicals
electronic publications of certain types
audio books, i.e. readings, but not dramatizations

as well as certain types of unpublished works of speculative fiction. Note how the term "published" is used to exclude speculative fiction in other media -- dramatizations, games, TV, movies, etc.

In addition, the third Rule of Acquisition says that "Works about speculative fiction" are included. The rule doesn't clarify whether such works are limited to "published" speculative fiction or whether works about speculative fiction in all types of media are included.

Due to this lack of guidance, I have seen editors adopt one of three different approaches:

Include all published non-fiction works about content that is both speculative and fictional regardless of the medium: board games, comics/manga, video games, movies, TV/anime, etc.
Exclude published non-fiction works about content that we do not consider to be "published" speculative fiction, where "published" is defined as per the Rules of Acquisition, i.e. "paper", "electronic" or "audio" publication.
Include only published non-fiction works about speculative content which can be plausibly linked to "published" speculative fiction. This approach lets us include secondary bibliographies, i.e. bibliographies of bibliographies even though they are not -- technically -- "about" speculative fiction. It also includes non-fiction works about popular shared cross-media universes like "Doctor Who" and "Star Wars", but only as long as there is a plausible connection to the universe's "published" component. Thus a book about "Star Trek physics" would be included (because it applies to all media including Star Trek novels) while a book about Star Trek movie outtakes and bloopers would be excluded.

Personally, I prefer the third approach. I seem to recall that it had plurality support the last time we discussed the issue, but I don't think it was ever codified. Ahasuerus 18:03, 27 April 2020 (EDT)

So should we reopen and try to codify this finally? I am operating under approach 3 because this is how I had always read (and understood - and been explained to) our rules. Or should we try to find the old discussion first? :) Annie 18:07, 27 April 2020 (EDT)

I prefer the third approach also. -- JLaTondre (talk) 19:05, 27 April 2020 (EDT)

So do I. Stonecreek 23:29, 1 May 2020 (EDT)

OK, let me see if I understand this correctly. Under approach 3, Mijn vriend Spider-Man would be eligible, wouldn't it? This is a non-fiction work containing interviews with philosopher, publisher, comic experts, ... about Spider-Man, as well as a biography of Peter Parker, and a list of the best spider-man stories. And as there exist novelizations of spider-man films, that would be the plausible link, yes? MagicUnk 06:33, 2 May 2020 (EDT)

Since it's about the Spider-Man universe in general and since that universe includes a lot of "published" SF, I expect that it would be allowable. On the other hand, something like Behind the Mask of Spider-Man: The Secrets of the Movie, which is about a single movie and not related to published SF, would be "out".

I also expect that we will run into some borderline cases, e.g. books about films based on published SF. It can be difficult to tell how much of the text is about the book and how much is about the film. Ahasuerus 08:05, 2 May 2020 (EDT)

Thanks for the confirmation that I got it right :) Btw, I'm fine with option 3. Makes sense. Cheers! MagicUnk 10:23, 2 May 2020 (EDT)

Yeah, these cases should be in: that is, where novelizations or fiction spin-offs do exist and we don't know if these fictions are dealt with in a given nonfiction.

Another question does arise with (auto)biographies of actors who are mostly or solely affiliated with genre movies. William Shatner, for example, has published genre titles, but other actors haven't done much (or nothing) on this side of genre. Would it be enough to have published one piece of fiction? Stonecreek 09:24, 2 May 2020 (EDT)

I prefer #3. For the question of material about (or by) actors: If they are not "in" as authors, then non-SF material about (or by) them should not be "in", either. --MartyD 12:29, 2 May 2020 (EDT)

I agree, although we'll probably have some borderline cases. In addition to the previously mentioned Shatner, Boris Karloff was an actor who had a number of written SF credits. Ahasuerus 15:09, 2 May 2020 (EDT)

Outcome

ISFDB:Policy#Included has been updated with the following language:

Published non-fiction works about speculative fiction which can be plausibly linked to published (as defined above) speculative fiction. This rule allows the inclusion of secondary bibliographies, i.e. bibliographies of bibliographies, which are two steps removed from published speculative fiction. It also allows the inclusion of non-fiction works about shared cross-media universes like "Doctor Who" and "Star Wars", but only as long as there is a plausible connection to the universe's published component. Thus a book about "Star Trek physics" can be included (because it applies to all types of media including novels) while a book about Star Trek movie outtakes and bloopers should be excluded.

Rules and standards changelog has been updated. Ahasuerus 15:22, 6 May 2020 (EDT)

More precise definition of CHAPBOOK publications

Currently Template:PublicationFields:PubType says:

CHAPBOOK. ... a separate publication of a single work of SHORTFICTION (q.v.), a single POEM or a single SERIAL installment of a longer work. In addition to the single SHORTFICTION, POEM or SERIAL content record, such publications may also contain one or more ESSAY and INTERIORART content records. ... Publications with more than one SHORTFICTION, POEM or SERIAL content record should be entered as ANTHOLOGY (for multiple-author publications) or COLLECTION (for single-author publications). [emphasis added]

Based on this definition, a booklet which contains a novella plus one of the following:

an excerpt from a larger work
a short poem
a fictionalized essay

is not a CHAPBOOK and should be entered as a COLLECTION/ANTHOLOGY.

In a recent Community Portal discussion (which see for details) we reached general agreement that the definition of CHAPBOOK publications should be expanded to allow up to one additional short fictional work under certain circumstance. Here is the proposed Help language to be inserted after the last sentence quoted above:

The following types of SHORTFICTION titles are ignored when deciding whether the publication is a CHAPBOOK:
- Excerpts
- Synopses, fictionalized essays and other types of supporting material
- Up to one bonus short story, poem or short serial installment if the publication's title page lists only the title and the author of the main title

Does this look OK? Any potential pitfalls, caveats, exceptions, additional scenarios, etc? Ahasuerus 19:03, 1 May 2020 (EDT)

It might be helpful to reword the initial portion of the CHAPBOOK section slightly. Right now, the emphasis is "... if it contains a single ... title ...". Then we're forced into listing other things it might also contain as exceptions to the "contains a single title". I realize the best part of that definition is it is objective, not subjective, but making it subjective could make everything else easier: "... if it is presented as a publication of one work of less-than-NOVEL length. --MartyD 10:12, 2 May 2020 (EDT)

"One fiction work of less-than-NOVEL length", I assume? Ahasuerus 09:11, 4 May 2020 (EDT)

Well, yes. I was going to use SHORTFICTION, but then, of course, we have POEM.... fiction did not occur to me. --MartyD 15:27, 5 May 2020 (EDT)

Then we could say if it is presented as a publication of more than one such work (again, instead of "contains"), use ANTHOLOGY or COLLECTION. And then your proposed list above could be reworded as an explanation that such publications may contain ancillary and supporting material that should not affect the CHAPBOOK vs. not determination, with the items you list as examples of such material. Then we're not forced to have an exhaustive list of exceptions, and the spirit of what CHAPBOOK should be used for should be clear. --MartyD 10:12, 2 May 2020 (EDT)

I agree that the list of exceptions proposed above is somewhat unwieldy. However, if we say "presented as", wouldn't we then have to explain what "presented as" means, which would effectively result in the same enumeration as above?

Perhaps we could compress the list of exceptions a bit:

The following types of SHORTFICTION titles are ignored when deciding whether the publication is a CHAPBOOK:
- Supporting and incidental material such as excerpts, synopses, and fictionalized essays
- Up to one bonus short story, poem or short serial installment, but only if the publication's title page lists only the title and the author of the main title

Unfortunately, I can't think of a good way to further compress the two items above because the second one is a special case which needs a precise definition. Ahasuerus 09:11, 4 May 2020 (EDT)

Sound perfectly understandable to me! Christian Stonecreek 09:23, 4 May 2020 (EDT)

One little nit about the second of your two items: "... lists only the main title and the main title's author(s)." When I read it the first few times, I kept interpreting "the title" as referring to the bonus story, etc. Italicized text is just an editorial suggestion if the first "main" is inserted. --MartyD 15:27, 5 May 2020 (EDT)

Sounds eminently reasonable. The updated proposed language is:

The following types of SHORTFICTION titles are ignored when deciding whether the publication is a CHAPBOOK:
- Supporting and incidental material such as excerpts, synopses, and fictionalized essays
- Up to one bonus short story, poem or short serial installment, but only if the publication's title page lists only the main title and the main title's author(s)

Ahasuerus 15:26, 6 May 2020 (EDT)

Looks good to me. Annie 15:47, 6 May 2020 (EDT)

To me, too. --MartyD 07:31, 9 May 2020 (EDT)

Outcome

Template:PublicationFields:PubType has been updated with the following language:

The following types of SHORTFICTION titles are ignored when deciding whether the publication is a CHAPBOOK:
- Supporting and incidental material such as excerpts, synopses, and fictionalized essays
- Up to one bonus short story, poem or short serial installment, but only if the publication's title page lists only the main title and the main title's author(s)

Rules and standards changelog has been updated. Ahasuerus 10:31, 9 May 2020 (EDT)

The cleanup report CHAPBOOK Publications with Multiple Fiction Titles has been modified to let moderators "ignore" records. Ahasuerus 16:38, 9 May 2020 (EDT)

SERIALs and (Part i of n)

The wording in the help for naming serials titles states:

"SERIALs. If the title of a SERIAL installment is unique, e.g. "Butterflies in the Kremlin, Part Eight: As the Bear Turns" or "Ciężki bój (cz. 1)", then use the full form of the title. If, on the other hand, the title is shared by at least one other SERIAL installment of the work, append a space and a parenthetical statement such as "(Part 1 of 3)" to the title. For novel length works (40,000+ words) printed as a single installment in a magazine or fanzine, append a space and "(Complete Novel)" to the title. "

The use of (Part i of n) is merely suggested under "such as". ../Doug H 16:45, 3 May 2020 (EDT)

In this case such as "(Part 1 of 3)" was shorthand for Use "(Part 1 of 3)" for the first part of a 3-part serial, "(Part 4 of 7)" for the 4th part of a 7-part serial, etc. If it's ambiguous, we may want to clarify/expand the wording. Otherwise I agree with Annie's arguments below. Ahasuerus 08:34, 4 May 2020 (EDT)

It is not ambiguous in describing what the naming convention is or how to use it. My question is related what other alternatives are 'permitted' under the such as. At worst, if the arguments made below suggest it is the best and recommended approach, the wording might be changed from "such as" to a stronger term like "of the form of". ../Doug H 10:49, 4 May 2020 (EDT)

That's a good point. "Such as" was supposed to indicate that "(Part 1 of 3)" was an example of the "Part X of Y" pattern that should be followed. I seem to recall that the original wording was "use the form (Part X of Y)", but it confused some editors. Unfortunately, as you pointed out, "such as" can also be read as "you can use (Part 1 of 3) or you can use another format". "Of the form" would be a better, less prone to misinterpretation, way to phrase it. Ahasuerus 11:36, 4 May 2020 (EDT)

For a SERIAL spread over a large number of issues (24 - 72), would it be acceptable to use a more generic title for the SERIAL like "(Serialized in nn parts)"? Each MAGAZINE's Content would refer to the same title, meaning 1 title per serialization with nn publications, rather than nn titles each with one publication. Displaying the SERIAL would show all the MAGAZINES together (presumably in order), rather than having to chase them down one by one. This would also reduce the number of entries in the parent record's summary - avoiding long lists like those seen for Kéraban-le-têtu but not Empires.. I would not expect this to change the rule (beyond providing it as an alternate suggestion under "such as"). I do expect there are other aspects I've not considered, such as statistics, user expectations, and of course arguments about whether this should be a standard, conversion etc. The floor is open. ../Doug H 16:45, 3 May 2020 (EDT)

I do not like having the same title for different content - makes it impossible to understand which part is where and goes against what titles (as opposed to variants) represent. Plus if the serialization is ever reprinted, it makes it even harder to work out what you need to complete a set. I would rather have the long list (and eventually some UI based solution on alternative view if desired) than losing data by lumping things together. Annie 00:31, 4 May 2020 (EDT)

PS: if you go based on your idea and we have a serialization in 30 parts but we have only 15 entered, finding what we are missing becomes very hard - hiding the information on the pub level makes it one step removed from where it should be. Is there any other reason to propose this besides the fact that you do not like the long list? The such as is just for the naming of the individual parts - some serials have separate names so we do not add the part of notation. It is not there to imply that you can simply use the same title record for different parts. Annie 00:36, 4 May 2020 (EDT)

Let me make this clear at the outset, I'm much, much more interested in the articulated reasoning than result.

"impossible to understand which part is where" - by selecting the associated title, the list of publications containing the serializations should be presented, in what I presume is date order, which hopefully is in part order. I agree you can't tell by looking at the title alone you cannot tell, or by looking at the contents of a particular magazine. But sometimes you can't tell that by looking at the magazine itself. ../Doug H 10:49, 4 May 2020 (EDT)

"goes against what titles (as opposed to variants) represent" - what do "titles" represent? For novels and such we are clear that they should match what is in the publication. Parenthesized suffixes break that rule. For ESSAYs we use it for disambiguation of common titles such as Foreword. For SERIALs, it is used to differentiate magazine printings of novels from separately published versions as in "(Complete novel)". Variants represent the same content under a different name for the composition or author. Or a translation. Or a portion of the entire composition, although we don't seem to variant short fiction extracts back to their canonical source. The same complete material published under the same title/author will end up as two publications under one title. Two serializations of the same material in the same number of parts would end up under different titles because there is insufficient information documented to say the breaks are at the same places and hence the contents are the same. ../Doug H 10:49, 4 May 2020 (EDT)

"if the serialization is ever reprinted, it makes it even harder to work out what you need to complete a set" - I'm not sure what you're getting at: what a reader needs to collect to obtain a physical set or what an editor needs to find to document the new set. And if we're talking about a reprint - how does one distinguish a re-serialization from a reprint? If the former, they'd be different titles and the old serialization is irrelevant, and if the latter, it is the same publications. ../Doug H 10:49, 4 May 2020 (EDT)

Think of the users and not the editors for a second. We do not compile bibliography so we say we have it but so people can use them. And we live in the age of the reprints. If I have 20 issues with 20 parts of. 30 parts story and there are reprints of the full run of a magazine, are you really proposing that it will be better for me as a user to check the 60 separate publications (30 original, 30 reprints - names don’t always match) to find which reprints I need for my missing parts of the story? Annie 15:01, 4 May 2020 (EDT)

Test case: 20 issues of magazine covering 20 parts of a 30 part story. How to find which issues have my missing parts. (Ignoring reprints for now). Current approach: search for author, find and select the title in the summary, see 30 Serializations with (Part x of 30). In the magazines, find the gap in the story, check which part was stated in the prior issue and select the title corresponding to the following number. Note the publication and date from the entry. Go back to the summary list. Repeat for the other 9 missing issues. Hypothetical approach: search for the author, find and select the title in the summary, see 1 serialization with (Serialized). Select the entry and see a list of publications with the story. Match up issues listed with those I have to find which I am missing. If you add reprints, you potentially double the number of look-ups in the current approach (have to look up both copies for each Part x, although statistically 1.5 times). The hypothetical approach also potentially doubles, although if you guess right on first try it is the same. Unless you decides that both serializations can share the same title (something not yet discussed), at which point there is only one to pick and it will list both sets of magazines, presumably one after the other so they are consecutive. Although the test case seems moot - if I'm missing a part of the story, I'm missing a magazine in the series and I should be looking at the magazine grid instead. ../Doug H 17:44, 4 May 2020 (EDT)

"losing data by lumping things together" - this implies that the "part i of n" is included in the serialization itself. The Jules Verne example I cited does not provide such information. Only by collecting the entire series and examining it can one determine there are 24 parts. One could assume they never missed an issue and go by the issue numbers and first and last entries, but that would likely have to be included in the publication notes. And if one were to run across a single issue with a single part, could one document it without finding the others? No data is necessarily lost. The suffix of "(Serialized)" or "(Serialized in nn parts)" could be completely valid statements of what is known. ../Doug H 10:49, 4 May 2020 (EDT)

You still end up with a title record that does not tell you what it contains. Which is against the idea of titles. Would you also like us to lump all languages and translations in one title record - these re much closer in contents to each other than the pieces of serialization are. Or all stories in a collection? Because lumping serialization pieces in one title is not different from saying that if you have a collection of 20 stories, we can just lump the 20 stories together in a single story record. A non art title represents a certain text. The moment we say that it can represent different things, it becomes something else. Annie 15:01, 4 May 2020 (EDT)

With the existing approach, providing title information must either be replicated across every part, or be restricted to the first - things like which translation it is, dubious authorship, or the fact the dialogue was printed in four fonts and three colours. The proposed approach gives you one place for such information. And to the second point - no I don't want to, and didn't say so. Your analogy to stories disregards the fact that the story is a single thing broken down into parts, while stories are independent. Your statement that "a non art title represents a certain text" comes as close as anything I've seen on this site to a Tenet that should be enshrined. Of course we have exceptions - no one checks that Introductions and (Excepts) are truly the same and we lump together texts that vary in (what each editor considers) to be in minor ways. And possibly for (Part 1 of n) titles that are reprinted as we can't be sure that the breaks are in the same places. Or that two translated texts are necessarily the same. Could SERIALS not be considered collectively as a piece of text? ../Doug H 17:44, 4 May 2020 (EDT)

"a serialization in 30 parts but we have only 15 entered" - assuming you know there are 30 based on the 15, can you document the 15 if you don't know which ones they are? Are you forced to find all 30 to document what you have? (much the same point as above). ../Doug H 10:49, 4 May 2020 (EDT)

That may not be always known. Sometimes we do not know where all the pieces are. Annie 15:01, 4 May 2020 (EDT)

So if I have volume 12 of "Magasin d'Education et de Recreation", which contains chapter XXXIII of Vingt Milles Lieues Sous Les Mers, without knowing how may parts there are, and which one this is, I cannot give it a title? Or I stretch the "such as" and use a suffix like "(Chapter XXXIII)" or possibly "(Chapters XXXIII-XXXVII)". ../Doug H 17:44, 4 May 2020 (EDT)

"Is there any other reason to propose this besides the fact that you do not like the long list?" - I would like to see all parts of a serialization together - e.g. as publications under a single title, and find it by selecting the title under a publication, rather than selecting the title, going to the parent, checking the SERIALIZATION list and picking through the various "(Part 1 of n)" titles to see which ones are part of this serialization as opposed to another of the same length, and having to repeat this for each part to see which publication that part was in. The long lists dislike is not simply because they are long, but because they push the meaningful publication list content down much further on the page and I do want to see variants, so cannot change the criteria. I don't see what value there is in having 15 invented (sub-)titles that simply tell you where something is in a sequence that doesn't mean much of anything unless you see the whole sequence anyway, so thought I would ask. ../Doug H 10:49, 4 May 2020 (EDT)

I'm not suggesting it as a new standard for serializations, but an alternative in appropriate cases. I do recognize, however, that it provides a distinctly different appearance and behaviour for serializations that might be confusing. But IF preventing confusion is the ONLY reason to say no to an approach, we should at least identify why a given approach is better. ../Doug H 10:49, 4 May 2020 (EDT)

So what you are looking for is a visual way to show which serial pieces belong together? Because that seems to be the only argument above I can see besides - I do not like how it looks. Annie 15:01, 4 May 2020 (EDT)

From what I can see, there is no data that connects the parts other than assumptions. You have to assume that the "of n" will allow you valid grouping, and where printed more than once, the publication name will distinguish the sets, and where reprinted by the same magazine, the dates will provide the break. I have seen notes somewhere where a series changed how many were in it part-way through, and suspect that not every serialization finished, so this approach will be complicated and a bit unreliable. So this approach allows you to bring together things you are suggesting is simply visual. This has the effect of grouping SERIAL parts together, and if that is the lack, then some other solution like SERIAL series to group and SERIAL sequence may be required. ./Doug H 17:44, 4 May 2020 (EDT)

(Unindent) Let’s cut to the heart if your idea, shall we? You are proposing different texts to be recorded under a single title. How is 20 parts of a story different from 20 stories in a collection? Both are 20 separate texts - so we need 20 separate title records. You want the first case to be one title while the second one not? What is the difference? Again - I am against title records which are pointing to different texts - except the cases where we really cannot split cleanly yet (unidentifed translations). If it is not the same text (or slightly revised one), it cannot be the same title record - not the way we define titles. We even split translations - which have the same title, author and base text because we acknowledge they are different texts. Limping different texts into single titles go against anything in this DB. Annie 19:16, 4 May 2020 (EDT)

A few thoughts:

The way we usually enter serial installments when we don't know how many parts the serialization had (or will eventually have) "in toto" is by using the "(Part 19 of ?)" format. If we don't know anything about it, we use the "(Part ? of ?)" format -- see this title record, which demonstrates both formats. We may want to update Help:Use of the SERIAL type with this information. Ahasuerus 20:55, 4 May 2020 (EDT)

If you do, may I suggest your wording cover the situation where I have 2 unknown of unknowns. And would my (Chapter XX-XXX) fulfill the "such as" criteria? ../Doug H 22:03, 4 May 2020 (EDT)

I assume it's in reference to the "(Chapters XXXIII-XXXVII)" example above? I expect that a range of chapters would fall under the "if the title of a SERIAL installment is unique" rule above, so it should be entered as it appears in the publication. If we entered it as "(Part 5 of 30)", we would lose some information.

Whether the simple use of a roman numeral to indicate the part number of a serial (e.g. "Part VII") makes the title "unique" for the purposes of this rule is a different question. As I recall, the last time it came up, the majority opinion was that it shouldn't be considered "unique". However, checking the database, I see that some SERIAL titles treat roman numerals as "unique", e.g. see this title. It looks like it's something else to discuss and clarify in Help. Ahasuerus 12:58, 5 May 2020 (EDT)

In this specific case, I don't think it applies under the reference to the title being unique. The title is the same in every part, but they all start with a chapter (actually "Chapitre") and number, which happens to be in roman numerals. The small sample had only a single chapter per serial, but I can see that 6 month bound volumes would have multiple chapters and hence the question about ranges. So this would definitely fall under the "such as" clause. Part i of n is additional information, so not using is not losing information. The Chapters / Chapitre is not part of the title, but does qualify as real and distinguishing information from the actual text. If it were acceptable as an alternative, I expect that the French text and Roman numerals would be as well, coming from the text directly. More as a note - while the magazine would have one 'part', the bound volume would not contain a single combined part, but rather each of the individual parts would be re-used, being spread out through the volume. ../

So we are talking about Dickens's style serial (I know he did not invent it - but this is where I saw that for the first time :)) -- where it is basically a cut novel with chapter numbers? Did the French print one chapter at a time or multiple per installment? Annie 16:02, 5 May 2020 (EDT)

If the roman numeral is printed (thus making the title unique), it is closer to as printed than our (part X of Y) so I would not insist on the latter. Especially with the "novel in chapters in ebooks", they have unique names often. I would still add (part X of Y) mainly because of the Y but either way works for me. Annie 16:02, 5 May 2020 (EDT)

Long novels with lots and lots of serialized installments can, admittedly, present a display problem. For example, Varney, the Vampyre or, The Feast of Blood was originally published as a "penny dreadful serial ... over a three year period with the parts generally being published on a weekly basis." That's well over 100 installments. If we were to enter all of them, the author's Summary page would become unwieldy. This problem used to be primarily an 19th century issue -- Eugene Sue's Le Juif errant will be a chore once we start entering its serializations -- but lately it has become a bigger issue due to the proliferation of electronic magazines. There have been a few attempts to come up with a way to address this display problem, typically by tweaking the way serializations appear on Summary pages, but it has been inconclusive.
Allowing multiple different ways to enter the same type of data as suggested above is generally counterproductive since it leads to more complexity and confusion.

Ahasuerus 20:55, 4 May 2020 (EDT)

My wrap-up (lots of rabbit holes, but all digressions):

My biggest lesson is the perspective of focusing on the 'text' rather than the content. I'm still enamoured with definition (paraphrased) "A TITLE represents a piece of text". I am (almost) inspired to write a primer on ISFDB for newcomers which would start from there in explaining how everything works. Which I am still learning even after 12 years here.
The display for multiple serials is still a rough cut and entirely different discussion and timeline.
Serials lack for a single entity that represents the entirety. Which may account for the point above.
This is a forum where a serious question can get a reasoned response from knowledgeable and patient members. For which I thank you.
Oh yeah, I don't plan on trying this approach. But I may hold off on entered all those 19th Jules Verne serializations for a bit.

../Doug H 22:03, 4 May 2020 (EDT)

I think that you were mixing up a bit title (as in the string we use as a title) with a title record (the record in the DB). The first can have different texts behind it (think of translations with the same title) but the latter is defined as a “same text with minor revisions, same title, same author, same language, (same translator if relevant although the same text clause covers that). This is why we split translations and collections with the same name but different contents (one of them becomes variants because the initial text is the same, the latter gets their own titles). I will be the first to admit that most people including me use title in both of these meaning - thus sometimes confusing things a bit I suspect. So in this case, having the same title as a string was not my issue at all (we need differentiator but we can use a different one from part a of b) - it was the second mixup of having a db record which has entries containing different pieces of text. I can understand exactly where you are coming from with these but changing a title record to mean “any part of this” is a lot deeper than just a naming convention change. :)

The lack of record for complete serials is a side effect of us not allowing variants of variants (same problem we have when we try to tie two translations of the same work together when an editor changes the title or the author spelling. It may be worth opening that discussion. Annie 22:16, 4 May 2020 (EDT)

Letters -- cleaning up the data entry rules

Back in 2014 we had a Rules and Standards discussion and Template:PublicationInfo:WhatToInclude was updated with the following language:

Individual letters to the editor published in magazines: Entries may be restricted to significant letters by well-known sf personalities. Editors have the option to include other letters. An untitled letter should be entered using the format: Letter (Title of Magazine, Date).

At the time we forgot to update Template:PubContents:Letters, which hasn't been modified since 2008. It says:

Letters should be entered with the following format: Letter (publication name, publication date). Example. If the letter has a title the editor has the option to append it by adding a colon, a space, and the text of the title to the letter entry. Example. Entries should currently be restricted to significant letters by well-known sf personalities.
Letters may eventually be assigned their own Entry Type. if they are, existing titles will have to be modified manually.

I suggest that we merge the two sections and put the resulting language in Template:PubContents:Letters, which will read:

Individual letters to the editor published in magazines: Entries may be restricted to significant letters by well-known speculative fiction personalities. Editors have the option to include other letters. All letters should be entered using the format: Letter (Title of Magazine, Date). If the letter has a title, append a colon, a space, and the text of the title: Letter (Title of Magazine, Date): letter title.

P.S. The issue of "significant letters by well-known sf personalities", which we discussed on the Moderator Noticeboard a few days ago is a separate topic. For now I just want to make sure that the Help language is consistent. Ahasuerus 10:17, 5 May 2020 (EDT)

Looks good to me. Annie 17:26, 9 May 2020 (EDT)

And in principle, it does to me. But we do have a lot of irregular (undated) magazines in the database, like this issue or that one. For them I have used only the title of the magazine with the issue number.

And if the letter is titled I have used only 'Letter: (Title)'. I'd like to think that this could also be used to define and find the letters. Christian Stonecreek 08:35, 10 May 2020 (EDT)

That's a good point. It didn't occur to me that not all magazine titles follow the "Title of Magazine, Date" format. I guess we should change the language from Letter (Title of Magazine, Date) to Letter (Title of Magazine Issue). Ahasuerus 17:46, 12 May 2020 (EDT)

There's already a standard for a letter with a title: "If the letter has a title the editor has the option to append it by adding a colon, a space, and the text of the title to the letter entry." Having a second standard actually makes it more difficult to find the letters. --Ron ~ Rtrace^Talk 06:30, 13 May 2020 (EDT)

But does or doesn't that phrasing mean that in this case the magazine doesn't need to be mentioned in the entry for the letter? I interpreted it as 'Letter: (Title)' would be sufficient. Christian Stonecreek 10:29, 13 May 2020 (EDT)

It looks like we may be talking about two different types of exceptions:

Exception 1: The letter has a title, which is covered by the "If the letter has a title, append a colon [etc]" rule above.
Exception 2: The title of the magazine issue doesn't use the "Title of Magazine, Date" format. Under the current rules, a letter published in Perry Rhodan, #2994: Engel und Maschinen must be entered as "Letter (Perry Rhodan, 2019-01-04)" rather than "Letter (Perry Rhodan, #2994: Engel und Maschinen)".

It's the second exception that I think is inconsistent.

Having said that, it's not the same issue as the one that I originally raised above. It may be better to reconcile our Help templates first -- which basically amounts to correcting a 6-year-old oversight -- and then discuss what we want to do about the second exception. Ahasuerus 11:41, 13 May 2020 (EDT)

(after editing conflict) Different approach to be prepared for when LETTER is a title type:
Letter:untitled|<letter_title> [(<magazine issue title>)] (command syntax)
which is in line with our current practice for title (disambiguation) imo, and it would allow for automatic coversion when we have the LETTER type. This translates to, for example:

untitled (magazine issue title) - to disambiguate if letters did not receive a title
title, or, title (magazine issue title) - if letters did receive a title. Latter case to disambiguate same titles across different issues for same author
Further disambiguation with numbers in square brackets for authors with multiple (untitled) letters with same title in same issue, like this: Letter:untitled|<letter_title> [n] [(<magazine issue title>)] (not sure if that ever occurred or will occur?).

How difficult is it to add LETTER as an additional type, and would that be useful to implement now? (as Annie said elsewhere, the longer we wait, the messier things get and longer it'll take to fix things :). MagicUnk 11:54, 13 May 2020 (EDT)

If I recall correctly, the last time we discussed this issue, we were still unsure whether we wanted to:

create a separate LETTER title type, or
make it an ESSAY sub-type similar to how novellas, novelettes and short stories are effectively a sub-type of the SHORTFICTION title type

If we want to resurrect the discussion, I suggest that we do it on the Community Portal. This section is an attempt to reconcile/merge two Help templates which got out of sync when we updated one of them in 2014. Ahasuerus 17:57, 13 May 2020 (EDT)

Outcome

Template:PubContents:Letters has been updated as follows:

Individual letters to the editor published in magazines: Entries may be restricted to significant letters by well-known speculative fiction personalities. Editors have the option to include other letters. All letters should be entered using the following format: "Letter (Title of Magazine, Date)". If the letter has a title, append a colon, a space, and the text of the title: "Letter (Title of Magazine, Date): Letter Title".

Template:PublicationInfo:WhatToInclude has been updated to transclude Template:PubContents:Letters. Rules and standards changelog has been updated. We still need to decide what we want to do about letters published in magazines with non-standard titles. Ahasuerus 14:09, 16 May 2020 (EDT)

German Gold Mark standard symbol?

Hello all. I've come across 3 records that have the German Gold Mark (1873–1914) entered as, eg. ℳ 1.60. All other entries for the Mark are just 'M' (except for the 'modern' RM & DM variants). Which standard should we adopt? I'm personally in favour of just having 'M' (but I'm no currency expert...). And by extension, should we have older versions of the German Mark also just as 'M'? (see Wikipedia for a summary). MagicUnk 15:27, 5 May 2020 (EDT)

I submitted three such (spaced "ℳ 1.60") this "weekend". All for the Tauchnitz series Collection of British Authors, copy paste from User:Chavey P434347, who probably follows the series list in the book, pages 2-4 of the cover, eg #3128 back cover, May 1896. --Pwendt|talk 17:05, 5 May 2020 (EDT)

If you use a special symbol for the currency symbol ($ and so on, ℳ included), the space should not be there -- regardless of how the publisher used it. Annie 17:12, 5 May 2020 (EDT)

Any other editor from Germany that wants to chime in as to which symbol to use ? MagicUnk 15:09, 7 May 2020 (EDT)

Sorry to haven't recognized this threa(d)/(t) before.

Well, I'm not in particular favor of one possibility: the Gold Mark is a different currency than Marks, so there's something to be gained in separating the symbols. On the other hand, it's some work to sort things out (but I'll do a share of it if the decision is for separating). Christian Stonecreek 16:40, 7 May 2020 (EDT)

Preference on the symbol used? ℳ1.60? Just as a reminder, the help page says: "Enter East German Marks as "M", for example "M 7.80"." so M on its own is already taken.

We really need that drop down list so we can just put the NAMES of the currencies and it can show whatever is needed... One day one hopes. Annie 17:05, 7 May 2020 (EDT)

Yes, ℳ would be preferable (for me). Christian Stonecreek 00:58, 8 May 2020 (EDT)

OK, thanks for the input. I think we can safely say that for German Gold Mark (used from 1873 to 1914) the symbol to use is 'ℳ' (and no space). I've updated the help text accordingly, and added an explicit example. Cheers! MagicUnk 11:50, 8 May 2020 (EDT)

So what we do use between 1914 and 1948 and before 1873? If you are going to add years, make a complete chronology :) Annie 12:28, 8 May 2020 (EDT)

According to the Wikipedia article linked above:

Before unification in 1870, the different German states issued a variety of different currencies. ... Vereinsthalers were legal tender up to 1908. [But then it says] From 1 January 1876 onwards, the mark became the only legal tender.

From our perspective, the important thing is to capture the price in an unambiguous way. At some point we'll need to revisit the issue as per this 2017 discussion, but I guess "ℳ" should work for now. Ahasuerus 13:32, 8 May 2020 (EDT)

Well, we already have 386 Reichsmark (currently as RM) pub records in the DB (with perhaps some Rentenmark (1923-1924) thrown in for good measure - which we could add too if there's sufficient support for it - see below). So, we should at least add this Reichsmark to the list too. Wikipedia says: The Reichsmark (sign: ℛℳ) was the currency in Germany from 1924 until 20 June 1948 in West Germany, where it was replaced with the Deutsche Mark, and until 23 June in East Germany when it was replaced by the East German mark. Still a gap between 1914 and 1924, which had Papiermark and Rentenmark, but see below.

As for the period before 1873, that would indeed have to be looked at case by case, and in any case would require additional clarification in the notes. With adding ℛℳ (and perhaps Papiermark and Rentenmark too), we have closed the gap (or as good as - special cases, eg during transition periods, would require notes clarification). So, in summary, for the German Mark, usage would be as follows:

Before 1873: case-by-case
1873-1914: Gold Mark - ℳ
1914-1923: Papiermark - also ℳ + notes clarification (English: "paper mark", officially just Mark)
1923-1924: Rentenmark - RM
1924-1948: Reichsmark - ℛℳ
1948-1990: East German Marks - M
1948-2002: West German Marks - DM

The Papiermark-Rentenmark period may have to be simplified to keep it manageable. If so, then the list would become:

Before 1873: case-by-case
1873-1923: Goldmark/Papiermark - ℳ
1923-1948: Rentenmark/Reichsmark - ℛℳ
1948-1990: East German Marks - M
1948-2002: West German Marks - DM

But what do you think? Add it to the help text too? MagicUnk 16:28, 8 May 2020 (EDT)

And by the way, the symbol for Reichsmark appears to be ℛℳ, whereas our database currently has RM as abbreviation. So we should standardize RM (for the period 1924-1948) to the symbol ℛℳ (to be in line with the Gold Mark symbol and, obviously, because it appears to be the actual official symbol...).

And another thing: it looks like there's some cleanup to do as there are several pub records for the period 1924-1948 that are priced as just 'M' (whereas they should have been in ℛℳ), as there are for the period 1873-1914 that have to be updated and priced using ℳ. MagicUnk 16:28, 8 May 2020 (EDT)

You sound almost surprised that there is cleanup to be done in the DB... :)

Why ℛℳ and not just RM for 1923-1948 - it is our DB, as long as it is readable, we do not need to use exact symbols? The easier it is to type something, the more likely it is someone to actually stick to it and I cannot see how ℛℳ will be better than just RM - and officially letter representations are allowed if you cannot make the special symbols anyway (we explain that for the pound but it is valid for all weird character ones)) - then you have RM, M, DM and ℳ as valid for German books (based on the year (and which side of the Iron Curtain for the M/DM). ℛℳ is used for Reichsmark but not for Rentenmark I think so using RM is cleaner.

Better to stick to ℛℳ because ℛℳ is the official symbol, RM for Reichsmark is not. Also because RM for Rentenmark had been in use for 1 year only, so really we should represent Reichsmark correctly - and as I said above, we can ignore Rentenmark since it has been in use for 1 year only (or we could include it as in my proposal 1 above if we want to be all inclusive). Which does not invalidate your comment on letter representation, of course (letter representation could cause a minor inconvenience when you actually want to mean Rentenmark iso Reichsmark, but it would still be correct for the vast majority of entries (and yes, the same can be said for using ℛℳ as in proposal 2 above when wanting to enter Rentemark)). MagicUnk 07:49, 10 May 2020 (EDT)

M/ℳ will be easily separable even if someone uses M for the latter as there won't be space after it (M10.00/ℳ10.00 will be valid for anything pre 1923; M 10.00 for 1948-1990 without disambiguity). And I think we can use ℳ and a note for anything before 1873 (just to keep it simple). ℳ will need no space after the symbol; the other 3 will need space after the name of the currency. The more complex you make a system, the more likely is that it won't be followed - and some people work from old computers and small/weird screens. And don't rely on much of IT knowledge from the editors -- ℳ made be impossible/hard for someone (which is we have that note in the help allowing for letters to be used). Annie 17:56, 8 May 2020 (EDT)

We should not accommodate just for the sake of accommodating. Do consider the volume we're talking about - only a few pub records, all (most) of which are only of interest to bibliographers anyway I'd think. So to those people that really would know to make a distinction. Besides, moderators should also be able to catch any mistakes when incorrectly using the wrong symbol/letters. Also, it would be rather straightforward to identify any mistakes by correlating the symbols/letters with the years they've been valid currency (someday we would even be able to have a cleanup list, provided we'd have a table keeping the currency codes/symbols/validity period...).Also, I'd think that copy-paste (even for computer-illiterate editors) is no rocket science :) So, all in all, the volume of pub records that may cause issues is negligible in the overall scheme of things imo that it would not warrant a deviation from the formally correct (or at least as correct as possible) situation. So, still in favour of ℳ/ℛℳ/M or DM.
And a note on using ℳ for publications before 1873. Vereinsthalers for example, are not the same as (Gold) Marks, so I would be wary of extending the use of ℳ to before 1973. I cursory read through the Wiki article on Vereinsthalers and I couldn't find a valid abbreviation nor symbol though. So how to represent Vereinstalers in a pub record, no idea (yet). Regards, MagicUnk 07:49, 10 May 2020 (EDT)

1948-1990: East German Marks - M, this is to easy.

* Deutsche Mark der Deutschen Notenbank (DM) 24. Juli 1948 bis 31. Juli 1964

* Mark der Deutschen Notenbank (MDN) 1. August 1964 bis 31. Dezember 1967

* Mark (M) der Deutschen Demokratischen Republik (auch Mark der DDR) 1. Januar 1968 bis 30. Juni 1990

I am not interested in to add this currencies, but you can see them in the DNB. Just to make it more difficult Henna 14:51, 10 September 2020 (EDT)

Capitalization and international titles (again)

There was a discussion in 2018, which seems to have ended in agreement and plans, but I can't find much in the way of results for subtitles, particularly in French. My immediate problem is, as Annie forecast, which one is the correct one between Au XXIXe siècle : la journée d'un journaliste américain en 2889 and Au XXIXe siècle - La journée d'un journaliste américain en 2889? ../Doug H 15:24, 7 May 2020 (EDT)

A few stats: for French titles with Le, La, Les or L' after the colon

279 use the lower case 'l', 963 the upper case 'L'.
127 use upper case for the following word, 1,115 use lower case.

Well, to start with, we use ":" for subtitles. So thus "-" needs to be changed technically unless the part after that is not a subtitle - in which case it will be all small letters :)

This page is where we started discussing the languages. Nothing on subtitles for French. :( Check with Linguist and let's add it to the notes and follow it through. My preference is to keep it easy and just capitalize subtitles (treat them as titles) but... If not, we need a definitive list of which languages needs capitalization and which do not. :) Annie 16:26, 7 May 2020 (EDT)

Missed the dash, and checking the source it is indeed an em-dash, though they capitalize the L. ../Doug H 17:12, 7 May 2020 (EDT)

That solves the immediate problem -- both stay as they are (for now; the dash probably should be changed to m-dash plus spaces need cleaning ("Em-dashes should be entered directly adjacent to the words on both sides") - or leave as dash and the spaces around it) and get varianted until we figure out which one needs fixing for capitalization. The capitalization in the magazine is not really important (we standardize after all) - not sure if it is house style or French style or what :). But we do need to decide what we do with subtitles in general. Annie 17:24, 7 May 2020 (EDT)

Concerning the "colon" vs "dash" debate : in the original version, what we have here is a subtitle (very clearly so), in other words Au XXIXme siècle: La journée d'un journaliste américain en 2889 (this db style) or Au XXIXme siècle : la journée d'un journaliste américain en 2889 (French style).

About French subtitles in general : when the subtitle on the book is just written on a new line, it often (but not always !) appears with a capital letter, but it is quoted with a colon, and the rule in French is not to use a capital after a colon (and to put a space before it). When introduced by the preposition ou ("or"), the subtitle is considered as a new, separate title, and therefore usually takes a capital. But I don't think there are clear, formal rules about this, and many counter-examples can be found. Personally, I wouldn't sweat over it too much, and, as Annie said, keep it simple : Title: Subtitle, Title: ou Subtitle (when written on two lines) or Title ou Subtitle (when on one), for instance. Hope it makes sense. Linguist 05:15, 8 May 2020 (EDT).

More stats: For French titles

1794 use spaces on both sides of the colon, 3132 only on the right. 2 use a space before but not after and 8 use no spaces at all. I doubt we'll clean the two main ones up, but can we have a spacing rule? (e.g. preferred but not rigid). With this many titles, I wouldn't be surprised some actual titles have colons and the spacing is correct.
" ou:" - 18, although 17 are ": ou:"
" ou :" - 8
" ou," - 10, always ": ou," followed by a capital, although mixed capitals after that. Unsure if these are part of the title or subtitles.
" ou " - 110, but not always clear if in the full title or separating sub-titles so
": ou " - 17, with 12 followed by lower case, 4 by upper case (other has "...: ou bien: ..."). And one lower case has capital Ou.

If we adopt this as our 'rule', it shouldn't be too hard to clean the punctuated ones up. ../Doug H 12:38, 8 May 2020 (EDT)

A lot of our old publications have policy-related issues - some because policies changed, some because people ignored policies, some probably because someome messed up. For smaller languages, cleaning them up is easy and I had been working through some of them. For the bigger ones (bigger in the DB), it get complicated. French is actually in a better shape than Italian for example - both French moderators had been ignoring the English-based rules even before we made it English-only; in Italian most of the old titles follow English capitalization rules (and it should not - Italian is sentence case like most languages that are not English). Spacing comes from the French rules -- in any other language, the punctuation symbol goes next to the previous work; in French, they have a space before :, !, ? and so on... In the last few years, we had been trying to keep that in mind and fix the new titles coming in.

So yeah - these can use some TLC -- it comes down to time and effort sometimes though. Annie 13:40, 8 May 2020 (EDT)

So can we add:

Title : Subtitle, Title : ou Subtitle (when written on two lines) or Title ou Subtitle (when on one)
Punctuation has a space before :, !, ? and so on...

to the Title Regularization? Although I'd like to confirm we add the word "ou" with subtitles and the colon only if it's on a second line. Or is this assuming the "ou" was already there? And is the comma (,) excluded from the punctuation that has a preceding space (as per all the 407 existing records)? And do we normalize the capitalization as if it were a subtitle if there is an actual colon in the title? ../Doug H 14:02, 8 May 2020 (EDT)

It is a working page so go ahead and add it there; Linguist can update/fix if needed later. Or wait for him to confirm here - from all the European languages, the punctuation of French had always been the most mystifying for me. The page was supposed to produce a real help page when we get people's opinions and knowledge assembled - I probably need to put it on my priority list again.Annie 15:38, 8 May 2020 (EDT)

(unindent) I've posted my interpretation in the Title Regularization page. Feel free to amend. Thanks for helping. ../Doug H 21:32, 8 May 2020 (EDT)

Entering US territories

Template:AuthorFields:BirthPlace says:

Use the "City, Administrative division, Country" format, e.g. "Ante, Champagne, France" or "Annapolis, Maryland, USA".

Based on this language, we have a cleanup report which looks for names of US states which are not followed by ", USA" or, for the original British colonies, "British Empire".

What Help and the cleanup report do not address is the issue of US "territories", i.e. locations under US jurisdiction which are not US states. There are two types of territories: "incorporated" and "unincorporated". (Territories can also be "organized" and "unorganized", but I don't think we have to worry about that.)

Incorporated Territories

"Incorporated territories" were proto-states -- Florida, Arizona, Oklahoma, etc. The last two, Alaska and Hawaii, became US states in 1959. When entering their names, sometimes we use the word "Territory" while other times we don't. For example:

Jim Thompson: Anadarko, Oklahoma Territory, USA, 27 September 1906
Clifton B. Kruse: Bartlesville, Oklahoma, USA, 14 November 1905

The question then is which format we want to adopt as our standard. My current thinking is that it would be better to include the word "Territory", in part because it would help with more complex cases. For example, Alaska was a possession of the Russian Empire prior to 1867, a US "Department" in 1867-1884, a "District" in 1884-1912, and an incorporated "Territory" in 1912-1959. It would be odd to use "District of Alaska" (see Barrett Willoughby), but not "Alaska Territory".

Unincorporated Territories

Unincorporated territories are locations with a looser relationship with the US government. Most are uninhabited islands -- see this Wikipedia list, so we don't have to worry about them. The 5 that are inhabited are:

Puerto Rico
Guam
United States Virgin Islands (not to be confused with British Virgin Islands)
American Samoa
Northern Mariana Islands

For Puerto Rico and US Virgin Islands, we use "Puerto Rico" and "US Virgin Islands" respectively without adding ", USA". We don't have any records for the other unincorporated territories.

I propose that we codify the current usage pattern, i.e. do not use ", USA" for unincorporated territories, in Help.

Ahasuerus 12:31, 9 May 2020 (EDT)

Uncountable nouns vs. plural nouns

I propose a trivial text change, "less" to fewer", in the Help here. It's a common mistake. Thanks, Kev. BanjoKev 11:46, 12 May 2020 (EDT)

English is weird. And yes - it should be fewer technically :) Annie 12:34, 12 May 2020 (EDT)

Try this on your bookshelf Annie :) Kev. BanjoKev 13:09, 12 May 2020 (EDT)

One of my English teachers had the 1973 edition and really liked sharing pages of it. :) It is a fun book. I think I have one of the American editions somewhere around the house. Although I always found Swan (in all his editions) to be better at actually explaining it for audience that grew up with a different language. :) 14:03, 12 May 2020 (EDT)

I've made the change to the page. Good for that teacher! Was it an English teacher or a teacher of English? :) Anyway, why am I not surprised you have 'Usage' :) Kev. BanjoKev 15:31, 12 May 2020 (EDT)

Strange values of pub_year

The SQL query

SELECT pub_id, pub_year,year(pub_year),month(pub_year),day(pub_year), CAST(pub_year AS CHAR) from pubs 
	where CAST(pub_year AS CHAR) rlike '^....-00-[1-9][0-9]' or CAST(pub_year AS CHAR) rlike '^....-00-0[1-9]'

returns

pub_id|pub_year  |year(pub_year)|month(pub_year)|day(pub_year)|CAST(pub_year AS CHAR)|
------|----------|--------------|---------------|-------------|----------------------|
289806|1984-12-01|          1985|              0|            1|1985-00-01            |
423540|1969-12-04|          1970|              0|            4|1970-00-04            |
287914|1987-12-01|          1988|              0|            1|1988-00-01            |
289771|1959-12-09|          1960|              0|            9|1960-00-09            |
289772|1959-12-09|          1960|              0|            9|1960-00-09            |
289773|1959-12-12|          1960|              0|           12|1960-00-12            |
289774|1959-12-12|          1960|              0|           12|1960-00-12            |
292084|1959-12-07|          1960|              0|            7|1960-00-07            |
292119|1959-12-06|          1960|              0|            6|1960-00-06            |
292120|1959-12-06|          1960|              0|            6|1960-00-06            |
292121|1959-12-07|          1960|              0|            7|1960-00-07            |
292313|1980-12-01|          1981|              0|            1|1981-00-01            |
345477|1966-12-08|          1967|              0|            8|1967-00-08            |
346073|1980-12-01|          1981|              0|            1|1981-00-01            |
373806|1992-12-01|          1993|              0|            1|1993-00-01            |
385783|1969-12-01|          1970|              0|            1|1970-00-01            |
382804|1972-12-01|          1973|              0|            1|1973-00-01            |
391349|2000-12-01|          2001|              0|            1|2001-00-01            |
400363|1959-12-11|          1960|              0|           11|1960-00-11            |
400662|1959-12-11|          1960|              0|           11|1960-00-11            |
400667|1959-12-10|          1960|              0|           10|1960-00-10            |
400668|1959-12-10|          1960|              0|           10|1960-00-10            |
407162|1948-12-01|          1949|              0|            1|1949-00-01            |
407829|1995-12-10|          1996|              0|           10|1996-00-10            |
407828|1995-12-05|          1996|              0|            5|1996-00-05            |
411538|2000-12-05|          2001|              0|            5|2001-00-05            |
416723|1989-12-01|          1990|              0|            1|1990-00-01            |
417097|1989-12-02|          1990|              0|            2|1990-00-02            |
417885|1989-12-03|          1990|              0|            3|1990-00-03            |
418396|1990-12-02|          1991|              0|            2|1991-00-02            |
421682|2005-12-01|          2006|              0|            1|2006-00-01            |
421752|2005-12-02|          2006|              0|            2|2006-00-02            |
423364|1970-12-06|          1971|              0|            6|1971-00-06            |
424583|1969-12-03|          1970|              0|            3|1970-00-03            |
424602|1969-12-05|          1970|              0|            5|1970-00-05            |
427670|1970-12-01|          1971|              0|            1|1971-00-01            |
427817|1970-12-03|          1971|              0|            3|1971-00-03            |
428827|1970-12-04|          1971|              0|            4|1971-00-04            |
436504|2009-12-07|          2010|              0|            7|2010-00-07            |
498744|1958-12-01|          1959|              0|            1|1959-00-01            |
502981|1957-12-01|          1958|              0|            1|1958-00-01            |
517391|1999-12-01|          2000|              0|            1|2000-00-01            |
517492|1999-12-02|          2000|              0|            2|2000-00-02            |
553047|1852-12-10|          1853|              0|           10|1853-00-10            |
583073|1999-12-17|          2000|              0|           17|2000-00-17            |
584537|1999-12-18|          2000|              0|           18|2000-00-18            |
582980|1999-12-22|          2000|              0|           22|2000-00-22            |
583159|2013-12-21|          2014|              0|           21|2014-00-21            |
587906|1986-12-01|          1987|              0|            1|1987-00-01            |
589994|1960-12-02|          1961|              0|            2|1961-00-02            |
589996|1960-12-01|          1961|              0|            1|1961-00-01            |
590163|1968-12-01|          1969|              0|            1|1969-00-01            |
590164|1968-12-02|          1969|              0|            2|1969-00-02            |
590165|1970-12-01|          1971|              0|            1|1971-00-01            |
597297|2005-12-03|          2006|              0|            3|2006-00-03            |
598085|2006-12-02|          2007|              0|            2|2007-00-02            |
598215|1975-12-03|          1976|              0|            3|1976-00-03            |
602167|1960-12-01|          1961|              0|            1|1961-00-01            |
602556|2005-12-04|          2006|              0|            4|2006-00-04            |
607934|1971-12-01|          1972|              0|            1|1972-00-01            |
608126|2004-12-01|          2005|              0|            1|2005-00-01            |
608127|2004-12-02|          2005|              0|            2|2005-00-02            |
608130|2004-12-03|          2005|              0|            3|2005-00-03            |
612631|1959-12-06|          1960|              0|            6|1960-00-06            |
630721|2000-12-02|          2001|              0|            2|2001-00-02            |
649179|1996-12-01|          1997|              0|            1|1997-00-01            |
655881|1926-12-01|          1927|              0|            1|1927-00-01            |
690599|1959-12-08|          1960|              0|            8|1960-00-08            |
715412|1959-12-08|          1960|              0|            8|1960-00-08            |
717386|2018-12-01|          2019|              0|            1|2019-00-01            |

i.e. with a number of entries, the value shown on the web (see http://www.isfdb.org/cgi-bin/pl.cgi?289806 for the first row) is 1985-00-01 (invalid) instead of 1984-12-01 (valid). Similarly, Nov. 30th seems to be some special date. See

SELECT pub_id, pub_year, year(pub_year),month(pub_year),day(pub_year), CAST(pub_year AS CHAR) FROM pubs 
	WHERE CAST(pub_year AS CHAR) RLIKE '^....-00-[0-9][0-9]'

where the first few lines are

pub_id|pub_year  |year(pub_year)|month(pub_year)|day(pub_year)|CAST(pub_year AS CHAR)|
------|----------|--------------|---------------|-------------|----------------------|
398844|1840-11-30|          1841|              0|            0|1841-00-00            |
     2|1998-11-30|          1999|              0|            0|1999-00-00            |
     3|1891-11-30|          1892|              0|            0|1892-00-00            |
     5|2001-11-30|          2002|              0|            0|2002-00-00            |
     6|1994-11-30|          1995|              0|            0|1995-00-00            |
     7|1991-11-30|          1992|              0|            0|1992-00-00            |
398171|1991-11-30|          1992|              0|            0|1992-00-00            |

In particular, the special date 8888-00-00 shows for pub_year always as 8887-11-30. DB version used is: mysql Ver 15.1 Distrib 10.3.22-MariaDB, for debian-linux-gnu (x86_64) --WolfgangRieger 03:39, 18 June 2020 (EDT)

I have run the same queries on the development server which has MySQL 5.5.17/Win64 installed. Unlike what you are seeing under 15.1, there is no difference between the values displayed in "pub_year" and "CAST(pub_year AS CHAR)". I suspect that the differences in observed behavior are due to one or more of the following issues:

Database version mismatch
Settings mismatch, especially the settings that allow invalid "date" values as is the case on the ISFDB server

Ahasuerus 12:26, 18 June 2020 (EDT)

FWIW, I just ran that query on my - somewhat in need of an update - Fedora 26 box, and didn't see any issues either. MySQL/MariaDB version info:

    $ mysql --version
    mysql  Ver 15.1 Distrib 10.1.33-MariaDB, for Linux (x86_64) using readline 5.1

Server settings should be whatever the Fedora/MariaDB defaults are. Timezone is UTC+1/BST. ErsatzCulture 13:08, 18 June 2020 (EDT)

I've seen this before - the problem is the date format - aka - do you expect the months as 00-11 or 01-12 during the cast. Why are you using CAST for date/time-related fields at all - it can have unexpected side effects based on configuration(such as the one you stumbled upon)? Annie 15:06, 18 June 2020 (EDT)

In WolfgangRieger's tables shown above, the CAST is the correct value & the pub_year values are the wrong ones. The ISFDB allows 00s in the date values which is not handled by all database library bindings. The CAST bypasses the issue. -- JLaTondre (talk) 16:31, 18 June 2020 (EDT)

Ah, yes - true (I am not sure what I was thinking about really above) - but yeah, the problem is the ability to use 00 in each field... :) Annie 16:51, 18 June 2020 (EDT)

Whatever the problems with my DB version/DB setup might be, a date like 1985-00-01 is IMHO invalid. If the month is 0, the day has to be 0 too. And the value 1985-00-01 is shown in http://www.isfdb.org/cgi-bin/pl.cgi?289806. --WolfgangRieger 03:27, 19 June 2020 (EDT)

It's certainly true that dates like "1985-00-01" are invalid. I can't think of any scenarios that would necessitate their use. We should probably enhance our pop-up validation to disallow them. We could also create cleanup reports to find and correct existing errors. Ahasuerus 10:49, 19 June 2020 (EDT)

This is the value returned by the ISFDB server, not by my DB installation. As regards the library bindings, the Python connector for MariaDB I'm using returns NULL for all dates containing 00s. So I cast to string in the query and use a custom class for publication dates, which handles the specifics of date comparison. Furthermore, there are apparently issues with date handling in MySQL and incompatibilities in date handling in MySQL vs. MariaDB. Therefore one might question the wisdom of using the date type in the pub_year column, given that the use in ISFDB is non-standard to begin with. --WolfgangRieger 03:27, 19 June 2020 (EDT)

There are certain issues with MySQL dates, e.g. dates prior to 1000-01-01 are not officially supported and BCE dates can't be entered. However, creating a custom data type for ISFDB dates would involve a great deal of work, so it's very unlikely to happen. Other free databases like PostgreSQL support BCE dates, which is something to consider if and when we decide to change the underlying database technology. Ahasuerus 10:49, 19 June 2020 (EDT)

Well, I used the YYYY-00-XX date for a few cases where it is known that a certain title / publication was published after another one, but the exact month of publication is not known. I think it is meaningful for those few cases. Christian Stonecreek 12:25, 19 June 2020 (EDT)

Once FR 794, Add 'Printing number' and "Printing # Details" fields to pub records, has been implemented, we may be able to revisit this issue and improve the way we present the data. Ahasuerus 10:54, 25 June 2020 (EDT)

Note on kana transliterations (Japanese)

I added (as a clarification) the following to Template:TitleFields:TransliteratedTitle, which also appears on Help:Screen:EditTitle:

For languages that do not generally include spaces (such as Japanese and Chinese), use the same spacing as used in the original title.

This was a result of this discussion. ···日本穣 · 投稿 · Talk to Nihonjoe 12:52, 18 June 2020 (EDT)

I am in two minds about this change and I think that we should have had a discussion before it was changed in the rules to explicitly specify a rule (As opposed to pointing to a preference). When we add transliteration to an English title which is spelled weirdly (words running into each other or symbols used and so on), we will standardize it thus allowing a search to find it. One of the main functions of the transliterations is to make it easier to find something in the DB - which is why I leave older transliterations where I find them in my languages - even if they are not the standard now, they had been once upon a time. While writing in Japanese rarely includes spaces, the users of the language, especially native speakers, may have gotten used to searching based on "Western" patterns due to how things had been presented online historically (just like with the Slavic languages - Cyrillic or not). So if someone wants to add both a spaced and a non-spaced Kana (or romanized) transliterations), I would not have a problem with that -- especially if they are a user of the language and search that way. Now, my Japanese is down to being able to read Kana and a handful of words so I may be wrong but still my 2 cents...

If we are going to enforce single rules, we will need to have a "how to search" page somewhere that spells out all the rules. But that sounds like a step back for me from where we are now. It is probably not a bad idea to have the page anyway - so people know what to expect but even with it, the most likely to be used search ways should really work no matter what. Annie 12:51, 22 June 2020 (EDT)

My knowledge of Japanese is almost non-existent, so I can't really comment on the specifics. That said, if NDL, the national library of Japan, is using a certain way of entering data and a native speaker says even I cannot state boldly that "general public" uses "this way" or "that way", I think it's at least worth looking into. Ahasuerus 15:04, 22 June 2020 (EDT)

Seems to me the better approach is to allow both translieration variants. No harm in that. MagicUnk 01:50, 23 June 2020 (EDT)

I don't have a problem with including both, but Arctorbob seems to be wanting to use spacing between words without including the unspaced version. If we pick one or the other, I strongly prefer the one that follows the spacing used in the title because that mirrors how we use the form on the title page (for both names and titles), even if it's unusual. If we do include the version of kana with spacing, we will have to decide whether to space out particles (since they are--technically--separate words). We already include Romanized versions of は as both "ha" and "wa" (at least I do), and we use "English" spacing for the Romanization since (at least in part) it would otherwise be very difficult to read. In all the time I've been entering Japanese titles here, this is the first time anyone has ever mentioned using spaces in kana transliterations. I've used the NDL many times in the past (they are great for finding readings of names), and I suspect this might be a new thing there, too, as I've never noticed them using spacing before. ···日本穣 · 投稿 · Talk to Nihonjoe 13:19, 23 June 2020 (EDT)

I do not get the feeling that he is advocating for "use only spaced" -- if anything, he reminded you that it is a multi-field after you decided to change the rules and explain to him that we have a preferred version. So can we please revert that change in the rules text (I will be happy to if you rather not) and do we agree that both are acceptable? If you want to start a special topic on "Transliteration in Japanese", feel free to and hash out whatever else is needed but as the rules stand now, both spaced and non-spaced are valid and neither should be rejected (or corrected to the other one). :) Annie 13:29, 23 June 2020 (EDT)

I guess we're reading his comments differently, then. How about this wording:

Transliterated Title. Populate only if the title is spelled using a non-Latin alphabet/script. If you know the Romanized form of the name, enter it in this field. If there is more than one possible Romanization, click the '+' button next to the field label and enter the other Romanized spellings of the title. You can click on the '+' button as many times as necessary. For languages that do not generally include spaces (such as Japanese and Chinese), use the same spacing as used in the original title. For Japanese, including a kana transliteration with spaces between words is acceptable as long as one with the same spacing as the original title is also included. This field is not to be used to enter English translations, which can be added to Notes if known.

Will that work? ···日本穣 · 投稿 · Talk to Nihonjoe 14:48, 23 June 2020 (EDT)

I am not sure why you keep insisting on mixing up Chinese and Japanese here -- if your new rule (either the one you just proposed or the one you had changed the rules to previously) needs to apply, none (or almost none) of the Chinese transliterations we have at the moment will be valid. Plus the way you had it changed to, implies that ALL transliterations of Japanese need to be following the no-spaces rule -- and this is not what we do for romanization. Additionally, technically, if you leave it as is, the Kana is not allowed at all because we use the word "Romanization". So this whole paragraph needs a complete overhaul. :)

So why don't we try to rebuild this whole section so it reflects what it actually is used for (we use it for Latin languages when they use special characters, we allow Kana and so on). What we are trying to have is:

At least one version with Latin characters.
Any other versions in alphabets/syllabaries and other writing systems which are native for the language (Kana for Japanese for example). Do we want to allow Arabic and/or Cyrillic for languages which use more than one writing system (there are a few languages that had historically flipped between the three of them and Serbian can be written in both forms (or could for a very long time)).
(Any language specific rules -- your Japanese one if a majority agrees).

So why don't we revert the changes and actually have a discussion on how to get this section to reflect what we actually do on the site and what we want to do on the site? Annie 15:11, 23 June 2020 (EDT)

I’m a third generation Japanese-American and I thought I’d add my two bits here. English is my first language and Japanese school is more decades ago than I care to admit to. Having said that, I think that spacing transliterations in Kana would cause search problems for native speakers. In my experience, spaces are normally only used to separate given from family names, and paragraphs.

No problem with romaji, since it would mostly be used by non-native speakers. Maybe spaced kana would be ok if the search engine could be reworked to strip out spaces when searching in kana/kanji?

I would like to point out that kana is not an alphabet, it’s really a syllabary, in that each character represents a syllable. Rkihara 16:13, 23 June 2020 (EDT)

Fixed the syllabary thing in my write-up - you are indeed correct that Kana is not an alphabet (and Arabic is technically using an abjad) - I was using alphabet as a shortcut to writing system and I know better than that. :)

So how about allowing both spaced and non-spaced kana? We are not discussing always spacing but allowing spaced kana in addition to the non-spaced one - we can add that as a specific rule for Japanese transliterations in Kana (as Nihonjoe's latest revision is trying to). Is there a reason not to allow the spaced one (if the non-spaced is also there)? Annie 16:29, 23 June 2020 (EDT)

Annie: Who is "mixing up Chinese and Japanese"? They were given as examples of languages that don't normally have spaces in the written language, which is true. And it's not a "no spaces" rule, it's a "use the spacing found in the title when giving a kana transliteration" rule. Arctorbob is correct that some titles have spaces in them. I've never argued with that. This is what we currently do with all transliteration, regardless of the language. It's just not explicitly stated for languages that use Latin characters (or others that use spaces normally) since it's not necessary to state because they already employ spacing between words. It wouldn't invalidate any of the Chinese transliterations at all as all of the Chinese transliterations are in Roman/Latin characters (at least I've never seen any here in any other script).

You mix them up in the proposed (and edited...) rules - I am trying to point out that neither for Japanese, nor for Chinese, we follow that rule (no spaces in the original, so no spaces in the transliteration) when we romanize; the rule will apply only for Kana (or at least for one of the Kana translitearions) (and consequently Japanese). Saying that Chinese or Japanese need to be transliterated without spaces in romaji/pinyin is not exactly correct or the practice. Hope this clarifies that point. :)Annie 16:29, 23 June 2020 (EDT)

Regarding your bullet points:

Yes, this one is obvious.
Yes, I see no issues there, as long as there's evidence they are applicable.
Yes, no issues there.

I'm not seeing disagreement except where you're apparently misinterpreting what I wrote. I'm open to other wording since it's obviously not clear enough to convey what I meant. ···日本穣 · 投稿 · Talk to Nihonjoe 16:20, 23 June 2020 (EDT)

I disagree with the exact way it is written - not with the spirit of the latest proposed changes (aka the spaced is allowed as long as there is also a non-spaced Kana). :) I am in agreement with the last proposal as long as we actually fix that whole paragraph - so let's work on that :) Annie 16:29, 23 June 2020 (EDT)

(unindent)Proposed language:

Populate only if the title is spelled using a non-Latin alphabet/script or if it is written in the Latin script but contains characters with diacritics (such as ą or ć), other non-standard characters such as ł and Æ, non-standard representations of words (for example the word Three spelled as Thr33) or other cases which will impede the search for the title.

If there is more than one possible transliteration, click the '+' button next to the field label and enter the other spellings of the title. You can click on the '+' button as many times as necessary.

When adding the transliterations, the following rules should be followed:

At least one of the transliterations should be a Romanization (aka using the Latin alphabet).
If a writing system different from Latin is used for the transliteration (i.e. Kana, Arabic abjad and so on), it needs to be native to or used by the language that is being transliterated (in the current times or historically) - i.e. do not transliterate a Japanese title into the Cyrillic script as Japanese never used the alphabet.
When transliterating Japanese, including a kana transliteration with spaces between the words is acceptable as long as one with the same spacing as the original title is also included.

This field is not to be used to enter English (or other) translations or original and/or alternative titles. These can be added to Notes if known.

Will that work and cover everything a bit better? The middle rule (the non-native exclusion) is so that we do not end up with a flood of Cyrillic transliterations of Japanese (and other languages). Annie 16:49, 23 June 2020 (EDT)

That works for me, though I've never seen a submission where the submitter tried to include alternates like what you described (using Cyrillic for Japanese). I suppose it could happen, though. ···日本穣 · 投稿 · Talk to Nihonjoe 18:49, 23 June 2020 (EDT)

Submission - no. Being asked if they can (not for Japanese but for a Latin-based language) - yes. Thus thinking of it. A Bulgarian or a Russian, adding a translation for a Japanese story and adding the original may decide to add transliteration based on the translation language (as those were even occasionally printed in books). Cyrillization and Romanization are both transliterations after all - all depends on what languages you know. Not very likely, I agree, but if we are going to make the rules generic, we may as well and at least everyone knows that Japanese never used Cyrillic. We can change the language with another if you prefer :) Annie 19:07, 23 June 2020 (EDT)

No, it's fine. ···日本穣 · 投稿 · Talk to Nihonjoe 12:05, 24 June 2020 (EDT)

The first thing that comes to mind is that the ISFDB Help text currently contains the following "Transliterated" templates and page sections:

Also, Help:Screen:PublicationSeries says "...five fields which are similar to the fields found in Publisher records: "Name", "Transliterated Name", ... See Publisher-specific Help pages for more information on what to enter in these fields."

Currently these templates and sections are short and say (effectively) the same thing. If we are going to expand the language, we probably need to create a single Template and link the other templates/pages to it. It will help avoid the kind of divergence and confusion that we have seen with other Help pages.

The second thing that comes to mind is that the first paragraph of the proposed Help text can be difficult to parse if you are not familiar with transliterations. The language also doesn't explain while we don't have a transliterated value for "Philip José Farmer" or mention digits/punctuation. It may be better to agree on an explicit list of characters, change the Help language to something like "any characters that are not in the Latin-1 list of characters" and then link to it. Of course, we will first want to review all Latin-1 characters and make sure that we are OK with everything in the second half of the character set. Ahasuerus 15:40, 24 June 2020 (EDT)

So any proposal how to say the same in a better way? I don't mind it being restated. Annie 16:04, 24 June 2020 (EDT)

I think the first issue that we want to address is the list of Latin characters that do not require transliteration. If we state that "Latin-1 characters do not require transliteration" and link to the Latin-1 character set, we will be saying that not only "e", "è", "é", "ê" and "ë", but also "ð", "þ", and "ÿ" do not require transliteration. Is that really what we want to say?

I don't think so -- those are exactly the symbols I will want transliterated so we I can search without trying to remember the exact spelling in Icelandic or switch to its keyboard. But I will be fine if we decide this is what we do want to say if that will get the Central European languages sorted out. On the other hand, even when not needed, transliterating these symbols does not cause harm and noone is going to check the list if someone transliterates anyway so not sure if that would be really a problem... Annie 17:12, 24 June 2020 (EDT)

Alternatively, we can approach this topic from the opposite direction. Instead of saying "Latin-1 characters do not require transliteration", we can say "Names and titles that includes characters outside of the Latin-1 character set need transliteration (if known)". It will make transliterating non-ASCII Latin-1 characters like "ð" optional. Ahasuerus 16:43, 24 June 2020 (EDT)

We may want to add that transliterating any Latin-1 character that does not belong to the English alphabet or has a diacritics sign is optional (or we will have overzealous moderators rejecting a transliteration of letters from Latin-1). On the other hand, it makes c-cedilla optional while t-cedilla (and the rest of the much rarer cedillas) is mandatory which makes no sense at all (I know it is how it is but it always puzzled me in the Latin-1). Alternatively, we can list which of the Latin-1 are optional (c-cedilla but not è for example) thus allowing for the weird ones to be handled while leaving the standard ones in place. Annie 17:12, 24 June 2020 (EDT)

Well, Latin-1 is an 8-bit character set, which means that it's limited to 256 characters. The first 128 were already set in stone when the standard was being developed, which left the designers with 128 characters to play with. There was no way to squeeze every Latin-derived character in, so they had to pick and choose. Since our database uses Latin-1 (for now), any non-Latin-1 character needs to be transliterated if searches are to work intuitively.

In any event, we may want to split this issue into 3 smaller, more manageable issues. First, create a single "Transliterated Values" template and consolidate the duplicative "transliterated" Help language. Second, update the new template with the proposed kana language. Third, revisit the rest of the issues raised above as a new R&S discussion. That way we won't get sidetracked. Ahasuerus 11:31, 25 June 2020 (EDT)

We cannot update the language for Kana before we actually allow Kana so we will need to fix that whole paragraph anyway. :) Splitting the “when to transliterates Latin alphabet titles” will be fine. Annie 12:49, 25 June 2020 (EDT)

Polish złoty

I noticed that publications with Polish price are written primarily as zł 110.00. However, I've seen zł29.90 / 24.90 zł / zł 50.- / zł 280,- / even zł 17 (Polish złoty). Just wanted to check in and confirm these all should be normalized to zł 100.00, right? MagicUnk 15:05, 13 August 2020 (EDT)

We used to be more free form, but the current rules specify that 1) the currency symbol/abbreviation goes before the number and 2) that if it's a symbol there should be no space and if it's an abbreviation there should be a space. It also states that a period should be used as the decimal separator and comma as the thousands separator, regardless of currency. For whether or not decimals should be included, that is dependent on the currency. Since the samples you provide have them, I assume it makes sense for Polish prices. That means zł 110.00 should be the format. -- JLaTondre (talk) 19:04, 13 August 2020 (EDT)

Thought so too. Thanks for the confirmation! MagicUnk 06:10, 14 August 2020 (EDT)

Resolving genre vs nongenre when tags disagree with the flag

(Apologies if this is something that's been discussed before, but a very brief Wiki search didn't find anything relevant.)

KJ Parker's Sixteen Ways to Defend a Walled City is currently flagged as NONGENRE, despite having 5 different tags containing the word "fantasy". A sequel was recently published, but is currently marked as genre, which means that it appears in a completely different section of the author's bibliography page, which is a tad disconcerting. Questions:

Who - if anyone - is the ultimate arbiter of whether a title is NONGENRE or not? Is this something that could/should be picked up by a report? e.g. fiction titles that are marked as NONGENRE but have one or more of the main genre tags? (NB: I haven't read either of these books, so I've no idea how genre or not they may be - I just came across the more recent one as part of my backlog of recent UK pubs that need adding.)
The two titles aren't currently defined as being in a series - Goodreads has them as The Siege #1 and #2). Whilst I naively wouldn't expect adding them in their current states to a new series to break anything, I'm mildly curious how this would be displayed on the bibliography page. I could imagine there are existing series that start off NONGENRE, but turn GENRE, anyone know of any examples? ErsatzCulture 18:27, 21 August 2020 (EDT)

If the second book is a sequel, they should be connected in a series - and that will put them in the same place in on the page (with one genre book, the series becomes genre). So just add them to a series - no worries. There are series like that - where the author is above threshold (Parker is) so we add the non-genre books as well.

As for who is the arbiter - the community... usually someone who actually reads the book :) When we disagree, we discuss. I tend to lean towards genre when it is even a smidgen in but I had not read that one yet so no idea :(.

Tags are not moderated - anyone can add any tag so we rarely do anything based on them. And fantasy can mean "our type of fantasy" but it also can be "fantasy as in someone mental fantasy". So... :) Annie 18:34, 21 August 2020 (EDT)

Yes, as Annie says, discussion is the correct solution. I'm currently reading this & disagree with the non-genre. While no magic, etc., it is set in an alternate world and has the feel of a genre work. Per the edit history, Biomassbob applied the tag so I will talk with him. -- JLaTondre (talk) 18:14, 23 August 2020 (EDT)

Clarifying Synopsis Help

Template:TitleFields:Synopsis currently says:

A short non-spoiler synopsis can be entered here. Note that this is not a place for criticism or reviews, and should maintain a neutral point of view. It must be in English, even if the title's language is not English. State the source of the text if you didn't write it yourself.

The first ISFDB 2.0 version of this Help template only said that the data in the Synopsis field:

should maintain a neutral point of view

This guideline was based on the assumption that synopses would be primarily written by our editors. The reality, however, has been different. Many ISFDB synopses come from publisher descriptions, blurbs, Library of Congress Cataloging-in-Publication Data summaries, etc. For this reason the Help template was latter updated to say:

State the source of the text if you didn't write it yourself

Naturally, blurbs and other publisher-provided descriptions do not always "maintain a neutral point of view" because they are effectively advertisements. They can also be misleading in subtle and even not so subtle ways.

In order to clarify how editors should enter synopses from secondary source, I propose that we change the language as follows:

If you wrote the synopsis yourself, make sure that it maintains a neutral point of view. If the synopsis comes from another source like a blurb or a bibliographic note, enclose the text in quotes and state its source. If you omit parts of the quoted text, replace the omitted words with three periods (...)

The intent of the change is to accurately document how we have been handling synopses. The full text of the rewritten template will be:

Enter an optional short non-spoiler plot summary. It must be in English even if the title's language is not English. Note that this is not a place for criticism or reviews.
If you wrote the synopsis yourself, make sure that it maintains a neutral point of view. If the synopsis comes from another source like a blurb or a bibliographic note, enclose the text in quotes and state its source. If you omit parts of the quoted text, replace the omitted words with three periods (...)

Ahasuerus 15:07, 5 September 2020 (EDT)

Yes, that'd be okay with me. Stonecreek 15:18, 5 September 2020 (EDT)

In light of the original discussion, should we add something along the line of 'if you adapt text you've not written, clearly state so'? MagicUnk 15:34, 5 September 2020 (EDT)

Nope, this is the whole point. You do not "adapt" someone's writing under these rules and under the spirit of the field. You either cite an external source (with omissions) OR you write your own. The rule as written does not allow a "let me grab this from somewhere and rewrite it even though I have no clue how valid it is or what is safe to change". Annie 16:52, 5 September 2020 (EDT)

OK :) so add 'If the synopsis comes from another source, do not adapt it,...' to the rules?

Other question: what about a translation into English of a foreign-language blurb for example? (I've done some of these). For me at least it's not so easy to literally translate (and Google translate shouldn't be relied upon too heavily if you want to end up with more-or-less proper English...), so I suspect some (inadvertent) adaptation will happen in this translation case. Should we add 'for translations of a non-English blurb, stick as close to a literal translation and add 'translated into English from 'source' ' to the updated rules proposal? MagicUnk 08:22, 6 September 2020 (EDT)

I like the language (and it matches what had been allowed in the field in the last years anyway). Annie 16:58, 5 September 2020 (EDT)

I agree with the proposal. A few questions though, who will explain what happened to RedDragonBooks (he answered on his talkpage two days ago) and who will undo all the bad and unwanted adaptations. --Willem 17:26, 5 September 2020 (EDT)

As soon as this is officially approved, I will work with RedDragonBooks -- and undo all the edits. Won't be the first time I chase bad edits through the DB and restore them back to policy :) Annie 17:40, 5 September 2020 (EDT)

Yeah, me too. Can't expect Stonecreek to clean up his own mess now can we. --Willem 17:47, 5 September 2020 (EDT)

Having to redo/restore records can be understandably frustrating, but let's not let our frustrations get the better of us.

I have restored the last full backup on the development server and identified all of RedDragonBooks' submissions. He created 112 submissions in August and 18 in September; almost all of them were "Edit Title" submissions. I can create a list of submission URLs and make it available to volunteer moderators. Ahasuerus 20:41, 5 September 2020 (EDT)

I can lend a hand, if needed. Regards, MagicUnk 08:22, 6 September 2020 (EDT)

I like this. Whether it would be too much detail, I think it might make sense to be a little stronger/stricter about synopses from other sources. Something like:

A synopsis from another source may be used, in whole or in part, and the source must be cited. An English synopsis should be quoted verbatim, while a non-English synopsis should be translated, following the original as closely as possible. Use an elipsis/three periods ("...") for omitted text. Individual words may be replaced for clarity, with the replacement enclosed in square brackets ("[]").

I think that is "standard" treatment of quoted material. I don't know if it's necessary to say anything about the source of the translation. Google Translate doesn't give copyrighted results, and there is no guarantee that the translation it provides tomorrow will be identical to what it provided today. If someone is quoting a published translation (a) I'm not sure anyone would even necessarily realize that it's a translation and (b) it's already covered under cite-the-source directive. --MartyD 10:02, 7 September 2020 (EDT)

I like Marty's proposal that also includes statement concerning translations. I'm still inclined to add that if a source is translated, it is explicitly mentioned in the submission (ie 'translated from source') - not sure what's the best way to add that to the proposal though... Regards, MagicUnk 16:11, 7 September 2020 (EDT)

It is already covered by the first sentence (it comes before the language related rules) but if you want to make it even more explicit: just replace "following the original as closely as possible." with "following the original as closely as possible and identifying the exact source of the text and its language" and we are all set. Annie 17:15, 7 September 2020 (EDT)

Thanks Annie. That would sum it up quite nicely I'd think MagicUnk 19:57, 7 September 2020 (EDT)

I don't think that this is too much - the better we explain what we expect, the less likely it is to end up in the same mess again. While there will always be subjectivity in any text based field (especially in a multi-language multi-cultural team like ISFDB), this at least should get us closer to a more uniform approach. Annie 17:15, 7 September 2020 (EDT)

I also think that more specificity would be good to have in this case. Ahasuerus 17:39, 8 September 2020 (EDT)

It should be recognized that the proposed updated creates situations which can be problematic (unfortunately, all good intentions seem to have repercussions). Quite a few synopsis submissions (particularly from some self-published authors) are poorly written with confusing language and misspellings. The spirit of this proposal would seem to offer little choice between accepting a poor quality submission or flat rejection. Removing sections (the permitted ellipses) or individual word corrections (the permitted brackets) doesn't offer much ability to handle these cases. So some questions:
1. What is our "quality tolerance" for the synopsis field?

Difficult to make all-encompassing rules about level of quality - we'll have to make judgement calls for each individual case where a moderator identifies quality issues. General rule should be to leave less-than-perfect submissions alone, unless it's really egregious MagicUnk 05:25, 9 September 2020 (EDT)

2. Does the same rules for not editing a sourced synopsis apply to an editor written synopsis? If so, how do we handle proposed updates to the synopsis field?

Assuming editor-written synopses are 'neutral', and not sourced by default, any other editor that has read the book, can amend the pre-existing synopsis and expand/clarify, as long as they remain 'neutral' MagicUnk 05:25, 9 September 2020 (EDT)

3. If someone submits a synopsis that can be matched to a secondary source, but does not specify the source, I assume we should add the source and quote the text? We have several regular editors that copy in blurbs without sourcing them.

yes MagicUnk 05:25, 9 September 2020 (EDT)

4. If a self-published author submits a synopsis that matches what they put on their book, is that an editor synopsis (since it is theirs) or a secondary source synopsis that needs to be sourced (since it matches the back cover)? I'm currently processing an edit that matches this case so this isn't a academic question.

It should be a sourced synopsis - that way it's clear it's also on or in the publication in question. We shouldn't treat these different when the submitter also happens to be the author MagicUnk 05:25, 9 September 2020 (EDT)

5. If an editor has read the work, does that change the rules on editing the synopsis? A number of the comments above seem based on the idea that if one has not read the work, one cannot reliably edit the secondary sourced synopsis. But that should not be an issue for someone who has read the work. Are we saying that an editor who has read the work has only the choice between leaving the mistake or completely re-writing the synopsis? An editor may be willing to correct a mistake, but not be willing to re-edit the whole thing.

This is a tricky one. But. I'd say a 'neutral' account by an editor who actually read the book can replace or correct (contents-wise) a copied-over synopsis. But I wouldn't encourage it, and besides, I believe that once a synopsis exists, editors will tend to leave it alone, so this case isn't going to come up often (if at all) MagicUnk 05:25, 9 September 2020 (EDT)

6.The rules state that the synopsis should be short. Quite a few book blurbs are what I would consider long (multiple paragraphs). What do we consider too long?

Trying to define 'too long' is going to be impossible. My own feel is that the multi-paragraph synopses are not too long. A rule-of-thumb could be that the max length is capped by what can be fitted on the back cover of a book (using standard font size, obv. :). And as a moderator you can always work with the editor to decide what part of the copied-over text can be culled (if at all). MagicUnk 05:25, 9 September 2020 (EDT)

I don't care where the line is drawn for the synopsis field (other than I wouldn't like to see an increase in the amount of poorly written ones) as it isn't something I'm particularly interested in as an editor (I'd actually be happier with the option to hide them). But as a moderator, I'd like to make sure we all know where that line is drawn. Rejecting submissions (or removing portions of submissions) is discouraging for editors (particularly new editors). Since as proposed, the rules offer little option between accepting and rejecting, I'd like to make sure we're in agreement on when to reject so we're not having another kerfuffle over rejected edits in a few months time. -- JLaTondre (talk) 22:06, 8 September 2020 (EDT)

My comments with each question above. In summary, I'd rather have a poorly-written synopsis, than no synopsis at all (but that's just me). If it's copied over as-is from the back cover, leave it alone. If it's from an editor that has read the book, and another editor has read the book too, he/she should be allowed to update/replace the synopsis (assuming he/she does a better job/add to the complenetess of the synopsis). If it's an (extremely) badly written (but what does that really mean 'badly written'? Who's going to define that?) synopsis, work with the submitter to correct the language (vast majority of these will be from non-English speaking editors, either as translations, or as accounts of books read by them). They will benefit from an English-speaking moderator to help them to phrase their synopses correctly. As a last resort, and if it's egregious and the editor is non responsive, reject the submission (less disheartening for the editor nowadays since rejects can now be easily resurrected).

All in all, I wouldn't prevent these (corner?) cases to improve the rules and adapt to the current practice (ie copying blurbs). Hope this makes some sense. Regards, MagicUnk 05:25, 9 September 2020 (EDT)

"vast majority of these will be from non-English speaking editors": This has not been my experience. The worst ones I've seen have been from English speakers. -- JLaTondre (talk) 19:35, 9 September 2020 (EDT)

I'm curious about this. Do you happen to have some examples? MagicUnk 23:00, 9 September 2020 (EDT)

I think the questions that JLaTondre is raising are worth looking into. However, most of them would probably be best addressed in a separate discussion. For example, the issue of correcting synopses can be tricky if we have one title record for two versions of the same story. For now, I'd like to reach a consensus re: the proposed change. Once it's been finalized, we can look into other, related issues. Ahasuerus 14:44, 11 September 2020 (EDT)

Reading through the above, the summary would be something like:

Enter an optional short non-spoiler plot summary. It must be in English even if the title's language is not English. Note that this is not a place for criticism or reviews.
If you wrote the synopsis yourself, make sure that it maintains a neutral point of view.
A synopsis from another source like a blurb or a bibliographic note may be used, in whole or in part. If you do, enclose the text in quotes, state and date its source. An English synopsis should be quoted verbatim, while a non-English synopsis should be translated, following the original as closely as possible and identifying the exact source of the text and its language. Use an elipsis/three periods ("...") for omitted text. Individual words may be replaced for clarity, with the replacement enclosed in square brackets ("[]").

I guess this more or less what we said, yes? Regards, MagicUnk 15:08, 11 September 2020 (EDT)

I think that sums it up nicely. Perhaps it needs a quote like "Don't write a synopsis yourself unless you read the story" to prevent adaptations of coverblurbs. --Willem 15:28, 11 September 2020 (EDT)

MagicUnk's version looks good to me. Re: "Don't write a synopsis yourself unless you read the story", I think we have it covered by the "verbatim" clause above. Ahasuerus 14:19, 14 September 2020 (EDT)

Outcome

Template:TitleFields:Synopsis has been modified to reflect the agreed upon standard. Rules and standards changelog has been updated. Ahasuerus 17:38, 17 September 2020 (EDT)

Issue with Saga Press - how to resolve?

(not 100% sure if this should go in R&S or is a Community Portal discussion, but here goes)
Annie and I have a disagreement on how to handle Saga Press publications before and after the move to Gallery.
Here are the facts:

Saga Press has always been an imprint of S&S (since 2014) (and continues to do so)
Saga Press has been moved to Gallery Publishing Group in 2019, but
All Saga Press copyright pages (to date) continue to mention "Saga Press, an imprint of Simon & Schuster" (no mention of Gallery whatsoever on or in the books that I've checked - both the few that I own and Amazon's LookInside)
We go by what's on or in the book

So, since we go by what's on or in the book, the most correct publisher would be 'Saga Press / Simon & Schuster' for ALL Saga Press publications, both from before and after the switch to Gallery. And since we accept to leave off the parent company for well known imprints, it is acceptable to go with just 'Saga Press' (and we add publisher notes to clarify).
Annie argues that we should distinguish pub records from before and after the move - but that is not apparent at all from the publications themselves, so why would we make an artificial distinction in the pub records? I feel we shouldn't. The split happened as an artifact due to Amazon starting to register new Saga Press publications as 'Gallery / Saga Press' (we inverted that, because Amazon's is plainly wrong). I am not in favor of using secondary sources to decide to split publishers. If Amazon wouldn't have done that, I'm sure no-one would have bothered, and would continue to use just Saga Press. Again, we should keep in mind that we record what's on or in the book, and need to minimize deviations from that golden rule whenever we can. In this case, it is sufficient to mention S&S's reorganization of their imprints/subsidiaries in the publisher's Notes field.
As an aside, I did the update of the notes for both Saga Press and Saga Press / Gallery, under the assumption that sooner or later Gallery would show up on the copyright page, but nope, turns out that that's not happening anytime soon... Can still happen in the future, sure, who knows. But until such time we shouldn't artificially split the Saga Press imprint. Thoughts? Regards, MagicUnk 16:20, 12 October 2020 (EDT)

We probably should just consolidate under "Saga Press" and forget about the exact corporate structure. The split happened both because Amazon and the rest of the online vendors started using the different name (albeit a wrong one in some cases) and because S&S had an announcement for the change. Adding the corporate parent when we are in a single publisher will be an overkill IMO - add it in the notes but don't burden people to type it every time - S&S Inc. is really a publishing group and if we need to add them to all their subsidiaries, half the DB will need to have it added.

We probably should ping any verifier in the post-imprint era. :) Annie 17:19, 12 October 2020 (EDT)

I agree. I think just merge them all into Saga Press and make a note on the publisher page. It gets too confusing, otherwise. ···日本穣 · 投稿 · Talk to Nihonjoe 19:36, 12 October 2020 (EDT)

I've left a note on the talk pages of the PV-ers of Saga Press / Gallery publications and asked them if they were OK with renaming publisher to just 'Saga Press'. Regards, MagicUnk 06:31, 14 October 2020 (EDT)

Seems like there are no objections from the primary verifiers. If there are no further concerns, I'll convert the Saga Press / Gallery to just read Saga Press in a couple of days, and cleanup the publisher record Notes accordingly. MagicUnk 17:17, 15 October 2020 (EDT)

When you say convert - you know you can just merge the two publishers, right? :) Annie 17:50, 15 October 2020 (EDT)

Eh, yup. That's what I meant to say. Sorry for the sloppy English... MagicUnk 00:41, 16 October 2020 (EDT)

No worries. It is not one of the obvious features so just making sure you are not going the long way around for fixing this :) Annie 01:15, 16 October 2020 (EDT)

I have merged "Saga Press" and "Saga Press / Gallery". MagicUnk 08:50, 26 October 2020 (EDT)

Lord Halifax's Ghost Stories

I'm confused by our handling of Charles Lindley, Viscount Halifax's ghost stories. These publications are collections of what are supposed to be true ghost stories, not fiction. In addition, Halifax collected stories from multiple people and didn't write them. The individual writers are credited (at least in the original edition[4]). So from my perspective:

As non-fiction accounts, these are non-genre and should not be included in the database.
If included in the database, the pubs should be entered as non-fiction and the contents as essays credited to the individual authors.

Thoughts? -- JLaTondre (talk) 09:23, 17 October 2020 (EDT)

I'm undoubtedly the main, and perhaps only, perpetrator. Boy, that was a long time ago. There were several discussions on aspects of how to handle this. There was this guidance about crediting. I don't recall any discussion about whether they should be "in" or "out", however. The Ghost Book of Charles Lindley, Viscount Halifax is listed in (current link) Locus1. That does classify them all as non-fiction and does credit the tellers as authors, where identifiable. --MartyD 08:18, 19 October 2020 (EDT)

Expanding omnibus content field values to encompass more than just novels and collections?

Template:TitleFields:Content states that for unnumbered series, 'enter the count of included titles, e.g. "3N" or "2N+2C" where "N" stands for "Novel" and "C" stands for "Collection"'. Neil Gaiman's American Gods Quartet omnibus includes two novels and two novellas, all unnumbered, so how would that be represented?

This isn't the first time in recent weeks I've encountered this issue with omnibuses containing an unnumbered novella (I *think* the other was a Feist Riftwar pub that had a novel trilogy plus a novella), and I know that series like Rivers of London contain unnumbered novellas, so unless there's some existing solution that I don't see, could there maybe be some additional letter codes for the storylen values added? Having a pub called "American Gods Quartet" that at first glance seems to only have 2 content items seems a bit off... ErsatzCulture 15:36, 18 October 2020 (EDT)

We use "ss", "nv" and "nt" for these -- something like 2N+2ss for example when the omnibus contains 2 novels and 2 stories which are not numbered or come from different universes. In your case: 2N+2nv. See this for an example or this. We probably should update the help page. :) Annie 21:04, 18 October 2020 (EDT)

Thanks. I just ran a query against a local copy of the database for all the values currently in use, and it seems a bit messy? User:ErsatzCulture/TitleContentValues I'm guessing some of these other forms have been relatively recently introduced and/or aren't actively policed for consistency? It's debatable how necessary consistency might be - it feels like something where human-readability trumps machine-friendly-consistency - but I see it's a field that you can do an advanced search on, so having all of "1,2,3", "1-3", "1, 2, 3", "1,2,3 Boxed Set", "1,2,3 (Boxed Set)", etc can't be ideal. ErsatzCulture 05:29, 19 October 2020 (EDT)

As with most of the non-strictly formatted fields, these can get a bit... creative - just look at the mess that is the price field. :) Technically "1-3" and "1,2,3" are the expected forms (I prefer the first version personally when possible); the ones with Boxed Set are a bit... unconventional. :) Annie 06:28, 19 October 2020 (EDT)

Personally I think having both "1-3" and "1,2,3" is acceptable (I'm pretty sure I've submitted edits with both), but I've done a bit more digging, and found a few cases that might be worth either codifying officially or changing to a different form:

* The plus form, but using a comma instead e.g. "2C,1N" in [5]

* The value in square parentheses; these looks to me like careless copypastes e.g. O/1,2,3+3ss (parens removed to stop MediaWiki confusing it for a link) in [6]

* There are a few cases where a full or semi-abbreviated word has been used, should these be considered acceptable as synonyms for the abbreviations e.g. "novella" in [7], "coll" in [8] ?

* Is there a format for indicating unknown number of novels/stories etc? This might be useful for "Complete Works of Lovecraft/Wells/etc" ebooks that I don't think it's reasonable to expect an editor to manually count up, so you might want to put something like "?N+?SF" as a (slightly) preferable alternative to leaving the field blank

Are there any objections to me starting to add some of the currently-undocumented-but-official values to that help page? ErsatzCulture 11:17, 19 October 2020 (EDT)

You're surely more than welcome to update the Help Pages to reflect the current practice more precisely. But... propose the updated text here first. That way it can be amended by other editors and moderators (if they feel like it). Or they'll tell you all's good and well and you can update the pages. Oh, and you're even more than more than welcome to clean up the mess too :) MagicUnk 11:10, 20 October 2020 (EDT)

Re. cleaning up the mess, I spent some time yesterday writing some code to go through all the title records and analyse their values. This could potentially be part of a nightly report and/or be used on the post-submission and mod approval pages to display a yellow warning for non-compliant values. Provisional analysis looks like this:

       1. GOOD: Non-omnibus with title_content undefined                         : 1799686 
       2. POOR: Omnibus with title_content undefined                             :    4274
       3. GOOD: Omnibus with clean a-b range                                     :    2937 
       4. GOOD: Omnibus with clean comma-separated volume numbers                :    2650 
       5. GOOD: Omnibus with clean {count}{type-abbrev} value                    :     513 
       6. GOOD: Omnibus with clean foo+bar+baz values                            :     258 
       7. ????: Omnibus with other title_content value                           :     142
       8. BAD:  Omnibus with known words in value                                :      42 
       9. BAD:  Omnibus with comma-separated volume numbers with whitespace      :      27
      10. BAD:  Omnibus with value in square parentheses                         :       9

The 142 "????"/other records are mostly ones that fall into the some of the weird cases I mention above, and can't really categorize until people opine on whether they think those forms are acceptable or not. ErsatzCulture 15:29, 20 October 2020 (EDT)

Paper books and ASIN

As explained here, for pubs with 979 ISBN's there should be an ASIN too. Should we update the rules here and/or here accordingly? MagicUnk 09:18, 24 October 2020 (EDT)

What needs to be updated? The first help link is about the ISBN field. The ASIN is a separate field. The second help link is about the External Identifiers field and it only prohibits using values that match the ISBN. As that is not the case, these are already allowed (same as for books without an ISBN). -- JLaTondre (talk) 09:52, 24 October 2020 (EDT)

Well, Annie was (or seems to) implying that for 979 ISBN's ASINs are mandatory, not optional.MagicUnk 10:30, 24 October 2020 (EDT)

Nope. Annie was explaining how without them the link does not lead to the page you want it to - so they are a good idea the same way they are a good idea for ebooks and someone may add them sooner or later (the same way we add links to libraries and other sources). :) Annie 10:37, 24 October 2020 (EDT)

Thought I'd ask, but I'm fine with that :) MagicUnk 07:14, 26 October 2020 (EDT)

Capitalization of "But"

As per Template:PublicationFields:Title, we do not capitalize the following words in the middle of English titles:

Articles: "a", "an", "the"
Conjunctions: "and", "or"
Prepositions: "at", "by", "for", "from", "in", "of", "on", "to", "with"

The only exceptions are cartoon captions which use the original case.

It's been suggested that we add the word "but" to the list of conjunctions above. For reference purposes, we currently have 682 English title records with " But " in their titles. We also have 206 English title records with " but " in the title. (INTERIORART titles excluded.)

Note that our current standard is loosely based on the "title case" standard in the APA style guide. The emphasis is on "loosely" because the APA standard uses the "three letter" test for prepositions and conjunctions. It results in somewhat different lists:

conjunctions: "and", "as", "but", "for", "if", "nor", "or", "so" and "yet"
prepositions: "as", "at", "by", "for", "in", "of", "off", "on", "per", "to", "up", and "via"

Another thing to keep in mind is that "but", like some other conjunctions, is not always a conjunction. It can also be used as a preposition ("nothing but") or even an adverb -- see examples here.

Substantively, I don't have a strong preference one way or the other. Ahasuerus 10:07, 27 October 2020 (EDT)

A few of the prepositions can serve as other parts as well so maybe title the last group a bit more widely - we always keep them lower case even when they serve as something else :) No preference for ‘but’ - I lean towards leaving it capitalized (otherwise it is inconsistent with ‘if’ for example) but either way works for me. Annie 10:23, 27 October 2020 (EDT)

I'd prefer "but" and "nor" be treated like "and" and "or". Simple things for my simple mind. And since we like lowecase from/with, perhaps we could have a "four-letter" guideline for articles/conjunctions/prepositions.... --MartyD 10:37, 30 October 2020 (EDT)

While we're at this list: what about 'plus' added, as it's used here: the reason is that it has the same meaning as 'and', and it seems somewhat incongruent to have different standards for the both. Christian Stonecreek 14:46, 30 October 2020 (EDT)

Subtitle delimiters with printed alternate format

I am working on a submission, and the title page of the book has a period as delimiter between what we would use as title and subtitle. E.g., Relatos extraños. Volumen 2. It is printed that way on what passes for the title page in the e-book. The help seems to focus on TITLE (over) SUBTITLE presentations and doesn't discuss whether presented punctuation should be preserved or altered/normalized. --MartyD 07:23, 8 November 2020 (EST)

I wouldn't consider a volume number to be a subtitle. I would try to find the first volume, and then enter them as part of a series. ···日本穣 · 投稿 · Talk to Nihonjoe 12:01, 9 November 2020 (EST)

It still is a type of a subtitle though - and even if we find the first volume, we still need to keep the volume numbers in the title most likely Annie 15:47, 9 November 2020 (EST)

I had been wondering about that. We allow "or" as a separator when it is presented after all. On the other hand, leaving it like that leaves the door for variants because of a subtitle punctuation which we had been trying to prevent with the standardization. I think we should standardize but I am not sure if the rules support it... Annie 15:47, 9 November 2020 (EST)

Per the Amazon Look Inside, "Relatos extraños. Volumen 2" is given on the title page as a single line and all in the same font/size. It is not presented as two lines of different sizes like it is on the cover. As such, I would enter it as per the publication title page and not as a subtitle. Unless "." is a Spanish convention for subtitles (like ":" is for English) and in which case we may want to consider language specific options like we do with case. -- JLaTondre (talk) 18:34, 9 November 2020 (EST)

I did enter it as presented. (I also made a series). Easy enough to change if we decide we want to do something different. The first volume is simply Relatos extraños with no number/volume indication. I also share the concern about variants bases solely on punctuation, but we can wait to see if that is a practical problem. Thanks for the input. --MartyD 09:22, 10 November 2020 (EST)

Rules and standards discussions/Archive/Archive18

Clarify how to deal with unverified data added after primary verification

Clarify how to deal with unverified data added after primary verification -- Outcome

Ph.D., Dr.

Prices in (Soviet) rubles?

Tall paperbacks

Magazine Editors

How to deal with multi volume publications

Proposal

'Split' Omnibuses

Extending the "Content" field to collections

Different ASINs: when to create a new publication vs when to add another ASIN to existing pub?

How to deal with parent/variant titles of different length

Outcome

Suffix normalization?

Multi-Volume Page Counts

Outcome -- Help updated

Eligibility of NONFICTION about non-written SF

Outcome

More precise definition of CHAPBOOK publications

Outcome

SERIALs and (Part i of n)

Letters -- cleaning up the data entry rules

Outcome

German Gold Mark standard symbol?

Capitalization and international titles (again)

Entering US territories

Incorporated Territories

Unincorporated Territories

Uncountable nouns vs. plural nouns

Strange values of pub_year

Note on kana transliterations (Japanese)

Polish złoty

Resolving genre vs nongenre when tags disagree with the flag

Clarifying Synopsis Help

Outcome

Issue with Saga Press - how to resolve?

Lord Halifax's Ghost Stories

Expanding omnibus content field values to encompass more than just novels and collections?

Paper books and ASIN

Capitalization of "But"

Subtitle delimiters with printed alternate format

Navigation menu

Search