In the past, ELAG workshops focused mainly on the very structure of the FRBR model: should it have two more entities in the group 1 (a "top hat entity" and a "performance entity"), should it be transformed into an object-oriented model, etc. These were very interesting and necessary topics, but insofar as the model "belongs" to IFLA, we should hand over our suggestions to this organisation which, in turn, ought to evaluate them, to accept or reject them, and to assess all other similar proposals from professionals all over the world — in one word: to ensure maintenance and evolution of the model.

It is now time to focus on implementation issues. FRBR is an abstract model and what we need in order to promote it is to show concrete data and practical results. It is therefore proposed to address the following topics:

Of course, the multiplication of entities (instead of just one record) and of links is the readiest answer, but we have to discuss whether other aspects of cataloguers’ activity and of OPAC features are not concerned as well.

According to FRBR, the (computer) catalog is not seen as a sequence of bibliographic records and as a replica of the traditional catalog, but rather as a network of interconnected data, enabling the user to perform seamlessly all the necessary functions. Therefore we have to investigate how this network is created and how on the other side the user will navigate within this network. In what ways does the introduction of abstract entities (work, expression) and (above all) relationships influence cataloging and the catalog?

In what ways can the obvious advantages of FRBR be realized in future systems?

We have to be aware that vendors are already developing systems following FRBR. If we have conceptual problems with the model, we can assume it is even worse for them. Therefore it is our responsibility to at least attempt at a specification and some guidelines.

Catalogues do exist, and in the past we already had to define requirements for retrospective conversions. But in this case it seems particularly tricky: we have to "split" compact, "flat" records, into distinct records reflecting each FRBR entity. It is well known that it is always easier to merge data than to split them. And what will become of our traditional formats? Is XML to supersede MARC?

Cataloguers’ training is also a critical issue: it is well known too that nothing is more difficult than to change one’s working routine, and professionals have to become familiar with the model as soon as possible and in the possibly best conditions.

The same can be said about users. OPACs must be designed in a way that allows them at the same time to remain as "user-friendly" (and even friendlier, if possible) as they are, and to take advantage of all the huge potential benefits we expect from such a precise and intellectually accurate model as FRBR is. How to do it in a smooth way?