ISFDB:Community Portal/Archive/Archive48

From ISFDB
< ISFDB:Community Portal‎ | Archive
Revision as of 03:14, 14 May 2020 by Nihonjoe (talk | contribs) (archive Jan 2020)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This is an archive page for the Community Portal. Please do not edit the contents. To start a new discussion, please click here.
This archive includes discussions from January - June 2020

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

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


Echopraxia - Peter Watts - 1st Tor edition cover

I have a problem with the cover scan here. Using Amazon's Look Inside (the 'Print Book' tab) here [1], one can see the different text placement.

The question is, which cover is 'right'? Thanks, Kev. BanjoKev 10:06, 1 January 2020 (EST)

Our record is primary verified by three people. I would assume one of them would have noticed if the record has the wrong cover. The uploaded cover was scanned by one of those verifiers and it looks like a scan of the book itself (there is some distortion on the right that is consistent with curve of a dust jacket). It's possible that there are two different versions of the cover. If you click on the Amazon listing for the tp, you will also see a third location of the text. Basically, I would trust the verified version over the Amazon versions (even with Look Inside, there can be differences between the samples and the real versions). If someone actually has a h/c with another cover, a new record can be created at that time. -- JLaTondre (talk) 10:22, 1 January 2020 (EST)
Thanks. The existing PV'd cover is the same as the OCLC/Worldcat # cover that Bluesman SV'd and that Hauck uploaded 9 days later. So that checks out ok.
This raises the validity of the Amazon version (or any Look Inside data, for that matter). Do you mean that Amazon versions are to be treated as 'not real' as in they may be pre-publication scans/data files they get from the publishers. Please explain. (I do understand that information obtained from Look Inside should be noted as such in publication Notes)
This whole enquiry line started because I have the Head of Zeus 1st printing (which I've started to edit here with only cover scan and OCLC/Worldcat check so far).
In this printing are the following contents, as I would wish them to appear.
  • 13 * The Crown of Thorns: External Layout * (2014-08-00) interior art by Peter Watts [as by uncredited]
  • 15 * Echopraxia * [Blindsight / Firefall * 2] * (2014-08-00) * novel by Peter Watts
  • 358 * Echopraxia Notes and References * (2014-08-00) * essay by Peter Watts
The interior art and essay are referenced in the Notes here - only the once amongst the Echopraxia titles, but not given in the Contents there. The page numbering Wjmvanruth notes for them is exactly as in my printing. The Essay is given in the Contents for all three Firefall titles.
So... at present, we don't have any Contents-listed original publishing dates for either the interior art or essay, despite a version on Look Inside that tells us that Tor did publish them in 'some version' of hc and that, according to my Head Of Zeus 1st edition, HoZ reproduced the whole book with the same page numbering as Tor. Hmmmm. Kev. BanjoKev 15:02, 1 January 2020 (EST)
Quick note: confirming that essays between Echopraxia and firefall pubs are the same (or not) can easily be confirmed by having PVs comparing text (fragments). MagicUnk 17:38, 1 January 2020 (EST)
Regarding your question on Amazon Look Inside: I have seen differences between the Look Inside and the physical book before. I know the Look Insides are provided by the publisher (for physical books; for Kindle versions, I would assume it's a preview of the actual Kindle file). I assume in these cases the publisher provided a softcopy to Amazon, but than made changes before printing. Don't know for sure. In my opinion, if we have a verified publication, I would not create a new publication record based on a small delta like this unless there is something in the Look Inside that indicates it's a new printing / edition. If we didn't have a primary verified pub, I would say update the record to match the Look Inside (with the appropriate pub notes on source) as the vast majority of the time the physical version and the Look Inside are the same. -- JLaTondre (talk) 08:38, 3 January 2020 (EST)

Mechanismo & Wyst: Alastor 1716

Hello Biomassbob, Willem H., Stonecreek. Rather than posting on each individual's talk page, I thought I'd post my question here :). The Glossary for Mechanismo is recorded as SHORTFICTION. However, we generally record glossaries as ESSAYs instead. Could you check your PV'd copies and confirm that indeed it should be recorded as an ESSAY, and adjust the record accordingly (and if it really -is- a short story, add additionally clarify in the title's notes)?
Same for Jack Vance's glossary for Wyst: Alastor 1716 Thanks! MagicUnk 06:23, 2 January 2020 (EST)

I have added notes to each of these glossaries substantiating why they are appropriately considered SHORTFICTION, rather than ESSAYS. Neither is a short story, both are a series of very short stories. The Wyst section establishes the basis for the three books in the Alastor series; the Mechanismo glossary writes very short stories about each artwork in the pub, so far as I know original to this volume. Bob 14:35, 2 January 2020 (EST)
Thanks! I noticed you typed "Glassary" here - I assume that's a typo? :) MagicUnk 06:47, 3 January 2020 (EST)
I agree with Bob. We have a help text here under SHORTFICTION and ESSAY explaining it's the choice of the editor which type to use. If we use SHORTFICTION, no lengte is assigned, to indicate it's not a story. --Willem 14:42, 3 January 2020 (EST)
And so do I. Thanks for clarifying, Bob! Christian Stonecreek 15:03, 3 January 2020 (EST)
Fixed glassary. I'm well known for my many typos (sadly). Bob 21:53, 4 January 2020 (EST)

