标签： 关联数据

上海图书馆夏MM的国家社科基金课题，结合上图的关联数据项目，基本上每周一次相关专题分享与研讨。参与者来自多个机构，看着他们不断前进的步伐，很羡慕那种氛围。
本周他们讨论URI规则等，是我感兴趣的主题。正巧昨天开始正式放暑假，于是今天在37度的烧烤模式下，去上图蹭听学习。感谢他们的接纳。
首先由许磊主讲《URI设计原则》，从爱尔兰国立大学两位研究员对URI类型及设计模式等的研究开始，以所述URI类型，分析各国图书馆界关联数据和政府开放数据的URI模式。
三十分钟报告结束，进入讨论阶段，夏MM主持探讨前已发布的家谱系统URI是否需要更改，哪些需要改。Keven并进一步提出上图的URI政策问题，为今后更多项目做准备。尽管现场没有定论，但确定会后据此提出方案。至此不过四十五分钟，真是相当务实高效的会议。

今天的报告让我对URI类型和模式有了比较清晰的认识，至少区分Thing、Concept、Resource和Onto四种URI是我比较明白的，Hierarchical URI也可理解，Representation URI就不明所以了。期待许磊写出文章。

———-小河尘的分割线———-
许磊在书社会发了不少博文，主要涉及编目与关联数据。关于MARC、RDA、FRBR、BIBFRAME等等的学习笔记，信息量相当大。比如BIBFRAME方面有：
【学习笔记】BF规范（2015-06-07）
Bibflow简介（2015-05-08）
[学习笔记]RDA注册元素与BF属性–题名篇（2014-08-29）
[续]catwizard老师的博文–Bibframe.org的类与属性发布（2014-04-30）[此文刚才查时才发现，估计一年多前还没加上书社会好友，因此先前没注意到]

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