ISFDB:Proposed Design Changes
From ISFDB
This page is intended for consideration of proposed changes to the Design of the ISFDB.
Specifically, at first, for those changes intended to provide what Al has described as "features considered necessary for solid bibliographies".
Much of the in ital text here is taken from ISFDB:Community Portal#Intended Order of Work, with editing to combine experts from a discussion into a set of coherent issues. Further discussion will no doubt take place, hopefully leading to a consensus (or a decision from on high) and action. -DES Talk 11:07, 29 Jan 2008 (CST)
Contents |
Roles
This would encompass ideas like Narrator, Illustrator, Editor, Cover Designer etc.
- Some people have suggested that a translator creates a new work (title) that can be published in multiple formats (publications), but that might be debated. Even if a translation is considered to be a new work, we might want to record both the translator and the original author, as both are essential to making the final work what it is, and both are of bibliographic significance. -DES Talk 11:22, 29 Jan 2008 (CST)
- This might be implemented by defining a fixed set of roles, and allowing an entry into each. This has the disadvantage that any new roles would need a code change, and that empty entries would need to be stored for most toles in most records. Another way would be to have a varying number of "role" entries in a publication record, just as we have a varying number of review, interview, or content entries. Each role entry would consist of a role type (either freeform, or, perhaps better, picked from a dropdown list like the story length entries) and one or more canonical names for the person/people in that role for that publication. This would be flexible going forward, and might be able to reuse code from the way reviews are implemented now. -DES Talk 11:22, 29 Jan 2008 (CST)
Printing records
Should we try to split the concept of publication into "edition" and "printing"? This might allow display of only distinct editions/bindings, with printing-level detail only shown if wanted. A problem with this idea is that it is not always clear which printings are actually different in content until we have full data for multiple printings. -DES Talk 11:56, 29 Jan 2008 (CST)
Based on
A title (or perhaps a publication) should be able to be "based on" 0 or more other works. A "Based on" record might consist of a link to the work (publication?) based on, and the nature of the relationship (expanded from; includes; expands; abridged from; revised version; experted from; restored) picked from a dropdown list. This would handle fixups, expanded versions, revised versions, screenplay->novel conversions and the like. -DES Talk 12:04, 29 Jan 2008 (CST)
This has already been proposed for variant titles, but this proposal is wider, and would extend to a relationship between works of different types, or that are not "the same work" in the way that a variant title normally is.
- The link should be two way. That is, If Work A is "based on" work B, this fact should be shown in the display of work B as well as in that of work A, if possible. -DES Talk 12:05, 29 Jan 2008 (CST)
New Fields
Possible new fields to add:
- Printing number (to a publication)
- Physical dimensions (do we care?)
- juvenile title. Possibly just Yes/No, Possibly a recommended age. Currently this is specified by overloading the "length" field, which is probably unwise. Should this be a title-level field, if added?
- Catalog number. Currently this overloads the ISBN number field, and must be placed in the notes when both are present. (Publication level?)
- Publication date (or first printing date) (title level or publication level
- Copyright date?
- Simplified title? (see talk page)
- Date of Variation, for variant titles? (See ISFDB:Community Portal#Variant Titles and Dates for more discussion.)
Fields to restrict
Fields that possibly should be restricted to valid entries from a table, rather than being free-form:
- Binding (hb, tp, pb, chapterbook, audio, ebook, perhaps others)
Fields to make multiple (many to one)
- Primary verified. Allow for more than one primary verifier at a time on a given publication.
Publishers
We currently do not have the ability to edit publishers (like we do with authors), merge them, have supporting fields like web sites, dates of existence, or related bibliographies. We also don't link imprints to publishers like we do with pseudonyms to authors (or even variant titles).
- Update: we now have publisher edit and merge, and supporting fields for Wikipedia page and other websites, and one notes field. Dates of existence, bibliographical notes like company ownership, addresses, distributors, known ISBN ranges, and publisher series are being recorded in the Publisher Wiki pages, and some linking between imprints/publishers/companies has been started there. See here for all Publisher Namespace entries so far.
- Regularization of publisher and imprint names has started but lacks direction, with some editors overloading the publisher field with imprint AND publisher info, and others recording the imprints and noting publisher in the wiki. One emerging standard is " / SFBC" after original publisher name to indicate book club editions.
- Future directions are unclear: variant publisher names seem unlikely to happen, and a hierarchy of companies, publishers and imprints like we have with series and sub-series seems unlikely in the short term too. Workarounds include Wiki Redirects and Wiki Links. There is a fear of data loss if over-regularization occurs too soon, and possibly cloning the publisher field to an additional new field would allow one to remain for "exactly as stated" (or at least "editors preference") and the other field could be used for grouping into a smaller number of useful publisher-related information. BLongley 19:30, 1 July 2008 (UTC)