FR 794 Add a 'printing' field to publication records

As requested at Rules and standards discussions#Date Precedence with '00' Dates by User:Ahasuerus, here is a Community Portal discussion about this feature request.

I personally am of the persuasion that we want such a field and it need not be a numeric field and instead a general text string is probably the best. I also believe we should include some useful Help/advice about how it should be used. I believe we want a "stated" revision/printing/issue type of value that can be used as a supplement to date since in many cases there is no stated date for specific printings.

In the case of assumed printings we might be able to use to same field, however, there should be very good reliable source for such an assertion otherwise it is just noise and would be better in the note if anywhere.

—Uzume 17:35, 3 January 2020 (EST)

We could also add some sort of print/issue rank typing field to go with this allowing one to select "via statement", "via number line", "assumed; see pub note for evidence", etc. I recommend the issue rank type field be limited in value much like format and pub type are.

I believe this could be useful for simplifying reprints of magazines as well (instead of creating new editor title records and new series).

—Uzume 12:51, 6 January 2020 (EST)

I have reviewed the FR and prior discussions. My take on what is achievable is as follows:
1. The use of a 'printing' field would be the visualization of what printings are already in the database, thus avoiding duplicate pub records by mistake, and a quick way to see which printings are still missing.
2. It is to be used to sort pub records (date, publisher, printing) - note that the 0000-00-00 records must be sorted separately from the dated entries to ensure they are appended at the bottom of the list (ie sort dated records UNION sort unknown date records - if memory serves :). Imo with the available information in the pub records there's no algorithm that can interweave the undated records into the dated records in a way that makes sense, so the UNION is the best we can do.
Some thoughts:
  • To ensure proper sorting, the printing field must be numeric; alphanumeric field would allow for erroneous entries such as a 1st printing pub record having 'A' as printing rank, and a 2nd printing having '2' as printing rank would be sorted '2' first, then 'A' while it should have been the other way around - actually, I can't think of an example where a non-numeric printing would be required?
    • Even if 'as printed' alphanumeric printing rank exists, I suggest to cover a conversion to numeric sequence in the rules
    • Related to that, the printing field cannot hold 'as printed in the book' values, because what to do with number line? Copy it over into the printing field because that's what's on the copyright page? It would make the pub list unreadable very quickly. Better to only copy over the number (ie second printing by number line translates from 3 5 7 9 10 8 6 4 2 to simply '2', for example)
  • At least for (recent) UK/US/... publications, this approach would work quite well, as it'd be a simple translation of the number line.
  • Dutch titles are notorious for maintaining printing sequence across editions (even across publishers) - at least for me, having a printing field would make it much easier to manage all these different printings. A numeric printing would work for the Dutch case equally well.
    • What about German, French, other languages? Would a numeric printing field work? (and if not, why not?)
  • If we don't have a copy of the book, or the book doesn't have the printing info, we have to allow for secondary sources: again for the Dutch case, a quite reliable source of printing information is the Dutch Bibliography (PPN) - see Het zwaard van Shannara for an example
  • Not a fan of an additional rank 'type field' - this info is better recorded in the notes imo
  • I believe the above covers what Uzume requires - except perhaps for the 'as stated' and additional 'rank type' field parts.
