URI、URL和URN,标识符体系和命名空间

11月初BIBFRAME 2.0草案在邮件组提出,很奇怪地安静了一周,接下来一周忽然就吵得昏天黑地。特别是针对单件,有各种讨论,其中一个涉及URL。
开始的引发问题是为什么在2.0中URL作为文字(而不是标识符)。期间RSC主席Gordon Dunsire插上一脚,介绍RDA有关URL和URI讨论,基本结论是:“URI是一个thing(RDF资源),URL是一个字符串(非可解析标识符)”。对此结论,多位表示不赞同。
Karen Coyle认为URL就是URI。并且“如果你有一个URL,你不能知道它是非可解析的,直到你试着解析它……你可以自己决定你不希望解析某些构造良好的URI,把它们当成字符串,但把这些称为URL似乎不正确。”
LC的Ray Denenberg直截了当地表示,“把URL当作一个非可解析标识符是严重的错误。”在为LC编目员编写的BF的RDF简单入门中,他指出,两者“没有在解释上有任何价值的实质性区别,因此假定它们是相同的。”
OCLC的Jeff Young提供了一份W3C Note,称有助于理解URL和URI的区别。
面对质疑,Dunsire的解释是:anyone can say anything about any thing. RDA认为URL是远程访问资源的地址,这里“资源”指RDA/FRBR实体载体表现。在承认URL不是不可解析后,举例说明如果把URL处理为URI,将形成同义反复。
他的解释很长,但显然没有说服其他人。
对我来说,重要的还是仔细看看Young提供的文件。

——— URI、URL和URN:澄清和建议 ———
URIs, URLs, and URNs: Clarifications and Recommendations 1.0 / Report from the joint W3C/IETF URI Planning Interest GroupW3C, Note 21 September 2001

关于URI:
– 传统视角(1990年代中期),认为标识符(URI)可以指定资源的位置(URL)或资源的名称(URN),因此URI是URL或者URN,还可能是URC(指向资源的元数据即引用)。
– 当代视角(此文件所处的2001年),只有一个通用的URI体系,http:和urn:都是URI体系。urn:定义的URI体系子空间即命名空间,http URI即是URL。
– 附加URI(未在文中考虑的):
— 使用URI作为标识符,不标识网络资源,而是标识抽象对象(概念)或者物理对象(一本书甚至一个人)【关联数据世界中的thing?】
— 国际资源标识符IRI:URI语法扩展到非ASCII字符【2001年就考虑到了】

关于注册:
在2001年,就已有了IANA(Internet Assigned Numbers Authority)负责维护的两个标识符体系注册,目前仍在更新:
Uniform Resource Identifier (URI) Schemes
Last Updated 2015-11-25(当年有30个;目前约300个,如ftp, http, feed, tv, z39.50)
Uniform Resource Names (URN) Namespaces
Last Updated 2015-10-19(当年有8个,包括issn;目前有约60个,包括isbn)

文中提到未注册的命名空间如hdl:有猜测指该体系未注册,是因为拥有者不清楚应该注册为URI体系还是URN命名空间
确实,我也不知道这两种注册的本质区别是什么。
目前很多著名的命名空间都没有注册,只在应用中声明。

OAI-ORE《对象重用与交换》笔记

《对象重用与交换》(OAI-ORE),此标准的名称说明了目的或功用,但“对象”指什么?这个“对象”,当指资源及其组合,在OAI-ORE中称为“聚合”(aggregations)。
“我们使用多页Web文档首页的URI来标识整个文档,我们使用HTML页面的URI提供访问一个Flickr集以识别整个图像集。但这些URI实际上只是识别这些特定页面,不是构成整个文档的页面联合,或者识别在一个Flickr聚合中所有图像的联合。本质上,此问题是,没有标准途径去描述聚合的成分或边界,这正是OAI-ORE致力于提供的。”——ORE User Guide – Primer

OAI-ORE目前为1.0版,用户指南文件包括入门、抽象模型、词表、序列化格式等:
Open Archives Initiative Object Reuse and Exchange (OAI-ORE) (version 1.0, 17 October 2008)

概要:
在Web中,“资源”指代感兴趣的任何项目,聚合则指资源的某种组合。
OAI-ORE基于语义网,以RDF图(三元组)描述Web资源的聚合。
OAI-ORE使用资源地图(Resource Map)描述聚合的成分或边界,揭示聚合本身及与被聚合资源间关系,并可选用代理(Proxy)指明被聚合资源。
OAI-ORE标准可用于网络爬虫、网络计量研究、数据交换与交互、数据重用与重构等,供机读使用。

