Group entities should be individually "typed" docs in CouchDB. The relations should be individually "typed" docs too. Cleverly indexing all these docs for straight-forward use with map/reduce views would be the
Yeah, how I'm gonna handle relationships is the next major thing I've got to figure out. FRBR has its own concept of relationships, too, and I'm potentially leaning toward creating a "relationship" document type that handles them all back and forth. I can't help but feel I'm replicating too much of a relational database, were I to do that, but I fear how complex a map/reduce view would be with all these different document types floating around, cf. Damien's View Collation:
http://www.cmlenz.net/archives/2007/10/couchdb-joins
I use a CouchDB doc to represent the pragmatic intersection between single coherent data nugget and interrelated data nuggets that can created/queried/updated as a block without contention, conflict, or performance degradation exceeding my threshold for pain.
Say what now?
In your case, to represent all Group1 entities as a single doc could create a situation, in a distributed/replicated CouchDB network, where a WEMI could be modified at the same time on ten different Couches, replicated, and result in a big WEMI mess. If this WEMI represents the Starr report the day it was released that could be a big problem. If it represents a less
This is a good point - the replication part of a CouchApp (which I have only just started to learn about) is very appealing to me. The fact that I can only use HTML/JS also adds another layer of "Sounds like a Fun Challenge". I just didn't anticipate how much of an "interesting problem" an FRBR attempt has created ;)
How far do you want to take your pet project?
Why do I get myself into things like this? ;) -- Morbus Iff ( earth? shxt and scrambled eggs. earth? ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