I for one would love to see a 'printing' field implemented rather sooner than later :) Thoughts? MagicUnk 13:02, 6 January 2020 (EST)
Something else: it -is- possible, and must be allowed, to have the same printing rank multiple times, if that's how it's stated in the publications - see comments in FR 794 for examples. To be clear: I am not advocating to have a printing rank derived by the editor: it should be as stated in the book (numericalized), or if not available, from 'reliable' secondary sources such as National Bibliographies MagicUnk 13:36, 6 January 2020 (EST)
I do not see the value in forcing a "numericalization" of issue/print ranks. What is the numerical print rank in a magazine issue reprint? How does one "numericalize" the print rank of a Japanese or Chinese book with a stated printing of some kanji character which may have no conceivable ordering (e.g. 下 is a common character meaning "down" and is sometimes used for ordering but its numerical value would not be able to be created in a straightforward way as it often just means "last"). String values can be sorted without any problems and forcing editors to come up with numerical values does not seem to add much value beyond attempting to keep people from entering random garbage. This is what submissions and moderation is for. I would advocate moderator warnings on submissions with print ranks we do not expect.
It should not be difficult to add a cleanup report looking for pubs with the same publisher, date, and format, etc.
—Uzume 15:43, 6 January 2020 (EST)
First, let's agree on what the print rank is intended for: to be able to sort printings with 'same date-same publisher' (which would include the 0000-00-00 case), AND, to convey (from the title screen) which printings are already in the database. On second thought, doesn't have to be converted to an (integer) number per-se, provided the sorting functionality can still be achieved, preferably in a consistent manner (to be supported by rules on how to obtain/derive/enter the print rank to ensure sorting is not thwarted). And to refine my earlier statement: print rank -can- be derived provided there's no actual printing information in the book itself and if certain criteria are met (see below). Or if available then the 'as-printed' info must be recorded (with allowance for an abbreviated 'numericalized' notation, such as number line --> single-digit print rank).
Are we all agreed that that is what we want to achieve/use them for?
BTW, and to be clear, I still think the 'numericalization' is the least error-prone approach imo as it would guarantee that I can achieve what I want, as illustrated below.
Second, to your examples, can you elaborate please? I am unfamiliar with magazine re-issues to fully understand what you are trying to say. Any actual examples? As far as I can see, there are two possibilities:
1. A. there is a first print run (and gets distributed), and then a couple of days/weeks/months later, there's a second print run of the same issue (and that gets distributed too). Provided there's information somewhere on or in the magazine to discriminate between the two, they would get (a derived) 1st and 2nd printing, respectively.
B. If we can't distinguish at all, the best we can do is add notes to clarify that there are, in fact, two print runs, and record them as 1st print run only (even though they have been printed separately). Or just leave the printing field blank and add a note to clarify, as no useful print rank information can be conveyed anyway - this would have my preference. Or
2. the re-issue is, in fact, a totally different edition (such as e.g. facsimile re-issues of classics many years after the original). For this case I would argue they would be different in more ways than simple print runs - they would likely have different publisher and/or different printing dates and/or different finish (e.g. glossy vs. cheap paper), and so on. These are different publications, each with a (derived) 1st print-run. For this case I wouldn't even bother entering printing number as they'd be clearly distinguishable anyway (but you could if you wanted to).
As to the Japanese/Chinese example; my understanding of what you are saying is that you can have several print runs (presumably potentially with different printing dates?), all with the same print run information (ie. the character 下 in your example). Again, two possibilities I can see:
1. if there's no additional information on or in the book or anywhere else to otherwise discriminate between print runs, then don't bother entering a print rank (indeed, what's the value of recording 'last' multiple times? I don't understand what it means in context of print-runs?) I.e. barring additional information to allow to discriminate, we're stuck. If there are dates, then fine, sorting will sort itself out :). Or,
2. if there -is- additional information on or in the book that allows to distinguish which print-run was first, we'd record the derived print rank (and clarify in the notes, as appropriate).
As I believe that you propose to restrict to only record 'as-printed' printing information, you wouldn't be able to sort nor convey what print runs are already in the database, while deriving a ('numericalized') print rank could. Or am I misunderstanding you? If so, can you detail what your proposal would entail and how it would work, perhaps with some use cases? MagicUnk 05:57, 7 January 2020 (EST)
There is one other wrinkle to the "numeric vs. non-numeric values" debate. I vaguely remembered that many Russian publishers handled printings differently, so I decided to check FantLab. According to this FantLab record, the 2001 edition of this novel had the following "additional printings":
  • 2002 - 10000 copies
  • 2003 - 10000 copies
  • 2004 - 20000 copies — АСТ (ISBN 5-17-008498-6), Люкс (ISBN 5-9660-0229-0)
  • 2005 — 15000 copies — АСТ (ISBN 5-17-008498-6), АСТ Москва (ISBN 5-9713-0621-9), Транзиткнига (ISBN 5-9578-2901-3), Харвест (ISBN 985-13-5169-5)
  • 2006 — 20000 copies — АСТ (ISBN 978-5-17-008498-2), Транзиткнига (ISBN 978-5-9578-2901-0)
These "additional printings" were apparently not numbered. Moreover, some were associated with multiple ISBNs because they were published by different imprints of the same publisher (АСТ). Are they really "printings" as we understand them? If they are, can we assign sequential numbers to them even though they are apparently not numbered by the publisher? If we do, will the four different 2005 ISBNs share the same printing number (5)? Ahasuerus 18:55, 6 January 2020 (EST)
They are printings in the same way as the US numbered ones are. They may have different covers and/or copyright pages to account for the added ISBNs and some of them switch ISBNs completely but they are printings - the Bulgarian books have the same logic. The problem with adding sequential numbers is that as they are not numbered, a missing one may be identified later on if we grab data from an incomplete entry -- thus messing up our numbering. So if we are sure of the data, we can add numbers (and I had added to some books); but if we are not, there is a chance that there is a missing number somewhere in between... And the year is not always enough either see this one which has 3 printings in 2006 alone. Annie 19:19, 6 January 2020 (EST)
Agree that this is a potential source for erroneous data entry if somehow you've missed a printrun in-between. Annoying for sure, but I don't see how we can prevent this from happening. However, I believe it's not such a big an issue since once the missing in-between printrun is discovered, it is easy enough to insert the new one with its (numerical) printing (assuming we go with that), and correct the other printings accordingly. The only non-trivial (corner?) case is where you have the same year (as in Annie's example). Barring additional information (such as perhaps month/day somewhere else? - Annie, is there a way to discriminate the order in which these 2006 runs were printed?) there's no way to disambiguate. Recording these ambiguous cases with the same printing, accompanied with a note explaining the issue, could be a possibility - after all, if recorded this way, sorting would still be correct (ie all 2006 runs are below each other). Not perfect, but it would work for our purposes, no?
And if there would be no date (ie for the 0000-00-00 case) we're stuck, and we'd have to leave the printing field blank. (but hey, no printing information is also information :) Anyway, I wouldn't want this case to prevent us from having a printing field :). MagicUnk 05:57, 7 January 2020 (EST)
Russian (and Bulgarian) printings always have an associated "signed for printing" date with them - I think that most of Eastern European books had that at least last century. Not easy to find without the book at hand sometimes but they always exist. It is not the Depot legale of the French but it is usually enough to separate the printings. So the 3 2006 printings are easily separable based on that (when you do not have a better way - more or new ISBNs, separate printer and so on). And later printing often list the previous ones (often being the imperative word).
I still do not feel comfortable us assigning a number based on an incomplete set of data. If we call something second printing, it means "second printing" and not "second printing we know of but we had not done much of a research". We need to be able to stand behind our data and while changing the numbers is easy, knowingly adding incorrect information just so we can make up some numbers is... bad. If we want to have system generated numbers (printing we know of), we can discuss that but mixing genuine numbered printings with "printings we know of" devalues our data. Which does not mean that we should not have the field - just that it needs to be non-numeric. And once we have it, coming up with standards per language/country for the ones we know do not number is not that hard. Bending some data to conform to another country's publishing practices is a bad idea - just witness how long it is taking us to get untangled from the US focus of this DB - while multiple ISBNs and publishers are almost unheard of in this set (or were...), they are common in Russia/USSR; same with multiple prices in the Western European world.
One option may be to have a radio box: Numbered/unnumbered printing which then either allows only numbers (for properly numbered printings) or free text (for the rest). :) Annie 11:49, 7 January 2020 (EST)

