couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thad Guidry <>
Subject Re: Defining my document model when the source is entity-relationship
Date Thu, 09 Jul 2009 18:46:43 GMT

I can think of one wiki article that helped me tremendously in understanding
the CouchDB way of relationships.  And how I could apply that to library
cataloging techniques.

SKYPE: thadguidry

On Thu, Jul 9, 2009 at 1:12 PM, Morbus Iff <> wrote:

> Hello!
> I know nothing about CouchDB (woohoo!)
> You can all blame nslater for this mail (boo! hiss!)
> I don't really have a huge interest in learning CouchDB - it's more of a
> passing "huh", based solely cos nslater keeps talking about the damn
> thing on IRC all the time. But, I'd figure that if I'm going to rib him
> about working on some crazy new technology, I might as well base my
> flaming and puerile hatred on actual facts and usage, yeah? ;)
> So, to satisfy said passing "huh", my pet project will be to implement
> FRBR within CouchDB. FRBR is a librarian tech which basically models a
> way to talk about works of creation. It's relatively new in the scheme
> of things (the librarian world moves a lot slower than the internet
> world). The design of FRBR, however, is mostly based around the idea of
> relational databases, which is exactly what CouchDB purportedly isn't.
> Right.
> I've already, four or five years ago, taken the FRBR spec and converted
> it into a set of MySQL relational tables. The earliest thing I can do
> with CouchDB, however, is thinking about how FRBR fits into the
> "Self-Contained Data" model of /relax/why-couchdb.
> To quote from WP:Functional_Requirements_for_Bibliographic_Records:
>   Group 1 entities are Work, Expression, Manifestation, and Item (WEMI).
>   They represent the products of intellectual or artistic endeavour.
>   Group 2 entities are person and corporate body, responsible for
>   the custodianship of Group 1’s intellectual or artistic endeavour.
>   Group 3 entities are subjects of Group 1 or Group 2’s intellectual
>   endeavour, and include concepts, objects, events, places.
> There are some swank charts on WP showing this model.
> The simplest question, really is:
>  * Should all these Group entities be individual docs...
>  * ... or should they all be a single document inside CouchDB?
> Perhaps I should start out with an example of what FRBR is and isn't.
> You own a book called "Morbus Rules". It's signed by Morbus, but your
> dog took a piss on it, so the bottom half is slightly stained. At first,
> you'd say to yourself, well, "hey! that's a document! why, it's just
> like the business card or address book analogy we love to use!"
> Right. It is.
> But, in FRBR, that simple book is a lot more complex. That simple book
> is an "Item" (your personal copy) of a "Manifestation" (all other books
> that are the same printing from the same publisher) of an "Expression"
> (all versions of this book that share the exact same creative parts) of
> a "Work" (the theoretical hand-waving artistic/creative "feeling", which
> could be expressed as a book, a musical, an interactive DVD, etc.). It
> has various "People" and "Companies" involved (that could change from
> Work or Expression or Item - i.e., you are the Person:Owner of this
> Item, but the Person:Author is always the same of any of these
> Expressions). Concepts, locations, and other tag-like thingies also
> apply to this Manifestation (and potentially, to the Item itself, like
> "dog pissed on it" or the more polite "used").
> /me coughs. You, in the back, wake up!
> Should FRBR Group 1 entities (the combined mega-Thing of Work,
> Expression, Manifestation, and Item; "WEMI") be a single document within
> CouchDB? Or should they each be their own document which somehow relates
> to all the others?
> Things like tags and identifiers (this books ISSN, DOI, ISBN, UPC, etc.)
> I can easily see as being part of the Self-Contained Data of a document.
> But I'm not sure if there should only be one JSON document called
> "Work", with it containing all the other major pieces of a creative
> endeavor, or if it should be four major documents (W, E, M, I) with
> relations to each other.
> I don't expect you to understand FRBR, fully I'm just trying to fit a
> design that was specifically made /for/ relationship databases into
> something that was specifically made /not for/ the relational approach.
> --
> Morbus Iff ( tomorrow never comes until it's too late )
> Technical:
> Enjoy: and
> aim: akaMorbus / skype: morbusiff / icq: 2927491 / morbus

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message