If I understand Bruce’s plans for MakeCSL, for the various parts of a
style, users will pick and choose the macros to use based on previews of
existing styles, and MakeCSL will consolidate these into a single new style.
Yes.
That should work well for styles based on the core styles, but it
wouldn’t let the tool take advantage of the potentially hundreds of
unique styles that might eventually be in the repository.
My argument (which is in part based on the practical demonstration of
MakeBST) is that the variations among those styles come down to
trivial differences, and that if you break apart those styles into the
right pieces, it’s easy to then put them back together in infinite
variation.
Consider some of the macros I just checked in for publishers.
Some styles do “New York:ABC Books” others do “ABC Books;New York” and
still others wrap them in some grouping punctuation. But beyond that,
what other variations are there really?
So define those two or three or four different variations as macros,
and be done with it.
Bruce has been
recommending to users on the Zotero forums that they post styles to the
Zotero style repo rather than post them on their own websites, and it
seems quite possible that in the not-too-distant future there could be
too many styles to easily go through and find one close (or identical)
to the custom style needed.
I’m not so sure. Consider that each style gets tagged with one-or-more
categories. So it’s quite easy to then filter on those categories.
When you couple that with previews (of styles, and also macros), I’m
not concerned. Even if there were, say, 100 styles with the “history”
category, you could still narrow that further by saying certain styles
are “base” styles.
Either as a feature of MakeCSL or as a separate search function of the
style repository, perhaps there could be a GUI tool that let you upload
one or more sample records and type or paste in what the bibliographic
output should be. The tool could generate previews for all existing
styles using the sample data and then run an edit distance function
(Levenshtein or similar) on those previews and the user’s input to
determine what style came closest to the desired formatting. With some
more complicated logic the tool might be able to pick and choose the
macros from those styles necessary to form a new correct style, but that
wouldn’t be necessary for a first step.
Thar could be cool. In essence, you’d be automating the wizard process.
But, of course, one still needs the basic model and process before one
would build that automation; right?
Also, there’s the question of how you’d have those samples. If you had
to create them or otherwise intervene in getting them into the system,
that might take more work than a good wizard interface.
Also, I’m not convinced users need their own data for previewing. I
find it more of a hassle to have to find suitable preview data for
creating new styles (in, say, csledit.xul) than if we just had some
good sample data upfront (perhaps adapted for different fields).
BTW, if you’re curious, here’s the current SQL generated by Django:
$ python manage.py sql styles
BEGIN;
CREATE TABLE “styles_category” (
“id” serial NOT NULL PRIMARY KEY,
“name” varchar(25) NOT NULL UNIQUE
)
;
CREATE TABLE “styles_optiontype” (
“id” serial NOT NULL PRIMARY KEY,
“name” varchar(30) NOT NULL UNIQUE
)
;
CREATE TABLE “styles_style” (
“id” serial NOT NULL PRIMARY KEY,
“title” varchar(100) NOT NULL,
“slug” varchar(50) NOT NULL UNIQUE,
“type” varchar(1) NOT NULL,
“author_id” integer NOT NULL REFERENCES “auth_user” (“id”)
DEFERRABLE INITIALLY DEFERRED,
“created” timestamp with time zone NOT NULL,
“updated” timestamp with time zone NOT NULL,
“citation_id” integer NOT NULL,
“bibliography_id” integer NOT NULL
)
;
CREATE TABLE “styles_option” (
“id” serial NOT NULL PRIMARY KEY,
“type_id” integer NOT NULL REFERENCES “styles_optiontype” (“id”)
DEFERRABLE INITIALLY DEFERRED,
“value” varchar(15) NOT NULL
)
;
CREATE TABLE “styles_macro” (
“id” serial NOT NULL PRIMARY KEY,
“type_id” integer NOT NULL,
“slug” varchar(50) NOT NULL UNIQUE,
“xml” text NOT NULL
)
;
CREATE TABLE “styles_macrotype” (
“id” serial NOT NULL PRIMARY KEY,
“name” varchar(40) NOT NULL UNIQUE
)
;
ALTER TABLE “styles_macro” ADD CONSTRAINT type_id_refs_id_7952bca7
FOREIGN KEY (“type_id”) REFERENCES “styles_macrotype” (“id”)
DEFERRABLE INITIALLY DEFERRED;
CREATE TABLE “styles_layoutlistitem” (
“id” serial NOT NULL PRIMARY KEY,
“macro_id” integer NOT NULL REFERENCES “styles_macro” (“id”)
DEFERRABLE INITIALLY DEFERRED,
“context_id” integer NOT NULL,
“position” integer CHECK (“position” >= 0) NOT NULL,
“prefix” varchar(10) NOT NULL,
“suffix” varchar(10) NOT NULL
)
;
CREATE TABLE “styles_context” (
“id” serial NOT NULL PRIMARY KEY,
“name” varchar(100) NOT NULL UNIQUE,
“type” varchar(1) NOT NULL,
“sort_id” integer NOT NULL REFERENCES “styles_macro” (“id”)
DEFERRABLE INITIALLY DEFERRED,
“layout_prefix” varchar(5) NOT NULL,
“layout_suffix” varchar(5) NOT NULL
)
;
ALTER TABLE “styles_style” ADD CONSTRAINT citation_id_refs_id_1bf2bf95
FOREIGN KEY (“citation_id”) REFERENCES “styles_context” (“id”)
DEFERRABLE INITIALLY DEFERRED;
ALTER TABLE “styles_style” ADD CONSTRAINT
bibliography_id_refs_id_1bf2bf95 FOREIGN KEY (“bibliography_id”)
REFERENCES “styles_context” (“id”) DEFERRABLE INITIALLY DEFERRED;
ALTER TABLE “styles_layoutlistitem” ADD CONSTRAINT
context_id_refs_id_54305e8c FOREIGN KEY (“context_id”) REFERENCES
“styles_context” (“id”) DEFERRABLE INITIALLY DEFERRED;
CREATE TABLE “styles_style_categories” (
“id” serial NOT NULL PRIMARY KEY,
“style_id” integer NOT NULL REFERENCES “styles_style” (“id”)
DEFERRABLE INITIALLY DEFERRED,
“category_id” integer NOT NULL REFERENCES “styles_category” (“id”)
DEFERRABLE INITIALLY DEFERRED,
UNIQUE (“style_id”, “category_id”)
)
;
CREATE TABLE “styles_context_options” (
“id” serial NOT NULL PRIMARY KEY,
“context_id” integer NOT NULL REFERENCES “styles_context” (“id”)
DEFERRABLE INITIALLY DEFERRED,
“option_id” integer NOT NULL REFERENCES “styles_option” (“id”)
DEFERRABLE INITIALLY DEFERRED,
UNIQUE (“context_id”, “option_id”)
)
;
COMMIT;
Bruce