ISFDB:Community Portal

From ISFDB

Before posting here, consider whether one of the specialized noticeboards might suit your needs better:

• Help desk: for questions about how to do something, either in the ISFDB or the ISFDB Wiki. This includes both questions about how to do a specific task, and also more general questions about what should be done about particular situations where the information is clearly wrong and the solution is not obvious.
• Rules and standards discussions: for discussions about the rules and standards, such as whether certain kinds of publications belong in the ISFDB, or whether the help text defining capitalization should be modified. It also includes questions about interpretation, such as whether a SERIAL type can be used for sequences of short stories subsequently republished as a novel.
• Verification requests: for asking help with bibliographic problems concerning specific publications which require a physical check.
• Moderator noticeboard: for when you are trying to get the attention of one or more moderators.
• ISFDB:Community Portal/Archive: Archive of old discussions on this page.
• Development: A page for discussing ISFDB-related software development issues.

Podcasts on the magazine page

I have added a section for podcasts on the magazine page. Any other podcasts out there that we are treating as magazines. This also gave me a way to get the Clarkesworld podcasts into the system.--swfritter 18:59, 6 April 2009 (UTC)

Images larger than 600 pixels seem to be working now

I noticed this a few weeks ago, and uploaded one tonight Image:SSSNKJCHNN1990-067169863X.jpg. Images with one dimension larger then 600 pixels seem to be working now. I don't know if our software or a preference setting got changed.. but I thought I would point it out. I don't recall any announcement. Kevin 04:55, 7 April 2009 (UTC)

There's been no change. They've always been accepted and available for linking, but you get an error message that a thumbnail couldn't be created. In order to see the image from its wiki page you still have to click on the "Full Resolution" link. That doesn't affect your ability to link to it from the database. MHHutchins 05:47, 7 April 2009 (UTC)

AHhh In checking my preferences I must have updated mine under files and "Limit images on file description pages to:" to the 1280x1024 option sometime since last I looked (and now images smaller than that display at native resolution without the need for a thumbnail to be created) Thanks Kevin 06:16, 11 April 2009 (UTC)

Server slow-down or just me?

Has anyone else noticed how frustratingly slow the server has been for the past week? Or could it be my ISP? MHHutchins 19:42, 10 April 2009 (UTC)

It's been really slow for me most of today, and at times for quite a while. BLongley 20:18, 10 April 2009 (UTC)

It's been slow all week. It's worse at night (US Eastern), but it has been slow somewhat frequently in the early morning, too. --MartyD 00:39, 11 April 2009 (UTC)

Yes it has been slow all week. I was blaming my ISP but all other sites weren't affected. --Chris J 01:49, 11 April 2009 (UTC)

Apparently the hosting company noticed the problems too and bounced the system around 9pm-10pm EDT. Hopefully, it will feel better now! Ahasuerus 02:35, 11 April 2009 (UTC)

Did it burp in the process so that it's little tummy feels better? MHHutchins 03:26, 11 April 2009 (UTC)

Editor self-sufficiency checklist?

As more of our "new" editors are getting closer to self-sufficiency, I think back to the (relatively few) cases when we moderatorized someone and then found out that he wasn't familiar with some obscure quirk, er, I mean "feature" of the system. Most of the time it wasn't a big deal and a leisurely discussion on the Talk page sorted everything out. However, I recall a few cases when Bad Things (tm) could have happened if more experienced moderators hadn't intervened quickly.

I wonder if we could have a list of "known gotchas" that all moderators (and ideally editors) should be aware of, from the obvious "do not edit Titles in the Contents section unless you want to change ALL occurrences of the Title" to "do not create Pseudonym associations lightly since they can't be easily deleted" to "if you don't understand how UK prices worked 40 years ago, here is where to check". That way each prospective moderator could review the list and either confirm that he is aware of the issues or ask questions. Ahasuerus 03:39, 21 April 2009 (UTC)

Another one: Non-merged titles not deleted after removing them from a pub. These can be hard for a moderator to catch since there is a two step process and it is easy to forget your own.--swfritter 13:53, 21 April 2009 (UTC)

Wonderful idea. If you'll create the page, I'll add to the list as the ideas come to me. In the meantime, I'll be making notes. Thanks. MHHutchins 17:44, 21 April 2009 (UTC)

Unmerging of content titles losing page numbers is one recent gotcha I've seen. I never do that myself (I always add title/remove title/merge as necessary) so keep forgetting about it. BLongley 18:12, 21 April 2009 (UTC)

Recently discovered unmerge issue: The title of an entry in a pub can be wiped out and replaced by the pub name. I think this only happens if it is the first entry.--swfritter 21:36, 21 April 2009 (UTC)

Another result from unmerging pubs from content titles instead of vice versa (as Bill pointed out above.) I wish this function was removed as it can cause several unwanted results. A moderator looking at such a submission has no idea of what the acceptance might bring about, and not going back to make corrections. A non-mod editor would be even more unaware. MHHutchins 22:07, 21 April 2009 (UTC)

To expand on a couple of things already mentioned: choice of Canonical author when creating pseudonyms should also involve a check on whether there is a Canonical entry already - I spent too much time recently working on some chains where A was a variant of B who was a variant of C. It can be undone (maybe that should be one of the Mod skills?) but is hard work and not entirely satisfactory in the results. And secondly, UK prices of 40 years ago are simple compared with other Commonwealth countries, see Bluesman's recent discovery. I doubt that needs to be mastered before we use the blackjack though: when I figure out East Africa I'll be demanding Bureaucrat status at least. ;-) But knowing things like not needing a "£" prefix if the price is "x/y" format (i.e. shillings and pence, no pounds involved) might be desirable. Some fixes I've had to do recently on British magazines effectively brought them back down to the real price from entries that actually made them 20 times higher. :-/ BLongley 19:30, 21 April 2009 (UTC)

(fiddled the indents as this applies to the above comment) Prices in books published close to the time of decimalization (2/15/71), can have prices in both pre (5/-) and post (25p) schemes e.g. BSTSRLDSB51970.--Rtrace 22:12, 21 April 2009 (UTC)

And Australia and NZ decimalised earlier, and changed the number of shillings in the primary unit. E.g. One British pound stayed one British pound, but the Antipodean pounds became two dollars. The dual-pricing on those books has similar issues. The Irish Punt is another matter - there's 20 years where it stayed in step with the UK (although book prices don't illustrate that, introducing the problem of the halfpenny.) But I think we're getting beyond what we need mods to know. BLongley 18:48, 22 April 2009 (UTC)

Another thought: Double quotes are OK in Publication and Title titles, but not in Author records (use single quotes instead). Single quotes cause problems in Series titles under some obscure and hard-to-recreate circumstances. Ahasuerus 21:11, 21 April 2009 (UTC)

And another thing - various pieces of top-of-the-form pub data do not get updated automatically - editor title, coverart title, etc. Not data destructive so not critical.--swfritter 22:46, 21 April 2009 (UTC)

And let's not forget our perennial favorite: When editing a Publication record with no pre-existing Contents data, the first Title defaults to ANTHOLOGY. Ahasuerus 23:00, 21 April 2009 (UTC)

[unindent]When the title reference record is present in the contents section of some pub types (not all), don't overwrite it unless you're aware of the ramifications of your action. (Some editors will start adding content and overwrite this record.) MHHutchins 23:17, 21 April 2009 (UTC)

And how about having a basic understanding of the difference between a title record and a publication record? If I had a nickel... MHHutchins 23:17, 21 April 2009 (UTC)

And which title types are "containers" and which are "contents". (And the one that is sort-of in-between at the moment, CHAPTERBOOK .) And the great bafflement that is the "Editor" record. BLongley 18:34, 22 April 2009 (UTC)

Changing the Author's name (in Author Data) to a value that is shared with another Author record is a very bad idea since the software assumes that Author names are unique, so all data linked to the second record will become inaccessible. The way to fix it is to change the first record's name in Author Data to something else (e.g. by adding "1" or "- test") and then manipulating individual Title and Publication records. Author Merges should be approached very very carefully since they can destroy intricate webs of variant titles. Ahasuerus 18:24, 25 April 2009 (UTC)

If there is a "special character" in a field, Moderator screens will show the field as changed even when no changes to that field were made. Ahasuerus 16:19, 1 May 2009 (UTC)

PublishAmerica RULES!

Who says PublishAmerica doesn't produce winners! Just look look at the price of this "Jem"[1] in the after market. After reading the product description I ordered it right away! A future classic, order soon before the rare book dealers corner the market and drive the prices even higher!!!Kraang 02:17, 22 April 2009 (UTC)

I'm not buying until someone writes a review! I wonder if an ebook version is on the way.--swfritter 02:27, 22 April 2009 (UTC)

I wonder if "Tom Thorstenson" is also the dealer, or if not, whether this is an unpublished Philip K. Dick manuscript. My god, what idiot would pay $200+ for a paperback published by a vanity publisher? MHHutchins 04:47, 22 April 2009 (UTC)

His mother? Kevin 12:50, 22 April 2009 (UTC)

Helix Resurrected & missing issues added.

It's back. I also added data for the three issues that hadn't been entered. See this issue for the notes I put in the pubs that were resurrected]. This issue has the notes for the issues that were entered from a secondary source. Please note that the secondary source is also a webzine. An appropriate candidate for the transient verification flag. I will add more disclaimers to the magazine linker page tomorrow.--swfritter 20:47, 23 April 2009 (UTC)

Much appreciation for your efforts. Alas, I can think of a half-dozen more webzines that are just as worthy, or probably more so, than Helix: The Infinite Matrix, The Internet Review of Science Fiction, and Infinity Plus come to mind. (And those are just the ones beginning with "I"!) Thanks. MHHutchins 20:53, 23 April 2009 (UTC)

Too late for Galaxy Online!--swfritter 21:38, 23 April 2009 (UTC)

I think it wise that if you find that some of the material of e-publications have value that the data be entered as the author of one story wished. After all this db records the existence of material at one time, with no assurance that it will last forever. It does give the researcher the basic data to look for and there almost always is someone around who has stored the e-version. The DB therefore protects the actual existence record and others will find the material so recorded. Hopefully, such action will preclude a statement like Anne McCaffrey made that she could not remember what story inspired her 'Brain ship' Series. Thanks, Harry. --Dragoondelight 23:15, 23 April 2009 (UTC)

Nominating Kpulliam for moderatorship

Ref: Moderator Qualifications#Becoming a moderator for the nomination process.

Nomination statement

I nominate Kpulliam (talk • contribs) for moderatorship; he has accepted the nomination. Kevin has over 2,800 submissions and has a good working knowledge of all aspects of the database as demonstrated by his recent work on cleaning up reviews, e.g. see this Mummy! discussion, and has actively participated in Wiki discussions. I believe that he is qualified.

1. Support, as nominator. Ahasuerus 23:22, 25 April 2009 (UTC)
2. Support, as somebody that watched his edits today even more closely than usual. I'm sure we'll have differences over "variants for punctuation alone" or something, but he seems far more constructive than destructive, while still being quite inquisitive. BLongley 22:25, 26 April 2009 (UTC)
3. Support,of lately I've only moderated the easy submissions, but I still follow the different talk pages. Kevins submissions have covered most of the more complex areas of the database and I feel he is ready to be cut loose and go at it.Kraang 00:08, 27 April 2009 (UTC)
4. Neutral, reluctantly. Kevin has done some terrific work but seems a little too impulsive at times.--swfritter 16:49, 27 April 2009 (UTC)
5. Support, with the same reservations as Swfritter, but with the solid belief that the new role will moderate those impulses (no pun intended!) MHHutchins 17:28, 27 April 2009 (UTC)
   • Comment: I have to admit that I thought about this issue before nominating Kevin and almost added a line similar to Michael's to the nominating statement. I suspect that part of the problem is that we have a number of issues (and associated workarounds) that have been debated to death and are all too familiar to "first generation" moderators. Thus, when a relatively new contributor looks at one of these thorny areas and says "Oh, sure, I can fix this, no problem, give me a few minutes", we tend to be a little apprehensive. Ahasuerus 18:08, 27 April 2009 (UTC)
6. Support. Kevin has worked hard and has shown marked interest in the intricacies of the DB. His interest in the Other Sites usage stunned me. Though it presently does not appeal to me, it probably is an important adjunct of the DB that needs refinement. (hint) (wink) --Dragoondelight 11:58, 29 April 2009 (UTC)
7. Support. I haven't moderated that many of Kevin's submissions, but the ones I've looked at have been good. The discussions he's been involved show he has a sharp mind, learns quickly, and communicates well.--Rkihara 15:49, 29 April 2009 (UTC)

Outcome

Nomination is successful; moderator flag set on the account. Congratulations! :)

You may want to review Help:Screen:Moderator, which describes the Moderator page, and please don't hesitate to ask if in doubt! Ahasuerus 05:18, 1 May 2009 (UTC)

• Thank you all for your support and comments. I will still welcome comments about my edits and as such feedback will continue to be appreciated! - Now to see what all of the fuss is about.....Moderator Menu... Here I come! Kevin 05:39, 1 May 2009 (UTC)

Future Moderators

Aside. This council of elders needs to develop Bluesman, William H. and MartyD. If it continues to dither you may lose their interest. I do not know the status of RTrace or HolmesD, I am assuming they are not moderators, but both also need to be fast tracked. Thanks, Harry. --Dragoondelight 11:58, 29 April 2009 (UTC)

"Dither"??? As one of the 'potentials', I don't feel that anyone has been 'dithering' in the slightest. There will always be generalists and specialists, both of which this site needs and supports. Hell, Harry, you get support and I'm not sure just what you are! LOL!! Thanks for going to bat, but I think the 'elders' (have to laugh at that as I'm older than all of them) are doing just fine!! ~Bill, --Bluesman 05:20, 5 May 2009 (UTC)

My understanding of the rules is that as an editor you can nominate yourself or others. It is not necessary to be a moderator. Not all editors want to be moderators, so be sure to check the protocols under Moderator Qualifications#Becoming a moderator first.--Rkihara 20:28, 29 April 2009 (UTC)

There is no "Council of Elders". There are editors that communicate and those that don't. Some edit well without communicating well. Those might be supported into self-editing that requires moderator abilities, it makes them more productive and lessens the workload for the rest. I'd suggest Don Erikson as somebody heading that way - very active, few faults apart from some typos. You've mentioned Bluesman, Willem H, MartyD and Rtrace - all people that communicate and I hope we are supporting them. And you, although I notice you didn't add yourself to the list. HolmesD is a bit too quiet for my liking: no problems with his editing, but I can't see him being an active moderator. It's activity and communication that make a mod, as well as their edits: we've actually demoted several mods recently, even a bureaucrat. And several mods are specialists: it's not uncommon to see someone that knows all the magazine guidelines inside out that dithers over "tp or pb" for a book, and book specialists that couldn't be sure of the dimensions for a magazine. We're not looking for perfection in mods, and we're not trying to keep non-mod editors down. I'm glad to see editors looking at fellow editors as potential mods though. BLongley 22:07, 29 April 2009 (UTC)

Rest assured that we would love to see more editors become moderators. Not only does it make their lives easier, it also makes the moderators' lives easier and frees them/us up to do more work on data entry, data cleanup and, in some cases, scripting, robots, the backups and even walks in the park! :) If an active editor communicates well, he will eventually become familiar with all (or the vast majority of) policies and "gotchas" and his submissions will no longer require moderatorial review.

Having said, it can be hard to tell whether an editor is ready for self-sufficiency or not. He may be proficient at modifying publications and merging titles, but has he done some of the more obscure things, e.g. has he created nested series, unlinked variant titles or fixed "invisible" EDITOR records? It's almost like we need a test, which is pretty much what happened with Kevin (see the link to his Talk page above). Ahasuerus 22:28, 29 April 2009 (UTC)

Less like a test... more like a Journeyman's project. Another thing that has 'boosted' me in the last two weeks as far as truly digging in the DB is working on ISFDB:Authors_that_only_exist_due_to_reviews. My recommendation... Pick a letter (no not that really short one).. put an 'in progress' sign at the top of it, and do them all. Then go back through the list, and do them all again by finishing the publications they link to (If there is one unlinked / un-entered pub in a magazine, there are probably others... so do all the ones you skipped the first time). Each time through there will be some you just aren't sure what to do with, or how to proceed. That's ok... leave a note to yourself, and come back around again. I've been going back and forth in the J's now for quite some time and I'm no-where near done. Kevin 23:12, 29 April 2009 (UTC)

On this one mini-project, I've entered new pubs, edited old ones, changed review titles, changed review authors, fixed authors, fixed titles, renamed authors, discovered new authors, entered collections of fiction, non-fiction, I entered pubs that were out, then then deleted them from the system, read, and then re-read the 'Rules of acquisition', Discovered overlapping authors, disambiguated authors, researched like heck in the LOC, Worldcat, Amazon.com (US, British, French, and German), Google Books, Internet Archive, Wikipedia, etc. Entered non-english language originals, just so I could enter the English language variant, chased tangents, bugged verifiers (politely) entered 'real changes' (not just notes and covers) after asking first, bugged verifiers some more (still politely), started entering real changes with notes: If this is wrong we can change it back on wiki pages, learned more wiki code (to add highlighting for my notes... they were running together on the screen), seriously the list goes on and on. Pick a project.. something that will make you ask yourself again and again in the same (day, week, whatever) 'How do I do this' 'How do I want to do this' 'how has this been done before' and 'has this been done in different ways before' and you will be well on your way. Kevin 22:56, 29 April 2009 (UTC)

I would like to know what constitutes a 'real change'?? Every change is 'real' and I don't see anything that delineates between 'real' and the (implied) 'important' ones.... --Bluesman 05:29, 5 May 2009 (UTC)

Oh I definitely was not trying to imply that one type of change was more important than the other. To be clear, there are two types of changes, 'Additive', and 'Destructive'. Additive changes put more info into the DB (e.g. page count when empty, cover links when empty or broken, added notes, etc). Destructive changes require the removal of previously entered information (e.g. change in authors name, change in title, change in year, etc). What I was referring to above as 'real' were 'destructive' changes, where I was erasing some information already present, as opposed to simply adding more information. It's always easier (for me) to press the submit key with confidence to change someone elses verified work when the changes are additive and I have the book in front of me, than when they are destructive and I am working from secondary sources alone... so mentally I felt more 'trepidation' at submitting those changes. Thanks for keeping me honest! All changes are real (and welcome!, and worth doing!), but changes that erase information cause me more concern/worry than those that don't. Kevin 11:13, 6 May 2009 (UTC)

Perhaps "Additive" and "Deletive"? Destructive seems to indicate that any erasure is/could be bad. The DB is an evolving thing, and there is a great deal of 'data' from years past that needs to be altered/deleted for clarity, which I think the current 'bent' seems to prefer. So do I. And with the current band of editors being so easy to reach, issues on data get resolved very quickly. I see that the trend has been getting more aggressive in changing data on verified pubs from 'vanished' editors as well. A lot of this is we have access to more data. I remember well being totally afraid to add, never mind change anything (that was when I found out someone was actually watching LOL!!!). Those same watchers now give me the confidence to submit just about any change and learn from the 'fallout'. For the rest we have these pages. And with cyberspace, does anything truly disappear????? ;-) ~Bill, --Bluesman 00:38, 7 May 2009 (UTC)

The situation about changing verified pubs has occurred because the definition of "verified" has evolved over the years. It's like a butterfly you can never really pin down. Moments after you think it's captured, something else comes along to scare it away. I'm doing third and fourth passes at some of my books, but only when they're brought to my attention. I have too many projects going on to do a thorough pass of every book in my collection. MHHutchins 03:58, 7 May 2009 (UTC)

(Not Indented)I think Kevin's statement on what "Additive" and "Destructive" changes are makes very good, clear sense and should be incorporated into some stage of the "How To Instructions". If people, and most workers here do, give a quick thought to what can happen things should work better. No one else said it quite that way to me, except I especially like VBT, Very Bad Thing. Would two other categories be "Clarification" and "Declarative"? Thanks, Harry. --Dragoondelight 22:53, 6 May 2009 (UTC)

That's a very good point. I learned a great deal about the way the latest version of the software (the current version is "ISFDB-2", BTW) worked in May 2006 by testing it to destruction. In a way, it was harder to do than what Kevin describes above, since I had to figure out what software behavior was intentional and what "features" were actually bugs, but it was very educational. Ahasuerus 02:48, 30 April 2009 (UTC)

I'm glad you liked that Project, Kevin, it's one I started! It does lead to all sorts of interesting areas - have you encountered the reviewers that are reviewing under a pseudonym yet? I'm still not sure how to best deal with those. But it's obviously not a universally appealing one, and I'm happy to suggest or construct others, and "mentor" people if needed if it's an area I could work on myself anyway. "Publication Series" has a few open areas that could be worked on but will probably not take people across so many areas, but does teach people ISBN prefix ranges for publishers, Imprint versus Publisher information, printing numbers and ISBNs across changes of cover art, prices, format etc. There's a lot of projects that could be created: I'm slogging through some British magazines that need some improvement but could suggest other things that need doing - publisher information, finding the covers, distinguishing editors, etc. All could lead into exciting new research for somebody. Or a hard boring slog if it's not something you're interested in. But if people have an interest, we can find a project, I'm sure. BLongley 20:13, 30 April 2009 (UTC)

Well I read the 'rules' and as a document it reminds me of all constitutions that I have read. The real critical issue is that you (the group) need to develop a program that gives people a sense of where they stand. People want and need peer approval to go for the gold. What is readily found is the criteria of being a 'total' moderator, not a journeyman moderator. Editors see the DB by the attitude and commentary of moderators, much of which is expressed in the loftiness of truly well rounded individual effort. Unfortunately, people are not built that way. Without a program or schedule to show them the elements needed for success, they rely on the moderators to give them that boost. The problem is that they need more counselor guidance to attain a moderator role. It is clear from recent 'moderator' statements that the moderators do not desire more 'self approvers'. The moderators have made that clear, but have not clarified what exactly is needed. As a guideline, after a thousand or so points or whatever, a moderator needs to start a conversation with them to determine their goals and possible needs. Thanks, Harry. --Dragoondelight 23:40, 29 April 2009 (UTC)

We have tried "mentoring" in the past when a moderator (or two) and an editor were interested in the same area. They would split the workload and the moderator would explain the system's quirks to the editor until the later reached self-sufficiency. Swfritter, Rkihara and Davecat had particularly successful arrangements, I believe, and may be able to comment further. Ahasuerus 02:48, 30 April 2009 (UTC)

Mike Hutchins and I both worked with Davecat. I thought the process worked fairly well and think, at least at first, new editors should work primarily with one or two moderators. Rkihara came on board a few months after me and we both learned from each other by doing double verifications on pubs we owned in common. We both had some really good and really bad ideas and the communication normally resulted in the good ideas being more commonly used.--swfritter 21:03, 30 April 2009 (UTC)

I've tried the same set-up with other new editors, and have found that some are more receptive than others. It doesn't take long to figure out just how much help an editor needs . . . and how much he'll accept. MHHutchins 04:00, 7 May 2009 (UTC)

Personal aside. I am pushing this issue because I have realized that my ambition burned out. I would never feel at ease as a moderator and possibly that is why some 'drop' out. There may be just a 'tad' too much expected of prospective and active moderators. Having trained a great many people, I will state you need to actively and personally encourage workers to wish to 'fly'. You have to stand by and watch them smash themselves into the woodwork or dance in the wind. Give them the keys and let them develop skills. Thanks, Harry. --Dragoondelight 23:40, 29 April 2009 (UTC)

It is certainly true that self-sufficiency doesn't imply perfection. If it did, we would have no moderators left :) Ahasuerus 02:48, 30 April 2009 (UTC)

Second Aside. Sorry guys, but council of elders is the mildest thought I have had since first coming here. I actually think of the control group and participants as the 'club of anarchists'. I frequently wonder at how much sub-rosa is done by people. I think you real solution is the DB needs a larger group of interactive thought, not necessarily a completely trained cadre. If you get people to habitually interact with more numbers I think you will find less 'explorative' work done. Thanks, Harry. --Dragoondelight 23:40, 29 April 2009 (UTC)

I don't think there is much "sub-rosa" stuff, i.e. editors consciously trying to get around our established rules, happening. There are certainly different "styles", individual preferences and even different interpretations of the (sometimes confusing) Help pages and policies, but that's to be expected and we try to sort these cases out as they percolate to the surface. Occasionally, new editors have problems with the rules and either leave (I believe that Hayford Peirce left in part for this reason) or adapt and even thrive (David Siegel did in spite of having strong opinions on a number of topics.)

The "sub_rosa" event that came near to triggering my near departure from the isfdb concerned submissions from Shsilver who on his Talk page stated "Re-submitted the Helix information on the advice of another editor." Since this advice does not appear on his Talk page I can only assume it was given in a private email. It appeared to be an attempt to sneak the data in. I was so distracted by that issue that I wasn't really concentrating on the issues associated with his other submissions.--swfritter 18:29, 30 April 2009 (UTC)

It's hard to be sure what Steven Silver meant given his lapidary comments. Even if he was advised by another editor (who may not have been a moderator or a frequent contributor) via e-mail, given Steven's lack of prior experience with ISFDB, it may have been misinterpreted, so it may be premature to draw conclusions. (The first rule of The Cabal: There Is NO Cabal!) Ahasuerus 18:44, 30 April 2009 (UTC)

Remember that the notes on Rejected Edits might be considered communication too. But I've looked at mine from the 11th April and can't see how Steve Silver could have misinterpreted those, they were about Argentus rather than Helix. He might have misread "If there's enough evidence of first publication of fiction in Helix, then we can treat it like a Non-Genre magazine and do the relevant fiction only" suggestion that I posted in the ISFDB:Moderator_noticeboard#Shsilver_submissions talk maybe? That's all on public record though. I don't discuss edits via email and would discourage anyone from doing so. But this Wiki communication does make it bloody hard to find discussions at times - I think Bluesman and Mike Hutchins discussed the middle name/initial problem directly here, but I don't recall anything about Helix and am useless at Wiki-Searches. BLongley 19:57, 30 April 2009 (UTC)

Oh, and there is obviously no Cabal - it was retitled "Nightbreed". ;-) BLongley 19:57, 30 April 2009 (UTC)

The dates and times seem to support that explanation. Silver may have jumped the gun on an issue I obviously had volunteered to resolve. As far as Cabal's around here - it might sometimes appear that way because many of us have a good idea as to the thought processes of others. In addition, there are many discussions that get started on individual talk pages but don't get on to the main pages immediately.--swfritter 20:45, 30 April 2009 (UTC)

Overall, I think it's fair to say that different people develop editing and communications skills differently and their pace of progress can differ dramatically. Some of us, e.g. David Siegel and I, had a fairly extensive Wikipedia background when we (re-)joined the project, so using this Wiki was easy for us. Other editors had some kind of computer/IT background, which made it easier to master the fine art of data manipulation. Yet another group had no IT background but learned the ropes by creating tens of thousands of submissions (you know who you are!). Conversely, some editors had certain problems which made it harder for them to become self-sufficient, e.g. at one point Don had serious health issues, which made it harder for him to edit. Dave Sorgen, a retired programmer, learned the software quickly, but he spends much of his time traveling in remote areas, which makes it hard for him to stay current. We also had an active and well-meaning German editor at one point, but his English skills were limited.

And then there is the "churning" factor. Some editors are primarily interested in a specific area of the database and when they are done with it, their interest wanes. Other editors go on an editing spree when they find the ISFDB, but burn out quickly. Yet another group has to stop editing for family and other personal reasons. And then there are some who burn out after so many thousands of submissions. Which reminds me. Now that the backups have been mostly automated, I may take a day or two off to recharge my batteries... Ahasuerus 02:48, 30 April 2009 (UTC)

'Recharge Batteries'? Do I smell a whiff of Solder? - Hey Bill, I think Fixer or Dissembler has taken over Ahasuerus's login. What should we do? Kevin 03:52, 30 April 2009 (UTC)

I'll bet you $1,024 you can't prove anything! Ahasuerus 16:02, 30 April 2009 (UTC)

Move Electric Velocipede to Fanzines?

Seeing as how it has a Hugo Nomination in that category. There is already an empty link in fanzines.--swfritter 19:16, 28 April 2009 (UTC)

I think I entered a lot of the contents, but only from secondary sources. It seemed a significant title, but I have no preference for Fanzine or Magazine. Put it where you will. BLongley 20:32, 28 April 2009 (UTC)

I will probably place a common link in both places. Looks like a semi-prozine to me too but if the publisher says it's a fanzine . . . --swfritter 23:36, 28 April 2009 (UTC)

Service problems

It took 8 minutes for this page to come up, plus another 4 minutes to load the comment box. Is there anyone who can contact the website host to let them know there's a problem? This is too frustrating and too much a waste of time. This has happened so many times today that I've stayed away, only to come back and have the same problems. Funny thing though, right in the middle of all this, everything pops up just fine. But it's not long before it starts happening again. The problem must be on the host's end, because I have no problems connecting to other websites. MHHutchins 22:22, 28 April 2009 (UTC)

I have been noticing this problem for the past couple of weeks. Kevin 22:27, 28 April 2009 (UTC)

I have seen unhealthy delays over the last few weeks as well, but never as bad as 8 minutes. I'll ask Al to send our service provider an e-mail, but a cursory review doesn't find anything unusual, at least not at the moment. On average, our processor is 89% free and spends only 3% of the time waiting for the database, although I see significant spikes now and then. Unfortunately, both average and "spike" numbers can be misleading since we are running on a virtual machine, which may have problems of its own. I have neither the tools nor the expertise to analyze the issues, but one thing that I have noticed is that the system is often running the "Diff pubs" script and the login script. Since these scripts should be rarely executed during day to day operations, it may suggest that are we getting hammered by robots hitting every single link on the Web site. I'll mention this to Al too. Ahasuerus 02:28, 29 April 2009 (UTC)

Last night, shortly after 1:00 am (server time), it took more than twenty minutes between entering a submission and final approval. MHHutchins 19:13, 29 April 2009 (UTC)

I too, have noticed. Really slows you down. LOL. I have started playing pinochle between screens. Thanks, Harry. --Dragoondelight 19:21, 29 April 2009 (UTC)

I think I may have caught it red-handed. Wiki load times were up to 1 minute as of 3:20pm EDT, so I ran some basic diagnostics and it turns out that the system was spending almost all of its time waiting for the disk. Load times appeared to be fine on the database side, so either our virtual machine is misbehaving or the fact that our Wiki tables have grown a lot over the last year is causing us problems. Let me see if Al can get rid of the old versions of the most active Wiki pages (including this one), which helped the last time around. Ahasuerus 19:37, 29 April 2009 (UTC)

Let's hope that solves the problem. I'm getting too good at four-suite Spider Solitaire! MHHutchins 22:06, 29 April 2009 (UTC)

I had about 30-45 minutes of total unavailability just now, from about 1:12 AM until about 1:45 AM CDT (You can see the gap between my two approvals for Ceres Solution). I got actual Server Error 500 messages a couple of times, so it's not network related, its definitely on our box. Kevin 07:01, 3 May 2009 (UTC)

It was still pretty bad at 6:15 AM EDT or so. It got better around 6:45 in that it would eventually respond with only moderate delay. This just for page views, not storing. --MartyD 11:09, 3 May 2009 (UTC)

Well after it got good for 10 minutes last night it went out on me again. It was so far gone, that I didn't know if my post (about the problems) went through until I got up just now. Kevin 13:21, 3 May 2009 (UTC)

A few points:

1. No changes to the database have been made yet. We need to check whether the script to purge the old versions of Wiki pages -- which Al ran last year -- will still work with this version of the Wiki software.
2. When the backups run, the system typically slows down to a crawl. The main backup process runs at 4am EDT. Images are backed up between 5:10am-6:20am EDT, but let me change the time slice to 3:30am-4:40am EDT.
3. We run on a "virtual machine", so we don't have a full server to ourselves, which means that we may be indirectly affected by all kinds of other things happening on that physical server. If we were to upgrade to a dedicated server, it would be another $850/year.
4. Today was a particularly bad day. My monitoring service typically sends me 1-2 notifications of system unavailability every night, but today I received 3.

I think the prudent thing to do is to purge the old versions first and see if it helps. If it requires a new script, we may need Marty's help. Ahasuerus 15:49, 3 May 2009 (UTC)

Lady Churchill's Rosebud Wristlet wiki?

Looks like we've got all but the latest issue in the database but no wiki page for it. It has garnered some nomination votes in the semi-prozine category so seems appropriate to place a link in the magazine section although there is an empty link in the fanzine wiki.--swfritter 23:53, 28 April 2009 (UTC)

And that's my other admitted 'zine project. Again, I have no preference for fanzine or magazine. I just dumped the data from their website here. BLongley 17:54, 29 April 2009 (UTC)

I will probably put links in both places. I actually would be more likely to look in magazines for pubs that carry mostly fiction. Thanks!--swfritter 18:28, 29 April 2009 (UTC)

No problem, glad it helped. Maybe I should admit my unofficial Interzone project? Still fixing editor records, learning a lot about Brin1 along the way, adding months to years, fixing prices, etc. NOT adding publisher, correcting regular column names, adding [n] to Interiorart entries, adding Coverart URLs etc. Someone else can do that. Another of my "iterative improvement" projects that I tend to keep quiet lest someone "remind me" that I could do so much more. BLongley 22:22, 29 April 2009 (UTC)

I was glad to find the wristlets - saved me a lot of work; I finally have enough sense to look for non-wiki'd magazines before I start adding them. I have been slamming data from semi-prozines in much the same way. Better that they be in the system un-spiffed then not in the system at all.--swfritter 00:05, 30 April 2009 (UTC)

Software development resumed

As most of you know, Al has been mostly unavailable since the middle of last year. The rest of us have been unable to get a development system up and running, so all software changes and bug fixes had to be put on the back burner. Well, I am happy to report that MartyD was able to set up a development system (thank you, Marty!) and is ready to start making changes.

The current plan is as follows:

1. Do a minimal "proof of concept" change which will test the process -- see the Proposed changes to Series display section immediately below
2. Decide on the overall approach, i.e. "low hanging fruit" vs. "big ticket items"
3. Clean up our bug list and prioritize outstanding issues

As far as the overall approach goes, I don't think Marty will be in a position to undertake major tasks like creating an Award editor screen or replacing the "lexical match" logic for Serials just yet. We'll need to start small and fix the simple stuff first so that Marty could slowly expand his knowledge of the application.

I'd take a stab at prioritizing the bug list, but I seem to be coming down with something. I am sure we all have our pet peeves and priorities, so we will need to do a cost-benefit analysis soonish. Ahasuerus 22:31, 30 April 2009 (UTC)

I would look first at the Editor self-sufficiency checklist? section and fix anything that will remove a gotcha with minimum effort. A display only solution could be implemented for showing how many titles are merged - should be implemented in both the edit screen so the editor can see it and pub submission display where the moderator can see it. This might be a good place to start because it requires no database updates. Perhaps a database related update would be the capacity to remove a pseudonym assignment at the author biblio level. These might be good feet-wetting projects.--swfritter 00:00, 1 May 2009 (UTC)

Some quick wins would be putting the relevant publication tag/id, and/or title IDs on the Approval screens for the awkward edits where the mod doesn't know what's being unmerged from where or what's being removed from what. Finding out after approval is a bit late and can lead to a lot of fixing. BLongley 19:09, 1 May 2009 (UTC)

