FRBR作为一个概念模型，用以指导实践，出现了如题所示的新名词――FRBR化（Google目前搜索结果：FRBRize，动词112项；FRBRizing，动名词182项；FRBRization，名词183项）。
定义？“FRBR化”还是个非正式的称呼。OCLC如是说：
examine the issues associated with the conversion of a set of bibliographic records to conform to FRBR requirements.
This process sometimes is informally referred to as “FRBRization”. （转换书目记录集以符合FRBR需求的过程）
RLG（美国研究图书馆集团）的“红绿灯”RedLightGreen，可以说是最早实用的FRBR化大型WEB书目数据库。通过将FRBR的“作品――内容表达――载体表现――个别资料”四级实体简化为二级“作品――版本（载体表现）”，RLG把自己的联合目录放到了互联网上。在搜索结果显示页面，显示的是作品，而非一般OPAC的“载体表现”。对大部分用户，感兴趣的是作品而非某一个版本；如果只对某一版本感兴趣，再继续看相关版本不迟。对于高产作家的作品，此种显示方式尤能显示出其优点（请参见“红绿灯RedLightGreen”及“FRBR影响之OPAC应用”）。
从RLG及LC、OCLC等的FRBR化成果看，以“作品”这一实体集中书目记录，可以说是FRBR化的一种基本形式。但这一方式，在我国实施起来似乎还麻烦多多。试分析原因：
一、文献原题名的著录问题
MARC 21记录普遍采用原题名作统一题名，为作品的集中创造了良好的条件。而中文编目中并没有规则要求以原题名作统一题名，目前CNMARC一般将“在编文献中出现的”原题名著录于510并列题名中。
并列题名并不一定是原题名，还包括自译题名。有些译著，并列题名与原题名并不一致。此时，或者做二个并列题名，或者著录时根本就省略了原题名，这就为集中同一文献留下隐患。
《新版中国机读目录格式使用手册》中有个实例，在编图书《来自地狱的女人》为“If tomorrow comes”的某个译本，统一题名采用另一个译名《假如明天来临》，而非原题名（此书还有一译名《假若明天来临》）。如此一来，没有题名规范记录即无法著录统一题名，增加了问题的复杂程度。
原题名可以不著录，而要著录另一个被选为“统一题名”的译名。是不是有些奇怪？于是“统一题名”的选择面对疑惑：为什么选这个译名而不选另一个译名？
这种做法还增加了统一题名维护的工作量，每出版一个不同题名的译本，就要维护一下题名规范记录。
直接用原名不好吗？为什么要自己累自己呢？
另外，图书出版不规范，有意无意“省略”原题名的情况随处可见。从另一方面为实施原文统一题名增加了不小的难度。
记得一次用MARC 21做某中文译著合集的记录，费了九牛二虎之力才找齐全部原题名。虽然很有成就感，毕竟只能当作消遣，如果当工作来做，死路一条。
二、名称规范问题
要确认是否同一作品，单靠题名显然是不够的，还需要责任者名称。中文编目中人名规范不普及，编目中缺乏足以信赖的名称规范档，责任者名称经常照录图书题名页。图书翻译、出版中各译各名的现象本就普遍，于是，同一作者各种译法，五花八门。
有了规范意识后，又存在盲目依据人名翻译辞典的现象，有时就把有名的作者“规范”成了无人知晓的责任者名称。
与题名一样，翻译图书还经常不提供原作者名称，造成名称规范工作有心无力。
三、不同语种名称标目形式不同问题
这或许是集中不同语种同一作品的最大障碍。
“红绿灯”的做法是全部使用拉丁字母，对于非拉丁语名称（题名与责任者）采用音译，如中文图书用汉语拼音。这当然是计算机技术发展早期无法处理其它语种字符时留下的后遗症，虽然现在“红绿灯”已将字符集转换为Unicode，原来已经编目的文献是无法逐一更改的了。韦氏音标可以用计算机批量改成汉语拼音，要由拼音改成汉字则是不可能的。
我们自然不会全部用拼音。但因为用户不习惯用作者原名查，或者根本不知道作者原名拼写，我们反其道而行之，将作者原名全部音译成汉字。
不过，既然同名异译现象如此普遍，使用名称规范档已不可避免。那么，我们何不在书目记录中直接使用原名？而通过名称规范将读者输入的汉译名导向书目记录？
日本对作者标目即采用原文。以“If tomorrow comes”为例，NII（国立情报学研究所）的WebCat中某日文译本“明日があるなら”，作者标目为“Sheldon, Sidney”，而非题名页中的“シドニィ?シェルダン”。
目前CALIS设计的名称规范库是各语种统一的，对同一作者不同语种记录间的连接无疑是十分有益的。但同一责任者采用不同标目形式的通行做法，在进行数据处理时，无疑为集中同一作品（哪怕是OPAC显示）增加了相当大的困难。
四、书目数据库、MARC格式、CNMARC/XML转换表
Last but not least，在我国，常见的情况是中西文（或者还有日文、俄文等等）书目数据库各自独立，还采用不同的机读目录格式。各语种书目数据库分列，对于依“作品”集中所有语种书目记录的不便显而易见。不同的MARC格式，又增加了问题的复杂性。
这种状况不是著录问题，不是修改一下编目条例/著录规则、机读目录手册就可以得到改善的。基本上可以说其本身是不会改变的，只能信赖外部技术。
就现在来看，通过为不同MARC类型分别定义索引字段的方式，一些图书馆自动化系统已经较好地解决了不同MARC格式书目记录合库问题。现在需要解决的主要问题就是不同数据库各自独立的问题。
只能寄希望于跨库检索技术的发展。集中同一作品的问题不是简单的重复结果去重，首先需要判定出各库中的同一作品，然后再对所有检索结果重新组合显示。
不过，如果采用“红绿灯”的方式――他们实际上是将所有记录重新转换成XML格式――那么一个库还是多个库的问题就不存在了。
我们需要做的，是建立一个CNMARC到XML的转换表，与LC已有的MARC/XML转换表（MARCXML: MARC 21 XML Schema）一起使用，一举解决多库、多MARC问题。
参见本人FRBR相关博客文章：
红绿灯RedLightGreen （2005年02月28日）
FRBR影响之OPAC应用 （2005年05月10日）
书目记录四种实体的汉译 （2005年05月20日）
FRBR博客 （2005年06月30日）