(unindent) Hi Annie, my examples above are just that, examples. While I believe the mechanisms explained to obtain derived printing ranks can be useful in certain cases, they by no means are to be considered given, and in any case must be applied judicially. I would never advocate not to be thorough :) but mistakes are made... It also looks like the discussion is crystallizing out towards a consensus to have a non-numerical printing field, supported by a case-by-case set of rules to apply, probably per language and/or country to be able to accomodate the varied practices out there. This supporting rules' set is then something that we still need to continue to build, as you suggest. In any case, while I remain in favour of a purely numerical field, I have no fundamental problems with using a non-numerical field. On a slight tangent, I haven't seen any examples on how to record the specific cases showcased above. For example, I'd be curious to know how you and Uzume'd envision practically recording the magazine, the Chinese/Japanese, the Russian/Bulgarian, and other practices. Cheers! MagicUnk 13:41, 7 January 2020 (EST)

That will depend a lot on what we decide to do exactly -- how many fields, will we distinguish between derived and stated and how in a separate field and so on. The note above was explaining why a number won't work outside of the numbered practice. And there is another thing to be careful about - where we want to show these. Number only ones will fit almost anywhere (and will be very useful in the pub table under the title for example); the text ones will make that table unmanageable. We may also decide to just ignore the new fields for cases where printing is not well defined. Blocking everything while we find all possible corner cases and agree on all rules had (and would) never worked anyway. I am also just fine not recording the Bulgarian/Russian ones outside of the first in the new fields - if anything, we need the multi-publishers/multi-ISBNs for these a lot more (but that is a different conversation). :) Annie 14:09, 7 January 2020 (EST)
Welll, numbers -will- work outside of the numbered practice provided there's sufficient information available so that a conversion algorithm can be applied and yields unambiguous results. If not, then the numbers will be undetermined and remain blank. We can do that :) There's not really a conflict there and I agree with what you're saying that you can decide not to enter printing information or choose not to (or not required to) apply any conversion. That leads to your suggestion to use an 'as printed' field, next to a derived (numerical) printing field (IIRC this has been suggested in the past too). In that case we would be better off naming the latter 'sorting field' then(?). Ie two fields, which can have the exact same information in case of the numbered practice. That still doesn't answer which of the two (or both?) we'd want to display on what screen(s). So, what about only displaying the 'as printed' field, but with a limited width, say, 10, 15 positions at most, and sorting on the not-displayed sorting field. Would that work for the pub list? Drawbacks? Cases where it wouldn't be workable? (one thing we have to be careful about is that we have to make sure that the solution we end up with remains workeable, ie that data entry does not become too much of a burden to the point of untenable for the editors. Likewise, as you're saying readability is important too ...)
As for sorting in the case of having these two fields, sorting could be done as follows: sort on the 'sorting' field by default, and if for some pubs that field is left blank, use the value from the 'as printed' field. If both are blank, well these records end up at the bottom of the list (not sure if this is clear enough, but it'd be something like SORT(IF sortingField ISBLANK THEN asPrintedField ELSE sortingField) (btw, this approximates your radio-button suggestion :) MagicUnk 15:47, 7 January 2020 (EST)
Any reason not to use a single field that does the same thing the page field currently does (allow any needed text entry with a piped sort). It would keep things consistent. -- JLaTondre (talk) 17:22, 7 January 2020 (EST)
Euh, I'm lost... what do you mean with a piped sort?! Can you explain what you mean by that? Thanks! MagicUnk 11:53, 8 January 2020 (EST)
There are two things here: what we record/show and how that relates to sorting on lists. The sorting can be done via a pipe: so the 3 2006 printings above can have strings such as "2006.1|First 2006 printing" for example. That way you define both how it sorts and what you show at the same time - like we do with pages. Annie 12:07, 8 January 2020 (EST)
See the "Sorting" section of Template:PubContentFields:Page, which discusses the uses of the "pipe" character, for details. Ahasuerus 12:31, 8 January 2020 (EST)
Aaah, yes. Got it :) Fine with me MagicUnk 13:30, 8 January 2020 (EST)
Works for me. Annie 17:34, 7 January 2020 (EST)
Showing how a scheme works for particular examples sounds like a good idea. Can someone explain how you would enter priting/sorting fields for these five printings (of many) for Tarzan of the Apes? 1st (US), 1st (CN), First Special Printing, 13th printing (precedes Special printing), 14th printing follows Special printing. ../Doug H 13:10, 8 January 2020 (EST)
To answer Doug's question: If we assume we sort on date, then publisher, then printing, we wouldn't be able to reorganize the way you requested with the '|' symbol because date sorting takes precedence. In other words, since the dates are all different (except for the first two) the sort order can't be changed - and we even wouldn't want to! (btw, are you sure 13th printing precedes special printing? If so, the current printing dates are in error). So, if you want to sort the first two (wanting the US first), you could enter something like this:
First Printing: July 1963 | 1 (US)
First Printing: July 1963 | 2 (CN)
First Special Printing: January, 1976
Thirteenth Printing: November, 1976
Fourteenth Printing: December 1977
If you would enter something like this
First Printing: July 1963 | 1 (US)
First Printing: July 1963 | 2 (CN)
Thirteenth Printing: November, 1976 | 3
First Special Printing: January, 1976 | 4
Fourteenth Printing: December 1977 | 5
You would still end up with the same ordering displayed for the printing info, like this:
First Printing: July 1963 (US)
First Printing: July 1963 (CN)
First Special Printing: January, 1976
Thirteenth Printing: November, 1976
Fourteenth Printing: December 1977
Again, this is assuming that the piped printing sorting is applied only after sorting on date, then on publisher. Note that this outcome is as expected (date sorting first). Maybe Ahasuerus can chime in with details on alternative implementations of the pipe sorting (as I'm not sure exactly how the current page piping is coded)? MagicUnk 13:09, 13 January 2020 (EST)
One thing to keep in mind about the "pipe sorting" of page numbers is that "pipe" numbers can include decimals. If we decide to use the same algorithm for the proposed "printing" field, we'll be able to use "|1.1" for the first US printing and "|1.2" for the first Canadian printing.
That said, I am still thinking of the best way to capture and display printing numbers. The discussion above suggests that if we continue to sort publications by date, a "printing" field would only change the way we sort publications with the same publication date. In most cases it would be limited to 0000-00-00 publications.
However, sorting issues aside, there is also value to simply displaying the printing number on the Title page. Consider Devon Monk's Magic to the Bone. We have publication records for 4 printings of the mass market paperback edition published by Roc. You have to check all 4 to discover that there have been at least 5 printings and that we are missing the 3rd one. Having the printing numbers displayed on this book's Title page would be very useful, sorting issues aside. Ahasuerus 15:24, 13 January 2020 (EST)
Yes, exactly! :) One thing I've been thinking is that there's no real need for sorting on publisher at all. It should suffice to sort by date, and then by the piped printing (which would, indeed, mostly be relevant for the 0000-00-00 case only). I'd like to have input on:
1. what would be the maximum workable width of the printing field before its contents starts to wrap?, and,
2. in most 'special' cases as discussed above we can go with 'as is printed in the book', but what should we do with the line number in US/UK pubs? Would we be copying it as-is in the printing field (which isn't helping readability), or would we go with 'abbreviating' it to the number only and enter that? We'd need some standard so as not to get an ugly mess of one editor handling line number one way, and another a totally different way for the same title (need to be consistent within a title, not necessarily so across different titles, eventhough that'd be preferred, of course)... MagicUnk 16:52, 13 January 2020 (EST)
I'm happy to see the sorting drop aside. So for the Tarzan examples (pardon my date ordering of the special), I'd go along with (and actually prefer) to make the printings numerical where possible (e.g. 13 vs. Thirteenth). Some considerations for explaining the use of the field should cover a) distinguishing variant printings (e.g. 1 Canadian and 1 US / USA / America / U.S. / U.S.A. / United States / ...) and reuse of printing numbers (e.g. 1 Special / Special 1). ../Doug H 08:33, 15 January 2020 (EST)

Magazines can sometimes be reprinted years later. Since we treat magazines as editor title series (instead of pub series which I believe is a better method; I am not advocating removing editor records or their series), we sometimes see our records in strange organizations like: Amra - 1959 and Amra - 1959 (facsimile). Amra, Vol. 2, No. 2 did not get re-edited from Amra V2n2, March 1959 or even from Amra V2n2, March 1959. The reason someone did that was to help disambiguate between this reprint and the earlier printings (because different editor title records can be in different title series). Using pub series would solve this issue but using a pub record print ranking type of field could also help by allowing a causal viewer to explicitly see in the title record view that certain pub records are tagged with some sort of reprint designation. I believe this field can provide more than just sorting among pub records with the same/indeterminate dates, but it provides a title viewer a better overview of pubs of a specific title. I am not sure it is applicable in all cases but I am not against using a "piped" field type to provide a visual value as well as a sort key value. It also has potential benefits for searching (trying finding a succinct listing of all the first reprintings of the Amra magazine). With such a field, we could at least find such a listing via a search (although switching to pub series for magazines would have the benefit of also having separate issue grid potential). —Uzume 17:01, 15 January 2020 (EST)

URLs associated with "New Record" submissions are now hyperlinked

All URLs associated with "New Record" (New Publication, Clone Publication, New Award Category, etc) submissions are now clickable on submission review pages. Ahasuerus 20:50, 5 January 2020 (EST)

Thank you! -- JLaTondre (talk) 20:35, 6 January 2020 (EST)

Pub record replace titles

I am not sure if this is highly coveted/useful or even how difficult it would be to write/merge/create, however, I often find myself needing to replace titles, meaning both removing and adding (aka import/export content) titles at the same time. Currently the software does not allow this and more than a single submission is necessary to articulate the procedure. I wonder how complex would it be to merge:

  • edit/rmtitles.py
  • edit/clonecontent.py

This might also affect:

  • edit/importcontent.py
  • edit/exportcontent.py

More generally, it might also be possible to add this directly to:

  • edit/newpub.py
  • edit/editpub.py
  • edit/clonepub.py

Which might also affect:

  • edit/clone_intermediate.py

I think it might prove useful to unify all the pub title content editing controls into a single place.

So do you think this sounds useful to you and is not too crazy and daunting? I am looking for feedback (including perhaps better ideas) before submitting a software feature request. Thank you. —Uzume 12:07, 6 January 2020 (EST)

So you are looking for a way to combine "Remove Titles" with "Import Titles, Option 2"? What about the rest of the possibilities (the ability to import a complete other collection for example - Option 1 of the import (import all from a pub))? And do you also envision having the ability to manually add more titles (as you can with Import but cannot during a remove)? And what about cloning? Is the idea to be able to clone and replace/remove during the cloning process itself?
While I would love to be able to import, edit and remove from a single screen, unless we are covering all the options (basically bringing these 3 to a single page), I find them more intuitive as separate options. Annie 12:58, 6 January 2020 (EST)
I am not sure it matters. I was considering both options. As it is, both options have the same "clonecontent" backend. I am proposing to merge the backend with "rmtitles" or better yet with "newpub", "editpub", and "clonepub".
For example, we could have a editpub.cgi?ExportFrom=<pubid> or editpub.cgi?ImportTitles1=<titleid>&ImportTitles2=<titleid> in a similar fashion as we now have with clonecontent.cgi. Further the existing titles could have checkboxes next to them to have them removed much like rmtitles.cgi currently does. "newpub", "editpub", and "clonepub" could have form boxes to apply such form parameters to themselves and be reloaded or something similar to avoid the necessity for separate entry forms like "importcontent" (we could still have those if such things were useful and clearer of course).
—Uzume 14:14, 6 January 2020 (EST)
Could you please rephrase the idea in functional terms? Much of what you are suggesting describes proposed technical implementation details, which are meaningless to most ISFDB editors. Ahasuerus 18:08, 6 January 2020 (EST)
Well I was proposing it in steps merging backends (because it might very hard to design and make all that work in one go) but the ultimate goal would be a single pub editor that can do what it does today as well as adding and removing titles. This would work for newpub, addpub, clonepub, editpub and effectively including the functionality of removetitle and import/export content. Is that functionally simple enough? —Uzume 19:48, 6 January 2020 (EST)
Implementation difficulties aside, I suspect that moving the "import titles", "remove titles" and "import from a publication" functionality to the Edit/Add/Clone/New Publication page would make the consolidated page hard to navigate. Ahasuerus 16:05, 7 January 2020 (EST)
Perhaps but that could be improved with better UI improvements, but it would also make it *much* easier to navigate if you consider how many times one has to navigate multiple submissions of different types with different interfaces and then hope that a mod approves them in the right order and/or wait for approval before making the next change (and that is if the mod doesn't notice the need and then go about attempting the change it by his/herself...sometimes incorrectly because they did not investigate things the same as the original editor that made the submission did). —Uzume 17:10, 15 January 2020 (EST)

Blocking "Add Publication to This Title" for certain title types?

Why are we blocking addpub.py for certain title types. For example why is this "not supported":

It seems like most people would want to add pub record issues to magazine editor title records. Why am I required to add a new magazine (including new title) and then subsequently merge the extraneous editor record that results from that?

According to edit/addpub.py, the currently "supported" title types include only: 'NOVEL', 'COLLECTION', 'OMNIBUS', 'ANTHOLOGY', 'CHAPBOOK' and 'NONFICTION'. Thank you.

For context, I did some searching and this goes back to CVS edit/addpub.py 1.20 and FR 446

I am assuming it is somehow related to this outdated Help:Screen:AddPublication that states one cannot change the contents during the add.

—Uzume 14:20, 6 January 2020 (EST)

Thanks for the heads-up re: Help:Screen:AddPublication! I have updated the text to reflect the way the software works in 2020.
Re: the main question, there are three deactivated fields on the "Add Publication to This Title" edit form: "Title", "Author(s)", "Pub Type". It works well for book titles, but magazines are a bit different. The Title field would need to be activated because MAGAZINE/FANZINE publication records and EDITOR title records use different naming conventions, e.g. "New Worlds, #3 (October) 1947" vs. "New Worlds - 1947". The "Pub Type" field would also need to be activated because EDITOR titles are used for both MAGAZINE and FANZINE publications.
Other than that, I can't think of any reason why we couldn't make "Add Publication to This Title" work for EDITOR titles. Ahasuerus 17:44, 6 January 2020 (EST)
Cool, then perhaps we can get an FR to reenable all the other missing title types that addpub used to work years ago before FR 446 broke them in late 2015. Or maybe this would be better as a bug since it used to work and was broken. —Uzume 20:06, 6 January 2020 (EST)
I can see how the ability to "Add a Publication" to an EDITOR title could be useful, but we have to be careful with other title types. Early on, the software let you "Add a Publication" to SHORTFICTION titles, which caused problems. Similarly, adding a publication to a POEM, ESSAY, SERIAL, REVIEW, INTERVIEW, COVERART or INTERIORART title wouldn't work too well. Ahasuerus 15:23, 7 January 2020 (EST)
Well, if we can somehow make "Add Publication" on a short story/poem record create a chapbook record, that will be very useful actually - especially with all those never before reprinted story that keep popping up and with more and more authors making their stories available outside of collections. I'd argue that it will used a lot more than adding a publication to an EDITOR. :)Annie 17:39, 7 January 2020 (EST)
I can see how it could be useful, but there is a catch. A regular "Add Publication to NOVEL/COLLECTION/etc" submission creates a new NOVEL/COLLECTION/etc pub record and links it to an existing title record. An "Add Publication to SHORTFICTION/POEM" submission would not only create a new CHAPBOOK pub record and link it to an existing SHORTFICTION/POEM title, but it would also create a new CHAPBOOK title and link the pub to it. That would be a significant change to the option's functionality.
Perhaps it would be better to create a new option, "Create a CHAPBOOK publication for this title", which would only be displayed for SHORTFICTION/POEM titles. It would help address the issue that we had back when "Add Pub" was available for all title types: editors often tried to use it to "add" collections/anthologies/magazines/etc to SHORTFICTION/POEM/ESSAY/etc titles. Ahasuerus 13:29, 8 January 2020 (EST)
Yeah, that works as well and makes sense - as long as we do try to do something. AddPub is easily replace-able with ClonePub when we have at least one publication anyway so I rarely use AddPub (I use it mainly when I am adding the first pub to a pub-less parent for example) but I can see how it can get confusing if we add it back to the Short fiction and poem types (and SERIAL... let's not forget SERIAL) :) Annie 13:45, 8 January 2020 (EST)
It sounds like we need two separate FRs then, one for adding pubs to EDITOR titles and another FR for adding chapbooks to SHORTFICTION/POEM/SERIAL titles. Ahasuerus 19:47, 8 January 2020 (EST)
Yep - probably better to keep them separate. Annie 19:50, 8 January 2020 (EST)

(unindent) FR 1331 and FR 1332 have been created. Ahasuerus 14:27, 13 January 2020 (EST)

I definitely think CHAPBOOK from "non-container" title type option should have different naming than the original "Add Pub". I do not see why we could not allow all other pub types as well, however, as these would essentially just be create new pub with a prefilled title "export" to the new pub in a single edit/submission. I am already advocating for merging new pub/edit pub, etc. with title imports/exports. —Uzume 17:26, 15 January 2020 (EST)

Alphabetical author order -- wrong preposition?

I was looking at something else and noticed that we use a different preposition (and view) in the alphabetical order compared to the Chronological. See the chapbooks here. The ones that say "with Conrad Shepherd" are actually "AS Conrad Shepherd" and why do we show them separately anyway (compare to the chronological view where they are in the usual "only by" format. It is not just the chapbooks - but it is easily visible with them. Am I missing something that we are trying to achieve here? Annie 16:45, 7 January 2020 (EST)

That would be Bug 491 :-) Ahasuerus 18:38, 7 January 2020 (EST)
Any plans on getting it fixed one of those days? Because this is beyond ugly - not to mention that it is the only interface that actually shows the data differently. This one looks even uglier... :) If the Chronological list keeps the variants under their parents, why does the alphabetical one flattens them - I would expect the two lists to be exactly the same, with the order changed... Annie 19:23, 7 January 2020 (EST)
It's the single biggest bug left in the system. Unfortunately, I need to massage the way author pages are built -- without messing up anything else -- in order to fix it. I didn't want to tackle it while I wasn't feeling well, but I may be in good enough shape to try it this month. I'll see what I can do. Ahasuerus 22:25, 7 January 2020 (EST)

Publications with Wiki pages

The cleanup report Publications with Wiki pages has been adjusted to work with the new "Publication Web Pages" multi-field. Once the nightly job runs at 1am server time, I expect the number of flagged publications to go from 236 to 295.

As we discussed 10 days ago, some Wiki-based pages for existing publications (like this one and this one) will need to be folded into regular Note fields. When this report is out of the way, we can re-assess where we are and create additional cleanup reports.Ahasuerus 21:33, 7 January 2020 (EST)

A new cleanup report to find pubs which use the 'Incomplete' template

A new cleanup report to find pubs which use the 'Incomplete' template has been deployed. As per FR 1312, it uses the same grid format as the cleanup reports which find container pubs with no fiction titles. The data for this report will appear once the nightly job runs in about 6 hours. Ahasuerus 19:45, 8 January 2020 (EST)

2020-01-11 - Performance problems

Earlier today the server was mostly unresponsive due to identified technical issues. Everything seems to be back to normal now, but we don't know what the problem was. We are still looking into it. Ahasuerus 14:19, 11 January 2020 (EST)

It's still happening, although sporadically. I have asked to have the whole server rebooted. Ahasuerus 16:19, 11 January 2020 (EST)

L. E. Modesitt, Jr. - Recluce Maps

Hi, i'about to add the german translations of the Recluce series. Book 5 to 13 have maps by Ellisa Mitchell and some of the original pubs have them too. As far as i can see they are all identical - at least in the translations - and a quick Amazon "look inside" check on a few shows this also seems to be the case for the originals. If so, shouldn't one of them be a parent title and the others varianted to it? So before i add the translations and variant the maps to nine different titles i'd like to ask if anyone would be able to check if the maps in the original pubs are indeed all the same? Werner Welo 06:34, 12 January 2020 (EST)

I wondered about how to approach recurring maps, but only got as far as noting a couple of links to check - Using a series title and use of images. I'll be adding this discussion to my set. ../Doug H 10:14, 12 January 2020 (EST)
If they are indeed recurring, it may be better to merge them and set the title to 'Recluce Saga (map)' or something similar. At least they have to be varianted to a parent (likely the first occurrence). Stonecreek 13:00, 12 January 2020 (EST)

Moderator Note is now required when editing PV'd publications

As per FR 1321, a Moderator Note is now required when editing publications that have been primary-verified by users other than the submitting editor. You may need to do a full page reload (Control-F5 under most browsers) to get the new functionality working correctly. If you come across any oddities, please post your findings here. Ahasuerus 17:40, 12 January 2020 (EST)

How does this affect other submission types that affect PVed records like title submissions, etc.? —Uzume 16:12, 15 January 2020 (EST)
At this time only "Edit Publication" is affected. We may want to consider other scenarios, e.g. importing titles into a primary-verified publication. Ahasuerus 17:34, 22 January 2020 (EST)
I can see some situations where requiring our existing "Moderator Note" (however we decide to re-name it) for even all pub edit submissions against PVed pub records, might not be the best approach. For example, if I only want to add/fix external identifiers for a pub record. These normally have little to no bearing on the actual physical publications (we sometimes see LCCNs printed in publications but I have not heard of cases where they contain BNB, JNB, OCLC or other identifiers much) and I do not see why a PVer need be much involved with such a change. I expect a PVer to probably know about the same as others on that front. And normally an external identifier change is highly self-explanatory even for a moderator much less a PVer or any other editor/reviewer (so what do you propose I start putting in these required "Moderator Note"s?). The same could be said for the new web page links that are now allowed on pub records. These too have little bearing on the actual physical publication which is what PV is all about and a web page link is usually pretty self-explanatory. —Uzume 16:12, 15 January 2020 (EST)
I agree that certain fields are less impactful than others. However, I'd rather err on the side of caution. Even some External IDs -- e.g. OCLC/WorldCat -- can get tricky. Ahasuerus 17:34, 22 January 2020 (EST)

They Never Came Back

I don't see a reason why this 'nonfiction' (which actually is a collection) should have its place in the database. Can anyone else? Thanks for thinking about it. Christian Stonecreek 08:27, 17 January 2020 (EST)

Feel free to axe Allen Churchill as far as I am concerned. —Uzume 11:45, 17 January 2020 (EST)
Based on the pub ID, the paperback is from the very early days of the DB (loaded from another DB I would think). But yeah - it is not genre and it is not by someone above threshold so I would support nuking it. Annie 12:14, 17 January 2020 (EST)
Thanks for the input! I deleted the publications & the title. Christian Stonecreek 14:23, 17 January 2020 (EST)

Header template signifying remove author (and other) wiki pages

What was that template again? And where can I find the info? Thanks! MagicUnk 13:36, 17 January 2020 (EST)

over here. However - you are a moderator, you can just delete the page now. :) Annie 13:54, 17 January 2020 (EST)
Right, stupid me. Didn't think of it. Thanks for the location though. Appreciated! MagicUnk 14:47, 17 January 2020 (EST)
Nah. Unless you do it, it is hard to remember that you see new things now. :) Annie 14:55, 17 January 2020 (EST)

2020-01-21 - Performance problems

The performance problems are back. I have submitted a request to have the server bounced. Ahasuerus 11:49, 21 January 2020 (EST)

James Rollins/James Clemens canonical name

Any objections to changing the canonical name? His Rollins name is a lot more visible and recognizable and we have 70 pubs under the current one and 239 under Rollins. Annie 20:15, 29 January 2020 (EST)

That seems like a good candidate. ···日本穣 · 投稿 · Talk to Nihonjoe 20:25, 29 January 2020 (EST)
Retrieved from "https://isfdb.org/wiki/index.php?title=ISFDB:Community_Portal/Archive/Archive48&oldid=580662"