All-told there are fourteen fields. But Common Knowledge is less a set of fields than a structure for adding fields to LibraryThing. Adding more fields is almost trivial, and they can be added to anything existing or planned—from tags and subjects, to bookstores and publishers. They can even be added to other Common Knowledge fields, so that, for example, agents and editors can, in the future, sport photos and contact information.* This can lead to, as Chris puts it, “nearly infinite cross-linking of data.”

Common Knowledge works like a wiki. Any member can add information, and any member can edit or revert edits. All fields are global, not personal. Common Knowledge diverges from a standard wiki insofar as each field works like its own independent wiki page, with a separate edit history.

Right now we’re basically slapping fields on pages, but this structure is built for reuse. The license is also built for reuse. We’re not asking members to help us create a repository of saleable, private data. Whatever you add to Common Knowledge falls under a Creative Commons Attribution license. So long as you include a short notice (eg., “Powered by the LibraryThing community”), you can do almost anything you want with the data—take it, change it, remix it, give it to others. You can even sell it, if someone will buy it. Regular people, bookstores, libraries–even our competitors–are free to use it. We’ll be adding APIs to get it out there all the more. Go crazy, people.**

Common Knowledge isn’t the answer to everything. Some data, like web links, requires a more structured approach; some, like our “work” titles, works best when it “bubbles up” from user data; and some, like page counts, have yet to be extracted from the MARC and ONIX information we have. But the possibilities are great. Series information? Blurbers? Cover designers? Books about an author? Tag notes? Other classification schemes?*** Bookstore locations? Publicists? Venues? Book fairs? Pets? Pets’ vacination dates?

Anyway, we’ve done our thinking, but this is the ultimate member-input feature. We’re going to have to figure it out together. Fields will need to be added (and removed?). Rules will be debated, formatting discussed. Although the base is solid, the feature set is still skeletal.****

Why I’m excited. LibraryThing means a lot of things to a lot of people. Some come for the cataloging, some for the social aspect. A lot come for what happens between those two poles. As I see it, Common Knowledge is the perfect LibraryThing feature. I don’t mean it’s good; I mean it’s in tune with what makes LibraryThing work. It’s social, sure, but it’s based in data. It’s not private cataloging and it’s not MySpace-like “friending.”

LibraryThing is sometimes called a “social cataloging” site. When I used this term at the American Library Association, it became an unintentional laugh line. Social cataloging sounded impossible and funny, like feline water-skiing. This more than anything else got me fired up about doing this. True “social cataloging”; it was an idea that had to be tried!*****

Details, acknowledgements and caveats. Common Knowledge is deeply unstructured. This is going to give some members hives! Names aren’t in first-middle-last format, but free text. You can enter places however you want. We’ve arranged some careful “hint” text, and fields have a terrific “autocomplete” feature, but we’re not validating data and returning hostile error messages. We’re aiming for accessibility and reach, not perfection. This is Wikipedia, not the Library of Congress. It scares us too, but we’re also excited.

Abby, Casey, Chris and I planned this feature during the Week of Code. We worked through the issues together, and Casey, Chris and I all wrote the initial code. When we broke up, the rest of the coding and the interface design all fell to Chris. Although it was a team effort, this is really his feature. I’m very pleased with what he did with it.

We decided to work on this (and on our standard wiki, WikiThing, which grew out of it) because it was an ideal project for the entire group to tackle. This jumped it past collections. I still think this was a good idea, but there has certainly been some grumbling. We heard you. Collections is next on our list, with nothing new in between.

*So far we have only three data types—radio buttons (gender), long fields (book descriptions and author disambiguations) and short fields (everything else).
**Competitors who use it might want to stop asserting copyright over everything posted to their site. This was legally bogus already, but it certainly would conflict with a Creative Commons license… Incidentally, we haven’t decided whether to go with CC-Attribution Share-and-Share-Alike or straight CC-Attribution (discussion here), but it’s going to be one or the other.
***This particular one may happen very soon.
****And yes, we can discuss the whole radio-buttons-for-gender topic. See here, here. I’m of the opinion that two genders plus maybe “unknown” and “n/a” (for Nyarlathotep?) are the best you can get without consensus-splitting disagreement. You’ll note we aren’t including other potentially-contentious fields, like sexual orientation or religion.
*****In conception, Common Knowledge most closely resembles the Open Library Project, the Internet Archive‘s incipent effort to “wikify” the library catalog. Open Library is also a “fielded wiki,” based on Aaron Schwartz’s superior Infogami platform. You’ll notice that we’ve mostly steered clear of the “traditional” cataloging fields that Open Library is starting from. We do cataloging differently, and we don’t want to duplicate effort. Anyway, we’re hoping they and others mash up the two data sets, and others.