Another thing that should be fairly simple - didn't most of us agree that we'd prefer 0000-00-00 titles to go at the bottom rather than the top? BLongley 19:09, 1 May 2009 (UTC)

Ditto on the 0000-00-00 titles.--swfritter 21:23, 1 May 2009 (UTC)

Double ditto on the 0000-00-00 titles.Kevin 22:38, 1 May 2009 (UTC)

Not to disagree with that, but would you then want the same thing for pubs within a title? It would be a little odd to have 0000-00-00 titles at the bottom and 0000-00-00 pubs at the top. Of course, I'd rather see pubs sorted by catalog number AND first date of that catalog number, then have printings of that catalog number indented a la variants or series, but that's probably just me.... --MartyD 01:02, 2 May 2009 (UTC)

You caught me copy and pasting. While the word titles was used... I read the request as having to do with undated publications within a title. Thanks for keeping me straight! Kevin 01:24, 2 May 2009 (UTC)

I agree that both 0000-00-00 titles and pubs are best displayed at the bottom, but keep in mind that in the past we also discussed various complications related to Variant Titles, omnibus editions and imprints that are used by more than publisher. At one point we had an extensive discussion of this topic and agreed that we needed to add a "Printing" field to the Publication table which would help order numerous 0000-00-00 pubs published by the same publisher. However, that goes beyond "display only" changes, so we probably don't want to go there (yet).

Re: Marty's proposal to sort publication records based on the first appearance of each ISBN/Catalog ID and then use indentation if there is more than one pub that shares the same ISBN/Catalog ID, it may well be workable. If you could make this change on your home system and then upload a picture of a sample Title page (e.g. some Le Guin title with a dozen+ pubs), it may give everyone a better idea of what the end result will look like. Ahasuerus 02:31, 2 May 2009 (UTC)

Proposed changes to Series display

As far as the "proof of concept" project goes, I asked Marty to review the way Series are currently displayed. There have been numerous requests to change the display order so that "Series with short fiction only" and "Non-genre series" would be displayed. Here is what he found as far as the display order of Summary Bibliographies goes:

• SERIES: Fiction Series ("NC" -- has title types of Novel, Collection, Omnibus)
• WORKS: Novel
• WORKS: Collection
• WORKS: Omnibus
• WORKS: Serial
• SERIES: Editor Series ("E" -- has title types of Editor)
• WORKS: Editor
• SERIES: Anthology Series ("A" -- has title types of Anthology)
• WORKS: Anthology
• SERIES: Non-Fiction Series ("NF" -- has title types of Nonfiction)
• WORKS: Chapterbook [as we all know, these are partially broken]
• WORKS: Non-Fiction
• WORKS: Non-Genre
• WORKS: Cover Art
• WORKS: Back Cover Art [not fully implemented]
• WORKS: Interior Art
• [SERIES: Short Fiction Series ("Short" -- has title types of Shortfiction) ** currently commented out]
• WORKS: Short Fiction
• WORKS: Poem
• SERIES: Essay Series ("Essay" -- has title types of Essay)
• WORKS: Essay
• WORKS: Review
• WORKS: Interview

The software works its way down the list and if it finds anything eligible for display in a particular section, it also displays other Titles in that series. That's why Short Fiction Titles are displayed along with book length Titles at the top of the pages, but only if there are any book length Titles in that series. This behavior is certainly not perfect and sometimes results in empty series headers. I am sure we could come up with all kinds of ways to improve it, but I suggest that we limit our changes to something very straightforward and basic for now.

One simple solution is to redefine "Fiction Series" to include Non-Genre and Short Fiction Titles so that Non-Genre and Short Fiction series would appear at the top. Another solution is to re-enable the "Short Fiction Series" section so that all series that contain nothing but Short Fiction would appear after Interior Art and before the rest of Short Fiction. (Do we want to move the art sections below Short Fiction?)

I am sure Marty will be able to answer any questions that may arise <he said heading for the bed>. Ahasuerus 22:31, 30 April 2009 (UTC)

Here is what Henry Kuttner's bibliography will look like if we decide to display all fiction Series, including "Short Fiction only" Series, at the top of the page:

   *  Baldy
         o The Piper's Son (1945) [SF] with C. L. Moore
               + Variant Title: The Piper's Son (1945) [as by Lewis Padgett ]
               + Variant Title: The Piper's Son (1945) [as by Henry Kuttner ]
         o Three Blind Mice (1945) [SF] with C. L. Moore
               + Variant Title: Three Blind Mice (1945) [as by Lewis Padgett ]
               + Variant Title: Three Blind Mice (1945) [as by Henry Kuttner ]
         o The Lion and the Unicorn (1945) [SF] with C. L. Moore
               + Variant Title: The Lion and the Unicorn (1945) [as by Lewis Padgett ]
               + Variant Title: The Lion and the Unicorn (1945) [as by Henry Kuttner ]
         o Beggars in Velvet (1945) [SF] with C. L. Moore
               + Variant Title: Beggars in Velvet (1945) [as by Lewis Padgett ]
               + Variant Title: Beggars in Velvet (1945) [as by Henry Kuttner ]
         o Mutant (1953) [C] [as by Lewis Padgett ]
         o Humpty Dumpty (1953) [SF] with C. L. Moore
               + Variant Title: Humpty Dumpty (1953) [as by Lewis Padgett ]
               + Variant Title: Humpty Dumpty (1953) [as by Henry Kuttner ]

   * Elak
         o Thunder in the Dawn (1938) [SF]
               + Magazine/Anthology Appearances:
               + Thunder in the Dawn (Part 1 of 2) (1938)
               + Thunder in the Dawn (Part 2 of 2) (1938)
         o Spawn of Dagon (1938) [SF]
               + Variant Title: The Spawn of Dagon (1938)
         o Beyond the Phoenix (1938) [SF]
         o Dragon Moon (1941) [SF]

   * Gallegher
         o Time Locker (1943) [SF]
               + Variant Title: Time Locker (1943) [as by Henry Kuttner and C. L. Moore ]
               + Variant Title: Time Locker (1943) [as by Lewis Padgett ]
         o The World Is Mine (1943) [SF]
               + Variant Title: The World Is Mine (1943) [as by Henry Kuttner and C. L. Moore ]
               + Variant Title: The World Is Mine (1943) [as by Lewis Padgett ]
         o The Proud Robot (1943) [SF]
               + Variant Title: The Proud Robot (1943) [as by Henry Kuttner and C. L. Moore ]
               + Variant Title: The Proud Robot (1943) [as by Lewis Padgett ]
         o Gallegher Plus (1943) [SF]
               + Variant Title: Gallegher Plus (1943) [as by Henry Kuttner and C. L. Moore ]
               + Variant Title: Gallegher Plus (1943) [as by Lewis Padgett ]
         o Ex Machina (1948) [SF]
               + Variant Title: Ex Machina (1948) [as by Henry Kuttner and C. L. Moore ]
               + Variant Title: Ex Machina (1948) [as by Lewis Padgett ]
         o Robots Have No Tails (1952) [C]
               + Variant Title: The Proud Robot (1983) [as by Henry Kuttner and C. L. Moore ]
               + Variant Title: Robots Have No Tails (1952) [as by Lewis Padgett ]

   * Gerry Carlyle
         o Trouble on Titan (1947) [SF]

   * Hogben
         o 1 The Old Army Game (1941) [SF]
         o 2 Exit the Professor (1947) [SF] with C. L. Moore
               + Variant Title: Exit the Professor (1947) [as by Henry Kuttner ]
               + Variant Title: Exit the Professor (1947) [as by Lewis Padgett ]
         o 3 Pile of Trouble (1948) [SF]
         o 4 See You Later (1949) [SF] with C. L. Moore
               + Variant Title: See You Later (1949) [as by Lewis Padgett ]
               + Variant Title: See You Later (1949) [as by Henry Kuttner ]
         o 5 Cold War (1949) [SF]

   * Jirel of Joiry
         o Quest of the Starstone (1937) [SF] with C. L. Moore

   * Keeps
         o The Jungle / Clash by Night (1991) [O] with David Drake and C. L. Moore [as by Henry Kuttner and David Drake ]
         o 1 Clash by Night (1943) [SF] with C. L. Moore
               + Variant Title: Clash by Night (1943) [as by Lawrence O'Donnell ]
               + Variant Title: Clash by Night (1943) [as by Henry Kuttner ]
         o 2 Fury (1950) with C. L. Moore
               + Variant Title: Destination: Infinity (1958) [as by Henry Kuttner ]
               + Variant Title: Fury (1947) [as by Lawrence O'Donnell ]
               + Variant Title: Fury (1950) [as by Henry Kuttner ]
               + Magazine/Anthology Appearances:
               + Fury (Part 1 of 3) (1947) with C. L. Moore
               + Fury (Part 2 of 3) (1947) with C. L. Moore
               + Fury (Part 3 of 3) (1947) with C. L. Moore

   * Michael Leigh
         o The Salem Horror (1937) [SF]
         o The Black Kiss (1937) [SF] with Robert Bloch

   * Pete Manx
         o Roman Holiday (1939) [SF] with Arthur K. Barnes [as by Kelvin Kent ]
         o World's Pharaoh (1939) [SF] [as by Kelvin Kent ]
         o Science Is Golden (1940) [SF] with Arthur K. Barnes [as by Kelvin Kent ]
         o The Comedy of Eras (1940) [SF] [as by Kelvin Kent ]
         o Man About Time (1940) [SF] [as by Kelvin Kent ]
         o Hercules Muscles In (1941) [SF] [as by Kelvin Kent ]
         o Dames Is Poison (1942) [SF] [as by Kelvin Kent ]
         o Swing Your Lady (1944) [SF] [as by Kelvin Kent ]

   * Probability Zero
         o Blue Ice (1943) [SF]
         o Corpus Delicti (1943) [SF]

   * Tony Quade
         o Hollywood on the Moon (1938) [SF]
         o Doom World (1938) [SF]
         o The Star Parade (1938) [SF]

   * Tony Quade/Gerry Carlyle
         o The Energy Eaters (1939) [SF] with Arthur K. Barnes
         o The Seven Sleepers (1940) [SF] with Arthur K. Barnes
               + Variant Title: Almussen's Comet (1940) [as by Arthur K. Barnes ]

The good thing about this approach is that it will summarize all Series data at the top of the Summary page and help identify any problems with them, e.g. it turns out that we currently have two "Tony Quade" series. The bad thing is that it can make the top part of the page appear too busy with minor series like "Probability Zero" appearing before Novels. One obvious alternative would be to have a separate "Short Fiction only" Series section before the Short Fiction section. Which one do you prefer? Any other approaches that we should consider? Ahasuerus 16:14, 1 May 2009 (UTC)

I suggest choosing between (1) ALL series at the top or (2) adding Short Fiction Series and Non-Genre Series (if we want -- whether to have Non-Genre Series is a side issue) and making all of the post-Anthology series be "pure" -- series containing exclusively titles of that particular type. Either of these approaches avoids the "empty series" problem for mixed-title-type series. #1 will result in all series being displayed, but in a big group at the top with no logical ordering beyond name. #2 has a potential problem of mixed-title-type series not including Novel, Collection, Omnibus, or Anthology being omitted. Whether #2 is a practical problem, I haven't yet investigated. There is a third approach, which is inelegant from all sorts of points of views: (3) Each series group could be restricted to displaying series of titles of its type together with titles of any subsequent type on the page (but NOT series containing titles of preceding types). This would ensure all series are displayed somewhere. --MartyD 17:49, 1 May 2009 (UTC)

When you say "ALL Series", do you mean all types including Editor, Essay, etc? I don't think we would want them to appear along with regular fiction series since they are really different beasts. Ahasuerus 04:23, 2 May 2009 (UTC)

When I say "ALL" I do mean all. I am thinking not just about the missing Short Fiction series, but also the appearance of "empty" duplicates of previously displayed series. At the root is no enforcement of homogeneity of title types within a series. The Series sections are built by asking for all series where ANY title has the desired type (except for Fiction Series, which looks for N/C/O, all of the other series sections look for just one type). The bibliography display, however, also goes to great lengths to display Titles only once. So to avoid "empty" series, any series previously displayed in some other section would have to be eliminated just as is done with the titles. A very simple way to do that is to put all series up front and avoid trying to have type-specific Series sections, since type-specificity isn't guaranteed anyway. That's (1) above. Another way to do it is to filter out series that have been displayed already in some other section. That's (3) above. Another way to avoid the problem is to present only the container series with heterogenous title types and to restrict the other series displays to only series with homogenous title types. That's (2) above. There's a fourth choice, which is to throw SF into Fiction Series instead of giving it its own section; I've included it in this summary:

1. Single series section
• PRO: no empty series, no missing series, no location ambiguity, independent of title types, easy to implement, backward-compatible in the API
• CON: "pure" series intermingled with no organization, possible excessive up-front "clutter"

Homogenous-only series sections (for the later, non-container sections)

• PRO: no empty series, better location of "pure" series, less up-front "clutter", easy to implement
• CON: mixed-type non-container series omitted, location may not be obvious (one N + many SF will be in F Series, not SF series), not backward compatible in the API (or extensive API additions)

Series in first applicable section only

• PRO: no empty series, missing series unlikely, better location of "pure" series, less up-front "clutter", backward-compatible in the API
• CON: location display-order dependent and may not be obvious (one N + many SF in F Series, not SF Series; one SF + many Essay will be in SF Series), hard(er) to implement

Add SF to Fiction Series (instead of being its own section)

• PRO:missing series less likely, easy to implement, semi-backward-compatible in the API
• CON:empty series, poor location of "pure" SF series, medium up-front "clutter", does not work for Non-Genre

This assumes we really don't want titles duplicated in the display. Also note that all/any of this is simply changing the display, not the structure of the underlying data. Having written this, my opinion is that either #1 or #3 would be best, depending on which behavior people prefer. I like #2 the least, and #4 leaves something broken. #4 can also be incorporated into #3. --MartyD 12:05, 2 May 2009 (UTC)

There is another, relatively minor, issue that needs to be discussed. If we are to include Non-Genre novels in Fiction Series, then we will need to designate them accordingly. We currently use "[SF]" for Short Fiction, "[C]" for Collections, "[O]" for omnibuses and "[NF]" for Non-Fiction, so "[NG]" would seem logical for Non-Genre (unless it's too obscure.) Also, at least one user has asked to display "[N]" next to Novels, which are currently not marked since Novel is the default Title type when displaying series. Ahasuerus 16:36, 1 May 2009 (UTC)

Bump since Marty's edits were invisible earlier today due to, um, a not entirely successful experiment. I am still trying to absorb his comments since sentences like "no enforcement of homogeneity of title types within a series" make my CPU, er, I mean my brain hurt a bit. What can I say? Moral obsolescence may be setting in ... Ahasuerus 00:58, 3 May 2009 (UTC)

I must admit that after looking at the example I wonder why we have a "Tony Quade/Gerry Carlyle" series and separate "Tony Quade" and "Gerry Carlyle" series too without them being connected. BLongley 01:21, 3 May 2009 (UTC)

The reason that these series are currently not connected is that there is no easy way to see them. At this time, for a Series to be displayed at the top of its author's Summary Bibliography page, it has to have at least one Novel, Collection or Omnibus in it. If it doesn't -- and many magazine Series do not since they never get collected in a single volume, with reprints spread across numerous different collections and anthologies -- then its constituent short fiction Titles are displayed at the end of the Short Fiction section in no particular order. As a result, few editors get to see the whole picture, so duplicate, related, etc Series never get cleaned up, which is what you see in the Kuttner case. This is one of the major arguments for changing the display logic. Ahasuerus 02:29, 3 May 2009 (UTC)

And I'd quite like the series to be in date order by when they started rather than alphabetical. And I quite like Short Fiction and Long Fiction to show in the same series, but I'd want them separated by long/short category first rather than date. And probably keep the Omnibuses for an "Even Longer Fiction" subsection. BLongley 01:21, 3 May 2009 (UTC)

I'm not sure this is a good example to start with, it makes me head hurt. And we haven't even shown nested series yet. BLongley 01:21, 3 May 2009 (UTC)

Re: "no enforcement [yadda yadda]". What I'm really saying is the display is pretending there are "types" of series -- corresponding to the types of titles -- but it looks to me like any type of title can be included in any series, so the underlying database and code does not really support that concept (or does only to some degree, which is why there is odd behavior). --MartyD 01:54, 3 May 2009 (UTC)

That's exactly right. I remember Al making a comment about it. Ahasuerus 02:41, 3 May 2009 (UTC)

Short and Long Fiction already do show in the same series. See all three series under Henry Kuttner. What doesn't show up is a series with only Short Fiction. Short Fiction Series is not displayed because it ends up being a mess when there are mixed-title-type series, such as in Kuttner's case. And not having the Short Fiction Series causes the odd date mis-ordering you see at the end of his Short Fiction section (those out-of-order titles belong to a series and are not intended to be displayed where they appear). --MartyD 01:54, 3 May 2009 (UTC)

As for alternative sortings, etc., that's an interesting idea, but a different issue. Looks like we should start a Sorting Wish List somewhere. :-) --MartyD 01:54, 3 May 2009 (UTC)

Agree. This mini-project is just a "proof of concept", i.e. proof that we can modify software behavior [edit:] without Al's active participation and not have it explode in various spectacular and fascinating ways. That's why my original thought was to simply add "Short Fiction" and "Non-Genre" to the list of Title types that trigger the Fiction Series section. I guess it's option number 4 on Marty's list, but I am not sure why it would exacerbate the "empty series" problem or not work for Non-genre? Ahasuerus 02:41, 3 May 2009 (UTC)

It won't exacerbate anything, but it will leave the problem unfixed and popping up in various places (which I gather has been seen with regard to "empty" series in the Anthology Series section -- that's the same problem). If you want to have the display work mostly the way it does now, with addition of Short Fiction Series and Non-Genre Series, I suggest we try #3 (add NG and SF series prior to their respective non-series sections, filter out series previously displayed on the page, add the proposed [NG] tag to Non-Genre titles in the Fiction Series section) and see what people think. It is the most work, but least outwardly disruptive and fixes the two main bugs (missing info, empty entries). We could then look at reorganizing and/or consolidating the series sections as a follow-on step (and I have a feeling there will be other bugs that should be fixed first). --MartyD 11:49, 3 May 2009 (UTC)

Works for me! Ahasuerus 15:51, 3 May 2009 (UTC)

Since this is a test change and there is no opposition, I think we can proceed and see what happens. In the meantime, we can start working on prioritizing bugs/features so that we would have a "pipeline" with some changes being implemented while other proposed changes are still being discussed. Ahasuerus 01:22, 4 May 2009 (UTC)

Sounds good to me and yes I hope nothing implodes. :-)Kraang 01:49, 4 May 2009 (UTC)

For a seriously messed up series display, see Brian W. Aldiss. Several series, such as Hothouse are missing completely, and Enigma -- a nested series -- is put under Essay Series (because some of the nested series contain an essay) with only a select few of the sub-series included.... --MartyD 16:27, 4 May 2009 (UTC)

"Hothouse" could be patched up by adding the eponymous fix-up novel to the series, but overall it's a rather spectacular mess. Aldiss is also responsible for The Horatio Stubbs Saga, a Non-genre series, so he is a pretty good guinea pig. Ahasuerus 17:05, 4 May 2009 (UTC)

(Unindent) I have not read ALL of the above, but I do have one thing to chime in on the topic of "Series". Why does a pub have to 'disappear' once it's been assigned to a series? Not everyone is even cognizant that some of these (stretched) series even exist. I've searched for pubs only to find they are the third variant in some imaginary series. Why can't a pub exist as a novel/collection/omnibus AND show up in the series of its' choice?? I find Poul Anderson's page impossible to navigate; Gordon R. Dickson; Andre Norton; Frederik Pohl; and many others. Not user-friendly. --Bluesman 05:09, 5 May 2009 (UTC)

I don't know the reasoning behind the current behavior. I've found myself bitten by it, too. I misspoke about it slightly: titles can be displayed multiple times, but displaying them in a series removes them from further display. So putting all series at the end in theory would allow the titles to be displayed both in the proper non-series spot and in the series. Another variation to consider down the road. --MartyD 10:16, 5 May 2009 (UTC)

General interest magazines

We have a section for "General Interest Magazines with SF Content" on the Magazines page. I can see how it can be useful to have a list of links to the likes of Argosy, Boy's Life and Playboy in one place, but with the steady increase in the number of non-genre magazines that we cover [bits and pieces of], I wonder if we can realistically have all of them listed together and still keep the list manageable? If not, how can we best handle them? Ahasuerus 08:27, 1 May 2009 (UTC)

Did you take May 31st off?--swfritter 17:46, 1 May 2009 (UTC)

I don't think I am familiar with "May 31st". Is it a magazine? I can't find any references to it in that Wiki page's History... Ahasuerus 18:10, 1 May 2009 (UTC)

I think we should retain a list of such magazines for those who need quick access. But I don't think we need to create individual Wiki pages for each title. Perhaps we should just remove the list from the SF magazines page, create a specific page for this list of titles, and place a link to the page from the SF magazine page (just as we handle fanzines.) MHHutchins 15:22, 1 May 2009 (UTC)

Definitely no wiki pages for each title. They should have a page of their own - one page would work for now although we may soon need some sub-headings. These pubs are not likely to be accessed very often by the casual user. As they start getting more complete we will primarily need to access to check and see if an issue is already in the database. In some cases we may eventually have to consider merging editor records. I have been reading a little bit of Bleiler's "Science-Fiction: The Early Years" each day. It's a wonderful book that has plot summaries for thousands of works that were published before 1930. Many novels but also a lot of short stories in both magazines and collections. I may start putting a few of these in each day which will substantially increase the number of non-genre magazine entries.--swfritter 17:45, 1 May 2009 (UTC)

I think we are already able to get a list of non-genre magazines by searching on "Editors of" in the database. I suppose the fact that the regular Search form won't let you see anything past the first 100 hits is reason enough to have a separate Wiki page... Ahasuerus 02:46, 3 May 2009 (UTC)

If I don't hear anything more I will create a new page in the next couple of days. The reference to that page on the magazines page does not need to be prominent since this is data that will be rarely accessed via the pub level. I might also but a link to the fictionmags site for people who are looking for more complete data for such magazines.--swfritter 20:38, 3 May 2009 (UTC)

As a side issue. When I first began entering non-genre magazines I was creating editor series while others had the good sense (and wiki acumen) to link by editor name. The series methodology requires more maintenance so I have changed all the non-genre magazines to link by editor name - most of them were already that way. Would it makes sense to totally remove the series links?--swfritter 18:21, 1 May 2009 (UTC)

I agree that linking by editor name seems like a better approach in this case. Ahasuerus 02:46, 3 May 2009 (UTC)

Help:Screen:Moderator updated

I have added a paragraph to Help:Screen:Moderator to cover what moderators can do on the Wiki side that regular editors can't. Corrections/additions welcome! Ahasuerus 04:58, 2 May 2009 (UTC)

Title type tags in bibliography display

The changes to the display of Series in the bibliography (see the discussion above) has uncovered a need for some additional tagging of titles to indicate the title type (e.g., Spending My First $100M (2009) [SF] -- "[SF]" is the "tag"). This is currently done only in the Fiction Series section and only for Anthology, Collection, Omnibus, and Short Fiction titles. All other title types in Fiction Series are untagged, as are all title types in all other Series sections.

I believe the intent of the code is to tag everything other than titles with the "default" type for the series. E.g., Fiction Series would tag everything but Novel, Essay Series would tag everything but Essay, and so on. I am making it actually do that, but many "tags" have not been defined.

I propose introducing abbreviated tags for each type of title for which there is a corresponding Series section and unabbreviated tags (using the title's type) for everything else. Here is a table of what I propose. Green rows are types that have Series sections today. Blue rows will have series sections in the near future. Yellow rows have no series sections. BOLD in the "Proposed Column" tag is new.

Title Type	Current Tag	Proposed Tag
NOVEL1		(none)2
COLLECTION1	[C]	[C]
OMNIBUS1	[O]/[O<type>]	[O]/[O<type>]
SERIAL		[SERIAL]
EDITOR		[ED]
ANTHOLOGY	[A]	[A]
NONFICTION		[NF]
CHAPTERBOOK		[CHAPTERBOOK]
NONGENRE		[NG]
xxxART		[xxxART]
SHORTFICTION	[SF]	[SF]
POEM		[POEM]
ESSAY		[ES]
REVIEW		[REVIEW]
INTERVIEW		[INTERVIEW]

¹These all appear in a single "Fiction Series" section.

²There is a proposal to use "[N]".

I am soliciting opinions on whether abbreviations should be used for all of them and for specific abbreviations/tags to be used in any particular case (suggest alternates for the abbreviations I've proposed, too). Thanks. --MartyD 11:54, 5 May 2009 (UTC)

[NF] sounds reasonable, but I suspect that the rest of the new types will appear outside of "their" Series type so infrequently that our users will have a hard time remembering what, say, "ES" stands for. Should we spell them out? (I'll check the latest backup tomorrow to see what the numbers look like at the moment -- unless you already have the numbers handy.) Also, CHAPTERBOOKs are a whole different headache, but there will be time to revamp them later. Ahasuerus 04:05, 6 May 2009 (UTC)

More long-form ones is certainly easy; those are just the title type string and are used instead of a hard-coded abbreviation. From the 4/25 back-up. Count of types appearing in any series:

+--------------+----------+
| title_ttype  | count(*) |
+--------------+----------+
| NOVEL        |    21709 |
| ESSAY        |    11001 |
| SHORTFICTION |     4698 |
| ANTHOLOGY    |     2009 |
| OMNIBUS      |     1427 |
| EDITOR       |     1343 |
| COLLECTION   |      824 |
| NONFICTION   |      493 |
| NONGENRE     |      153 |
| POEM         |      134 |
| SERIAL       |       83 |
| INTERIORART  |       37 |
| CHAPTERBOOK  |        1 |
| COVERART     |        1 |
| INTERVIEW    |        1 |
| REVIEW       |        1 |
+--------------+----------+

Count of non-N/C/O types appearing in a series with some other type:

+--------------+----------+
| title_ttype  | count(*) |
+--------------+----------+
| SHORTFICTION |     3699 |
| ESSAY        |     1627 |
| ANTHOLOGY    |      314 |
| NONFICTION   |      152 |
| EDITOR       |      145 |
| POEM         |      109 |
| SERIAL       |       83 |
| NONGENRE     |       32 |
| INTERIORART  |       23 |
| CHAPTERBOOK  |        1 |
| INTERVIEW    |        1 |
| REVIEW       |        1 |
+--------------+----------+

Looks like there is a coverart series out there.... --MartyD 10:15, 6 May 2009 (UTC)

Can we please get rid of "chapterbook" entirely? Chapbooks have been around for centuries. "Chapterbooks" didn't exist until some teachers in the past decade or so wanted to build their students' self-esteem about progressing from illustrated story books to non-picture books with chapters. MHHutchins 04:07, 7 May 2009 (UTC)

It would be easy to change the display logic, but the term "CHAPTERBOOK" is also embedded in dropdown lists and in the lists of values allowed in certain database fields and in the validation logic and... well, you get the picture :) I am sure it's doable, but it's probably best handled as a separate change, in part because it will require a database tweak. Ahasuerus 04:40, 7 May 2009 (UTC)

All seem reasonable to me. I am especially looking forward to NG, NF, and ES. Kevin 00:42, 8 May 2009 (UTC)

Now that these are present and visible to all, I'm soliciting feedback. I suggest adding a subsection (=== [existing tag] ===) below this point to discuss any particular tag. --MartyD 20:07, 11 June 2009 (UTC)

SF

Can we please change "[SF]" to "[Short]" or some other code that does not also stand for "Science Fiction"? See Source Forge FR #2805039 (Change display of shortfiction in series). This request has ben on the Wiki as Feature:90157 for some time. -DES ^Talk 20:28, 11 June 2009 (UTC)

I can support this idea, particularly as SF might also mean "SourceForge"! ;-) Just what do we change it to? "[Short]" might imply Shortstory as opposed to Novella or Novelette. BLongley 22:34, 11 June 2009 (UTC)

Can you do [NA], [NV], [SS], and [Sh] instead of [SF]? Can the code read the title length? That would be fantastic! Kevin 01:48, 12 June 2009 (UTC)

If you do this, i suggest [NT] instead of [NA] to avoid the latter being read as "Not Applicable" which is often abbreviated NA or N/A. We will probably need some readily available index or caption to these terms -- perhaps the abbreviate ions could link to a wiki page which explains all of them or perhaps there could be one such link somewhere on each biblio page? -DES ^Talk 05:06, 12 June 2009 (UTC)

The display is using the title, so IF a title has a length available, we could certainly make use of that. For SHORTFICTION titles as of a couple of months ago, these are the lengths:

+----------+----------------+
| count(*) | title_storylen |
+----------+----------------+
|    62666 | ss             |
|    18856 | sf             |
|    18811 | nt             |
|     5667 | NULL           |
|     4704 | nv             |
|       22 | -              |
|       19 | None           |
|       16 |                |
|        6 | shortfiction   |
|        5 | na             |
|        3 | White Noise    |
+----------+----------------+

Note that what you see for the length does not have to be what is displayed to represent it. All of the tagging can use any text we want it to. --MartyD 10:20, 12 June 2009 (UTC)

Chapterbook

Do please change the display logic on this at least. I am hopeing that eventually this will be converted into a fully supported SHORT WORK type, but one step at a time. -DES ^Talk 20:28, 11 June 2009 (UTC)

It can be done, but needs work in a lot of places, almost as much as adding or changing to "SHORT WORK" or whatever. And a lot of rules and standards agreement - we have genuine self-proclaimed chapterbooks but they're not always single-item things, they're COLLECTION and ANTHOLOGY types really too, not always one SHORTFICTION published standalone. So we'd be undoing a lot of the workarounds already in place. Something I'd like, but no Developer can go do something that keeps everyone happy, the Designers need to get involved first. BLongley 22:44, 11 June 2009 (UTC)

Yup, we definitely need to decide what we are going to do with the whole "Chap(ter)books issue" first. Converting them to a "container type", with a separate section reserved on the Summary page, was the leading contender the last time we talked about it and we can probably pull it off now, but we need a more detailed design. Ahasuerus 00:09, 12 June 2009 (UTC)

Serial

I think we should reconsider the 'Serial' display on the bibliography page (Can this patch be applied to the series display pages - I would like it there - All parts I think). Unless there is a compelling reason for it (Any Serial title in a series, will normally (always?) have a novel title in the same series and already be displayed). See Poul Anderson and his serialized 'Iron' near the bottom of his fiction series stuff. Since the serialization is (correctly in my opinion) in the series, and the full novel title is in the series, it is being displayed twice on his bibliography. Kevin 02:17, 12 June 2009 (UTC)

If we remove the Series designation from the two SERIAL records, they will still appear under the associated NOVEL record, which will address the immediate problem. We still need to address the larger "lexical match" issue, but that will have to wait at least a few weeks. We could probably fix the "lexical match on ANY author" bug real quick, though -- see the way Harry Harrison's To the Stars is currently linked to L. Ron Hubbard's 1950 SERIAL that uses the same title.

But those two 'serials' appear in that hybrid Baen paperback magazine. I don't recall if it was destinies, new destinies, etc. People looking at the book contents should see an appropriate series call out for that story. Kevin 04:27, 12 June 2009 (UTC)

As far as applying the logic from the last patch to the Series page, it is definitely desirable and has already been requested on Sourceforge -- see Feature 2804561. Ahasuerus 04:04, 12 June 2009 (UTC)

ISFDB Downtime

ISFDB was down much of Monday and Tuesday due to two separate and seemingly unrelated software failures. This is rather puzzling, but hopefully it won't happen again. In the meantime, please keep in mind that we have two backup areas, one at http://groups.google.com/group/isfdb and the other one at http://isfdb.blogspot.com/ , where we post downtime announcements when the Wiki is not available. Ahasuerus 04:05, 6 May 2009 (UTC)

I've been getting several timeouts recently - I hope this isn't due to testing the live server against proposed changes? BLongley 22:46, 11 June 2009 (UTC)

Nope, there has been no testing going on on the live server. As far as I can tell, it occasionally decides to refuse all connections for a few minutes. Unfortunately, I haven't been able to find the root cause :( Ahasuerus 00:05, 12 June 2009 (UTC)

Alan Moore and Co

[Moved to Rules and standards discussions]

Local copy of ISFDB on Windows

I've put together a set of instructions at ISFDB:Personal_Windows_Website for setting up a private copy of the ISFDB in a Windows environment. It's adapted from the Linux instructions and is based on a sample of one, so I'm sure some tweaking will be required. Leave a note at User_talk:MartyD if you try it and need help getting it running. And of course feel free to augment/clarify what's there based on your own experiences. --MartyD 10:33, 13 May 2009 (UTC)

Wonderful, thanks! I took a peek yesterday night, but had to run and fight other fires. I'll give it another shot tonight. Ahasuerus 17:35, 13 May 2009 (UTC)

Apache installed, no problems encountered. The MySQLdb installation program, on the other hand, found a problem with my version of Python, apparently due to the fact that at one point I upgraded Python to 2.6, realized that it was causing issues with some older scripts and downgraded back to 2.5. Apparently, the downgrade wasn't as clean as I thought and the current version is some kind of 2.5/2.6 hybrid which is not recognized by MySQLdb. Hopefully, this won't be a problem for anyone else. Ahasuerus 03:39, 14 May 2009 (UTC)

I couldn't get MySQLdb to work with 2.6. I did do a clean uninstall instead of trying to downgrade, though. --MartyD 10:47, 14 May 2009 (UTC)

I had ActivePython installed since I use it to talk to library catalogs. I have now installed regular Python instead, which had some side effects, but that's another story. I already had MySQL and Cygwin, so adding the make/CVS functionality wasn't too troublesome. There was a minor glitch with permissions when installing the ISFDB scripts, which I documented on the instructions page. At this point everything looks OK and Apache can serve static files (localhost/isfdb.gif etc), but it refuses to recognize the existence of any cgi scripts:

[Fri May 15 00:22:04 2009] [error] [client 127.0.0.1] (OS 3)The system cannot find the path specified.  : couldn't create child process: 720003: history.cgi
[Fri May 15 00:22:04 2009] [error] [client 127.0.0.1] (OS 3)The system cannot find the path specified.  : couldn't spawn child process: C:/Program Files/Apache Software Foundation/Apache2.2/cgi-bin/history.cgi

I played with httpd.conf to the best of my (limited) ability and even added ExecCGI to the list of options, but it didn't help. ScriptAlias seems to be configured properly:

ScriptAlias /cgi-bin/ "C:/Program Files/Apache Software Foundation/Apache2.2/cgi-bin/"

Oh well, I'll give it another shot tomorrow. Ahasuerus 04:33, 15 May 2009 (UTC)

This is the error you get if there is no c:\usr\bin\python.exe for the cgi scripts to run. The ISFDB build/install process pretty much hard-codes this path (you'll see it at the top of the Apache2.2\cgi-bin\history.cgi you were trying to run). The easiest workaround is to mkdir c:\usr\bin and then copy python.exe into it from your python installation. If we get to the point of being able to make tweaks, I will add customization of that location to the build/install process. --MartyD 10:10, 15 May 2009 (UTC)

That did the trick -- thanks muchly! :-)) Ahasuerus 14:13, 15 May 2009 (UTC)

Hmmm. I don't actually have a c: drive (well I do, but it's an SD card reader with no card for it) so I think I need the customisation. BLongley 17:48, 15 May 2009 (UTC)

