Allen, Faceted Classification and FRBR
Last month I saw a demonstration of Siderean‘s Seamark Navigator, which they call a “relational navigation server” but which you can think of as a sort of RDF search engine. It looked pretty impressive, believe me.
Bradley Allen is the Chief Technology Officer at Siderean, and he was doing some of the demo. There were a couple of questions about FRBR and he gave informed answers. One thing he said really caught my attention and set me to tugging thoughtfully on my beard. He said:
work + facets = expressions = manifestations + tags
By facets he means not the facets that come from a faceted classification system, but the kinds easily divined from MARC records: year of publication, call number range, format (book, music, video, map), language, subject headings, etc.
Last Wednesday in a blog post titled Faceted Classification and FRBR he talks about this after redefining the Group 1 entities!
- An item is a unique physical embodiment of a work (i.e., a singleton set).
- A work is a set of items with the same intellectual content.
- An expression is a set of items with the same realization of intellectual content.
- A manifestation is a set of items with the same production history.
This set of definitions allows us to shift the burden of effort in creating a FRBRized catalog from defining specific entities of the four classes with explicit relationships from one level to the other (which, I believe is the assumed work process) to simple entry of values for facets associated with production, realization and intellectual property metadata on a per-item basis.
I think those set based definitions of the FRBR entities (ala Elaine Svenonius; give credit where credit is due) are exactly right.
However, I think the two definitions (set-based, and entity-based) need to be thought of as inter-changeable.
The FRBR model is not meant to specify the _implementation_. The FRBR model as it’s written _now_ should NOT get in the way of “creating a FRBRized catalog from defining specific entities of the four classes with explicit relationships from one level to the other (which, I believe is the assumed work process) to simple entry of values for facets associated with production, realization and intellectual property metadata on a per-item basis.” You should not take the model to mean that your implementation _has_ to have actual records for each FRBR entity.
Still, I think being explicit about the validity of the set-theoretical understanding in the FRBR model documents would make this point clear, and also aid in the understanding of the FRBR model in general. I find the set-theoretical way of talking about the entities to be easier to understand, myself.
As long as we are talking about implementation though, if you _don’t_ have any records anywhere to represent, say, the Work entity… then where do you store data that applies to the Work as a whole? Right now, we have a bunch of manifestation records only, and data that applies to the Work record as a whole is duplicated accross all of them (and it better all be identical and without typos–if it’s really meant to apply to the work as a whole!). When dealing with legacy data, that’s Just The Way It Is, and your systems need to deal with it, true. But are you really proposing that this is a desirable way to keep moving forward to? It creates lots of problems, as I know you are aware.
Comment by Jonathan Rochkind — 10 September 2007 @ 12:27 pmJonathan- Good to see that you agree with some of the points I made in the post that William’s linked to here; I’d like to note, however, that if you read the original posting, I explicitly credit Svenonius and link directly to the relevant passage in the Google Books scan of “Intellectual Foundations.”
The question about where the data is that applies to the Work as a whole is an interesting one. In the approach I’m describing, that data is generated on the fly at query time out of the index of Item metadata. In general, faceted navigation engines construct an aggregated description of a set of results for a query; if the query against a set of Items is phrased in terms of ideational facets (e.g., subject or other access-point-valued attributes), then the user query plus the (potential noisy) aggregate description is a description of a Work. Correspondingly, further refinement of such a query by additionally filtering in terms of production facets (e.g. publisher and publication date and location) would lead to a description of a Manifestation of a given Work.
These generated descriptions can be saved out to a database, in the same manner that people can save searches in traditional systems. The point I’m making is that this provides a more scalable alternative to that of creating Works and Expressions out of whole cloth. Making Works and Expressions interactively discoverable out of the existing Manifestation data, rather than forcing machines and/or catalogers to do additional heavy lifting is the goal.
I’m going to work some examples and post them on my blog in the next few days.
Comment by Bradley P. Allen — 11 September 2007 @ 6:06 pm