Work out a layout for volumes

[George]

* Volumes are connected to Editions
* Editions are connected to Works

George: http://upstream.openlibrary.org/books/OL13449003M/Collected_works
[4/20/10 11:41:49 AM] Edward Betts: editions with volumes: OL13449003M, OL13444793M, OL13447577M, OL13489071M, OL13456520M, OL13446962M, OL13443760M, OL13447132M, OL13447207M, OL13448943M, OL13448020M, OL13489063M, OL13446744M, OL13443690M, OL13489065M, OL13493127M, OL7120086M, OL13448612M, OL13488185M, OL13447647M, OL13445246M, OL13439942M, OL13442693M, OL13489068M

[George (george-archive)]

Also need to cover it in the Edit UI - perhaps an "Add Volumes" widget in Librarian mode.

* Active bug - can't add fields on Upstream: http://upstream.openlibrary.org/type/volume?m=edit
* http://upstream.openlibrary.org/type/volume
* http://openlibrary.org/type/volume

[George (george-archive)]

New (needed) fields for volume type:

- title (string), unique
- author(s) (string)
- contributor(s) (string)
- work(s) (work)
- TOC
- number of pages (string)

[Karen Coyle (kcoyle)]

There are simpler and more complex volume situations.

- The simplest one is that a single text has been spread over multiple physical volumes. There is only one title, one author.... So v. 1, v. 2 (with links for scanned) is fine. No more details needed.
- The next is serials, which only get a title (of the serial), and the volume often has a number and a year. Those are in the Archive as "v. 1 1985," which is fine as a string to show to users who are looking for something in particular.
- More complex are the "collected Works" of an author where one or more works are in each volume, and users would like to know which volume has which work. This could be in a TOC, or it could be associated with the volume number. As long as users can see it somewhere on the record it is probably ok.
- Monographic series (World Best Books in 100 volumes, etc.) - If they are a single Work per volume, there is usually a separate record for each volume, and the name of the series is in the series field. Sometimes you just get a single metadata record for the series, but it's not very useful. Rather than create another full level below Edition that has what is essentially the description of a work, I think it would be better to treat these as separate -- if necessary finding a library that has done the cataloging. Plus, I think for scanned works the scanners will enter the data for the Work in the volume they are scanning. I'd use the Archive data, even if limited, rather than put them under a single title.

There may be other cases, but I think they would be uncommon. For example, a multi-volume set of essays. Those usually get treated like a serial -- no author (maybe an editor), just a title, and the detailed the contents are ignored. However, a TOC would be helpful.

In a sense, "volume" is a level between edition and TOC, but I don't know any system that models it that way, mainly because the majority of editions are a single volume. With serials this can get to be very complicated: the MARC record allows for 6 (!) levels of numbering in serials. That's needed for processing incoming issues, though, and users generally see something like "v. 1, 1876 - v. 100, 1977", and then a link to retrieve each volume. That should be enough for us, and the volume + year that is in the IA record for the scanned item would be sufficient to hold the link to the volume.

All of this means that we may be able to get by with just a simple "volume" field, and may not have enough data to create anything more complex than that. And the next level of complexity may be more than we want to undertake.

There are some items that can be considered either a serial or a bunch of separate monographs. Examples are various yearbooks, recurring reports like census reports, etc. Whether or not we merge them will depend on the metadata that we receive, but if we have a choice, and can show something sensible in the "volume" field, i think that bringing these together may be more user-friendly than keeping them apart because some of them come in sets of many hundreds, and they will clutter up the retrievals and keep users from finding other things that their search retrieved. [Another libra...