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 library oddity: encyclopedias, annuals (like yearbooks, Physician's Desk Reference, etc.) are often coded as serials in library data because they are purchased on an ongoing open order, which is usually handled by the serials system. Most users would not consider them serials and they aren't kept in the serials area of the library. We'll get some serial MARC records for those, and some Book MARC records, depending on the library's whim.]