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
|