Sorry, it doesn't have to be C:. There is no drive specification in the CGI files, so it needs to be on the same drive as the working directory for the Apache process. By default, that will be the drive onto which Apache was installed. --MartyD 18:02, 15 May 2009 (UTC)

OK, I might give it a go this weekend. I've got Apache and MySQL working already, although not the same versions. Sounds like I ought to replace the ActivePython though. (Not a problem, I've never used it.) BLongley 18:39, 15 May 2009 (UTC)

As a prize for getting it running, I can send you the proposed series changes to try out. --MartyD 00:39, 16 May 2009 (UTC)

Proposed New Feature - Reviewed Author search

Since MartyD helped me get a local ISFDB working I've been playing around a bit. What do people think of this? How many want it? Is it in the right place, under the right name?

BLongley 18:49, 18 May 2009 (UTC)

Looks great, and would be a tremendous help in getting rid of those authors with only invisible records. Thanks. MHHutchins 19:31, 18 May 2009 (UTC)

Thanks to Kev Pulliam for the suggestion. Now all we need is for me to relearn CVS and one of the Sourceforge Admins to add me as a Developer and someone to explain how and when such changes can be deployed... (Ahasuerus, can you deploy code on the live server?) BLongley 20:03, 18 May 2009 (UTC)

I'd encourage more people to try the local installation of ISFDB so we can get more testers involved. While I am of course an absolutely brilliant programmer and there can be no possibility of my activity introducing any "bugs", I may introduce unwanted "features". ;-) So more people testing offline would be good. BLongley 20:03, 18 May 2009 (UTC)

I vote yes. Looks great. (And I've even dusted off a WinXP laptop to see about doing a local install for testing and or simple coding myself) Kevin 22:57, 18 May 2009 (UTC)

Al and I are trying to make it possible for me to bounce the Web/MySQL servers. As a side effect, it may also enable me to deploy software changes, but if I tried that, I would more than likely cause a catastrophe of mind boggling proportions. (Or at least cause extended downtime and force us to go back to the backups.) Al is still our best bet, but if he is not available, we'll have to think of some other way. Perhaps we could create "change packages", cross-test them and see if Al could install them once every 2-4 weeks rather than on an ad hoc basis? Ahasuerus 00:30, 19 May 2009 (UTC)

I think (but am not sure) that I've checked in edits to three modules that will enable this functionality. Anybody that can download and try it out, please do! I'm going to reserve some of the other changes till I can see if this worked. BLongley 20:53, 20 May 2009 (UTC)

The activity tab under https://sourceforge.net/projects/isfdb/ reports that:

1. blongley committed patchset 159 of module isfdb2 to the ISFDB Bibliographic Tools CVS repository, changing 1 files, 1 hour ago
2. blongley committed patchset 158 of module isfdb2 to the ISFDB Bibliographic Tools CVS repository, changing 2 files, 1 hour ago

I also see your changes at http://isfdb.cvs.sourceforge.net/viewvc/isfdb/isfdb2/edit/ and http://isfdb.cvs.sourceforge.net/viewvc/isfdb/isfdb2/biblio/ and can download them. I'll try to test them locally later tonight. (Hey, this is exciting!) Ahasuerus 21:36, 20 May 2009 (UTC)

There's two separate sets of changes I've made (3 files for "Reviewed Author", then 2 for "Pseudonym Search") - five files in all. And I'm excited too. Or is it "nervous"? I've recently made some "Emergency" changes at work that caused me more work and less worry - you lot are unknown critics! BLongley 23:12, 20 May 2009 (UTC)

Publisher Search Fix

I think I can fix this search:

So it doesn't give:

But this instead:

There's a bit of a problem with the "[100-199]" link at the bottom if that's needed though, so I'm reluctant to release this as an incomplete fix unless someone can test it. BLongley 19:15, 18 May 2009 (UTC)

Wow! Even better. An advanced search that actually works? Go for it, pal! MHHutchins 19:32, 18 May 2009 (UTC)

The options that don't deliver anything but lots of purple look fixable, although purple follow-on pages aren't totally avoided yet. I've got exact "Page Count" searches working for instance, but wonder if anyone would ever use such? BLongley 20:12, 18 May 2009 (UTC)

I've got "Cover Artist" working too - but is "Back Cover Artist" worth fixing? BLongley 20:50, 18 May 2009 (UTC)

I might do "Price" searches though, after all the weird "£4.13" submissions Fixer did recently. It seems only humans are good at spotting weird prices. BLongley 21:12, 18 May 2009 (UTC)

A search for back cover artist would be too specialized for my use. But I'd love to have a boolean search for publisher using a wild character combined with year or author. Would that be a part of your "fix"? MHHutchins 21:16, 18 May 2009 (UTC)

There's always the question of whether anything I do will ever get deployed first. :-( I can look at wild characters next though. Combination searches are something for the future - I still haven't figured out where the "ANDNOT" problem stems from and I thought it would be a simple matter of finding where Al missed a space. :-( But I'll offer my usual Developer/Designer/IT Consultant suggestion - you can have several imperfect improvements "soon", or a perfect one "later". The difference is that for ISFDB there's no cost difference. ;-) BLongley 21:57, 18 May 2009 (UTC)

I'm pretty sure that the ANDNOT problem is very simple. I'm looking at an old version of the code, & also have no way to test it; but if you find the file named search.py & look for the line that says:

	print '<input TYPE="RADIO" NAME="%s" VALUE="ANDNOT">AND NOT' % (operator)

I think inserting a space in the VALUE field will fix it. -- Dave (davecat) 11:27, 1 June 2009 (UTC)

Bill aready did it in CVS: patch. --Roglo 12:16, 1 June 2009 (UTC)

Soon. Yes Please fix all the purple pages. As to the second page going bonkers, I think there is a bug in the 2nd page results for most searches, as they IIRC change from clickable links to cliable links straight to 'edit'. That might be the true source of the second page problem

I now have fixes for all the main purple pages of Publication Search. Not yet for follow-on pages. It seems people can see my first fixing attempts now on other searches, so I'll wait so see how those are received first before potentially breaking anything else. BLongley 22:49, 20 May 2009 (UTC)

I think I've said this elsewhere, but the code changes for all the broken parts of Advanced search have been submitted, and I think I've covered all the likely follow-on pages too now. I think I'll pause on other changes to allow our tester(s) (more testers welcome!) to assess them and to encourage Ahasuerus to roll them out. BLongley 22:44, 23 May 2009 (UTC)

I don't think backcover artist data entry was ever implemented although there is a field for it.--swfritter 00:17, 19 May 2009 (UTC)

The polite term is "partially implemented" :-) 00:20, 19 May 2009 (UTC) —The preceding unsigned comment was added by Ahasuerus (talk • contribs) 00:20, 19 May 2009 (UTC).

Dangit - you guys are teasing me - I saw a comment of 'Partially implemented' and thought it was already up and running. (chuckle) That's kind of like having a Hay Baler, and no Hay Rake. Only Partially Implemented. Kevin 00:25, 19 May 2009 (UTC)

Perhaps it can be done through the Web API? Have we sent Kevin on a snipe hunt yet?:-)--swfritter 00:31, 19 May 2009 (UTC)

Do the snipes live in the Briar Patch? Kevin 01:52, 19 May 2009 (UTC)

"Snipe" is a notorious Back-Cover artist, but as secretive as Banksy. Indeed, Banksy may be the artist for several back-covers. Or front covers. Your mission, should you decide to accept it, is to find the Back-Cover artists, identify them, and create suitable pseudonyms. BLongley 22:49, 20 May 2009 (UTC)

But then they will still be Back Cover Artist Pseudonyms... and people will still have trouble finding them. Kevin 02:54, 21 May 2009 (UTC)

Not with my latest fixes. I've noticed (while looking into the "Doctor Who and the Unfeasibly Long Tags" issue) that there are several Back-Cover-Art entries recorded in notes. So there's obviously a small desire to record such. If we can actually enter them, my changes will find them. I think there's a lot of other places where we need to add the code to display them though. Still, has anyone successfully submitted any yet? BLongley 22:39, 23 May 2009 (UTC)

(Unindent) OK, I've found a couple more publications that could do with Back Cover Artist entries: Science Fiction Monthly, July 1974 and Science Fiction Monthly, August 1974. Does anyone else think this is worth working on? BLongley 21:05, 31 May 2009 (UTC)

Perhaps Interior Artist search would be more useful for now? I think it is the same search, just with INTERIORART instead of BACKCOVERART. --Roglo 21:17, 31 May 2009 (UTC)

We can add that search too, but I was actually asking about being able to enter Back Cover Artist. The search changes are already made for that, but are pretty pointless if we don't actually have any. But it stops the big purple errors. BLongley 22:26, 31 May 2009 (UTC)

The only references to BACKCOVERART are in SQL code (plus bib.displayWorks('BACKCOVERART'), so that it could show up in bibliographies). I don't think it is possible to create a BACKCOVERART without access to the SQL server. You can create multiple COVERART records for a single pub if you are persistent enough (and conspiring with a moderator). --Roglo 13:11, 1 June 2009 (UTC)

It might be possible to create them via the Web API, I haven't checked. But I'm actually asking about whether it would be worth making them more easily enterable, or possible, if the display code is already there. It seems a shame to leave it partially implemented. I doubt it's worth a lot of effort for the few pubs I've identified that could do with it, but it might be for some people that are using "bc" page codes. Or people that want to indicate that there is a wraparound cover and the art is on the back too. There's probably not enough reason to add more fields like "Artistn" to the editpub screen, but it could be an allowable content type like INTERIORART is, for those that really want such. BLongley 19:33, 1 June 2009 (UTC)

A smaller fix

The Publication area of Advanced Search has lots of broken bits, but the Author Search has only one I think. Pseudonyms. I can change this:

to this:

and although I can't (and so haven't) tested the follow up page I can't think of anyone with over 100 people using the pseudonym, so am fairly happy for this to go forward if I've got the intended purpose right. BLongley 22:18, 20 May 2009 (UTC)

OK, that looks awful - my screenshots are worse than my coding (I hope!). But if the idea is that you put in the pseudonym and get the canonical author(s) I think I'm on the right lines. I think I'll check that in while I still remember how, and leave the "Pseudonymns" typo for a later fix. BLongley 22:24, 20 May 2009 (UTC)

Use of varients for different texts

I just noticed that In Fury Born is listed as a variant title of Path of the Fury. Nowe the copyright page says that In Fury Born "Contains a much revised version of Path of the Fury". This appaears to be accurate. Roughly 2/3rds of the text of IFB is new, the remaining third is a reworked version of PotF, with a fair amout of rewriting, but no essential change in the story, and much text unchanged. It seems to me that linking two works with as much difference as this is not what VTs are for. It also means that IFB does not show up in its nornal place on David Weber, and a user could easily think, looking at that page, that IFB was only a retitling of PotF. I would like as clearer policy on what VTs should and should not be used for. In particualr, is it or is it not appropriate to link as VTs two works that are related but significantly different, such as expansions and revised versions. Obviously whe4n and if we get some sort of "based on" or "related work" link in the software, that will be the way to go, but we don't have one now. -DES ^Talk 05:07, 22 May 2009 (UTC)

You may want to see this recent discussion of variant titles.... FWIW, in Poe's case, where the text is significantly altered (beyond changing a name or adding/dropping a couple of leading lines) I've gone with separate titles and notes. --MartyD 09:53, 22 May 2009 (UTC)

And if you've read that discussion you are probably as exhausted as I am from re-reading it. There is no real quantitative measure. There are stories that are 99% identical except for the last paragraph that should be entered as separate titles and others that might be substantially different that could justifiably be merged if the titles are identical or made variants if not. The most important thing is to fully document the information in the title notes. I agree, we should have some general guidelines but I have no idea how it could be worded. My own opinion on the above case is that the two versions are so radically different that they should be separate titles.--swfritter 14:33, 22 May 2009 (UTC)

The current variant function only works well enough to record a difference in title or author credit. It is unable to record a difference in text. There should be software support for an entirely different function for that purpose. And until there's someone who can do that, this topic, just like many discussions that have preceded it, sadly, will be a waste of time. We don't need to fret over quick fixes that will have to be corrected sometime down the line. As Swfritter points out, recording information in the notes is the only way to do it at the present time. MHHutchins 15:23, 22 May 2009 (UTC)

Well then.. lets try to 'solve the problem' - Could we 'clone' the Variant code and call it 'Expanded Variant' or something similar. It seems to me that would involve the least work (duplicating a present function), and just changing the name and descriptions... Instead of (AKA 'The Original Title') in a contents listing it could show (An Expansion or Derivative Work of 'The Original Title'), and so on and so forth. I bet that once we 'clone' the function once, we will then immediately want to clone it again for 'Abridged Variant' or something similar, And then perhaps a third time for 'Juvenile Variant', and then perhaps a fourth time for 'Screen Adaptation (Teleplay, Screenplay) Variant', and then a fifth time for 'Graphic Novel Variant', and then a 6th time for the reverse 'Novelization Variant' but that perhaps will need more codeing... anyway... Many birds.. one stone, film at eleven Kevin 03:36, 23 May 2009 (UTC)

When it gets implemented it will probably be a relatively simple fix and one that will allow for easy expansion of variant processing definitions. A flag could be added to designate whether the variant type is "variant title", "variant text", etc. and a set of rules involving processing procedure for each type could be defined. Maybe someday.--swfritter 13:29, 23 May 2009 (UTC)

Once we are going with new code, i hope we can fully implement "based on" relationships to handle varient text, fixups, expansions, condensations, revised versions, and the like, and make clear which is which. This means allowing for multiple targets, and/or allowing a given work to take part in multiple "based on" relationships.

In the meantime, I think VT relationships between works with significantly different text, including expansions, should be broken, and the relationship documented in notes, and for fixups at least, in tags. -DES ^Talk 15:06, 23 May 2009 (UTC)

I think the relationships should be kept. Assuming we get the fixes, it'll be much easier to find which relationships need adjusting if we have them rather than starting from scratch with people reading notes on unrelated titles. This does not, of course, stop people from recording notes which will help when we get to that point, or even in the meantime. I'm not fond of Tags as they seem a lazy way of recording incomplete notes, and would prefer people use pub notes or even the Wiki for proper notes on the publication records they know about. There's a whole concept of "edition" that is lacking at the moment that we can do something with in the meantime with (revised) (expanded) (abridged) or other suffixes on titles, but that will be lost if a different title is a revision, expansion, or abridgement of another and there's no variant link. BLongley 22:27, 23 May 2009 (UTC)

We need or at least should have, the notes, whether the VT is broken or kept, if the final version is to be at all accurate. I am inclined, by the way, to think such notes should usually be title-level rather than pub-level, but either is better than nothing. Take a look at what I have done with Path of the Fury, where I did break the VT. -DES ^Talk 23:22, 23 May 2009 (UTC)

Agreed on the notes. Recording at every level possible in the meantime is good. However, breaking the VT now just means that somebody will have to reconstruct it later when they find the notes. There is no way that the people that fix the software will be also able to provide a list of things that need looking at after the fix, as there is nothing left in the database to suggest there is any kind of relationship. "Notes, notes and more notes" helps. Breaking links that are there for a reason, however poor the reason may be by current standards, doesn't help. I repeat - keeping the links and noting on both sides is better. How would you feel if I broke every current variant US/UK title that didn't have an explanation recorded on both sides? The variants are there for a reason: yes, it's good to add more notes, but if you're wanting software improvements I think it's better to let the programmers also provide lists of current variants that need a second look rather than break the variants and start from scratch. BLongley 00:04, 24 May 2009 (UTC)

Unindent. If you really thank that a full "based on" relationship will be implemented soon, say within the next 9 months or so, AND there there is a reasonable programmatic way to find VTs that represent differing texts short of a manual examination of all VTs, then not breaking existing but (IMO) improper VT links might be a good idea. Note that if links are broken but good notes are added, a query scanning the notes field for such key words as "version" "based on" "expanded" and the like should probably find any such situations where good notes were inserted. This is not starting from scatch. In the mean time, the DB comntains incorrect information, as it seems to me that a VT relationship is a way of saying "these two pubs contain essentially the same text, even if under a differeent title or author". Removing incorrect info and replacing it with accurate data in the noites is IMO a good thing^TM. How do you expect that VTs representing difffering texts can be programatically identifed from among all VTs? -DES ^Talk 01:08, 24 May 2009 (UTC)

For Novel length works - Compare paperback pagecounts if pagecount is not within x pages of the same, flag for review. Same for Hardcover with y pages. For all works, check all variant title and pub notes automatically for 'expanded', 'abridged', etc. By allowing the variants to remain we reduce the first run of variants (to be reviewed in order to apply a different variant type) to the likeliest subset of records to search. I'm with Bill here... it may be technically incorrect at the moment... but it's not completely wrong. Kevin 02:37, 24 May 2009 (UTC)

I don't think that differing texts can be programatically identified, but I think that we can far more easily identify the VTs for humans to look at if they are VTs than if they are not. I know I'd prefer to have a list of all 23,000 VTs and the things they are VTs of than have to look at all 398,000 titles. And that 23,000 will be much shorter if we can eliminate "same title, pseudonymous authors" and prioritise "massively different page counts" and "notes with certain keywords in". I don't think we've got a massive number of incorrect variants currently, I think you're reading too much into what you see as the definition - VT has never meant "essentially the same text" to me, just that there IS a relationship of some sort. I'd actually like to see more (sensibly noted) variants right now: e.g. Stranger in a Strange Land definitely needs splitting into original and expanded/restored versions at least. The sooner we do it the easier it will be to put each pub under the right version. At the moment, each new pub just gets thrown into the pot and rarely has enough information at pub-level to sort it out. Split NOW and hopefully new additions will get put into the right category. BLongley 06:17, 24 May 2009 (UTC)

I found this ISFDB_FAQ#How_does_the_ISFDB_deal_with_.22Portions_of_this_story_originally_appeared_in....22.3F in my browsing today. Per the FAQ, Variants 'are' an accepted methodology of documenting Text changes "If an individual story is rewritten or revised, then we create a Variant Title for it and add the nature of the changes, e.g. "expanded", "abridged" or "restored", in the Notes section. Please note that these conventions are likely to change in the foreseeable future as we beef up our software in this area." - This may need to be updated, or we may be soon approaching the foreseeable future. Kevin 02:18, 26 May 2009 (UTC)

Single member series

I just noticed 25389 which contains only "The Star". To the best of my knowledge there was no sequel to "The Star", nor any other work which might be in a series with it. Is there any reason not to remove this work from the series, and rename the series for reuse? I don't know who created this series of why, presumably someone had a reason at the time. -DES ^Talk 05:11, 22 May 2009 (UTC)

The story was supposedly also published under the title "Star of Bethlehem" although we don't seem to have that variant in the system. Maybe this was an attempt to document the variant title?--swfritter 13:52, 22 May 2009 (UTC)

Development - status update

At this point we have 3 editors with a locally installed version of the ISFDB application: Marty, Bill and myself. I also have the ability to bounce the Web server and the MySQL database if and when they go down.

In theory, I could also use my newly acquired powers to install the changes that Marty and Bill have been working on, but I need to learn more about the installation process before I can do it safely <imagine a 10 year old at the controls of Bolo Mark XXXIII>. I plan to spend the next day or two recovering after a very eventful fortnight, then I will do more digging and check with Al to see if he thinks that I am ready to install a sample fix. I may also need administrator privileges on SourceForge to keep it up to date, but that's a different story. The bottom line is "soon, very soon (hopefully)". Ahasuerus 21:23, 23 May 2009 (UTC)

If you knew my blood-alcohol levels at times of certain updates you might be even more nervous. ;-) BLongley 23:02, 23 May 2009 (UTC)

Oh, so that's what the smell on that chunk of code was! :) But yes, I realize that we all have our quirks and limitations -- and some of them are hard to diagnose remotely. Besides, we need a single "code master", which is why I may well be stuck installing all the updates for a while. Besides, I am lucky: only 2 emergency landings in all my years of wandering. What could possible go wrong?.. Ahasuerus 04:29, 24 May 2009 (UTC)

But I've tried to keep my updates small and uncontroversial, they're mostly changes to displays and will not corrupt any core data. Hopefully they'll give more data to stop moderators approving controversial edits without research, or help all users search better. BLongley 23:02, 23 May 2009 (UTC)

Ahasuerus, please let me know your Sourceforge account name and I can add you. E-mail off list is faster for getting my attention. --Marc Kupper|talk 02:27, 24 May 2009 (UTC)

I would guess, from the people posting bug reports, that he is "ahasuerus_isfdb". BLongley 06:49, 24 May 2009 (UTC)

I have one general comment about making changes to the code which concerns the notes that accompany a change. Some of the current notes don’t give a background on why the code was changed. For example, one of the notes has “bug fix: add missing non-null columns and values to mw_user insertion” and I can see from the diff that an “insert into mw_user(user_name) values('%s')” was changed to “insert into mw_user(user_name,…,user_touched) values('%s', '', …, '')”. From a Python and SQL syntax view I’m fine with this change and it does fill in values that were not filled in before. However, I don’t know how to reproduce whatever problem this is supposed to fix so that I could then verify that it is indeed fixed. As it is, this particular change puzzles me as the table should either already have default values set for columns that need them and/or MySQL will be filling in the field using the implicit default value based on the field type. I’m guessing the repro is to run MySQL in strict mode and in that case the insert will fail and the supplied change will fix that problem.

Thus a better note would have something like “Run MySQL in strict mode and do an xyzzy. You will get a Python error dump as default values were not provided when inserting new rows into mw_user. This change is to add the missing non-null columns and values.” --Marc Kupper|talk 02:27, 24 May 2009 (UTC)

That started from talks here. It seems the difference between strict mode and non-strict mode on the local MySQL implementation may be important. Use non-strict and the script may work. BLongley 06:49, 24 May 2009 (UTC)

Still, it does re-raise the issue of where we should be talking about changes. I've posted on MartyD's talk-page for installation problems, and posted examples of proposed fixes on the Community portal for general changes and Moderator area for Mod-Only changes - I've also added comments to Bugs and Features on Sourceforge. And there's the mod-list emails and some direct emails too. If we aren't going to use the Sourceforge project forums, then one dedicated area here might be appropriate. I don't really want to repeat myself in 3 or more areas. BLongley 06:49, 24 May 2009 (UTC)

The create_user.py change was mine, in response to all three of us running into the same missing value and no default in a non-null column error while following the MySQL set-up instructions. It didn't occur to me to log a formal bug, since it was just a local environment set-up script. I will make sure there's a but or feature request logged for any future changes. As an aside, I can't figure out how to mark bugs fixed, so I may be a bit Tracker impaired.... --MartyD 01:15, 25 May 2009 (UTC)

What if we start a change akin to something like the commonly-used Change Log, where each major section is a "release", with a minor section for each change. The top section would be "Next Release". Once released, it would get renamed to match the release (however we identify them -- date, number, whatever), and we'd start a new "Next Release" section. Changes could be proposed and discussed or simply "announced" (and discussed after the fact), as appropriate. Links could be dropped into other pages to request feedback on specific proposals. I suppose we might have to use sub-pages instead of sections and MediaWiki's "move" function if we wanted to keep those links intact. --MartyD 01:15, 25 May 2009 (UTC)

(unindent) I have been granted enhanced CVS powers (thanks, Marc!) and I am now playing with bug creation/assigning/closing etc. I also found the source files on the "live" server, but they are in one of Al's subdirectories (which explains why I couldn't find them at first!) and I don't want to touch them without first discussing the issue with Al. In the meantime, I am experimenting with installation options under Windows. Hopefully, this week won't be as exhausting as the last two and I'll be able to get more done. Ahasuerus 03:04, 26 May 2009 (UTC)

Changes present on the live site but missing from the source tree on SourceForge have been incorporated into the respective modules in CVS. --MartyD 00:42, 28 May 2009 (UTC)

Kim Harrison vs. Dawn Cook

According to a recent Locus interview, Kim Harrison is the same person as Dawn Cook. Since the Harrison persona is presumably the better known one, I wonder if we want to make it the canonical name? Ahasuerus 01:56, 27 May 2009 (UTC)

Harrison should be the canonical name, IMHO. MHHutchins 03:34, 27 May 2009 (UTC)

I'm regretting all my work on "Paranormal Romance" (or "Chic-Spec-Fic" as I'm inclined to call it - does my dropping a K mean I get to be the originator of a new term?) so would go with whatever's easiest. BLongley 23:24, 27 May 2009 (UTC)

Signed copies of China Mieville's The City & ytiC ehT

Powell's in Portland will have Mieville signing copies of his new novel on Sunday, June 9. It's getting some very good reviews. You can also pre-order a signed copy (for list price plus 3.95 postage) if you can't be there. MHHutchins 03:49, 27 May 2009 (UTC)

Alisa Kwitney / Sheckley

I just received the second novel by Alisa Sheckley (submitted this), and noticed there is no connection between her two names. She is known as Alisa Kwitney for her novel The Sandman: King of Dreams, and as Alisa Sheckley for The Better to Hold You and her new novel Moonburn. Kwitney is her husband's name, Sheckley her maiden name, and before linking them I was wondering what the canonical name should be. Both Wikipedia and her own website have Kwitney, but since she's Robert Sheckley's daughter, has written mostly mainstream novels as Kwitney, and as Sheckley is writing "paranormal romance" novels, I would prefer Sheckley as the canonical. Any thoughts about this? Willem H. 10:19, 27 May 2009 (UTC)

I prefer Sheckley. BLongley 23:16, 27 May 2009 (UTC)

Sheckley seems to work. Ahasuerus 15:45, 28 May 2009 (UTC)

All votes go to Sheckley, so I started submitting. Thanks Willem H. 08:42, 30 May 2009 (UTC)

Technical issues - Thursday, May 28 2009

Our virtual server was bounced overnight and we are experiencing intermittent loss of connectivity this morning. When a problem occurs, all connection requests time out, but when connectivity is restored, it looks like the Web server and the MySQL server are fine. There is nothing I can do about it at the moment, but I will try to review the log files later today and see if I can find any clues. Ahasuerus 15:43, 28 May 2009 (UTC)

I had similar time-out/connectivity problems a couple different times, spread out over Weds the 27th, primarily during the daylight hours (Say between 8 am and Noon CDT most likely). Because every thing appeared fine once I did reconnect, I assumed the problem was closer to my end than the server end, and I did not make an exact note of the time. Kevin 16:27, 28 May 2009 (UTC)

Will Wikipedia Re-Licensing allow Hot Linking to Wikipedia Images?

I notice that Wikipedia is re-licensing under Creative Commons by Share Alike (CC-BY-SA) on 15 June. Does anyone know if this will allow us to hotlink images from Wikipedia, Wikimedia (As in Authors photographs)? Kevin 03:02, 29 May 2009 (UTC)

Nevermind - I just went and lookup up the linking policy text after asking the question and realized they will probably still restrict that to Wiki-Sister sites, due to the issue of bandwidth theft, etc. Oh well... back into my corner I go. Kevin 03:05, 29 May 2009 (UTC)

However, it now becomes even more likely in any given case that we can download a wikipedia image, and re-upload it here. I have done so in several cases, particularly for author images. -DES ^Talk 14:41, 29 May 2009 (UTC)

AND NOT searches

I am in the middle of testing the software changes that Marty, Bill and Roglo have uploaded to our software repository. One of the things that Bill has fixed is the "AND NOT" Advanced Search so that when you search on, say, "Author (includes) Jo Walton AND NOT Title includes Farthi", you will get a list of all Jo Walton titles that do not include the string "Farthi" in the title. Bill's fix works fine, but it takes a long time to run this kind of search, about 1 minute and 15 seconds on my local server. I assume that MySQL has to traverse the whole Title table and while doing look-ups against the Author table, which can be time consuming. Fir the technically inclined, here is the raw SQL query that is displayed by the software at the top of the search page:

select titles.* from titles,authors,canonical_author where authors.author_canonical like '%Jo Walton%' and authors.author_id=canonical_author.author_id and canonical_author.ca_status=1 and titles.title_id=canonical_author.title_id AND NOT titles.title_title like '%farthi%' order by titles.title_title limit 100

Assuming that we can't improve this query's performance, I wonder if the additional functionality is worth risking a server slowdown while the query is running. If not, then we may want to remove the "AND NOT" option from the Advanced Search page. Ahasuerus 04:10, 30 May 2009 (UTC)

I don't understand how this significantly increases the search time. It should be pulling all records like in a regular search, and then applying the ANDNOT criteria only to that subset. Kevin 04:19, 30 May 2009 (UTC)

I am not sure, but the "AND" version of the search posted above takes 0.47 seconds on my system while the same "AND NOT" search takes 1 minute and 15 seconds, so something must be different. Something to look into on the local development systems before we apply the fix, perhaps? Ahasuerus 04:28, 30 May 2009 (UTC)

P.S. The new "Reviewed Author" search is taking about 12 seconds on my server and Publication search on Cover Artists takes over a minute. I wonder if Bill is seeing similar results? Ahasuerus 04:46, 30 May 2009 (UTC)

The AND NOT example took 41 seconds on my machine the first time, but subsequent queries with different data then take about 13 seconds, so it's caching something about the tables/columns (and going back to the same original query is instantaneous). The "%x%" form of a text match is worst, since it will always scan the entire table (defeats indexing). AND NOT should not perform any differently than AND in this situation -- each has to do the same amount of work. Also, if you ran the AND NOT, you cannot then run the AND and compare, as it benefits from whatever was cached from the run of the AND NOT. --MartyD 10:46, 30 May 2009 (UTC)

On my ancient machine the query above takes about 2 min 50 sec (after a few runs, but not much difference between them) and the following one:

select * from (select t1.* from titles t1,authors,canonical_author where authors.author_canonical like '%Jo Walton%' and authors.author_id=canonical_author.author_id and canonical_author.ca_status=1 and t1.title_id=canonical_author.title_id) as t2 where NOT t2.title_title like '%farthi%' order by t2.title_title limit 100;

takes under 9 sec. --Roglo 11:08, 30 May 2009 (UTC)

Unfortunately my local configuration doesn't behave anything like the live server. E.g. A Title search for an Author of "Terry Pratchett" doesn't even complete locally, whereas it does (slowly) on the live server. The new Reviewed Author search works much better though. My Publication Search works about the same as you seem to be getting. BLongley 12:38, 30 May 2009 (UTC)

My results (the second query is from the new Advanced Search pp_search.cgi):

mysql> select distinct pubs.* from pubs, pub_content pc, canonical_author ca, titles t, authors a where pc.title_id=ca.title_id and ca.title_id=t.title_id and ca.author_id=a.author_id and t.title_ttype='COVERART' and a.author_canonical LIKE '%Embden%' and pc.pub_id = pubs.pub_id order by pubs.pub_title limit 100 ;

10 rows in set (2.42 sec)

mysql> select pubs.* from pubs where pubs.pub_id in (select pc.pub_id from pub_content pc, canonical_author ca, titles t, authors a where pc.title_id=ca.title_id and ca.title_id=t.title_id and ca.author_id=a.author_id and t.title_ttype='COVERART' and a.author_canonical LIKE '%Embden%') order by pubs.pub_title limit 100 ;

10 rows in set (10.69 sec)

On my machine EXPLAIN shows that the first query first finds titles with t.title_ttype='COVERART' but the second one does a full scan of pubs. --Roglo 13:35, 30 May 2009 (UTC)

"IN" often will not perform well, as it will usually execute the sub-query, then correlate the outer result against it. Here, with no criteria in the outer selection, it will be the whole table. This example would be better off written as a join:

mysql> select distinct p.* from pubs p, pub_content pc, canonical_author ca, titles t, authors a where p.pub_id = pc.pub_id and pc.title_id = ca.title_id and ca.title_id = t.title_id and ca.author_id = a.author_id and t.title_ttype = 'COVERART' and a.author_canonical LIKE '%Embden%' order by p.pub_title limit 100;

The AND NOT case is more difficult. Looks like the optimizer is deciding to do a scan of titles, which is relatively big, rather than considering only the restricted set of titles for the matching author(s). --MartyD 16:25, 30 May 2009 (UTC)

select titles.* from titles,authors,canonical_author USE INDEX(authors) where authors.author_canonical like '%Jo Walton%' and authors.author_id=canonical_author.author_id and canonical_author.ca_status=1 and titles.title_id=canonical_author.title_id AND NOT titles.title_title like '%farthi%' order by titles.title_title limit 100 ;

16 rows in set (0.10 sec). Now I'm happy with the search time :) --Roglo 16:48, 30 May 2009 (UTC)

It took 0.88 seconds the first time around (and 0.06-0.10 seconds on subsequent runs), but it's a huge improvement - thanks! Ahasuerus 17:00, 30 May 2009 (UTC)

P.S. But keep in mind that the Advanced Search page supports various permutations of search values, so we may have to examine which indexes are best used for each one and construct different query strings for them. However, as long as we cover the most likely searches, I think we should be able to release the AND NOT functionality into the wild and improve the performance of other searches later. (So much for it being a trivial fix! :-) Ahasuerus 17:23, 30 May 2009 (UTC)

The USE INDEX fix above is really related to the search by author, because it allows us to limit the amount of titles that should be scanned. It makes Advanced Title Search by Author usable, so I will try to test it a little, and commit it unless someone stops me :) --Roglo 18:23, 30 May 2009 (UTC)

I added Feature Request 2798917 ISFDB Advanced Search queries faster. --Roglo 19:23, 30 May 2009 (UTC)

I think we need smaller, more specific bug reports or feature requests. There's 3 sections of advanced search, all with their own problems. All I've done is enable the broken functions and added one more that was requested. So we've got Title Search with 5 options, possibly multiplied by 3 conditions and 5 options, and maybe another 3 conditions and 5 options. (Make those 6 options if you like the Reviewed Author addition.) Author Search: 6 by 3 by 6 by 3 by 6. Publication Search: 11 by 3 by 11 by 3 by 11, if you accept my fixes. There's several thousand combinations to look at and constructing the perfect query for each would be impossible. So I can understand possibly banning some searches. Or restricting some. Or changing some - "Begins with" searches are much more likely to use an index than "Contains". The more characters put into a search the more likely it is to yield a small set of results, we could demand a minimum length of characters in a search field. Or ban the pointless - nobody has managed to get a Back-Cover Artist into the database yet, so searching on such is pointless at the moment even though I've enabled it. Is preventing server-crippling searches a priority? If so, we need to address what anyone can currently do before enabling anything else. BLongley 23:56, 30 May 2009 (UTC)

Yes, this is getting somewhat hairy. I was hoping to use the Advanced Search issues as our first guinea pig to be applied to the live server, but they may be getting a little too big for that. I'll try to use your "Show present Pseudonym relationships at approval" change (yv_new.py) instead. Ahasuerus 00:53, 31 May 2009 (UTC)

Display changes might be less controversial, and I'm glad that one looks useful. Cover image previews would be my choice given current activity, but if we're going in small steps then it's up to you. BLongley 01:07, 31 May 2009 (UTC)

Ron Miller

We were just visited by Ron Miller, or at least apparently so. See Author:Ron Miller, Bio:Ron Miller, and Bio:Ron Miller/Pubs. This last is a temp page I created to hold the bibliography which does not belong on the Bio page. I am going to attempt to enter some if not all of the publications listed (excluding things clearly out of scope like journal articles), as I believe Ron Miller is well over the "certain threshold" mentioned in the RoA. Provided, that is, i can find useful online confirmation and sources for the needed data, perhaps in OCLC or Amazon. I am also going to put a note on his user page trying to tactfully explain what I am doing.

