Rules and standards discussions

From ISFDB
Jump to navigation Jump to search


ISFDB Discussion Pages and Noticeboards
Before posting to this page, consider whether one of the other discussion pages or noticeboards might suit your needs better.
If you're looking for help remembering a book title, check out the resources in our FAQ.
Please also see our Help pages.
Help desk
Questions about doing a specific task, or how to correct information when the solution is not immediately obvious.
• New post • Archives 		Research Assistance
Help with bibliographic projects.
• New post • Archives 		Rules and standards
Discussions about the rules and standards, as well as questions about interpretation and application of those rules.
• New post • Rules changelog • Archives 		Community Portal
General discussion about anything not covered by the more specialized noticeboards to the left.
• New post • Archives 		Moderator noticeboard
Get the attention of moderators regarding submission questions.
 
• New post • Archives • Cancel submission
Roadmap: For the original discussion of Roadmap 2017 see this archived section. For the current implementation status, see What's New#Roadmap 2017.



Archive Quick Links
Archives of old 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
Rules and standards changelog

Every rule change that comes out of a discussion here should be added to the Rules and standards changelog.

Clute/Nicholls Verification Revisited

There was a short discussion back in 2013 where we decided that publications should not be verified for the Clute/Nicholls slot based on a SFE3 entry. We do mention SFE3 in our description of Clute/Nicholls, which confuses matters a bit. I wanted to ask if our policy is still that Clute/Nicholls is reserved for the paper (or CD/ROM if anyone can still play that one) versions. If so, we should probably adjust the note about SFE3. I'm asking because of the verification for this publication which I can find in the Ray Russell and Playboy entries of SFE3, but not in my 1999 Orbit edition which contains neither entry. Opinions? --Ron ~ RtraceTalk 08:47, 3 January 2021 (EST)

Since I posted this question in January, I've discovered 5 additional publications where the Clute/Nicholls verification is marked when the publication is not mentioned in the 2nd edition of Clute/Nicholls, but is instead mentioned in the online SFE3. After encountering one of those publication a week ago, and since all of these were added by the same editor, I left a note on his talk page inviting him to comment on this discussion. The response I got was rather odd and appears to say that they are intending to leave the project to resolve the issue. I certainly don't want anyone to leave over this, and also it doesn't resolve the issue of records being marked incorrectly (assuming we stick to the latest consensus). So the original question still remains as to whether we now want to allow Clute/Nicholls verifications for publications listed only in SFE3. If we decide that we don't and want to abide by the 2013 discussion, and given that the editor who added them won't remove them, should we remove them for him? While I have removed errant verifications, I've been very careful to only do so for inactive editors. Also, if anyone has a good relationship with Hifrommike65, could they reach out to him and try to smooth things over? I was just trying to resolve an issue with the data. Given the confusion by mentioning SFE3 in the Clute/Nicholls description, I even understand why someone could interpret the source to include SFE3. Thanks. --Ron ~ RtraceTalk 14:32, 25 April 2021 (EDT)
My opinion hasn't changed since 2013: "I agree that the 2nd edition and the 3rd edition are very different beasts and we shouldn't be using the "Clute/Nicholls" slot to record SFE3 verifications."
However, instead of "remov[ing] SFE3 from the description page", I think it would be better to add an explicit statement explaining that the third edition is very different both in terms of size (1.3 million words vs. 3.2 million words in 2011 and 6 million in 2020) and nature (stable printed text vs. an ever-growing Web site.) Ahasuerus 15:02, 26 April 2021 (EDT)
P.S. Two more things. We may want to consider adding SFE3 as another verification source. I work with their editors fairly closely and, although the editorial content is constantly changing and expanding, books are rarely removed from bibliographic sections.
I would respond on Hifrommike65's Talk page, but I am currently sick and I am afraid that I will miss something and make a mess of things. Ahasuerus 21:25, 26 April 2021 (EDT)
I would support adding SFE3 as a new Secondary source. ···日本穣 · 投稿 · Talk to Nihonjoe 10:41, 27 April 2021 (EDT)
@Ahasuerus - Hope you're feeling better, or will soon. I do think the addition of SFE3 would be a good idea. Since Locus stopped updating their site, the only verification source that keeps current is Worldcat. So it would be good to have another one. Though, I still leave Locus unmarked for anything after 2007 in the hopes that they'll update it someday. --Ron ~ RtraceTalk 17:38, 28 April 2021 (EDT)
Adding SFE3 is fine especially because it does not have an external ID for us to use. I think we need a bigger discussion around external IDs and secondary verifications though if we are going to be adding/removing things. SFE3 is good for English, Fantlab is good for Russian, Fantascienza is good for Italian, BNF is good for French, DNB for German, Goodreads is a non-library OCLC and so on. I am kinda wondering why do we need the secondary verifications on things that we have external IDs for -- if a book has an OCLC number for example, what does the secondary verification add that the number does not? As it is, the list of secondary verifications is long and takes a lot of space on the page of every book - and only a few are anywhere near being relevant for non-English titles... Before we add yet another English-only source, shall we decide how we want that whole area to evolve? Annie 18:59, 29 April 2021 (EDT)
I can think of two things we would lose by eliminating sources with external ids from the verification list. First, is the ability to question the verifier about a specific publication. I've occasionally received queries from other editors about the Reginalds or the Bleilers. The other thing we would lose is the ability to mark a publication as not covered by the secondary source (status N/A). This prevents editors from having to check a source where someone has already checked it (though I have seen it marked so in error, especially Bleiler78). That being said, neither really apply to Worldcat. Anyone can check the link themselves, and I would argue that marking Worldcat "N/A" shouldn't be done since while a publication isn't listed today, it may be listed in the future. I would treat SFE3 similarly. Lastly, while SFE3 is certainly English-centric, it isn't English-only e.g. Théophile Gautier. --Ron ~ RtraceTalk 07:16, 30 April 2021 (EDT)
Book/disk-based (limited) sources are different from online ones - having a way to mark that one was checked in a book and is missing is useful. Not as much on online ones - these evolve - N/A there is not a permanent state. What we really need is the ability to show only relevant secondary verifications on the pages (the same way we show only relevant external IDs)... Annie 16:33, 30 April 2021 (EDT)

Standard for disambiguating author names

Is there a standard for disambiguating author names? I picked up a specfict book by Nicole Marie and discovered:

I e-mailed the author of the book I have and discovered it'll be a third Nicole Marie on ISFDB.

My questions are:

  • Is appending "(I)" to a name the official standard for disambiguating an author name? Can someone cite where this is in the help? I know some library systems disambiguate using the author's year of birth (and death if that's the case). In this case all three Nicole Marie seem both contemporaneous don't have public year of births available.
  • Is "(I)" that a Roman Number I meaning one?
  • Assuming the I is a one why isn't this a II or two as this is the second Nicole Marie?
  • How do I get that note to appear at the top of the author listings? Ideally, all three author records will have a note explaining that the other two records exist. I know I could do it via the note field at the author level but that note is down in the list of bullet points. I'm curious about how the note at the top of http://www.isfdb.org/cgi-bin/ea.cgi?277983 got there and how to edit it to mention the third Nicole Marie once she is in ISFDB.

--Marc Kupper 18:58, 4 January 2021 (EST)

See Help:How to separate two authors with the same name. Dates & professions are preferred, but sometimes that is not possible and we use Roman numerals in those cases. We use none for the first, I for the second, II for the third, etc. Both Nicole Marie's do have the "Note: There are other authors with the same name" at the top. The software does that automatically. Once you add Nicole Marie (II), it will appear without you doing anything. -- JLaTondre (talk) 19:05, 4 January 2021 (EST)

Eligibility of scriptbooks of TV episodes and films with speculative elements?

I've just had a quick look through ISFDB:Policy#Rules_of_Acquisition, and I don't see anything explicitly addressing these. I can see there are a few already in the database - e.g.[1], [2] - but those look to be relatively old submissions, from when - as I understand it - the rules on what was accepted for entry may have been looser than they are nowadays.

In theory, these scriptbooks aren't maybe much different from novelizations, but I thought it prudent to check first before having a submission rejected. Thanks ErsatzCulture 11:06, 14 January 2021 (EST)

Printed plays are eligible so yes, these are eligible as well. :) Annie 11:51, 14 January 2021 (EST)

Graphic novels

Opening a can of worms here but.....
Rules and stanmdards clearly state that exclusions include "Comic books, manga, and graphic novels"
However, there are exceptions, where one of our authors provides the words (think Gaiman) that are included.
This stemmed from my obtaining a copy of Retroworld which seems to be an adaption of the work(s) of Julia Verlanger. Les Voies d'Almagiel and Horlemonde in two halves sub-titled "The Ways Of Almagiel" and "The Hydras of Argolide."
At one point Downward to the Earth (again split into two kindle volumes) was included but apprently Silverberg had nothing to do with the adaptation and probably none in this "sequel" either.
So my question is: How is one to know the exact involvement of an above threshold author in such grahic material in order for such to qualify for inclusion ? --Mavmaramis 11:13, 10 February 2021 (EST)

I would support changing the rules to say: "Speculative fiction adaptations in graphic format are included; graphic novels, manga and comics that had been later novelized are excluded" as a clarification/change of the GN rules (basically - if the original is ours, we want the graphic adaptations but we do not want the original of something just because the adaptation is ours). Then we do not need to worry about who actually adapted something. Annie 11:39, 10 February 2021 (EST)
I'd be fine with that. ···日本穣 · 投稿 · Talk to Nihonjoe 11:40, 10 February 2021 (EST)
Does this open the door to Edgar Rice Burroughs (Tarzan etc) and Robert E. Howard (Conan etc.) based comics? ../Doug H 13:49, 10 February 2021 (EST)
Yes and no. It opens the door for the ones which are adaptations of the actual stories/novels that are published in text format; it does not open it for the ones that are in their universes but are original stories.
I was thinking about that but if we allow ones in known universes as well, we are opening the door for all DCU and MarvelU and Dr Who comics... We can try to do "predominantly text based universes" if desired (that will allow one-off GNs in otherwise straight text universes) but... this is way too subjective so I prefer to just stick to adaptations for now. Annie 13:56, 10 February 2021 (EST)
So an adaptation would have to be able to 'point' to the original title(s) to qualify, but there is no formal way to link them. Does this add impetus to the notion of additional title/title relationships beyond variant - like translation or abridgement? Not that any s/w changes would be required to allow the policy change, but a way to document them should be part of the wording. It would help a) focus on the adaptation being to existing text and b) simplify future conversion. ../Doug H 14:38, 10 February 2021 (EST)
And there went my evil plan to sneak the change in and then ask for a site improvement... :) Translations are fine as variants IMO -- although if we want to make it more explicit on the creation side, I am all for it. It is the same problem we already have with text adaptations - we need to have a way to mark them as such. Which we do not now :( So... notes, maybe a template or 3 - and one day we may have something better. So yes but we do not need a software change to change the rules... The wording above is for the "Rules of Acquisition" (as a change of scope essentially) so we won't be adding things about connections and templates but if we go for it, a whole set of help pages will need some updates and that's where this will go. One step at a time. Annie 15:10, 10 February 2021 (EST)
If, as Annie said "It opens the door for the ones which are adaptations of the actual stories/novels that are published in text format" then that would also include the Elfquest graphic novels for which see Wendy Pini. Novelizations of which are already listed. Then there are the above threshold artists who have done graphic novel works Howard Chaykin for example - Juan Giménez who has illustrated graphic adaptions of material written by Alejandro Jodorowsky - The Technopriests, The Metabarons for example. Then there's Moebius with Arzach, The Airtight Garage, Gardens of Edena et al. and Philippe Druillet with his Lone Sloane series; Yragael/Urm the Mad and others.
Where do you draw the line - I mean how is anyone supposed to know whether a graphic novel has or hasn't been adapted from a pre-existing published text or is merely another graohic volume extension of that specific universe ? Not sure there's going to be a "hard and fast"rule to cover all eventualities. --Mavmaramis 16:24, 10 February 2021 (EST)
Most of these are not based on pre-existing non-graphic novels/stories though - Metabarons was published as a comics (with text by Jodorowsky) and is not an adaptation of an existing novel/story. I may be wrong - if you know differently - can you point to the story/novel that it is adapted from? And unless someone can go above threshold without the graphic contents and art (we are a fiction DB after all, not an art one), they are not above threshold so we do not include every book from "our" artists.
Having a novelization later is NOT going to make the GN eligible. Only the opposite will be true - if something starts as a story/novel (like the ones we started this conversation with) and then get adapted, the adaptation is in. That will kick out most of the Elfquests that started as GNs, even if they had had later novelizations.Annie 16:42, 10 February 2021 (EST)
PS: And one can know the same way we know if something is a translation - by researching :) We are trying to allow limited list of GNs here to accommodate those GNs that adapt well known stories -- not trying to add as many as we can - our DB is really not set well for comics and GNs... If it is not clear that it is an adaptation, it is out. Annie 16:45, 10 February 2021 (EST)
Which is why I proposed a 'link' to the source, being necessary for approval. ../Doug H 19:37, 10 February 2021 (EST)
No disagreement here but this does not belong in the Rules of Acquisitions - it belongs to other parts of the rules. Once we decide that we are changing the scope of the project (the RoA), we can figure out the rest of the rules changes to accommodate them. If the RoA is not changed, no reason to lose time trying to figure out where else and how we need changes. Other from that - yes, a link to the work that is the base should be mandatory for approval... :) Annie 15:09, 13 February 2021 (EST)
So what's the take away here? Will we extend to cover graphic adaptations? TAWeiss 18:39, 5 March 2021 (EST)
Nope. I got only one "supported" on my proposal and a few "but what about"s with no support. Which means that the rules remain as they are - unless it is an above threshold author, GNs are out. We can try again in a few months - I want the adaptations in but we need a much better support to change the ROA. Annie 18:48, 5 March 2021 (EST)
That does leave us a bit in limbo on this series. We only have 4 of the 7 adpatations in the db. Shouldn't we either complete the series or remove it? I'd prefer we add the missing three. TAWeiss 14:15, 3 April 2021 (EDT)

When is a cover designer the cover artist ?

There are a multitude of instances where the name of the cover designer has been entered as the cover artist and others where it has not. Can't seem to immediate locate any rule/standard regarding that. Anyone care to elaborate on why the inconsistancy ? --Mavmaramis 05:30, 11 February 2021 (EST)

Granted, artist credits are a mess. I myself never add cover designers as artists. I make a note instead. Likewise, I shy away from crediting iStock and its ilk. I understand other editors & moderators are more relaxed in crediting designers, but the issue is: when is there enough of an 'artist' input from a designer to be credited as artist, and when not? I am in favour is a clear and unambiguous rule: don't credit designers - at all (put them in the notes). My 2 cents. Regards, MagicUnk 06:51, 11 February 2021 (EST)
Thanks. I was mostly referring to books published in the UK in the 1970s - Dobson, SFBC(UK), Millington (to name three) - the likes of Terry James, Richard Weaver (et. al.) who are all noted as "Cover design by ......" on the physical copies but are credited as cover artist here. And actually is that such a terrible thing ? I think it becomes more of a minefield when it comes to the modern covers that use stock images (Alamy, Shutterstock, iStock) etc. Maybe have a cut off date (say, arbitrarily the year 2000) or something like that. Again, I suspect that other moderators/editors will have differing opinions about crediting cover art and there won't really be a "hard and fast" rule. --Mavmaramis 07:27, 11 February 2021 (EST)
I don't do many COVERART submissions, but a somewhat peripheral anecdotal observation: from submitting ~10 years worth of

Kitschies Award art nominees and last year's BSFA art category, it felt like the majority of those covers fell into the "design" rather than "art" bucket. For the purpose of linking to the appropriate title/pubs, I created COVERART records for them, rather than the "stub"s you can do for award finalists that don't exist in the database (cf horror works that aren't speculative). This year's BSFA finalists will probably be announced in the next week or so, so if the consensus opinion is that I'm doing things wrong, I'd prefer to know sooner rather than later ;-)

(NB: I'm definitely not advocating that awards functionality should dictate rules for "core" data, just pointing out this as a related issue.) ErsatzCulture 09:13, 11 February 2021 (EST)
Adding a cover because it was nominated is counter-intuitive for me but then I think that we over-obsess over art in the DB anyway. If it is not eligible under our rules, then it is out regardless of what awards it wins. We would not add a non-fiction book that is not genre even if it is nominated for an award; why would we treat covers differently. We are a fiction DB - we have the non-genre flag to accommodate special cases around fiction but outside of fiction and above threshold authors, we should follow our own rules strictly IMO. Annie 15:06, 13 February 2021 (EST)
The basic rule is that if it just a designer credit, they do not get a COVERART record - they need to be the artist to get it. Unfortunately, secondary sources use different rules and even with books at hand, people credit differently. And a lot of new editors don't get proper coaching in what is considered a cover artist and not all moderators always ask when they cannot verify. So the DB has a lot of designers credited. If the book is not PV'd feel free to remove the cover and add a note. If it is, you can work with the PV on that... The DB has a lot of inconsistencies - partially because of changing rules (GNs and non genre non-fiction inclusion for example, especially the latter) and partially because people read and interpret rules differently and have different levels of attention to details... Annie 09:19, 11 February 2021 (EST)
Should we strengthen the rules and clarify that if someone is credited as designer on or in the book, he/she is not to be credited as author - and perhaps explicitly allow for the case mentioned by ErsatzCulture? After all, we record what's on or in the book, and only revert to secondary sources in lack of having the actual product at hand. MagicUnk 12:29, 12 February 2021 (EST)
At the moment they say: "The cover designer (as opposed to the cover artist) is only entered in this field if he or she also did (parts of) the cover art. Otherwise the cover designer can be recorded in the note field.". I do not know how much clearer we can make them but if you have an idea, please propose a new/better wording :) Annie 15:02, 13 February 2021 (EST)
I'm sure the distinction between art and design - as determined by ISFDB rules, which I suspect might differ from what "creatives" consider - has like been discussed in the past, quite possibly more than once; could anyone give me a hint where I might find this, as the couple of pages of wiki search results didn't bring up anything that looked relevant?
e.g. Naively, I would personably consider much of the work of Will Staehle to more likely to fall into the "design" rather than "art" category?
Alternatively, would there be objections - technical or otherwise - to having a COVERDESIGN title_ttype (plus appropriate UI) to have these properly recorded in the database, distinct from COVERART records? ErsatzCulture 14:32, 14 February 2021 (EST)
EDIT: I trawled through each archived rules page, and eventually found this from 2018 which I assume is a reasonable summary? ErsatzCulture 14:54, 14 February 2021 (EST)
That looks like a reasonable summary. I see my opinion hasn't changed.! :-) --MartyD 12:29, 15 February 2021 (EST)
To answer Annie's question, here's a different, succinct wording: "The cover designer (as opposed to the cover artist) is never credited as artist. The cover designer can be recorded in the note field." (you could perhaps also add the clause, cover designer credited on or in the pub). This to me leaves no room for interpretation, unlike the current wording. Regards, MagicUnk 12:54, 15 February 2021 (EST)
I think the idea of having another field for Cover Designers" is actually rather an elegant solution. That way (like cover artists) you can easily find all the covers they have done. --Mavmaramis 10:08, 19 February 2021 (EST)
This is part of a much larger conversation on roles. Adding a separate role/type about cover designers when we do not have one for text editors and translators is emphasizing art over text in a fiction DB. So I am technically not against the idea per se but against implementing it now, before the different roles for text non-authors had been implemented. Annie 10:23, 19 February 2021 (EST)
We are still left with the fact that, depending on who is entering data and/or moderating such submissions, the cover designer's name has been entered in the cover artist field or recorded in the notes. Admiredly there is a text search facility that would allow one to find such information. And yes Annie, I agree that you could create fields for translators (or indeed any individual named in the publication, whatever their role, however minor). I don't see why such a field could not be implemented relatively easily - uless there are complex machinations fpor doing so I am unware of. I hope it is something that could be placed on a list of "things to do" somewhere close to the top of the list. I do feel that having implem,etation of such would solve this issue. --Mavmaramis 14:21, 19 February 2021 (EST)

Roles

Re: the issue of "roles", there is quite a bit of history involved. Originally, the idea was based on the MARC-21 bibliographic format, which is used by most major libraries. The standard includes a Code List for Relators, which supports "relators" like "book designer", "cover designer", "abridger", "adapter", "consultant", "copyright holder", "proofreader", "dedicatee", "translator", etc.

The way we originally envisioned "roles" -- see ISFDB:Proposed_Design_Changes#Roles and FR 97 -- was similar to the way we currently handle External IDs. We would have an infinitely repeating group of two fields, one for "Role" and one for "Name". The "Role" field would be a drop-down list of supported roles similar to the drop-down list of supported "External ID Types". The "Name" field would simply capture the name of the person who played that role, similar to the way the "External ID" field captures an External ID.

When we took a closer look, we quickly discovered two issues. The first one had to do with the fact that we make a distinction between "title" records and "publication" records. Some "roles" like "abridger" or "translator" would be associated with title records. Other roles like "cover designer" and (probably) "narrator" would be associated with publication record.

The second -- and more important -- issues had to do with pseudonyms. A lot of people involved in the book/magazine business wear multiple hats. Some authors (especially in Europe) have been known to use one set of pseudonyms for their own works and another set of pseudonyms for their translations. If we were to create uniform bibliographies, we would need to capture and display these "alternate name"/"canonical name" relationships, including collective pseudonyms, self-collaborations and the rest of the stuff that we currently support for authors. That would involve a great deal of work, which is why the idea hasn't been implemented yet. Ahasuerus 15:09, 19 February 2021 (EST)

After sleeping on it, it occurs to me that we could handle cover designers the way we currently handle narrators and translators. We would create a new non-linking template, call it "CoverDesigner" and make it behave the way "Narrator" and "Tr" currently behave. That way it would be easy to convert all occurrences of "CoverDesigner" if and when we added more robust support for "roles". Ahasuerus 19:12, 20 February 2021 (EST)
Some thoughts:
The template interim solution doesn't - as far as I can see - address the "cover award" category use-case I mentioned up-thread. I appreciate that some have expressed the opinion that that sort of thing isn't a core part of ISFDB's "mission", but it seems a bit crazy to me that we might have a list of art category nominees/finalists, where some of them don't link to the art/cover in question (even though the chances are that it is already logged in the database), based on some (AFAIK) distinction between what constitutes art vs what is design.
(At the risk of diverting this discussion, is that distinction formalized anywhere on this Wiki? Or is it based purely on the credit in the work or some other source? If the latter, then I wonder about all the entries that seem to be based on listings in Locus - when I checked a copy I had to hand a few days ago, it just seemed to list "Cover by Foo", not art or design.) ErsatzCulture 13:08, 21 February 2021 (EST)
Cover designers have a very different job compared to cover artists. For example, here is how masterclass.com describes their responsibilities:
  • Oversee all elements of the design process: This includes graphic design and typesetting.
  • Select cover art and typography: The imagery and fonts they choose will appear on the front cover, back cover, spine, and (when applicable) inner flaps of a book.
  • Produce a mockup cover: They’ll send this out before the cover is finalized for notes from the author and publishing company.
  • Create a cover appropriate for the genre: Book cover designers are mindful of how design work intersects with book marketing, and thereby understand that a great book cover is one that instigates book sales. A book’s genre matters. For instance, potential readers of a thriller are likely to favor a different kind of cover image than potential readers of a self-help book.
  • Collaborate with other creatives: The cover designer works with a publishing company’s creative director and any other professional designer assigned to the same project.
In other words, the cover artist produces the picture which appears on the cover. The cover designer is responsible for how the picture is selected/presented/positioned/cropped/framed/etc as well as for everything else that appears on the covers and on the spine. Two very different job descriptions. Ahasuerus 16:13, 23 February 2021 (EST)
If the "no cover design" rule holds, could I suggest a slightly hacky workaround for the aforementioned "art award" use-case? In the "Add Untitled Award" functionality, there is a field for an IMDB tt12345 ID; could this be extended to also support URLs, possibly just for a whitelisted set of domains or patterns? This would allow you to link to a relevant pub record for covers that aren't COVERARTs - perhaps not ideal, but at least it would make it possible for a user to see the artwork without having to leave the site. ErsatzCulture 13:08, 21 February 2021 (EST)
Let me make sure that I understand correctly. You are proposing that we add a new field to "untitled award" records. The field would be used to capture cover scan URLs. It would only be populated when the untitled award in question is given to the cover designer of the publication in question. Is that about right? Ahasuerus 16:50, 23 February 2021 (EST)
Ahasuerus> "Is that about right?" - sort of. Rather than adding a new field, I am proposing to make the existing "award_movie" field more flexible in what it accepts, and how the front-end code renders the value. This is more of a technical implementation detail - mainly avoiding the hassle of a database schema change, unless you really want to do that - than a conceptual alteration, IMHO at least. Also, by "capture cover scan URLs", my gut-instinct preference would be to have those URLs point at a relevant publication page, rather than (say) a direct image URL, but I can't say that I've thought through all the ramifications of that, or have a strong preference for that. ErsatzCulture 18:08, 23 February 2021 (EST)
If we decide to capture a new data element -- in this case a certain type of a cover scan -- it will need to be stored in a separate field in the database. Storing additional data elements in an unrelated database field is a particularly dangerous type of "overloading", which causes serious software problems. Early on, we had to deal with quite a few of them due to poor design decisions and it took us a lot of time and effort to fix everything. Ahasuerus 09:48, 24 February 2021 (EST)
There is another alternative - allow uncredited as cover artist for covers (as we allow uncredited for INTERIORART). This will allow us to have a record for every cover (if we want to), use these for awards and more importantly these will allow us to connect reused covers which have no artists but have distinctive designs or use stock images (which now can only be connected via the notes if someone bothers to) - both when they are reused as covers and as interior art. We can add a "the cover needs to be pictorial" or something like this but that will solve two of the current issues with covers. We do not want a coverart for every entry but if there is a picture, why this is different from the same one being reprinted as interior art. That may also help people not use the editor just so they can connect the covers (happened a few times...) Annie 17:02, 23 February 2021 (EST)
This sounds a lot like Marty's proposal at the end of this 2019 discussion. It starts with "It's too bad this died without solving Stoecker's immediate problem. Here's a limited proposal cobbled together from the things above". Does it accurately reflect your thinking? Ahasuerus 12:59, 24 February 2021 (EST)
Pretty much - apparently I missed the continuation of it back then somehow. Except that it is not just variants now - awards should also allow these covers to be created (plus it is very likely that a cover which had been nominated for an award to show up as interiorart or coverart again). And I would advocate for a whole new "special author name" instead of juggling uncredited/unknown but I can live with our two known contenders. It is not very surprising that we are converging on the same ideas when they make sense. :) Annie 13:28, 24 February 2021 (EST)
What would be a good "special author name(s)" to use to cover this category of cover art? "uncredited artist"/"unknown artist"? Would we want to tweak the software to disallow the display of all (except the Awards page) "uncredited/unknown artist" bibliographies they way we currently do it for "uncredited"/"unknown"?
Also, if you want to take the text of Marty's 2019 proposal and massage it to reflect your ideas, it may be best to post it in a new sub-section of this discussion. Ahasuerus 17:23, 24 February 2021 (EST)
Annie> "<stuff>" ;-) Not sure I completely follow this, let me ruminate on it overnight... Also I have some comments on what Ahasuerus copypasted above about designers, but I think my response will be too long to put in this already overlong-wiki item, plus it's just gone 11pm here. I'll create a page in my personal Wiki area tomorrow with some specific examples of where I think the current data-model/R&S practice doesn't reflect how (some) modern covers are produced. ErsatzCulture 18:08, 23 February 2021 (EST)
Think about covers like this one. It cannot have a coverart now unless you want to use Shuttlestock as artist and I really hate this - that's like saying Google or Internet. And there are even worse cases where there are no real images per se (so not even Shuttlestock to use) so it is just a designer - but we still may have an interesting view we want to catch.
If the design is reused in a translation or for another book, we cannot connect them. Neither we can add awards. Change the rules to allow to use "uncredited" or "come_up_with_new_value" or even "authorless records" and both issues are solved. Plus the designer for this cover in this edition may be one person, for the SAME cover but with different publisher, they can credit someone else (because the designer does not just pick the pictures). If someone credits the designer as an artist, then we end up with the same cover under 2 names. Annie 18:37, 23 February 2021 (EST)
Here's a long rant with pictorial examples of why I think the art vs design argument is a false dichotomy. User:ErsatzCulture/ARantAboutCoverDesignAndArt I don't expect to convince anyone to my way of thinking, but at least it's documented and out of my system now ;-) ErsatzCulture 12:39, 24 February 2021 (EST)
Again risking going off-topic, was there any discussion about (optionally?) making templates for people linkable, if they already have entries in ISFDB? e.g. off the top of my head Ken Liu, Harry Harrison and Ursula K. Le Guin all have translator credits, and it would be a minor improvement to have their names link to their bibliography page. Whether this would need to be done via a different template in the note, or by some sort of dynamic lookup at render time, I dunno. ErsatzCulture 13:08, 21 February 2021 (EST)
Yes, the issue of making the Translator template linkable was discussed in September 2018. Ahasuerus 16:31, 23 February 2021 (EST)

