[A long time ago I insisted to Tim that what he was doing _was_ FRBR, even though he wasn’t doing it exactly like other people trying FRBR, because FRBR left enough things ambiguous and up in the air that it can accomodate multiple decisions about when something is or isn’t the same work, is or isn’t the same expression, etc. I still think that what LT is doing is an implementation of FRBR].
I think what LibraryThing calls “editions” is actually pretty much what FRBR calls “manifestations”. No problem that LT is using a different term in it’s UI — but might be helpful to remember that when looking at interoperability with other peoples data. Which is the real promise of the FRBR model, clearly modelling our domain such that we can explain what we’re talking about to other systems.
With expressions, editions/manifestations, and works…. indeed LT might become the most full implementation of FRBR out there, as Tim suggests.
Which is perhaps ironic because I’m pretty sure LT/Tim don’t care at all about implementing FRBR for the sake of FRBR,or for the sake of ‘standards’. LT is implementing what makes sense to meet their user’s needs. [Which is perhaps why initially Tim was resistant to accepting that he was ‘doing FRBR’ at all].
But nevertheless they’ve still arrived at the need for an Expression entity much like FRBR’s.
I think that actually provides some strong evidence that the FRBR model is actually pretty good, yes even including that pesky “Expression” entity that people find it inconvenient to use. Certainly if it’s too inconvenient to use in a given system (with ‘system’ including the aggregate cooperative cataloging infrastructure), compared to the benefits it brings, then, sure, you don’t have to use it. You don’t have to do anything. But I think LT’s analysis arriving at the need for an Expression entity in order to do certain things for users, is validating for the FRBR model.