I welcome input from any of you as to whether I am handling this situation properly, and any help anyone likes to give in getting the relevant stuff from this biblio in to the DB proper. -DES ^Talk 04:35, 30 May 2009 (UTC)

Sounds like an eminently reasonable approach to me! Ahasuerus 04:47, 30 May 2009 (UTC)

The Jungle Book

I would have thought Kipling's The Jungle Book out of scope, but I see Fixer has submitted selections from it, and we have three publications on file, one verified. Of course, if this is in, there have been dozens if not hundreds of editions, with many printings. Probably as many as The Lord of the Rings. Should this be in? -DES ^Talk 14:46, 30 May 2009 (UTC)

A child raised in the jungle by its inhabitants to whom he speaks, told through stories in which the boy grows and matures through lessons learned. Wouldn't the speaking animals be enough for it to be speculative fiction? Think of Animal Farm, Watership Down, The Secret of NIMH, the works of E. B. White and literally hundreds of more titles that would be excluded if The Jungle Book doesn't qualify. Consider The Graveyard Book: a child raised in a graveyard by its inhabitants to whom he speaks, told through stories in which the boy grows and matures through lessons learned. Would the latter being ghosts make it more speculative? MHHutchins 15:16, 30 May 2009 (UTC)

I think DES may be referring to the line in Rules of Acquisition which reads "Speculative fiction is defined to exclude: ... Animal books for very young children (?)". The original intent was to exclude short (typically 6-20pp or so) books for preschoolers that depict simple scenes from animal life featuring anthropomorphized animals. Kipling's work is certainly well above that threshold, but the policy implications are that we may want to clarify the RoA. Ahasuerus 15:58, 30 May 2009 (UTC)

Yes I was thinking of the RoA, and somehow I just don't think of TJB as SF, but I see your point. In it is. -DES ^Talk 19:09, 30 May 2009 (UTC)

And I will add the explanation of the original intent to the RoA. Ahasuerus 20:58, 30 May 2009 (UTC)

Marc immediately clicks to make sure James and the Giant Peach is in ISFDB. I agree though that sometimes the line is fuzzy. Another edge are some futuristic military technothrillers. I'm reading Black Star Rising (Amazon.com 0451220145) where much of the action is centered around stealth fighters that are visually invisible. While the book is touted for it's realistic naval fighter life and flying it also gets more into specfict than the average technothriller as it discusses consequences for when completely invisible fighters get into dog fights, changes in attack and defense strategy, etc. --Marc Kupper|talk 08:22, 31 May 2009 (UTC)

Another edge case: Orbit by John J. Namce. Nance has mostly written aviation thrillers sort of in the Airport vein, but better written and wider-scoped. However, this one deals with a malfunction aboard a private space ship, something a litlte like the next stage of the RL SpaceShip One project. The tone is much like an aviation technothriller, and the tech only a litlte beyond current off-the-shelf tech. Probably Out, but soemhow i think it would appeal to many SF fans, and would like to make it In. —The preceding unsigned comment was added by DESiegel60 (talk • contribs) .

I think, (unfortunately) even in 2009, any plot synopsis which includes the phrase "Private Space Ship" would most definitely be 'In'. I look forward to the day when the Novelization of 'Snakes on a Space Ship', is 'Out' as a Ho-Hum Thriller, but we aren't there yet. Kevin 18:05, 31 May 2009 (UTC)

Concur with Kevin. Ahasuerus 18:36, 31 May 2009 (UTC)

Fine, I'll add it. i was thinkign of the RoA excluding TechnoThriller "Tommorow Fiction". I have the books so i can do a primary verify. -DES ^Talk 19:14, 31 May 2009 (UTC)

Programmer Development Page

Do we need one?--swfritter 16:49, 30 May 2009 (UTC)

I am sure the answer to this question is either "Yes!" or "Hell, yes!" :-)

The second question is whether we want to set one up here or whether we want to use the forums on Sourceforge.

The third question is how can we tell whether an issue is purely technical or whether it requires a community-wide discussion. For example, when I started the AND NOT topic above, I was thinking in terms of "impact on system performance vs. additional functionality" trade-offs and not about a technical solution to the performance issue. I guess we can always start a technical discussion on the technical forum/page and then move it here if we find policy implications (and vice versa.) Ahasuerus 17:09, 30 May 2009 (UTC)

Perhaps the technical issues could be in the programming area until a concise impact statement could go on the Community Portal. We are all, of course, experts at concise statement. Perhaps I should expand upon that idea . . . Oops, sorry the mail just came.--swfritter 21:40, 30 May 2009 (UTC)

"Possibly cripple the server" to "Add functionality" versus "just leave the purple Python problems when we're trying the silly options" should of course be discussable options for all users. Whether we can keep the techie stuff on Sourceforge is another matter - we need to break down the problems expressed here ("make stuff faster") into smaller chunks, but Sourceforge isn't (AFAICS) doing well at keeping needed coordinated changes together. Typically, a search covers two modules for the initial search and further pages. An additional search option covers three modules. A display issue may cover 10 modules. (E.g. I hate "unpaginatedpp" displays when a "0" for page count suppresses that in many other areas, but some people want to enter "unpaginated" in full and have the software deal with it.) "Impact statements" will only be as good as the knowledge of the proposing impacter - and we're just getting to the stage where even Al won't know the impact. BLongley 00:10, 31 May 2009 (UTC)

Re: tracking changes. I haven't found an easy way to find all related changes at Sourceforge (yet) except by checking comments and hoping that the developer remembered to identify all affected Python scripts. Is there a way to associate bugs and changed Python scripts, preferably including their revision number? If there is none, then we may want to either use the Sourceforge ISFDB Developers forum or start a Wiki page which would have a list/table of all current bugs and features that we are currently working on with the following columns: (A) developer, (B) tester, (C) a list of Python scripts affected and their CVS versions, (D) current status, i.e. development or test, and ETA, (E) known conflicts and dependencies, etc. It all seems so basic that I find it hard to believe that Sourceforge doesn't support something similar. Am I missing some obvious area? Ahasuerus 01:16, 31 May 2009 (UTC)

(unindent) Development has been created and a proposed "ISFDB patch process" has been posted. Ahasuerus 05:04, 31 May 2009 (UTC)

Link from submisison page to wiki

To those now doing development:

How much trouble would it be to add a message to the page displayed after a submission -- the one that shows the XML submitted -- that says something like:

"Your submission must be approved by a moderator before it enters the database. If the moderator has questions or comments about your submission, they will be posted on http://www.isfdb.org/wiki/index.php/User_talk:<Poster's User ID Here>. Please check your wiki talk page for comments or questions."

It seems just too easy for new people to find the ISFDB but not visit the wiki, and rejecting subs to put a note in the reject reason is a bit of a kludge, and may not work in all cases anyway. -DES ^Talk 21:32, 30 May 2009 (UTC)

Not too difficult, but it's needed on about 20 submission types. Some of which aren't yet available officially. Do people actually read the XML anyway until they get to the Mod stage? (I suspect some don't even then - but I usually read it to see when an author is being added or deleted unexpectedly, for instance.) BLongley 00:18, 31 May 2009 (UTC)

If we make the font big enough, they will be forced to read it sooner or later :) Ahasuerus 00:54, 31 May 2009 (UTC)

Frankly I'm not at all sure most people, even most mods, really need the XML -- I would favor a page that displays the change to be made in a more human readable form, confirming what the editor has just submitted, ideally with am option to cancel the change if the editor realizes that an awful error has just been made. But I think the link is more urgent than that ideal situation, and if added now, could be retained if and when the XML is changed to something else. In any case I would suggest putting the new link (if implemented) above the XML. Even if this is added to a few if the most common submission types, such as new pub and update pub, the ones newcomers are most likely to submit, it might help a lot. -DES ^Talk 03:22, 31 May 2009 (UTC)

I never look at the XML when submitting things but probably would notice if something extraordinary happened in it. It's fine with me if it goes away as I use the XML dumper far more often. --Marc Kupper|talk 07:57, 31 May 2009 (UTC)

OK, change to edit/submitnewpub.py committed. If that looks like a big enough pointer, we can roll it out to the other types. If not: we can make the message bigger, brighter, more threatening... ;-) BLongley 11:29, 31 May 2009 (UTC)

What would be VERY nice would be an obvious notice in the main ISFDB views or nav menu that something new has been added to your talk page, along with a link to that page. Not only is it currently too easy to not know about your talk page at all, it's also pretty easy to forget to check your talk page until you've developed the habit of watching both the Wiki and the database. If that's too hard, I suggest a link to the talk page in the My Pending Edits view. There is no visibility into the fact that a pending edit is on hold, why it is on hold, or where to look for more information about it when it pends and pends and never comes out of pending. --MartyD 11:57, 31 May 2009 (UTC)

This functionality was requested a long time ago, which prompted Al to look into it. He said that doing that kind of Wiki look-up was non-trivial or at least beyond his understanding of the Wiki software at the time, so it would have required a fair amount of digging. If you know how to do this using the current version of the Wiki, more power to you! :) Ahasuerus 14:12, 31 May 2009 (UTC)

Kev's just submitted feature request 2799074 (Add Column 'Status' to 'My Pending Edits') so the link to talk pages could be added at the same time. I think it should also appear on "My Rejected Edits". BLongley 15:45, 31 May 2009 (UTC)

Change for 2799074 committed, test away. BLongley 17:53, 31 May 2009 (UTC)

Held by looks nice. Interestingly, it links to my local server but the check your talk page links has isfdb.org hardcoded. Just so you know someone is testing your patch ;) --Roglo 18:39, 31 May 2009 (UTC)

Good point, that should probably be derived from one of the localdefs variables. I just used what DES suggested for now. BLongley 19:11, 31 May 2009 (UTC)

Actually, despite the needed improvement to my fix, I don't think we're going to be changing our website address anytime soon and check your talk page seems urgently needed. We've recently had to reject edits from JLochhas and RLCalvin to get their attention, and I'm sure we've lost a lot of editors along the way. This could be a desirable, safe, tested (have you finished testing?) option if Ahasuerus wants to try a small change first. Even if it did go wrong it wouldn't really affect the mods. ;-) BLongley 19:50, 1 June 2009 (UTC)

Of course, if we're not freezing and not deploying soon, the improvement could be added quickly too. BLongley 19:54, 1 June 2009 (UTC)

(Unindent) Hopefully you've all noticed "Your submission must be approved by a moderator before it enters the database" message now, and the talk page link, for "new pub" submissions - does the text need reworking, or can we roll it out to other submission types now? (If so, which need it most urgently?) BLongley 22:50, 14 June 2009 (UTC)

It looks OK and I think it's ready to be propagated, but we may want to put this warning into a central place rather than 10-20 different scripts so that we could easily change it later. Ahasuerus 23:01, 14 June 2009 (UTC)

I like it. I think it will help. And it definitely should be everywhere (seconding Ahasuerus' comment that it should be centralized). One thing I noticed, though, is that it almost seems like an error message. No big deal for seasoned veterans, but a newcomer might be scared by it. I suggest rewording it to be a little softer. Something like: Your submission has been queued for review by a moderator before it enters the database. or Your submission will be reviewed by a moderator before it enters the database. I don't know if anyone else had the same reaction, so don't mind me if I'm in the minority. --MartyD 02:13, 15 June 2009 (UTC)

Come to think of it, "must be approved" does sound a little too "martinetish". "Your submissions will be reviewed by a moderator before it is included in the database", perhaps? Ahasuerus 03:10, 15 June 2009 (UTC)

First patch going live tonight

We will be installing a small, experimental patch on the live server tonight. The patch tag is "r2009-01". The following two features will be implemented as per the Development page:

• 2799069. Link from submission page to wiki [for "New Pub" only].
• 2799066. Show present Pseudonym relationships at approval [moderators only, naturally].

With luck, the installation process will be uneventful and the users won't notice anything (fingers crossed.) I will post again once the new functionality becomes available. Ahasuerus 18:13, 4 June 2009 (UTC)

Ooh, I'm excited now! What time is this happening? Do I have to stay up late to watch? Or should I get up early tomorrow to see how it went? BLongley 18:40, 4 June 2009 (UTC)

No real need to. If you wake up in the middle of the night because the moon is really REALLY bright, you'll know that it didn't go well. (Hey, if Stephen can reference Dinosaur Beach, I should be allowed to allude to Inconstant Moon!) Ahasuerus 19:18, 4 June 2009 (UTC)

OK, so long as you keep an eye on the Klystron generator we should be fine. If it overloads, don't reverse polarity, just use a bobby-pin to wangle the potrzebie. BLongley 19:58, 4 June 2009 (UTC)

Oh, I wouldn't dream of reversing polarity, it never works! (And I expect to install the patch some time around 9pm Eastern, i.e. 2am British summer time.) Ahasuerus 20:42, 4 June 2009 (UTC)

I'm definitely not staying up then. I might get up early to see if you've combined my DNA with that of a fly or suchlike, but even if you did, what could I do but buzz off? (Goes to bed, wondering if he's got a new Pub or Pseudonym to add for testing purposes...) BLongley 21:36, 4 June 2009 (UTC)

(unindent) Patch installed, new functionality confirmed, everything looks OK :-) Please report any problems/issues here. If everything goes smoothly and there are no issues, we should be able to start rolling out more fixes over the weekend. Ahasuerus 00:52, 5 June 2009 (UTC)

Tried it under another name and it looks good, but it doesn't appear on the "Edit This Pub" and "Clone This Pub" will these be added? I assume there is no need to have this appear for any moderator submissions. The pseudonym message looks good and should come in handy for approvals.Kraang 01:29, 5 June 2009 (UTC)

Yes, other submission types will be enhanced soon. We just wanted to deploy something small first, something that we could easily back out of things went wrong. Now that we have proved that we can make small changes successfully, we can start making bigger/more extensive changes. Ahasuerus 03:18, 5 June 2009 (UTC)

Looks good to me. I note that it does appear for submissions under a moderator account, probably simpler not to have to check the user rights, and lets us see what new users see. On to other submission types and other changes! -DES ^Talk 17:22, 5 June 2009 (UTC)

What to Implement Next

Glad this went well. What's next? Do we develop the "Link from submission page to wiki" for other submission types? Suppress the message for Mods? Add more links from submitted edits to things that mods find difficult to check? There's a lot of stuff awaiting testing, and even more awaiting coding, so some more guidance is welcome. BLongley 19:57, 5 June 2009 (UTC)

I see no point in spending development effort to suppress this msg for mods. It may even be a handy link for some, and even when unneeded, does no harm. Why complicate the code? Adding this msg for at least the other common submission types seems like a good idea to me. More mod-helpful links does likewise. There are many useful things on the Feature request list. -DES ^Talk 20:08, 5 June 2009 (UTC)

Yes, I guess what I'm looking for is a communal effort to guide the developers and testers into 1) what is most urgently wanted and 2) will be supported through to implementation. The Feature request list here still includes requests from May 2006, before they opened editing to pesky controversial people like me and you. Closing off some of those would help, although I guess asking the submitters individually to review their old requests would be fairly simple, even if it annoys people that silently supported such feature requests. They can always be re-raised. I just want some idea of our direction before I go do anything big. BLongley 20:32, 5 June 2009 (UTC)

I have, as you know, been going through the on-wiki features list a bit, and cloning some on source forge. Some of those requested features from 2006 still look like good ideas to me. I agree that some prioritization and consensus is needed, although in an open source project, ultimately nothing happens unless a particular developer cares enough to work on the change. I think Ahasuerus's suggestion below is good, although something like a formal voting process on the desirability of a given change may be needed in some cases. -DES ^Talk 20:46, 5 June 2009 (UTC)

[Originally posted on the Development Talk page in response to Bill's question about policies, procedures and prioritization]

In the past, Al was the one who knew the most about the application and he also served as the guardian of database/application integrity, so he was effectively our benevolent dictator. For example, there was once a request to enable automatic deletion of Title records when the last Publication for that record was deleted. Al flatly refused to implement it because he thought that it was too dangerous. Ahasuerus 20:28, 5 June 2009 (UTC)

I can understand that, there's often a good reason for a title to stay (Tuck swears it exists, etc) even if our only publication is bogus and needs deletion. Maybe a "Delete title and all publications" for review by a moderator would be better - there's many manga and RPG entries where I'd like the deletion process to be easier, but automatic looks too risky to me too. We can work on other checks as well - "a title cannot be deleted if an award links to it, or if it has been verified, or reviewed, or <FITB reason>". BLongley 21:45, 5 June 2009 (UTC)

I have often thought about this ability (especially when mass slaughtering innocent RPG accessories), but, unfortunately, it could be easily abused when the potential victim is anything but a straight "NOVEL/NOVEL" pair. Imagine deleting a short fiction Title which is embedded in half a dozen anthologies and losing all of them! Perhaps we could allow it if and only if the Title is (a) a Novel and is (b) linked to one and only one Novel pub, which contains no other Titles (i.e. no introductions etc) ? Ahasuerus 23:36, 5 June 2009 (UTC)

I don't think we have anyone in a similar position at the moment, so we will have to make these decisions by consensus, just like we make policy decisions. If we can't reach a consensus, we will shelve the proposal. There will be one big difference, though: those of us involved with development will be the ones deciding what is and what isn't safe to implement since the rest of the team won't be in a position to judge. Again, if there is no consensus, we will shelve the proposed change since it's much better to be safe than sorry. Ahasuerus 20:28, 5 June 2009 (UTC)

I will be administering the installation process for now, so I will be deciding when things go live based on version conflicts, testing schedules, my availability, etc, but it won't affect what ultimately gets deployed. Ahasuerus 20:28, 5 June 2009 (UTC)

I think this makes you the "benevolent dictator" for now. I'm fine with that (you seem cautious enough) but I'd like to see some visibility of the decision process (who you're listening to, who you trust to test if you're not doing that alone yourself, etc.) BLongley 21:45, 5 June 2009 (UTC)

The Benevolent Dictatorship model seems to work quite well for some types of all volunteer projects, but it requires the BD to be extremely knowledgeable while I don't have the kind of knowledge of the software side of the project that Al does. I suppose I would try to veto some really off the wall idea, e.g. a request to mass delete all non-verified Pub, but as long as we operate by consensus, a request like that would generate enough opposition to kill it anyway. And if it didn't, we would have much bigger problems :) Ahasuerus 23:36, 5 June 2009 (UTC)

Another issues with the BD model is that the BD-du-jour can easily become the primary bottleneck if his availability declines or if is unable to delegate/manage effectively. At the moment we have a few active developers (Roglo is on a 2 week break, but he will be back) and no testers/admins/installers except me, so I suspect that I may become the next bottleneck. If that happens, we may have to ask the development crew to start dong more cross-testing even though testing is not as much fun as developing. Ahasuerus 23:47, 5 June 2009 (UTC)

Prioritization is a different can of worms. First, there are technical considerations, e.g. r2009-02 will contain 3 (and only 3) sets of changes because we need to get the live server in sync with the Sourceforge repository before we do anything else. Second, we are still getting out feet (tentacles, etc) wet, so we probably want to go for the easy-to-implement low hanging fruit. Once we are confident that we can handle bigger fish, we may want to do a poll on the Community Portal. Of course, major changes like implementing an Award editor or removing the lexical match logic for Serials could lead to revision conflict, so we will have to plan that part carefully. Ahasuerus 20:28, 5 June 2009 (UTC)

Yes, there's some big projects requested and there's still plenty of small changes we can get by with for now. More testers, and more developers still wanted, but eventually we'll want some project managers (maybe even program managers). They're a necessary evil in the long run, I've found. I'm looking ahead a bit, I know - but I can foresee times when user "MysticMeg" spends ages making sure that an author and reviewer have their star signs checked for compatibility before we'll accept a review as impartial, and hopefully that sort of thing can be stopped before development starts. (If people really want such a feature, shoot me now.) That's a long way off I hope, but there's lots of low-hanging fruit that can be addressed but need discussion - e.g. links to talk pages. Do we want editors to know which mod is holding their edit and give them an easy way to harangue them before we give the mod a chance to UN-hold the edit? BLongley 21:45, 5 June 2009 (UTC)

Assuming that wasn't a joke, i for one do want editors to know who holds any given edit. Anytime any non-mod editor has asked about that, i have responded with a link to the holding editor's talk page. I don't think it has happened more than 3 or 4 times since I've been a mod. IMO anything that facilitates communication between mod and editor is a Goo Thing^TM. -DES ^Talk 12:06, 6 June 2009 (UTC)

No joke: such a link has been developed. (Feature 2799074.) However, the lack of ability to unhold means a moderator can't hold a submission for investigation, run out of time or patience, and unhold it for another mod to look at. Or maybe a moderator should be able to assign the hold to another mod - e.g. people keep holding edits to my pubs for me to look at. I'm sure they don't want to be flooded with complaints because I haven't approved it yet but they did the original hold. So while the feature should go in, there may be other features that should be done first to minimise annoyance. BLongley 12:29, 6 June 2009 (UTC)

Good Idea. Feature Request #2802260 submitted for FLAGged submissions to assign a submission for review of a different MOD. Kevin 14:45, 6 June 2009 (UTC)

I agree that some structure will probably be needed, managers of some sort. But it is early days yet, and we will see what, er develops, naturally. -DES ^Talk 12:06, 6 June 2009 (UTC)

There are different ways to structure and administer an open source project (see the article linked above), but first we need to figure out how many developers we will have. If DES, Swfritter, Wim Lewis and Marc all get their systems going, the total number of people with development access will approach 10 and at that point we may need more structure. Ahasuerus 23:47, 5 June 2009 (UTC)

Embedded HTML in notes

My own opinion is that it is not wise for many reasons. But if we are going to allow it I would really like to see a set of standards for what is allowable, a tutorial, and some copy-paste templates. Expecting HTML literacy is not the best way to attract new editors.--swfritter 14:23, 6 June 2009 (UTC)

I don't think it is ever requited. I think a limited set of HTML should be allowed and an even more limited set should be encouraged. In the encouraged list I would put br tags for breaking up lists into visible lines, i tags for italicizing titles, and a tags for embeddign links to other sites -- some of the latter are already documented for specalixed cases. I would include in the "allowd but not particularly encouraged" category ul/li tags to make bulleted lists. I would be happy to write up a brief primer/help page that covered these forms. Does anyone have other tags that should be included, or serious objec tions to any of the above. (I have used all of the above and see no reason not to do so. Most editors seem to use either br or ul/li tags routinely.) -DES ^Talk 21:56, 6 June 2009 (UTC)

If an editor needs to update the notes for a pub that has HTML tags then the knowledge is required. I have at times avoided updating notes with HTML tags; although I can figure them out I am not all that fluent in their use. I specifically think italicizing and underlining items is not necessary.--swfritter 23:10, 6 June 2009 (UTC)

Tags for italics are not necessary, but IMO are highly desirable. (I don't see much reason for underlines.) They are also very simple and pretty obvious in context, even to some one who knows no HTML, I think. It is pretty much always OK for an editor to simply remove the HTML, IMO.

Would a basic help page on the few HTML tags that seem reasonable for the ISFDB be useful to you? Should i go ahead with creating one? -DES ^Talk 23:15, 6 June 2009 (UTC)

One of the issues with HTML is that improperly formed HTML can make a submission unapprovable. We may want to create a feature request to beef up HTML validation in submissions first. Ahasuerus 23:44, 6 June 2009 (UTC)

I'd support the validation feature, and suggest we implement that before any sort of extra encouragement to enter HTML. The one that really breaks us is one that at first glance would be entirely innocuous. I suspect people will still want to enter anchor tags to other sites though (coverart images for the other side of a dos-a-dos book, Gutenberg downloads, free audiobooks or samples, interviews etc), and that might need a whitelist of some sort. But we could use that for valid coverart sites too, so it might help us in the long run anyway. BLongley 23:55, 6 June 2009 (UTC)

Yes, a Help page with examples possibly even as part of pub Help; a defined number of tags that are allowable; a larger edit screen for notes so I can see the tag pairs.--swfritter 00:45, 7 June 2009 (UTC)

I might have mentioned this elsewhere so forgive me if I repeat myself: but I recently tidied up 120 notes where we didn't even have matching levels of "<" and ">". About half of those made lines of notes invisible: e.g. one editor seems to enter "<br." quite often and another "<li<". I imagine there's plenty more examples where the numbers of "<" and ">" match but there's a missing "/" on close tags (which is usually less important as it doesn't hide data, just makes following data look funny). We can make some simple software improvements to warn people about this at submission or at approval level if we can agree the limits. If we allow too much, then finding a proper HTML editor/validator plugin would be better though. BLongley 22:24, 14 June 2009 (UTC)

Cover art supplied by ...

Moved to ISFDB:Proposed Interface Changes#Cover art supplied by ...

Series parent display

Moved to ISFDB:Proposed Interface Changes#Series parent display -DES ^Talk 05:56, 14 June 2009 (UTC)

Patch r2009-02

Patch r2009-02 has been put together and is currently in the middle of testing on my local server. If everything goes well, it will be deployed on Sunday. (See the Development page for technical details.) The following bugs and feature requests will be addressed:

• Bugs 1956355, 1961441, 1966177. Empty series are displayed on the main Biblio page and Titles are displayed in a wrong chronological order. Also addresses the request to add Nongenre Series and Short Series displays to the Biblio page.
• Bugs 2137453, 2271738. Pubs with ISBN13 do not get proper Amazon links (which need ISBN10 instead).
• Bug 1987739. 8888-00-00 is not converted to "unpublished" in various places.

In addition, the live server will be reconciled with our source code repository on Sourceforge, which makes it a particularly tricky patch and prevents us from deploying anything else in addition to the changes listed above. Ahasuerus 05:29, 7 June 2009 (UTC)

Testing likely delayed since the tester is recovering from an encounter with ruffian bacteria. To quote my favorite Troll, "undercooking hobbits is a primary cause of indigestion". Ahasuerus 19:58, 7 June 2009 (UTC)

Patch r2009-02 is now live. Henry Kuttner, Brian W. Aldiss, James Patterson, Philip Francis Nowlan, Charles de Lint and others will be happy to showcase the new "Short Fiction Series" and "Non-genre Series" functionality as well as other improvements. We may want to tweak some of the new codes, e.g. [SERIAL], but the core of the new functionality is hopefully solid. The ISBN-13 fix also made it and so did the 8888-00-00 fix (and 9999-00-00 for "forthcoming"), although Marty later found a couple more places where 8888-00-00 still needs to be fixed. Please report any problems here.

Most importantly, the main (aka "live") server is now fully synchronized with the Sourceforge repository, which greatly reduces the probability of Bad Things (tm) happening.

P.S. I will start working on r2009-03 tomorrow. Ahasuerus 03:20, 8 June 2009 (UTC)

Code already exists to display credit for bestsf.net

Code already exists live on the server to display a credit for BestSF, see Interzone April 1998. Currently 46 publication records hot link and credit images from Best SF. It appears that the editor of that site Mark Watson was working on the ISFDB back in early 2005 What's_New_from_2005#What.27s_New_-_18_Jan_2005. Should we remove this code? Should we contact bestsf.net for permission? Is permission already documented somewhere? Is the permission implied (by our what's new history that Mark was test ISFDB2? Thanks Kevin 00:03, 8 June 2009 (UTC)

As I recall, Mark was one of the people helping Al with the ISFDB-to-ISFDB2 conversion and related activities, but it was a while back and I don't think he has been involved since at least early 2006, so we probably want to ask his permission. As Jerry Lewis once said, safety first ;-) Ahasuerus 03:28, 8 June 2009 (UTC)

Permission Request Email sent, with CC to isfdb.moderators@gmail.com address. Kevin 03:21, 9 June 2009 (UTC)

Minor Navbar Changes Proposed - Edit Author, Show All Titles, Magazines and More

Moved to ISFDB:Proposed Interface Changes#Minor Navbar Changes Proposed - Edit Author, Show All Titles, Magazines and More -DES ^Talk 02:30, 14 June 2009 (UTC)

Searching by ISBN behavior

For an ongoing discussion of the nature of ISBNs, Catalog IDs, and other identifiers, see Rules_and_standards_discussions#Dealing_with_Bad_ISBNs (and also Rules_and_standards_discussions#Formatting_ISSN_numbers).

I noticed while testing some recent changes that searching by ISBN does not behave as one (well, "I") might expect. I'm seeking opinions about how search should behave AS ISBNs ARE CURRENT IMPLEMENTED before logging a bug. Please use the appropriate discussion above for general ISBN and Catalog ID comments and ideas.

Example 1: Two pubs sharing the same ISBN pair, one entered with ISBN-10, the other entered with ISBN-13. You can't tell from the pub displays, as both show the same numbers, but the title display shows the difference. Searching by ISBN for 0-441-01547-6 finds one record, and searching by ISBN for 978-0-441-01547-4 finds the other record. Do we expect either should find both?

Example 2a: In the example above, searching by 0-441-01547-6 or 0441015476 (or by 978-0-441-01547-4 or 9780441015474) produces the same result. Consider A Touch of Sturgeon (showing ISBN-10 of 0-671-65526-4 and ISBN-13 of 978-0-671-65526-6). It was entered with an ISBN-10, yet searching by ISBN for 0-671-65526-4 or 0671655264 produces no results. Searching by ISBN for 0%671%65526%4, however, finds it. This is because the ISBN was entered and stored with the hyphens, but ISBN searching normalizes search strings to remove dashes and spaces from valid ISBNs. Do we expect this should have been found using any of the three search strings?

Example 2b: Before someone goes and fixes this one, consider Dragon Magazine #246. Note the bad checksum on its ISBN 978-0-7869-0810-9 (and also a lack of ISBN-10 in the display). Searching by ISBN for 978-0-7869-0810-9 finds it, but searching by ISBN for 9780786908109 does not. Do we expect that it should?

My feeling is that since ISBN 10s and ISBN 13s are shown together, often on books and almost always in the Publication display, searching by ISBN for either value should find all publications, even those entered using the other value. And since dash-or-space punctuation is semi-optional, the search should produce the same results whether the search term includes dashes-or-spaces or not, whether the underlying record is dash-or-space punctuated or not, even if the ISBN has a checksum error. But some of that thinking flies in the face of looking for "exactly as recorded", so I figured I'd see what other people think. Thanks. --MartyD 10:50, 9 June 2009 (UTC)

I tend to agree. IMO valid ISBNs should ideally always be stored without embedded hyphens or or spaces, and a search with a valid ISBN (i.e. one with a checksum that passes) should be searched for in both ISBN-10 and the corresponding ISBN-13 format. I'm less sure what should be done about ISBNs currently stored with hyphens, particularly since they can have them placed incorrectly. removing hyphens (or spaces) from every search target might be prohibitive in perform ace terms (if it isn't, doing this would be ideal, and allow storage "as printed"). Perhaps a data-change script to remove existing hyphens would be needed. Note that I do not think that an invalid ISBN should be converted to the alternate form.

However, before you log a bug, I think this is really an enhancement (feature) request. What is happening now is basic string comparison. What we want is a smarter search, and i hope this won't be too complex to implement, but I think this is,m in effect, as design change (albeit a design that was never publicly documented). So call it a feature, but hope for early implementation, is my view. -DES ^Talk 12:04, 9 June 2009 (UTC)

Personally, if I wanted to find both records in one go I just wouldn't put the ISBN-13 prefix or the check-digit in. 0-441-01547-6 will never match 978-0-441-01547-4, so just search on the common part 044101547. This may not be intuitive to all users but education in the ways of the check-digit would help. BLongley 17:32, 9 June 2009 (UTC)

The danger of changing this search is that there's other uses of that field and so other searches that could break, especially if you try and remove hyphens before searching - e.g. I can search with "#F-" to find F Series Ace paperbacks, but without the hyphen it's contaminated with loads of other publications. I'd publish the current algorithm and the proposed one before attempting any changes, we have to run it past the people that search for ISSNs and Catalog numbers as well. And it would be nice to future proof for 979- prefixes too. BLongley 17:32, 9 June 2009 (UTC)

I really think that is too much to ask for. A user sees an ISBN printed in a book and searches for it. If no result is returned, the user is entitled to assume that no record exists for that book, at least not with that ISBN, not that a different form must be searched for. The case of an invlaid ISBN is an odd one, and I hope fairly rare, but a valid ISBN htat might be in either -10 or -13 form is very very common. -DES ^Talk 21:23, 9 June 2009 (UTC)

BTW it is my view that hyphen removal and ISBN conversion should not apply if the search target starts with # or is not itself a valid ISBN, or at least a plausible one -- in particular any non-numeric character should disable such conversions. -DES ^Talk 21:26, 9 June 2009 (UTC)

But search already does remove the hyphens (and spaces). Sometimes. See Example 2a. The only way to find that one without knowing about SQL wildcarding is to use the omit-the-check-digit trick above while leaving in the punctuation. To my simple little pea brain, if I type in the ISBN and search doesn't find it, it's not in the database. This isn't the same as searching by title or even by author name, where there's a good possibility of variation in spelling, punctuation, omitted/extra words/initials, etc. An ISBN is an ISBN. --MartyD 18:15, 9 June 2009 (UTC)

Exactly. -DES ^Talk 21:23, 9 June 2009 (UTC)

And an ISBN-10 is not an ISBN-13. If I search for one and don't find it, it isn't here: it hasn't been recorded that way. It's arguable that we should be able to record whether it was recorded one way, or the other, or both. Or that most of our users don't understand ISBNs and we should make it easier for them: - but does that mean we try and form all the other valid ISBNs and search for them, or search without the ISBN-13 prefix(es) and check digits? Maybe even without a leading 0 or 1 so we find SBNs? Lots of options to discuss. BLongley 18:58, 9 June 2009 (UTC)

An ISBN is an ISBN. Many, perhaps even most, books now print both a -10 and a -13, and which we enter is pretty much at random, as far as i can see. Many online sources, particularly Amazon, now report ISBN-13s for books published long before the -13 format was thought of. A user finding a -13 ISBN from such a source and searching on it should be able to find the proper record in our db. Not to convert between -10 and -13 for search purposes is IMO almost as counterproductive as making title searches case sensitive would be. Asking the user to guess which way the editor happened to edit a value so fully convertible that we display BOTH forms, and require you to enter edit mode to even see which way it is stored seems perverse. -DES ^Talk 21:23, 9 June 2009 (UTC)

BTW, this little piece of the existing behavior extends to "catalog ids", too. If for some strange reason a pub had "#0-441-01547-6", search using "0-441-01547-6" would not find it. The current algorithm is: If the search term is a valid ISBN (without dashes and spaces looks like an ISBN, and first 9 or 12 digits compute to check digit), search for pubs whose stored ISBN string contains the search term with spaces and hyphens removed. Otherwise, search for pubs whose stored ISBN string contains the original, unaltered search term. A more do-what-I-mean algorithm could be: If the search term is a valid ISBN, search for pubs whose stored ISBN string contains either the original search term or the search term with dashes and hyphens removed or the search term converted to ISBN1x (whichever it is not) without punctuation or the search term converted to ISBN1x with punctuation. Otherwise, search for pubs whose stored ISBN string contains the original, unaltered search term. --MartyD 18:15, 9 June 2009 (UTC)

If a valid ISBN has been #ed out I'd want to find and probably fix those. Have you got examples? As the only time I can foresee that happening is if it's known to be the wrong one, but still stated on the pub that way, and we haven't found the right one. But we have variable practices in situations like that so more investigation is in order. BLongley 18:58, 9 June 2009 (UTC)