Fine Points of Variant Dating

It is my understanding that for variant title records, we date them with the first publication using that combination of title, author's name and language. I will usually clean up variant dates when I encounter ones that are incorrect. However, I have always considered changes in title due to disambiguation, or in title type not to trigger a new title date. For example, this coverart, titled "Stirring Science Stories, April 1941", has this variant with the title "Stirring Science Stories, April 1941 (cover)" as INTERIORART. In this case I would have entered 1941-04-00 for the date of the variant since the main part of the title, "Stirring Science Stories, April 1941", hasn't changed. I have treat changes in the ordinal numbering disambiguation ([2], [3], etc.) the same way. For example, this illustration, which appears in a single publication multiple times requires the numeric disambiguation and I have kept the date of the original appearance, 1924-11-00, for each disambiguated appearance. However, another editor has interpreted this differently and changed the dates of the variants of this title to match the first time they appeared with the given disambiguator. So to sum up the question, should a change in title type (e.g. COVERART -> INTERIORART) or a change in disambiguation trigger a change in date of a variant record? --Ron ~ RtraceTalk 07:37, 13 March 2021 (EST)

We have had the discussion of covertart vs interior art before and the result was interior art variants should be dated by the first date of their appearance. The Eyrie case is an oddball and I don't recall that case ever being discussed. -- JLaTondre (talk) 09:49, 13 March 2021 (EST)
I agree - we date based on first appearance of this title/author/type/language combination - the same way we would date a story that get republished under a new name, even if the new name contains the date of the original publication. That allows us to see when a title/author/type/language combo is used without the need to check each book one by one. So interior art that used to be a cover gets dated as the first appearance of the interiorart, not when the cover was created.
However, the disambiguation 1, 2 and so on is there because we cannot have the same art twice in the same book - so we should probably date these based on the non-disambiguated title appearance. However, that’s not the case in the initial example above. We have a change of type - so the new type calls for proper dating (see my note for being able to see what is used when). The Eyrie is definitely different - I will be in favor for clarifying the rules for these. . Annie 14:45, 13 March 2021 (EST)
A few months after the first discussion we had another one, followed by this. Consensus was reached to date any variant title on the first date that variant was published, which led to this feature request and this cleanup report, announced here, as yet only displaying coverart and serial titles. There were some 10.000 interior art mismatches waiting. The question of disambiguated titles never came up in the discussions, imo this could be an exception. I'm not in favor of changing the rules again. --Willem 15:09, 13 March 2021 (EST)
To clarify my note - I would be in favor for dating change only for the disambiguated ones (with the 2,3 and so on) which are done to ensure that we can have 2 versions of the same one in 1 book. Annie 15:28, 13 March 2021 (EST)
My logic for treating these as I have is that whether adding "[1]", "(cover)" or having a changed title type, the title as published in the book has not changed. We are merely adding something artificial for purposes of disambiguation. --Ron ~ RtraceTalk 15:40, 13 March 2021 (EST)
But we are also changing the type - a cover is different form interior art and hiding the date when a cover is used as an interior art is not nice in a dB. We had that conversation years ago - see the link above. Cover reprinted as interior art is not the same as the cover - and gets its own dating. We are a dB - why would want to make people need to check the listing under every interior art if they need to know when it is used like that for the first time - instead of having it on the entry? This is exactly what we discussed and made a decision on last time - which was to hold the rules as they are. Annie
Sorry, but you're going to have tell me which discussion you are referring to. The first seems to be chiefly about adding a new record based on creation date of things like paintings subsequently used for covers or interiors. It does have a side note about the oddness of seeing a "the date 2002-10-00 for Amazing Stories, June 1926 (cover)", but it's not addressed in new proposed language (now adopted? Text isn't in this template nor in the Rules and standards changelog). The second and third discussions deal with changes in language of the artwork, which doesn't apply to this discussion. The result of the first discussion said "Title records for artwork (COVERART and INTERIORART) should follow the varianting and dating rules used for the titles of the works illustrated". The work illustrated is never going to have a variation due to a change in title type, since only allow that for artwork. You do have a point about the date. However, I'm not sure if anyone looking at the "Amazing Stories, June 1926" is really going to wonder when was the first appearance of that artwork printed either inside or on the back of a publication, but not on the front. Even stranger is this where we can at a glance tell when the artwork was repeated 7 times versus when it was repeated 8 times. BTW, this not a practice I use only for artwork. In this publication should I have dated the second iteration of the poem 2016? --Ron ~ RtraceTalk 17:40, 13 March 2021 (EST)
There are two separate cases here:
  1. Coverart also appearing as interior art
  2. The same title and title type with disambiguation added
The first case has been hashed out repeatedly (as linked above) and the community opinion has been the we apply our existing rules to it. And those rules (per Template:TitleFields:Date as you linked above) are "When entering a variant title record, enter the earliest known date when this variant record was published" (emphasis added). There is no exception in the rules for art. For the second case, there seems to some agreement that we have an exception for that. So I'd recommend suggesting a proposed modification to the rules for us to discuss. -- JLaTondre (talk) 10:24, 14 March 2021 (EDT)
Again I would ask which discussion you are referring to where changes in title type were agreed to. The first referenced discussion only speaks to this obliquely and comes up with proposed language that says "follow the varianting and dating rules used for the titles of the works illustrated". Those rules state that we should use the earliest date of the variant: "When entering a variant title record, enter the earliest known date when this variant record was published. This includes variant title records created for new titles, new alternate names, new translations and/or significant textual revisions." Title type is not included in the enumerated changes that necessitate a new date. --Ron ~ RtraceTalk 15:42, 14 March 2021 (EDT)
The quoted part of the Help template starts with "enter the earliest known date when this variant record was published" [emphasis added]. Since a variant INTERIORART record is a separate title record, the current rules require that we use the first known date of its appearance as opposed to the date of its parent title record. Or am I missing something? Ahasuerus 13:50, 15 March 2021 (EDT)
I will propose text that eliminates a new date for both cases as:
"When entering a variant title record, enter the earliest known date when this variant record was published. This includes variant title records created for new titles as published, new alternate names, new translations and/or significant textual revisions. Changes in title due to a disambiguation suffix, e.g. [2] or (cover), or changes in title type, should not be considered to be a new title for purposes of dating"
Again, if there are repeated discussion where we agreed that title type necessitated a new date, please point me to them. --Ron ~ RtraceTalk 15:42, 14 March 2021 (EDT)
I will oppose this. Strongly. A big chunk of the old 2 discussions was about not dating interior art based on its appearance in different form. If we need something to be a variant, it needs a new date when it shows up as a variant. This is the current rule - there are no exceptions. Unless you can show a rule that allows exceptions? So what you are proposing is a change of rules as written (and agreed in later) and a departure of how we treat variants.
If we want to allow for “we need this one so we can have two copies of the same record in the same book” then I am fine. But dating interior art based on when it was published as a cover or as a real picture (for art that started as actual art) is back to what we agreed not to do. I will ask you again (a bit strongly) - why are you trying to cripple the DB by hiding information on the usage of the image inside of a book and enforcing a date that has nothing to do with the interior art record? If you do that, what is the difference between that and using the cover in a different language or as a cover to a different book (or the same book but under a different title)? We date based on the variant usage there, this is not different. Annie 22:05, 14 March 2021 (EDT)

Non-genre magazines and editor names

Our rules for non-genre magazines say:

  • Enter in the "Editor" field "Editors of PERIODICAL NAME". If the actual editor is known with reasonable certainty, you may optionally enter the name(s) of the editor(s) as co-editors, but leave "Editors of PERIODICAL NAME" as one of the editors in any case. For the "Editors of" line, get the actual periodical name as correct as possible.

The usage in most of the non-genre magazines in the DB had been to include the actual editors names only if they are of genre interest (which is why we use "Editors of" to start to - reducing the number of non-genre editors in the DB). However, that understanding differs between moderators so let's decide what we actually mean:

  • If we know the editors, we want to include them as co-editors even if they are of no genre interest at all. Nature and New Yorker have clear editors for example...
  • We want to include the editor as a co-editor only if they are of genre interest.

What are everyone's thoughts? In both cases an update of the help page to clarify will be a good idea but let's figure out what we want to do.

For the record, I think that including the names of non-genre editors defeats the purpose of using "Editors of". But if everyone else thinks the opposite, so be it. :) Annie 19:20, 24 March 2021 (EDT)

I actually disagree with many of the restrictions we place on non-genre magazines, but this is not one of them. The actual editor can be an important or interesting piece of data as they undoubtedly were responsible for publishing the genre stories. There are certainly examples of other non-genre magazines where this data has been entered (Adventure, Blue Book and The Strand). I know that the procedures for entering non-genre periodicals predate the non-genre flag. Perhaps we no longer need the special "Editors of ...." EDITOR record now that the EDITOR record can be marked non-genre. I find myself asking Why are we treating this differently than we would a general fiction anthology that contains some genre fiction? In that case we would add the anthology with the actual editor, and all the other data we ordinarily enter with only the exception of the non-genre content. We would mark the anthology title record with the non-genre flag and everything would be fine. It would certainly simplify things. --Ron ~ RtraceTalk 19:54, 24 March 2021 (EDT)
I never liked having different rules for magazines and books to start wiht and it is even more glaring in the non-genre world. But as we do have them, I am trying to at least make them appear consistent/logical...
If we decide to drop the usage of "Editors of" being mandatory for non-genre magazines (leave it as an option if we want to use it but don't force it everywhere on non-genre magazines), I won't disagree with that at all... Annie 20:14, 24 March 2021 (EDT)
I'd rather have the editor's name if known, and skip the "Editors of". Doesn't appear to add any value. TAWeiss 21:49, 24 March 2021 (EDT)

(unindent) And apparently we started discussing what we are doing about this exact usage of the author names in 2018, changed the rules half-way through and planned to have a discussion on the rest - and it never happened. So I guess this is the overdue continuation of the 2018 rules changes. :) Annie 00:43, 25 March 2021 (EDT)

Since we can now mark these entries as non-genre, I think the best and least confusing path would be including the actual editors and dropping the "Editors of MAGAZINE" unless we don't know the actual editor(s). I'm all in favor of simplifying anything we can in the various rules. ···日本穣 · 投稿 · Talk to Nihonjoe 12:19, 25 March 2021 (EDT)
Sounds like we are all converging on this... :) Annie 13:11, 25 March 2021 (EDT)
Sorry, this will be a little long-winded. Four separate thoughts:
  1. I don't understand why "Editors of" is required. If we have an actual editor recorded, I see no point in also having an "Editors of" record.
  2. Not recording the actual editor(s) to avoid non-genre clutter is internally consistent with not capturing the covers or cover artists for the same reason. If we think we ought to change the rules for any of them, we should consider changing it for all of them.
  3. I used to be more sympathetic to the anti-clutter goal than I am now; I would rather see more complete information, in case it is useful in the future.
  4. If a person has a record, and so "bibliography", due to works where ISFDB policy clearly dictates the person's role in a published work should be recorded, it seems wrong to me if that bibliography does not include entries for other ISFDB-recorded works for which that person is responsible. For example, suppose Chris McGrath did a completely non-genre/non-fantasy cover for an issue of The New Yorker, and that issue of the magazine were recorded due to inclusion of some SF story. We wouldn't record the issue just because he did the cover, but once we're recording the issue anyway, why not record that he did it?
For #3 and #4 I have a real-life example. The Bridge World, a non-genre magazine related to the card game, has from 1994 to date run a slew of stories featuring Cthonic the bridge-playing robot. Through later 1997, the magazine's editor was Edgar Kaplan. After he passed away, Jeff Rubens took over. By fall 2004, 16 issues of the magazine in 7 different years contained these stories. If the magazines had been recorded as they appeared, there would have been no formal record of Rubens' participation. In November 2004, The Principle of Restricted Talent was published by the Cthonic story authors. It collected the previously published works, as well as some new stories. The foreword for that book was written by... Jeff Rubens. If I hadn't been familiar with both the book and the magazine and/or had not been entering the magazine information after the book was published, the linkage between ISFDB records for the book and magazines via the Jeff Rubens common bond might not have been made, since Rubens' editorship would not have been recorded. I realize some hearts will not be broken over that thought, but this is a bibliographic database, and that kind of linkage is exactly the kind of thing we should be identifying and recording.
Aside from a small amount of clutter, I don't see what harm recording the editors (or cover images, or cover artists) for non-genre publications causes. And having it recorded might be helpful in the future. --MartyD 15:55, 25 March 2021 (EDT)
I am trying to recall the original arguments in favor of the "Editors of ..." data entry standard. I think one of them was that it can be hard to decide what kind of magazine/newspaper editor we want to enter in the "Editor" field when dealing with non-genre periodicals.
Consider the non-genre newspaper The New York Times. Wikipedia has a list of its top officials, including top editors, going back to the 19th century. The list includes "editors in chief", "managing editors" and "executive editors". The last position has a note to the effect that it was "created in 1964 superseding Managing Editor as top news official" and then mentions that it was vacant between 1969 and 1976. Finally, there is "Editorial page editors" with a note stating that the position was "titled Editor-in-Chief or Editor until retirement of Merz but never had authority over news pages".
Given this web of overlapping positions, what should a "naive" ISFDB user enter in the "Editor" field when entering a NYT issue? And that's The New York Times, an established newspaper whose history has been well documented over the decades. Trying to sort these things out for an obscure regional periodical published a hundred years+ ago would be much harder and the results would be much less reliable. Ahasuerus 16:51, 25 March 2021 (EDT)
So keep it as an option for the magazines we do not know the editors of but do not enforce it for the ones we know the editors of. I would be happy to use uncredited instead as we do for anthologies but we had already used "Editors of" for a long time so we can as well continue...
That will leave the big dailies and so on in the old format but allow Dragon and other mostly smaller (and occasionally peripheral to us - a lot of these are movies and game ones) non-genre magazines just with their real editors. Annie 17:33, 25 March 2021 (EDT)
I've always thought the "Editors of ..." + "Name" was misleading. It makes it sound like the named person was only one of multiple editors when often they were the only one. I'm in favor of allowing only just the named editor(s) when people want to add it and using "Editors of ..." for cases where they don't want to bother tracking it down (for example, when the data entry is based on secondary sources) or it's otherwise too complicated. As for "uncredited", we only use that when there is not a credit and that should be allowed as well for cases where the non-genre magazine is known to not have an editor credit. -- JLaTondre (talk) 19:25, 25 March 2021 (EDT)

Proposed change: Using "Editors of"

We all seem to be converging on the same idea so here is a proposed text/rule change: In How to enter non-genre magazines, replace

  • Enter in the "Editor" field "Editors of PERIODICAL NAME". If the actual editor is known with reasonable certainty, you may optionally enter the name(s) of the editor(s) as co-editors, but leave "Editors of PERIODICAL NAME" as one of the editors in any case. For the "Editors of" line, get the actual periodical name as correct as possible.

with

  • If credited in the magazine, enter the editor name as printed.
    • If the magazine has more than one editor and some of them are unknown or unclear, use "Editors of PERIODICAL NAME" as a co-editor.
    • Using only "Editors of PERIODICAL NAME" is also permissible.
  • For the "Editors of" line, get the actual periodical name as correct as possible.

In The editors names section, replace

  • If the actual name of the editor(s) of a non-genre periodical is known, their names may be listed as co-editors along with "Editors of PERIODICAL NAME".

with

  • If the actual name of the editor(s) of a non-genre periodical is known, you can use their names. "Editors of PERIODICAL NAME" can be used to substitute 1 or more unknown editors.

Thoughts? Feel free to rewrite the wording. That removes the mandatory requirement for Editors of while leaving it in place for when it makes sense or when the data cannot be found or is unclear. Plus it leaves all the existing non-genre magazines in the DB IN policy (so no cleanup required). Annie 12:18, 26 March 2021 (EDT)

I like the changes. ···日本穣 · 投稿 · Talk to Nihonjoe 12:25, 26 March 2021 (EDT)
I would change that last sentence into
*If the actual name of the editor(s) of a non-genre periodical is known, you can use their names. "Editors of PERIODICAL NAME" can be used to substitute 1 or more editors.
I.e. leaving off the 'unknown' allows to hide editors not of interest behind the "Editors of ..." thingy. MagicUnk 18:14, 26 March 2021 (EDT)
Agreed. I'm in favor of the change with MagicUnk's modification. -- JLaTondre (talk) 08:12, 27 March 2021 (EDT)
I think the proposed text as amended by MagicUnk would be an improvement. My main concern with the new wording is that we would still have two separate Help paragraphs discussing essentially the same data entry rule. It's duplicative at best and may facilitate a later divergence at worst. Ahasuerus 14:39, 27 March 2021 (EDT)
So let’s drop the second one. Annie 15:14, 27 March 2021 (EDT)
It sounds like we have consensus. To be on the safe side, let's give it until the end of the weekend in case anyone has missed the discussion. Ahasuerus 18:11, 1 April 2021 (EDT)
I like MagicUnk's modification, too. ···日本穣 · 投稿 · Talk to Nihonjoe 18:00, 2 April 2021 (EDT)
If we are going to update the rules, and only keep one set, may I suggest the following text?
  • If credited in the magazine, enter the editor name(s) as printed.
    • "Editors of PERIODICAL NAME" can be used to substitute 1 or more editors when they are unknown or unclear, or not of interest.
    • Using only "Editors of PERIODICAL NAME" is also permissible. <-- this can be left out as it's implicit in the sentence above (or kept for clarity's sake)
  • For the "Editors of" line, get the actual periodical name as correct as possible.
Or is this proposed text too dense to be easily understood? MagicUnk 10:27, 5 April 2021 (EDT)
I'm good with it. It captures all cases discussed. -- JLaTondre (talk) 17:07, 6 April 2021 (EDT)

(unindent) Let me try to consolidate the language and adjust the wording to be consistent with the rest of the Help page (e.g. "periodical" instead of "magazine"):

  • If credited in the periodical, enter the editor name(s) exactly as printed with the following caveat:
    • "Editors of PERIODICAL NAME" may be used instead of some or all editor names if they are unknown or unclear or not of genre interest. If using the "Editors of ..." format, get the actual periodical name as correct as possible.

Hopefully this covers everything. Ahasuerus 09:55, 7 April 2021 (EDT)

Looks good to me. Annie 12:42, 7 April 2021 (EDT)
I like it! ···日本穣 · 投稿 · Talk to Nihonjoe 13:11, 7 April 2021 (EDT)
Agreed. -- JLaTondre (talk) 18:48, 7 April 2021 (EDT)

Outcome -- Help:Entering non-genre periodicals changed

The agreed upon change has been made. Thanks to everyone who contributed to the discussion! Ahasuerus 09:26, 8 April 2021 (EDT)

Magazines naming - including the issue number