ORE模型中关键实体间关系UML图

———- ORE Specification – Abstract Data Model 抽象数据模型 ———-

聚合特征
– 资源可能在一个服务器上,也可能分布在Web上;
– 资源间关系各异,如包含、替代等;
– 资源类型可能不同,甚至由不同词表定义,如书目、目次等;
– 资源与外部资源间关系各异,如引文、镜像、译文等。

聚合举例
– 相同类型、不同项目:收藏图片集,来自不同网站;多页HTML文档,以“前页”、“后页”链接;
– 相同项目、不同格式:Flickr上的照片,有多个尺寸与分辨率的图像,另有评论等;学术出版物,以过渡页(splash page)形式存储在arXiv等中,链接到多种格式全文,另有引文链接等;
– 不同类型资源组合:研究成果集,由成果、数据、可视化分析工具组成;
– 有层次的资源组合如:叠加期刊(overlay journal),文章组合为期、期组合为卷、卷组合为期刊。

5.3代理(Proxy)【这个没完全弄明白,尤其是第3个】
特定于聚合环境的关系(非全域/全局关系,即不是在所有情况下成立),必须断言两个三元组(代理P作为被聚合资源AR的代理,在聚合A中起作用):
<P> <ore:proxyFor> <AR>
<P> ore:proxyIn <A>

用途:
– 被聚合资源间关系(如:顺序关系,只适用于特定聚合中。参考文献的顺序,对各参考文献本身不适用)
<P-1> <hasNext> <P-2>
– 外部被断言关系到被聚合资源(如:引用关系。聚合是最佳论文集,用代理表明所引被聚合资源为最佳论文)
<URI-1> <xyz:cites> <P-1>
– 链接被聚合资源(如:起源或出处,被聚合资源来源于另一个资源)
<P-1> <ore:lineage> <P-2>
对主体代理的资源地图必须包含三元组 <P-1> <ore:proxyFor> <AR-1>
对客体代理的资源地图必须包含三元组 <P-2> <ore:proxyFor> <AR-1>(两个三元组中被聚合资源AR-1相同)

the use of ore:lineage

———- ORE Specification – Vocabulary 词表 ———-
指导原则是在可能的情况下重用已有词表。
使用命名空间:ore(本身), oreatom; dc, dcterms, dcmitype; foaf; owl, rdf, rdfg, rdfs

自定义类与关系
(4个)
ore:Aggregation 聚合;父类 dcmitype:Collection
ore:AggregatedResource 被聚合资源
ore:Proxy 代理(代表一个存在于特定聚合中的被聚合资源)
ore:ResourceMap 资源地图;父类 rdfg:Graph

关系/谓词(8个)
ore:aggregates 聚合;父属性 dcterms:hasPart;定义域 ore:Aggregation,值域 ore:AggregatedResource
ore:isAggregatedBy 被聚合;父属性 dcterms:isPartOf;逆属性 ore:aggregates
ore:describes 描述;定义域 ore:ResourceMap,值域 ore:Aggregation
ore:isDescribedBy 被描述;逆属性 ore:describes
ore:lineage 世系;定义域、值域 ore:Proxy
ore:proxyFor 代理;定义域 ore:Proxy,值域 ore:AggregatedResource
ore:proxyIn 代理在;定义域 ore:Proxy,值域 ore:Aggregation
ore:similarTo 相似;父属性 rdfs:seeAlso;定义域 ore:Aggregation,值域 ore:Resource

推荐的重用词表(例举而非枚举)
– 类
DCMI类型:为资源赋予大类
DCTerms:主要作为关系的定义域、值域
FOAF:用于与人相关的资源,包括个人、组织和项目

– 关系(两类关系:1、资源-关系-文字;2、资源-关系-资源)
DC元素:dc:description,dc:format(建议用MIME类型),dc:language(建议使用ISO 639-1),dc:rights,dc:title
DCTerms:dcterms:audience(建议客体dcterms:AgentClass),dcterms:contributor(建议客体dcterms:Agent),dcterms:conformsTo(建议客体dcterms:Standard),dcterms:creator(建议客体dcterms:Agent, foaf:Person),dcterms:created(ISO8601格式),dcterms:extent,dcterms:isVersionOf,dcterms:modified(ISO8601格式),dcterms:references(建议客体Resource),dcterms:replaces,dcterms:rights(建议客体dcterms:RightsStatement)
FOAF:foaf:mbox,foaf:name,foaf:page
RDF:rdf:type(建议客体rdfs:Class)
RDFS:dfs:isDefinedBy(为类规定取值词表),rdfs:label(为类规定人读标签),rdfs:seeAlso