I just picked an ISBN to illustrate. Nothing in the code knows it's a real ISBN, just that the first 9 or 12 characters are only digits and the last digit-or-X is what you get from the ISBN check digit calculation. And it doesn't have to be a leading "#". The catalog ID could be "ABC-04410-15476-DEF", and searching using 04410-15476 would not find it, either, just because the search term passes the ISBN recognition rules and is modified. --MartyD 01:19, 10 June 2009 (UTC)

That's where serial searched could answer the problem. Let it search both ways and display the combined results. Kevin 04:16, 10 June 2009 (UTC)

Actually, looking at 2b, I'm wondering why Dragon Magazine has an ISBN rather than an ISSN anyway. Is there an ISSN-13 I've not heard about yet? BLongley 20:12, 9 June 2009 (UTC)

I believe I have seen magazine issues which had both an ISSN and an ISBN. Ahasuerus 21:35, 9 June 2009 (UTC)

Call me a dreamer. I want to enter ISBN format ISBN10, ISBN13, ISBN13_979, Both With and WithOut dashes, Hyphens, Emdashes, With and Without the leading 0 or 1, (Yes I'm biased towards english results) with and without checksum digits, and also a simple matching search should still work for any segment of an ISBN, Publisher or Catalog number, and find the book I'm looking for. (Yes that's alot of trapping and ELIF's) but it only seems reasonable. It might be Easier to code if we rework the ISBN system so that all ISBNs are stored as ISBN13 and ISBN10 is derived for all ISBN10 and ISBN13_978 data entries. Kevin 22:44, 9 June 2009 (UTC)

I would be willing to omit searches that drop the 0 or 1, in fact I would oppose logic to automatically add the leading digit, as i do sometimes need to work with ISBNs whose leading digit is not 0 or 1. I also don't see the need of searches that omit the checksum digit (except by explicit wildcarding), and how is the software to know if a 9 digit search target has an omitted check digit, or is an SBN, or whatever. Too much flexability tends to lead to over-complex interfaces and/or confusion behavior. I would settle for a system in which a valid ISBN could be entered with or without spaces, dashes, etc, in -10, -13, or -13(979) form, and any pub record with any exactly equivalent ISBN, in whatever form, would be found. A wildcard for partial match searches would be nice. A search for cat #s should be a plain text match, preferably with wildcards. -DES ^Talk 23:06, 9 June 2009 (UTC)

Oh.. I'm not imagining a complex user interface. I'm thinking that the ISBN Search function performs serial searches on the transformed number and displays the results as a single result list. As an example, enter an ISBN8 (without the language prefix, or checksum), then you would get all matching ISBN10/ISBN13_978, ISBN_979, SBN's, etc that match, All presumed in english (1 or 0). If you enter an ISBN10/ISBN13_978 or ISBN13_979 with say a 5 language identifier, then you would get results including the 5. The 1 or 0 should only be assumed if missing, and if missing the search should run without the 1 or 0 added as well as with. Kevin 04:12, 10 June 2009 (UTC)

I see. If a 9-digit string that might be an ISBN is entered do you assume a missing lead character, or a missing check digit? I guess you assume both, and return any result that matches either assumption. Do you support a wildcard, so that 123-456-7??? matches any ISBN that starts with 123-456-7 perhaps? Should just doing the -10 / -13 conversion, and running both searchs, be a proper inital small change? -DES ^Talk 13:37, 10 June 2009 (UTC)

(unindent) It's not a complete DWIM searching solution by any means, but can anyone see anything wrong with -- and are there any objections to -- the relatively small change I proposed above: current behavior + allowing "valid ISBN" text to match as entered + allowing "valid ISBN" text to match other-length ISBNs (punctuated and non-)? Or shall I forget this idea, and we live with current "not-a-bug-but-a-Feature" behavior until such time as searching can be made to do much more (perhaps in conjunction with any change to how these IDs are captured and stored in the first place)? --MartyD 15:01, 10 June 2009 (UTC)

Sounds good to me, we can worry about perfection later. -DES ^Talk 22:14, 10 June 2009 (UTC)

Agreed. There are all kinds of complications here, e.g. we are already seeing some books that list an ISBN-13 but not an ISBN-10, but we can sort them out later. Ahasuerus 01:33, 11 June 2009 (UTC)

Better is better. Go for it. Kevin 04:12, 11 June 2009 (UTC)

I'm fine with the small feature request as proposed, don't go into SBNs yet though, it seems some of you don't really understand them yet. (E.g. there's 11 digit numbers that have been called SBNs when they are at best SBNs with a 3 digit price replacing the check digit.) BLongley 21:54, 11 June 2009 (UTC)

Draft Help page on serials

Please see Help:Use of the SERIAL type for a draft of a help page that discusses this subject and the reasons for our current practice. Comments welcome. -DES ^Talk 22:13, 10 June 2009 (UTC)

Change Clone and Edit 'Submit' Buttons

Moved to ISFDB:Proposed Interface Changes#Change Clone and Edit 'Submit' Buttons

Development Choices - A new Page?

Development discussions seem to have overtaken the Community Portal. Development is for documenting what's going on, and Development:Talk is for talking about development code, techniques, etc I feel. Do we need another page with 'special' rules for quicker archiving, to throw up screenshots, etc and discuss user interface, etc. We could post a headline and link on Community Portal, and then link to a 'Development Examples and Discussion' page. When a particular feature goes live on the server, and gets thrashed a bit with everyone testing and proposing changes/updates, that conversation could be archived before it spends 6 months to a year drifting to the top of the page. Just a thought. Interested in seeing if there are similar thoughts out there. Kevin 02:55, 12 June 2009 (UTC)

We already have ISFDB:Proposed Design Changes perhaps we could use that? That was an attempt at such a thing some time ago. Unfortunately it was created just as Al started to have little time for development, and well before the current round of proposals and changes. Some of the content may well be obselete, but the page can be used, i would think. And much of it, i think, is not obselete. -DES ^Talk 12:22, 12 June 2009 (UTC)

That page seems more tuned for 'changes to the sql database', not changes to the 'isfdb interface'. Kevin 01:55, 14 June 2009 (UTC)

Very well, we now have ISFDB:Proposed Interface Changes also. -DES ^Talk 02:25, 14 June 2009 (UTC)