Our current policy (as written) is to use Magazine Title, Date but a lot of magazines do have both a number and a date (see Locus so our practice has allowed the number for a long time, despite the written rule. We also mention: "If there is no apparent date, or the date is incomplete, a volume/issue number may be substituted. The date is preferable, but the usage (be it the one of the magazine like Interzone or the one of the country of publication as in France) or an erratic or undocumented publication schedule may lead to the use of only the issue number."

The grid of Locus allows you to find an issue when you have just the number. The grids of Cossmass Infinities or Dragon (we used to have the numbers on this one but Rtrace cleared them out in the last days enforcing the rule as written) are useless for that - all you see is the same month you have at the top of the list so if you have a reference saying that something is printed in Dragon Magazine 121, it is impossible to even start guessing where it falls in the table. And going into the series does not help - the number is only in the notes (if someone bothered to add it there). We could not have made this less user-friendly if we had tried...

My proposal (Taweiss mentioned it the other day and it made me thinking) is to stop strictly enforcing the "Magazine Title, Date" format when the issue numbers are clear and allow "Magazine Title, Magazine Issue, Date" as an alternative format, with the issue number formatting as it is used on the cover/masthead/title page (depending on what the magazine has). We have magazines where this will not be practical as it is hard to define an issue number but for a lot of the modern ones, the issue number is clear. And we have a lot of magazines already following this format... The only argument in previous discussions (and earlier) had been the inability to find a clear issue number for some magazines but alternative allowed formats will work (and leaving this so useless just because some magazines cannot get better than what we have now does not sound as a good idea to me). And if we ever get the extra fields (As per the outcome of the linked 2018 discussion), migration (and making the grid use the new fields when they are there) will still be easier than doing it based on the notes. Thoughts? Annie 14:00, 7 April 2021 (EDT)

I like this idea. ···日本穣 · 投稿 · Talk to Nihonjoe 14:27, 7 April 2021 (EDT)
I strongly disagree with having two correct and competing standards. If we allow that, do we allow records to churn back and forth between the two standards? If not, which one wins? First editor? Last editor? Any active verifier? I think that were we to allow this, we'd end up with a chaotic mix of varying standards within any single magazine grid.
In the prior discussion, there were objections beyond the inability to find a clear issue number. Other unanswered objections were when to use which of the two existing or the one new proposed standard? Also we never decided on a standard way to reflect the issue number (#, Issue, No. Number, Whole Number). Further, the presumption in both these discussions is that we are talking about the whole number of the magazine. There have been editors that have tried to also encode volume and issue (e.g. here). The same arguments about wanting to reflect the whole number in the grid could also be made about volume and issue number. Do we really want the title field of F&SF to read "The Magazine of Fantasy & Science Fiction, Volume 138, Numbers 1 & 2, Whole Number 747, January/February 2020"? I think the prior solution of dedicated fields for these items works far better than overloading the title field with additional data beyond the minimum to make each issue's title unique. We could then add whichever data items into the grid just like we did with format. I think waiting for the FR is a far better solution. --Ron ~ RtraceTalk 18:12, 7 April 2021 (EDT)
Let's be pragmatic. The FRs will take years to implement - if ever. Our grids (and magazine series lists and yearly records) are useless in their current form. And we all know which magazines are ok with just dates - we are talking about allowing alternative format, not enforcing it. Basically codyfying what had been happening anyway.
Most of the modern magazines will have clear numbers and are known by number, not by date. Are you really advocating disabling the usefulness of the DB just because of the few that cannot? Can you please propose how a person who has Dragon Magazine 121 is to find the record in our DB? Ideal solutions that work for everything are all great and nice but when looking for them makes the DB useless and unsearchable, they are not a good idea. Annie 18:29, 7 April 2021 (EDT)
I don't find the issue grids useless at all. A person with Dragon Magazine 121 can simply look at the issue date and find it in the grid. I have to assume that The Dragon has a cover date, or we should have entered it with issue number only per the current standards. Alternatively, they can use advanced search and look for Dragon in the series name and 121 in the notes. However, we don't have the May 1987 issue entered yet. Looking at FictionMags, it does not appear to have the date on the cover. However, the September 2007 issue has both date and number. The June 1977 issue has only month, volume and number. Will the hypothetical user know that we list Vol. II, No 1 as #7? A magazine from the same era, Omni, has only dates on the cover even though FictionMags lists volume and number for all issues. If we all know which magazines are OK with just dates (I don't), then why don't you define when that standard should be used vs when your new standard should be used. If both date and whole number + date are valid, then I certainly would not expect anyone to re-add the issue numbers to the existing issues of The Dragon. Or, if that is allowed, then anyone would be within their rights to remove them again. You actually seem to be advocating for the whole number + date to be the preferred standard, in which case, why wouldn't we convert the hundreds of issues of F&SF? If it's obvious, it should be able to be written down. Being that I asked this in the previous discussion and again here without anyone offering a clear answer. I'll also note that I've been waiting for support for persons with roles other than Artist or Author/Editor (translator, abridger, editor of novels) to be added for far more years than we've been waiting for this FR. I don't go against the standards by entering translator as a co-author which would certainly make them easier to find. Instead, I patiently wait until that feature will be eventually implemented and keep the translator in the notes. --Ron ~ RtraceTalk 19:34, 7 April 2021 (EDT)
I am not going against the standards anywhere, am I (although a lot of editors and moderators had through the years and I probably had stepped weirdly somewhere - as we all had)? I am proposing a change in the rules that would make the DB more user-friendly. Is that the same somehow? Adding translator names as authors will be a problem because they will be new authors on variants and that makes a mess of the way the DB works (you need the authors on the parent or the listings are all messed up). So the only option for the translators at least until some changes are done are the notes. Magazine issue numbers on the other hand can be made available without a software change and without losing anything in the process.
The grid, when the standard is enforced, is useless for finding the issue by number. The Locus grid can be used for that. Needing advanced search to find a magazine issue by number is neither intuitive, nor something an internet user will do. They will look around, realize that our listings are weird and decamp to FictionMags. And there is no way for a user to know if we miss the issue or we just do not have the number in the notes (even if they somehow figure out how to search for it) unless they understand our idea of data entry.
Until a few years ago, we had the Wiki pages with the grids manually built based on the magazines series. These had the numbers sometimes (not often but they could be easily added there). When we cleared them, based on the agreed policy of cleaning the Wiki and not needing a manually built table where we have an automatic one, the list of issues with numbers does not exist anymore. Which made the magazine lists a lot less usable.
I find the Dragon Magazine grid with no number on the issues to be less usable and less intuitive and a lot less user-friendly than it used to be when the numbers were there. These issues are often referenced by number online. Unlike Asimov's, Omni and FS&F for example. If someone wants to add the numbers to them? Considering the number of PVs, this will mean discussion and if most people agree, majority rules, right? Considering that the main verifiers of The Dragon was the first to point out the grid losing information, I expect that to be one of the magazines that will get its numbers back if the rules are changed. Or the question to be brought up for discussion anyway which may lead to the same (and I would support them being added back under rules allowing for it).
The rules as we have them work nicely for old style magazines - the ones that people know by date anyway. New ones are very often going by issue number, even when they are monthly. Staying stuck with a rule defined for 20th century American and UK magazines (with vastly different distribution model than modern magazines) just because we cannot reconcile the two standards is... a bit short-sighted. Annie 20:19, 7 April 2021 (EDT)
I didn't mean to suggest that you went against standards. However anyone who entered both an issue number and a date in the title field did. This was proposed before and the rather than change the standard, the consensus was to do a feature request with dedicated fields. I daresay most magazines in the database (including the first 278 issues of The Dragon) are 20th century US or UK magazines. I don't think referred to by number vs referred to by date on the internet is good standard either as it is hard to quantify. Can you please define a bright line rule where someone looking at a magazine (or a secondary source) can say which of the 2 existing standards or your proposed new standard should be followed. We have such rules for when to use the other two standards. Please come up with a rule so we don't have to discuss issue by issue over the entire run of any magazine, which format should be used, with each new verification. --Ron ~ RtraceTalk 21:25, 7 April 2021 (EDT)
We have a lot of new magazines being added (webzines and ebooks ones mainly; some printed versions as well) - the old distributions models are all but dead while the magazines are still alive and thriving so the numbers will start tipping the other way if they had not yet. For most of them they are more likely to be referenced by number and not date... These suffer - see my other link at the beginning of the thread.
Any magazine that prominently shows an issue number on its cover and/or title page should be allowed to have it also on its title here. That tends to be also how people look for magazines (and when talking about them). So that is the search we should be making easy.
I am not proposing removing the date. I am proposing adding the Issue number as well. Anyone searching by date will still be able to find them. But now anyone that looks for them by issue number will also have a chance. Getting more user-friendly is important - we have enough arcane rules for editing, having weirdness for searching as well is not a good idea...
As for the new fields - I had learned to be pragmatic. I can wait but if there is a way to make the DB easier to search and more user-friendly in the meantime, I will always go for it. The point of the DB is for people to use it, right? :) Annie 21:45, 7 April 2021 (EDT)

(unindent) A few general thoughts:

  • The "Missing or variant dates" paragraph in Template:PublicationFields:Title is, as currently written, rather confusing:
    1. It only applies to magazines, but it appears at the end of the Template page, far away from the "Magazines" section. It needs to be merged with "Magazines".
    2. It covers a number of different issues in one big undifferentiated paragraph. It needs to be broken down into multiple sub-bullets.
    3. It doesn't mention fanzines or other periodicals like newspapers.
    4. It doesn't tell you how to enter biweeklies like the first 8 issues of Authentic or other magazine issues with a fully qualified date.
    5. It doesn't tell you where to find the date. When talking about quarterlies and monthlies, it mentions "the date in the form given on the magazine", which probably refers to the cover, but it's unclear. "If there is no apparent [stated?] date, or the date is incomplete [how incomplete is "incomplete"?], a volume/issue number [both volume and issue?] may be substituted" is not really clear either.
  • This problem may have become more pronounced in recent years, but it predates the electronic age. Consider New Worlds Magazine, which, depending on the era, used issue numbers or months or seasons -- or some combination of values -- on the cover. Ditto Future / Future combined with Science Fiction. Our records are currently inconsistent as seen on the linked grid pages. I suggest that we don't touch them until we have a better understanding of the issue.
  • Unlike books, where the title page is our well-established standard, the standard for magazine titles is ambiguous:
    • For the title of a magazine, the best source is the information (often below the table of contents) about the publisher, giving the address; this often says something like "IF is published monthly by . . . ." If this is not present, the magazine cover and the heading on the contents page are about equal in priority; again take a good guess. The name on the spine should be used last.
  • This ambiguity exacerbates previously noted date ambiguities because editors are supposed to create a composite title built from chunks of information potentially found in different locations -- the cover, the publisher's statement, the top of the TOC page or the spine.

I'll post about the issue raised in the original post after I give it some more thought. Ahasuerus 14:36, 8 April 2021 (EDT)

I have pulled out a few of my magazine stacks and compared them to our records. The first thing that I noticed was that many of our records prioritize consistency between issues over the rules stated in Template:PublicationFields:Title. For example, consider Other Worlds Science Stories. Every physical issue that I have checked says "Other Worlds Science Stories" on the spine, but the title on the cover and on the TOC/copyright page is often given as simply "Other Worlds". The rules in Template:PublicationFields:Title state that "the name on the spine should be used last", but our records use the title on the spine even when other, supposedly higher priority, titles are different (see this issue for an example), presumably to make issues look consistent.
The second thing that stood out was that Template:PublicationFields:Title says "Information [to be used in the title field] can also be drawn from bibliographic sources when useful". That's very different from the standard which we use for books, where we rely on what's stated on the title page. Moreover, when you combine it with the Help statement "The date is preferable", it can be read to mean that a date found in a secondary source can be used in the issue title even though the actual magazine title is "Stupendous Stories #2" and there is no date in sight. That's very confusing and very different from the way we enter books. Ahasuerus 13:48, 10 April 2021 (EDT)
It is. It also means that a magazine that does not have a month printed anywhere on it (or only hidden in the publisher data somewhere) can be named with the month (and be in policy) while the cover and the world uses only the number. Which makes it even harder to know how to search for it in our DB (we are a dB after all, search should be one of the main concerns when rules are made up). Thus my attempt to find a middle ground and get the magazines’ usage of dates and issue numbers lead us to naming as opposed to us applying artificial rules regardless of the magazines and what their covers and title/copyright pages say. Annie 14:52, 10 April 2021 (EDT)
The publisher data is hardly hidden, and by the current standard is preferred: "For the title of a magazine, the best source is the information (often below the table of contents) about the publisher...". Yes, I do believe the current rules allow for a date only from secondary sources. My theory as to reason for including the cover date as part of the title field, is to make the title of individual issues unique. We even enter the date in a standardized format which suggests that the date is not meant to reflect what is in the magazine. Despite how we've modeled it, are cover date or any of the numbers really considered to be part of the title of a magazine in the real world? The current standards allow for cover date, volume and issue number, and whole number under different circumstances, but never more than one of those. When we discussed this before, we decided put the number data into new fields, which I still believe to better approach than having the title field do all the work. --Ron ~ RtraceTalk 16:44, 10 April 2021 (EDT)
The new fields will not solve the issue of naming - arguably, one piece of data already has its own field - and because of our standards, for monthly magazines, it is an exact repetition of what we put in the title of the magazine. So you have the same information in searchable and visible form in the grid and the yearly list twice (both show the date and the title) while everything else is kicked to the notes. And using just a date for the title of a magazine that prominently displays an issue number is illogical. As I said - we could not have made that less user friendly if we had tried.
New magazines may have publishers and editors listed, if that. They will have an issue number but according to our rules we should ignore that fact and instead make up a date from somewhere (or just use a date that may be eventually somewhere but not prominent or obvious even to people who read the magazine. The days when all magazines had the nice publisher data had gone I am afraid. Even Apex which used to have an issue number and a date on the cover came out in 2021 with issue number only and the date is only available from their site. And yet, I suspect that you would argue that we should still name with the date - despite that the date is not even mentioned in the issue (please do not go and change it - the date is not in the magazine, it has no place in the title. I can date based on the secondary sources but I refuse to make up titles based on them).
How and why we had moved so away from “what is printed in the magazine” to “you can use secondary sources to determine the title of a magazine you are holding” would be laughable if it was not tragic. Inventing data is not what bibliographies are about - and yet, that’s what our rules are doing for some magazines. Making the data so hidden that it is effectively unsearchable is just the bonus.
And I still fail to see how “Magazine, Issue 1, November 1982” is worse than “Magazine, November 1982” or how it will cause confusion or issues. The old argument of “but the rule cannot apply to every magazine because finding the issue number may not be trivial” is not really valid - our rules already say that you can use data from secondary sources for the date - which allows a double standard for the same magazine already. That had not led to editing wars... Annie 18:17, 10 April 2021 (EDT)
Why would dedicated fields for volume, issue and whole number not solve the problem? If we had the fields, we could easily display them in the grid. We added format into the grid a while back in just this manner.
I've been actively editing since 2009 with some earlier edits going back to when the site was hosted elsewhere and Al was the only moderator. --Ron ~ RtraceTalk 19:54, 10 April 2021 (EDT)
A little stroll down the memory lane: Al rewrote the ISFDB software and created the moderation system in 2004-2006. He and I were the first moderators when the beta phase started ca. May 1, 2006. We then sought out additional contributors and quickly moderatorized everyone who joined for the next 7-8 months. It was touch and go for a while because we were working with live data and some of our contributors were inexperienced, but we survived. The new system went "live" at the end of 2006 and from that point on we used more stringent moderator qualifications. Most of the original beta testers stopped contributing after a while and eventually their moderator flags were revoked. Ahasuerus 21:40, 10 April 2021 (EDT)
My earliest edits were definitely made to a different host name (did it change twice? I recall an edu address at some point). I added much of Cabell's Biography of Manuel and recall that it took quite a long time for approval (weeks, months). I eventually gave up until later. I recall there being a blog where Al would 1) apologize for how long approvals took, 2) state what he was currently reading and 3) complain about how his copy of Clute/Nicholls was falling apart from over use. Anyway I drifted away because of the delays. In 2007, I must have rejoined because I have a welcome note from you. But it wasn't until 2009 before I started editing regularly. --Ron ~ RtraceTalk 22:13, 10 April 2021 (EDT)
Yes, the database was hosted by Texas A&M University between 2003 and 2007. I don't think we had approval delays that long in 2006-2007, so it must have been during an earlier attempt to create a moderation system. I wasn't involved with the ISFDB project between ca. 1998 and mid-2005 and missed most of the ups and downs. I did spend a number of months cleaning up after a (by then defunct) overzealous data acquisition robot in 2006. Ahasuerus 23:36, 10 April 2021 (EDT)
Because they won’t solve the problem of a user searching for the magazine who does not understand our structure or is coming from Google. Standards had changed a lot since 2009 (they had changed since I started editing in 2016). Some things that made sense back then do not anymore. So we try to find a way to get them improved (and it is even better if we can leave all we already have in the dB still in policy after the change - which my proposal will achieve). Annie 17:06, 11 April 2021 (EDT)
Though, to be honest, my earliest edits did not include magazines. I do not recall there ever being a standard that didn't allow for dating magazines from secondary sources. So, the tragic move you describe may have been the original standard for magazines. No one has offered an alternative to my theory that the date in the title field is for uniqueness of publication records as opposed to trying to encode cover date in the title field.
But that's not really the issue at hand. I strongly believe that good database design does not include overloading a column (title) with additional unrelated pieces of data (whole number). It's more properly handled by a dedicated field, which is what we decided previously. A discussion which I believe you also participated in. We can't just keep stuffing data into the title field because someone wants to see it in the grid.
I don't know why you think I would engage in editing data to conform to a standard, while it is being discussed. The edits I made to The Dragon, to bring the titles into standards, were done before you suggested a new standard. I even left a note on the verifiers page, stating my plans and linking to the help template. There were no objections until after I had made the edits. I've made no similar edits since we began discussing this. Contrast this with your statement that you refuse to enter data that conforms to the current standards. --Ron ~ RtraceTalk 19:54, 10 April 2021 (EDT)
Nothing to contrast. I refuse to enter data that conforms with a "can be used" statement which goes against the major policies of the site (we document the books, not what someone else had documented about the books), not with a standard. By definition a "can be used" allows ambiguity so an editor can decide what they prefer to do when the case arises. I won't stop someone from entering it that way or go and fix it for them (unless I hold the magazine and there are no other verifiers) but I am not going to enter it that way. The DB allows quite a lot of editor decisions (and when moderating, I'd approve a valid edit even if I would do things differently). Annie 17:54, 11 April 2021 (EDT)
As I have stated previously, your proposed new additional standard has no definition as to when it is used instead of the existing standards. Prominence of issue number on the cover would be hard to quantify. Recent issues of Locus have Date above the title, with whole number, followed by Volume and Issue number below the title. Is date most prominent? What should we do here? I haven't argued about difficulty of finding issue number, so I'm not sure to what you refer. However, I will not that I've discovered that the entire run of The Dragon is on Internet Archive. By your proposed prominence of the whole number rule, it does not appear at all in the magazine until the 8th issue. Or are you proposing that whole number be extrapolated from later issues? This would be adding additional data not published in the issue. --Ron ~ RtraceTalk 19:54, 10 April 2021 (EDT)
One thing to consider is that the planned addition of the 3 fields listed in FR 1202, "Add fields for magazine issue numbers to pub records" -- "Volume", "Issue", "Whole Issue" -- may not necessarily address the issue of magazine/periodical titles. Currently, we have a separate field for "Date", yet we also incorporate dates in magazine titles. It's conceivable that the same thing will happen once we have the new fields in place. It's part of the reason why the FR says "Further discussion may be needed to flesh out the design". Ahasuerus 21:29, 10 April 2021 (EDT)
Nope, I am not proposing to extrapolate data from anywhere. I propose to let the magazine issue lead is to its naming. So if the first issues have different structure, we have them named differently than the rest. Pretty much like I did with Apex when they dropped their date. What we would do for a book series that changes its volume definitions from 1,2,3 to IV, V and so on midway through a series (when the volume number is part of the series - same named anthologies for example).
My proposal is to treat magazines how we treat books - allow them to have the titles people can find on them and do not fix them. We can impose order (so it does not look too ragged between issues) but if the issue number is there, it belongs in the title. Annie 17:06, 11 April 2021 (EDT)
BTW: there is a difference between database design and site design. We can keep the data in separate fields and still show them in one display value when it makes sense. As our dB does not do that, we need to load into the title. If we had all the fields in play, we can construct a visible and searchable title from all the pieces - thus solving both the dB design issue and the human-reading issue. Then we will truly show what a magazine uses (unfilled values will be skipped). But that won’t solve the issue quickly and while I can be as patient as anyone, a temporary allowance of using the actual identifier that a magazine uses will help. Going back to Dragon - why was it so bad for it to have the issue number but it is ok for Locus? That is what made me thinking (and posting). No one would argue that dropping the issue number from Locus makes any sense, right? Annie 17:16, 11 April 2021 (EDT)
Well, I updated The Dragon because before your proposal, there was no standard to support both date and whole number in a title. I have been correcting non-standard magazines for years now and the only complaints have been the previous discussion which didn't result in a standards change, and your new proposal. I mainly did this when I moderated an edit for a magazine entered in a non-standard way. Changing the magazine title is not trivial. You have to also change the cover art title and any items that use the title for disambiguation. Sometimes I would fix the whole grid, sometimes just a few issues. I didn't try to tack Locus because I've not had to moderate and issue edit, and because the issues tend to be verified by active editors. I suspected that we were going to have to discuss this standard at some point, a discussion that I did not look forward to, and that I am not currently enjoying. Thus, I intentionally avoided having to argue the issue by concentrating on fixing records where there were no, or only inactive verifiers. As to what harm it would have done to leave The Dragon outside standards, I could make the same argument about deleting the cover art for a non-genre magazine unless it illustrates a fiction item. It also does no harm to have it included. Yet you asked Taweiss to remove them, because that's the policy. Someone did the same with the early Gernsback magazines recently. I don't question why people edited to conform to standards even though I disagree with those standards. Why are you questioning edits I did to conform to a standard that you happen to disagree with? --Ron ~ RtraceTalk 19:23, 11 April 2021 (EDT)
Where did I question the edits themselves or your reason for them? I even started with a note that we lost the numbers by "enforcing the rule as written". The changes made me think on the issue and to come propose a new solution. The changes are IN policy as the policy stands - or I would have reversed them. I have no issues with the changes per se - just with the loss of data because of them. Thus this thread. The question of Dragon vs. Locus above is pointing to the root of the problem - technically, if the rule does not get changed, Locus will also needs to be changed (and if it does get changed, all the notes with have sourcing Locus based on the issue number will also need to be updated (because if we tell people that the source is Locus 515 and it takes understanding the DB structure to get to the issue, something is really wrong in the Db; although the lack of comma in Locus will put them out of policy even under the changed rules but that's a different conversation). And the non-genre magazines covers are the next thing on my list of things to kick the dust on... :) Annie 20:49, 11 April 2021 (EDT)
That's the meaning I took from "Going back to Dragon - why was it so bad for it to have the issue number...". I will note that when I looked at the grid for the Dragon there was a mixture of standard and non standard titles. I was certainly not going to break the correct ones to make the grid uniform. Rather I fixed the ones that were non-standard. Perhaps you really only asking why I didn't fix the Locus grid, which I explained above. --Ron ~ RtraceTalk 21:49, 11 April 2021 (EDT)
Nah, it was mostly a rhetorical question leading to the sentence immediately after that explaining that this is what made me think about this whole thing (and I am still thinking - thus my db vs site note) and try to figure out to leave the numbers in the grid... If I have an issue with an edit, I tend to call it directly and lead with it, not bury it in the middle of a very long discussion. Sorry if it read that way - nowhere had I implied that the changes are against policy - they are in policy. As for Locus - considering how pretty much everyone had PVd, edited or moderated at least one issue, the fact that it is the one out of policy is almost amusing. But it also shows that the rule is not either as strict, or as universally usable as its writing implies. :) Annie 22:06, 11 April 2021 (EDT)

(unindent again) Full disclosure: I'm am of the "as stated in the publication" bent. My preference is that the standard basically allow use of the magazine's "natural" issue identification for the titles, even if there is then some ordering and/or formatting normalization. Note that the grid display works properly for any identifier after the comma. If issues are identified by whole number ("Foobar #21"), then the title should use that -- even if we know something else, such as date or volume. If issues are identified by date ("Foobar April 2021"), then we should use that. If issues are identified by date and whole number ("Foobar #21 April 2021") then use both, perhaps imposing an order of appearance on the distinct name, number, and date components. If the issues are identified by volume + number use that, and so on. I do think it would be a good idea to try to draw a line between primary identification and secondary identification, to try to avoid "Foobar April 2021 Whole #21 Volume 3 Issue 7", but even that extreme seems like something we could live with. I also think it is not a good thing to have our title requirements force construction of titles that don't match the way people identify the issues (e.g., forcing date-in-title for a periodical publishing on an irregular schedule and identifying itself by whole number -- no one will ever think of it as the April 2021 issue of Foobar). --MartyD 08:50, 11 April 2021 (EDT)

Pretty much my thinking when I posted. Leaving date only as also valid so we do not need to fix the old magazines. Annie 17:16, 11 April 2021 (EDT)
A few questions:
  1. What is considered the title page for purposes of how the name is reflected in the magazine? The current standard is 1) publisher information (often below the table of contents); 2) TOC and Cover with equal precedence (we should probably decide on an order since these can disagree; and, 3)The spine.
  2. If all data items are present (date, volume and number, whole number) do we reflect all three?
  3. If we are going to have a different standard for old magazines so that we don't have to convert any existing data, how is that determined? Is it data entered before the change in policy, or is it based on publication date? My personal opinion is that different standards based on these criteria isn't really workable. I'd have to see the proposed language on when to use the different standards to know for sure.
  4. I assume that we would want to standardize the order and format of the data items. I would recommend Date, Volume number, Issue Number, Whole Number no matter what order they appear in. Since this will crowd the grid, do we want to consider abbreviating the month in the date (January -> Jan)? For quarterlies and non-standard names, we probably should spell them out. For Volume and Issue, I'd recommend "Vol." and "No.", for Whole Number, I'd suggest using the pound sign (#) as the most compact, unless that will cause confusion with issue number. Also, I haven't tested it, but the year is currently suppressed in the grid. Will this continue if the year is in the middle of several data items, of will we need a code change to suppress it no matter where it occurs? Or, does the current software require that year is last in order for it to be suppressed. --Ron ~ RtraceTalk 18:45, 11 April 2021 (EDT)
One by one
  1. That order works for me. Cover should beat TOC of you ask me, and copyright page (which a lot of the newer magazines, especially e-magazines, have) can be used as a last resort. Unless you believe that the publisher information is the same as the newer copyright pages in which case using them as first option is against how we use them for books (and then we will need to make a distinction of what is publisher information and what is a copyright page).
  2. Why not? None of these should be mandatory though.
    If they are all optional, that's not a standard. The grid will be chaos. Your desire to have the issue number reflected will be left to the whim of the editor of each issue.--Ron ~ RtraceTalk 19:30, 11 April 2021 (EDT)
    We have a lot of optional standards. From the date that CAN be added from secondary sources to the EDITORS OF rule - the old one or the new one (to just cite two in the magazines rules alone). None of these had led to real problems. Bibliographers tend to try to keep things ordered. Add a "it is preferable that issues credited the same way are recorded the same way" if you want (although common sense had led to that through time).Annie 20:04, 11 April 2021 (EDT)
    That's never been my understanding of the clause about using the date from secondary sources. It's in the context of "Missing or variant dates", and it occurs after the statement "The date is preferable...". I believe that the clause is telling where you can find a date if it fails to appear in the magazine. If the intent is that this was up to the editor, then the word "optionally" or "may" would have suggested your interpretation. The words "must" or "should" wouldn't make sense here, since the date from a secondary source may not exist. My understanding of the new "Editors of" change was that it was left as an option for when the actual editor couldn't be determined. I can't imagine anyone deciding on "Editors of Non Genre Zine" over "John Q. Editor" if they actually know that data. --Ron ~ RtraceTalk 21:43, 11 April 2021 (EDT)
    Your own words above "Yes, I do believe the current rules allow for a date only from secondary sources." as a response to my "It also means that a magazine that does not have a month printed anywhere on it (or only hidden in the publisher data somewhere) can be named with the month". I am getting confused here so I will just ask - do you believe that if the date is derived from secondary sources and is NOT on/in the magazine, it CAN be added to the title under the current rules? If it can, then how is your understanding different from what I stated here and you say is not your understanding? If your understanding is that we cannot use secondary sources for the dates in the titles then why did we have the conversation around secondary sources and what does the comment I copied here from you mean? Dating (aka the publication date field) based on secondary sources is a different story, we are talking about the title.:) Annie 22:23, 11 April 2021 (EDT)
    Sorry, I didn't intend to be unclear with my meaning. My understanding of the rules as stated is that when the date is missing in the magazine, but can be found in a secondary source, then the magazine should be dated with title followed by date. When I said "That's never been my understanding", I was referring to whether getting the date in this manner is optional. I derive this from the statement "The date is preferable...". I understand "can" within the context to mean "where the date can be found" and not "you can do use date or not if you feel like it". I realize that we are arguing the choice of words (can vs. should) as if the help pages were crafted by lawyers, which they were clearly not. I continue to believe that optional standards are a bad and and lead to edit wars. --Ron ~ RtraceTalk 18:18, 12 April 2021 (EDT)
    Thanks for explaining. I still disagree with this interpretation and do not think that finding it in a secondary source means that it should/must be added to the title... But rules interpretation is part of why we have these discussions after all.
    While I do understand why you do not like optional double standards, I am really surprised that you defend a rule that allows a secondary source to overwrite a primary source. But as the naming issue is not just in this very narrow case, it does not really matter. And I still think that making up titles based on artificial rules and ignoring what the magazine says (and not including its identifier in its title) is bad and leads to bad user experience. :) Annie 18:38, 12 April 2021 (EDT)
    As for Editors of, we had known the editors of a LOT of non-genre magazines and newspapers and yet, they were almost never added unless they were genre ones from most people (as the rules allowed that). The changed rule as it stands now reads: "Editors of PERIODICAL NAME" may be used instead of some or all editor names if they are unknown or unclear or not of genre interest." which was the agreement of the Community. So yes - even if they know the editor, editors may decide not to add them IF they are not of genre interest. Which had been the usage all along for most people despite the way the rule was actually written - the change is that now we do not enforce the adding of "Editors of" IF we know the editors. I am not looking for another big cleanup project - I am trying to keep the new rules as much in line with the old ones as possible, leaving all existing data IN policy where possible - while opening the door for better data going forward. Same thing I am trying to do here. :) Annie 22:23, 11 April 2021 (EDT)
  3. Again, we allow the editors the leeway to decide if all the information should be added or if just an "issue, date" or just "date" is enough (similarly on how we allow editors to decide when a subtitle is part of the title of a book). That leaves what we have in policy and allows the flexibility to actually add the titles as they appear.
    That's not what we do. If there is a subtitle on the title page (excluding prosaic ones like "A Novel", or "A Romance"), it's supposed to be entered. --Ron ~ RtraceTalk 19:30, 11 April 2021 (EDT)
    We allow editors to determine what is part of the title and what is a subtitle. We can discuss if we want to allow (require) a Magazines's subtitles for some of this information and when or if we want this only in notes. We do not allow subtitles for magazines at the moment under the naming convention even though there are cases when they are needed (issues with special titles on some/all issues for example). I am fine either way. That goes somewhat to what Marty wrote about as well - secondary vs. primary identification for an issue.
    Unless your reading of this rule (because of where it is on the page) is that we CAN have subtitles on magazines already. Then all this missing information (volume, issue numbers, subtitles for special issues and so on) should already have been added as a subtitle (it is written in the magazine) and almost all our magazines are out of policy because as you pointed out, subtitles are required to be added. In which case the big question is "why had we all been adding every single issue out of policy so far?". And then the grid will need an update because that sends the data in the middle of the title. :) Annie 20:04, 11 April 2021 (EDT)
    Sorry, I thought you were stating that subtitles were optional for publications other than magazines. It isn't really clear whether the subtitles paragraph applies to magazines at all. Magazine have their own titling rules which ignore subtitles: "the title should be of the form Magazine Title, Date". The subtitle rules only give book titles as examples, and further the examples they give differ from practice, though not in a way that bothers me. Special issues of magazines are problematic as the standards offer no guidance. Is it a subtitle? Would it depend on which of the 4 sources has the special issue statement? I would probably put "Special Unicorn Issue" in the notes with the other unstructured data. --Ron ~ RtraceTalk 21:43, 11 April 2021 (EDT)
    Yes and subtitles rules are in a separate paragraph - the same level as titles case for example (which do apply for magazines, that we all agree on, correct?) so technically speaking, the subtitle rule should apply to magazines and as their titles are defined based on other sources (not the title page), their subtitle will necessarily need to come from them as well - subtitles come from where the titles come from. Reading the rule, all that additional information indeed will need to be part of a subtitle (same way it would be if this is an anthology and not a magazine - especially because unlike anthologies (and other books) where some of the numbering can go into the title series number field (or publication series number field or the catalog ID for some special cases), we cannot do this here because of how we treat magazines). But this is not how we had used the rule (And I really prefer not to) but if we want to be by the book, we should have. Or we can stop clinging to a 10+ years old rule which makes up information and discards valid printed data and actually bring the magazines to the ISFDB standards - the data in the publication takes precedence - and fix the rules and allow the data on the magazines to actually be added to the DB properly... Hiding data in the notes does not make it searchable or visible until you open the issue itself - which brings me to where the thread started. :) Annie 21:56, 11 April 2021 (EDT)
    Yes the paragraphs are at the same level, but given that magazine titles are stylized and already do not represent what is in the publication (full date, not how abbreviated on the page, not in a European format even if that's how it appears). Since the magazine paragraph doesn't tell you where to put the subtitle, in which case it will not parse into the issue grid anyway. --Ron ~ RtraceTalk 18:29, 12 April 2021 (EDT)
    Neither does the book paragraph tell you where to put a subtitle. The subtitle does not show up in the rules until after all titles are taken care of. The statement is "If the title has a subtitle, enter it, with a colon and a space used to separate the title from the subtitle." - no qualifications, no "only real titles and not constructs and imaginary titles". As the magazine section explains how to derive a title, by the time you reach the subtitle section, you have a title. And that title may have a subtitle. :)
    Shall we stop parsing the rules and looking for holes and arguments and instead try to find a way to record the magazines with their main identifier in their titles (as anyone would expect) and not hidden in the notes while data that is not even in the magazine makes it into the title? Annie 18:55, 12 April 2021 (EDT)
  1. Date should go at the end, not at the beginning. Leave the date at the end so the grid suppresses it and we do not have the issue. So Title, Volume number, Issue Number, Whole Number, Date, with at least one of the "Issue Number, Whole Number, Date" being mandatory will ensure unique naming. Annie 18:59, 11 April 2021 (EDT)

Catalog IDs and Publication Series Numbers

Magazines have three fields we never use - Catalog ID and Publication Series/Number. Using either the Catalog ID (Perry Rhodan uses it for example) or the Pub series number for the Issue number (whole number or just issue number or a combination of volume+issue number) will make them visible in the Yearly lists, searchable directly (as opposed to relying on parsing the Notes which may have all kinds of other numbers) and should not be that hard to be shown on the grid (to be confirmed?). It also will allow us different rules per magazine - so we do not need to deal with he whole "come up with something that works for every single issue - for some it may be as easy as 151, for some it may be "volume 1, Issue 2" and so on).

It does not solve the pure search issue but we can add some verbiage explaining how to search for a magazine (yes, we can do it now as well but relying on Notes and having to open multiple issues to find issue 12 is not really a great way to search). I still think that the main identifier (being it whole number, date or issue number) should be on the title itself but we may use the Catalog ID and/or Publication series Number to our advantage to assist in not overloading the title field with ALL the information we have (especially if the grid is changed to accommodate it). Moving from these fields to new fields when we get them will be trivial... Annie 22:32, 11 April 2021 (EDT)

