Originally coming out of a discussion on Code4lib and RDA-L between me, Karen Coyle, and others (too many others). Response rewritten for this forum.
Please keep in mind that of the Work, Entity, Manifestation, Item entity model, it’s really only Item that is an actual physical thing. All the others are abstract things, that I continue to believe are most easily thought of as sets of the things “below” them.
In traditional library cataloging, Items of the same Manifestation are considered interchangeable for our patrons. This is why we generally do not catalog below the Manifestation level, at the Item level. On the other hand, in some circumstances for rare books catalogers, items of the same manifestation are NOT interchangeable for their users, and this is why (I am led to believe) rare books catalogers sometimes DO catalog at the Item level).
Compare to an Amazon book page. When you look at an Amazon web page for “a book”, they REALLY mean they have dozens, hundreds or thousands of actual physical books in some warehouses somewhere they can sell you. But there isn’t a page for each Item, Amazon too considers items of the same manifestation generally interchangeable for it’s users, you don’t generally get to pick WHICH Item sitting in a warehouse you get. The typical Amazon page basically represents a Manifestation, as the typical traditional library catalog page does.
(But if you ordered a book on Amazon and they sent you the book translated in a different language, or in digital form on an Apple II 5.25″ floppy disk, or in the 1986 first edition when you ordered the 2009 fifth — you’d be pissed! All those things might be in the same Work or Expression, but for Amazon customers and for library users, Items from the same Work or Expression are not neccesarily interchangeable.)
So you can kind of get away with considering a Manifestation to be a real thing and talking about something “being” a manifestation, but it’s always good to remember that even a Manifestation is really an abstract set composed of a bunch of items.
But if you start thinking that an item in your hand can “be” a Work or Expression without “being” a Manifestation (and item!) too, you are setting yourself up for a lot of confusion. You can’t have a Work or Expression (or, technically Manifestation), without having all the things below it, up to Item.
Okay, so maybe there ARE a few edge case exceptions. Someone in a listserv conversation once suggested that if there’s a movie that is in pre-production, but nothing’s been filmed yet, maybe even a script hasn’t been written yet, maybe that Work exists, even though no Expressions, Manifestations, or Items of it do yet. Maybe an IMDB page for a pre-production movie represents a Work for which there are no E M or I. Could be useful to model things that way, sure, why not. But bear in mind that even in that weird case, you don’t have any item in your hand! The movie that hasn’t been made yet is a purely conceptual non-physical thing, so okay maybe it’s “just” a Work. As soon as you have something in your hands (a script, a daily DVD), you’ve got an Item. Which belongs to a Manifestation set, which belongs to an Expression set, which belongs to a Work Set.
That’s the way the FRBR WEMI entity model is intended, and that’s the only useful way I can figure out to think about it. If you forget this in your modelling, I think you wind up with poorly modelled unuseful data.
In a conversation with Karen Coyle on the lists, I think perhaps she was forgetting or getting confused about this, and in the process accurately recognizing that if you DO get confused about this, you wind up with data that’s tricky to use and reconcile and merge with other data.My response edited for this forum.
Karen Coyle wrote:
I think this becomes a question of how we express WEMI — you can always link from/to any WEMI using “contains” or “contained in” — so you can always link to all of the Works in an aggregate. What I would like to achieve is for different decisions (like one community calling the aggregate a Work/Expression and another focusing on the individual works and linking those to a Manifestation) to not create incompatible data.
Keep in mind that EVERY item-in-hand MUST be a Manifestation. At least this is my interpretation of FRBR.
If you have a bound volume that’s an “aggregate”, it HAS to be a manifestation. (as I argued above in this blog post)
So there’s no way to “call an aggregate a Work/Expression” instead of a manifestation, if that aggregate is an actual physical item in your hand.
You’ve got a manifestation whether you like it or not. The question is how much “authority work” are you going to do on identifying the Expression and Work it belongs to. If you don’t do much because it doesn’t make sense for you to do so, maybe it starts out modelled as a manifestation just belonging to a “dummy” Expression/Work that contains only that Manifestation. Some other cataloger somewhere else does the “authority” work to flesh out an Expression and/or Work that maybe contains multiple manifestations or maybe doesn’t. Is your data incompatible? Not really, it can be merged simply by recognizing that your “dummy” Expression/Work can be merged into their more fleshed out one.
There’s also a question of how much “authority work” you want to do on the _contents_ of the aggregate. Maybe you don’t want to spend any time on that “analytical” task at all, and your record does not reveal that the item in your hand IS an aggregate, it does not actually expose relationships to the other Works/Expressions contained within. It might have a transcribed table of contents as an attribute only, not as a relationship to other entities. Later some other cataloger fleshes that out. Here too, that other catalogers extra work can be (conceptually at least) easily “merged in” to your record, there is no incompatibility.
[If two different catalogers/communities decide that two different Works contain _different_ manifestations, and violently disagree, then THAT’s an incompatibility that’s harder to resolve and is a legitimate concern. But that’s not what we have in this example, which is quite straightforward.]
I’ve had this ill-formed notion for a while that we shouldn’t actually be creating WEMI as “things” — that to do so locks us into a record model and we get right back into some of the problems that we have today in terms of exchanging records with anyone who doesn’t do things exactly our way. WEMI to me should be relationships, not structures. If one community wants to gather them together for a particular display, that shouldn’t require that their data only express that structure. I’m not sure FRBR supports this.
sound vague? it is — I wish I could provide something more concrete, but that’s what I’m struggling with.
While to some extent I sympathize with your inchoate thoughts about modelling WEMI being a mistake, and we’ve talked about that before — ultimately I still disagree. It is appropriate to use an entity-relation-attribute model to come up with the kind of explicit and formal model of our data that we both agree we need. It’s a conventional, mature, and well-tested modelling approach (I wouldn’t want to pin all our eggs to RDF experimentation that at least arguably does not rely on an entity model).
You can’t have an entity model without entities. The FRBR WMI (and more debatably E) entities are the ones that clearly come out of a formalization of our 100 year tradition of cataloging, meaning there’s probably something to them AND that using them makes retroactively applying the model to our 100 years worth of legacy data is more feasible (and BOTH of those facts are totally legitimate grounds for decision making. And the decision has already been made too, although in the case of FRAD I’d still be reluctant to accept it as a “done deal”, but in the case of FRBR, it is much better done, a much more useful and accurate abstraction of our cataloging tradition).
But you’re right that neither Work, Expression or Manifestation are “things” if you mean physical things. They are abstract things, they are sets of physical things, that it is useful for us to model so we can say things about them (including but not limited to which physical things are a member of them). It’s often useful to say things about things that aren’t physical things you can hold in your hand too.
If ALL you have are assertions about Manifestations (or worse Items!), then you’re going to end up duplicating a lot of assertions (see, I’m avoiding talking about records!) to assert something about every manifestation that belongs to the same Work, when your assertion is REALLY about the Work. A certain movie is a film adaptation of a certain work. Do you really need to make a bunch of RDF triples asserting that it’s a film adaptation of EVERY manifestation (or every single Item, every copy on someone’s shelves!) that exists of that Work? No, and it’s not even true, it’s not neccesarily an adaptation of any particular edition/manifestation (or if it is, you might know which one), it’s an adaptation of the Work.
We model the Work as an entity so we can make assertions about it, whether in records or in free-floating RDF assertion fantasy land. We can assert once that a film is an adaptation of a work, and we can assert that a bunch of manifestations/editions are all manifestations of that work (belong to that work-set), and then we can know that all of those Manifestations belong to the Work that was adapted into that film.