Looks good, (other than it's all my topics at the moment - Chuckle) Kevin 03:32, 14 June 2009 (UTC)

Image Linking Permission - From the ISFDB?

Do we have any policy on image linking from the ISFDB? Since we now host 5000+ images I think it would be appropriate to pre-develop one and post it to ISFDB:Image_linking_permissions. I propose...

1. Blanket permission to any non-commercial / non-profit site for up to 500 hot links to our images. Please contact us if you are approaching that limit.
2. Blanket permission to any commercial / profit site for up to 250 hot links of images, with a human readable link back to "www.isfdb.org" required in each article / blog entry using the image(s). Please contact us if you are approaching that limit.
3. Blanket permission to all deployments (private or public) of the isfdb.org software and or database to link all images without limit. Please contact us if your deployment will serve more than 100 unique users a day, or you are approaching that limit.

The above policies are both generous and reasonable. They might even encourage small fan sites to use us to host their images, (and thereby upgrade our database information to support thier off-site project). Thoughts? Kevin 14:38, 13 June 2009 (UTC)

Seems not unreasonable to me. Of course we already grant permission for reuse as all our contents are published under a creative commons license, but hot-linking is different. -DES ^Talk 14:43, 13 June 2009 (UTC)

Number three is because a 'deployed' private isfdb already hot links every image to www.isfdb.org, so the CC license doesn't cover that. Kevin 14:59, 13 June 2009 (UTC)

Bump. I would like to close this out, or at least get some more opinions, but I think it's been lost in all the discussion below. Kevin 22:02, 16 June 2009 (UTC)

Given our current unexplained timeouts and slowdowns, I'd be reluctant to encourage others to use our bandwidth for now in case that's part of our problems. So I'd leave it as a reminder that we have no problem with reuse of the images, but wouldn't encourage hot-linking yet. If the person/people paying for our current hosts feel more generous, then let them say so - I don't think it's up to us to be even more generous than we currently are. (Or are you paying for our hosting, Kevin?) BLongley 19:57, 18 June 2009 (UTC)

Nope, I'm not paying for the bandwidth. I'm just trying to document a policy. It came up (to me) because we asked someone else to get permission from a similar (German, Single author) Wiki site. It pointed out to me that we don't have a policy, even one so stringent as "No." documented. As for the hosting costs, if they ever become an issue, then we can discuss them. I assumed that our out of pocket costs are rather minimal / covered by the monetized amazon links. I haven't priced a shared server with shell access, but my unlimited storage, unlimited bandwidth (Yes, I know it's not really unlimited), unlimited domain name hosting solution is just under ~$100.00 a year. (shrug). If everyone else here feels it is appropriate to hotlink to other similar sites, and not offer some similar arrangement when 'we' have the better image available, so be it. Kevin 23:45, 18 June 2009 (UTC)

I don't know who is paying for our current bandwidth and hosting costs, what the costs are, nor how near our limits we are, nor whether bandwidth consumption has anything to do with the recent (all too frequent) server time outs. I rather suspect it doesn't but that's just a guess. We should find out. Having found out, if we have plenty of bandwidth to share, i have no objection to hot linking. If we don't have a healthy margin, then encourage reuse but not hot-linking. -DES ^Talk 04:03, 19 June 2009 (UTC)

It might also be time to readdress the possibility of a "switch off images" option for local copies (or maybe even make it a user preference online) so that we can truly use ISFDB completely offline, or avoid unwanted data-charges for images we don't really need if online. BLongley 19:57, 18 June 2009 (UTC)

A few comments/answers:

• The ISFDB FAQ currently says "Q: Is it okay to deep link into ISFDB pages? A: Of course it is", so in a way we already have a policy.
• Our current bandwidth allowance is $350Gb/mo (plus apparently unlimited FTP for backup purposes) and we barely use a couple of Gb/mo.
• We tried a shared server when we moved to this ISP last year and the performance was often atrocious, presumably due to other users' malformed MySQL queries. We ended up upgrading to a virtual server ($30/mo) and it worked well for us until the recent series of intermittent outages started.
• Al is the one who gets the bill from the ISP and I pay for it. Ahasuerus 04:25, 19 June 2009 (UTC)

new header templates

I have recently created Template:AuthorHeader and Template:PubHeader, to provide standardized headers for Author: and Publication: pages in the wiki. We already have Template:BioHeader and Template:PublisherHeader. Thes tempaltes can, with a small code change, be used to put the standard header in by defualt when an editor clicks on the wiki-link for a DB page to a previously empty wiki page. They can also be added in bulk to existing pages in the appropriate namespaces.

Does anyone have any comments or objections about making use of these header tempaltes standard in the pages in the Author:, Publication:, Bio: and (perhaps) Publisher: namespaces. (It may be that the publisher one should wait until there has been more progress on publisher standardization. In fact I think it probably should.) -DES ^Talk 22:43, 13 June 2009 (UTC)

There is probably nothing wrong with a generic publisher header that only puts it in the publisher category. That way we can (if we choose) impliment all new links to the wiki from the database at the same time, and later if/when we think it prudent the header itself can be adjusted here in the wiki, and no code update to the isfdb itself is required. Kevin 22:52, 13 June 2009 (UTC)

Hmm perhaps. except that for links to work, {{PublisherHeader}} requires a numeric ID parameter, to link to the proper ISFDB publisher record. Adding a generic template without such a parameter would be pointless (and i don't see much value to a huge category simply including all publisher pages anyway: the same list is available via special:allpages). If we setup pages with record numbers specified, and publisher merges are done later, the wiki pages will need to be changed at the same time. of course, requiring merging editors to update the wiki also might be one more way to slow down publisher merges. :) Adding the publisher header is not a horrid idea, if we are prepared to update pages when publishers are merged. If we are not, then it should probably wait. -DES ^Talk 23:06, 13 June 2009 (UTC)

The way the preload function works, the text to be preloaded is in the wiki on [Publisher:Whatever_I_Call_The_Template_Page] so today I can write the code to preload the template page (With just the publisher category, the publisherheader template, or nothing at all), and 6 months, 6 years from now the page in the wiki is all that needs to be edited to change text preloaded. Kevin 00:15, 14 June 2009 (UTC)

That works for me. -DES ^Talk 00:27, 14 June 2009 (UTC)

Note: that reminds me we should probably protect those preload pages when we make them. Just a semi-random non-linear thought. Kevin 00:37, 14 June 2009 (UTC)

Any comments on the other three header templates? -DES ^Talk 23:08, 13 June 2009 (UTC)

The other templates all look fine (shrug) - Things like that I usually don't notice that something bothers me until I'm using it in action. But again, both the template and the preload can be modified without a code update. Kevin 00:36, 14 June 2009 (UTC)

True. However I am considering using AWB to more or less mass-populate the existing pages with the headers, and if you or anyone had strong objections i would want to know. Of course the template can always be edited later to change the results en mass. -DES ^Talk 01:02, 14 June 2009 (UTC)

I think the ones that don't need an input variable should be fine to deploy that way. If anyone has a problem with the template, itself, that can be changed on the template page. Kevin 01:57, 14 June 2009 (UTC)

A Preliminary List of Major(ish) Projects

Can we add to this list, or is this what you are proposing as the preliminary list? (Because I really want/need a better implementation of chapbooks and other short works independently published as ebooks and special printed editions.)Kevin 01:30, 14 June 2009 (UTC)

The list is wide open, add away! :) Ahasuerus 04:15, 14 June 2009 (UTC)

Reversing Canonical Name and its Pseudonym

Clearly very useful since it would help eliminate a great deal of manual work, but may be time consuming to implement. We will need to make sure that the option can't be used on house names, collective pseudonyms and such. Ahasuerus 01:06, 14 June 2009 (UTC)

If we implement removal of Pseudonym relationships (below), a reversal becomes just two steps (1. delete; 2 add the other direction) and just a few clicks, and that might be less work and less dangerous. Or we could restrict it to mods like publisher edits, I suppose. -DES ^Talk 01:12, 14 June 2009 (UTC)

What I had in mind was reversing all affected VT relationships, including Series and other frequently "left behind" areas. The process tends to be quite time consuming at the moment. Ahasuerus 01:23, 14 June 2009 (UTC)

I see. that is a bigger kettle of fish. Larger coding, but more payoff. -DES ^Talk 01:27, 14 June 2009 (UTC)

Add the Ability to Merge Contents Titles with Pre-Existing Titles at Submission Time

After selecting Submit on the Add New Collection/Anthology/Magazine/Non-Fiction screen, the editor will see another screen, which will give him the the option to merge Contents Titles with pre-existing Titles when available. It shouldn't be too time-consuming to code the new screen, but the approval screen for this type of submissions could be tricky. Ahasuerus 01:06, 14 June 2009 (UTC)

Sounds like a good idea to me, if it can be implemented without an overly complex interface. For it to work well, i think that links must be available so that the editor (and the approver) can navigate to the records for the works proposed for merger. Often seeing such details from the current merge screes (which do have such links, both when using "Show titles" and when using "Dup candidates") I find important to determine which candidates should be merged. -DES ^Talk 14:06, 16 June 2009 (UTC)

Redo Serials to Eliminate the Current Reliance on the Lexical Match Logic

This will likely require database changes the way Review changes last year required database changes. Serials will be harder to do than Reviews because there are multiple records involved. Will require additional design work. Ahasuerus 01:06, 14 June 2009 (UTC)

This might/could be rolled into a rework of 'Variant' support as a whole. Just make 'Serial Part' one of the variant types. Kevin 02:04, 14 June 2009 (UTC)

I am inclined to think that Serials are better kept separate, variants confined to works with essentially identical text, and a general "Based on" relationship implemented to handle revisions, expansions/condensations, fixups, and the like. Serials are many-to-one, variants basically one-to-one, and fixups mean that based on must be many-to-one or perhaps even many-to-many. But in any case, eliminating the lexical match would be a very good idea IMO. -DES ^Talk 14:02, 16 June 2009 (UTC)

Variants are many to one also aren't they? I think they just usually are one to one, or am I misunderstanding the term? Kevin 22:04, 16 June 2009 (UTC)

Variants are many-to-one in an sense, but any given variant relationship is one-to-one, and any given variant has exactly one parent. But a given work may be based on multiple works, and have multiple other works based on it. Really a many-to-many relationship, hence fundamentally different from a coding perspective. See the discussion under #Based on. -DES ^Talk 22:14, 16 June 2009 (UTC)

Automatic Deletion of Empty Series

Al tried this at one point and it didn't work well because of embedded Series. For example, if Series B is embedded within Series A and the last entry in Series B is deleted, do we want to delete Series A as well as Series B is Series A has no other data? We may want to consider adding an option to delete Series records instead. Ahasuerus 01:06, 14 June 2009 (UTC)

Yes to either method. Automatic deletion of empty serial trees upon moderator approval of title deletion (or title series change)(Make sure the empty tree check is after the new series gets applied...it might have been moved to the parent series); or Delete this Series from the view of an empty series. Either one is fine with me, but it's pretty obvious which one will be easier to code. Kevin 02:07, 14 June 2009 (UTC)

I think one of the problems was that just because B becomes empty it doesn't mean that it's not a parent of series C, i.e. you have to check the series hierarchy, not just whether there are any titles left in the series. BLongley 11:46, 14 June 2009 (UTC)

I can also see cases in which an editor is juggling series assignment -- particularly within a series hierarchy -- and leaves a given series empty for a moment, but intends to reuse it shortly. And before you "very well an new series of the old name will be created" recall that the wikipedia isfdb series template links to series by record number so such changes would break such links. -DES ^Talk 14:19, 14 June 2009 (UTC)

It sounds like the least controversial and the least time consuming fix would be to add a new option to the Series-specific Navbar which you see when you pull up a Series. The new option will let you delete a Series if and only if it has no Titles in it and if it has no "child" Series. If there are no objections, I will create a Feature Request tonight. Ahasuerus 16:44, 16 June 2009 (UTC)

Feature request 2809640, "Allow empty Series deletion", has been created. The text reads:

Add a new button on the main Series screen, "Delete This Empty Series". The button will only be displayed if the Series has no Title record associated with it and has no "child" Series. Add an extra check to the Moderator approval screen to avoid creating orphan pointers when submissions are approved out of order.

Implementation details:

When the user clicks this button, a regular SeriesUpdate submission with a blank series name will be created. Since Feature 2807944, which needs to be implemented first, will prevent users from blanking series names, this will allow us to re-use "SeriesUpdate". If we don't do it this way, we will have to create "SeriesDelete", which will require more extensive modifications to the main Submissions screen and probably the Web API.

Anything else that may be missing? Ahasuerus 00:58, 21 June 2009 (UTC)

Sounds good to me, nothing else I can think of. -DES ^Talk 01:35, 21 June 2009 (UTC)

I deleted a series name this morning and left a note on Bills page. Here's the one that's gone "24734 Rod McBan" renamed "Formerly Rod McBan - to be reused". There's only one Rob McBan now this record "24733 Rod McBan" (current). If I send in a blank name now it deletes the name. This didn't work in the past, so why does it work now?Kraang 01:18, 21 June 2009 (UTC)

You didn't delete it, you just renamed it to blank. 24734 shows that it still exists and should probably be renamed "To be reused" or some such. Renaming to blank is not a good idea, it makes dangling series harder to find. -DES ^Talk 01:33, 21 June 2009 (UTC)

Yup, unfortunately, it's not gone, it's just that its title has been set to an empty string. Here is what happens when I run this query internally:

select * from series where series_id = 24734;
+-----------+--------------+---------------+-------------+
| series_id | series_title | series_parent | series_type |
+-----------+--------------+---------------+-------------+
|     24734 |              |          NULL |        NULL |
+-----------+--------------+---------------+-------------+

Ahasuerus 01:43, 21 June 2009 (UTC)

That's interesting because I couldn't do that before.Kraang 01:41, 21 June 2009 (UTC)

We'll have to take a look at the history of the Series page and see if anything has changed... Ahasuerus 01:43, 21 June 2009 (UTC)

(unindented)I thought it best to leave it at the one I did and find out if this causes any problems and why it can be done now and not in the past. No changes to series that I read would lead me to think this was possible or intended.Kraang 01:52, 21 June 2009 (UTC)

In another discussion, Bill (I think it was him) reported cleaning up some 20 such series not long ago, so someone has been able to do this for a while. In any case Feature 2807944 (Prevent series name blanking) will prevent any more such when/if it is implemented. -DES ^Talk 01:48, 21 June 2009 (UTC)

Ah yes, I remember it now. I looked and found 6 2008-2009 submissions by ChrisJ and one Bob Hall that did that, so it's been possible for some time. Ahasuerus 01:50, 21 June 2009 (UTC)

See your comments here also. -DES ^Talk 01:52, 21 June 2009 (UTC)

Allow Deletion of Pseudonyms

The actual software change should be fairly straightforward, we just need to decide whether we want to have a new option in the NavBar or whether we want to add functionality to the Make This Author a Pseudonym screen. We also need to prevent editors from creating duplicate pseudonym relationships, but that can be done quickly. Ahasuerus 01:06, 14 June 2009 (UTC)

I would put it in "Make This Author a Pseudonym" but don't feel strongly. If you make it a navbar item it shopuld be hidden or greyed out if the dispalyed author is not a Pseudonym currently, IMO. -DES ^Talk 01:15, 14 June 2009 (UTC)

One problem with making this part of the Make Psuedonym page (Like the undo variant is adding a zero variant title record), is that pseudonyms 'can' have more than one 'parent' author, so just coding to use a special input (like 0) may not be enough. It will probably end up being more like the 'unmerge' edit screen for this functionality, so you can pick which relationship to remove. Kevin 01:49, 14 June 2009 (UTC)

Oh yes, it would require a new section with a table/list of existing pseudonyms and a check box for each one, which is why I am not sure that we want to use the existing screen. Also, we may want to consider implementing a better way of breaking VT relationships since "0" is not exactly intuitive for new editors. Ahasuerus 03:34, 14 June 2009 (UTC)

Implement Chapbook Title Type

Bring back, recreate, or undo the removal of support for Chapbooks (Or make another title type) that can serve as a 'short length title' container for all types of contents, and that can be edited without reverting to anthology. This is needed to document the explosion of short fiction being released as individual works on the web (downloadable), and as chapbooks by specialty presses these days. This will include display support on Author biblio pages, and series support, etc. Kevin 05:18, 14 June 2009 (UTC)

I fully agree. Such a type should be a true container type, much like an anthology or collection. This means there must be both a title type and a matching publication type (some such works may have multiple publications.) It should be used for publications smaller than a usual book, and for publications of any physical size that contain only a single work of fiction (with possibly essay and interior art contents) that is shorter than novel length. Such works should appear in a separate section of an author's summary biblio page, just as collections and serials do.

As to nomenclature, i favor SHORT WORK, but could live with CHAPBOOK, or some other term. Please don't leave it as CHAPTERBOK. -DES ^Talk 05:36, 14 June 2009 (UTC)

SHORT WORK, works for me. Kevin 16:17, 14 June 2009 (UTC)

I prefer SHORT BOOK, unless you are proposing that these are for single-content works only? (Which seems to be how some people are misusing the current broken situation.) As I've seen anthology and collection chapterbooks here, but we can make those real collections and anthologies and record the fact that they have been labelled chapterbooks by the publisher in notes. How far do people want to go to eliminate the phrase CHAPTERBOOK? BLongley 17:40, 14 June 2009 (UTC)

I think there are two different things that usually but not always go together. The standalone publishing of a short story or two. The type of physical container. We distinguish between mass market paperbacks, trade paperbacks, hardbacks and magazines. A way to distinguish chapbooks where the book is printed and folded with-out a separate bound on cover is useful. Omnibus has a slight problem with this also since they can contain a mix of novels and collections/anthologies. Dana Carson 21:33, 14 June 2009 (UTC)

I thought that was what 'ph' Pamphlet binding was for? Kevin 21:36, 14 June 2009 (UTC)

Not Single Content - Multiple Content items, as DES described. As for CHAPTERBOOK, that is DES's windmill, not mine. Kevin 21:35, 14 June 2009 (UTC)

I think the most frequent use in practice would be for publications having only a single content item. But accompanying essays, interiorart and other non-fiction contents would be far from unheard of, i would expect. I could see a convention (which i don't think needs to be enforced in software) that this type be limited to items containing only a single work of fiction. If there are multiple fiction works, then the anthology or collection type can be used, perhaps with a binding of ph. -DES ^Talk 18:57, 15 June 2009 (UTC)

As to the name, i think everyone who has commented on the matter agrees that the name "Chapterbook" was a mistake and should be changed. As long as we are making code changes affecting this type (assuming that we are) that seems the moment for correcting that mistake and/or choosing a better name. "Chapbook" at least arguably describes a publication/binding format, while the main use of this type would be to describe the nature of the contents (a basically stand-alone publication of a work of short fiction, possibly with essays or other non-fiction). Thus a name other than "CHAPBOOK" seems like a good idea to me. -DES ^Talk 18:57, 15 June 2009 (UTC)

While such a type could be used for a small/short publication, bound as a pamphlet or chapbook in the traditional sense, containing multiple works of short fiction, I would not be unhappy if we agreed not to use it in that way. Our existing types, with a binding code of "ph", would hadle that case well enough, IMO. -DES ^Talk 18:57, 15 June 2009 (UTC)

I can think of a few permutations where having a Chapbook (or whatever we decide to call it) container may be useful:

• 1 work of fiction + 0-n Essays + 0-n Interior art
• 1 essay + 0-n Interior art

On the other hand, I think that 2+ pieces of fiction would be probably better displayed as Collections even the total page count is low. What about a 25 page publication collecting 32-4 Essays, though? Is it Non-fiction or Chapbook? Ahasuerus 19:56, 15 June 2009 (UTC)

I agree with your two cases, and i incline to think the 25 page book with 32 essays is best recorded as simply Non-fiction, possibly with a "ph" binding if appropriate. But that would be something of a judgment call, IMO. -DES ^Talk 20:11, 15 June 2009 (UTC)

Sorry, that was supposed to be "2-4" Essays :-( Ahasuerus 20:27, 15 June 2009 (UTC)

I see. Well the same answer, I would prefer non-fiction for such a work. -DES ^Talk 20:38, 15 June 2009 (UTC)

Instead of trying to imagine all the permutations (how many poems for example) - perhaps we can put a general page count. I believe I have seen <100 pages to be defined in some places as a chapbook length publication (This is also probably related to the definition of 100 pages = a novel). I imagine there will be things above 100 pages (A singe previously published short work plus art plus intro for example) that we want to call chapbooks instead of novels, but <100 pages for multiple items seems like a 'fine' objective line in the blowing sand for multiple item publications. This definition could be applied for 'any' contents where the page count is less than 100 pages. Kevin 23:52, 15 June 2009 (UTC)

Well, the main reason that the Chapbook Title type has been so frequently requested is to prevent works of short fiction that have been published in standalone format from getting "lost" in the sea of short fiction at the bottom of the Summary screen. This is what many encyclopedias do (e.g. Clute) and what many ISFDB editors have been advocating. However, if a chapbook contains multiple stories and appears in the Collections section -- or contains multiple Essays and appears in the Nonfiction section -- then it's already visible as a "book" and the same concern doesn't apply. By putting collections with <100 pages in a separate section we would arguably make them harder to find. Perhaps we could even consider listing single-Essay chapbooks as "Nonfiction", which would mean having two Titles per pub: one Essay and one Nonfiction. Ahasuerus 00:32, 16 June 2009 (UTC)

(Also it should be used when the publication calls itself a chapbook - just as we use Novel for things that call themselves novels) Kevin 23:52, 15 June 2009 (UTC)

Oh no, we do not rely on what the publisher claims because their claims can be wildly off the mark. As Help:Screen:NewPub says, "Note that frequently a magazine will describe a story as a complete novel, even though it may be substantially below the 40,000 word mark. The description in the magazine should not be relied upon for this distinction." Ahasuerus 00:32, 16 June 2009 (UTC)

I agree with Ahasuerus, we don't and shouldn't go by what a publication calls itself, or what the author or publisher calls it, because their usage is way too inconsistent. The kind of publication I think we really need a "chapbook-like" type for is: publications with exactly one fiction contents item, shorter than novel length, with 0 or more non-fiction contents items, such as essays, introductions, cover art, interior art, poems, etc, etc. Such a work isn't a NOVEL, because the work of fiction is shorter than novel length. It isn't a collection or an anthology (although it is functionally similar) because those both normally include multiple fiction works. It isn't an omnibus, for similar reasons. It is desirable that such works appear in their own section of an author's biblio page, distinct from both novels and shortfiction, because they do exist as separate publications, but are not really novels. The only case i can see these being useful for beyond "exactly one work of fiction" would be to handle ACE Doubles and similar publications (e.g. TOR Doubles) when they are made up of exactly two shorter than novel-length works of fiction. And most people seem fairly content with the current handling of ACE and TOR doubles. -DES ^Talk 02:02, 16 June 2009 (UTC)

UNINDENT - I'm almost in agreement with both of you. My take: Max 1 item of Prose. 1 Item of Prose, or 1 Item of Fictional Essay, or N items of Poetry required. Unlimited Fictional Essays, Poems and all other title types. If Prose/Fictional Essay or Poetry absent, then it's a Nonfiction container pub and so be it. If it has Prose greater than 1 (excluding fictional essay) then it's an Anthology/Collection container pub. - I'm quibbling over the Fictional Essay now before we create it because it will probably come up later. I'm quibbling over poetry because I moderated a 2 poem, 2 essay chapbook the other day and it felt right at 25 pages or so. Kevin 03:26, 16 June 2009 (UTC)

I could also easily be talked into 2 being the max number for prose, with an upper page limit Y (Maybe 50?) that would exclude all the Ace doubles, etc. I could also be talked into an exemption for Any publication with fewer than Z (Maybe 25?) pages being a chapbook no matter what the contents. Kevin 03:26, 16 June 2009 (UTC)

Clarification - The upper limit Y I mentioned was only for when two non-essay fiction titles were present, in order to exclude the Doubles. I think I wasn't clear. Kevin 22:07, 16 June 2009 (UTC)

As to relying on the publisher... the concern is generally cases of 'inflation' where the publisher calls it something bigger than it actually is. I don't think Novels hiding as chapbooks will be a very common occurrence. Kevin 03:26, 16 June 2009 (UTC)

I assume that by "prose" you mean non-verse fiction, as technically an essay is prose. I can live with your take above, except thst zi don't see the need for the upper page limit -- pagee sizes vary soo much, and I could see s profusely illustrated 20,000 word story on small pages being 80 pages long or more. And I don't think your "any pub smaller than 25" pages clause is needed, but i won't argue the matter further. -DES ^Talk 12:52, 16 June 2009 (UTC)

I'm glad agreement is close: what you're talking about now won't affect the coding, only how to use it. Binding is a red herring - it won't affect the container type. So if we agree a SHORTWORK is a container type like an ANTHOLOGY or COLLECTION or NONFICTION or OMNIBUS, then we just have to make sure that when Publication Type and Title Type are both SHORTWORK then we treat it the same way as those: hide the content entry for such. We can reuse the CHAPTERBOOK code that makes such appear in their own section, above the shortfiction that I hate seeing such lost in. Yes, some books will no doubt get downgraded - I guess "The Trouble with Tycho" is a casualty of that, being a standalone novella, but it's not as bad as not finding that it was published as a standalone book. BLongley 20:18, 16 June 2009 (UTC)

Again, we can break this down into smaller steps:

• I think it's only a one-line change to stop CHAPTERBOOKS breaking as soon as you edit them (add CHAPTERBOOK to the list of content title type options, rather than forcing a change to ANTHOLOGY by default).
• Hiding the CHAPTERBOOK content so that people realise that it's just the container type, NOT the shortfiction/essay, is a little more work.
• Being able to ADD the container type to existing broken publications a bit more work still. (Think of all the Magazines with missing EDITOR records - we're working on those, and will have to do the same with these too. A fix script should be possible though.)
• (Optional step) Change all display logic to show "SHORTWORK" (or SHORTBOOK, or whatever people want) rather than "CHAPTERBOOK". (Would demand changes to every place the term is used, but saves us making a big database update.)
• Finally - eradicating the phrase "CHAPTERBOOK" entirely in favour of SHORTWORK (or SHORTBOOK, or whatever people want) will demand changes to every place the term is used, and a mass database update. BLongley 20:18, 16 June 2009 (UTC)

I'd prefer to see small incremental changes, but appreciate that people would see more "CHAPTERBOOK" entries appear in the meantime: but it allows people to demonstrate what they will use them for in the future before we do anything dangerous. Nothing in this set of coding proposals enforces any rules on what SHORTWORK/BOOK will finally be used for, any more than we enforce the number of NOVELs in an OMNIBUS currently, or SHORTFICTION works in a COLLECTION or ANTHOLOGY. BLongley 20:18, 16 June 2009 (UTC)

That sounds fine to me, I agree that usage of a CHAPTERBOOK/CHAPBOOK/SHORTWORK/SHORTBOOK type is a rules-and-standards issue, and that there is no need to enforce this via code, just as most of our current conventions are not so enforced. (Some idea of how we would use it probably affects what we call it, and maybe any special coding wanted, however, so it was worth discussing here a bit, IMO.) Changing the wiki help will be easy. Is a mass database update really needed? Could the display code be set to "translate" the CHAPTERBOOK type stored internally to whatever name we want, so that only raw SQL or Data dumps would see it? -DES ^Talk 20:33, 16 June 2009 (UTC)

We could stop at step 4 and leave the software to translate everything, but that still leaves confusion for developers and people using the raw data. I'd prefer we eradicated the term entirely, to avoid potential future confusion for people that arrive later and don't know the sordid history. And to avoid translation on every screen where it might be displayed. BLongley 19:43, 18 June 2009 (UTC)

I agree tht would be ideal, unless a mass data change is seen as too risky or onerous. -DES ^Talk 20:10, 18 June 2009 (UTC)

Implement new short item Title Types

Big Picture

Before we spend a great deal of time discussing the new sub-types, we may want to decide just how far (or "deep") we want to go with this. Limiting the number of title types and "storylen" selections to a relatively small set was a conscious decision since we didn't like what we saw in Contento's list of abbreviations. This decision was made very early in the project and it affected everything else that was done later, so undoing it now may not be easy.

What we may want to do first is outline what's wrong with the current approach at the functional level, e.g. the fact that there is no dropdown list in the storylen field or that it's overloaded with "jvn" and "nvz", and then see how we can address these issues conceptually. There will likely be certain trade-offs involved if we add more subtypes, e.g. it will make Publication and Title pages more clear, but it may also make it harder to run some searches. Ahasuerus 16:08, 14 June 2009 (UTC)

I think that we (as a community) have gotten particular (picky?) enough that there is now often a desire to go to that further level of detail. We also have enough data, that the rare instances of particular types, appear in the tens, if not hundreds within the database, or in the type of material now being entered/produced. In using Contento and Locus as a secondary source, we have been exposed to the benefits of having that extra detail as well. Kevin 16:16, 14 June 2009 (UTC)

I think some people have got picky and want to go to a further level of detail - e.g. magazines are now being entered to a level of detail I have no interest in, and this discourages me from working on them. But I won't stop them, as their activity isn't harming anyone else. Some of the suggestions below though are things that mean massive amount of rework - OK, there's only 200 or so maps but about 5000 Introductions, about 1000 Afterwords and 1000 Forewords. (And 20 "Foreward"s I'm suspicious of.) In most cases I can't see the benefits outweighing the rework. But I've tried to respond on each category. BLongley 20:53, 14 June 2009 (UTC)

There's closer to 750 Map titles when you include 4 variations: "Map (", "Maps (", "(map)", "(maps)" Kevin 21:27, 14 June 2009 (UTC)

Yeah, I just filed a bug report on that. :-( Title includes "MAP", type is "INTERIORART" works for two pages of results then forgets the title on page 3. BLongley 22:09, 14 June 2009 (UTC)

I am not sure we want to go to that level of detail either, but I'll have to think about it some more. BTW, it so happens that I verified a "Foreward"s just the other day. Who needs those pesky spelling rules anyway?.. Ahasuerus 21:30, 14 June 2009 (UTC)

I at least would like a somewhat greater level of detail than our current structure supports well, but perhaps not as detailed as some of the proposals below get. It seems to me that these suggested new title types mostly fall into two categories:

1. tools/types to enable capture of data not easily captured by our existing system, requiring awkward one-off kludges or not being recorded at all. These include, IMO:
   • Section titles
   • Group titles
   • Facetious/Fictional Essays
   • Non-Genre Shortfiction
2. tools/types to make finer distinctions between things we already are or could be capturing adequately if perhaps not optimally. These include, IMO:
   • Lists
   • Maps
   • Script
   • Play
   • Diagram
   • Audio Reading
   • Lyric
   • Frontispiece
   • Introduction
   • Afterword

It seems to me that the first group is more important to implement. Of the second group, it depends on just where it is judged worth making finer distinctions. (I would implement some of these but not all, if it were my sole decision, which of course it isn't.) Also, items in the second group would possibly require revising existing data is the db is not to be inconsistent in its handling of such things, as existing entries for many of them have been recorded under one or another of the existing types. That is mostly not true for the first group with the exception of Fictional Essays, where I think the change would be worth it.

I think the initial design decision Ahasuerus speaks of is now worth reconsidering, at least to some extent, but i also think we do not want to approach the number of types and subtleties of distinction that Contento supports. -DES ^Talk 19:17, 15 June 2009 (UTC)

One thing to consider is that we already have two hierarchical levels of Title Types. The first one is NOVEL, SHORTFICTION, ESSAY, etc and the second one is Novella/Novelette/Short Story. At the moment, only Short Fiction Titles can have "sub-types", but we could conceivably create new sub-types for some of the proposed Types. For example, "Frontispiece", "Maps" and "Diagrams" would become sub-types of INTERIORART, "Lists", "Introduction", "Afterword" (and perhaps "Fictional Essays") will become subtypes of ESSAY, etc. This would require the use of JavaScript, but we already require it during editing (but not while browsing) if you want to be able to add Authors and Titles. I suspect that this approach would make "title type" herding much easier and alleviate many concerns associated with the potential proliferation of "first level" Title Types. Ahasuerus 00:43, 16 June 2009 (UTC)

I gues that I have never really considered Novella/Novelette/Short Story to be types at all, merely values of the length property. But we could also use the "storylen" field, or create a new similar "sub-type" field, to make these distinctions. Just as the display code now shows the story length on some screens, the code could display such sub-types in proper cases. Sextion titles, group titles, and non-linking reviews could not be handled in this way, i would think. -DES ^Talk 01:51, 16 June 2009 (UTC)

Sub types is fine with me, it's both a database design choice and a coding choice. In fact it will probably remove some objection to the various types proposed IF we can code the drop down list to only present the proper options for each Top Type. Kevin 03:39, 16 June 2009 (UTC)

Conclusion?

Copied from #Non-Genre Shortfiction below, because it really applies to all types and so i wanted to answer it here. -DES ^Talk 20:59, 18 June 2009 (UTC)

Given the number of new types under discussion, it's probably wise to settle the ones that we think will work and which won't, and make one big change to the software to allow the ones we want. I think the mandatory database change is small - just add some more options to the enumerated types. (Unless people are expecting the introduction of such to magically change all current worked-around entries, and I don't think that's going to happen. People will have to fix things record by record.) What we will have to do is make sure the new types appear in all the right places on our current screens, or define where they should appear - e.g it should be fairly simple to include Non-Genre Shortfiction with Genre Shortfiction everywhere, but as the point is to clarify the difference it's probably wise to consider where such should appear. (IMO, somewhere near the bottom, but that could be at the bottom of Shortfiction or at the bottom of the page, and I guess there's always the possibility that Genre and Non-Genre Shortfiction end up in the same series.) BLongley 20:37, 18 June 2009 (UTC) End text copied from #Non-Genre Shortfiction below -DES ^Talk 20:59, 18 June 2009 (UTC)

And weren't you the person arguing for incremental changes in connection with "based on"? ;) That said you may have a point. Are we ready to make decisions on these yet? Should we set up a list and indicate approval or disapproval on each? Or do we need to discuss either the individual suggestions or the whole matter more first? -DES ^Talk 20:59, 18 June 2009 (UTC)

Some things can be best done incrementally, this doesn't look like it can be broken down easily. I don't think we want to rework all the same pages each time we approve a new title type. I'm not sure we're anywhere near conclusion yet on all types, but a summarisation of the options that have been raised should reveal that some ideas are already dead or withdrawn, some are still under discussion, and some are unresolved and either need more discussion that isn't happening or should be withdrawn. I see no harm in a neutral summary being posted for now: I don't think we're going to see new additions to the list, but maybe we should let people have the weekend to make sure of that. I know the discussion list is already getting too long for my taste, but we should have a possibility of "we'll do this, won't do that, and will leave the other worms till later" soon. Which is sort of an incremental change, as it allows for the possibility of a second set of changes, I'm just a bit sceptical about whether the second will ever happen. But the first should. BLongley 21:26, 18 June 2009 (UTC)

Facetious Essay

For those in-universe info-dumps that are not really factual, and so don't really fit "essay", but have no plot and are not realy stories. Things like the "Interludes" in Hammer's Slammers or the various appendicies in many of David Weber's books. For the matter of that, most of the appendices to LotR would fit this category. -DES ^Talk 05:48, 14 June 2009 (UTC)

Yes Kevin 06:31, 14 June 2009 (UTC)

I'm mildly tempted on this. But "Facetious Essay" makes it sound like one of the "Probability Zero" types to me, whereas "In-Universe Background Data" is the sort of thing I want it for. BLongley 20:03, 14 June 2009 (UTC)

How about 'Fake Essay' or 'Fictional Essay'? Kevin 21:10, 14 June 2009 (UTC)

'Fictional Essay' would suit my purposes. BLongley 21:14, 14 June 2009 (UTC)

'Fictional Essay' would cover many hard-to-categorize cases, so it looks useful. Ahasuerus 22:22, 14 June 2009 (UTC)

I'm fine with that name ("Fictional Essay") for this category. It is perhaps better than "Facetious". -DES ^Talk 13:00, 15 June 2009 (UTC)

I'd prefer "Fictitious" to "Fictional", but otherwise agree. -- Dave (davecat) 20:46, 16 June 2009 (UTC)

I prefer "fictional". Also, not sure if it's been raised but I have several fictional whole books that are aren't novels, e.g. reference books on dragons, travelogues of space trips.) ... clarkmci/--j_clark 08:43, 28 June 2009 (UTC)

Lists

To handle glossaries, Dramatis Personae, and other things that are lists, not really essays. -DES ^Talk 05:48, 14 June 2009 (UTC)

Yes Kevin 06:31, 14 June 2009 (UTC)

Maybe -- Dave (davecat) 20:52, 16 June 2009 (UTC)

Maps

As separate from other interior art. -DES ^Talk 05:48, 14 June 2009 (UTC)

Yes Kevin 06:31, 14 June 2009 (UTC)

Section titles

Sometimes collections and particularly anthologies are divided into sections, with section titles. There is currently no way to capture these titles, but it would be nice to be able to do. Interiorart entries have been abused for this purpose, but not often or consistently. -DES ^Talk 06:14, 14 June 2009 (UTC)

Sure Kevin 06:31, 14 June 2009 (UTC)

Whom do we credit the section titles to? And can we 'Hide' them on the Author's Biblio page if we credit them to the Author? Kevin 06:32, 14 June 2009 (UTC)

In an anthology, to the editor(s) I would say. In a collection, to collection ed if ther is one, or to author. Or better, make them an authorless type that displays only in pub records, never on author biblio pages. -DES ^Talk 06:55, 14 June 2009 (UTC)

I like the authorless type idea. Kevin 07:29, 14 June 2009 (UTC)

Essays and Shortfiction and Serials and Series have been abused for this too. I'm slightly positive towards this one. "Authorless" would be be good for such, but it might be simpler to work around with a convention for now before we go break "titles always have authors" rules. BLongley 20:08, 14 June 2009 (UTC)

Eh, maybe just give them all the author "Title, Section", with code in the contents display to never display Mr. Titles, name, just his work. Kevin 21:09, 14 June 2009 (UTC)

The Locus Index does something similar and we may want to review their approach to see if it will work for us. For example, would you say that the way "P.S.: Ideas, Interviews & Features..." is displayed in Ballard's Cocaine Nights would work? It seems to be lacking something extra that would make it stand out as a section title. I guess we could bold or italicize it at display time as long as we have a separate code for it internally. Also, if we make it author-less, it may necessitate other changes since the software currently requires at least one author for each Title. "section title" as a new reserved Author name in addition to "uncredited" and "anonymous", perhaps? Ahasuerus 22:32, 14 June 2009 (UTC)

How about just Prepending and appending "-----" to whatever the section title name should be? Kevin 23:38, 14 June 2009 (UTC)

Well, as long as it's just a display issue, we can easily change it later. We just need to decide what we need to do at the data level. Ahasuerus 01:44, 15 June 2009 (UTC)

I could live with a convention of entering these with a generic author, which would not be displayed, if that would be technically easier than making them truly "authorless". I like Kevin's idea of displaying these surrounded by "-----", but as you say, the display format can be changed more easily than the db format goign foreward. -DES ^Talk 19:22, 15 June 2009 (UTC)

Script

Script, Teleplay, or Screenplay, or other type of 'story directions for recorded visual medium' Kevin 06:17, 14 June 2009 (UTC)

I think I would combine this with "Play" but not a big deal. -DES ^Talk 06:58, 14 June 2009 (UTC)

Traditionally, Play's have been a more accepted form of fine literature (See Shakespeare), but in SpecFic, the Script adaptation is much more prevalent. By separating the two, those interested in the (percieved?) differences can pick and choose whether to read the Plays of Terry Pratchett, or the Screenplays of Heinlein by type. (Scripts often have much more detailed, set layout descriptions and opening and closing effects etc described for each scene, and are frankly a less 'involving' read, than Plays IMHO). Kevin 16:32, 14 June 2009 (UTC)

I think that is true is some cases, but far from all. Light disposable farces, and scripts for fan dramas presented at SF conventions, are just as much "plays" as Shakespeare is. I am always suspicious of a type distinction largely supported by arguments about quality. For the matter of that, soem stories have been written partly but not entirely in dialog/play format. For example Blish's "More Light") consists largely of the text of a play, with a framing story indicating how the narrator came to read it. -DES ^Talk 19:33, 15 June 2009 (UTC)

I wasn't trying to denigrate Scripts, only to point out that more people are used to reading LIGHTS UP - MAIN CHARACTER IS AT THE CONTROLS OF THE SHIP as opposed to FADE FROM BLACK WITH A DESCENDING ZOOM TO MAIN CHARACTER AT THE CONTROLS OF THE SHIP. (shrug) - Camera direction (if present) I find to be distracting. Some folks may not mind the differences. (shrug). Kevin 00:05, 16 June 2009 (UTC)

I am inclined to think that merely recoding plays and scripts as works of shortfiction (or novels, if long enough) with a note about their dramatic form is enough, but if more distinction is wanted then i think that a single "Dramatic Work" type covering plays, video/audio scripts (when published as such) and any other works published in dramatic form would be sufficient. -DES ^Talk 19:33, 15 June 2009 (UTC)

I Could live with a single type for both. I don't have a significant concern. I just wanted to make sure both options were on the table before a decision was made. (That's how you make good decisions in my book). I could go with 'Script' for both, or 'Dramatic Work' for both. I think 'Play' for both types would be misleading. Kevin 00:05, 16 June 2009 (UTC)

Play

Story directions for a live acted visual presentation. Kevin 06:17, 14 June 2009 (UTC)

I've got by without this and "Script" fine for now. Are people unhappy about the way the Pratchett Plays are entered? I think I got a comment on some of the Quatermass books too, but that's the only way you can read them so they've been left in. BLongley 19:12, 14 June 2009 (UTC)

I'm saying I can't search for a play. I have to search the title for 'play' and sift through the results (If I want to find a play). Kevin 19:42, 14 June 2009 (UTC)

So you CAN search for a play then. Yes, the results will get messed up with things like "The Game-Players of Titan", but that's what advanced search is for (and not the broken bits either). Have we got a load of unemployed thespians searching us daily for new ideas? I suspect not. I haven't even had people ask why the Plays aren't variants of the main titles. (Which I'm beginning to lean towards myself, actually.) BLongley 19:59, 14 June 2009 (UTC)

Thats a circular argument. By that standard, all title specific information should be overloaded into the title field, and we don't need any Title Types. You CAN find everything... you just have to work at it. Kevin 02:47, 15 June 2009 (UTC)

No, I'm just saying that the "- The Play" suffix convention is currently working. I wouldn't use that to justify removing all title types in favour of "- a collection", "- a novel", "- an omnibus" suffixes with tens of thousands of edits to get to that state. It's just that as we have a workaround already I can't see the need to change. "It ain't hardly broke, so don't hardly fix it". I'm sure there are hidden plays still, but I haven't seen anyone asking about how to find them in the years I've been here. Not worth the effort, IMO. It's not even been important enough to really consider whether the Plays I do know about should go under the main title or be variants of them or totally separate as now. BLongley 17:33, 15 June 2009 (UTC)

If we had a standard of '- The Play' then I might agree that it isn't broken. But the good news is after checking my local database I can now agree that two title types for plays/scripts is overkill. I found less than 200 titles for "the play", "(play)", " script", "teleplay", and "screenplay", Kevin 00:16, 16 June 2009 (UTC)

Well, '- The Play' wasn't my standard, fortunately PTerry or publisher seems to have adopted that anyway. BLongley 19:34, 16 June 2009 (UTC)

Diagram

Technical type Interior Art (Ship Schematics, Timeline of Events, Family Tree of characters) - Any visual presentation (other than map) where there is information in the artwork, as opposed to artwork for, err well artworks sake. Kevin 06:17, 14 June 2009 (UTC)

If this is desired, I think it could cover Maps too. (Even though I do find the presence of a Map in modern Pub contents as a useful warning sign that I'm probably not going to like the book.) BLongley 19:21, 14 June 2009 (UTC)

That would be possible, but I suspect that maps far outnumber all other diagrams, and may be worth marking as such. But I am not wedded to either "map" or "diagram". -DES ^Talk 19:34, 15 June 2009 (UTC)

I agree maps far outweigh other 'specific' interior art types. My primary concern in addressing this was to see if there was support for Family Trees , Time-lines, and Organizational Charts, that now often get a mishmash of 'essay' or 'interior art' designations depending on the editor. I'm fine leaving ships schematics etc as interior art. If we do not implement this type, we should address the help to try and steer them towards one or the other for those sub-items. Kevin 00:24, 16 June 2009 (UTC)

Audio Reading

Podcast, download, etc. A short work, read to the listener, by a single reader (or a group of readers who do not alternate readers based upon the dialog or actions in the story). Kevin 06:17, 14 June 2009 (UTC)

I don't think this is a type of title. A give work, printed, read aloud, and dramatized, should none-the-less have only a single title record IMO, and we already distinguish audio books by binding. -DES ^Talk 07:06, 14 June 2009 (UTC)

I can't distinguish with Binding when it's included in a publication already. See Subterranean Online, Spring 2007 and Subterranean Online, Summer 2007. I also imagined that it would be a variant title of the printed published title. Kevin 07:28, 14 June 2009 (UTC)

I hadn't thought of that situation, and it makes a bit more sense now. Still I think a note might handle this rare case. -DES ^Talk 13:32, 14 June 2009 (UTC)

About half the Subterraneans online that I haven't entered yet have similar audio contents. I believe Clarkesworld also always issues a podcast of one of its stories. It's very likely to be something more and more of the better webzines will do. Also some ISBNs in the near future may include the printed word, the ISBN, and the audio at a single bundled price (Or more likely the ebook and the audio download, skipping the print). Several of the early Baen CD Bind in Extra's included the audiobook as part of the same purchase. Things are being 'bound' together today in ways that were impossible before (Which coincidentally I think I recall also helped give rise to the modern novel... it could be bound as a single volume inexpensively) Kevin 02:50, 16 June 2009 (UTC)

Hehehe - First we had words, then people started putting pictures with them, and now they are including sound - I'm just poking fun, but what will we do when they sell a single Blu-Ray disc with ebook, audio book, audio dramatization, graphic novel (ebook) and the feature film all together? Maybe we can call the film Interior art? - Chuckle - Maybe we can talk the IMDB into linking back to US for a change?) Kevin 02:50, 16 June 2009 (UTC)

I'd be against doing this as a title type. Possibly we need to do something more with pubs to allow for it. But the title as such should refer to the words, whether printed or read. -- Dave (davecat) 21:15, 16 June 2009 (UTC)

Audio Dramatization

Podcast, download, etc. A short work, read to the listener, by a cast of readers / audio actors (who alternate readers based upon the dialog or actions in the story), or that includes sound effects (other than simple opening music). Kevin 06:17, 14 June 2009 (UTC)

I don't think this is a type of title. A give work, printed, read aloud, and drqamatized, should none-the-less have only a single title record IMO, and we already distinguis audio books by binding. Moreover I think true dramatizatiosn should be OUT of scope altogether, just as video dramatizastions are -- ther are too many data elements that woukld nee to be captured to so such justice (cast by role, director, producer, musicians, sound effects, author of script, author of work from which script was adapted, etc). -DES ^Talk 13:30, 14 June 2009 (UTC)

Any rule which excludes The Sagan Diary by John Scalzi (Read by Elizabeth Bear, Mary Robinette Kowal, Ellen Kushner, Karen Meisner, Cherie Priest and Helen Smith) is a silly rule. But the distinction between a single reader, and multiple readers, and again the distinction between a simple narration, and one that includes radio style sound effects is worthy of documenting, as evidenced by your reaction to the same. To each their own I say, and why don't we catalog to a level of detail that allows each to find their own. I tried to draw the line between the two title types at the happy medium. Single narrator only (for the purists like yourself), and all other type (for those wanting something different). Would you really seek to exclude this gem of Tolkien's Hobbit and LotR. Kevin 16:24, 14 June 2009 (UTC)

One could equally argue that any rule that excludes Forbidden Planet is silly. But we exclude all videos, of what ever quality and significance. Similarly i would exclude all dramatizations (at least ones with multiple readers) and would think they could be deleted on sight, just as RPG modules are. We have Scope and RoA rules for a reason, and it is not appropriate to have things be IN or OUT depending on who is doing the entry or moderation. (of course no one has to enter things they don't choose to enter.) That said the example (The Sagan Diary) you cite I might well call an audio-book and count as IN. I would exclude the Tolkien, although I would love to have a copy, and have entered some JRRT audio books in the past. -DES ^Talk 16:38, 14 June 2009 (UTC)

"Forbidden Planet" is in, but only the novelization. If we have a valid dead-tree version of a work I don't mind an audio version of it. But that would be for comparable versions - e.g. it doesn't justify the soundtrack of the film. The number of performers doesn't matter to me: a relationship to the written work does. So I can cope with "Unabridged" and "Abridged" audiobooks, but not "a dramatization for radio" that bears no relationship to a particular book or story. Some Doctor Who "audiobooks" probably cross that line for me already. BLongley 19:34, 14 June 2009 (UTC)

I think this type is about "dramatizations". And that is another reason for them to be OUT, they are often sufficiently different from the underlying printed work that they would need to be separate titles, not merely variants of or publications of the underlying written story. Dramatizations often (although not always) elide descriptive text or move it into dialog, for obvious reasons. In some cases much more rewriting than that is done. -DES ^Talk 19:37, 15 June 2009 (UTC)

The problem is drawing the line. Straight read = in. Multiple readers (by Chapter) or 'Voices' plus narration true to the text = in (Put here or under Reading Above). Straight Read / Alternating voices + 'some' limited music = in (Put here or under Reading above). Read or voices + some sound effects = Limbo. Partial Rewrite (for length, or for effect) = Limbo. Complete re-write = out. I pointed out all these combinations because I think that Multiple 'readers' is in because it's the same text, and many audio books supplement with mild music or rare sound effects. Couldn't any 'abridged' audio version have just as much anonymous changes as your average radio dramatization? I fully agree that complete new 're-imaginings' of a story in Audio are out. My problem is that I think you have drawn the line so close, that half the audio books out there are now 'out', but we can't tell they are out unless we listen to them... so keep some sanity by moving the line to where we can identify it without doing a minute comparison of the work, but this moves enough 'dramatized' things (Some music, some sound effects, some re-write/abridgment for time/format) 'into' the database, that now we need to separate 'Single Reader' from 'Combinations of Readers / sound effects / but not a re-imagining' in order to document that some are more pure than others, and Cast of 1 vs cast of 1+N is easy to identify without listening to the complete work. (PS This line I'm moving, is an example and not my line. If I was king for a day, almost everything published without moving pictures would be 'in' in one shape or form, but I think you guys know that by now.)Kevin 04:04, 16 June 2009 (UTC)

On audio, I tend to have an "exclusionist bias" and if you reallu want a bright-line rule, I'd be willing to draw it at "single reader" -- anything with multiple readers is out -- although I think that is probably too conservative. But I think the two of us have probabvly hashed though our views prett throughly, and i at elast intend to wait for the input of others on this type. -DES ^Talk 12:36, 16 June 2009 (UTC)

Lyric

Spoken words of a poem or song, intended to be accompanied by music (Music not required in notation, score, or audio track form). Kevin 06:17, 14 June 2009 (UTC)

Is there really enough difference from "Poem" here to make the distinction? A good many of Kipling's poems, for example, seem to have been intended to be sung, and I have heard them performed, set to popular (music-hall) tunes of his day. Other examples could be cited. -DES ^Talk 13:55, 14 June 2009 (UTC)

I can't see a lot of need for this, and it doesn't cover the situation where the musical notation is included. BLongley 19:09, 14 June 2009 (UTC)

Actually I purposely defined it ("Music not required...") to apply in those cases where music is present. I figured with all the SpecFic exclusionism (Too many pictures.. Out. Too many voices... Out. Too many sounds... Out. Too many musical notations... Out.) going on around here, the title type of 'Score' suggestion might get me in hot water. Kevin 20:43, 14 June 2009 (UTC)

I don't think I'm in favour of "out" on any of those grounds. I just don't see a distinction between our current use of POEM and this that couldn't also be used to demand a separation for POEMs that do have musical notation. (All those filkers that started in Merovingen Nights, for instance.) BLongley 21:18, 14 June 2009 (UTC)

I agree with Bill here. i wouldn't exclude lyrics with notes (scores), merely record them as poems. -DES ^Talk 19:39, 15 June 2009 (UTC)

That was kind of my point in proposing this; Getting songs out from under poems. I'm honestly curious about songs that may be printed in books, but most 'poetry' leaves me bored. This was intended to cover Songs (with music printed), songs (without music printed), songs (without music printed, but commercially available elsewhere). It was also intended to cover the extremely rare case where a well known author writes Speculative Fiction Songs, and releases them as commercially available rock music. Kevin J. Anderson released an album Terra Incognita: Beyond the Horizon 2 weeks ago where "Anderson developed and expanded one of the novel's storylines to form the basis of an epic rock CD, under the band name "Roswell Six." He and his wife, bestselling author Rebecca Moesta, wrote all the lyrics to the songs." It shares the universe with his most recent novel Terra Incognita: Edge of the World. Heck, I have a CD of Non-genre songs sung by Travis S. Taylor, but since it's non-genre and not officially released and I'm not sure on the authorship it's not appropriate, but it's a darn cool footnote for a complete bibliography. This is one of those things where if you have a title type, it just might bring some bibliographical goodies out of the closet of history. (Shrug - Who knows). I'm not going to be upset if this doesn't go in this time. Kevin 02:01, 16 June 2009 (UTC)

Well, if we go with the "sub-types" approach outlined above, we may decide to create a "song" "sub-type" for POEMs. Ahasuerus 02:35, 16 June 2009 (UTC)

Sub Type is fine here (Above I said 'out from under Poems' but a subtype of poem is just dandy). Of course if this goes live, I'll have to bring up The Who's 'Tommy', Wagner's 'The Rings', and perhaps Rush's 'Cygnus-X' as spec fic. - Chuckle - Just kidding (Sorta) Kevin 04:43, 16 June 2009 (UTC)

Frontispiece

Introductory interior artwork (A higher class of interior artwork) - An alternate choice might be to go with 'Int. Artwork (Pen and Ink)' and 'Int. Artwork (Color/Painting/Photograph)' - An Aside, this alternate option could be adapted for the few Graphic Novels we let in to document the various contributors since they usually separate tasks. There have been some fantastic frontispieces over the years (And more to come as the specialty presses keep chugging along), and relegating them to the closet of 'interior art' along with Jack Gaughan's doodles and similar sketches seems such a shame sometimes. Kevin 06:30, 14 June 2009 (UTC)

I see endless arguments over "quality" if we implement this. And a good many books, particularly from specialty presses, have some very high quality interior art that is not a frontispiece. I can see some reason to distinguish between Interiorart (Color) and Interiorart (B&W) though, or perhaps to distinguish "plates" (set on their own page, nothing on the verso, possibly do not get a page number). And there is currently no good way to indicate multi-page interior art. -DES ^Talk 13:52, 14 June 2009 (UTC)

Why not go all out? (I like the Plate Idea!). Frontispiece, Plate, Interior Artwork (Color or Photograph), Interior Artwork (B&W), and Interior Artwork for all undifferentiated items. Kevin 16:06, 14 June 2009 (UTC)

Ohhh - Just had a (great?) idea. What if we overloaded the 'length' data field for Interior Artwork? When no length is specified, it's just 'Interior Art', but if we add a length of Frontispiece , etc then it will modify the display inside a publication (And on the Artists Biblio page?) just as Novella, Novellete, SS do now for short works. May require some other monkeying with the system (Change Length to Subtype in the entry pages). That solution might actually work for ALLOT of both our suggestions in this section. Kevin 16:06, 14 June 2009 (UTC)

I have no desire for this. If people really want to distinguish Artist efforts this much, I think they would be demanding links from the titles on their page to the actual uploaded images first. As it is, nobody's really addressed artist pseudonyms, and people are rarely merging coverart or such to tidy up artist pages. Very low priority, IMO, not just from my perspective but from what I see people doing with artists at the moment. (Which is mostly just trying to identify them!) BLongley 19:44, 14 June 2009 (UTC)

I'm generally against distinguishing types of interiorart. I wouldn't yell & scream if we had subtypes for color & monochrome, but I don't think it would add enough to be worth it. -- Dave (davecat) 21:35, 16 June 2009 (UTC)

Signature Page

It's a stretch, but it would be nice to document the bound in signature pages of the various special editions as a content level item when viewing the publication in the database. Kevin 06:30, 14 June 2009 (UTC)

Yes, it's a stretch. I think I'd support "Cigarette Ad page" above this, just to keep the magazine page-counters happy. BLongley 19:47, 14 June 2009 (UTC)

How about 'Special'. In the rare instance that there is a 'Special' page in a publication (Signature Page, Cardboard Advertisement, Contest Entry Form, etc). Anything that would/might be of special interest to a collector (Due to presence or absence), but doesn't fit under any particular title type. The page itself will probably be descriptively titled, "Kent Cigarettes" type 'Special', "Signature Page" type 'Special', etc etc such that the type description itself WOULD be redundant, but documenting it as special removes the need for faking it up as an essay, or leaving it malingering just in the Notes. Aha! - Could this be another Author-less type, like the Section Separator discussed above? Could be used to document 'ANY' type of Bind in or tip in feature of a book. Would make documenting errata pages easier when they exist, or 'certificates' that might accompany some special super uber limited editions. (Gosh wow - If I buy this One of a Kind Super Limited Edition, I get the Authors Grocery List in his own hand from the day he delivered the manuscript). Thoughts? (Again, I fairly well expect this to be not added, but at least we discussed it) Kevin 02:37, 16 June 2009 (UTC)

I guess if we have "sub-types", then we could have a TYPE of "Special" (?) and a list of "sub-types", which would include "Section Header", "Signature Page", "Contents Entry Form", etc. Keep in mind, though, that Help is currently written to exclude most of these sub-types, so it would require a great deal of re-verification. Ahasuerus 02:43, 16 June 2009 (UTC)

It's going to happen sooner or later. Any OCD Based Collection hobby (bibliography included) will always get more detailed with time. The work isn't finished until each artifact/item/feature is photographed and filed along with a description of them item in excruciating detail (Look at Taxonomy, Archeology, Ornithology, etc). On a more serious tone, if we are clear in our discussions of verifications that 'All verifications prior to X date may have excluded Y data types' we will be on solid ground for leaving those verifications alone until someone comes along who already wants to reverify that work. Same as has been happening with Cover Art since uploading was enabled last year. Kevin 04:32, 16 June 2009 (UTC)

First off, I don't know what's meant by a "signature page". But there is a problem with including (say) cigarette-ad pages (& SFBC-ad pages, etc. ad nauseum), in that these were often perfed to be torn out. It's often not obvious that something is missing. Potentially, there goes a lot of verification. (Um. I wonder whether these things were ever geographically targeted, different in different copies.) -- Dave (davecat) 21:43, 16 June 2009 (UTC)

I think that a "signature page" is the page in a special signed & numbered edition, that carries the author's signature, and sometimes the signatures of the artist, editor, publisher, or other people significant to the work. Such pages are part of the printed book, just like title pages, and no more likely to be ripped out. I think Bill's suggestion of "Cigarette Ad page" was satiric, though Keven ran with it. -DES ^Talk 22:21, 16 June 2009 (UTC)

Many of the Limited, and Special editions, as opposed to the Trade editions of works coming out these days from some specialty presses (Subterranean is one I have an example of) have an extra 'signature' page bound into the book, with an inked signature. This is usually an unnumbered early page. Kevin 22:20, 16 June 2009 (UTC)

Movie/Album/Graphic Novel Review

I hesitate to suggest this, because so many of the science fact books (which read like science fiction - and I love having cataloged here) and the premier level Graphic Novels could get lumped into it, but how about a 'Review of Non-ISFDB Material'. This would be a combination of essay and review. The Authors and titles would not be hot linked, but it would display as a review (indented, with title, and reviewed work authors shown) inside a publication. Gives proper credit to the reviewer, documents the review (In case the RoA ever change and we can enter them - (Like published filk CD's as an example of a borderline exclusion). Kevin 07:18, 14 June 2009 (UTC)

There is some merit to the non-linking reveiw IMO. Or perhaps just a "do not link" checkbox/flag on the existing reveiw type, to reduce the interface complexity and the number of distinct types. -DES ^Talk 13:46, 14 June 2009 (UTC)

I like the checkbox solution. It also removes this change from this Title Type change discussion. Thanks. Kevin 15:55, 14 June 2009 (UTC)

What about things that are 'In', and reviewed, but not a 'book' (Webzines, Fanzines, Audio Dramatization) Do enough of those exist to fix the 'Book Review' Language with a second 'In' review type? Kevin 07:18, 14 June 2009 (UTC)

Just change the language to simply "Review". I have already entered and linked a number of reveiws of shortfiction works that are not "books". (And I don't agree that Audio Dramatizations are IN. Where do the RoAs include them? See above for why they shouldn't be in, IMO.) -DES ^Talk 13:37, 14 June 2009 (UTC)

I like changing the language to just 'Review'. It also removes this change from this Title Type change discussion. Thanks Kevin 15:55, 14 June 2009 (UTC)

I think Reviews will work so long as there is an ISFDB title to link to: Books, Magazines, Fanzines all work. The display of such could be clarified dynamically I think to show "Magazine Review" or "Fanzine Review" - or just simplified to make it clear it's not always a book. BLongley 20:18, 14 June 2009 (UTC)

To clear up a a lot of our data it would be less effort to change a review to a non-linking review (have you ever tried to change one to an Essay?) so that might be something to look at anyway. But it's not that simple - e.g. we have "Authors" here that exist only because somebody reviewed their single or album. And those Musicians and Bands should go, IMO. BLongley 20:18, 14 June 2009 (UTC)

Don't forget that some Editor title records are merged. See example. The only way you would be able to link to a specific magazine or fanzine is a by link to the pub.--swfritter 00:06, 15 June 2009 (UTC)

I've never felt too bad about linking a magazine review to the year, I'm sure most users can pick one title out of 12 after that. (Or are there weeklies or fortnightlies merged at year level)? Offering links to publications might be good but then people would use them to link books to the exact publication being reviewed, which makes finding them from title level a bit more of a pain. This might be the right thing to do, but I've seen many reviews that refer to both the hc and tp versions. And such should probably apply to all exact reprints as well. The level to link to is "edition" probably, but we don't have that. BLongley 17:43, 15 June 2009 (UTC)

Anyway, as I see it there's enough problems working out what to fix when a review becomes non-linking. BLongley 17:43, 15 June 2009 (UTC)

Short Short Fiction

Defined as being between 1000 and 2500 words in length per Wikipedia] though I could easily live with combining this with the flash category below. Kevin 07:18, 14 June 2009 (UTC)

I think this would at most be an additional storylen setting, not a title type, just like Novella, Novelette, and Shortstory. But don't we already have enough arguments over what length a given work is? why add more? and AFAIK none of the major awards distinguish these super-short lengths. -DES ^Talk 13:42, 14 June 2009 (UTC)

You are correct, I was getting myself wrapped up in the different 'types' of items I would like displayed separately on the Author's biblio page, or that would have the 'length' call outs we have discussed elsewhere. I retract the suggestion. Kevin 15:51, 14 June 2009 (UTC)

I'm happy to look at this as a Shortfiction story length, but again, I'd want some justification. The category below has at least 300 titles that I know could be mildly usefully adjusted. How many in this category would benefit? BLongley 22:20, 28 June 2009 (UTC)

I haven't a clue. I threw it out for discussion, then realized it wasn't a title type, so stopped thinking about it. (shrug) Kevin 02:46, 29 June 2009 (UTC)

Flash Fiction / Super Short

Defined as being between 1 and 1001 words in length per Wikipedia. Kevin 07:18, 14 June 2009 (UTC)

I think this would at most be an additional storylen setting, not a title type, just like Novella, Novelette, and Shortstory. But don't we already have enough arguments over what length a given work is? why add more? and AFAIK none of the major awards distinguish these super-short lengths. -DES ^Talk 13:43, 14 June 2009 (UTC)

You are correct, I was getting myself wrapped up in the different 'types' of items I would like displayed separately on the Author's biblio page, or that would have the 'length' call outs we have discussed elsewhere. I retract the suggestion. Kevin 15:51, 14 June 2009 (UTC)

This designation actually would be very valuable for a lot of magazine entries; Ferdinand Feghoot, etc. The awards distinguish stories with these lengths by almost totally ignoring them. The arguments over story lengths are very rare except in the case of novella vs novel.--swfritter 11:57, 28 June 2009 (UTC)

I can support this as another SHORTFICTION storylength setting if it's going to be of significant use. There's at least 300 book entries that would benefit: Drabbles are exactly 100 words and would fit nicely here, but I'm not asking for Drabble as a separate category. I'll fix Drabbles if someone else will fix the rest though. (And yes, I do mean I'd look into the coding changes as well as fixing the 200 Drabbles already here, and maybe adding the other 100 as they're Spec-Fic too.) BLongley 22:08, 28 June 2009 (UTC)

I can see the value in clearly identifying qualitatively different types of Titles, e.g. fictitious essays, but I am not sure under what circumstances a higher level of granularity for story length would be desirable. Are there some uses for it that I haven't thought of? Ahasuerus 02:23, 29 June 2009 (UTC)

Introduction

And possibly 'Author's Introduction' to separate between 1st party and third party introductions. Kevin 07:33, 14 June 2009 (UTC)

Um. Why? I'm inclined to think that having ESSAY as a type, & "introduction" or "preface" or "foreword" in the title, is adequate. Admittedly, authors (& editors & other 2nd-party introducers) don't always use such a word; but I think the potential gain is still very small. -- Dave (davecat) 21:50, 16 June 2009 (UTC)

Afterword

And possibly 'Author's Afterword' to separate between 1st party and third party introductions. (And yes, I'm stretching the envelope all over with these suggestions, because it will probably be a 5 years before we go through this type of content item expansion again, if ever) - Blame DES. He started it (chuckle). Kevin 07:33, 14 June 2009 (UTC)

What is the value of distinguishing between Introductions, afterwords, and other essays? I don't see it, but maybe after you point it out... -DES ^Talk 13:39, 14 June 2009 (UTC)

Introductions discuss the 'work at hand' with the understanding the reader hasn't read it. (No spoilers). Kevin 15:48, 14 June 2009 (UTC)

Afterwords discuss the 'work at hand' with the understanding that the reader has probably read it (Usually a more critical analysis - with spoilers). Kevin 15:48, 14 June 2009 (UTC)

Essays do not need to have a 'work at hand' and can (and often do) stand alone. There is no required associated longer/other work. Essay's are more likely to be reprinted elsewhere, referenced, etc. while introductions and Afterwords are nearly always tied to a single work. Essay's can also be about something totally different, like a science fact article or other non-fiction type short work. Kevin 15:48, 14 June 2009 (UTC)

I think that is not merely as general a rule as you may believe. I have seen a number of "critical introductions" that discuss the work or works in detail, not avoiding spoilers. I can slso cite at least one case of an introduction later reprinted away from the work it origanally introduced. (See 118815.) Come to think of it, both Clarke and Le Guin have included introductions from other publications in collections of essays. Also, I have seen anthologies that include a "Foreword", a "Preface", and an "Introdution". Would all these be of type "Introduction"? With granularity this fine, it might be much harder to find a given work, and I can foresee lots of argument over borderline cases. (More types make more borders and hence more borderline cases, and i cna think of a number of texts that don't exactly fit any of the proposed subtypes but aren't exactly critical essays either.) I think this is probably going too far in differentiation. -DES ^Talk 20:02, 15 June 2009 (UTC)

All good points, and perhaps valid enough to exclude this title type. (as to being reprinted, I just said that essay's are more likely to be reprinted elsewhere). Kevin 02:16, 16 June 2009 (UTC)

As for my general reasoning, I attempted to recall Every 'type' of extra information we overloaded into the Title Field, because we didn't have a Title Type (Introduction (STORY NAME), Afterword (STORY NAME), Map (STORY NAME), etc.) and we created a title. We used to overload the title field for Variants, then we upgraded. This is just another upgrade. Now we can have STORYNAME of type MAP, STORY NAME of type Authors Introduction, STORYNAME of type Afterword, etc, just as we can now have STORYNAME of type Interior Art. AND Bonus - We can break all those introductions, etc out of Essay on the Author Biblio page. Now any critical essays they write can stand out from the crowd of introductions etc. Kevin 15:48, 14 June 2009 (UTC)

The need for parenthetical additions is not to subtype but to disambiguate. There are thousands of pieces of text (whether we call them essays or whatever) whose only title is "Introduction" If we don't put "(storyname)" into the title, the author's biblio page may have a dozen or more entries that can't be distinguished except by drilling to the publication level. If we changed these all to type "Introduction" we would still need to keep the "(storyname)" in the title, or there would merely be a section on the biblio page "Introductions" with a bunch of things not usefully distinguishable from one another. And don't suggest that the disambiguator can be automatically picked up from the enclosing publication. This makes no provision for intros to individual stories, of which I have entered quite a few (when they seem significant enough to record, not mere blurbs -- a judgment call) Auto-disambiguation also won't handle well the situation when an anthology or collection is reprinted under a different name, but with the introduction unchanged. -DES ^Talk 20:02, 15 June 2009 (UTC)

You are correct. I wasn't considering the disambiguation completely. It will still be needed on some cases (many cases?). But some cases could end up going the way of interior art and sharing the name of the primary work with a different title type. How does this strike you (This is my last argument for an Introduction and Afterword Type). Picture a basic novel, with an Intro, Novel, and Afterword. With a separate Intro and Afterword type, it could be entered as 'NOVELNAME type Intro', 'NOVELNAME type Novel', and 'NOVELNAME type afterword'. Now disambiguation isn't needed. Feel free to say 'I Hate it, we'll never do it that way'. As I mentioned earlier tonight and several sections above, I posed most of the multiple 'slices' here to get it all out on the table, and trim it down to what we wanted. Better that, than to get done and realize we should have put in something not considered. Kevin 02:16, 16 June 2009 (UTC)

I think 'NOVELNAME type Intro' and 'NOVELNAME type afterword' might encourage people to break the 'exactly as stated' principle. Did it actually say "Intro" in the pub, or "Introduction" or "Introduction to Novelname"? Was the afterword called "Afterword" or "Author's Afterword" or "Editor's Afterword" or "Publisher's Afterword"? Yes, I know our current convention is only "Exactly as stated (plus a possible suffix)" but we've lived with that quite a while now. BLongley 18:20, 16 June 2009 (UTC)

I agree with Bill here. Kevin's suggestion might well work for the sort of "basic" case he describes, but I thing it will fall down on more complex cases, cases where an into or afterword is reprinted as an essay later (I cited several above) and cases where an intro or afterword, particularly by someone other than the author of the work being introduced, has its own title. It is in some ways a nice idea, but I think it falls down on inspection. -DES ^Talk 19:42, 16 June 2009 (UTC)

I can see the reasoning, but I've never really heard any clamour for differentiation of INTERIORART or ESSAY before and there would be an awful lot of rework of existing data needed for little benefit that I can see. BLongley 20:26, 14 June 2009 (UTC)

Clamour? No. Not when [2]What's New is 365 days - 1 whole year out of date (as of today oddly enough). There hasn't seemed to be much point. I'd probably be happy enough with Intro/After, Fake Essay, Map/Diagram, and the old Essay and Interior Art, but you make hay when the sun is shining, and it appears right now that the sun is shining. Hence all the noise. Kevin 21:06, 14 June 2009 (UTC)

Good point about "What's New" - updated now. Thanks! Ahasuerus 21:47, 14 June 2009 (UTC)

Non-Genre Shortfiction

I have several times seen people try to enter the Shortfiction contents of non-genre or mixed-genre anthologies or collections, and they often try "NONGENRE" contents, which just creates new book-level titles. Someone desperately wants such in, judging by Maxim Jakubowski's page. I suspect a lot of shortfiction here isn't actually genre but is added for completeness. Could we use such a category, or just encourage people not to enter such? BLongley 20:37, 14 June 2009 (UTC)

I Like the idea. It documents the contents (when someone has entered them) so they don't get entered again, and properly classifies them. Many of the collections in Bleiler's checklist are collections with 1-3 'in' stories, but he doesn't identify the stories explicitly. Kevin 20:48, 14 June 2009 (UTC)

Separating "genre"/"non-genre" from Title Type has been often requested and I agree that we need to do it. Like some other proposals here, it probably belongs on the ISFDB:Proposed Design Changes page since it will require a database change. No hurry, though; we are accumulating a lot of good info here and can sort it out later. Ahasuerus 21:38, 14 June 2009 (UTC)

I also like the idea, but agree that it does not need to be on the "right away" list. -DES ^Talk 20:03, 15 June 2009 (UTC)

I agree that this would be a Very Good Thing, having run up against the what-to-do-with-nongenre-contents problem a few times. I also agree that it's a database structure change, to be undertaken when possible, not one of the things we could in principle hash out & expect someone to just do one of these days. (I guess I'm just metooing here.) -- Dave (davecat) 21:56, 16 June 2009 (UTC)

Given the number of new types under discussion, it's probably wise to settle the ones that we think will work and which won't, and make one big change to the software to allow the ones we want. I think the mandatory database change is small - just add some more options to the enumerated types. (Unless people are expecting the introduction of such to magically change all current worked-around entries, and I don't think that's going to happen. People will have to fix things record by record.) What we will have to do is make sure the new types appear in all the right places on our current screens, or define where they should appear - e.g it should be fairly simple to include Non-Genre Shortfiction with Genre Shortfiction everywhere, but as the point is to clarify the difference it's probably wise to consider where such should appear. (IMO, somewhere near the bottom, but that could be at the bottom of Shortfiction or at the bottom of the page, and I guess there's always the possibility that Genre and Non-Genre Shortfiction end up in the same series.) BLongley 20:37, 18 June 2009 (UTC)

I have copied Bill's commetn to #Conclusion? above. I urge that people respond to it there, rather than here. -DES ^Talk 21:04, 18 June 2009 (UTC)

(unindent) It may be that we should be sure we have a consensus on the RoA before proceeding with this. See Rules and standards discussions‎#Nongenre shortfiction for current discussion on this point. -DES ^Talk 21:04, 18 June 2009 (UTC)

Excerpt

Just thought of this after looking at the "disambiguation" suffixes we use on Introduction and Afterword essays and such. Not all excerpts have the same title as the full work, e.g. Amazon Fragment (Excerpt from the first draft of Thendara House). An EXCERPT could be just another subtype of SHORTFICTION maybe (I tend to leave the Story-Length blank for such anyway, might as well use it for something useful) but I'm also thinking that if given its own type we could Link the EXCERPT to the title it's actually an excerpt of, same way as we link REVIEWs. Thoughts? (Flame away - I only thought of this 5 minutes ago and there's probably some big flaws I haven't thought of yet.) BLongley 18:32, 16 June 2009 (UTC)

The major objection I can see is that it might encourage more recording of routine promotional excerpts which I gather we have been tending to discourage of late. If we are going to record those, a special type or special length/sub-type might be a good idea. Not IMO as urgent as some of the other suggestions, but worth considering. -DES ^Talk 19:45, 16 June 2009 (UTC)

I'm not sure we have been discouraging them recently - in fact, I think people have been entering them more often now, if only to explain the differences in page-counts between various sources. I know that I always used to ignore promotional excerpts after the numbered pages ended, but found oddities worth recording, like an entire short-story being used as a promotional excerpt for a Collection, or a serialised story only (originally) available by buying several books in the Star Trek series (didn't matter too much which book you bought, so long as you bought ONE of the Star Trek titles in a particular month, you'd get that episode). Rare oddities, but worth consideration, even if it ends up in the "most of us don't really care" bucket. BLongley 21:09, 16 June 2009 (UTC)

I think Excerpt as a Short Fiction 'length' or subtype is a fine idea. (And I agree with Bill - I don't find them in old records, but I do find them in new records - Makes me think we are entering them more. Kevin 22:24, 16 June 2009 (UTC)

I think we have to choose one method or the other: if EXCERPT becomes a true content title-type it's not too difficult to introduce the linking to the parent title. (Just extend/reuse all the REVIEW coding. Well, once we've fixed that.) If it's just a new "length" for SHORTFICTION then it's probably a bit less coding, but we'd still have to overload the title occasionally and make people go hunt manually. And some people might want to know how big an excerpt it actually is. I don't think we've got a lot of excerpts that need attention, but as we're on the topic it's still worth thinking about. BLongley 20:22, 18 June 2009 (UTC)

Large Issues: Roles & "Based on"

There are two large issues that I for one would like to see at least some planning/design work on. In fact I regard them as rather more important than any of the title type issues discusses above, although probably involving more db structure changes. These are field support for additional "roles" and support for a more general "based on" relationship. Roles would also be highly useful, if not essential, to some of proposed the new types discussed above. -DES ^Talk 13:54, 16 June 2009 (UTC)

Roles

Roles have already been discussed a bit at ISFDB:Proposed Design Changes#Roles and elsewhere. My current view is that these should ideally be flexible, with different publications having different numbers of roles recorded. When editing there should be a "role" pulldown, with the option of also entering free-form text if possible, and a corresponding edit box to enter the name of the person filling the role. There would be an "add role" button which would add another pulldown/editbox pair to the form. On display the roles would be part of a publication's metadata, perhaps in the form of a bulleted list. -DES ^Talk 13:54, 16 June 2009 (UTC)

Roles could support capturing such information as translator, cover designer, book editor, editor of single-author collection, narrator for an audio book, series creator for sharecropped works, etc. If we implement an audio reading type, use of roles might be very important. -DES ^Talk 13:54, 16 June 2009 (UTC)

I think this needs to be broken down a little too. Some of the roles are publication level, some are title-level, some may be either or both. E.g. Cover Designer is almost certainly publication level. Collection Editors are probably title-level, but I've seen Silverberg and Clarke both credited as Editors of the Same Anthology in different countries, this might occur for Collections too. Translators and Readers may be at publication level or at pub-content title level: for a Novel it's probably Publication, but for Anthologies and Collections there may be different translators or readers for each content title. There's probably an overlap with Variants or "Based on" relationships to consider too. But there's evidence of oddities already planned for: e.g. BACK Cover Artist. BLongley 19:29, 16 June 2009 (UTC)

Some text moved to #Splitting Authors and Artists below -DES ^Talk 23:33, 17 June 2009 (UTC)

Still, again these are good suggestions and should be on the discussion list. BLongley 19:29, 16 June 2009 (UTC)

Good points. We may well need roles at both pub and title level, but I suspect that pub-level are more urgent and would wind up being more common. I agree with your examples. Translators should probably really be at edition-level, except that we don't have that. (I have seen multiple publications of each of several different translations of a given Verne work, for example.) But then the same could perhaps be said of cover artist. -DES ^Talk 19:55, 16 June 2009 (UTC)

Some text moved to #Splitting Authors and Artists below -DES ^Talk 23:33, 17 June 2009 (UTC)

[after editing conflict] I don't think authors (in our current use of the word which includes artists and editors) should be assigned roles, but that roles should be assigned to authors. There's a difference there. Let me explain. Robert Silverberg should have one record for all his credits. His relationship to the publication is defined by the role we assign him. The system automatically assigns him the role of editor when the pub type is ANTHOLOGY, as it assigns him the role of author when the pub type is NOVEL. If he were credited with an INTERIORART credit, we would assume him to be the artist, even though there is no such credit explicitly assigned by the system. I would suggest a entry form that allows a drop-down menu to assign pre-defined roles then allow the editor to add another credit (as it does now for cover art). That way we can assign as many roles to a publication as are necessary. The system will combine these credits into one "author" summary page, but only display the assigned role on the publication record. To bring up a recent example: Robert Conquest edited The Robert Sheckley Omnibus, but there is no credit on his summary page. Once role assignment has been implemented, it will. The question is: how will it be displayed? Perhaps under a newly created Book Editor category. Which begs another question: how will this is differentiated from books listed under Anthologies which at the moment assumes the author to be the book editor? MHHutchins 23:13, 17 June 2009 (UTC)

Collection editor perhaps? -DES ^Talk 23:39, 17 June 2009 (UTC)

Based on

My views on designing a "based on" relationship are at ISFDB:Proposed Design Changes#Based on, ISFDB talk:Proposed Design Changes#"Based on", and at Feature:90164. Such a feature could be combined with an improved handling of variant titles, or separate, leaving variants for cases where the text is more-or-less identical but the title and/or author credits are different. My preference would be for the second (separate) option, but either could do the job. -DES ^Talk 13:54, 16 June 2009 (UTC)

A one to one "based on" relationship with more flexibility should be fairly easy to implement. E.g. the current variants are simply based on a title having a title_parent. Add a "title_parent_type" column and you can specify the nature of the relationship - default this to the "current" or "usual" meaning of "variant" (whatever that is: same text with different title or author-pseudonym?) both for existing data (populate with default when we add the new column) and new entries (add the latter to the make variant title screens). Provide some tools on title-edits to change the link type on the variant title so we can correct/refine the existing relationships. Making the parent '0' to break the link should also still work (although making that more intuitive should also be a long-term goal.) BLongley 19:06, 16 June 2009 (UTC)

The one to many relationship (e.g. for fix-up novels based on several short stories) is more complex. Compare it with our problems with author pseudonyms: we can't currently undo such (although that feature is also requested). We do have a table for title_relationships at the moment, for reviews and interviews, which already seems to have some suggestion of a "translation of" relationship. But we haven't yet fixed the problems caused by pseudonymous reviewers or interviewers. (Well, I have, and have provided a fix script for existing data too, but the code fix is r2009-04 and the data fix is not necessarily going to be implemented on risk grounds). But that area is still a bit too "Here be Dragons" for my comfort. BLongley 19:06, 16 June 2009 (UTC)

Still, I think both parts are highly desirable, but probably should be split so that we novice ISFDB developers (and I only mean novice on ISFDB, I think most of us actually pretty experienced at development elsewhere) can go from small fixes to medium fixes to large fixes rather than jump from small to large. BLongley 19:06, 16 June 2009 (UTC)

Actually, a one to one could do the job, as long as it isn't exclusive. A work can be the parent of many variants now, each a separate "variant" relationship. Similarly, a work could be "based on" more than one other work, each a separate "based on" relationship, to handle fixups. The real problem is the other way, i think. Currently a title record that is a variant has exactly one parent, while more than one work may be based on a given work, there might be a condensed version, a later revised version, and still later it might be used in a fixup. (I can find such examples easily enough.)-DES ^Talk 20:12, 16 June 2009 (UTC)

I'm not sure what you mean by "one to one could do the job, as long as it isn't exclusive"? There's no problem with "A work can be the parent of many variants" , but there IS a big problem with a variant being the child of more than one parent. BLongley 20:40, 16 June 2009 (UTC)

I see your poijt, i was thinking as I wrote and was thinking only of the "parent" work i fear (although in the case of a "based on" relationship i think that our notion of "parent" and "child" may be reversed, or it may be sufficiently symmetrical that such designations don't make sense at all). My comment was premature.-DES ^Talk 21:12, 16 June 2009 (UTC)

In any case, however the code is done, I urge making the interface (and display) separate from, even if similar to, the current variant interface. This will allow for an enhanced fully-flexible version of based on later, after a simpler and more limited implementation earlier. I fully understand the need to take small steps, i was not calling for a full implementation of my vision next week. -DES ^Talk 20:12, 16 June 2009 (UTC)

I think clarifying the current "make variant" reasons will help us decide which are most needed in the long run. Let's do that, and see what people complain about. If somebody says "I can't make this a 'budget edition' variant of the main title!" we can point them at the price guidance, or if they complain about not being able to make it a "translation of" we can point them at the rules on how to enter foreign editions. Or change those rules, if needed. (We might end up with a better way to enter foreign titles, currently banned from variant rules unless it started as being not in English.) BLongley 20:40, 16 June 2009 (UTC)

The problem is, that implicitly makes the decision that a based-on relationship is a form of variant. -DES ^Talk 21:12, 16 June 2009 (UTC)

No, it will clarify that we already have variants here trying to show a "based-on" relationship. E.g. Belin's Hill (revised 2005). The first step would hopefully show up such anomalies: if the common understanding of variants is currently "same text, differently captioned" then the misuses we currently have should stand out a bit better, and be fixable, or inspire discussions of why "variant title" isn't the way to go in a particular situation, and encourage more effort into designing "based on (generic solution)". I suspect the current one-to-one relationships like this are most easily clarifiable this way, but showing up the faults and dealing with the results looks a useful small step. BLongley 22:12, 16 June 2009 (UTC)

Yes we do indeed have such variants now. Weather this is a misuse of the current mechanism might be debated -- i have argued in the past that it is, but others have disagreed. If the full "based on" relationship is implemented as i suggest, such variants will eventually be improper and, in time, corrected. I fear, however, that rather than encouraging "more effort into designing 'based on (generic solution)' " it would more firmly legitimize such variants ("See we already have variant text for that") and discourage a fully flexible "based on" or similar feature, and leave no good solution for recognizing fixups, split novels, and other relationships that a full "based on" solution can handle but a "variant text" feature cannot. -DES ^Talk 16:01, 17 June 2009 (UTC)

There is also the problem that "text variants" and "title variants" are at least potentially orthogonal, which IMO is another reason to have them be separate relationships. For example, a revised work may be published with an author credit other than our canonical name. To keep the author's biblio intact, a parent record must be created and the published work listed as a variant -- a "title variant". But if it is already a "text variant" of the original work, this would mean that it would be a variant of two parents, which the current mechanism does not support, and neither would the suggested "enhanced variant" ("text variant") mechanism, as I understand it. Similarly, if a work ABC (shortfiction) is expanded into ABC (novel), but the expanded version is later republished as DEF, an "enhanced variant" mechanism would require a variant chain, or a work that was a variant of two different parents.

These issues, as well as the display differences i discuss in my response to Kevin below, are why i think that implementing an "enhanced variant" now would be going down a blind alley -- at best it would require an almost total rework later, and at worst it would make it less likely that a full implementation would ever happen. -DES ^Talk 16:01, 17 June 2009 (UTC)

I'd say that that the biggest barrier to the full solution is trying to jump to that in one go. Big changes take a lot of time to develop, and a lot of testing, and get a lot of complaints in the meantime. Small changes, even if they may make things too "comfortable" in the short term, won't stop some people pushing for a further improvement. And we'd get those tested by everybody using it, not just volunteer testers with their own local ISFDB. I'm also not sure why you think an Author-name variation means "two parents", can you clarify that please? (It might be good to indicate titles that actually only exist due to the need for a "Canonical Author" version for the main Author page, but we'll also have to cope with the fact that such may eventually get used when people discover that say, Richard Bachman was Stephen King.) I don't consider such changes a blind alley, I consider them a useful experiment at worst. BLongley 20:07, 17 June 2009 (UTC)

As a professional developer myself, i do understand that insisting on a huge all-at-once change is often a recipe for getting noting at all done. I am not saying that I don't want any change less that a full implementation of my dream feature. Not at all. But I also know that making an early "easy change" sometimes tends to constrain future development because of the reluctance to 'pull it out and start over' and even more the accumulated data that might need to be reworked or even tossed to fit a new design. In short i am not saying don't take incremental steps, i am saying have at least a rough plan so that those steps are headed towards a desirable final goal. I strongly suspect that piggybacking a new "text varient" or "nature of the relationship" expansion of the existing variant code would tend to constrain future development in ways I think unwise. Suppose that instead, as an incremental step, a different mechanism, similar to an expanded variant feature,. but using a new db column were implemented. it might, as a first stage, still be limited to having all "child" records point to a single parent record, rather than being a many-to-many connection. It might start with an entry interface effectively cloned from the existing variant interface. But it would allow for orthogonal intersections of variant relationships and the new "related work" or "based on" relationship, and it would be possible to experiment with different means of displaying the new relationship without changing the display for existing variants. would that be a sufficiently small incremental change, in your view? -DES ^Talk 21:14, 17 June 2009 (UTC)

Let me clarify some of the plausible scenarios that make me thing there would be a collision if "text variant" is built on the existing variant system. I could probably find actual examples of all these, but inventing them will be easier.

1. a) J. Random Author writes (and publishes) "Spaceship!", a novella. b) Later he expands it into Spaceship!, a novel. c) Still later this is published under the title Spaceship to the Stars with an author credit for "J. R. Author". Now b is a text variant of a. c is also a text variant of a, but is a title variant of b. This means that c has two variant parents, or at the least is a variant of a variant. Not good (within the linmits of the current mechanism.
2. a) J. Random Author writes (and publishes) "Superbeing" a novella. b) He expands this into a novel, which is published as Hyperbeings under the name "J. R. Author". Hyperbeings is never published as by our canonical author name ("J. Random Author"). Hyperbeings is a text variant of "Superbeing". c) But to get Hyperbeings listed on JRA's canonical bibio pag, we must create a record for "Hyperbeings as by J. Random Author", and make the title record for Hyperbeings as a actually publiahed a variant of this. So b must be a child of both a and c in variant relationships, albeit with a different "nature" for each. If "text variant" just adds a "nature of relationship" column to the existing "variant" mechanism, this situation cannot be handled properly. While if "based on" is separate, even if it does not support many-to-many relationships yet (and thus cannot handle most fixups) it can handle these and many similar cases, because a work can have a parent in a variant relationship, and a different parent in a "limited based on" relationship.