Checking the database, I see that we have 1912 magazine issues with a populated "Publication Series Number" field. They are mostly German magazines like Dorian Hunter (Heftserie).
We also have 13509 magazine issues with a populated Catalog ID field, e.g.:
Edit: Checking the software responsible for displaying the "issue grid" page, I can confirm that it would be easy to make it display additional data elements like Catalog ID. Ahasuerus 11:05, 12 April 2021 (EDT)
Why does this look like a very big cleanup project coming up... It seems like people had been using weird fields for all kinds of weird things... How/why all these issues ended up with ISSN in the catalog ID field (with the word ISSN to boot) is... interesting (and absolutely not what the Catalog ID is supposed to be used for - a value that belongs to the whole set really should not be in the Catalog ID). The other 3 of the Catalog ID examples are exactly what I want to put in this field(well, or similar to it).
And looks like the German magazines will need yet another cleanup... Annie 11:19, 12 April 2021 (EDT)
I like using catalog id far better than other things proposed. Putting it in the grid would be solve what I understand is the search issue. I don't think we should use publication series, that will throw these all onto the publisher page and I'm not even sure how that displays if you have no pub series but do have a pub number. In any case we wouldn't want to mix all of one publishers issue numbers together. --Ron ~ RtraceTalk 18:41, 12 April 2021 (EDT)
I am fine using Catalog ID - I prefer it. I was just pointing out that we do have fields. Now of course we need to figure out what we put there (and then we need to figure out what we do with the 13K we have already) but that can get us somewhere. What the German magazines have in the field is a structured representation of the Issue number and title. As long as we document it, I am fine with it :) The Catalog ID won't solve the pure searching issue but will solve the visibility one and improve on the searching (parsing Notes is always a bad idea) so... I am fine with it. And we can always do a construct between the title and the catalog ID in a field downstream which will allow the search. Shall I start a new discussion so we can start figuring out what we are doing. And I will also be starting one to discuss stopping that nonsense with the secondary sources overwriting primary ones :) Annie 21:02, 13 April 2021 (EDT)
I confess that the edits I see of Perry Rhodan perplex me. I suspect that the naming standard would not conform to either the stated standard or anything we've proposed here. Also there seems to be a lot of churn of editor names. I skip many of the edits that I've encountered in the queue. --Ron ~ RtraceTalk 18:41, 12 April 2021 (EDT)
The edits of the German magazines in the last weeks is because Christian is fixing this mess - finally bringing the German magazines to policy on author names. Naming outside of the English magazines had never followed the stated standard - the three big sets we have (Italian, French and German) had done the logical thing (using numbers and names as visible on their covers) instead of the artificial dates format and some of the other non-English ones had followed the lead. As I keep saying - despite the rule, the practice had not been doing that for a very long time. You may like it and defend it but we had not been doing it anyway... so allowing the change would have just codified the practice... Annie 21:02, 13 April 2021 (EDT)
No, there are plenty of magazines that continue to follow the published standards, including recently entered issues. We even discussed changing the stndard a couple of years ago, and did not reach a consensus to to do so. Rather, we decided on an FR for new field. The fact that editors ignore the published standards and some moderators allow them to do so, does not mean all or even most of us ignore them. I also fully expect that folks don't bother to read the help files, but enter data by example of other data in the grid. Thus, when one person does wrong, other copy them and if the moderators don't enforce the standards, things start to drift. It's not that folks want it that way, they're just aping what they see elsewhere. --Ron ~ RtraceTalk 21:42, 13 April 2021 (EDT)
And where had I said that there aren't? Annie 22:03, 13 April 2021 (EDT)
From your statement above: "despite the rule, the practice had not been doing that for a very long time. You may like it and defend it but we had not been doing it anyway... so allowing the change would have just codified the practice". My emphasis. --Ron ~ RtraceTalk 07:12, 14 April 2021 (EDT)
It is interesting how you are willing to read all sentences as a whole in the help page (and perform some weird looping logic sometimes) but insist on taking single sentences out of context in the wiki. :) The practice of allowing both date and issue format, whatever makes sense... Nowhere am I proposing to abolish the date format or that all magazines use the issue format - I am proposing codifying the practice to allow both formats. I am not about to propose the construction of one artificial rule to replace another, I am trying to use what the magazine has to say. Annie 12:15, 14 April 2021 (EDT)
How was I supposed to read your statement "You may like it and defend it but we had not been doing it anyway..."? Yes I am defending the current standards. You say we had not been following standards. I point out that plenty of editors do because many magazine recently entered follow the standards. And then you ask me when did you ever say there aren't. I again reiterate that you did when you wrote "we had not been doing it anyway". What did I take out of context. I have read the help pages many many times over the last 12 years. I keep a separate browser window open with tabs set to different help pages always and I refer to them frequently. So yes, I am more familiar with our standards than a single conversation. You'll have to be more specific about how my logic is "weird" or loops. --Ron ~ RtraceTalk 19:02, 14 April 2021 (EDT)
My proposal (and everything after that) is based on the fact that our practice already uses both date-based and issue-based format and that allowing both is the easiest way to reconcile the rules and the practice. That's what we had been doing for a long time - not following the written rule when it had not made sense. At no time had I implied that the date format had never been followed or that no magazine follows them. Hope that clarifies my policy comments. Anyway - I think we are where we started - you support the date format only, I want to allow both date and issue number format. Maybe the middle ground will be to enforce Title, Issue Number, Date (when the elements are known) format. Which will require a big cleanup effort and changing pretty much any magazine we have... :) Annie 19:13, 14 April 2021 (EDT)
Or that the practice is to ONLY to use issue numbers? I did not propose to change it completely - just to allow both, the way the magazines had been entered in the DB. The practice had allowed both the Date based and the Issue Number based standard for a decade (or more). Proposing that noone had read the help page in all that time is a bit... offensive. Annie 22:03, 13 April 2021 (EDT)
Well, I think it is a more charitble explanation than the only other possible alternative. If editors and moderators have read the help pages and are aware that there is no standard that allows for both date and issue number, yet they contiue enter data incorrectly, or approve incorrect submissions, then they are knowingly going against the standards without first achieving consensus through this forum to change those standards. Which of those two options do you think explains the how this data got into the database? Ignorance or flouting of the standards? --Ron ~ RtraceTalk 07:12, 14 April 2021 (EDT)
I'd call it growing pains in a complex environment - standards evolve. Why consensus was not sought is unclear (and way before my time) but it had been more than a decade and when that happens, reconciling and finding the middle ground is preferable than sticking to a rule that apparently had not worked for way too many people. Take the language regularization - until we kicked off the rules discussion on that a few years back, the English-language rules applied to all languages (the rules did no specify a language or other languages being exempt from them) - and yet no German or French publication followed them (while other languages tried to which lead to the DB looking very weird in some languages). If a rule had been that systematically misused and virtually every single moderator had allowed it at one time or another, something is wrong with the rule. So we reexamine. For the languages, it ended up being an easy solution - everyone agreed. For the magazines naming, it seems to be a bit more complicated - one editor disagrees. If we decide to uphold it (which is not obvious at this point), we get a cleanup report and go clean all magazines that do not follow it. Annie 12:15, 14 April 2021 (EDT)
It would not have been the first time we had acknowledged a practice and codified it when it makes sense. As it does here. Annie 22:03, 13 April 2021 (EDT)

(unindent) having read through the whole discussion, I'd like to add some of my thoughts.
1. Let's agree that dates (as written on or in the magazine) and issue numbers are NOT a part of the magazine title, even though they are currently entered as if they were - that they are being entered as part of the title is because there was (is) no other way to record these data elements elsewhere (disregarding for a moment the discussion above to use Catalog ID). Note that the publication date field is not useable to record date as printed on the magazine - for one, because publication date '1980-01-00' is not the same as 'January-February 1980' as printed on the cover.
2. We all agree that having additional fields for vol, issue, whole no, date-as-printed (and others I may have forgotten) is desired, and that it would improve the data quality on magazines
3. The above fields would NOT be optional. If they are printed on or in the magazine, they have to be filled-in. If they are not printed on or in the magazine, they should not be filled in. The discussion whether or not to allow secondary sources to complete data missing from the magazine is another topic - but for the sake of argument assume that ONLY data as printed on or in the magazine is allowed. Allowing some form of formatting standardization to make it look more pretty in lists is also another discussion topic.
4. For disambiguation purposes, we want to display additional data-elements next to the magazine's title. After all, what is the value of hundreds of identical Locus title records in a list of grid? The current rules state that either date-as-printed, or issue no can be printed along the magazine title for disambiguation purposes and, granted, making it easier to identify individual issues in lists or grids
5. Listing a title in the title field with additional data-elements appended to it that are separated with a comma is fully equivalent to listing a magazine title with softwarematically concatenated values from the other fields (as listed above), and separated with a comma.
6. If we agree that the purpose of the additional data elements is to disambiguate magazine titles to make them easier to distinguish from each other when displayed in lists or grids, then we need to agree on

  • What data-elements we want to additionally record
  • Will these have to be recorded as printed on or in the magazine, or do we allow some level of standardization/formatting?
  • Which fields will be displayed along the title (separated by comma) in lists, grids, anywhere else where lists are available for the DB user to peruse?

If these three questions are answered, and as an interim solution until such time we have the additional data fields, we change the rules to allow to add these additional data elements to the title when available on or in the magazine, and enter it in the title field - my proposal would be: If available, enter in the title field 'Magazine title, issue no, date-as-printed' (wording should be refined and expanded, of course). MagicUnk 15:00, 14 April 2021 (EDT)

Some of the points above hit on something I had been thinking about last night. There are two separate cases here really: Monthly magazines and non-monthly ones. Determining the month for a monthly out from secondary sources is not a big risk (I still think we need to keep the issue number as well in the title but let's just talk dates in the title). For non-monthlies, even when they have semi-regular schedule, how do we decide if the date should be January 2021 or January-February 2021 for example if the magazine does not use a date at all? And if the next issue slips so instead of March, it comes out in April, do we revise the previous issue to make it January-March? Annie 16:11, 14 April 2021 (EDT)
This issue you're pointing at is only relevant if you want to add a date from secondary sources to the title, because then you'd have to have a translation to a standardized format defined. The problem doesn't pose itself if we stick to only recording what's on or in the magazine (Interzone for example has "January-February 2021" printed in full on its cover. Also note that I'm making a distinction between the date-as-printed vs. publication date (see also Ahasuerus' comment on stated vs actual publication date in the next discussion topic below). These are often containing the same data, and then the difference is trivial. However, these are by no means always identical. For one, the formatting of these two fields is different: "January-February 2021" vs. 2021-01-00. So, in your example, we wouldn't record anything in the date-as-printed, but we would record the issue publication date as 2021-01-00, and for your second example where the next issue slips to, say, 15th of April, we would have as publication date 2021-04-15 (and again nothing in the date-as-printed field - or if it would have March 2021 on it's cover, we would have "March 2021" issue published on date 2021-04-15. Hope this clarifies. MagicUnk 12:42, 15 April 2021 (EDT)
MagicUnk's comments touch on a point that I tried to make above (twice, I believe) but which has not been answered. The date portion of the title is not intended to reflect what is in the magazine, we standardize it. Given that we reflect misspellings exactly as they are published for books, that has to be a conscious decision. Further, the statement from help: " Also, please note that the title should be of the form Magazine Title, Date, such as Asimov's Science Fiction, June 2004. This helps differentiate different issues of the magazine." absolutely suggests that the purpose of the date is for disambiguation. Given MagicUnk's ultimate suggestion runs into the problem of what to do about the thousands of records entered under the old standard. Annie's solution to this has been to make the new standard completely optional. I don't like the idea of optional standards for reasons I've given above. A better solution would be to define what makes a magazine on that people want to refer to by issue number and date as opposes to date alone.--Ron ~ RtraceTalk 19:23, 14 April 2021 (EDT)
If we decide on a new standard ('title, issue no, date' for example), it would mean a huge cleanup exercise. I am definitely not advocating to have two standards, or make the new standard optional and just leave the old entries as-is. That would become a mess. To put it more strongly: my proposal would be to record as printed on or in the magazine, nothing's optional - ie if it's there, enter it as displayed, if its not, don't add anything.
Furthermore, I believe that using 'title, issue no, date' (as printed) would be sufficient for disambiguation purposes. If it's not, we can A. either add more data-elements (like vol, whole no, if available), or B. we can add data element values from secondary sources (eg date formatted in a standardized way) - but then again, we'd then need to clarify what to do in eg Annie's bimonthly example and we'd have to come up with a standardized way to add that additional data element for these examples too (date in this case) - can become complicated rather quickly, so I'd rather try to avoid that if we can (and stick to as printed), or C. a combination of A. & B.
Your statement that the date portion of the title is standardized, yes that is correct, but that shouldn't be an issue provided we can come up with a consistent way of doing it. That is, if we want, or need to, keep doing it, and perpetuating current practice of standardizing date format when used as title disambiguator. Standardizing the formatting, either in combination with data obtained from secondary sources (or not), could be desirable, but by no means necessary in my opinion.
Finally, to your last statement, we're full circle I believe, in that there is ambiguity in the current rules as to what sources are allowed for date-for-disambiguation-purposes. If I got it right, Ron, you are of the persuasion that we are adding dates for disambiguation purposes, and therefore secondary sources are allowed or even mandatory - and then yes, it could make sense to stick to that approach and only allow dates. Compare that to Annie's (And Doug H and Nihonjoe, and myself - see also discussion below) are of the conviction that we shouldn't use secondary sources to get data-element values (at least not in the case we're discussing - having publication dates and/or prices derived from secondary sources is still permissible in my book if clearly indicated in the notes as such, but that's another discussion) MagicUnk 12:42, 15 April 2021 (EDT)

So if I add an issue of Fangoria, how do I title it? The three issues currently on the DB are titled Fangoria, title no., date. Should I copy that?--Rosab618 20:07, 15 May 2021 (EDT)

Extending the "Content" field to collections and anthologies

Let's try this again. We had this discussion last year and since then the number of collections and anthologies which would have been omnibuses but for the length of what they contain had just increased.

So I propose to extend the usage of the "Content" field to collections and anthologies (now it is allowed only for omnibuses) - for the collections/anthologies which are de-facto omnibuses for their series - except that their series don't contain novels. Allowed would not mean mandatory - it will be used only when the collection/anthology contains only (or chiefly) works from the same series - for example (more examples in the old thread). Thoughts? Any reason NOT to? Annie 20:49, 13 April 2021 (EDT)

I think this would be a good idea. I can think of several anthology series where this might be helpful. ···日本穣 · 投稿 · Talk to Nihonjoe 21:17, 13 April 2021 (EDT)
My opinion is pretty much the same as it was in May 2020. As I said at the time:
  • 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 15:26, 17 April 2021 (EDT)

Removing the loophole allowing secondary sources to take precedence over primary sources

As it became apparent during the Magazine naming discussion, there are a set of rules (Missing or variant dates combined with the Magazine paragraph) that can be interpreted (by Rtrace) to allow data from secondary sources to take precedence to data coming from the magazine itself, namely - even if a magazine does not have a month printed anywhere, If a secondary source has the month, this month needs to become part of the title of the magazine.

For example that would mean that Apex Magazine, Issue 121 should be called "Apex Magazine, January 2021" despite the fact that January is not mentioned anywhere in the magazine (cover or any page) while "Issue 121" is there (both on the cover and inside of the magazine). Please note that this is about the naming of the magazine; using secondary sources for dating is an acknowledged practice. Using secondary source to create a title for the magazine sounds against the basic idea of the DB - we record the books, we change titles (outside of regularizing for case and spaces and so on) only if we need to somehow disambiguate (which we do not here as we have an issue Number to use based on the "If there is no apparent date, or the date is incomplete, a volume/issue number may be substituted." statement from the same rules). The statement "Information can also be drawn from bibliographic sources when useful" marks both titles as possible but I do not believe that it actually is meant to allow the secondary source to take precedence; just allowing it in case it needs to be used (no issue number on the magazine for example?).

Two question:

  • Does anyone else read these rules in the way Rtrace does? My reading had always been that this is only last resort (data from the magazine allowing the disambiguation should take precedence - so in this case the title is formed with the issue number and not the date)?
  • Does someone have a proposed language to change this thing to clarify the meaning based on the majority reading?

Thanks! Annie 22:47, 13 April 2021 (EDT)

I also would understand the rules in the way that we take precedence with the in-magazine stated ambiguation. Christian Stonecreek 05:16, 14 April 2021 (EDT)
It's fine if you want to get rid of that clause. But how is one supposed to intepret the context of "The date is preferable" with the statment "Information can also be drawn from bibliographic sources when useful, ". Are you recommending striking from the statement above to the end of the paragraph? I see that the example has been changed a decade ago by a now inactive editor to follow the French, or like Interzone standard. It's certainly not a French magazine, nor does it have an erratic publication schedule. I've never understood what makes a magazine like Interzone which itself doesn't follow the standard it is supposed to exemplify, or indeed, any existing standard for naming. Poor examples aside, if we decide that we may only use date if it appears in the magazine, it makes the statement about using secondary sourced completely incorrect. --Ron ~ RtraceTalk 07:12, 14 April 2021 (EDT)
It looks like the relevant part of Template:PublicationFields:Title is:
  • Information can also be drawn from bibliographic sources when useful, but this should always be noted in the "Note" field. For example, the first few issues of the British edition of Science Fiction Adventures are dated simply 1958, but per the Tuck encyclopedia these are in fact bimonthly, starting in March of that year. If you have access to such a bibliographic source you can use this data, but be sure to make it clear in the notes field what information was drawn from secondary sources.
Checking the Science Fiction Adventures magazine grid, I note that all issues (1-32) have the volume number and the whole issue number on the covers. Our records use the whole issue number in titles: Science Fiction Adventures, No. 1, Science Fiction Adventures, No. 21, etc. None of them incorporate months in their titles. (Curiously, the months are used in the Date field, but none of them mention Tuck as the source even though the Help text above says "this should always be noted in the "Note" field.")
Based on the above, it would appear that the Help sentence which starts with "Information can also be drawn from bibliographic sources when useful" was meant to refer to "information" in fields other than the Title field, e.g. the Date field. Ahasuerus 11:07, 14 April 2021 (EDT)
I could agree, except that this is all within the template for the title field. --Ron ~ RtraceTalk 11:22, 14 April 2021 (EDT)
Sorry, I may not have been clear. What I was trying to say was that the Science Fiction Adventures example used in the Help text quote above suggests that the intent was for the language to apply to the Date field (and possibly other fields), but it was -- presumably accidentally -- put in the template for the Title field. At least that's what it looks like based on the evidence. Ahasuerus 12:23, 14 April 2021 (EDT)
I'm afraid I still have to disagree. The sentence after the mention of secondary sources, "If you don't have access, and find yourself entering data for a magazine without clear date or numbering characteristics" specifically mentions numbering. Numbering would only be used in the title (or the notes). It seems that title is still what is being talked about. --Ron ~ RtraceTalk 19:29, 14 April 2021 (EDT)
I would not say that secondary sources take precedence. Rather, data not available on or in the magazine (but available from secondary sources) have been used to complete the title. In other words, since per the rules title, date format should be used, here it has been interpreted as: 'if date not available, but can be derived from secondary sources, then go ahead and add date to title'. It is only when date is incomplete or unavailable that per the rules the title, issue format should be used. This is not the case here, since date is available from secondary sources. For me, this is allowed by this part of the rules: 'Information can also be drawn from bibliographic sources when useful, but this should always be noted in the "Note" field.' I do not read this as 'you can use secondary sources for any field, except for the title, as long as you add notes'. Rather, I'm reading this as 'you can use secondary sources anywhere, as long as you add notes'.
Seems to me that if we don't want to add secondary-source data to the title, we should rephrase that part of the rules to make it more explicit.
As for the mixed-up title, issue, date format: I actually prefer this mixup format over title, date, or title, issue format if the date isn't available. should we make current practice official? MagicUnk 13:47, 14 April 2021 (EDT)
Bleh, I really need to read my backlog first before posting... ;) MagicUnk 13:56, 14 April 2021 (EDT)
Just to make sure we are on the same page: You support the reading of that section to mean that the rule is to enforce (not just allow but actually enforce) the addition of a date, which is not printed anywhere on the issue, to the title while the issue number printed on the magazine is discarded and sent to the notes? Or did you mean something else?
And yep - chime into the other discussion for the issue number inclusion. ;) Annie 14:06, 14 April 2021 (EDT)
Well, yes, and no... I would not enforce it. Rather, you can use secondary sources for the date. If you do, you can use it to construct the title, date. If you don't, use the title, issue format instead. At least, that's how I read Information can also be drawn from bibliographic sources when useful, but this should always be noted in the "Note" field.. And by the way, I'm not really very enthousiastic about this interpretation myself. I'd rather have the title, issue, date format - see my thoughts above... MagicUnk 15:14, 14 April 2021 (EDT)
That's where I and Ron disagreed. I read "can" as "if you want to, you can"; his reading is "because date is preferred, you must" (aka secondary always beats primary in that case). I am fine with "can" if an editor wants to do it, I am not ok with must (and as an editor I would not use a date for this case because I am in the "record what is in the book" camp). Thus trying to clarify the rule so that only one of those readings is valid. :) Annie 15:18, 14 April 2021 (EDT)
I may have missed that statement of Ron (or misunderstood what he tries to explain), but I definately don't want to overwrite data that is stated on or in the publication. If pub and secondary sources disagree, only state so in the notes, nowhere else. For me it is permissible to complete missing information (obtained from secondary sources) only if that same information cannot be derived from the pub itself. MagicUnk 15:25, 14 April 2021 (EDT)
I don't think the date should be included in the title unless it's actually on/in the magazine that way. The primary should take precedence over the secondary. ···日本穣 · 投稿 · Talk to Nihonjoe 14:12, 14 April 2021 (EDT)
I also disagree with any data derived outside the primary source being used to identify (e.g. title) a publication. It would mean that I would be unable to enter a magazine without a date unless I first researched (?all?) the secondary sources. In a similar way I am also against entered secondary source derived dates in the date field for any publication (not just magazines) - which is a completely separate problem/solution/approach but reflects some kind of principle behind my stand. ../Doug H 16:15, 14 April 2021 (EDT)
Some bibliographic standards have provisions to record both the stated publication date and the actual publication date. For example, the MARC21 standard uses brackets:
  • 260 ##$aLondon :$bSussex Tapes,$c1968 [i.e. 1971]
It's not a bad idea, but it would take a great deal of development work to implement. For now, we use the Note field to clarify what is stated in the publication and what we learned from secondary sources, additional research, etc. Ahasuerus 11:13, 15 April 2021 (EDT)
(after edit conflict) Welll, I don't think that it would be that hard to add both stated and actual publication dates if we have the rules clarified and have them as Enter the date as printed after the magazine title, separated with a comma. Enter the actual publication date in the publication date field. That would nicely solve that issue imo until such time we would have an additional stated publication date field (or date-as-printed field :). If we'd do it like this, we would be not allowed to substitute the date as printed with a value from a secondary source. As a consequence, to be able to disambiguate the title in all (most?) cases we'd have to add additional data-elements to the title field - hence, we're back to 'Enter "title-issue-date" as printed to be able to disambiguate (see also my ramblings in the previous discussion topic).
Also, now that I'm thinking about it. Date (or even issue no or any other data element) is not really necessary for title disambiguation - a simple sequence number would suffice (albeit not really meaningful to the average DB user, hence the proposal to use (additional) existing data elements to disambiguate) Regards, MagicUnk 13:00, 15 April 2021 (EDT)
Now that I am thinking about brackets and parentheses... We already use parentheses to add disambiguating information to titles, e.g. "(excerpt)", "Introduction (Frankenstein)", etc. Would it make sense to put the month of publication in parentheses if it's not stated in the magazine? Ahasuerus 12:47, 15 April 2021 (EDT)
Just as a clarification: so do you propose "Apex Magazine, Issue 121, (January 2021)" or "Apex Magazine, (January 2021)" for the Apex issue above? Annie 12:55, 15 April 2021 (EDT)
Using parenthesis is really no different from using a comma. We could but I don't see much added value. And I would not advocate conditionally adding parenthesis - it's either all parenthesis or no parenthesis. Only having parenthesis if the date is not stated in the magazine (and consequently use no parenthesis if the date is stated in the magazine) is going to be quite confusing. MagicUnk 13:00, 15 April 2021 (EDT)

Last, First

Help:Getting Started:Enter a Novel states 'Author names should get entered using the "First Last" format and not "Last, First."' However, this is not mentioned as one of special cases under Template:PublicationFields:Author. I've always been under the impression that we do normalize these as "First Last" even if the title page was to use "Last, First." This came up with recent submission where the submitter pointed out it wasn't in the directions linked from the entry form (turned out to be a mute point in that case, as title pages used "First Last"; it was only the ToC that used "Last, First"). I feel it should either be added to Author template if it is the agreed upon standard or removed from the Enter a Novel help if not. Thoughts? -- JLaTondre (talk) 20:37, 12 May 2021 (EDT)

Help:Getting Started:Enter a Novel is a very old Help page which hasn't had a substantive update since 2009. I think that what it's trying to say is that editors shouldn't reverse the order of the author names on the title page. Basically, if the title page says "Mary Shelley", don't enter it as "Shelley, Mary".
I suggest that we delete this sentence. Instead we could expand the first sentence, which currently says "enter the author of the book, also from the title page" to read "enter the author of the book exactly as it is given on the publication's title page" to match Help:Screen:NewPub. Ahasuerus 09:49, 13 May 2021 (EDT)
Sounds good to me. Your suggestion clarifies the text without changing any rules. I have gone ahead and made the change since it should be non-controversial. I included a link to Template:PublicationFields:Author since there are some normalization cases (initials, ranks, etc.). I also changed the Note field since it said "this field is usually left blank" which is not the case. I removed that and added a statement about providing secondary sources when not using the actual book to enter information. -- JLaTondre (talk) 08:39, 16 May 2021 (EDT)
Looks good, thanks! Ahasuerus 13:42, 17 May 2021 (EDT)

Reviews of magazines

I asked why I couldn't link a review of Fantasy Tales in Fear magazine to Fantasy Tales. Rtrace gave me this reply:

"The policy is in this template: 'Reviews of media products (films, TV shows, games, music and dramatized recordings), stage productions, magazines and fanzines (regardless of their genre), and books that are not eligible for inclusion in the database (graphic novels, nongenre novels by authors that are below the threshold, nonassociational nonfiction works), should not be entered into the "Reviews" section of the data entry form. A record should be created in the "Regular Titles" section typed as ESSAY.' I suspect that part of the reason is that magazine and fanzine title records are not for individual issues, but are instead for all issues published for a given year (with the same editor). Personally, I'd have no problem with linking reviews to the composite title record for periodicals, but we'd need to have a discussion about changing the policy first in the Rules and standards discussions page. The other review should also should have been entered as an essay by the existing standards."

So shall we discuss? How about linking reviews of magazines to the magazine year? --Rosab618 03:30, 14 May 2021 (EDT)

