众所周知，在BIBFRAME2.0模型中，书目资源为三层三个核心类（作品——实例——单件）。一般认为BF2的“作品”对应于《IFLA图书馆参考模型》（LRM）和《资源描述与检索》（RDA）的四层模型中的“作品+内容表达”，但实际上LRM/RDA的内容表达与作品间关系、作品与作品间关系，在BF2中难以区分，汇集LRM/RDA作品也是一个麻烦事。因此有“超级作品”之议。
前些日子看2019年欧洲BIBFRAME研讨会的报告（参见：2019欧洲BIBFRAME研讨会，2020-6-16），注意到多个报告中提到BIBFRAME在作品之上新增了Hub，对应Share-VDE中定义的超级作品SuperWork——如此几种模型就都是四层了。
不过，目前BIBFRAME词表（BIBFRAME Ontology）中并没有看到Hub类，在会议报告【以下报告三】示例中提到的LC的BIBFRAME扩展bflc中也没有找到，因而定义不明。
但是，在LC的关联数据服务（id.loc.gov）中，BIBFRAME的检索范围有三种：BIBFRAME Works、BIBFRAME Instances和BIBFRAME Hubs。搜索结果的侧栏分面，Scheme下有BIBFRAME Hubs，Type中也有Hub，可见在数据层面广泛应用此区分。
在结果一览中，“词表”栏取值有BIBFRAME Hubs，不过此时“概念”栏取值为Work而不是Hub。以查“Shakespeare, William”为例：
- Scheme分面（=命中数）：BIBFRAME Hubs=1413，BIBFRAME Works=7323
- Type分面（=命中数）：Hubs=1413，Works=8736
主要相关报告：
一、美国国会图书馆的RDA和BIBFRAME（RDA and BIBFRAME at the Library of Congress / Sally H. McCallum and Jodi Williamschen, Library of Congress）
报告人Sally H. McCallum是美国国会图书馆（LC）网络开发和MARC标准办公室（NDMSO）主任，该办公室负责BIBFRAME开发。这个报告不但未提及Hub，反而仍强调BF“灵活使用作品/内容表达”，即作品和内容表达合一，因为大多数资源是一次性的；处理多媒体、特别是唯一资源时作品/内容表达识别有问题。
二、Opus Ex Machina：在BIBFRAME中建模超级作品、作品和实例实体（Opus Ex Machina: Modelling SuperWork, Work, and Instance Entities in BIBFRAME / Ian Bigelow, University of Alberta）
报告人所在图书馆应当是参与Share-VDE相关工作。报告中用“Opus”（作品）作为书目资源顶层实体的名称，以避免“Work”的多义性：Opus = BF的Hub = Share-VDE的SuperWork = LRM/RDA的Work。据称2019年1月Share VDE数据中引入超级作品类，2019年ALA年会前LC引入Hub到他们的数据。
三、关于身份：针对事物，但不是简单事物（含Hub 第1部分）（Identities for hubs, providers, and other things / Kevin Ford）
四、考虑关系：Hub 第2部分（Hubs and managing relationships / Kevin Ford）
报告人Kevin Ford是LC的NDMSO开发人员，应该是BF数据处理的实际执行人。在两个报告中专门讲述Hub：
启用Hub理由：1、意识到在bf:Work上做得太多了；2、意识到对于题名/名称-题名检索点没有很好的解决方案；3、上述题名/名称-题名检索点都是空白节点；4、与SHARE-VDE和Casalini合作以及SuperWork概念。 MARC来源：规范1XX$t，规范130，书目1XX+240，书目130，书目600/610/611$t、630，书目700/710/711$t、730【难道BF作品不是由这些字段抽取的？如何区分“作品”和“Hub”？】 MARC来源说出其作用，Hub作为聚合器（aggregator）执行3个功能：主题、相关作品、RDA意义的作品。
报告出处：European BIBFRAME Workshop 2019. National Library of Sweden, Stockholm, September 17 and 18, 2019