In general, any time a derived work involves both text changes and title or author name changes, a variant+"nature of relationship" solution will not handle things well.

Also, i do thank that the display of "text variants" or "based on" works should be quite differetn from the display of "title variants". Our current variantes are pretty much never displayed separately -- only on the same line as or adjacent to the parent work in biblio or series displays. I think this is correct for title (or author) variants. But IMO text variantges should display in their own places on biblio or series pages: they may have different types (novel vs short story, say) or different publication dates, and should be found in the correct place. Can you imagine if 2001 could only be found in the shortfiction section as a variant of "The Sentinal"? But that is what a text variant system would do if the current display rules are retained. I suppose that an enhanced variant feature could change its display behavior depending on the relationship chosen. But I suspect that would create overly complex and fragile display code.

Having said all this, all i really ask is that the longer term goal, and some of these scenarios, be kept in mind when creating whatever interim solution is first implemented. Creating a change that will need to be pretty much ripped out for the next step is perhaps not a step foreward, so please plan not doing that. That is all I really ask. -DES ^Talk 21:14, 17 June 2009 (UTC)

I very munch want to reserve the current variant mechanism for cases where the two works are identical in content (not counting trivial corrections of typos and such). Once we start down that path, i fear that the clear distinction between records that are for the same text, differently captioned (meaning different title or author credit or both) and records that are for different but related texts, will be lost or at least blurred. Also i strongly feel that title records for "different but related" texts should not be hidden on author pages, as now happens when an expanded version is marked as a variant. I suppose the display code could do that only if the variant reason is "altered title" or "author credit" or whatever, but not when the reason is "expansion" or "revised version" or whatever. But i really do want any changes to be made with an eye to making that distinction quite clear, and i fear the easy-to-code method you discuss with have the unintended consequence of foreclosing such a clear distinction. If that can be avoided, i have no problems with an incremental approach. -DES ^Talk 21:12, 16 June 2009 (UTC)

I don't think the first step I proposed will hide anything, it should make it clearer which current variants are inappropriate. Yes, that may make some things look worse in the meantime, but it doesn't actually change anything that we already have. BLongley 22:12, 16 June 2009 (UTC)

It won't hide the existing variants, no. Indeed in the short term it will make things better, by making it clearer which existing variants are "title variants" and which are "text variants". What i fear it will do is make things just enough better to reduce the pressure for a more comprehensive solution, and leave more data to be changed in more complex ways if that solution is ever implemented. I also fear that by conditioning ISFDB editors to think of revised, expanded, condensed, etc works as "text variants" the differences between these and "title variants" and the similarities between these and fixups, split and rejoined novels, and other things that could fall under a general "based on" relationship will be obscured, making the implementation of such a general relationship less likely. -DES ^Talk 16:01, 17 June 2009 (UTC)

Of course it is tempting to combine this with the existing variant mechanism, and it could be done much as you suggest above. But I fear that if we ever went to a more full-featured version of "based on" it would result an an over-complex interface to handle all the possibilities. I fear it would also lead to confusion between several concepts: variants that may never have existed but which we record to get all publications listed under the canonical author and canonical title; variants that had a different title or author credit, but essentially identical text; and versions or related works with significantly different text. Note that a variant is not listed separately on an author's biblio page, and is not even noticed by "dup candidates" (although that might change), while a "based on" work should, IMO be listed separately because it is a different work, not just a different name for (description of) the same work. That difference in display behavior may suggest different database storage, but that is up to the developers. -DES ^Talk 20:12, 16 June 2009 (UTC)