I think it would be good to be able to enter reviews for specific issues of a magazine or fanzine. These kinds of reviews are pretty rare, though, and usually are for fanzines rather than specific issues of a standard magazine. I don't think I've ever seen a review of a standard magazine issue, but I have seen multiple reviews of fanzine issues. ···日本穣 · 投稿 · Talk to Nihonjoe 16:12, 14 May 2021 (EDT)
The big problem here is the one that Rtrace alluded to: "magazine and fanzine title records are not for individual issues, but are instead for all issues published for a given year (with the same editor)". Linking a review of a single magazine issue to up to a year worth of issues would be misleading. Ahasuerus 23:04, 14 May 2021 (EDT)
Agree. I wouldn't link review of an individual issue to a year title. Make it an FR? MagicUnk 06:01, 15 May 2021 (EDT)
Well, it wouldn't necessarily require software changes. We could simply decide -- as a matter of policy -- that EDITOR records associated with different MAGAZINE/FANZINE issues shouldn't be merged. Once they have been unmerged, linking reviews to individual issues' EDITOR titles would be easy.
However, that would be a significant policy change with numerous implications. The most obvious one would be an increase in the number of entries on magazine editors' Summary pages. Consider Stanley Schmidt who edited Analog between 1978 and 2013. At the moment, his Summary page has 36 Analog links, one for each year. If we were to make this change, the number of links would jump to around 400. It was the main reason why we originally decided to merge EDITOR titles. Ahasuerus 21:00, 15 May 2021 (EDT)
That would also have an outsized effect on awards which also link to title records. Most awards and nominations for magazines are for a calendar year and this mostly works well with the current structure. The exception is for magazines with multiple different editors within a single year (e.g. tor.com). This necessitates having to repeat the award/nomination record for each distinct editor (e.g. Locus award after 2015). I'm not try to hijack the discussion to find a solution to awards, but just want to point out that this problem would multiply the number of award records that need to be created by quite a bit. The Hugos have two periodical categories with 6 nominees which is a minimum of 12 award records. Assuming monthly periodicals, this would bring the minimum up to 144 award records per year. The problem gets much worse if the long list data is entered, which it is for the Hugos and the Locus awards. For this reason, I would not favor unmerging the periodical title records. --Ron ~ RtraceTalk 22:26, 15 May 2021 (EDT)
The big downside of using ESSAY is the lack of linking. If the contents of an ISFDB-recorded publication includes a review of something for which there is also an ISFDB record, it is highly desirable to have a hyperlink, instead of just flat text. So my sense is we should allow/provide linking wherever both the reviewing and the reviewed works are present in the database, reserving the ESSAY treatment for the situations where we do not have a record for the reviewed work and do not want one created.
Most reviews, when you think about it, originate from a publication, not from a title (even though they're almost always reviewing the work). So a heavy-lifting approach could be to change review links to use publication records instead of title records, and then the title records could roll up the reviews in their summaries. --MartyD 08:28, 16 May 2021 (EDT)
I am not sure I understand how that would work. If a REVIEW reviews a novel which was simultaneously published on paper and as an e-book, which publication record should we link to? If a REVIEW reviews a work published in a collection/anthology/omnibus, wouldn't linking the review to the publication record connect it to all the titles in that publication? Ahasuerus 12:57, 16 May 2021 (EDT)
In the absence of a big change like that, and also considering that 'zine reviews are rare, I think we should just allow REVIEW and linking to whatever EDITOR record is most closely associated with the review. I.e., if the REVIEW is for a specific issue, then use the EDITOR record comprising that issue, regardless of whether it's issue-specific or an annualized conglomerate; and if the REVIEW is for the 'zine in general, then use the EDITOR record contemporaneous with the review or encompassing the beginning of the period covered by the review. No need to change anything, except policy/procedure. --MartyD 08:28, 16 May 2021 (EDT)
I agree that the current policy of entering reviews of magazines as ESSAYs is suboptimal, but I am not sure that linking a REVIEW of a single issue to (up to) a whole year worth of magazine issues is a better alternative since it would have the potential to mislead users. Ahasuerus 13:01, 16 May 2021 (EDT)
I don't really see how it would mislead. And it gives them one-click navigation instead of having to copy the text and (try to) search. --MartyD 08:34, 17 May 2021 (EDT)

Into vs into

Hello. Perhaps this is a small issue, but I’d like to ask about it. I see from the title capitalization rules that the word “Into” is to be capitalized in most titles. But a quick search of titles containing the word shows that a large minority of instances of “into” in fiction titles are currently lowercased. Should these instances of “into” be capitalized? Here are the first five lowercased examples from short fiction:

1. "Woman Struck by Car Turns into Nymphomaniac"

2. ... And into the Fire

3. A Demon from Hell Walks into a Speakeasy

4. A Robot Walks into a Bar

5. A Robot Walks into a Bar and Says...

Should “into” in these examples and others be capitalized according to our rules? If so, then I will submit corrections when I happen to spot them.

--Michael Main 11:49, 30 June 2021 (EDT)

Unless it's the first word in the title, it shouldn't be capitalized. ···日本穣 · 投稿 · Talk to Nihonjoe 13:59, 30 June 2021 (EDT)
Thanks for the comment, 日本穣 · 投稿. However, the rules in the template for an ISFDB title field state that for English titles all words (after the first) are capitalized except for "a", "an", "and", "at", "by", "for", "from", "in", "of", "on", "or", "the", "to", and "with". Perhaps this is outdated or an ongoing conversation among the moderators, but if so, that causes another problem since the majority of the occurrences of "Into" in a title are currently capitalized. --Michael Main
It's definitely been the subject of more than one debate. Even regular English style guides change their minds on such things somewhat regularly. ···日本穣 · 投稿 · Talk to Nihonjoe 14:30, 30 June 2021 (EDT)
In this case, stick to the rules and capitalize 'into'. At least until such time we get consensus to revise our rules - but until that time, 'Into' it has to be. MagicUnk 14:37, 30 June 2021 (EDT)
Thanks again. This answers my question of whether I should submit corrections (changing into to Into) so that indexed titles match our current style guide. (The current guide is clear that "into" should be capitalized.) Based on a quick survey, I would say that about 20% of titles break that guideline for "into." [My own opinion is that the style guide should not capitalize "into" in titles, but my stronger feeling is that when a style guide exists, it should be followed except for issues that are currently under review. I'd bet my favorite grammar book that valuing consistency over personal preference says something about my personality, but I'm not sure I want to know what it says.] --Michael Main
It looks like there may be two separate issues here. The first one is what the rules currently state. As MagicUnk pointed out, the rule as it exists now is to capitalize "Into" in English titles. The second issue is whether we may want to change our rules and add this preposition to the list of words that should not be capitalized. I suspect that that's what Nihonjoe was trying to say.
Ordinarily, ISFDB:Help desk is used to ask for clarification of existing data entry rules while this page, "Rules and standards discussions", is used to discuss proposed changes to the rules, but sometimes discussions cross over. Ahasuerus 15:22, 30 June 2021 (EDT)
Since thousands of titles have been entered on ISFDB with "into" or "Into" depending on the whim of the individual editor, an easier solution would be to enter future titles containing that word as it appears in whatever publication it comes from. The decision on how to enter it doesn't change the fact that when people search for a title on ISFDB it will appear whether they enter it with a capital letter or not. The same goes for all those other words in quotes above. The important thing is to spell titles, names, etc. properly when entering them so people can find them. --Username 17:14, 30 June 2021 (EDT)
So what happens when one edition has "Into" and another has "into"? How do you decide which ones becomes the capitalization of the title record? And then there is the little problem of adding based on secondary sources or based on title pages who show all letters with the same size. Add to that collections which look very ratty if half the titles are based on one standard and half on another... while the actual book may be using something different completely. That's why we have a house guide for capitalization. If you would like to propose to abolish the rules as we have them, feel free to start a proposal. I would oppose (based on what I explained here) but if you get enough support... Annie 19:45, 30 June 2021 (EDT)
As with many other debates about how best to do things here on ISFDB, this will probably not be resolved and peter out. I didn't really think my suggestion would be accepted, since I'm not a moderator, therefore my opinion means very little, but my point was that it's far more important to spell things properly than worry about capitalization. This is an online database, and like every other online database, it's not really reliable and no serious scholar would trust the info entered here, but would seek out physical copies of whatever publication they're researching. I've corrected hundreds, maybe thousands, of errors, some of which have gone unnoticed since 2006 when editors were allowed to start doing their own thing here. If someone looks for a title on ISFDB like Go INTO the Light, it doesn't matter if they type the second word starting with i or I, it still works, but if some editor enters that title in an edit as Go INOT the Light, the searcher won't find it. So editors should concern themselves far more with double-checking their edits for spelling and accuracy than worrying about whether certain words should be capitalized. --Username 22:31, 30 June 2021 (EDT)
Re: not a moderator - I've never found that a moderator suggestion is treated any better than an editor's. They are generally based on a deeper understanding of what is going on - historically, technically or in usage - but are just as often met with arguments of why it can't or shouldn't be done as any other suggestions. In this case, capitalization, the problem isn't finding the titles/publications but rather entering them - different capitalizations end up creating different database entries with no automatic linkage. So your search for Go INTO the Light could end up returning multiple entries Into, into, INTO or Into The. The solution to that was standardization of capitalization. It's not without its problems, but better than the alternative. The makeup of the 'standard' has been ongoing but seems to be reaching the point that tweaking it is more trouble than its worth. Once we get there we might be able to codify the rule and deal with exceptions more generically (flags / edit dialogue). But until then ISFDB relies on editors like us to keep the moderators on their toes. And rack up edit counts fixing things. ../Doug H 10:08, 1 July 2021 (EDT)

Thanks to all for the input on my question. The perspectives of Annie and Doug about the benefits of standardization were particularly helpful to me. As a follow-up, I'd like to note that I didn't intend to open up a can of wormholes. I just wondered whether I should submit title corrections when I notice an “into” that (according to the existing standard) should have been an “Into”. As an occasional contributors, I like standards: They make my task easier, in that I know what I'm submitting will be useful, and I hope they make the moderators’ tasks easier, too. But I didn’t want to be submitting trivial things if they were not wanted. Thanks! --Michael Main

Submit them :) There are a lot of things that need fixing in the DB and there is only that much time one can spend fixing them. So any help is welcome. "Into", "Onto", "But" and "If" are some of the more commonly lower-cased ones. The other direction also happens often enough... :) We even have a report to identify possibly wrong capitalization (moderators can ignore the ones that are actually not wrong). Plus these are easy to approve - no research needed.
One small request - when you do that, add into the moderator note either "capitalization fix" or "into -> Into" or something like that. This will make it easier for someone finding the update later to know what we did change and if the book is PV'd, it will tell the PV what the change is. While it is obvious on the submission and approval screens, once approved, the old value is lost. Annie 13:27, 1 July 2021 (EDT)
Thanks, Annie. I will submit them as I spot them, and I'll include the moderator note as you've explained! --Michael Main 20:34, 1 July 2021 (EDT)

Early releases from Baen and Patreon

(Copied from the Help Desk.)

A number of authors are providing early releases of their new publications to people who have signed up for a subscription on Patreon. There’s a lot of inconsistency in how the individual Patreon programs are setup.

Let me use Glynn Stewart’s Patreon offering as an example. For $5.00 per title, subscribers are able to download a Patreon Edition of an about-to-be-released title. Each of the titles is typically released two weeks prior to the general availability of the title and can no longer be downloaded once the publication is generally available. Each has a cover that is the same as the initial release cover with the words “Patreon Edition” added to it. The title page includes the term “Patreon Edition” on it. The edition also serves as a final editing check before full publication since each subscriber is encouraged to report any typos, etc. In many ways, these titles can be considered final eARCs.

Should these title variations be added to the database and if yes, would they be handled any differently than we handle variations of other titles? A unique publication date can be obtained by looking at the availability posting date on the Patreon page for that Author’s subscription. A unique cover image is available. Would I just go with that? Phil 11:46, 5 February 2021 (EST)

It really comes down to how different they are. We don't list eARCS separately and with ebooks, we tend to lump versions a bit more than with we for for paper books (versions and ebooks are a complicated matter). You may look at existing Patreon editions and notes to see what had been done. But as a whole, unless it has an extra story or artwork or something, I will leave it just on the notes level... Annie 11:58, 5 February 2021 (EST)
Then I'll plan on adding the info to the Title notes. Thanks! Phil 14:37, 5 February 2021 (EST)
Having the notes will allows us to move them out into proper editions if we decide to do that at some point so... yeah. As always with the DB - the better notes we have, the easier it is to implement a change if we need to so... document, document, document :) Wait to see if anyone else chimes in with another idea/solution but that is what I would do :) Annie 14:54, 5 February 2021 (EST)
I don't have any ideas or solutions, but when I saw this item, it reminded me that I read a while ago that Baen make some sort of very rough/early e-ARCs available to purchase, and that would seem to be a reasonable precedent, if there's ever been any discussion of how to handle them? A quick Google returns this page of examples, and this discussion about their content. ErsatzCulture 15:15, 5 February 2021 (EST)

(unindent)I am afraid I missed this discussion back in February. To answer ErsatzCulture's question above, yes, we have been aware of the "e-ARCs" that Baen has been selling since 2008 -- here is the relevant discussion. As was pointed out at the time, these are -- arguably -- not ARCs at all:

  • ... these "e-arcs" are actually being advertised and sold. The traditional ARC was only distributed to reviewers and buyers for bookstores and distributors, and indeed generally carried a large "NOT FOR SALE" notice. Fans only got these if they knew someone on the distribution list, or if someone on that list sold a copy in violation of agreement. But with Baen marketing these, arguably they aren't "really" ARCs at all, but separate editions. -DES Talk 12:33, 2 November 2008 (UTC)

"Patreon editions" are apparently similar in that they are only available for a limited time, have a different publication date and a separate price. I think they are more like "privately published" books, which were commonly sold to subscribers about a century ago, or more modern book club editions than traditional ARCs. I think they need separate publication records. I am going to copy-paste this discussion to the Rules and Standards page Ahasuerus 15:25, 11 July 2021 (EDT)

  • While the eARCs are being advertised and sold, they are still uncorrected proofs, just like any other ARC. As with regular ARCs, the amount of changes before the final publication can vary significantly, from just a few typos to a reworking of sections of the text. I don't think we should use the eARC "publication" date as the ebook publication date because of those changes. I think we should treat the eARCs the same as any other ARC, despite peoples' willingness to pay for them. ···日本穣 · 投稿 · Talk to Nihonjoe 11:55, 15 July 2021 (EDT)

Remove possibility to use L for £?

I stumbled upon this piece of text in the rules: ... but if you can't generate one on your keyboard you can use an L: "L2.50" means two pounds fifty pence... . I can't imagine that nowadays there's anyone out there that wouldn't be able to generate the £ sign. Besides, when doing an advanced search I got only one record back that I converted from L to £. Also, what about other symbols that are used in the DB such as ¥, ℳ, ₩, ƒ, ... for which we don't have an alphanumerical alternative either? So, if there are no objections, and for consistency's sake with other used currency symbols, I'll remove that sentence from the rules text within a couple of days. Regards, MagicUnk 12:02, 14 September 2021 (EDT)

Please leave it there. There are a lot of people using older computers and sometimes using weird keyboards - not to mention the people that are not really well acquainted with computers. Making the site harder for them to use won't help anyone. Annie 12:09, 14 September 2021 (EDT)
(after edit conflict) Doesn't make any sense. There is no-one that has any trouble finding or using the £ sign (and there's the alt-key combination as alternative too), people with computers that don't have it are all extinct by now :). Testimony is there was only one single record with an 'L'. And besides, ctrl-c, ctrl-v does the trick equally well. Also, if we'd keep that exception, then for consistency's sake we need to provide alternatives for all the other currency symbols we're using - which I am not supporting by the way :) MagicUnk 12:37, 14 September 2021 (EDT)
Really? I have issues finding it from my phone when I am tired - I can always get it from Wiki and copy (my usual way if it gets to that) but copying on small touchscreens is not fun and iOS keyboards are a different animal. As for having one only - maybe someone is fixing them when she remembers. ;) So nope - what you think as testimony is not really so. ;)
This is the only "English only" currency that requires non-lettered characters. Editors using the others are a lot more likely to have them neatly on their keyboards. US editors, especially older ones, working in English only can have UK books and still have no idea how to make the pound character. Just saying. Just because it is 2021 does not mean that people's understanding of how to work a computer is there yet. Annie 12:47, 14 September 2021 (EDT)
Wouldn't "GBP" be a preferable to "L" as a fallback for people with keyboard issues? And potentially having ISO-4217 codes as pure-ASCII for all (?) currencies for people who can't enter/don't know the relevant symbols? ErsatzCulture 12:33, 14 September 2021 (EDT)
That ISO code proposal has some merit. But I do recall there have been discussions around introducing that, but that propsal wasn't withheld - can't remember why that was. MagicUnk 12:37, 14 September 2021 (EDT)
So what's the problem with just leaving it as is until the day when this whole field gets restructured into a dropdown? Plus people are a LOT more likely to remember to use L than GBP:) Annie 12:47, 14 September 2021 (EDT)
I like having the prices consistently with £, but I'm sympathetic to the keyboard facility argument. That said, I could imagine a feature of the software, where a single-character L as currency symbol on the way in was converted to £ and presented that way thereafter. --MartyD 13:32, 14 September 2021 (EDT)
Keep in mind that currency codes and currency symbols are two different things. The currency code for the US dollar is "USD" while its currency symbol is "$". Ditto "GBP" vs. "£", "JPY" vs. "¥", "EUR" vs. "€", etc. FR 1158 "Allow multiple prices per publication" goes into the gory details, including the fact that "some currencies have had multiple ISO-4217 codes and some older ones have none."
Re: the immediate issue, I like Marty's idea. We could change the ISFDB code responsible for handling price values in submissions to auto-convert a leading "L" followed by a digit to a "£". Ahasuerus 13:38, 14 September 2021 (EDT)
I like the idea. Annie 14:20, 14 September 2021 (EDT)
Yup, that's a nice solution :) MagicUnk 06:47, 15 September 2021 (EDT)
OK then, FR 1434 has been created. Ahasuerus 16:00, 15 September 2021 (EDT)

(unindent) The change has been made. Template:PublicationFields:Price has been updated. Ahasuerus 14:05, 16 September 2021 (EDT)

Auto-converting Yen and Euro symbols

Can we do the same for the Yen? Now we allow Y4,800 or ¥4,800 - we may as well convert that as well... Annie 14:16, 16 September 2021 (EDT)

Sounds reasonable. Ahasuerus 14:28, 16 September 2021 (EDT)
@Annie: Some people are never satisfied! Couldn't you just revel in the magic of "we dream it, and it becomes so"? :-) @Ahasuerus: Sweet! --MartyD 14:40, 16 September 2021 (EDT)
Someone needs to keep Ahasuerus on his toes! :) I did not think of it until this morning or I would have mentioned it yesterday - he implemented too fast ;) Annie 15:25, 16 September 2021 (EDT)
Talking about making things easier for everyone, doing the same for €/E will save me some time as well. While I know how to make the euro symbol when needed, it will be a lot easier to be able to just put E and be done. Annie 15:27, 16 September 2021 (EDT)
Very well, FR 1436, "Auto-convert Euro and Yen prices", has been created. Ahasuerus 14:33, 18 September 2021 (EDT)
Done. Template:PublicationFields:Price has been updated. Ahasuerus 19:09, 23 September 2021 (EDT)

Japanese Prices

Do we have a way to check for 円, JPY, or JP¥ in the price field? All of those are used to indicate Japanese yen (though the first one usually appears at the right of the price rather than at the left). ···日本穣 · 投稿 · Talk to Nihonjoe 13:31, 24 September 2021 (EDT)

We have a cleanup report which looks for "Publications with Invalid Prices". Let me update it to include "円" and "JP". Ahasuerus 08:43, 25 September 2021 (EDT)
FR 1440 has been created. Ahasuerus 08:46, 25 September 2021 (EDT)
Done. There are two affected publication records. They will appear on the cleanup report tomorrow morning. Ahasuerus 16:10, 25 September 2021 (EDT)

Additionally, the same symbol (¥), as well as 元, are used for renminbi in mainland China (as well as in Taiwain until around 2000). ···日本穣 · 投稿 · Talk to Nihonjoe 13:31, 24 September 2021 (EDT)

I am not sure if there is anything that we could do programmatically to prevent the use of ¥ for Chinese prices. Re: 元 , Advanced Publication Search suggests that we use it inconsistently -- sometimes we enter it to the left of the price value and sometimes to the right. We may want to standardize its placement and update Help. Ahasuerus 08:43, 25 September 2021 (EDT)
That's true for a lot of currencies though - we should be catching these when approving but a lot manage to somehow get into the DB... and there are a lot more weird ones already in the DB.
I am waiting to see when Ahasuerus will get tired of us all and will decide to simply convert the field into a drop down/text field combo... Annie 13:43, 24 September 2021 (EDT)
Rest assured that I would have implemented FR 1158 a long time ago if it wasn't such a beast :) Ahasuerus 16:41, 24 September 2021 (EDT)

Prices That Start with a Digit

Technically under our rules anything starting with a number is invalid. So we may want to add these into the report and start clearing them. Annie 18:14, 25 September 2021 (EDT)

<pokes the code> Actually, it's already checking for N[N...].NN prices. However, it's ignoring N[N...] and N[N...],NN prices. Let me update it real quick...
Done! The report will find another 17 pubs when it runs in the morning. Ahasuerus 20:14, 25 September 2021 (EDT)
Not Just purely numerical. Anything starting with a number - our rules require currency symbol first even if the currency usually uses different order (most do not work like the $ actually). But that’s a good first step. Annie 20:56, 25 September 2021 (EDT)
What about older UK prices like 3/6, though? Ahasuerus 21:37, 25 September 2021 (EDT)
Ah, yes. I forgot these. They always have /, right? We can use that to filter them out. Unless I am missing another special case, that should be enough to leave out the legitimate values. Annie 21:41, 25 September 2021 (EDT)
I stumbled across this 1969 Gollancz pub a while ago that has "25-". I've no idea if that's a legit pre-decimalization form - looking at their other pubs from that year, it looks like "25/-" might be a more correct/normalized form? ErsatzCulture 07:40, 26 September 2021 (EDT)
EDIT: There's also stuff like "2d", which could maybe be normalized as "-/2"? Definitely don't take my word on that though... ErsatzCulture 07:49, 26 September 2021 (EDT)
Template:PublicationFields:Price says:
  • We always record the pence in ISFDB even if 0 (indicated by "-"), and use the "/" separator, e.g. 3/6 is used to mean three shillings and sixpence even if the book says 3s6 or 3'6; a price of three shillings exactly would be 3/- even if indicated on the book as 3s, 3" or 3' or even plain "Three shillings".
Ahasuerus 10:23, 26 September 2021 (EDT)
Yep. That’s the one I meant. It either starts with a currency or if has / (and the two are mutually exclusive). Annie 11:04, 26 September 2021 (EDT)
OK, I have edited Template:PublicationFields:Price for clarity. Let me tweak the cleanup report to see what it will find. Ahasuerus 11:54, 26 September 2021 (EDT)
The cleanup report has been updated to include price values that start with a digit and do NOT:
  • include a slash (old UK prices)
  • end with "Lit"
The reason price values ending with "Lit" were excluded is that we have approximately 4,000 prices formatted that way. I plan to convert them programmatically.
The new data will become available tomorrow morning. I expect the report to find around 770 problem prices. Ahasuerus 12:31, 26 September 2021 (EDT)
All price values with a trailing "Lit" have been converted. Other variations like a trailing "Lit." [note the period] will appear on the cleanup report tomorrow morning. Ahasuerus 19:38, 26 September 2021 (EDT)
The cleanup report has been further enhanced to catch prices without a proper decimal separator. I am going to make a brief announcement on the Community Portal. Ahasuerus 21:51, 26 September 2021 (EDT)

Auto-converting Thai baht, Philippine peso and Indian/Pakistani rupee symbols

Three more suggestions, for currencies I frequently use: ฿ / B (Thai baht), ₱ / P (Philippine pesos), Rs / ₹ (Indian/Pakistani rupees, NOT for South African rand which usually appears as just R.) PeteYoung 01:03, 24 September 2021 (EDT)

I can easily make the same change for ฿/B and ₱/P, but Help:List of currency symbols says that "₹" is to be used for "Rupees (India)" while "₨" is to be used for "Rupees (Pakistan)". Wikipedia has more details about their history. Ahasuerus 10:20, 26 September 2021 (EDT)
"B" and "P" have been added to the list of automatically converted characters; Template:PublicationFields:Price has been updated. Ahasuerus 13:08, 27 September 2021 (EDT)
Thank you, O Wise One! PeteYoung 21:00, 27 September 2021 (EDT)

How to update a publication

In the template How to update a publication, there is a reference to the "Bibliographic Comments" that seems to be obsolete. There is a page for it with a few references that should also be addressed. ../Doug H 19:51, 25 September 2021 (EDT)

Help:How to update a publication has been updated - thanks!
Bibliographic comments is a bigger can of worms which needs more research. It's linked to by other Wiki pages like Publication Series, which also need to be reviewed and either updated or deleted. Ahasuerus 14:21, 26 September 2021 (EDT)
Obsolete Wiki pages Bibliographic comments and Publication Series have been deleted. All relevant data is now in the database. Ahasuerus 14:40, 26 September 2021 (EDT)

Template:PublicationFields:Price - USA and Canada

The Template:PublicationFields:Price makes reference in the first line to books published in both the USA and Canada and states "only the USA price should be entered in this field". There is no distinction made between 'publish' and 'print'. 'Publish' is an action whereby books are released to a market which can be difficult to determine of USA / Canada, because at times their currencies have been close enough to retain a single price, and because sometimes the Canadian release uses stickers to allow easier price changes due to rapid or ongoing currency valuations. 'Printing', however, is generally stated on the copyright page. There are books which differ only in the location of printing, with the same cover, price (or prices), title and content. And the method used to easily differentiate the two Publications has been to use the Canadian price for the Canadian printings. Is this practice incorrect or should the template be tweaked to make this practice clearer? ../Doug H 12:46, 26 September 2021 (EDT)

I've always wondered myself if there really -is- a way to distinguish publications printed in the USA, vs. printed in Canada - is it a fact that books sold and printed in Canada are indistinguishable from their USA nephews when looking at the book? If so, then we may have to question the validity of entering both the US & Canada printings - for example, are there cases where books sold in Canada are import (ie printed in the US)? If that's the case, we can't enter a Canada printing for that one, but how do we know?... MagicUnk 13:44, 26 September 2021 (EDT)
Thanks to one of our own descriptions of what IS a Canadian - not an American - we are generally pretty good about distinguishing ourselves. Hence most books that are printed in Canada actually say they are printed in Canada. Even when it's a Canadian publisher. There's more likely an ISFDB problem with the reverse - books printed in Canada that are not identified as such because Americans have entered them without noticing. ../Doug H 13:49, 26 September 2021 (EDT)
It looks like there are at least three separate issues here:
  • There can certainly be a difference between "printed in", "published in" and "distributed in". For example, a London-based publisher may put together a book, have a Finnish printer print 10,000 copies, then distribute them in the UK, Ireland, Malta, Gibraltar, Australia and New Zealand with a list of country-specific prices printed on the back cover.
  • Our Help pages occasionally mention this distinction, but I don't think we have a single Help page where the differences are explained. For example, Gutter code emphasizes the difference between "manufacturing date" and "publication date", but it does it in a very specific context. We may want to create a separate Help page covering this topic, then update Template:PublicationFields:Price, Gutter code and other Help pages to link to the new page.
  • Re: the specific issue raised above, I believe we have repeatedly discussed differences between US and Canadian versions of the same book in the past, including various complications. I don't recall all the details, but I think it was fairly involved. It may be best to touch base with editors who specialize in this area.
Ahasuerus 14:00, 17 October 2021 (EDT)

Consolidating lists of currency symbols and abbreviations

I notice that Help:List of currency symbols has been created as part of this discussion, but was never completed nor actually put in official use. MagicUnk 14:31, 27 September 2021 (EDT)

Help:List of currency symbols is linked from Help:Contents. It was added on 2019-08-23, so it's been a part of Help for more than 2 years now. Ahasuerus 15:42, 27 September 2021 (EDT)
Ooops, totally missed that. Apologies... MagicUnk 06:00, 28 September 2021 (EDT)

Now, since there's a big overlap with the bulleted list from Template:PublicationFields:Price, wouldn't it be an idea to update Help:List of currency symbols, include the info from the bulleted list from the former price template, and replace the bulleted list with reference to the latter help text instead? (or make it a template in its own right). What do you think? MagicUnk 14:31, 27 September 2021 (EDT)

I noticed this issue while working on other price requests last week. I think that it would be best to combine the two lists as a single Help Template, organize them as a table and link to the template from the relevant Help pages. The section that deals with British prices could be either made into a separate template or turned into a section within the new template. Ahasuerus 15:42, 27 September 2021 (EDT)
I like the idea. We also need to add a few more missing currencies we see often enough but never added - Din (the Serbian/Yugoslavian/Croatian (before the devaluation and name change of their currency so pubs between 23 December 1991 and 30 May 1994) Dinar), Lev (the Bulgarian Lev), Rub (the Russian Ruble), zł (the Polish złoty) and possibly a few more from the region. Plus the Brazilian real (R$). And we may want to do some automation on capitalization (as we do not have a rule on what is capitalized, each currency has its own rules at the moment and we may want to ensure that at least inside of a language, we are consistent). Annie 16:24, 27 September 2021 (EDT)
Sounds like a plan if you ask me :) As to the additional British stuff, might be easiest to leave that part where it currently is, for now. MagicUnk 06:00, 28 September 2021 (EDT)
If you're mucking with the Template:PublicationFields:Price, can you address the previous post? ../Doug H 08:26, 28 September 2021 (EDT)

(unindent) Template:PublicationFields:Price and Help:List of currency symbols have been updated. I'll take a look at the issues mentioned by Doug H tomorrow morning. Ahasuerus 17:58, 16 October 2021 (EDT)

Multiple price values in price field

(This sort of related to the item a couple of positions up, but isn't quite the same thing, so I've added this as a new item.)

I stumbled across this recent pub, which has a price value of "$24.95 / CA $33.95 / £17.99", which seems inconsistent with Template:PublicationFields:Price, which states "Enter a single price, e.g. for books published in both the USA and Canada, only the USA price should be entered in this field. Instead, additional prices can (and usually should) be entered in the Notes field. This is done because the value in this field is used to differentiate between print editions, search the ISFDB data or construct statistics on book pricing, which would be difficult to do if multiple prices were present in the same field.".

Edit history shows pub has actually had a number of changes: it started off with just a US price, but I subsequently changed it to a UK price, to reflect the fact that this international pub had an earlier UK date than US, relegating the US price to the note field per the rule above. I'm not too bothered about this aspect of my edit being changed [*], but I'd like some clarification about what the standard is supposed to be?

NB: "The CA $33.95" seems to be non-standard, but I'm guessing it's not being reported in the invalid price report because either a mod had marked it as OK and/or the space between "CA" and "$" means the validation regexes think it's a US price? ErsatzCulture 12:35, 5 October 2021 (EDT)

