"Document updates (add, edit, delete) are serialized, except for binary blobs which are written concurrently. Database readers are never locked out and never have to wait on writers or other readers. Any number of clients can be reading documents without being locked out or interrupted by concurrent updates, even on the same document. CouchDB read operations use a Multi-Version Concurrency Control (MVCC) model where each client sees a consistent snapshot of the database from the beginning to the end of the read operation.

Documents are indexed in b-trees by their name (DocID) and a Sequence ID. Each update to a database instance generates a new sequential number. Sequence IDs are used later for incrementally finding changes in a database. Theses b-tree indexes are updated simultaneously when documents are saved or deleted. The index updates always occur at the end of the file (append-only updates)."

Sam writes this potentially gives us a consistent distributed source of both unique ID and sequential changes. Unique ID could line up with our own simple Knowledge Commons object ID server/service.

This part is also especially important:

"Documents have the advantage of data being already conveniently packaged for storage rather than split out across numerous tables and rows in most databases systems. When documents are committed to disk, the document fields and metadata are packed into buffers, sequentially one document after another (helpful later for efficient building of views)."

this seems to suggest that CouchDB would work best as a convenient way to package data for final delivery, that fits the "Document" model. So, a document object could be built from ID, content, multiple metadata sources, and stored in CouchDB as a CouchDB model "Document" object. This could be built programatically depending on needs of archive users.

To me, this makes CouchDB more likely candidate to be a utility of convenience, a storage system that can work with the spec that we creatd

So, I can imagine a distributed data structure where Unique ID for an object lives in a network-connected database, metadata about object lives in multiple databases,with FLOWS component applications that do the job of programatically collecting and writing metadata. And, when needed, special combinations of these can be stored for convenience in couchDB. It could turn out that all of these needs could be met by multiple couch databases (which would be awesome, as couch has provision for distributing db's). This could negate the need for using Postrgres/Mysql and other SQL-based db's for Knowledge commons, and FLOWS db network storage. (although applications like iRODS, Drupal, etc would still need their local SQL db to operate, but only for local functionality)