couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morbus Iff <>
Subject Re: Defining my document model when the source is entity-relationship
Date Fri, 10 Jul 2009 12:40:41 GMT
>>> I think it might be useful to go with your first instincts, that a   
>>> book is a document, and then see how to best organize the  
>>> information  you have about the book in support of some  
>>> application, rather than
>> But, in the FRBR model, the "book" (FRBR's "Manifestation") is not  
>> the "final" or "complete" document (CouchDB's "document"). Were I to  
>> strictly map "the book is a document", the CouchDB document would be  
> actually I'm not talking about "The Hobbit" as a concept, a class of  
> individuals comprising all the books, CDs, YouTube videos, etc., I was  
> referring to the "The Hobbit", the green volume sitting on my shelf  
> with an n-bit address in the universe that my dog chewed.

Ok, so, if we establish that:

  * I /do/ want to use the FRBR model of W, E, M, I. That's the goal,
    not "making a book database for some moving book customer"...

  * ... and you were talking about a "book as [CouchDB]
    document" as a copy of your "The Hobbit" on the shelf...

then that leaves me with an inferred statement of:

  * Make a CouchDB document model an FRBR Item.

which further asserts that the other Group 1 entities of FRBR (W, E, M, 
which again is what /I/ want, not a generic book database that we've 
seen a thousand times before) should also be modeled as specific CouchDB 

Is that right?

> business, she specializes in moving books. In her schema all that's  
> needed is height, width, depth, and weight. All this "Work",  
> "Manifestation", ISBN-code stuff is just fluff.

Sure, but I assert (again, though I ended up deleting it from the 
previous e-mail just prior to sending it) that this is a usability 
problem, not a data model problem. Even the FRBR stuff states, somewhere 
somehow, that the model isn't usable (or necessary) for "normal" people. 
  In my view, she'd never even see, or need to know, the concepts of 
WEMI in her using the app. IO would be friendly, regardless of the model.

> One way to view documents is to consider them like rows in a table  
> where you can have as many columns as you like.

Which also supports the "make each Group 1
entity a CouchDB document type" assertion?

Enjoy: and
aim: akaMorbus / skype: morbusiff / icq: 2927491 / morbus

View raw message