This cleanup report doesn't support the ability to "ignore" records. The reason that this price wasn't flagged was that the report only checks for "CDN" prices and ignores "Can" and "CA" prices. Since we don't have a list of supported currency symbols and abbreviations (yet), the software has no way of telling that "CA" is not some obscure but valid currency which uses "$". After all, we explicitly support "Mx$", "A$" and "Ar$", and other dollar currencies like "FJ$" and "Sr$" are valid.
One thing that we could do is upgrade the cleanup report to look for prices with a space followed by the dollar sign. Ahasuerus 13:30, 5 October 2021 (EDT)
Or look for more than one space or a space after the first number - there is only one place where a (single) space can go and it is before the first number on a non-symbol based currency. Annie 14:49, 5 October 2021 (EDT)
Good points. FR 1448, "Enhance identification of invalid prices", has been created. There may be some odd borderline cases that we are not thinking of at the moment, but we can always tweak the software once we clean up the bulk of the problematic data. Ahasuerus 17:21, 5 October 2021 (EDT)
Done. Ahasuerus 17:47, 5 October 2021 (EDT)

[* I am a bit annoyed that the pub date is now showing as the generic date "2021-09-00", and the text I'd entered into the note about the differences in UK and US date has been lost - this seems a regression, albeit an arguably minor one?] ErsatzCulture 12:35, 5 October 2021 (EDT)

I cleaned the price field and apparently never submitted on that one while clearing a boatload of other issues - it is one price in the field only - the rest go into the notes. Fixed now.
As for the date - discuss with the PV. I prefer to date when I have exact date from secondary sources. Some PVs prefer not to. Both usages are valid. The rest of the comments - I would keep them if I am PVing but again - up to the PV to some extent on some of the data. There is just that many wars I can deal with... :) Annie 13:01, 5 October 2021 (EDT)
It is not the publication date that determines 'primary' currency, but the country the book is printed in - Titan Books is a UK publisher (so printed in the UK I'd think), so the price should be in £, and not in $. This may require explicitation in the rules, though ;) MagicUnk 13:49, 5 October 2021 (EDT)
Not always. If the US price is written first inside/on the book, I would use the US price even if the books is printed in Tajikistan or UK. Published and printed are different things and with multi-country publishers, it is even more complicated... Annie 14:05, 5 October 2021 (EDT)
Hmmm, you're right - Solaris is printed in Denmark, and has UK prices... seems like I was a bit too hasty :) MagicUnk 14:16, 5 October 2021 (EDT)
Printing is an interesting thing lately. A lot of the old printers folded (no money, no ability to get paper and so on) or got bought by international conglomerates. So we will see that A LOT more from the non-POD publishers - China and Eastern Europe seem to be coming up as the printing heavens just now (when it is not Denmark - really? Denmark?). So we will see a lot more drift between where a book is published, where it is sold and where it is printed. Welcome to the the modern era I guess. Annie 14:26, 5 October 2021 (EDT)
I was actually going to mention Solaris, as they're a funny one. Last year this pub came out in April in the US, but the UK release (with the same ISBN) was delayed until September. Whilst Solaris is based in the UK, personally I'd have thought recording the first (i.e. US) pub date would be more useful? (I'd intended to update the pub note accordingly as-and-when it officially showed up in the UK, but had forgotten about it until this thread reminded me - will get onto it in a second...) ErsatzCulture 14:33, 5 October 2021 (EDT)
I'd use the first available date worldwide for the edition, yes and everything else goes into the notes. Because of these... practices of Solaris, we used to actually record the US and UK editions separately so we have both dates... As it is literally the same book (not just the same ISBN but the same book completely), it is an overkill IMO but it is one way to solve the mess. Annie 14:40, 5 October 2021 (EDT)

Art on interior of dust jackets

Our current guidelines (see here and here) do not state what to do in the rare case of art on the inside of the dust jacket (brought to light because of this publication). In this discussion, everyone seems to be in agreement that it should be counted as interior art. In order to make the changes, we need to discuss it here. There are two things to consider:

  1. Should it be considered cover art or interior art?
  2. If it's considered interior art, what "page number" should we use? In the above-mentioned discussion, I suggested "ji" for "jacket interior", but I'm open to other suggestions.

Thanks, and let the discussion begin! ···日本穣 · 投稿 · Talk to Nihonjoe 17:01, 11 October 2021 (EDT)

When there is separate art (i.e. non-wraparound) on the back cover, we enter it as interior art with a page number of "bc" (with the exception of dos-à-dos which don't have a front and back). I'm pretty sure we had a discussion regarding this based on Armchair Fiction pseudo-dos-à-dos books (like this one), but I can never find a discussion when I want to. So keeping with that, it should be entered as interior art. The use of "ji" seems reasonable. -- JLaTondre (talk) 19:47, 11 October 2021 (EDT)
If you need to open the book or turn it around to see it, it is not a coverart IMO (unless it is a cover under a dj... bt that is not the same as opening the book...). "ji" sounds reasonable but we have two of those things (front and back) so maybe "fj" and "bj"? Or keep it ji and just add notes on where it is. Although that opens another question - those paperbacks where the internal flap is attached to the cover and there is no jacket. So maybe use "f" for flap and not "j" for jacket (so fi or ff/bf)? Annie 20:11, 11 October 2021 (EDT)
"flap" is handy, since it encompasses both "jacket" and "interior". Adding "interior" to that would be redundant, so I like "ff" and "bf". That would also have good consistency with fc/bc and fep/bep. --MartyD 10:51, 12 October 2021 (EDT)
The only problem I see is that (in this case) we're talking about the interior of the dust jacket, not the front or back flaps. I think art on the dust jacket flaps (front or back) is also rare. In all the instances I've seen, if there is art on the inside of the dust jacket (again, not on the flaps, but the interior surface of the dust jacket, the part that's usually blank and can't be seen unless you take off the dust jacket), the art covers the entire interior surface of the dust jacket. ···日本穣 · 投稿 · Talk to Nihonjoe 12:41, 12 October 2021 (EDT)
My bad - apparently my brain went elsewhere. Then we have ij as well. :) Annie 15:40, 12 October 2021 (EDT)
I agree that it is best treated as INTERIORART; no preference otherwise. Ahasuerus 18:57, 13 October 2021 (EDT)
Sorry, I failed to comprehend that the art is on the reverse side of the jacket.... I think our current abbreviations consistently use <relative-to-the-pub location> + <physical location>. bc = Back (of the book) Cover, fep = Front (of the book) End Paper, etc. So my simple mind would like to see that pattern followed for what we choose here. Also, while having fallen prey to it admittedly makes me biased, I think the mild confusion above suggests "interior" or "inside" is ambiguous, and we may want to come up with something else if we can. We might also want to add "ff" and "bf" while we're at it, even though they are not needed for this specific instance. --MartyD 12:33, 14 October 2021 (EDT)
My mind blinked the same way for a second (for which I apologize)- you say internal, I think flaps not the reverse side of the cover (even if I knew this is not the case here). That gives me an idea "rj" as in "reverse jacket"? That at least is not ambiguous. Annie 12:50, 14 October 2021 (EDT)
I think "rj" would work fine. ···日本穣 · 投稿 · Talk to Nihonjoe 12:14, 18 October 2021 (EDT)

Help:Screen:NewPub Publisher

(post moved from here)

Not an attempt to hijack the thread. Perhaps it's time to do something about "The publisher has in the past not been a key entity in the ISFDB, but publisher and imprint support is in the process of being improved, and a process of determining canonical names for publishers and imprints is in progress.". Just a thought. John Scifibones 17:12, 22 October 2021 (EDT)

Pot over in CS please together with what you are proposing for us to do (fix the help page? something else?) :) Annie 17:22, 22 October 2021 (EDT)


Proposed changes to Help:Screen:NewPub Publisher

  1. Remove "The publisher has in the past not been a key entity in the ISFDB, but publisher and imprint support is in the process of being improved, and a process of determining canonical names for publishers and imprints is in progress. For the time being" so the next sentence starts "You are free...."
  2. Replace "Where multiple forms of a name exist, it is not important to always enter exactly the form of the name as it appears on the book. For example, an imprint may say "A Tor Book", "Tor", "Tor Books", "Tor Books Science Fiction", or "Tor: A Tom Doherty Associates Book". Sometimes several of these varying forms will be on a single book. These can be converted to a canonical form; in this case "Tor" would be the sensible choice. The ISFDB does not currently have a page to identify and document canonical forms for publishers but may do so in the future." with "Enter the name exactly as it appears in the book, until such time as a system of canonical publisher names is implemented."

The above changes would eliminate disagreements as to the correct publisher attribution. Personally, I would rather see established canonical publisher names. Either way removes opinion from the process. Flame suit on. John Scifibones 18:35, 22 October 2021 (EDT)

I agree on the first but I strongly disagree with "Enter the name exactly as it appears in the book, until such time as a system of canonical publisher names is implemented.". We had always standardized publishers to some extent - we do not have the ability to variant publishers like we can with authors and titles - which means that recording "as is" will cause three issues:
  • 699,674 publications (as o a few hours ago when the report was ran) which may be now out of sync with the rules. We need a plan on how we will be bringing them up to a fixed state (slapping "the publisher of this book may be out of sync with the rules" is a bad idea visually but so is just leaving them as is with no cleanup plan for them).
  • The publisher records will splinter - some publishers come up with all kinds of weirdness through their years of work. Until we can somehow variant/show the books on the same page, splintering a publisher such as Barkley in 20 different pages serves no purpose and will just reduce the ability to use our DB.
  • We MUST differentiate sometimes - The UK Orbit is not the same as the US Orbit or the French Orbit despite the same name. And the more international publishers we get, that will get even more problematic. So even if we want to, we have cases where we should record differently from what we see.
As much as I hate not using what is in a book, we are not dealing with clean slate and we need to consider how we will bring the old entries to conform to the new rules. Otherwise we are making an even bigger mess of the DB (and we are DB first and a site second).
  • One idea may be to make the Publisher a double field: One field for the "cannonical/consolidated name" and one for the "as written in the book" and build a system which connect them on the Publisher pages. Make that double field repeatable and you now have coverage for co-published books which now are entered every which way (another improvement in our Publisher handling that we sorely need). That will still require cleanup but it will be obvious which ones are old records (second field empty) and which ones are new. Or something along these lines. Annie 05:43, 23 October 2021 (EDT)
Just in case the long explanation above does not make that clear: I do not oppose the spirit of the change and I do want to get to a place where we can make that change. But we also need to face reality and it will probably require multiple steps to get us there. Annie 07:00, 23 October 2021 (EDT)
If I created the impression that this was a simple change, I apologize. I envision a multi step process
  1. Agreement that this is something worth doing and reaching a consensus on the final result (probably the most difficult step)
  2. Creating the code changes necessary for implementation. The ISFDB community appears to have quite a number of people capable of helping .
  3. Creating the canonical list and the associated variants. This can be going on simultaneously with step 2.
  4. Using change query's to convert the data. While inherently dangerous, a reasonable way to deal with the volume involved.
Annie, I like the multi-field approach. Entry of the canonical name in field one would build an editable drop down list of associated variants in field two, on the fly. If the editor enters a new variant, this will be yellow flagged for moderator attention. John Scifibones 10:58, 24 October 2021 (EDT)
I suggest that you'll not get agreement on #1 until you've got a pretty good handle on #3 to support the general and specific general cases and numbers. Poll for interested parties to form a project and identify the issues, the relative occurrence of them and what should be done about them. If a small group (2-5 people) can reach consensus while considering the nitty-gritty, there's a good chance the general population will agree. ../Doug H 12:38, 24 October 2021 (EDT)
And that’s why I proposed to post in CS and not in R&S because it is not as simple as changing the Rules - technically the rules already allow what you want. We need a plan on how to get things done. You proposed a change in the rules - just that - literally just change the text of the rules. We do those changes often and that’s the format to do it. So yes - you did sound as if you want just to change the help text and thus change how we do things starting tomorrow. Which as I mentioned is not trivial. :)
There May be a lot of developers around but people willing to help are thin on the ground. So I would not hold my breath for someone stepping up. Hopefully someone surprises me.
Point 4 can only get planned when the software is changed and a lot of it will be manual no matter what we decide - sometimes the decision on what to select will be based on the notes, not simply the field. Humans tend to write things everywhere and especially for PVd books, we want to be extra careful or we will invalidate the PV program quickly. :) The canonical list creation may be a bit harder than you envision - we have a LOT of publishers (plus a lot of self published where author=publisher). One approach is to start with the top 1000 publisher and see where it leads but even that is not trivial. The site had already been creating defacto canonical names for the smaller publishers - we keep it simple there and moderators when paying attention enforce the usage of the same name (and when they miss it, someone fixes later based on the similar names report or when they stumble on it). It is the imprints that move around and the big guys where things are splintered. The Baen case is one of the weird ones because we do have a separation but it had been almost ignored so the whole set of them there is all over the place. On the other hand look at the Penguins - a lot of publisher forms but we keep on top of the separation. Mostly. That opens a different kettle of fish - do we want all Penguins regardless of country connected or keep them per country (the Orbits are different companies altogether between US and UK; the Penguins are a multi-national with regionals. Publishers are a kettle of fish. And we may very well need to discuss the big ones one by one. :)
Welcome to the “we all know we can do better but getting to a point where we can may take years” games. :) Annie 15:51, 24 October 2021 (EDT)
If you think it should be moved, I have no problem. I thought this is where you meant. To me, Community portal would be CP. John Scifibones 16:51, 24 October 2021 (EDT)
It’s fine here for now - we need other discussions started to break this up and make progress slowly - now that we all seem to agree that the help page text is the least of the issues and fixing that won’t fix the problem. :) And you are right - I keep thinking Community Support and Not Community Portal. Posting at night does that. :) Annie 17:01, 24 October 2021 (EDT)

Currency

Change of the rule: I propose that a space is generally placed between the abbreviation/symbol and the numerical value. Without exceptions. This avoids wrong entries or minimized. --Wolfram.winkler 10:21, 9 November 2021 (EST)

The majority of the books added to the DB these days have their prices in either $ or € or £ (with the $ being probably the most often used one). Starting to require the space for these will add a lot of moderation time to the process without gaining us anything IMO - older editors will need to get used to the change, new ones will need to learn yet another weird one. So I do not think this is feasible at this time - instead of minimizing the wrong entries, it will increase them - tremendously. At the moment there is a single currency where we seem to have an issue (F); everything else is very clear cut. Chances of someone non-French using F is not very high (it is an old currency) but we can do some special handling around that I guess. Changing the rules so we can deal with that one case sounds a bit like an overkill.
Going the other direction (never having a space) just looks weird: Lit20,000 instead of Lit 20,000 or Lev11 instead of Lev 11 look like typos, not like a properly selected format. Just my 2 cents. :) Annie 12:17, 9 November 2021 (EST)
It would be interesting to know how many records need to be changed. Are there no routines that can correct this automatically? We can call a space challenge, every user is called to search for missing spaces and eliminate them (Careful, not meant seriously).
There is certainly a lot of work involved, but if you want to bring your database up to a plausible level, you have to show a lot of motivation and it is not easy. Simply to say everything is fine is not the right way, I think. And the logic of spaces in abbrevations and no space in symbols doesn't seem very logical to me. But this is only my opinion.--Wolfram.winkler 17:18, 9 November 2021 (EST)
The problem is not the old records - those we can easily take care of if we change the rules. The problem are the new ones that will keep being added and will need correction at moderation time (and require either a DB change or clearing up via the cleanup reports later on). Such changes may seem small but multiplied by the number of books being added, they tend to become big problems.
We have a standard and it is being followed - mostly - and seems to work. We are working on the ones that somehow managed to go around the standard so these will also be cleared soon. You are proposing a new standard. If you gain support, sure. But "I do not like it" or "I do not think it is logical" is not a good reason to change a standard when there are drawbacks to doing it (I think it is very logical actually based on how human minds perceive symbols - you obviously disagree - people are different). What are we going to gain by changing the way the site works and making "$ 7.99" the default format? If you can explain that, maybe you can gain support. Annie 18:16, 9 November 2021 (EST)
In English, there is never a space between the dollar/pound sign and the number that follows it, which is presumably why the standard was written the way it was. The English Wikipedia uses a similar rule with a caveat:
  • Currency abbreviations preceding a numeric value are unspaced if they consist of a nonalphabetic symbol alone (£123 or €123), or end with a nonalphabetic symbol (R$123); but spaced (using Template:Nbsp) if completely alphabetic (R 123 or JD 123).
Also, please note that we had a fairly extensive discussion about prices in June 2018. It resulted in FR 1158, "Allow multiple prices per publication". The FR covers this and a number of other issues in considerable detail. Ahasuerus 18:40, 9 November 2021 (EST)
FWIW, a very crude and possibly buggy query of the database shows there are roughly 425k $ prices, 92k £ prices and 28k € prices, none of which currently have a space after the symbol. (DM is the fourth most commonly used currency, with 27k entries. The aforementioned $ figure excludes the likes of C$ (6k entries), A$ (3.9k entries), etc).
I can only speak for £ (post decimalization) prices, but a format like "£ 9.99" looks super-weird to my eyes, and I don't ever recall seeing that form in use anywhere in the real world. Certainly none of the dozen or so websites I scrape for my UK submissions puts a space between the £ sign and the numeric digits. ErsatzCulture 18:54, 9 November 2021 (EST)

(moved from the Moderator Noticeboard) Unicode has a category called "Currency" that corresponds pretty closely to our choice of what to space and what not to. It doesn't have the German Mark ℳ (in the letter-like symbol category) , and uses ₣ for the French franc. External standards can be good. ../Doug H 14:16, 9 November 2021 (EST)

I suspect that ours was supposed to be ₣ but it was the infancy days of the project so it became F (and that's why it has no space to start with). I will see if I can find the old discussion (if it ever got to that much details). ℳ was added much later - to differentiate the different currencies when Germany was split (thus making it easier to trace which book is which and what's not and which are actually the older books from pre-1914) and the German editors had a preference to using the symbol (I was here for the deutsche mark discussion; the franc one predates me). But yes - standards are good. I would not want to drop the ℳ though but if that is what it takes to get us to standard, we can always discuss. Annie 15:27, 9 November 2021 (EST)
re ℳ: that's why I included the Unicode category, it doesn't say currency, but does say symbol. And while F is not a symbol, it does stand in for one. ../Doug H 17:04, 9 November 2021 (EST)
The symbol "₣" was something that Édouard Balladur, then French finance minister, proposed in 1988. However, it never became popular -- see Enfance : dessins, objets, histoire : littérature jeunesse, outils pédagogiques, illustrations, applications (2015) -- and then the whole thing became moot with the transition to the Euro. In the real world, "F", "FF", "₣" and "Fr" were, to the best of my knowledge, used interchangeably. Ahasuerus 18:24, 9 November 2021 (EST)
Advantages of changing the rule, generally a space between symbol / abbreviation and numerical value (e.g. € 1.00):
1. Uniform standard
2. No selection option, therefore no incorrect entries possible
3. Visually appealing
4. Simplified data entry
5. Process security
and more later.--Wolfram.winkler 16:30, 10 November 2021 (EST)
No contradictions? Then the rule can be changed. Thanks. I love quick decisions. --Wolfram.winkler 16:49, 15 November 2021 (EST)
I really hope you are not serious. You got noone agreeing with you. You got more than one editor disagreeing. Please read the whole thread - most of your points had been disagreed on at least ones. People won't repeat themselves just because you want to ignore what they say and repeat the same things. Annie 17:16, 15 November 2021 (EST)
Our data entry rules are changed when a new consensus has been established. In this case the proposed change to the rules has not been supported by any contributors aside from the person who originally proposed the change. Ahasuerus 17:31, 15 November 2021 (EST)
I see no reason to get embroiled in what I consider to be an inane discussion - unless it looks like it is actually gaining any traction. At which point I'll marshal arguments and spend the time presenting my arguments. ../Doug H 19:32, 15 November 2021 (EST)
In this discussion I cannot see any clear, reliable arguments against a rule change.
Annie says: "The frequency of errors is increasing". Why that should be so is not explained.
Ahasuerus says: "There has never been a space between a character and a value in English". Then it is time to change that, if it brings advantages.
ErsatzCulture says: "a format like" £ 9.99 "looks super-weird to my eyes". Not a reliable argument. This kind of argument was commented earlier by Annie as follows: "is not a good reason". Look above.
/Doug H means: no argument.
It would be better if the reason was:
I am against a rule change, because ... (reason)
That is a clear statement.
Unfortunately, there does not seem to be a clear majority in favor of a positive change. But that was predictable.--Wolfram.winkler 11:24, 17 November 2021 (EST)

Twitterzines

I was unable to find a discussion of "twitterzines" anywhere in the wiki so I don't know if this has come up for discussion before.

According to ISFDB policy, the rules of acquisition include "speculative fiction webzines, which are defined as online periodicals with distinct issues" and also "special speculative fiction issues of non-genre webzines" as eligible for indexing.

I'm just wondering if "webzine" includes such non-genre "twitterzines" as Cuento Magazine @CuentoMag (which publishes quite a bit of speculative fiction), Nanoism @nanoism, and escarp @escarp (which ceased publishing in late 2019 but is still online). The latter two zines also publish(ed) their stories (or sometimes poetry in the case of escarp) on a separate Web site (nanoism.net and escarp.org, respectively). Unlike escarp, both Cuento Magazine and Nanoism number each tweet-length story so that the former's most recent tweet (November 15, 2021) is numbered 864, while the latter has reached 934 stories as of November 12, 2021 (although the stories there are only numbered on the Web site, not on the Twitter account). Both figures exclude other tweets that provided author bios or other notices. In contrast, escarp only reached 230 tweets. Most of these stories are untitled but once the longer 280-character tweet became available, some authors used the extra space to add a title at Cuento Magazine and, I believe, at some other twitterzines not mentioned here.

While these would be regarded as non-genre magazines, does the publication of a speculative tweet-length story (which is, in effect, an individual "issue" since it's numbered and/or separately dated) make it eligible for indexing on the grounds that it is a "special speculative fiction [issue] of [a] non-genre [webzine]"? Greg --Explorer1000 23:40, 19 November 2021 (EST)

Every blog posts stories with dates on them. If we interpret the rule to allow for a "date-based issues", every story out there on a blog, Facebook or anything else with dates on it becomes eligible. Which is circumventing the attempt to start opening the door for web-only content slowly. Now - the numbering DOES give you a leg to stand on but as you said, these are only numbered on the site so that sounds more like a cataloging numbering and not a real numbering as magazines and webzines issues are numbered - if the "issue" itself does not carry a number, is it an issue at all?
A better idea may be to restart the conversation over in R&S and to change the ROA again to open the door a bit more. I still think that allowing any story from anywhere on the web will be too fast. Although I would admit that I cannot think of how to allow these cleanly while not allowing someone's personal blog and all author sites and so on... :) Annie 02:06, 20 November 2021 (EST)
Well one difference between a twitterzine (or indeed a webzine) and a personal blog is that the former is composed of stories written by a number of distinct authors, which are selected by an editor for publication, whereas a personal blog is a piece of writing that is (typically) written by the owner/publisher of the blog and so goes through no editorial selection process. I don't think blogs merit inclusion in the database as they are really just a publicly accessible diary entry. However, guest blogs, where different people contribute essays that an editor agrees to publish looks a bit more like a webzine and, to me, might merit indexing (once/if the principles of indexing such works are agreed upon).
But, based on some of the points you make, Annie, maybe some twitterzines are more eligible than others. If an issue number is a requirement for defining a periodical publication, and therefore "date-based issues" are ineligible, this would exclude escarp. Cuento Magazine would, on the other hand, merit inclusion since its now 866 stories (out of 1,958 tweets) are numbered as well as dated.
Nanoism, however, is different again in that there is a question as to which is the true publication - the Web site that publishes only the stories (plus "about" and submission guidelines pages) or the Twitter account where the stories are published in an unnumbered format among other tweets (which number 2,084)? Incidentally, Nanoism has an ISSN: 2372-4099 according to the "about" page. Greg --Explorer1000 15:44, 20 November 2021 (EST)

Kaidankai

I'm holding several submissions ([3], [4], [5], [6]) that would add Kaidankai, a site that posted stories over 100 days. It has the stories grouped by days so is that enough to call these issues and include as webzines? They were also posted as a podcast which clearly has distinct issues so if that was entered it would meet the webzine criteria. I'm on the fence over the web version though and looking for other opinions. -- JLaTondre (talk) 08:17, 27 November 2021 (EST)

Looking at the site, I see that it has the following "issues":
  • Days 1-7
  • Days 8-14
  • Days 15-21
  • Days 22-28
  • Days 29-35
  • Days 36-42
  • Days 43-49
  • Days 50-56
  • Days 57-63
  • Days 64-70
  • ​Days 71-77
  • Days 78-84
  • Days 85-100
Moreover, I note that this page says:
  • All accepted stories will be read on the podcast and posted to the website for 100 days. After that, they go dark.
As of this evening, story #92 is up, which presumably means that all stories will be deleted in 8 days.
Overall, I would say that this is borderline, but I can see how we can call these pages "issues" for our purposes. If we are going to include them, we may want to grab the metadata while the site is still up. Ahasuerus 19:59, 27 November 2021 (EST)
The pages so far have been archived:
  1. Days 1-7
  2. Days 8-14
  3. Days 15-21
  4. Days 22-28
  5. Days 29-35
  6. Days 36-42
  7. Days 43-49
  8. Days 50-56
  9. Days 57-63
  10. Days 64-70
  11. Days 71-77
  12. Days 78-84
  13. Days 85-100 (through Day 92)
  14. Contributors (through Day 92)
···日本穣 · 投稿 · Talk to Nihonjoe 16:18, 30 November 2021 (EST)
I will accept the edits and add the missing data. Nihonjoe, thanks for archiving them. -- JLaTondre (talk) 18:29, 1 December 2021 (EST)
We'll need to keep an eye on it and archive the 85-100 page and the contributors page again once all of the stories are up. ···日本穣 · 投稿 · Talk to Nihonjoe 11:59, 2 December 2021 (EST)
I'm wondering if it ended early. They are still on day 92 and it's been three days. The last story is also an expanded version of the first story. I'll continue checking daily just to be sure. There is also something off on the 100 days and it vanishes as day 11 and day 12 are already gone, including in the archives you made. -- JLaTondre (talk) 19:14, 2 December 2021 (EST)
Looks like it. I just checked and the last entry is still 92. ···日本穣 · 投稿 · Talk to Nihonjoe 12:27, 6 January 2022 (EST)

Page & Spine: Fiction Showcase

Page & Spine: Fiction Showcase is a webzine that publishes stories, poems and essays on a weekly basis, and it has been doing so since 2012. The current issue (as I’m writing this) came out on 31 December 2021. However, its issues are not saved as such. Rather, the various contributions to each issue are archived by month according to the sections in which they were published.

As a general fiction and poetry site, speculative fiction was originally published alongside general fiction, romance, mysteries, and so on, with microfiction appearing in its “Crumbs” section. Starting in May 2020, however, the editor/publisher of Page & Spine, Nancy Wagner, allocated a specialized section devoted to speculative fiction (and some poems), calling it “Outta This World” (though speculative microfiction has continued to appear in the "Crumbs" section). The contributions to “Outta This World” are indexed here.

Last year, Wagner posted on the site that final submissions would be considered until 31 December 2021. As readers are reminded in the current issue, the last issue of Page & Spine will be published on 6 May 2022 and that access to the site will cease on 3 May 2023 (in other words, it will be taken offline).

I think this site merits indexing, even though the “issues” themselves are not archived. However, it’s a large site and would probably need a group effort by indexers to cover it, if it is deemed to be acceptable for indexing. There’s less than a year-and-a-half available to index it and, having checked its inclusion in the Internet Archive, I found that the latter’s coverage of Page & Spine is a bit patchy. It therefore can’t be relied upon as a substitute for the actual site itself.

If speculative material across the site as a whole is not considered eligible for indexing, I think that at the very least, the “Outta This World” section should be. Any thoughts? —The preceding unsigned comment was added by Explorer1000 (talk • contribs) .

Under the current rules, the only webzines that are eligible are:
  • Speculative fiction webzines, which are defined as online periodicals with distinct issues (note: online periodicals without distinct issues are not considered webzines)
  • Special speculative fiction issues of non-genre webzines
  • One time speculative fiction anthologies published on the Web
Note that general NON-genre webzines are never eligible unless they publish a complete genre issue (unlike paper and ebook 'zines which can be added as non-genre and only with their genre contents insid indexed). There are a lot of fiction out there which may be worth indexing but unless we change the rules (which is possible and very likely) or find a rule under which they fit, they are not eligible (yet). This very strict definition of what is allowed was a first step - we never expanded again but we will sooner or later - and non-genre webzines with issues is probably the next step. From what I see on this site, the site as a whole is out at the moment; the "Outta This World" can be added as "webzine with monthly issues". :) Annie 15:44, 5 January 2022 (EST)
Thanks Annie! :) I'm aware of the current rules. I just wanted to open discussion on the eligibility of this particular site, especially as it will disappear in May '23. So if the rules are changed over the next year, say, so as to allow for indexing sites such as Page & Spine, then at least indexers will have advance knowledge of Page & Spine's existence.
I think that some items already listed (or which will be listed) in this database first appeared in "Page & Spine" (which doesn't publish reprints), but this first publication data is not yet being captured for the ISFDB.--Explorer1000 16:37, 5 January 2022 (EST)
We cannot just decide that a special site is eligible just because it will disappear though - we can try to organize a strike force for one that is eligible but opening the door for "ad hoc eligibility" can lead to some very wide open doors IMO - there are a LOT of them out there. :) We can discuss the change of rules though, using that one as an example and pushing for timing :) And worst case scenario, someone can add the details in Wiki preparing for the day when it MAY be eligible. It really comes down to time and effort and resources - in a perfect world, we will allow any speculative fiction anywhere in the world (online, paper, ebook, whatever the next technology is)... but the world is not perfect and we have limited resources (editors and moderators) so we are carefully opening the doors little by little. Annie 16:43, 5 January 2022 (EST)
OK. What if any updated rule specified that where a non-genre webzine has a section/department/column, which could also serve as an archive (as in the present case), that is devoted to speculative fiction, poetry and/or essays, then only this portion of the publication would be considered eligible for indexing? This would apply a general rule so that there would be no need for ad hoc decisions about specific electronic publications. It would also mean that the bulk of what such webzines/Web sites publish would not even be examined for indexing. So, with Page & Spine, only the two years' worth of material published exclusively in the "Outta This World" section (up to May 2022) would be eligible for indexing, while all the other circa ten years' worth of material, including speculative items, would not. In other words, I'm proposing a compromise between indexing everything in the 'ideal world' scenario and where nothing is indexed at all, which is the situation at present.--Explorer1000 18:46, 5 January 2022 (EST)
Figure out wording for the change, post a proposal (here is fine - and I can see if I can come up with wording based on your explanation if you want?), get enough support, revise a few times based on corner cases and other ideas (there will be a lot of them - a lot of them based on experience here and elsewhere and things you may had not seen before (or did not realize will apply to the proposal)) and the rules get changed. Same way we added the webzines at all a few years back. Same way ebooks were allowed a few years before that (it was just "paper" at the start of the project). And again - in this case the column seems like a legitimate issue-based webzine on its own so I'd allow it under that rule if someone submits it. But we do need to revise this whole set of rules anyway so... may as well discuss what we do want to try to allow. :) Annie 19:03, 5 January 2022 (EST)
Sorry for taking a couple of weeks to get back to this.
Here is my suggested insert into the "included" list of the current "Rules of Acquisition":
  1. Published works of speculative fiction, regardless of whether they are published within or outside the genre. "Published" is defined as follows:
  • paper books published by:
    • professional publishers
    • small presses
    • print on demand (POD) publications
    • self or vanity publishers
  • paper periodicals of the following types:
    • professionally published magazines (prozines)
    • semi-professionally published magazines (semi-prozines)
    • paper-based fanzines
    • newspapers
  • electronic publications of the following types:
    • e-books with a unique identifier such as an ISBN, ASIN, EAN, or catalog number
    • downloadable e-zines
    • Internet-based publications which are downloadable as electronic files in any number of ebook formats (ePub, Mobi, PDF, etc).
    • Speculative fiction webzines, which are defined as online periodicals with distinct issues (note: online periodicals without distinct issues are not ::::::considered webzines)
    • Special speculative fiction issues of non-genre webzines
    • Speculative fiction sections or columns of otherwise non-genre webzines
    • One time speculative fiction anthologies published on the Web
    • Online publications available exclusively as a Web page, but only if:
      • published by a market which makes the author eligible for SFWA membership (listed here), OR
      • shortlisted for a major award
  • audio books, i.e. readings, but not dramatizations
