On Wed, December 8, 2010 12:08 pm, Karen Coyle wrote: > I'd love to see it. Everyone's FRBR implementation seems to be > different. Sometimes slightly different, sometimes wildly different. > Maybe you can put your schema someplace online that could be pointed to?
I had to go and open my big mouth. After searching my hard drives I came up with "http://www.passkeysoft.com/~lee/OpenCat.sql";. Looking at it, I can see that it is obviously incomplete; I suspect that much of the schema I wrote later on an ad-hoc basis. It will take some looking at the Java code and the database itself to flush it out (as in dogs flushing out the quail, not "flesh it out" as in giving it form and substance -- although there might be some of that required as well), but this first early draft might give a hint as to what I was trying to do. I think it is more useful to think of FRBR group 1 entities as IMEW rather than WEMI. It almost all cases, when cataloging we start with a copy of a book, a single physical artifact. We gather together all the attributes of that artifact, then we start categorizing those attributes according to their level of abstraction, through Manifestation, Expression and Work. Item is the least abstract of these levels, Work the most abstract. Every observation about our artifact, that typically is not shared with any other artifact (e.g. purchase date, locally assigned ID, shelving location, checked-out and to who) is collected as an attribute in the Item (FRBR Item) definition. Next we select those attributes that /are/ shared across multiple copies, and whose *values* are also shared across a significant number of those copies (e.g. publication date, publisher identification, number of pages, alternative tiles, etc.). These attributes can be removed from the Item definition and collected in a Manifestation definition; each collection (set?) of item attributes sharing common values for these attributes can be collected into a single Manifestation /instance/. Each Item instance which shares these common attribute values can now reference this single Manifestation instance rather than each Item record trying to carry around the duplicated data. We can now repeat this process recursively with the Manifestation instances we have recorded, although by now it must be admitted that we are well ensconced into the realm of subjectivity. No dogmatic assertions about what stays and what goes are allowed. We select those attributes which are shared across multiple Manifestation definitions, and whose *values* are also shared across a significant number of Manifestation /instances/ (e.g. Title, contributors names, the language it is written in, editorial notes, etc.). These attributes can be removed from the Manifestation definition and collected in an Expression definition. Each collection (set?) of Manifestation attributes sharing common values for these attributes can be collected into a single Expression /instance/; each Manifestation instance which shares these common attribute values can now reference this single Expression instance rather than each Manifestation record trying to carry around the duplicated data. (Note the clever use of copy and paste that implies recursion ;-) ). Could this process be extended to cover more than the four levels of abstraction encompassed by FRBR/IMEW? Probably. But IMEW is not too shallow, not too deep, and corresponds nicely with the kind of abstractions we humans are used to. I think it's just right. What I found interesting was what I found when I got to the Work level abstraction. Like Peer Gynt, after peeling back the layers of the onion I discoverd that the nugget of the Work is ... nothing. I think a "Work" is a useful abstraction. It is the glue of commonality that holds together related expressions. An author can be said to have created a "Work" implying that s/he is the creative fountainhead from whom all the expressions flow. A "Work" can be categorized by any number of subjects, and those categorizations flow down to every expression and manifestation and item that claim it as "their work." But when the "Work" abstraction is stripped to the bones, there are no bones there. "Works" really have no titles, a titles is an attribute of an expressions; every expression of a work may have a different title, or may have no title at all. "Authors" own "Works", not vice-versa. A "Work" is a useful abstraction, but it is fundamentally one defined by relationships and references, and not by attributes. The notion of a "Work" as a useful but undefinable abstraction is the foundation of my database schema, which I will discuss further in a subsequent post. _______________________________________________ Ol-tech mailing list [email protected] http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech To unsubscribe from this mailing list, send email to [email protected]
