Talk:ISFDB Feature List

Features needed for beta

Al currently has the pseudonym editor and watchlisting ISFDB data on the feature list for pre-beta. My own list would not include the pseudonym editor, which I think would be handy but not necessary. I'd ask for:

• watchlisting titles
• resubmit rejected records

and possibly

• free text deletion reason field for deletetitle, delete pub
• free text rejection reason field for rejected submissions

An issue occurred to me regarding multiple submissions that would have an impact on resubmitting rejects too. Suppose you have an UpdateTitle submitted by editor A, and later, but before the UpdateTitle is approved, a MergeTitle submitted for the same title by editor B. Now suppose a moderator approves the MergeTitle first. The UpdateTitle is now going to try to update a record that no longer exists.

Rejected records might become "out of sync" in the same way. I don't think this is a showstopper, though; it's going to be relatively rare, I would think, and I can't offhand see a way it would cause data corruption, although I need to think about that some more. Including verification that relevant data had not changed since submission would be quite difficult -- I've written code like that and it's non-trivial. Mike Christie 04:48, 29 Nov 2006 (CST)

Not that I am necessarily advocating implementing something like that pre-beta, but would adding a "last edited" timestamp to all records and to all submissions (to be compared at approval time) help alleviate the problem? Ahasuerus 09:41, 29 Nov 2006 (CST)

A follow-up comment. Though I think there are lots of very useful features that would help, I think Ahasuerus is right that we don't yet know enough about how editors will really operate to assert that we have to have the watchlist and resubmit capabilities. I'd be willing to go along with just getting the bugfixes done and starting the beta. The risk, as Ahasuerus pointed out somewhere, is that we discourage editors who don't then return. I think good support from the moderators can ameliorate that risk.

If I get just one feature, I think it's resubmit rejects. That would cut down on frustration more than watchlisting would. If I get two features, it would be linking "recent edits" to the moderator display, for all editors, so anyone can see what was changed. That would be a crude watchlist. Mike Christie 05:02, 29 Nov 2006 (CST)

Numbering

Any objection to me numbering the features? I'd start at 90001. I think I'd lose the "Series" separator; I don't think there's a need to track those independently, is there? Mike Christie 07:26, 2 Dec 2006 (CST)

Sounds good! Ahasuerus 17:37, 2 Dec 2006 (CST)

Title characterization

I'm picking up a thread from Bibliographic_Rules#How_do_you_record_split_publications? which was getting rather long, and also because what I want to suggest is nothing to do with the current biblio rules.

It seems that a lot of what we want to say about a title is a way to characterize it -- it's abridged, fixedup, rewritten, expanded, translated, part 1 of a serial, 1965 edition, and so on. Would it be useful to add a "Characterization" field to the title record which would allow these options? Actually it could be free text, though I'd think we'd want to limit the variations somewhat. Then you could have title="Jem", characterization="", distinct from title="Jem", characterization="Part 1 of 4". Mike Christie (talk) 22:47, 14 Dec 2006 (CST)

What you are describing sounds similar to what I mentioned over on Bibliographic Rules the other day with two exceptions. First, I was thinking more along the lines of a dropdown list of allowed "characterization", but free text may well be a better way to go. Second, I was thinking that this "Characterization" field would apply to Variant Titles only and would be more of a "Relationship [to the parent title]" field. You seem to be suggesting that this field could be populated for any title, including standalone titles. How do you envision it being used for parent titles? Cases like "cut by publisher" so that subsequent Variant Title information, e.g. "text restored", would make more sense when displayed? Ahasuerus 00:02, 15 Dec 2006 (CST)

My 2-cents says I’m fine with a characterization field. In my own book list I thought about such a field but then realized I was adding notes all over the place (titles, sub-titles, author names, publisher names, etc.) and so I instead went with allowing (notes in parentheses) and the logic truncates those off as needed. Al may already be truncating at the "(" as the code already deals with “(part 1 of 3)” serialized titles. Marc Kupper 02:56, 15 Dec 2006 (CST)

Titles would be grouped and characterizations would be grouped and/or sorted. Translations could have the pubtitle in the actual pub language, the title title in the canonical version language, and a characterization on the title of "translation". Then they'd list under the canonical title if we want, or could be grouped separately as translations (ultimately a preferences checkbox). Mike Christie (talk) 22:47, 14 Dec 2006 (CST)

That would be certainly ideal, but first we would need to add some form of language support and populate the language field for some [unknown] thousands of records. That will take a while :-\ Ahasuerus 00:02, 15 Dec 2006 (CST)

Abridged, fixup, rewritten -- these are just displayed as parentheses after the title, but aren't part of the links, so the length of the hyperlink would be the only difference between this display and the approach of incorporating the parenthetical characterizations into the title field. Mike Christie (talk) 22:47, 14 Dec 2006 (CST)

We would be effectively replicating the standard encyclopedic functionality whereby titles are printed in one font (e.g. italics) and any additional information like "abridged" is printed in a different font. Which sounds eminently reasonable. Ahasuerus 00:02, 15 Dec 2006 (CST)

That gave me an idea for the DAW list and it was less then five minute’s work to fix the hyperlink generator for links to end the link before the " (". Marc Kupper 02:56, 15 Dec 2006 (CST)