So would that be sufficient or does it need more specific information?--Explorer1000 15:41, 21 January 2022 (EST)

Excerpts with no originals

I would expect that any excerpts from material would have an entry for the original (linking is another story). I would also expect some exceptions, such as previews of books never published. However, I ran across a different sort of exception - in this case a poem from the Rubaiyat of Omar Khayyam. I recognize the title but have never read any of it. If it is speculative fiction, it should be included and the referencing work (Weird Tales) is correct. If the excerpt(s) are the only speculative content from a collection of poems, should the Rubaiyat be included but only the speculative content? Which would mean dropping the "(excerpt)" from the names. If it is not speculative, should the referencing work not have included the reference? If it is left in, should an entry for the original be created even if not speculative to support the excerpt? But if you do, would we want only the original for the excerpt to link to (eventually)? This example has been translated, so should only 'link' to the translated version - which may or may not have been specified.

My query was prompted by an Icelandic translation of the Rubaiyat I ran across. I was going to put my query as to whether the Rubaiyat was speculative in the Help Desk, but the general questions seemed to belong here. Some questions may have answers, but some may simply be fodder for later discussions on generic linking for things like translations, versions of, and such like. ../Doug H 16:52, 8 January 2022 (EST)

Let's address the general issue first. We index everything in genre magazines, including non-genre stories. By extension, it applies to non-genre excerpts. Also, title records have a "non-genre" flag which can be applied to explicitly non-genre works. I don't think the existence of a title record for an excerpt from a non-genre work should require us to create a separate record for the full non-genre title.
Re: this particular case, I read Rubaiyat of Omar Khayyam a long time ago, so I am not 100% sure, but I don't recall anything particularly speculative about it. It's a collection of pithy short poems with philosophical and religious overtones. Ahasuerus 23:41, 8 January 2022 (EST)

Currency symbols (again): full-width versions of currency characters

I was being nosey and scrolling through the recent activity page for any interesting looking edits, and noticed this pub, which had an odd-looking (to my eyes) pound sign in the price field.

On further investigation, it looks to be copied directly from the publisher's site, and is a Unicode full-width version of the regular GBP £ pound sign. (There's a similar one for USD $, and I imagine there'll ones for the Euro, yen, etc.)

This isn't a big issue, but as someone who's got some hacky code to try to determine a pub's country of original based on the price, I'm wondering whether I should update my code to handle these variant characters and/or it's reasonable to submit edits to convert these prices to the standard characters? (I've not yet run a query to see how many records might be affected, but I suspect it'll be few enough that these could be manually handled without too much effort. I dunno if the price cleanup report would/could pick them up?) ErsatzCulture 11:54, 13 January 2022 (EST)

Should use the standard symbol IMO (and there should not be a space in there either) - that will make it easier to convert if/when these fields get restructured. That's partially why we allow L, E and a few other letters to be used in case one cannot do their own symbol and convert them on Submit. :)
That record also has the wrong date (6-8-2020 is August and not June in UK and almost everywhere else that is not USA) and it is also too short IMO (Kobo concurs: 32K words for the ebook on the English edition - the Japanese word counts work differently but that's definitely too short for a novel) :)
PS: We probably need this to be catchable in our cleanup report somehow indeed... Annie 12:10, 13 January 2022 (EST)
"Fullwidth" and "halfwidth" versions of regular characters as used by Unicode are a known problem. They appear to be more common in Japan, which is why our input filters automatically convert "fullwidth" yen signs ("￥") to regular yen signs. Let me add "￡", "＄" and "￦" to the list of characters to be automatically converted to their equivalents. It won't address the larger issue of all other ASCII and Japanese characters having "fullwidth" and "halfwidth" counterparts -- like in the title of this record -- but it's a step in the right direction. Ahasuerus 14:21, 13 January 2022 (EST)
Meanwhile I fixed the field (as I was updating the format and the date anyway - both were incorrect - reversed month/date and the book is really pb-sized). Plus a note added on the title level about the length. Annie 16:17, 13 January 2022 (EST)
The software and the publication record have been fixed. Ahasuerus 16:23, 13 January 2022 (EST)
Thanks both. (I'd spotted the length issue, but not the date or format ones. Will submit the ebook once I've processed the data I've scraped.) ErsatzCulture 18:13, 13 January 2022 (EST)

Different Prices

New editor here. I have a copy of Asimov / Foundation's Edge which appears identical to this one: Foundation's Edge except that both the US and Canadian prices are different. My copy is also: "Seventeenth Printing: March 1989". Based on the Last User Activity Date, the two existing PVs appear to be inactive so I haven't asked them to check. However, the cover scan for the above record confirms the prices stated in the pub record, although I suppose it could be a scan from a different printing (seems unlikely). Does the ISFDb have a policy for this situation? Should I
1) edit and change the prices in the existing record?
2) add a note to the existing record stating some copies have different prices?
3) create a new pub record?
Teallach 13:46, 19 January 2022 (EST)

That will depend - first we need to make sure that these are really the same books. The basic policy is to make sure that we don't lose editions if we can help it.
  • Does your say "Printed in USA"? Del Rey in 1989 published both Canadian and US editions and occasionally the only difference was the printing place and the prices. If you truly have the same book, some more ideas:
  • How different are the prices? Is it possible that the copyright in what you are holding was not updated but it is actually a later printing? The prices can help figure that one out compared to other books from the same publisher
In any case, it sounds like you are holding a different book from this one so we will need a new record and possibly an update on the one we have - but let's see if we can figure out what is going on first.Annie 15:57, 19 January 2022 (EST)
My copy is as follows:
On front cover and spine: US$4.95, C$6.50
On rear cover: Cover printed in USA
On copyright page:
  • A Del Rey Book
  • Published by Ballantine Books
  • LCCN: 82-45450
  • ISBN 0-345-30898-0
  • Manufactured in the USA
  • First Ballantine Books Edition: November 1983
  • Seventeenth Printing: March 1989
The LCCN is unhelpful; it relates to the 1982 Doubleday hardcover.
There are no house ads in the book, so no clues from date codes or contemporaneously published titlesTeallach 18:50, 19 January 2022 (EST)
My first reaction was "$5.95 (US) sounds too high for a 1989 mass market paperback". However, Advanced Publication Search finds 6 Del Rey/Ballantine paperback with a $5.95 price. Notably, 4 of them are reprints of different Foundation books (other Asimov paperbacks published by Del Rey in 1989 were priced between $3.95 and $4.95), so I suspect that the $5.95 data that we currently have on file is correct.
Based on what we know and the primary verifiers' unavailability, I think the safest bet would be to create another publication record and document the discrepancies in Notes. Ahasuerus 20:06, 19 January 2022 (EST)
I agree - something is off here but without the other PVs, it will be hard to discover what. So clone the existing one, add your own cover and add notes explaining the double 17th printing (ask if you would like some help with wording) and maybe one day, this mystery will be solved. I do wonder if all of those 5.95 are later printings keeping the copyright page but who knows. Annie 21:09, 19 January 2022 (EST)

Help entry for Cover Art

The existing entry for Cover Art makes special mention of how to (or not to) credit the designer of the cover. There are two other special cases that might be worth noting, if we have an accepted policy - namely photographs and movie images.

I'd like to observe that some of the information regarding attribution belongs in the publication, but some (e.g. designer) belongs in any associated COVERART title record that is automatically generated and would need to be tracked down after approval. Perhaps this aspect might also be covered. As might the known problem of being unable to generate a COVERART without an artist to be able to merge/variant with other publications with the same art and how to deal with it. ../Doug H 12:27, 22 January 2022 (EST)

Help entry for External Identifiers

There is an inconsistency between the template name and example - JNB / JBN. Which is correct?:

JNB | Links to Japanese National Bibliography | using a Japanese National Bibliography number (JPNO) | {{JBN|22859001}}

../Doug H 15:47, 28 January 2022 (EST)

I have checked the software and it's "JNB". The Help text has been corrected -- thanks! Ahasuerus 16:41, 28 January 2022 (EST)

Standarizing Help guidance re: editing primary verified pubs

We have two places where we describe the process of editing primary verified publications: the ISFDB FAQ and Help:How_to_verify_data#Making_changes_to_verified_pubs. Like a number of other Help pages which cover the same topic, they provide editors with somewhat different instructions.

Earlier today I created a new Help page, Help:How to change verified publications, in order to centralize the instructions that cover this process. At the moment, it has the same text that Help:How_to_verify_data#Making_changes_to_verified_pubs had a few hours ago, a minor grammar fix aside. After comparing it with what the FAQ says, I came up with the following, more detailed and explicit, Help language:

It's not uncommon for two seemingly identical copies of a publication (book, magazine, etc) to turn out to be two different versions of the publication. What at first glance may appear to be a data entry error in an ISFDB publication record may be an indicator of a different edition/printing. It's also possible that editors with access to the same publication may interpret the ISFDB data entry standards -- as they apply to a particular situation -- differently.
For these reasons, proposed changes to a primary verified publication should be coordinated with all verifiers of the affected publication using their Wiki-based Talk pages. [Sentence added on 2022-01-29:] Note that this is in addition to entering a software-enforced explanation in the "Moderator Note" field when creating a submission. If a primary verifier has created a special Talk sub-page for notifications, please read and follow any special requests placed at the top of the verifier's Talk page.
The following are the recognized exceptions to this rule:
  • The verifier's Talk page states that the verifier has requested not to be notified about certain types of changes
  • The verifier's Talk page states that the verifier has left the project or is deceased. (Note that each primary verifier's "Last User Activity Date" is displayed in the "Primary Verifications" table displayed on the verified publication's Web page.)
  • [Edit 1: The following exceptions were added based on the discussion below on 2022-01-29]
  • You are adding one or more External IDs
  • You are fixing formatting, spelling and/or grammar errors in Notes
  • You are adding publication-specific links to Web pages
  • You are adding one or more transliterated titles
If one or more primary verifiers do not agree with the proposed change or if no verifiers respond within 7 days, post a note on ISFDB:Moderator noticeboard. A moderator will determine whether to make the proposed change and will inform the current verifier(s).
Note that this process should be followed by all editors, including self-approvers and moderators. If an original verifier does not agree to the proposed change, only a moderator should make changes to the publication record after notifying the verifier about the decision.

How does it look? Ahasuerus 16:52, 28 January 2022 (EST)

I like the combined version. Annie 18:08, 28 January 2022 (EST)
As is current practice, I should also explicitly include allowance to notify PVs via the note to moderators for trivial/unambiguous edits. The proposed text doesn't really allow for it, does it?. MagicUnk 03:30, 29 January 2022 (EST)
No, it doesn't. The proposed wording is more restrictive than current practice and a step backwards:
  • It doesn't differentiate between changes and additions. Adding data to a record is also an act of changing the record. As currently written, this would apply to even the act of adding an external id.
  • The second exception should be based on the Last User Activity Date on the publication record. The data is shown on the publication record. People shouldn't have to waste time checking whether a user who hasn't edited in years has an inactive template on their talk page (which are not consistently applied, especially for users who were not highly active to begin with).
  • It should allow for simple changes (ex. spelling fixes in the notes) or changes that bring a publication inline with updated ISFDB standards (ex. removing series name from the title) via the notification system (but require a clear description of the change in the note to moderator field).
-- JLaTondre (talk) 08:38, 29 January 2022 (EST)
The concern that I had with allowing adding (as opposed to changing) data without notifying the verifier was that adding a cover scan, a cover artist, a missed price, etc would be, technically, adding data, yet we would want the primary verifier to be notified because it could indicate a different printing.
Thinking about it, I agree that trivial/unambiguous changes/additions should not require notification beyond entering an explanation in the Moderator Note field, but the challenge is defining "trivial/unambiguous" in a way that everyone agrees with. Let's try to list everything that we want to consider "trivial/unambiguous" in the list of exceptions above:
  • Adding External IDs
  • Fixing formatting, spelling and grammar errors in Notes
  • Adding publication-specific links to Web pages
  • Adding transliterated titles
I am not sure above removing series names from publication titles. In most case it's a trivial change, but I have also seen disagreements about borderline cases.
Re: using the Last User Activity Date to determine whether to notify the verifier, the software uses the following dates to calculate it:
  • Date of last submission
  • Date of last primary verification
  • Date of last secondary verification
  • Date of last Wiki edit
It's possible for an editor to stop editing the data yet to continue to be a user of the database and to want to be notified about changes to his or her verified records -- I remember it happening a few years ago.
If we do decide to use the Last User Activity Date, we will want to come up with a threshold value, e.g. 2 years. Ahasuerus 10:25, 29 January 2022 (EST)
Re. "Adding publication-specific links to Web pages", this might overcomplicate things, but could I also suggest adding "... or fixing broken links" - typically either turning them into archive.org copies, or new URLs (e.g. when publisher's decide to upgrade their CMS and don't bother to add redirects for their old links)? That the old link is broken should be explicitly stated in the mod note. Also, in cases where the old link works, but another editor thinks they've found a better one (e.g. replacing a search results URL with a proper "canonical" URL for a specific ISBN), any such edit would still need PV approval. ErsatzCulture 10:48, 29 January 2022 (EST)
We could phrase it as "Update obsolete URLs as long as they point to the same Web text". "Obsolete" is more open-ended than "broken" because it includes scenarios like "HTTP-to-HTTPS upgrade" where HTTP links still work but shouldn't be used any more (deprecated.) Ahasuerus 11:06, 29 January 2022 (EST)
I think a key element in what is 'added' is whether it is evident from the publication or not. If I add a cover artist based on the artist web site, this would in no way invalidate or change anything the other PVer's had entered or verified. As long as I document the source of the added information, no harm, no foul. Adding one based on an initial visible on the cover (possible near an edge, clipped for some printings) would be the grey area. As for checking Last Activity Date vs. Talk Page, I'd lean to Talk Page. Just because I've entered/verified all my library and have no desire to get involved in Forum melees doesn't mean I shouldn't be notified. And updating formatting is a slippery slope, sometimes (not often) the format conveys information. Until we develop format guides, I'd say that anyone who dislikes a format badly enough to change it, should have to notify the people who found it acceptable. Besides, who else is going to admire all the work put in? ../Doug H 11:19, 29 January 2022 (EST)
Given that such notifications make up a large part of Talk Page usage, is there any way to develop a 'notification template' where you point to a publication, explain what you want and have the system post it where appropriate including your talk page with links to the relevant notifications for you to check? ../Doug H 11:24, 29 January 2022 (EST)
There needs to be a trade of benefit vs. burden. For example, how many users have not edited the database in 6 months to a year, have not edited the wiki in 6 months to a year, and still check their talk page every week? I doubt it is many if any. -- JLaTondre (talk) 11:50, 29 January 2022 (EST)
I can live with 12 or even 6 months as the threshold; my main goal with the proposed Help changes is to migrate from inherently subjective and ambiguous descriptions like "significant" to a set of objective, unambiguous rules which would be easier to understand and enforce. Ahasuerus 16:27, 29 January 2022 (EST)
They will still get the notification of change through the "My Changed Primary Verifications" when they return. We can easily fix the tiny amount of issues that might slip through the cracks. Ideally, the software should handle all this - edits that change verified data go into a pending state, verifiers are automatically notified, they get an option to ok the edit or add a comment, when all active verifiers have responded or 7 days have past, it moves to the moderator queue to handle. But until then, we should be careful of driving up the burden of editing while providing little benefit. -- JLaTondre (talk) 11:50, 29 January 2022 (EST)
Re: Notification of change. The log is not a 'notification', it's a log. Checking my log I see an entry from January 18th with changes to ContentTitle, External ID. The Note to Moderator says "Have copy in hand. Will PV. Added LCCN". Based on green highlighting I see they put the page number for the novel. I also see that it is linked to Libris-XL instead of LCCN and the editor has not been PV'd. Most of the changes I see in the log I would not expect notice for - adding external IDs, cover credits (that create COVERART records) and Notes. If I was gone for six months or more (again) sifting through the chaff for wheat is possible but not friendly. Especially when the comments are vague and I end up going back through the XML to see what was really changed. As to benefit vs. burden - I invested my time creating/verifying an entry. In those cases where you think I'm wrong (i.e. not just 'adding' information), why should your time be worth more than mine? So while I agree with the trade-off concept and would probably agree with you on 90% or more the the examples we pull up - what are we trading off? ../Doug H 16:11, 29 January 2022 (EST)
It is most certainly a notification. Moderators could do better at quality checking the changes against the moderator note (as a moderator, it would be nice to be able to edit the existing note field or add an additional note when approving), but a few bad examples do not invalidate it. You are overly optimistic if you believe that telling people to use the wiki will by itself improve the quality of the information provided. You would simply have gotten the same information on your user talk page. -- JLaTondre (talk) 16:29, 29 January 2022 (EST)
Sorry for nitpicking English, a notification is an official communication. I'm willing to go with the log is a passive communication of information and the Talk page is an active communication. I'll read your arguments for the log as being for 'passive communication' unless you say that isn't your intention. ../Doug H 23:46, 29 January 2022 (EST)
Yes, that's exactly what it should be: any explanation in the notes to moderators is 'passive communication'. As it is readily accessible, and the editor gets a warning whenever a PV'd record is updated, I don't see much difference with notifying the PV on his/her talk page - at least not for trivial, uncontested (uncontestable?) changes and/or additions. It's a different matter where there's ambiguity, or you want the PV to verify something against the physical copy - that's where the talk page is needed. So, to summarize, I am not saying that you shouldn't notify the PV, I'm saying that the notes to moderator is equally valid as the talk page in the cases laid out above. I myself am oftentimes adding prices from secondary sources, external ID's, standardizing titles by applying Dutch capitalization rules, adding/expanding notes, all of which are explained in the notes to moderators, iso on talk pages - I never (that I recall) had any issues with PV's being offended or demanding I notify them on their talk page. Just my 2 cents... Regards, MagicUnk 11:37, 30 January 2022 (EST)
So that's what the "New" message meant. It showed up when the feature was introduced and I've basically ignored it since. ../Doug H 16:25, 30 January 2022 (EST)
Re: "trivial/unambiguous". In many cases (publications from the olden times - mostly pre-21st Century) we have only years. As with the example of sourced cover artists it'd also be tedious to get a hold-on for adding months or even days to those publications, as long as they are sourced. Much of my work on German publications (but also for other languages) is doing that. Stonecreek 12:13, 29 January 2022 (EST)

(unindent)

Back to the rules. I don't think there is any difference between adding, modifying or deleting information that is based on the verified copy. IF all other information is given a source attribution, it should be easy to identify what was verified. ANY change to the verified data needs to be brought to the attention of the verifier, prior to making the change. Any other change, if the source is documented in the Notes, is basically the result of research, not evident in the copy and hence need not be brought specifically to the attention of the verifier(s). With a good definition of how to record what is in the verified copy (including notes like "Designed by:", actual publisher names, non-existence of cover signatures), the rules would only need to deal with contact and drop the 'exceptions'. ../Doug H 16:44, 30 January 2022 (EST)

Varianted Cover Art

It seems redundant to me to write a note explaining where a cover art credit came from when ISFDB tells you in the cover art field what the current art is a variant of already, as can be seen here: http://www.isfdb.org/cgi-bin/pl.cgi?420922. Just a thought. --Username 10:29, 30 January 2022 (EST)

One reason I see is that it tells why the artist is credited on a publication that does not contain the information directly. One other possibility is that varianting COVERART was not possible 10 years ago, making the note necessary. ../Doug H 14:04, 30 January 2022 (EST)
Let's consider the publication in question, i.e. the 1969 Popular Library edition of Edmond Hamilton's Outlaws of the Moon. The "Cover" field says:
while the Notes field says:
Once we follow the link to our Perry Rhodan, #205: Der Wächter von Andromeda record, we discover that the Notes field says:
In other words, the original source of the cover art credit was Perrypedia. The attribution was then propagated to our Perry Rhodan 205 record and to our Outlaws of the Moon record. I think that stating this "chain of attribution" in the Notes fields of both publication records would be useful. Ahasuerus 15:30, 30 January 2022 (EST)

Melvyl

The link to Melvyl (the Catalog of the University of California Libraries) referenced in Sources of Bibliographic Information no longer functions and has been superseded. I've noted it as such on the wiki page with its replacement, but the template itself {{Melvyl}} needs to be dealt with. ../Doug H 12:48, 1 February 2022 (EST)

I have removed the Melvyl template and all current Wiki references to it. We never implemented it on the database side, so it's not an issue there. Thanks for the heads up! Ahasuerus 14:40, 1 February 2022 (EST)

Proposed Date help text revision

Cross-posted to Community Portal as well. I have a draft revision of the help text for publication dates available at User:MartyD/ProposedDateHelp for review. This is meant to codify/clarify existing rules/policies, not to define anything new or different. A special thanks to the early reviewers. Please comment on the discussion page there. Thanks! --MartyD 13:31, 5 February 2022 (EST)

Very nicely done. I like it. MagicUnk 07:45, 6 February 2022 (EST)
The official Template:PublicationFields:Date has been updated with the proposed text. --MartyD 12:40, 12 February 2022 (EST)

Converting a NOVEL to a CHAPBOOK (Titles with more than one publication record)

The helptext is clear enough, but I think one more step is needed. In step 2-5 the NOVEL record is converted to SHORTFICTION, effectively removing the container title from the publication. In step 6 the CHAPBOOK title is added, but because there is no container title, no language is set for the new container. I suggest to do step 6 only for the first publication, and add step 7: Set the language for the new CHAPBOOK title, and import this title in the remaining publications. Perhaps with a warning not to add other contents in step 2-5. I see no easier solution, since "the software will not allow you to add a CHAPBOOK to a publication record which contains a NOVEL title.". Thoughts? --Willem 10:41, 6 February 2022 (EST)

You cannot import it either - the software does not allow you to because the publication is still a NOVEL at that point and a chapbook cannot be added to a novel record. You need to convert each publication separately and add a separate chapbook record in each - and then merge them and adjust the language and the different flags (juvenile, non-genre and so on). Annie 16:04, 6 February 2022 (EST)
That should be tried. At that point the publication does not contain a NOVEL title anymore (it is already converted to SHORTFICTION). If the pubtype prevents the import, the helptext is wrong. --Willem 16:20, 6 February 2022 (EST)
Tried a few dozen times when I forget about that... (not lately though - see the last note here - you don't win anything even if you can do it). But sure, if you don't believe me - go and try. :) I can even give you something which needs converting to try on: this one for example. I wish it was doable - but it is one of the protections put into the software in the last year to ensure that we cannot import the wrong types into publication of a certain type. You cannot import a chapbook when the publication type is NOVEL and you still need to edit the publication to change the pub type anyway. Although even if doable, it won't reduce the number of steps -- you still need to change the publication type. I breaks even at 2 pubs. In cases where you have more than 2 publications, it actually increases the number of steps (as you are replacing Edit per title + 1 Merge + 1 edit for language and flags with Edit on the first book + edit on the title level + (Edit + Import) on each subsequent publication. Annie 16:30, 6 February 2022 (EST)
D**n, you're right. I suggest we change the helptext to "the software will not allow you to add a CHAPBOOK to a publication record of the NOVEL type." :) --Willem 16:55, 6 February 2022 (EST)
Thanks for the test subject by the way. --Willem 16:56, 6 February 2022 (EST)
Took seven edits because of the variant. And I nearly forgot to set the language! --Willem 17:03, 6 February 2022 (EST)
Why do you think I have a test subject I had not converted. :) They are a lot of work so I usually work on them in batches (with a bit of help from another editor). Did you remember to set the juvenile flag on the chapbook? And yeah - we need to change the wording. Annie 17:30, 6 February 2022 (EST)
Nope, you forgot that one :) Fixed now. I usually add all needed chapbooks, then merge them, then edit the result to add language and flags. And then variant up if needed (so the parent gets the child flag) :) Annie 17:52, 6 February 2022 (EST)
It's a labor-intensive process for sure. I expect that it would be difficult to reduce the number of steps/submissions because they all affect different records :-( Ahasuerus 18:23, 6 February 2022 (EST)
We still need to fix the help page in the "why we cannot have just one chapbook" section as Willem mentioned above - the steps are what they are. :) Annie 18:34, 6 February 2022 (EST)
Oh, sure. I just wish we could streamline the process without making the software look like the plot of a van Vogt novel... Ahasuerus 18:59, 6 February 2022 (EST)

