文字或是字符串:RDF双属性?

最近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,或许年代久了点?