利用关联数据、验证名称和主题(LC和VIAF)

MARC数据,除了控制字段,总意在被人而非机器消费与理解,如同早期HTML被人读,而非被机器理解”—— Nate Trail

最近BIBFRAME邮件组围绕LC新近提出的BIBFRAME修订建议展开热烈讨论。美国国会图书馆(LC)网络开发与MARC标准办公室的Nate Trail谈到,即使没有BIBFRAME,用“资源”代替“实体”的工作也可以开始:现在虽然仍使用MARC,但LC已经开始鼓励编目员在多个字段放LC控制号(LCCN)和其他标识符,而不是写出题名或实体名,这样系统已经可以做链接。——换言之,MARC也可以与关联数据结合。
Nate Trail提到“Terry Reese正在其MARC转换器中建立实体解析过程,把标识符转为链接”。顺邮件中的链接看Terry Reese的博文,发现MarcEdit 6利用LC关联数据服务(查询id.loc.gov),增加了验证名称与主题规范(1XX、6XX、7XX字段)功能。目前MarcEdit 6.1已经发布,“验证标目”功能已上线(与博文截屏大致相同)。

关于MarcEdit另见:MarcEdit的RDA助手(2013年1月29日)

———- MarcEdit 博文摘译 ———-
MarcEdit 6 Wireframes — Validating Headings (Aug 09, 2015)
在过去一年中,我花了很多时间,寻求集成很多成长中的关联数据服务到MarcEdit的途径。这些服务,主要围绕词表发展,提供某些有兴趣的机会,增强现有MARC数据,或者强化使用这些特定词表的本地系统。如在Bentley这样的例子,是计算机能够如何利用这些端点(endpoints)的真实世界证明。
在MarcEdit,至今我已经创建和测试链接工具近一年,我期望探索的领域之一,是图书馆是否能使用链接服务建立自己的规范工作流程。概念上,应该是可能的——存在必需信息……确实只是放在一起的问题。因此,这就是我正致力的。使用图书馆在MarcEdit中发现的关联数据,我正致力于创建一项服务,将帮助用户识别无效标目以及带这些标目的记录”。

MarcEdit Validate Headings: Part 2 (Aug 23, 2015)
验证标目工具加为MarcEditor的一个新报告,让用户取一个记录集,返回一个报告,详细了解多少记录有相应的LC规范标目。本工具设计验证在1XX、6XX和7XX字段中的数据。本工具设置只使用LC规范档查询标目和主题。在适当时候,我会寻求扩展到其他词表。
目前本工具必须在MarcEditor内部运行——尽管在未来某个时点,我会把此(工具)由MarcEditor抽出,提供一个独立功能,与其他命令行工具集成。
……
如果该值为变体(即非规范形式),结果报告“返回记录号、术语的标准化形式、当前LC首选术语及该术语的URL”:
Record #612
Term in Record: bible.–criticism, interpretation, etc., jewish
LC Preferred Term: Bible. Old Testament–Criticism, interpretation, etc., Jewish
URL: http://id.loc.gov/authorities/subjects/sh85013771
Heading not found for: Bible.–Criticism, interpretation, etc
……我马上会增加代码,让用户选择按报告更新变体标目。

———- Bentley的例子 ———-
博文中提及的Bentley,是密歇根大学Bentley历史图书馆。该馆的ArchivesSpace项目,使用Google Refine,通过VIAF API查询LC规范记录,增强档案记录中的名称和主题。其中还用到Python的FuzzyWuzzy库处理字符串的模糊匹配
代码主要采用GitHub上Matt Carruthers的:LCNAF-Named-Entity-Reconciliation
介绍博文(来自blogspot,有墙):
Arkheion and the Dragon: Archival Lore and a Homily on Using VIAF for Reconciliation of Names and Subjects (Friday, July 24, 2015)
Order from the chaos: Reconciling local data with LoC auth records (Friday, July 31, 2015)
Arkheion and the Dragon, part II