[libdb-develop] =?UTF-8?B?W3Rhc2tdIFdvcmsgVHlwZXMgYW5kIFN1YnR5cGVz?=
Status: Inactive
Brought to you by:
morbus
From: <mo...@di...> - 2004-08-18 16:03:28
|
Project: LibDB Version: cvs Component: Code Category: tasks Priority: normal Assigned to: Anonymous Reported by: Morbus Iff Updated by: Morbus Iff Status: active Defining "types" of media, like a "movie", "book", "comic book", etc., allows LibDB to show custom forms that specifically cater to what you're actually adding (ie. you wouldn't see a "Laserdisc" carrier when you're adding a "book"). Previously, these would be stored in the libdb_work table as "type", per the FRBR specification. However, recent development in the FRBR community has removed the Work "type" attribute, and introduced the concept of a "super type" and a "representative expression". These new approaches require some modification of the data model (at bare minimum, the removal of libdb_work.type, which has already been done). One place that will benefit the most from the use of "type" is the "roles" one can assign to a person or corporate body. With over 50 roles in the database now, just for "movies", that'd be an awful lot of junk to plow through if you're adding a "book". Thus, a type comparison would only show roles that would be relevant to what you're currently adding. Some roles, however, are shared amongst multiple types. Most movies, documentaries, and plays or operas have a "Lighting Technician", and nearly all literary types have an "Editor" and "Writer". As such, our implementation of types in LibDB should have a parent/child relationship. As with all cataloguing tech, however, there's a zillion different ways you can do this. Richard Acero mentioned http://copyright.gov, which breaks copyrightable items down into "literary works", "visual arts", "performing arts", "sound recording" and "serials/periodicals". Each of these types is further broken down into smaller subtypes: literary works encompass fiction, nonfiction, manuscripts, poetry, contributions to collective works, compilations of data or other literary subject matter, dissertations, etc. and performing arts contain motion pictures, scripts, and so forth. Regardless of the subtypes defined, I like the breakdown of the five "major" types. As mentioned, however, there's a zillion different ways of doing this, and some prior art can be found at the URLs below. I don't think it's in our best interest to settle on a final decision RIGHT NOW, this early in the development process. However, based on prior desires and outspoken need, I'm considering implementing "Literary" ("Books" and "Comic books") and "Performing Arts" ("Motion pictures"). Code-wise, the current plan in my head is: * add a new table: libdb_expression_types. * libdb_expression_types: id | parent | name | description * example: [20charIDa] | NULL | "Literary" | "Blah blah" * example: [20charIDb] | [20charIDa] | "Book" | "Blah blah" * add "expression_type" column to libdb_expression. * add "expression_type" column to libdb_roles. With the above implementation, a single role type could have three different values of expression_types: * NULL: this role type should be shown for everything. * [20charIDa] or "super type": shown for every type of "Literary" * [20charIDb] or "sub type": shown for only "Book" types. Prior Work URLs: * http://www.loc.gov/marc/sourcecode/form/formlist.html * http://www.austlit.edu.au/common/manual/AuthorityLists.html#WorkTypeTerms * http://www.loc.gov/marc/sourcecode/genre/genrelist.html Morbus Iff -- View: http://drupal.org/node/view/10162 Edit: http://drupal.org/project/comments/add/10162 |