Chapbooks with a Single Story

I've run into a problem with a story titled "The Gate That Locks the Tree", that appears in Liaden Universe Constellation: Volume 5. The story was first published in a chapbook, Gate That Locks the Tree where the story has a slightly modified title. Unfortunately, chapbooks cannot be part of a series, so the story itself is number 30 in the series "Adventures in the Liaden Universe". How can I make the story in the new collection a variant of the title in the chapbook? Bob 11:03, 8 February 2022 (EST)

Ignore the chapbook - open it and go down to the story itself. Variant the stories: this record and this record. That's it :) Annie 11:10, 8 February 2022 (EST)
You know, I tried that several times and failed. This time it worked. Thanks.Bob 19:58, 8 February 2022 (EST)
Aha! I figured it out. I was hitting "Create New Parent Title" instead of "Link to Existing Title". Duh! Bob 11:52, 9 February 2022 (EST)

Is Braille a font or separate letter system?

If we base titles (etc) from title pages, are there any special considerations for braille books to consider before I go down to verify? E.g. Sweet-blood [braille] at my local library, for ISFDB title. ../Doug H 13:01, 21 February 2022 (EST)

I would consider it a tactile font since it's simply presenting the alphabet in a different manner. Any publication that is in Braille should be listed as in whichever language it's in, and have a note indicating it's in Braille. ···日本穣 · 投稿 · Talk to Nihonjoe 14:07, 22 February 2022 (EST)
I agree with that - it is a font, not a language. Annie

Eligibility for a book - second opinion needed

I have The Original Bambi: The Story of a Life in the Forest on hold because I had been trying to figure out if it is in scope - there is nothing fantastical besides the sentient animals. But we do allow allegories ("Animal Farm" for example) and fairy tales - which gives me a bit of a pause. So... anyone with an opinion one way or another? Annie 23:01, 8 March 2022 (EST)

Our policy excludes:
  • Animal books for very young children, i.e. books for preschoolers which depict simple scenes from animal life featuring anthropomorphized animals
but "Bambi" is above that threshold. We include other non-fantastical books about anthropomorphic animals for children like Brian Jacques's Redwall novels (the supposedly "magical" MacGuffin turns out to be mundane), so I think Bambi and it sequel should be "in". Ahasuerus 08:39, 9 March 2022 (EST)
Redwall's animals don't behave much like animals though - while in Bambi we are essentially in a nature tale with talking animals which behave as what they are. I'll approve it though - better have one extra than miss one of ours - and we can always reverse that. Annie 13:52, 9 March 2022 (EST)
I imagine that if we read it it might be clearer... If i encounter a copy I'll give my opinion. Thanks. gzuckier 17:29, 9 March 2022 (EST)
Did you mean to transient verify it? Because that implies you have a copy at hand (or had when you verified it anyway) :) If not, you may want to remove the verification. Annie 17:46, 9 March 2022 (EST)

Vlaamse Filmpjes, magazine or publication series

I need some input / opinions after this discussion. "Vlaamse Filmpjes" is a Belgian periodical for young readers that has been around since 1930, and has some 3400 issues published. 10-15% of these are considered speculative fiction. The majority of these are 32 page staple bound phamphlets, that have one short story each. Sometimes two to four issues are combined in one publication. Normally I would enter this as a publication series of mostly chapbooks, like a lot of Dutch and German periodicals are (see Terra, Apollo, Terra Astra and many more, but to my surprise the issues we have in the database are entered as both publication series and magazine. I always thought this was forbidden, but I can't find anything in the help texts. We now have a stalemate where MagicUnk wants to keep it as a magazine, and I want to turn them into a publication series. Questions are: Is the combination magazine/publication series allowed or not, and if not, which of the two should the "Vlaamse Filmpjes" be. Comments are welcome. --Willem 16:25, 26 March 2022 (EDT)

I notice the site describes them as pocket books, despite the whole numbering and "volume" numbering schemes, so chapbook seems more appropriate than magazine (although I have no objection to either treatment). Putting a magazine into a pub series and using that to record and organize by whole number is rather clever. In my opinion, however, that combined treatment is incorrect. Issues of a magazine are like a title series in that no matter who publishes it, the series continues. --MartyD 12:00, 28 March 2022 (EDT)
It is clever but if we decide to allow it, we really need to do that properly - and well defined. As it is, I agree, the usage is incorrect - pub series are not used for magazines because the series field is already a de-facto pub series one. Annie 13:39, 28 March 2022 (EDT)
What is the distribution model and what do the Belgians consider these to be? That does not always help with the determination but it may help - that's how the Italian Uranias ended up as magazines even if the whole non-Italian world will probably consider them books... It is a thin line sometimes. I am leaning towards magazines (even though ISSN numbers are not just for magazines (they are for any periodical and some chapbooks series and even books series are know to have been published that way)) but either way works for me as long as it is one way or the other. Annie 13:39, 28 March 2022 (EDT)
If I remember correctly, Urania ended up as a magazine because serials were not allowed in other pub types. Vlaamse Filmpjes were (are?) distributed by subscription, through schools and on newsstands, and are considered to be magazines, but the other examples I mentioned are also considered to be magazines. We should have some consistency in how to handle these. --Willem 14:46, 28 March 2022 (EDT)
The problem is that depending on whom you ask, these can go either way :) So I tend to ask local readers when possible. The German editors decisions on how their magazines/whatever are entered should not be determining how we deal with the other languages (and that all can change anyway). It will be very hard to make a consistent rule (requiring columns for magazines will make 90% of the modern small print magazines anthologies for example). Not to mention the webzines. :) I'd love to have a workable rule but... Annie 14:55, 28 March 2022 (EDT)
I agree! I can live with either decision, but as they are now, they're simply wrong. By the way, Fandata (the Dutch SF database) has them as a publication series to make the titles visible on the author's pages. --Willem 15:37, 28 March 2022 (EDT)
Oh, I don't think that anyone is trying to argue that they need fixing. I am just not sure in which direction. :) As I said - I lean towards magazines but a series of chapbooks also makes sense :) The Fandata example is exactly why things can get even murkier these days - sometimes definitions in different bibliographies are based on how a certain DB/project is designed and not based on what the actual reality of the publications is. Another way to look at the differentiation is the editor situation - how important is the editor for these? Moving to chapbooks/pub series means that the editor gets recorded ONLY in the notes; keeping them as magazines leaves the credit to the editor. As these seem to be unknown for the non-PVd ones, it seems like they are not considered "someone's magazine" or something like that. Which may mean that chapbooks may be better.
One other thing: Our EDITOR really stands for "PERIODICAL" which is not a real book (Aka some annual publications which are considered proper books even if they are Periodicals...) and we have only two options under it: Fanzine and Magazine (and even that line can be blurry outside of the English sometimes). So we record things like newspapers as magazines (which is incorrect really but that's what we have) -- thus masking the whole issue a bit. So the question is not if it is a magazine really but rather is that a periodical? If it is, considering that it is not really a book, it really should be under the EDITOR I would think - which means Magazine. The hsort version of all that... pick one, document it and we can always change it if needed... Annie 16:08, 28 March 2022 (EDT)
And while making a decision - the naming rules are different -- you CANNOT have the story title in the magazine title under our rules. So that may also determine what direction you want to go. We can discuss changing the magazines naming rules but under the current rules this needs to be called "Vlaamse Filmpjes, 29 February 2008" as a magazine (with February in Dutch) (or "Vlaamse Filmpjes, #12" if we claim that the magazine is not dated) and just "De ring van de textielbaron" as a chapbook (series titles of any type leave the title of the book). The current Frankenstein of a title is invalid for either case under the current rules. Just saying. Annie 16:13, 28 March 2022 (EDT)
Just one of the things that are wrong. The editor should not be a problem i.m.o. Since only 10 to 15% of the issues are speculative fiction, it would be a non-genre magazine, with "Editors of Vlaamse Filmpjes" as editor. --Willem 16:27, 28 March 2022 (EDT)
Just pointing out the differences - because sometimes the subjective decisions are based on weird things. :) PS: Under the current rules, that is not necessarily needed about non-genre magazines anymore - it is allowed but not mandatory anymore so the magazines can keep their editors if desired. We changed that some time last year. Annie 16:36, 28 March 2022 (EDT)
I notice that, indeed, I did a couple of things wrong when entering these few Vlaamse filmpjes. Pub series, even title, can be fixed to conform to magazine entry rules, but I am still inclined to enter them all as magazines, but I'm fine with whatever the majority prefers. MagicUnk 10:35, 29 March 2022 (EDT)

(unindent) So there's a clear majority for magazine. I entered a test subject here, as I think they could be. Some thoughts: Volume/number was not printed before the 54th year of publication. I would prefer the title to be "Vlaamse Filmpjes, #whole number". The publication date was first printed around #1100. I'm not sure about the editor. I'm leaning towards "Editors of Vlaamse Filmpjes" only. Some editions have a list of editors, the early editions mention no editor at all and the names I have seen are not known in the speculative fition field. Any other suggestions? Thanks,--Willem 14:43, 6 April 2022 (EDT)

That looks reasonable to me. --MartyD 08:02, 9 April 2022 (EDT)

Seeking clarity on multi-volume works.

I have run across multiple volume works a couple of times and always seem to end up spending too much time digging through the help trying to figure out the best way to deal with them. Can the Help page be updated to explain the interplay between Title and Series (title and pub) values and what should be included in each:

  • When the individual publications have no individual title (e.g. Works of Jules Verne [over] Volume 1).
  • When the individual publications have separate titles as subtitles (e.g. Isaac Asimov's Understanding Physics [over] Volume I [over] Motion, Sound, and Heat.
  • When the entire set is published as a single bound publication (e.g. The above set as The History of Physics - presumably an omnibus).
  • When different publishers use different sub-titles (e.g. 2 vs. II, punctuation, Part vs. Volume).
  • Variations between publishers (e.g. The Works set was published as a 15 volume set, and also as a 10 volume set, where volumes 1-10 match in content, Mysterious Island has single volume, double volume and triple volume editions).
  • Does continuity matter? (Physics volumes are stand-alone, Works are stand-alone generally but some stories spanned volumes, Mysterious Island is one continuous story).

One factor to consider is that the Library of Congress seems to assign a single number to the set, and the OCLC allows both set and volumes to be done. Another is ISBN's, although all my examples pre-date ISBNs.

I'm sure there are other variations to be covered (such as those raised by The Lord of the Rings) that can be added to the discussion for consideration. Thanks for any input. ../Doug H 12:30, 23 April 2022 (EDT)

Just thinking aloud - that is one of the "we do what makes sense" area I think...
I go by the title page but with the simplified titles rule in mind. So Works of Jules Verne [over] Volume 1 will be Works of Jules Verne: Volume 1; Understanding Physics [over] Volume I [over] Motion, Sound, and Heat will be "Motion, Sound, and Heat" and series Understanding Physics (1) unless the whole book is from a larger set of volumes then Understanding Physics: Volume I: Motion, Sound, and Heat" is also possible.
Omnibus if it contains really different works; if it was really a single work that was just split for publication, I will go with NONFICTION (if it is what it is) and use the series or notes to connect.
Different subtitles make variants IMO - being it for 2 vs. II or for lacking oxford comma in some cases...
When the same title means different book (aka volume 1 of 2 vs 1 of 3), notes become mandatory.
Not sure if continuity matters when I am thinking about sets and multi-volume sets. Although I am much more likely to make sure that the boxset which contains the part of a novel in volumes is added as a set as well than I would be for a 15-volumes set of novels/series/anything (which can be usually shown via a pub series anyway).
LCCN assigns a single number, OCLC assigns a single number for the whole run of a magazine and so on - we record publications... If we record these just as sets, we will rarely see verifications on them so I prefer the practice of adding the individual volumes (and if they have a slipcase and so on, add the whole thing as well). But that is a bit murky. Annie 13:22, 29 April 2022 (EDT)

Text stories in comics floppies

A lot of the older comics books have one or more text story in them - and these stories are eligible to be added here very often. What is the current consensus on the type to use for the book: non-genre anthology (because there are other stories from other authors which are not eligible - that maks their covers eligible under the current rules) or non-genre magazine issues (especially for the long running series of comics - covers here won't be eligible)? Any opinions? Annie 13:08, 29 April 2022 (EDT)

I'd vote for non-genre magazine issues: comic books that feature more than one item would typically be that (like 'Heavy Metal' for example). Christian Stonecreek 04:24, 30 April 2022 (EDT)
I agree. That seems to me to be the best treatment. --MartyD 08:54, 30 April 2022 (EDT)
I never really considered this to be a question and had already entered several Otto Binder prose stories appearing in Captain Marvel Adventures exactly as we are discussing (i.e. non-genre magazines). --Ron ~ RtraceTalk 10:47, 30 April 2022 (EDT)
Heavy Metal is a magazine and not a floppy though - thus the pause/overthinking for a second. Annie 13:50, 9 May 2022 (EDT)

(unindent) Magazines it is then. :) Annie 13:50, 9 May 2022 (EDT)

Other Prices

Mod added A, C, N.Z. to a note where I listed other prices for a book, then wrote a message on my board telling me that's the way I should do it. Leaving aside the fact that there's hundreds/thousands of edits I've made adding other prices in notes without those letters, it seems repetitive and unnecessary to me to add them when I enter the actual countries in the note. If it says Canada, what's the point of a C? Of course, the main price entered in the price field needs those letters, but notes are entered as particular editors want, in a whole range of styles. I'm particular about entering them exactly as in the book itself, whether it says Canada or Can., Australia or Aust., New Zealand or N.Z.; if a book actually has an A, C or N.Z. in front of the other prices then I enter them that way, but I'm sure most people here know that doesn't often happen. Not sure what the point of my note is, since I'm going to keep entering notes in my usual way, but it was suggested I open a discussion here, so that's what I'm doing. --Username 20:10, 4 June 2022 (EDT)

I've run across updates to currency in my notes once or twice, but never someone saying it's the correct way. I don't think the currency standard should be imposed in the Notes, Specifying the price as 25d in the notes if it matches the book would be more useful for comparing editions than forcing £0.25. I've used the change in foreign prices to differentiate editions. ../Doug H 23:52, 4 June 2022 (EDT)
Suppose you have a publication with $16.99 in the price field. In the notes it says '$19.99 in Canada'. It's ambiguous whether it's 19.99 US currency or $19.99 Canadian currency. If we use the same standard in the notes as in the price field, there is no ambiguity. John Scifibones 07:21, 5 June 2022 (EDT)
As a Canadian, I see no ambiguity in '$19.99 in Canada' being in Canadian dollars. More specifically though, if there is ambiguity, by forcing the C$, you remove the ambiguity, which, if it had another interpretation, you deny later readers. If you want to put C$, go ahead, but explain your reasoning - e.g. "Additional price given as $19.99 in Canada, taken as C$19.99". ../Doug H 09:22, 5 June 2022 (EDT)
Results of a quick search
  • Publications with a note containing 'Canada' and 'C$' 9,815 (46%)
  • Publications with a note containing 'Canada' and ' $' 11,501 (54%)
    • Clearly there is a difference of opinion among the community, at least in usage. My intention is to discuss whether a specific policy statement regarding currency symbols in the notes in necessary. If so, what should that statement be? John Scifibones 10:46, 5 June 2022 (EDT)
    Clearly there is a difference of opinion, as an unknown number of the C$ entries were mine and have been changed to include the C$. And I wish they'd stop. ../Doug H 15:31, 5 June 2022 (EDT)
    One thing to keep in mind is that we have FR 1158, "Allow multiple prices per publication". It's a fairly well fleshed out Feature Request as such things go and ready for implementation. Once implemented, it will eliminate most of the ambiguity. Ahasuerus 13:22, 5 June 2022 (EDT)
    P.S. Let me clarify that "ready for implementation" means that it doesn't need additional discussions for a developer to start working on it. I am currently supporting Al's server upgrade efforts while working on fixing outstanding bugs (6 fixed, 15 to go.) Once these two tasks are completed, we can regroup and re-prioritize FRs. Ahasuerus 13:40, 5 June 2022 (EDT)
    Prior to seeing this discussion, it never would have occurred to me to do anything but record the other pricing information as stated in/on the book. That said, it also would not have occurred to me to question a submission containing notes stating apparently normalized prices. I guess I never thought about data normalization standards applying to free text notes. One other example to think about is people's names cited in the notes: Wouldn't we expect those to be as they appear in the book, rather than normalized to ISFDB standards? --MartyD 07:40, 6 June 2022 (EDT)

    Strikethrough, superscript and other HTML outside of Notes

    We currently support "limited use of HTML" in Note fields. Typically, we do not use HTML in other fields, but Help seems to be ambiguous about it. Here is what Template:PublicationFields:Title and Template:TitleFields:Title say:

    • Fonts. Sometimes a title will have one or more words in italics, or in boldface, or in an unusual font. The ISFDB software would permit representing these via embedded HTML. However, this would mean that user searches that did not include the HTML would fail in many cases where they ought to succeed. Therefore, do not use embedded HTML to show font changes.

    The way Help is worded, embedded HTML seems to be disallowed only to the extent that it changes fonts. Help even states that the ISFDB software "permit[s] ... embedded HTML".

    I suspect that this is the reason why we have the following 3 title records with embedded "strikethrough" HTML:

    and one publisher record with embedded "superscript" HTML.

    Using embedded HTML outside of Note fields causes a couple of problems. The first one is the issue with searching which is mentioned in the Help paragraph quoted above. The second is the fact that our software can't reliably display titles with embedded angle brackets. For example, consider the following submission. The title of the story on page 69 appears to be "Adventures in Gaming". However, if you look at the underlying XML, you will notice that the actual submitted title was "<sarcasm> Adventures in Gaming </sarcasm>". The software interprets "sarcasm" as an HTML tag, which is why it's not displayed on the main submission page.

    Based on the above, I am thinking that it would be best to simply disallow all HTML outside of Note/Synopsis fields. If we do that, we will have to change just 4 records. Then I will be able to update the ISFDB software to display angle brackets as text -- as opposed to as HTML -- making it possible to display titles like "<sarcasm> Adventures in Gaming </sarcasm>" correctly. It would fix Bug 673, "HTML tags in titles", and Bug 279, "Titles with "<?" do not display correctly".

    Does this make sense? Ahasuerus 19:05, 15 June 2022 (EDT)

    It does make sense. Also, I believe that allowing HTML in input can be a potential security issue as javascript can be injected. I agree with your proposal. --Ron ~ RtraceTalk 19:31, 15 June 2022 (EDT)
    Indeed, JavaScript injection can be a serious security issue. However, we have partial protection against it because we had CSP (Content Security Policy) implemented a couple of years ago. If a malicious user creates a fake submission with embedded JavaScript, CSP will prevent it from being executed in any modern browser. Ahasuerus 21:08, 15 June 2022 (EDT)
    I am 100% on board with disallowing HTML for non-notes/synopses. However, are there any explicit rules or help text to cover how an editor should handle titles like the examples above? e.g. should they use appropriate Unicode special characters, or just vanilla ASCII? If the former (which is what I'd expect), could/should the transliteration field be used for such titles to have a vanilla ASCII version that - I suspect - would be more amenable to searching on?
    (Also, if the Unicode option is the one chosen, then it'd probably be useful to have a help page covering how to enter special characters e.g. linking to online tools like https://unicode-table.com/en/tools/strikethrough-text/ . I'll volunteer to write such a help page.) ErsatzCulture 19:55, 15 June 2022 (EDT)
    The 2 Help templates linked above have sections for "Symbols and punctuation". We should probably fold them into a single sub-template. Ahasuerus 21:03, 15 June 2022 (EDT)
    Hearing no objection, I have created FR 1510, "Disallow HTML outside of Notes/Synopses". Ahasuerus 21:45, 20 June 2022 (EDT)

    Title spelling

    There is a disagreement between me and another editor about the spelling of this title [ DAS GROSSE SPIEL]. The title is written in capitals on the cover, title page and back cover. This is not intentional but is often practiced by this publisher. In German there is no equivalent for the letter ß as a capitel, but the substitute SS. Without capitels the title of the book would be Das große Spiel. On the back cover, the publisher refers in an essay about the book the title as Das große Spiel. Is the title (not the transliterated title) of the publication finally Das große Spiel oder Das grosse Spiel. Regards Rudolf Rudam 05:22, 16 June 2022 (EDT)

    Generally, we change titles in all caps to standard capitalization. Das große Spiel would be correct. ···日本穣 · 投稿 · Talk to Nihonjoe 13:07, 16 June 2022 (EDT)
    Sorry, but I don't think that's stated anywhere in the rules: there the regularization rules are for case, symbols & punctuation, and some special signs (like #). Instead, the rules in this case allow and demand the appropriate use of upper & lower case for the single letters, and I don't see an allowance to interchange letters with others that aren't stated on the title page. (Note that 'case' is discussed in the help for single letters, and 'capitalization' only refers to the first letter of a word). Both spellings ('ss' and 'ß') are and were allowed for this title in German (that's so, because ß stands for ss). We also wouldn't have allowed two German versions for this author. Christian Stonecreek 13:22, 16 June 2022 (EDT)
    Please also take a look at the spellings with DNB and OCLC. Christian Stonecreek 13:42, 16 June 2022 (EDT)
    As you wrote, "the regularization rules are for case". That means regularizing (or standardizing) ALL CAPS titles to Normal Caps titles. Onces that title is normalized as far as case, then Das große Spiel would be correct. We'd do the same thing for any title that's in ALL CAPS. ···日本穣 · 投稿 · Talk to Nihonjoe 14:39, 16 June 2022 (EDT)
    And regarding Kurd Lasswitz, I suspect that name may have been used before we could use special characters in names and had a Transliteration field for the name. Looking down the list of works, "Kurd Laßwitz" seems to be the most common usage by far. The canonical name should be changed to "Kurd Laßwitz" for this author, with "Kurd Lasswitz" as a transliteration. ···日本穣 · 投稿 · Talk to Nihonjoe 14:42, 16 June 2022 (EDT)
    'Case' (the upper and the lower one) is used in the rules for single letters, 'caps' (which I take stands for 'capitalization') is used only for the first letter of a word. The both notions have different meanings. And please also refer to the added note of 'Das grosse Spiel' as stated with Deutsche Nationalbibliothek and OCLC; at least the first source should know what it does. Christian Stonecreek 00:26, 17 June 2022 (EDT)
    Where does it say that "case" is used only for single letters? I think you're trying to be too restrictive in applying it. And DNB has both große (at the bottom of the listing) and grosse, so we can't use them as an example. OCLC is definitely not a reliable source of information, either. Either way we decide to go, if we normalize the capitalization, we should use "große". If we choose to leave it in all caps (which I don't think we should do), it should be "GROSSE". ···日本穣 · 投稿 · Talk to Nihonjoe 12:22, 17 June 2022 (EDT)
    Disclaimer: Although my parents are German, I make no claim to any German fluency or educated background.... My naive opinion is that if both "große" and "grosse" are acceptable, even though SS is compelled in "GROSSE" because there is no capitalized equivalent for "ß", then we don't know if the intent was "große" or "grosse" and so we should default to "SS" -> "ss". On the other hand, if "no" (I know, nothing is ever absolute) native/fluent German writer would use "grosse" -- even though it is acceptable -- then it seems "SS" -> "ß" is appropriate and would be understood/expected. I'm not entirely convinced of that, though. If we consider, say "KOENIG" -> "koenig" or "könig", it seems right to insist on the "oe" even if "no" native/fluent German writer would use that instead of "ö". The difference, of course, is that because "Ö" is available, the choice of "OE" vs. "Ö" is apparently deliberate, for reasons unknown. --MartyD 18:34, 17 June 2022 (EDT)
    p.s. I do think for this specific case that if the publisher uses "Das große Spiel" elsewhere on the same publication, that is sufficient evidence of intent to use "ß" not "ss". My feeling is the default should be "SS" -> "ss" with "SS" -> "ß" permitted if known to be the intent (similar to the rule for "A. B." vs "AB" in an author's name regularization). --MartyD 18:41, 17 June 2022 (EDT)
    And regardless of which is used, the other should be in the transliteration field so those searching either way can find it. ···日本穣 · 投稿 · Talk to Nihonjoe 20:19, 17 June 2022 (EDT)
    Some general remarks regarding "ß":
    • A capitalized equivalent for "ß" had been discussed for many years and was introduced in 2008 as a Unicode character. Since 2017 it's officially part of the German spelling rules. Since 2020 a capitalized "ẞ" is the preferred way to write when using all caps in text and information processing: "GROẞE" instead of "GROSSE", but both forms are still allowed. However, it had already been used decades before every now and then. See https://en.wikipedia.org/wiki/%C3%9F#Development_of_a_capital_form or the German page https://de.wikipedia.org/wiki/Gro%C3%9Fes_%C3%9F I can't remember actually having seen it in publications I own, but the Wikipedia page contains some examples.
    • There's a distinction is the usage of "ß" depending on the German-speaking country: Switzerland and Liechtenstein never use "ß", but always "ss". Therefore Das grosse Spiel would be correct spelling in these countries.
    • In Germany-German spelling, Das große Spiel is correct. Surely, Das grosse Spiel will be understood by everyone as well, but I can't image why someone would write it like that in Germany. In school, you'd very likely get that marked as wrong in a grammar test.
    As for the publication in question and the rules:
    I think the fact that there was no capital "ß" for a long time and "SS" was used instead for all caps words, somehow as a "workaround", should not lead to wrong spelling when normalizing titles back to regular case. I don't know why DNB uses Das grosse Spiel, but I guess that's because of some (weird, probably now outdated?) library rules. For me, being used to Germany-German spelling, Das grosse Spiel looks utterly wrong (sorry, DNB and people from Switzerland and Liechtenstein :) ). Das große Spiel should be used.
    Jens Hitspacebar 07:02, 18 June 2022 (EDT)
    I understand the rules as to use the title on the title page, and then to apply the appropriate lower and upper case. So the proper use of case for 'DAS GROSSE SPIEL' leads us to 'Das grosse Spiel'. Right so far?
    I disagree. The help for "Title" says: "Titles should have case regularized according to language-specific rules". It doesn't say "just lowercase everything". If the uppercase version of "Das große Spiel" is "DAS GROSSE SPIEL", why shouldn't the lowercase go back to "Das große Spiel"? At least regarding grammar, "grosse" is wrong in Germany. As for DNB, see my other remark below. Jens Hitspacebar 14:19, 21 June 2022 (EDT)
    By our used definitions 'Das große Spiel' and 'Das grosse Spiel' are transliterations of each other: both are used on title pages, but in this case one alternative with only Roman letters in it was used. So with große/grosse we do not have a case of case here (please allow the wordplay), which seems to be the only regularization allowed, according to the rules. The letter 'ß' is a non-Roman one, and like Nihonjoe I'd be all for allowing 'Das große Spiel' into the field for transliteration. As for now the rule says 'Populate only if the title is spelled using a non-Latin alphabet/script'.
    And for DNB: Deutsche Nationalbibliothek is the reference source for German publications, and imo we should try not to deviate from it, except for obvious gross errors.
    'Das grosse Spiel' to me looks also more strange than the classic 'Das große Spiel', but as you, Jens, explained, the latter looked and looks more strange to many German writing people (in fact, millions of them), and I'd say nowadays both in general are almost equal in German: to me 'Ich denke, dass' still looks more strange than 'Ich denke, daß', but today the former is the only one in use. Christian Stonecreek 11:15, 18 June 2022 (EDT)
    You probably mixed up something, or misunderstood me: I didn't say that the grammatically correct "Das große Spiel […] looks more strange to many German writing people". I meant the opposite: "Das grosse Spiel" will look strange to most people in Germany. It's all quite simple actually, at least when focusing on grammar: "Das große Spiel" is correct in Germany, "Das grosse Spiel" is wrong. There may be or have been some other, special rules which are or were used by librarians and which led to using "grosse" at DNB. Maybe it's not an error and they really just lowercased "SS" to "ss" for whatever reason. Maybe this way is even correct in a librarian's mind. I don't know. But there are also many decades old pubs at DNB which use "große". DNB is not error free (I've seen numerous price errors there already). So… in the end the question is: does the phrasing "according to language-specific" in the rule mean known grammar rules, or does it mean (probably unknown) librarian rules? I'd go for correct grammar. Jens Hitspacebar 14:19, 21 June 2022 (EDT)
    Retrieved from "https://isfdb.org/wiki/index.php?title=Rules_and_standards_discussions&oldid=636523"