Talk:Stabilizing Bibliographic Data

From ISFDB

Jump to: navigation, search

Introductory notes

Note: See this early May 2006 discussion for more background information. Ahasuerus 20:20, 27 May 2006 (CDT)

Just a couple of quick points about this draft guideline.

  • The author pages we are creating are starting to look alarmingly like a copy of the ISFDB, recoding edition data and what we verified. That can't be the right way to do it!
  • I saw the feature request for "verified against Reginald" flags, etc., and it struck me that that, plus a Wiki page for notes, might be all we need.
  • The "correct" flag is in the roadmap for 6/11/06. I suggest we leave it at just publications, since those are the clearest to verify and are 99% of our primary data. We can worry about the other records once we have the process working on publications.
  • There is a feature request built in to the guideline: an automatic wiki link from a publication moderation (also perhaps from the edit page) to a wiki page. E.g. for JCKOEG1952, displaying the edit page or moderation page of an edit to that publication would show a link to a wiki page entitled "Publication:JCKOEG1952". I don't see how to avoid the permanent tag or primary key here, though clearly it would be nice to have a more English language text such as "Jack of Eagles, Avon, 1952". If we agree this is worth doing, I'll move it to the Open Features list.
  • I have not here considered what happens to the Wiki pages on merging or deleting publications. I suspect for now that manual handling is going to suffice.
  • A main impetus for putting this together is that there needs to be a flow towards stable data, so that the pool of stable data can be identified as such and grow. Otherwise there is no way to tell what's been done without the wiki author pages, which are themselves subject to editing and changing. I entered a few books and found myself realizing that I'd have no way to tell, afterwards, what was reliable, without retyping most of that information on the author page. Anyway, the guideline isn't important, but the goal is, so if the guideline doesn't work, let's rewrite it, rather than scrap it.
Mike Christie 21:03, 26 May 2006 (CDT)

The above all look good to me. If we restrict the first pass at verification support with publications, we need to gather the requirements before implementation. In particular:

  • Validation against the primary source. The act of validation itself is subject to error - what is the minimum number of validations against the primary source do we need before locking the record?
    • I suggest we require nothing but a moderator's decision. I think the record is not "locked", so much as has the "correct" flag set, which is simply a signal to the moderator that another moderator thought the record was correct. And now I think about it, I think there's no reason any editor can't request the field to be set to correct -- a moderator gets to choose whether to accept that, after all. One other comment: when a moderator makes a decision to record a publication as correct, they should make sure the publication wiki page gives the verification that was done, and preferably who by.Mike Christie 22:00, 26 May 2006 (CDT)
  • Which fields in the record are locked? I would propose:
    • Title
    • Year
    • Publisher
    • Pages
    • Binding Type
    • Publication Type
    • ISBN/Catalog
    • Price
      • Under the approach I'm thinking of, the correct_flag is just advisory to the moderator. No need to introduce any actual locking in that case. That should not only simplify the code but allow for maximum flexibility as we work out how this process is really going to work. After all, every record is locked if you're not a moderator, in effect. Mike Christie 22:00, 26 May 2006 (CDT)
  • Open fields, even when the record is locked:
    • Tag
    • Artist (artists are often difficult to find, and we don't want a backlog of lockable records - except we don't know the cover artist).
    • Coverart URL
    • Note
  • Are we going to accept data on secondary sources? I think when we originally discussed this, we thought about having a matrix of checkboxes against known references. Now that we're actually going through this exercise, we're finding that the number of known references is expanding, and that there are disagreements between the various references. While not the primary motivation of the ISFDB, I'm finding that it is nonetheless valuable to have documented a detailed review of all the major references detailing inconsistancies between them. I think that if the publication record holds the current best knowledge we have (if the primary source is not available), then the wiki page for the author should only detail these inconsistancies. That in itself is a valuable contribution to the field of SF bibliography, as no one has tackled the problem before. Alvonruff 21:35, 26 May 2006 (CDT)
    • I'd suggest we use the publication as the location to identify these variances, just because a variance might be something like a change in attribution of a house name. I think it would be nice to have these visible on the author page, but I don't think that's as important, at least not immediately. Mike Christie 22:00, 26 May 2006 (CDT)

Updated process description

I've done a detailed expansion of the process description; I hope this makes what I had in mind a little clearer. I think this is related to Grendelkhan's notes on the ISFDB:Community Portal about verification flags, and I'll make a comment over there too. Mike Christie 11:23, 27 May 2006 (CDT)

Future features

It would be possible in the future to have a checkbox on the publications edit page labelled: "Check this box if you are entering the data from an actual copy of the publication." Checking this box would set the correctness flag to yes, and would also automatically add a note on the publication's wiki page that saying "Publication data entered from actual copy" and automatically adding the user's signature.

This could be extended to other bibliographic sources, with slightly different related functionality. Mike Christie 27 May 2006 (CDT)

Personal tools