This is why I'm suggesting small steps, and pointing out possible overlap problems. I've actually introduced a slight change to displays of variant titles recently (I'll let people find it for themselves - it's what some people have been asking for, but I think it'll help if people compare all the displays and decide which is best, or whether we should work on allowing people to choose which style). But we have no overall designer now, and I'm trying to be cautious. BLongley 20:40, 16 June 2009 (UTC)

I wish you would explicitly point it out to me -- on my talk page if you don't want to alert others -- so that I can look for examples and see what I think. -DES ^Talk 21:12, 16 June 2009 (UTC)

I don't think I'm revealing too much if I suggest you look at a Series, and how the Series displays on Author pages. I know there's been complaints about the "As by" making titles look as if they've only been published under that author name when it's been published by canonical author and pseudonym. But there's a lot of differences in displays, and I'm not going to make it obvious which I've introduced: they're all valid options. BLongley 22:12, 16 June 2009 (UTC)

Well, all recent software changes have been posted on the Development page, so presumably Bill is talking about the addition of VTs to the Series page (listed as "Subset of Feature 2804561".) My guess is that Bill is referring to the fact that his new logic always displays a VT on a separate line while the Summary page displays VTs on the same line using the "[as by Robert Heinlein]" format (in most cases). I noticed this difference in behavior during my testing and let it slide since this was a "quick and dirty fix" and we have to do a more generic rewrite to get the logic behind the two pages reconciled anyway.

Having said that, I am afraid that your comments above were very hard to decipher, Bill. Even though I tested the change and created a new Feature request for a more comprehensive solution just ten days earlier, it took me 20 minutes to figure out what your were talking about. Any editors who were not familiar with this change were in an even worse position. With the number of things going on and the number of proposed changes (in this section alone!), any non-specific suggestions "[to] compare all the displays" will likely be given a brief frown and then ignored. Ahasuerus 03:34, 17 June 2009 (UTC)

Being "hard to decipher" was exactly the intention. Making you spend 20 minutes on it was not. Sorry for that. :-( I gave pointers so that if people are really interested they can go look at that area with unbiased views. If it looks too hard, don't bother. If nobody bothers, I'll "compare all the displays" myself and put up some proposals later, but it'll be like Kev's Menu change proposals - lots of screenshots and lots of explanation needed, and I'm not up to that much work till the weekend at least. And there are plenty of other things to look at in the meantime, so that may be several weekends away. It's low priority stuff and I really only wanted people severely interested to look at it. BLongley 20:29, 17 June 2009 (UTC)

Frankly i find comments like "I'll let people find it for themselves" and "I don't think I'm revealing too much if I suggest you look at a Series" frustrating. I find even the listings under "outstanding changes" a bit terse. When a new patch/release is installed, or a recently revised feature is discussed, as one was here, I would like a clear explanation of what has been changed so that I can go into the DB and find (or create test) examples, and see how they work and if I like them. I understand that repeating all the details in the "outstanding changes" table might take too much room, but a link to the sourceforge item would be helpful, and a comment there or somewhere linked explaining how a change was implemented when this might not be obvious from the bug or feature listing. An added comment in the SF item would do, i should think. -DES ^Talk 16:01, 17 June 2009 (UTC)

Sorry for the frustration - the intention was that people would either be immediately interested or not. (Explained above.) BLongley 20:45, 17 June 2009 (UTC)

As to the listings on "outstanding changes": well, I'm open to suggestions. Make them too big and people are scared away. Make them a link to a different site like Sourceforge and people are scared away. Duplicate stuff here and on Sourceforge and people will only read one or the other. And even if the request/bug is standardised, we'll probably only get discussions on proposed fixes in one place or the other. :-( (Yes, it's a mess.) BLongley 20:45, 17 June 2009 (UTC)

The After installation messages aren't something I do, you'd have to take those up with Ahasuerus. But if we can put all the bug/feature reports, proposed fixes/enhancements to such, and discussions of such, in one place, we'd give him one thing to link to. Which would probably be a major help, as we're overworking him at present! BLongley 20:45, 17 June 2009 (UTC)

I can see that small steps are needed -- I am NOT urging that we rush into major change, and I'm sorry if it sounds as if i was. I quite agree that possible overlap and interaction issues must be considered. I am not dismissing your issues. Do you see the distinction i am trying to make by suggesting that "based on" not piggy-back off variants, or at least not appear to to the user? Perhaps there is a better way to make this distinction very clear while using the existing code and taking an incremental approach. -DES ^Talk 21:12, 16 June 2009 (UTC)

Having reviewed all this above and links, it seems that 'Based on' for text changes is "Variant Text" in sheeps clothing. While we currently have a single 'Variant' that is intended for 'Variant Title' and is also used for 'Variant Author'. If it's going to look like a variant on the authors biblio page, and the page to create it is going to replace the make variant page, then I'm afraid it a Duck, err "Variant Text". The 'fixup' problem can also be solved by having code that causes a 'Variant Text' relationship to appear many times on the Authors biblio page. The Novel appears first, and then where each Short Work appears, have the 'Variant Text' line appear. Why re-invent the wagon when we already have a horse and a yoke? Variant can be expanded to 'Variant Title', 'Variant Author', 'Variant Text', 'Variant Form' Perhaps for Audio Books?, 'Variant Language' (For translations). We could even be so bold as to split 'Variant Text' into 'Variant Text (minor)', Variant Text 'Expansion', Variant Text 'Abridgment', Variant Text Fixup, and illuminate all the (pardon the pun), Various Variants. Kevin 03:54, 17 June 2009 (UTC)

Part of my point is that, if I were designing it, "based on" would NOT look like the current variant on biblio pages. On a biblio page a variant appears on the same line (or I gather in a series display on an adjacent line) with the parent text. It does not appear in its own place in the biblio page, neither its alphabetical place in an alpha display, nor its chronological place on a summary display. In a title record display of the parent, all publications under a variant are displayed together with those under the parent record, and indeed it is not always obvious which are under the variant, particularly if it is an author variant. Whereas in my vision "based on" would work more like our current review display. A work that is "based on" another work would display in its own place in all biblio and series displays, it might be in a different series from the work on which it is based, it would have its own date, and would be in all ways a separate work. Indeed it might well have variant titles. At the title level, there would be a line with a link, something like "Based on: XYZ Work by ABC Author and QRS Work by DEF Author" where the underlines represent links. There might be some indication of this at the biblio level, but quite possibly not. And at the title record level of the corresponding work there would be line reading something like "Based on this work: GHI Work by ABC Author; LMN Work by ABC Author; XXY Work by ABC Author and DEF Author".

Also i don't think the page to create a based on relationship should replace the make variant page, precisely because the restrictions that should apply are different. Make variant can (and should be able to) create a new parent; make based on should not be able to. All variants should be children of a parent that is not itself a variant (although the code does not now enforce this), this is not true for "based on". A variant should be of the same type (Novel, shortfiction, Nonfiction, etc) as its parent (although the code does not now enforce this); this is not true for "based on". A variant can be a variant of at most one title (both in the current code and in my vision of the ideal code), whereas a work may be based on many other works, and still have others based on it.

In my view thinking of "based on" as an expansion of variant tends to obscure these differences, and risks leading to a design that locks in the pattern of the cur3ent variant feature, and may preclude or at least make harder an implementation of a full-featured "based on" feature. -DES ^Talk 14:12, 17 June 2009 (UTC)

I agree with DES here. Variant text (whether "based on this", "expanded from that", "revised from this", "made up of these") should have its own identity away from variant title. Users, editors, moderators should all see this distinction clear enough in their heads (and on the screen) not to confuse the two. Having a different entry interface and data display would bolster this distinction. Because a work can be revised several times or become part of several fix-ups (van Vogt from the beyond is nodding) it can't be handled like a variant in title or author, and the display should reflect that. I have no idea how this could be done, perhaps on the title record page, if not on the author's summary page. Ideally, a title might appear in different categories on an author's summary page. I don't see why a short fiction title in a series can't also be displayed under the short fiction category as well. A database user might not know a certain story is in a series and go toward the short fiction list and not find it. I'm going off on a tangent here. This is a display issue and should probably be discussed under a different topic. MHHutchins 15:54, 17 June 2009 (UTC)

Thank you for explaining it again and in greater detail. I see what you are talking about, and agree that what you are picturing is different from our current variant linking. I'm gonna let this one percolate for a few days. Kevin 00:39, 18 June 2009 (UTC)

Link Reviews to Titles or to Publications?

There have been a few discussions of Review linking over the last year. Some editors like the fact that we currently link Reviews to Titles while other editors would prefer them linked to individual Publications. I think the fact that the Title page currently lists all reviews for the displayed Title is very valuable and we will want to preserve this functionality regardless of what else we do, but I can see value in identifying the Publication being reviewed as well.

Unfortunately, the relationship between the Title and the Publication in question is not always one-to-one since you can review only one (or two-three) Titles in a Publication. This means that we if decide to capture the Publication record that is being reviewed, we also need to capture the reviewed Title separately, which will be quite awkward. However, since in 90%+ of all cases "one reviewed Pub = one reviewed Title", we may be able to come up with a clever way to automatically link them. We'll have to think about it.

On the display side, a review line in a Publication currently has the following components:

1. Review: - hyperlinks to the Review record
2. Title - hyperlinks to the Title record
3. by Author(s) - hyperlinks to the author(s) of the reviewed Title
4. book review by Reviewer - hyperlinks to the author of the Review Title

I guess we could add components 3a and 3b to the list above, which would read "in Publication by Author", but that would make the page look very busy. Alternatively, we could replace the currently displayed Title with the reviewed Publication, but that wouldn't work too well when the review covers just one Title in a Publication. Hm, clearly this needs more work... Ahasuerus 17:16, 16 June 2009 (UTC)

Well, as swfritter pointed out, the main argument for linking to publication is for magazines and fanzines, due to the merging of EDITOR records. BLongley 18:09, 16 June 2009 (UTC)

For books, the 'review' is usually of one publication, but may specifically refer to a couple of different bindings for instance. And the review will also actually apply to all reprintings of those, until there's a new 'edition' of noteworthy change. If we get printing numbers sorted out that will help group things into this nebulous idea of 'edition', but it won't help unless we also sort out relationships between hc, tp, pb, ebook and audio versions of that edition. (At which point we might want to reconsider whether "Abridged' audio books are actually a separate edition or even title. I think they probably should be, but I'm in no hurry to rework them all, although I have tried to leave notes when I know whether it's Unabridged or Abridged.) BLongley 18:09, 16 June 2009 (UTC)

Still, I think most book reviews are of one title - e.g. I rarely see one part of an Omnibus reviewed, unless it's been entered in the magazine with separate reviews for each part rather than of the 'Omnibus' title. However, there are publications that have reviews of Shortfiction: in fact, most Magazine, Anthology and Collection reviews I read go story-by-story and don't always review all the contents. Yes, an overall opinion of the quality of the containing work is given, but really, some content titles have not been reviewed. I'm sure this is a level of detail somebody will want sometime, so might be worth considering at this point. In the meantime, I think most of our workarounds are good enough for most purposes. BLongley 18:09, 16 June 2009 (UTC)

The entries I made of James Blish's reviews in The Issue at Hand and of Damon Knight's reviews in In Search of Wonder, and still more the reviews i have yet to enter in those pubs, are largely of short fiction, and those are some of the most significant collections of critical writing on SF to date, IMO. I linked tose to the appropriate shortfiction title records, and that seems to work reasonably well, although it means more entries than a single review record for a collection or anthology would. I have seen reviews that clearly are of a particular publication, but that is rare. What is more common is a review is written shortly after a work is first published, then a revised or expanded form of the work is published, and the initial review really must be noted as being of the earlier version only. (Dates will often make this clear if a reader is alert, but can be easily overlooked.) But in such a case it is probably best if we have a separate title record, perhaps a variant, for the revised or expanded work anyway, and reviews of that version can and should IMO link to that record. Overall, I don't seem many cases when a link to a pub or editor record, rather than to a title record, would be needed. There might be some, however. -DES ^Talk 19:36, 16 June 2009 (UTC)

Novels That Were Split for Subsequent Publication

We don't have a good way of recording Novels which originally appeared in one fat volume and were later split into 2+ volumes when reprinted in paperback or perhaps in another country. We typically turn enter the latter as VTs of the original novel, but it can be misleading since it suggests that the book has been reprinted multiple times rather than in multiple parts. The situation gets particularly messy when dealing with foreign language translations, which don't even have a separate Novel Title, so we are forced to stuff them under the original Title or some such.

At one point I wondered if introducing a "Split Novel" (?) sub-type for Novels might help, but now I am thinking that we could use the "Based On/Relationship" mechanism (if and when it's implemented.) Ahasuerus 23:23, 16 June 2009 (UTC)

I think so. A split novel is in a sense just the chronological reverse of a fixup. And then there are novels like Cyteen which was split and then unsplit again, so to speak. But this would require the full many-to-many based on, also able to handle fixups, i think. -DES ^Talk 23:42, 16 June 2009 (UTC)

I often find the reverse in older novels from the 1800's. First publication in 2 to N volumes, and modern publication in novel form. Kevin 00:52, 17 June 2009 (UTC)

It's not just novels. See The Early Asimov published in one, two or three volumes. Not too bad to solve with "Based On", as there is a single volume that could be a parent of a one-to-many relationship. But I suspect there are probably two-volume sets republished as three or four but never as one, which would require the full "many-to-many" solution DES mentions. BLongley 19:25, 17 June 2009 (UTC)

And I see from the above, and from The Best of Isaac Asimov, The Best of Isaac Asimov 1939-1952, and The Best of Isaac Asimov 1954-1972, that we're currently not always using VTs for a workaround. Given that this looks like a big change to fix them all, should we be standardising the workaround for now? BLongley 19:25, 17 June 2009 (UTC)

Books/Essays about individuals

We have all kinds of records and conventions to support Title level information, including Title level Reviews displayed on Title pages, but at this time the only type of supported records about Authors is Interviews. We also have hundreds of Essays and Nonfiction books about Authors, but unless they are Interviews, there is no way to access them from that Author's Summary page. In other words, if a user wants to see a list of all books and articles about Heinlein, he is out of luck even though the information may be in the database.

We may want to consider adding this functionality -- call it "Author Level Reviews"? -- to the database. I don't think it will be that difficult to do from the technical perspective since we already support Interviews, which are quite similar structurally. Interviews also support multiple authors (both interviewers and interviewees), which we can use as a template for this feature. The only catch I can think of is Essays/books that have non-Author specific contents in addition to one or more Author Level Reviews, but we could use the same rules that we use for regular Essays and Reviews. Ahasuerus 17:04, 20 June 2009 (UTC)

I mentioned a similar idea near the (current) end of the discussion in Rules and standards discussions#Entering Reviews of items that are not 'Books' or 'Magazines' (and I am sure I saw someone else discuss it earlier, but I don't recall where). There I called the relationship "subject" and I would extend it to books or essays that are about, but are not reviews of, a work of SF. In particular book-length critical studies or critical essays that are not really "reviews" could be linked with the works they discuss, as well as biographies and works such as Heinlein in Dimension could be linked with the authors they are about. This might also be a way to link critical essays that also serve as story intros to the stories that they are about, when the title does not obviously do so (as it sometimes does not) and the link biographical/memorial essays sometimes found in a collection to the author they discuss.

I like the idea. I would not like to call it "author reviews" however, because a "review" suggests evaluating something, which many of these do not really do. I can't think of a better term than "subject" as in "Robert A. Heinlein is the subject of Heinlein in Dimension or "The Lord of the Rings is a subject (one of several) of The Road to Middle-Earth". -DES ^Talk 17:46, 20 June 2009 (UTC)

For completeness' sake I should mention that "tags" could be used to tag all books/articles about Heinlein "heinlein", all books about LOTR "Lord of the Rings", etc, but this information wouldn't be accessible from the Summary page and you would have to do a Tag Search to find it, so the added functionality would be quite limited. Ahasuerus 17:57, 20 June 2009 (UTC)

And since no editor can edit another's tags it would be fragile. There would also be no link to the subject author or work. For Heinlein that is not a major issue, perhaps, but for a less well known author, or one with a less unique name, this might reduce the value significantly. (Is a work tagged "Smith" about George O, Thorne, George R., or Valentine Michael?) -DES ^Talk 18:12, 20 June 2009 (UTC)

True enough. I think the definition of the term "review" could be stretched a bit to accommodate some borderline cases, but there may be more extreme cases where it would not be appropriate. Something to keep in mind as we ponder this area. Ahasuerus 02:27, 21 June 2009 (UTC)

I don't think a book-length critical study or biography can usefully be called a "review" and no one much speaks of a review of a person, even when a brief article, comparable in length to a standard book review, is about that person. -DES ^Talk 02:33, 21 June 2009 (UTC)

Yup, that's exactly what I meant by "more extreme cases" :-) Ahasuerus 02:49, 21 June 2009 (UTC)

I understand the complexity of the request may put it closer to the horizon than the near term, but I can see a 'Linking Essay', and a 'Linking Nonfiction' title type eventually. It could have an Author as a required data field, and a title as an optional data field. I would support such an expansion once we get some higher priority medium and largish code changes under out belts. (I think this would be the largest / most complex change discussed to date). I also imagine now that the idea is in my head, I will see a need for it more frequently than I expect. Kevin 03:45, 21 June 2009 (UTC)

I don't see the need for a separate type. I think of this as a new property that can be applied to any existing type, and can thus be added to existing records without the need to re-enter or convert them. Indeed I see this as being very similar to the "based on" concept, and it could perhaps reuse some code from that feature. Like "based on" the link would probably be at the title level, not the publication level.

Note that a given item might have more than one subject. A non-fiction book might discuss the work of several authors in detail, and each would be a "subject" of the book. Or a book might discuss several specific works, and each would be a subject.

Note that when a work deals primarily with a single work, it should probably have as its "subject" the work and not the author, although it could have both. It would be rare for a work of fiction to have a subject link, but something like Rocket to the Morgue where characters are acknowledged portrayals of actual SF authors might qualify. But I could see this being available only for non-fiction and essay titles. -DES ^Talk 05:19, 21 June 2009 (UTC)

Do you see this 'subject' property being applied to all introductions and afterwords (linking them to the title being opened or closed)? Could it also be applied to Interior and Cover art (Cover art especially, as it often has a subject, 'beyond' the magazine / Anthology / Collection it illustrates.) The tough part is imagining a single data field accepting both TITLE and AUTHOR as valid 'subject's Kevin 06:24, 21 June 2009 (UTC)

It could be so applied; whether it would be worth the coding and data entry effort to so apply it is a different matter. Most introductions and afterwords seem to be clearly enough linked to the associated works now that I doubt there would be enough practical gain to be worth introducing such links. Cover art often illustrates a particular story in a magazine, collection, or anthology, a fact we are currently not capturing in most instances. It would be possible to use such "subject" links to indicate this. Whether it would be worthwhile to do so is something we would need to discuss. There would also be the question of how and where such info would be displayed if we did capture it.

As to the matter of having two different kinds of targets: it might be necessary to have to different varieties of subject links, or to have an indication in each link as to the type of target it is for. I envision a pull-down with two choices, say "Person" and "Title". Or record numbers might be entered with a preceding letter: "P1145" or "A2278". Or some other method might be used. But this is an implementation/detailed design choice, which need not be made at this point. -DES ^Talk 14:53, 21 June 2009 (UTC)

Patch r2009-03

Patch r2009-03 has been tested and is ready to be installed on the live server on Sunday. The following changes will be implemented:

• Bug 2796509. URLs not linked correctly in the post-approval screen.
• Feature 2800631. (was Feature:90126 here) Links to Submitter and Holder's talk pages
• Feature 1969512. Image Preview on Pub updates
• Feature 2800669. (Part of Feature 90147 here) Make getting from Pub Delete Submission to Pub easier
• Feature 2800680. (Was Feature 90110 here) Have the HOLD screen link to new-submissions
• Feature 2801298. (Was Feature 90109 here) Add Links to child VTs
• Feature 2800716. Add parent series to series display.
• Feature 2804561. (partial implementation). Add variant titles to series display
• Feature 2802553. Link to view pub after verify
• Bug 2802728. 8888/9999 still appearing in Series and Diff Publications
• Bug 2802844. Do not display "Other Sites" nav section for non-ISBNs
• Features 2802730 and 2799105. Provide link to ISFDB Hosted Image Wiki Page & Provide updated Cover Art Supplied by Links

Please report any issues with the patch here. Also, please note that the way Talk pages are linked on the main Moderator screen is experimental and may be changed based on moderator feedback. Ahasuerus 04:13, 14 June 2009 (UTC)

Patch installed, test away! Ahasuerus 16:43, 14 June 2009 (UTC)

Well, it looks to have installed correctly to me. I'd forgotten how subtle some of the changes are. Liking the series changes, but I see Mike is working on some of the Dray Prescot, which should be a real test! BLongley 22:00, 14 June 2009 (UTC)

Man I LOVE those variant links! Kevin 03:25, 15 June 2009 (UTC)

After being away for three days, and looking at the list of projects planned above, my mind is in a whirl, trying to take it all in. (Starting Saturday I'll be gone for a week, so I can't imagine how different things will be by the end of the month!) Is there one page where all of the changes can be highlighted, written out in English without resorting to the numbers (as in the listing beginning this topic), and explaining the changes to poor non-technie souls like me? Thanks. MHHutchins 20:46, 15 June 2009 (UTC)

Fear not, Michael, it's not nearly as bad as it looks! (Well, OK, perhaps editing the Community Portal page 92 times in one day was a bit excessive :-) The bug/feature numbers listed above refer to their descriptions on Sourceforge (bugs, features). The discussion above mostly covers big ticket items like increasing the number of supported Title Types (Novel, Essay, Editor, etc), which are not likely to be implemented overnight. Now that we have proved that we can make small changes successfully, we are trying to figure out what kinds of major changes we want to implement down the road so that (a) we could prioritize them and (b) avoid collisions and conceptual mismatches. We wouldn't want developers improving an area of the application which will be completely replaced 3 patches later :) Ahasuerus 00:53, 16 June 2009 (UTC)

Michael, don't worry about coming back to find the whole ISFDB changed beyond comprehension! Most of the actual changes lined up are still pretty small, and I'm trying to get us to go for "medium" next. And suggesting steps toward major changes. But it's good to share our dreams while there's still some enthusiasm. (Which will probably drop as soon as we introduce something the developers and testers liked that everybody else doesn't like.) I see the comment "the way Talk pages are linked on the main Moderator screen is experimental" hasn't invited a "hate that, remove it at once!" yet though, so some of us seem to be a bit more nervous than we ought to be. Just keep us in check - if we didn't break something in r2009-03, we might in r2009-04. So point out problems as soon as you see them. BLongley 22:29, 16 June 2009 (UTC)

In fact, I like it and want the same link on the approval screen, indeed I think i would be more likely to use it there than anywhere. -DES ^Talk 22:50, 16 June 2009 (UTC)

Linking to Talk pages is definitely useful, but displaying two links per table column means that the text now wraps (at least on some screens) in cases when it used not to. Perhaps we could eliminate the link to the User page if the Talk page link is sufficient? Ahasuerus 23:30, 16 June 2009 (UTC)

Looking at it again now it's live, losing the outer set of brackets for the "(Holder ((Talk))" might look better and would save two characters. (I know, I'm criticising my own code changes, I can wear two hats.) BLongley 19:08, 17 June 2009 (UTC)

That would be fine with me. But the link would need to have the userID as the link text, to identify the submitter. One moment though: a red-link on the userID often indicates a relative newcomer, so it has some value. On the approval screen the name is on its own line, so having both links shouldn't present a problem, IMO. -DES ^Talk 23:38, 16 June 2009 (UTC)

Should be simple enough. Is there a feature request number for that? BLongley 19:08, 17 June 2009 (UTC)

FR# 2807731 (Link to submitter's talk page from approval screen). Thanks. -DES ^Talk 19:37, 17 June 2009 (UTC)

I did a test and it does cause a couple columns to wrap at 800x600 and 1024x768. That said, I think at 4% to 8% we can stop coding for 800x600 as a general practice and 1024 screenwidth is pretty much on the way out. I wouldn't argue against coding for an assumed screen width of 1280 from 1280x1024, the next general size up from 1024, and still hit ~50% of everyone and growing. Kevin 00:49, 17 June 2009 (UTC)

Well, I for one use 800x600, Kevin. Too much eyestrain at 1024x768. (There are a couple of web sites I have to switch for because screens don't scroll to where I can click on needed links, & it's a real PITA.) -- Dave (davecat) 12:13, 19 June 2009 (UTC)

I haven't really been considering screen widths exactly, but try not to widen unnecessarily. I think there was a feature request to show a bit more of the subject (it's truncated at 40 characters at the moment) and some guidelines would be good for what people can cope with. (Which does bring in the question of whether the mod screens can have different limits to the others - part of me says "don't be elitist", but practically, it might be worth checking what works best for each type of user.) BLongley 19:08, 17 June 2009 (UTC)

And before we assume a minimum size based on our desktop/laptop displays, is there any sign of people using the site via iPhones or Googlephones or other Smartphones? We might have to consider smaller displays. (I'm willing to test such, if somebody feels like donating such a mobile and paying the data charges!) BLongley 19:08, 17 June 2009 (UTC)

I'm happy to consider smaller screens for 'users' of the database, but Editors, and Moderators? Not really. I personally use the database from my phone several times a year when I'm on a book buying tear, or digging through stacks sometimes. My only complaint from a 'user' perspective is that the ISFDB Index card icon, keeps the menu frame from shrinking, causing all the biblio stuff to roll horrendously as that frame can be shrunk. This could be fixed by putting a 240 pix wide blank gif at the top of the biblio frame in display, which will prevent the biblio frame from attempting to collapse beyond that point. That will be sufficient to allow a cell phone user to put that frame center screen and make maximum use of the database and limited screen real estate 'on the go'. Kevin 00:45, 18 June 2009 (UTC)

As a self-confessed "phone user" of the database, you get to enter the feature request :) Ahasuerus 01:12, 18 June 2009 (UTC)

Splitting Authors and Artists

This section split out of #Roles above, due to topic drift. -DES ^Talk 23:32, 17 June 2009 (UTC) One thing I would like people to consider is whether we should be separating "Authors" from "Artists" and all the other roles. I do find myself annoyed when looking for an artist that may match a signature, or an author that may be a pseudonym, and get either type of search cluttered with the other type. I think this may only get worse when we add Collection Editors and Translators and Readers and Designers and Photographers, etc. (In fact, I know they were already making things worse, I've spent a lot of time demoting "stray authors" to pub notes in the meantime.) BLongley 19:29, 16 June 2009 (UTC)

As to separating Artists from Authors, that has been raised before, but should be discussed. I haven't found it a major problem, and we would need to handle the cases where an individual is both. Not the most common case, but far from unheard of, and includes some very well-known individuals. (This may be more common with self-published work where the author also does the cover.) Hmm... What if we add a flag, or rather a set of flags, for "author", "artist", "editor" and the like, to each "person" record. Then a search could restrict to only records with the "artist" flag set, or be done for all "people" as the user might prefer. Just a thought. -DES ^Talk 19:55, 16 June 2009 (UTC)

There are indeed multi-talented "Authors" here and if we do split I think we have to start with assuming that they are the same person: e.g Terry Pratchett, Clive Barker and Robert Rankin certainly are both writers and artists. But Mel Odom and Mel Odom (artist) (not sure why I can't link to that one) aren't, as far as I know, and keep getting confused, hence the desire to split them without the need for suffixes. BLongley 20:57, 16 June 2009 (UTC)

{{A}} has a problem with "author" names that include parens, or some other non-alphanumeric characters. In those (fairly rare, I hope) cases you need to link like this: {{A|Mel Odom (artist)|altName=Mel_Odom_(artist)}} gives Mel Odom (artist). See Template:A/doc#Special case for more detail.

I see you point about possible confusion. But there are certainly cases of two or more authors with the same name, so such a split would at best reduce, not eliminate, the need for disambiguation. (It might also require changes to the isfdb name template on Wikipedia, which has been used to link artists as well as authors to their ISFDB pages.) And what would we do if Mel Odom (artist) decided to write and publish a book? Still a split would have some advantages. -DES ^Talk 21:25, 16 June 2009 (UTC)

Other examples of people with both art and writing credit here:

• William Pene du Bois
• Mervyn Peake
• J. R. R. Tolkien
• Richard Powers
• Tim Kirk
• Wendy Froud
• Terri Windling
• Jack Davis
• Katherine Coville
• Cat Sparks
• Mark Wheatley
• James Warhola
• Virgil Finlay
• P. C. Hodgell
• Yoshitaka Amano
• Laura J. Underwood
• Quentin Blake
• Dave McKean
• Barbara Kiwak
• Bob Eggleton
• Jason Van Hollander
• Richard Pini
• Wendy Pini

And all those (except for the first 3 and last 2 who were off my head) were derived from a single page of advanced search (looking for cover art on titles with "Tale"), and i ignored artists with only non-fiction and essay credits. If that search was representative, at least 15% of cover artists here have at least one fiction credit here also. -DES ^Talk 22:01, 16 June 2009 (UTC)

A quick scan says we have (of the last backup I've loaded) 55K different title authors, of which 12k have COVERART or INTERIORART. So even if a sixth of the artists have fiction as well, we can probably move 10K "Authors" to pure "Artist". Given the current worries about some search performances, there may be some noticeable performance benefits from such. A small improvement in searches for Fiction authors probably, but a big improvement in Cover or Interior artist searches. BLongley 18:44, 17 June 2009 (UTC)

Interesting. But if 10k authors are moved to an "artist" table, and 2k stay in the main "author" table, wuldn't a search for a cover artist have to check both tables, as there would be no way to know if a given artist was in the 20k or the 2k? Wouldn't that actually hurt performance? or am i missing something? Also, would a "pure artist" be moved back to the author table when/if s/he publishes a work of fiction (SF that is)? How would that work. I am not trying to pick holes for the sake of being contrary; I just see complications. I agree that the large majority of our authors have no publications of art in the db, and that a fair majority of our artists have no fiction pubs, and we ought to be able to take advantage of that fact. But I don't quite see how without making lots of problems in the minority cases. -DES ^Talk 19:21, 17 June 2009 (UTC)

2K authors would be in both, with some sort of link. If you're only searching for artwork, you'd look at the Artists table and look at 12K Artists. If you're looking for fiction or essays, you'd look at 45k Authors. 55K to 45K is a small improvement on Author searches, searching 12K Artists is far better than searching 55K "Authors" for Artists than now though. BLongley 23:05, 17 June 2009 (UTC)

End section split out of #Roles above -DES ^Talk 23:32, 17 June 2009 (UTC)

That makes sense, the only renaming problem is making sure that the link stays intact and that data is propagated to the other table as needed. Oh and copying a person from one table to the other as credits are added that require such. Doesn't look impossible at all, whether it is worth the effort i can't say. No futher objections form me. -DES ^Talk 23:37, 17 June 2009 (UTC)

Table? What? Copying? Why? What happened to DES's excellent suggestion of just flagging authors based on Roles? Then tailor the advanced search to limit Artist searches to Artist flagged 'Names', etc for all roles. You only need one Table, but it should/could be indexed against the flags. (Or am I confused as to the suggestion?) Kevin 00:30, 18 June 2009 (UTC)

I guess I forgot my own suggestion. That would surely be simpler to implement than a multi-table solution with non-normalized data. What the performance effect would be I can't say, but it might be worth trying. Whether it could also be used in basic searches (add an author and an artist search to "name" perhaps) I'm not sure -- not until it was stable anyway. -DES ^Talk 00:34, 18 June 2009 (UTC)

Seriously, folks, what's this nonsense about splitting artists from authors? What would be the purpose? What would be the benefits? Are we to expect an individual's efforts to be split into two summary pages? How many author/artists pages would benefit by splitting their work? Aren't the categories on the summary page sufficient to explain their roles for each publication? The whole business is a nonstarter for me. MHHutchins 04:39, 18 June 2009 (UTC)

Purpose: faster searches. Getting some of the broken Advanced Searches enabled (I believe the changes are mostly held up because of performance worries). It shouldn't affect any current displays, unless we want them to be affected. BLongley 18:57, 18 June 2009 (UTC)

If I understand DES' idea correctly, he is considering adding an extra flag to each author record which would tell the search engine whether the Author is responsible for art as well as for fiction. It wouldn't be that difficult to implement, but it seems to be more of a performance optimization issue rather than a design change that would affect our users. Adding "roles" that would support translators, editors of single author collections, etc would be much more consequential. Ahasuerus 04:47, 18 June 2009 (UTC)

Yes. This wasn't my idea initally and i wouldn't press for it to be a high priority -- it was Bill's idea. The objectives are two: to speed up searches, and to allow searches for an artist not to return similarly named authors who are not artists, so that the search results are more useful when it is known that an artist is being searched for (and, i suppsoe the other way about). This might well be availabe only under advanced search, although it could be part of Basic Searxh if we so choose. There would not, in any version of this idea, be separate bibiography pages for people who are both authors and artists, to the best of my understandign, and I would not support any such idea. -DES ^Talk 11:39, 18 June 2009 (UTC)

It's a fairly quick way to get some speed-up, and doesn't require tuning every possible advanced search query, which looks like becoming a nightmare. It also shouldn't change any current displays: you can just UNION the Writers and Artists tables (maybe via a view) back into Authors if you need the existing definition. Adding extra flags to each author record for Writer and Artist roles is simpler but needs more tuning to get the benefits - and would need revisiting for each new role. (Although we'd probably want to revisit in each case anyway, for instance when we add translator support do we want to add separate "Translations" sections to bibliographic pages?) The generic "define a new role and add it to the appropriate publications/titles/authors" is likely to introduce more tables that will reduce performance further and make advanced searches more complex. BLongley 18:57, 18 June 2009 (UTC)

Still, it doesn't have to be a genuine table split, a logical one might still help, I just don't know enough MySQL yet to be sure. In other DBMS I've used there are features like Bit-Mapped Indexes and Partitioning that would pretty much guarantee that "behind-the scenes" changes like adding an "Artist" flag would help even if the table stayed as one table. This is why I'm asking people to consider it - and at the moment it's probably a technical consideration alone, as I'm not proposing any screen changes to go with it. But such might naturally follow later - e.g. people are entering Companies and Photo Libraries for Coverart credits. Presumably the details for such would be a bit different from those of the (entirely human, as far as I know) Writers so it might be desirable to let Authors and Artists diverge to some extent - the common fields we already use can stay the same. BLongley 18:57, 18 June 2009 (UTC)

Duplicate entries on Summary bibliographies

We have long constructed the bibliography pages, particularly the summary biblios, on the principle that any given work will appear at most once on such a page (not counting variant titles and serializations). Novels which are part of a series appear in the series listing, not in the "Novels" section. (I vaguely recall that this was not true or not always true, for ISFDB1 pages, but i might be mistaken.)

I am coming to suspect that this is a mistake, at least in some cases. When a user visits a biblio page, particularly a fairly long one with multiple series and a good many non-series novels as well, looking for a particular novel that novel may be quite hard to find if the user doesn't know which series to look in. If, in addition, the user is not all that familiar with the way the ISFDB works, s/he may conclude that the novel isn't listed at all when s/he doesn't find it in the Novels section.

Now that short fiction series are listed on the biblio pages also, and short fiction works part of a series are not listed in the "Short Fiction" section, and may be in either the main "series" section above novels or the "short fiction series" section, depending on whether there are nay novels in the series, the problem is even more significant.

I do understand the desire to avoid redundancy, and the desire to avoid making already long pages even longer. But I think we may want to consider changing this display policy. I suggest two change options for consideration:

1. Fully redundant display. All works that are part of a series will always be displayed in the section where they would be if they were not part of a series, as well as in the relevant series section.
2. Optionally redundant display. A bibio could either display in the "fully redundant" mode described in #1, or as it does now. There would be some sort of user interface for switching between modes. Perhaps a logged-in user could set a preference for which display mode a biblio page defaults to when first entered. Perhaps the mode could be toggled separately for novels, short fiction, and other kinds of works.

Of course, we could make neither change. Such a change is not vital -- the alphabetic and chronological displays will let the work be found, once the user knows that. But I do think a "redundant summary" display might be useful (but it needs a better name if we go foreward). Does anyone else think thsi is worth considering further, before making a formal feature request, or even a design proposal? -DES ^Talk 23:27, 19 June 2009 (UTC)

Concur. And I think it should be deployed in two stages. First as a 'link' just as the alternate biblio pages are now. And then we should develop code to store user preferences. The 'Redundant' summary should be the default for all non-logged in users, and folks with no preference set. (As you mention, this is a tool to help those unfamiliar with the database find what they want, so it should be the default for those unfamiliar). So, to recap... Support as an alternate biblio for now, and later (if ever) the default once we can save preferences. Kevin 00:00, 20 June 2009 (UTC)

Of course it is not JUST a tool for newcomers. I suspect I would set my preference to redundant, if we had such a feature right now. -DES ^Talk 00:09, 20 June 2009 (UTC)

Another option would be a true, chronological list of titles, each tagged by type and annotated with series membership, without the groupings. --MartyD 01:56, 20 June 2009 (UTC)

That would be an option, yes. Personally I don't think I would want a list that intermixed novels, shortfiction, essays, etc, but some might. -DES ^Talk 02:07, 20 June 2009 (UTC)

It could be useful for comparing to other bibliographies published that way, and spotting the mis-matches in both directions fairly easily. Kevin 02:20, 20 June 2009 (UTC)

Well, the original design assumed that the Summary Bibliography page would be as important as the Alphabetical page and the Chronological page. However, since the Summary page is our default, it proved to be much more popular than the other two pages, so it is now thought of as our "standard biblio page". In addition, few of the changes that have been made to the Summary page over the last 3 years have been applied to the other pages (because Al was waiting for the design to stabilize), so the other two pages are now little more than "poor relatives".

It looks like we may want to do a few things. First, we need to whip the Summary page into shape, which will include the implementation of Chapbooks-as-containers and other things that we have on the Feature list and which can happen over the next few months. Second, we need to update the other important pages, including the Series, Alphabetical and Chronological biblio pages, so that they would reflect the current design/layout philosophy. Third, we need to consider whether we want to make the Chronological/Alphabetical pages more prominent by moving their links from the navbar to the top of the page. Fourth, we need to review the functionality that will exist after all these things are done and decide whether we need to create additional views of Author biblios. Ahasuerus 02:27, 20 June 2009 (UTC)

Fair enough. I just wanted to get this thought on record for consideration before I lost it. I didn't think it would be in the next round of software changes, even if everyone thought it was a great idea. -DES ^Talk 02:47, 20 June 2009 (UTC)

"Chapbooks-as-containers" is submitted for testing now, but "store user preferences" looks like a good idea too. For instance, we've already discussed whether switching off Images is desirable (and I think it is, if we want people to use the ISFDB software offline.) Series display is under consideration too, the "as by" seems to mislead at times, to the extent that people are creating variants just so something that was actually published shows up the way they want: showing all "actual" publications could be better. So many options, so much coding to do, so little time... I really do understand how Al feels at times. BLongley 23:51, 20 June 2009 (UTC)

Patch r2009-04

Patch r2009-04 has been tested and code reviewed. It will be going live later today (Saturday), probably around noon Eastern US time. Here is what will change:

• Bug 2799064 Fixed Advanced Search on Pseudonyms
• Bug 1743292 Fixed creating Variant Titles for Reviews and Interviews, which currently results in Author-less Titles
• Feature 2799068 Linked unmerged Titles to the affected Publication in the moderator screen
• Feature 1969497 Added Publication information to the moderator screen for Proposed Publication Updates (partial fix)
• Bug 2795822 Fixed the bug that resulted in duplicate Tags being generated when there were a lot of similarly titled Publications like Doctor Who and ...
• Feature 2799074 Displayed "held" Status and added a link to user Talk pages
• Bug 2797518 Fixed wrong links to the next page and author's records in Advanced Author Search results
• Feature 2803759 Changed the default Title Type in the Contents section from ANTHOLOGY to SHORTFICTION

In addition, the following changes will affect development/test systems only and have no impact on the live server:

• Bug 2806293 Fixed the problem that resulted in local database user creation failure.
• Bug 2806290 Updated the graphics on the Sourceforge site to match what's on the live ISFDB server.

As always, please report any issues or new bugs here. Thanks! Ahasuerus 14:17, 20 June 2009 (UTC)

Patch installed, test away! :) Ahasuerus 16:26, 20 June 2009 (UTC)

• The implemetnation of Feature 2799074 seems to be working just fine, and i love the link to the editor's wiki talk page. May well help people find the wiki. -DES ^Talk 16:33, 20 June 2009 (UTC)
• The impelmentation of Feature 1969497 also looks good to me. -DES ^Talk 16:47, 20 June 2009 (UTC)

Now it's live, I notice I forgot to correct "Pseudonymns". Ah well. BLongley 17:22, 20 June 2009 (UTC)

Yup, I noticed it during testing, but decided that it was more important to get the patch out quickly than to fix a typo, which we can always handle later :) Ahasuerus 17:58, 20 June 2009 (UTC)

I've used these and like:

• Feature 2799068 Linked unmerged Titles to the affected Publication in the moderator screen
• Feature 1969497 Added Publication information to the moderator screen for Proposed Publication Updates (partial fix)

BLongley 23:41, 28 June 2009 (UTC)

I've not used these, although I felt the need for them at one point: I think some people do like them though?

• Feature 2799074 Displayed "held" Status and added a link to user Talk pages
• Feature 2803759 Changed the default Title Type in the Contents section from ANTHOLOGY to SHORTFICTION

BLongley 23:41, 28 June 2009 (UTC)

I've not used these, and not seen anyone else use them either, although I felt the need for them at one point:

• Bug 2799064 Fixed Advanced Search on Pseudonyms
• Bug 1743292 Fixed creating Variant Titles for Reviews and Interviews, which currently results in Author-less Titles
• Bug 2795822 Fixed the bug that resulted in duplicate Tags being generated when there were a lot of similarly titled Publications like Doctor Who and ...

BLongley 23:41, 28 June 2009 (UTC)

I tried this, and something broke on the new PC. :-( Will investigate more.

• Bug 2806293 Fixed the problem that resulted in local database user creation failure.

BLongley 23:41, 28 June 2009 (UTC)

Series Bibliography display opinions wanted

While working on adding title type tagging to the Series Bibliography display, I noticed that in a case where some entries in a series are numbered and some are not, the titles are not displayed in chronological order. See, for example, the display for Black Widowers and also the display of the same series in Asimov's Summary Bibliography.

Do you prefer the current behavior be maintained, like so: