最近BIBFRAME邮件组的讨论热点之一是“RDF双属性”（RDF dual properties），3月份时另一个话题“BIBFRAME和RDA/RDF”（BIBFRAME and RDA/RDF）也涉及这个问题——不只是BIBFRAME存在这个问题，RDA/RDF也同样存在。缘由是：
RDF三元组有二种基本形式：
主体（URI）-属性（URI）-客体（URI）
主体（URI）-属性（URI）-客体（文字）
以题名（属性）为例，客体可能是文字（比如“红楼梦”），也可能是资源URI（比如对应《红楼梦》题名规范记录的URI）。对机器来说，URI和文字的处理方式是不同的，这就引出了是否要为这两类客体设计2个不同属性的问题。
目前来讲还没有答案——尽管从讨论看，个人感觉最终采用单属性的可能性比较大。
– 本次话题由LC的Ray Denenberg（LC的W3C代表）提出，向大家征求意见。
他称LC正在改进BIBFRAME词表，其中一个关键问题就是：是否应该定义“双属性”，以“题名”为例，有2个选项：
(a) 单属性：bf:title，可以取文字或资源
(b) 双属性：bf:titleLiteral和bf:title（或者bf:title和bf:titleResource），各取所需
LC内部的争论一：选项(a)给客户端增加确定客体类型的负担，选项(b)则加重（词表）的复杂性。争论二：是否要优化推理本体：如果是的，则需双属性；如果不是，则应当避免双属性增加的复杂性。
Denenberg以近来W3C在“Web注释”上的争论为此做注：该模型的第一个草稿为每个注释体定义双属性hasBody和hasBodyLiteral。争论的结果是在最近草案模型中改为单属性hasBody。他认为大家并不想为推理优化BIBFRAME词表，因此会建议方法(a)。
参见：Web Annotation Data Model (W3C First Public Working Draft 11 December 2014)
– 斯坦福大学的Robert Sanderson提出了第3个选项（经修正）：
(c) 总是用资源，同时允许非常简单地包装为一个字符串
_:work bf:hasTitle [ rdfs:label “题名” ]
讨论中，此法被认为会产生空节点、造成处理上的问题，且会引入标记上的复杂性（什么时候要加方括号），参与讨论者多未认可。
– OCLC的Richard Wallis（schema.org图书馆扩展负责人）态度鲜明：采用(b)会导致术语太多，增加提问、维护和培训的复杂性；(a)显而易见。他以schema.org说明，所有属性默认为字符串，“如果有资源URI则使用，没有则接受字符串”。Wallis同时还以词表使用模式角度，分析4种场景分析，此视角得到Karen Coyle认同。
– Karen Coyle提出了一些原则性的想法，摘译如下：
“我喜欢Richard的功能分析。与其在真空中决定，我认为更值得看实际运作及其影响。我还想确信不是开发一个基于遗产数据的方法论，而是推动遗产数据向前，接近我们想要去的地方。很多数据起着多重作用：检索、显示和标识符，很容易忘记某些看似简单如题名，实际上同时起着所有这些作用。它是显示的标签，识别书目项的重要部分，题名页的文本转录，字顺检索点，排列机制，等等等等，集于一身。我们需要基于功能性把其中一些弄走？”
在3月的讨论中Coyle对RDA/RDF没有规定属性值是字符串还是标识符持否定态度，认为当与RDF数据共用时相当有问题。她提出的解决方案是“创建规则的子集”，为每个属性明确定义数据值。
【以我的理解，如果对应到本次讨论，就是词表采用(a)，同时实际使用中通过如profile规定采用文字还是URI】
– OCLC的Jeff Young提供了SKOS扩展标签的链接，指出情况与此类似：
SKOS Simple Knowledge Organization System: Reference (W3C Recommendation 18 August 2009)
去看了一下，SKOS的扩展标签(SKOS-XL)为标签类定义了两种不同属性：
skosxl:Label类的说明是：……实例可以是资源，以URI命名（有skosxl:prefLabel, skosxl:altLabel 和skosxl:hiddenLabel三个属性）
同时又说明……实例有文字形式，采用属性skosxl:literalForm，纯文字：“如果该类两个实例有相同文本形式，不一定是相同资源”
这是2009年的规范，相对2014年的Web Annotation，或许年代久了点？