[open-bibliography] Is FRBR too complicated?

Rufus Pollock rufus.pollock at okfn.org
Mon May 24 08:41:42 UTC 2010


On 24 May 2010 01:39, Karen Coyle <kcoyle at kcoyle.net> wrote:
> Quoting William Waites <william.waites at okfn.org>:
>
>> ... is a conceptual model trying to make information retrieval
>> efficient
>>
>> ... presupposes a high level of understading of the model to
>> perform information storage
>>
>> ... it's not a simple model
>
> William, I'm about to do another blog post on FRBR about reusability, but
> what it comes down to for me is that the Group1 entities are really a single
> entity with subparts. I have only minor quibbles with Groups 2 & 3. The main
> problem with Group 1 is that the entities are interdependent and cannot
> exist without each other, which to me makes them "not-entities" but parts of
> some whole. You have to keep in mind that the folks who developed FRBR have

I couldn't agree with you more Karen! I've not got a biblio background
but I have been working with bibliographic data pretty heavily over
the last couple of years (see
<http://www.rufuspollock.org/tags/eupd/>)

I've been trying to understand / implement FRBR and have constantly
felt the domain model here is poorly thought out especially in now it
relates to non-book media (e.g. recordings). As a concrete example:
still can't work out where you distinguish a "work" from an
"expression" -- e.g. is this new translation of Shakespeare's Hamlet
into French a new expression or a new work and how to I associate it
to Shakespeare's Hamlet work/expression ...)

> no experience with data definition and thought they were creating something
> designed for a relational database (but I have proof that most of them have
> never created a database of any kind in real life). Keeping in mind that
> FRBR is a conceptual model (and possibly not a great one), we should feel
> free to make it work better rather than follow it slavishly. Which is why I
> would prefer to not make any reference to FRBR in the UI, but to make use of
> it in the background if it turns out to make sense to do so.

My feeling is that FRBR has confused associative relationships (e.g.
derived from) with a hierarchy (inclusion/subpart) structure -- the
classic example is indicating derived relationships, say between a
translation and the original which I think should be an explicit
"derived-from" relationship rather than getting shoe-horned into an
expression-work type setup as it seems to be (though pardon me if i
have misunderstood).

For me, the core useful part of FRBR (at least as compared to what
seems to happen in most current catalogues) is the distinction between
a

  * "work (/expression)": the artefact in abstract semi-platonic form)
  * "manifestation (/item)": something concrete e.g. book with an isbn
/ a (set) of recordings on a CD etc (of course it is useful to
distinguish, as FRBR does, between the individual item and the set of
all such items e.g. the print-run as represented by the ISBN).

Thus, I'd like to see FRBR pared back to a Work-Manifestation core
(perhaps with Item as an extra) together with a good set of properties
to express relationships between works e.g.:

  * is-derived-from (with subclasses such as translation, performance-of etc)
    * I note most of these properties are in something like
http://vocab.org/frbr/core.html but generally attached to
expression-work relation not work-work relation
  * is-part-of (for series, sets etc etc)

Some stripped down examples of trying to apply FRBR from my experience
can be found here: <http://wiki.okfn.org/p/Bibliographica/FRBR>

Regards,

Rufus

PS: I would also that this distinction would work well for a mapping
to copyright/public domain considerations (central to the EUPD project
I worked on): a Work would be something accruing a new copyright (I'm
ignoring "print-setting" copyright here). For more on the gory details
of doing PD status computation using FRBR-type concepts see:
<http://www.rufuspollock.org/2009/03/12/computing-copyright-or-public-domain-status-of-cultural-works/>




More information about the open-bibliography mailing list