Question: local extensions to schema?

A quick question that may have a quicker answer. Is there a right way to make local modifications to the DB schema? We will need a containerAuthor field for local use. I can shoehorn one in, but I really don't like the idea of diverging from the standard schema. Is there a graceful or safe way to extend the DB?
  • While I'm here, I want to make one more pitch for adding containerAuthor to the schema, and including this field for book types. This is needed for a very common use case that is not covered by hierarchical relations. Organizations (NGOs especially, but others as well) contract for reports. The cite for these looks something like this:

    John Doe and Jane Roe, Progress Cambodia, Working Conditions in the Weaving Industry (1998).

    If the institutional author sponsoring the report is entered as an author-type creator, the names collapse to "John Doe et al.", which is not right. If the individual authors are entered as contributor-type creators, this suggests a collection of essays or chapters by separate people, and my style delivers italics for the names instead of small caps. Logically, there is no way past this problem without another field.

    This is not about hierarchical relations; the sponsoring institution might have done only one report, and it might have been authored entirely by one individual consultant.

    We're going to see a lot of this type of cite here. It would simplify things a lot at this end if the field could be added to the standard schema.

    FWIW.
  • I guess I have my answer. :)
  • Just a quick note: I don't believe this use case is covered by the "container-author" variable in CSL. See this thread for an example use case.
  • Still need to solve the problem, though.

    We can't avoid local extensions to the schema, so we'll find some way to keep the migration process orderly and safe. I've had another look through the possibilities, and it looks like the least violent alternative for this issue is to open the "sponsor" field to books. Is there an alternative treatment for contracted studies that would be better?
  • Okay, I've figured out what to do for migrations. We'll set our schema and DB at upgrade level + 10000. The local version will unwind the 10000 increment if it is present, apply any Zotero migrations normally, and then apply our local modifications, following a separate upgrade counter. This will prevent direct upgrades to a later mainstream Zotero trunk release (Zotero will think it's doing a version downgrade and refuse to run). To move a user back into the mainstream, we'll provide a transition package that sets the mainstream DB upgrade counter back to the real version increment, and unwinds our schema changes in a way that will not conflict with mainstream schema changes.

    This will take a bit of work to set up, but once it's done we'll be free to hack in additional fields locally without trapping our users in a development fork or cul-de-sac. That will release some of the pressure for immediate solutions from the community, so that we can have more leisurely discussions over standards as people have time available (I'm putting a lot of time into getting up to speed and getting things in place at the moment, but when next term starts I'll be racing against the clock just like everyone else).

    Tools to build the tools to build the tools ...
  • edited January 25, 2009

    While I'm here, I want to make one more pitch for adding containerAuthor to the schema, and including this field for book types. This is needed for a very common use case that is not covered by hierarchical relations. Organizations (NGOs especially, but others as well) contract for reports. The cite for these looks something like this:

    John Doe and Jane Roe, Progress Cambodia, Working Conditions in the Weaving Industry (1998).
    Could you use the "report" item type for this, which does have an Institution field? Your example above is a report, right?
  • @ezralogo: ! You're absolutely right.
  • @ezralogo: We'll be needing some other fields for legal materials that are not yet available, so I can't avoid building the upgrade/downgrade wizard. But I'm very grateful to you for pointing this out, it crosses one off my list.
  • We'll be needing some other fields for legal materials that are not yet available, so I can't avoid building the upgrade/downgrade wizard
    It sounds like you're on a fairly tight schedule, but we're certainly open to making adjustments to the schema in 1.5, so it may be worth sharing your list (if you haven't yet) to see if quick consensus can be reached, as avoiding the upgrade/downgrade wizard would certainly be to your (and your users') advantage.
  • edited January 25, 2009
    A tentative list has been floated to xbiblio, but little issues keep cropping up as I work through the style, and I fear that I'm starting to sound a bit like the Little Boy Who Cried Wolf. Implementing things locally will give us a chance to work out a coherent proposal that covers all the bases, so that there can be a careful discussion of alternatives in context. I demoed Zotero with a draft version of the Bluebook style to a few students last week, and they were instantly won over. Some expressed outright astonishment that Zotero is available free of charge. So long as I don't put a foot wrong in building the widgets, they'll be happy to play along. I don't mind putting in the work, if it will make for a smoother process in the long run.
  • OK, that's reasonable. Let me know if you have any questions on the schema update process.
  • edited January 25, 2009
    One quick one is about the internal key numbers assigned to elements of the schema. In itemTypes, fields, and creatorTypes, the schema elements are numbered in sequence. If I assign a high number (thinking unreserved port numbers, like) to a field that we add, is that going to cause chaos, or will those entries just be ignored when control is returned to mainstream Zotero and the schema is updated? I'm thinking that if the latter is true, our downgrade just needs to restore the display tables in the schema (like itemTypeFields) to their pristine state, and the user is good to go for a Zotero upgrade.
  • edited January 26, 2009
    but we're certainly open to making adjustments to the schema in 1.5
    Any chance that the thesis item will get its "place"?

    http://forums.zotero.org/discussion/4497/thesis-problem/?Focus=19579#Comment_19579
    http://forums.zotero.org/discussion/339/additional-fields/?Focus=18612#Comment_18612

    I also would very much appreciate a dedicated status field (with preset values like submitted, in press, accepted, etc):

    http://forums.zotero.org/discussion/882/
    http://forums.zotero.org/discussion/4418/in-press-as-item-type/
Sign In or Register to comment.