对Kevin老师就LCSH的SKOS项目博文的一点想法

[pinoke]

本就想在数图笔记上发个评论，但后来写得有点多了，不如放在圈子里，大家一起讨论。

keven老师的博文“SKOS版的LCSH“总结的不错，首先谢谢分享经验。
“linked Data”理念的推广和RDF周边应用的成熟为传统KOS网络化改造后融入语义网提供了有利条件，我的感觉就是时机成熟了。美国国会图书馆对LCSH的SKOS化无疑会带动LIS界对SKOS以及传统KOS网络服务（即所谓的术语服务）的思考与实践。以下是对应kevin老师博文的各条谈点自己的看法。
4. 定义CCT自有的概念唯一标识体系非常重要，其中存在一个面向概念和面向术语的转换。
6. SKOS编码表征词表后的查询一定会用到SPAQRL，这点在之前的CCT讨论中还未涉及到。
7. LCSH的数据下载后解压出300多M的文件，够大的，本机处理比较困难，可节选部分做实验，数据较基础。
8. 我的观点是词表自身层面坚持保留CCT的MARCXML作为基础数据（CCT目前能够输出MARCXML，也这是未来发布的网络版一个特色功能），目前只有这套格式基本能把CCT所有类目体系、结构关系描述清楚。而在Web服务层使用基于MARCXML的SKOS表征对外提供检索、共享、交流、可视化、挖掘等服务功能。两者还是要分别对待，不能取一舍一。
9. CCT\CT\CLC这三个词表的关系是三位一体的，CCT是集大成者，也代表了情报检索语言分类主题一体化重要特征。以CCT为研究对象，也就等于同时做了CT和CLC。MAPPING映射层去研究CCT与CT、CLC的关系（远洋老师在POSTER提出的两种映射机制选择）。
10. 不知KEVIN老师所指“有关单位”动作如何，具我所知的CCT版权所有者在网络化改造方面已经做了很多工作，其中也包括对SKOS的关注和探索。他们的想法严谨，所做务实，不冒进也不拒绝新事物。这点让我非常佩服！

不管怎样，更多的人关注SKOS和传统KOS的发展问题，令人感到欣喜。

[Caveman]

谢谢远洋老师。
在IFLA匆匆一见，很是遗憾。
有些想法整理好了再向老师请教。

[远洋过客]

Cavemen: Check http://tspilot.oclc.org/resources/index.html and play with it.
１。　OCLC TS的词汇数据采用ＭＡＲＣＸＭＬ、ＳＫＯＳ、Ｚｔｈｅｓ，　你可以打开一个ＨＴＭＬ显示的词条，换最后的ｅｘｔｅｎｓｉｏｎ，看到不同格式。
２。在编码方式上，他们试用了ＸＭＬ，ＲＤＦ，ＪＳＯＮ。
３。在ａｃｃｅｓｓ方式上，他们试用了ＲＥＳＴ和ＳＲＵ＆ＳＲＷ。

[pinoke]

Cavemen从技术角度来谈实现，即所谓语义网环境下KOS服务的技术实现框架
Format，支持多种主流的编码格式是必要的，如skos,n3,json等
我个人倾向与使用RESTFUL风格的Web Service架构，因为REST与HTTP结合紧密，所以运用COOL URI也就相对容易些吧，我感觉，没有具体求证。
早期讨论对CCT要求的整体技术框架方面还不甚清楚。

Keven老师提到开放、跨单位的合作这点，我很赞同。像我们在NING上跨界限的交流虽不甚正式，但效果不错。
基于版权等各方面因素的考虑，现在我的理解是这样（也比较外围，呵呵）。就CCT来说，未来的网络版称要对外提供底层数据的下载MARCXML格式，是否可以认为在一定规则下开放了词表资源，在此基础上各单位组织个人可以开发各类词表服务和应用，迎来所谓的百花齐放局面。规则的具体条条框框我不太清楚哈，我总是朝着好的方面去想。对研究的词表对象而言，去挑战这样的大块头，很多事情不是单纯研究和探索能掌控的，我非常理解。

雨僧老师说到了一个关键问题，我们花大力气去做词表改造后最终的落脚点服务是什么？可行的具体服务有哪些，看似遥远其实非常现实。纵观现有的一些先导项目，最直接的就是知识体系的网络存取，检索一个概念得出该概念所有关联，还有就是后端用在检索系统的查询扩展，网络资源的标引等。关于CCT的MARCXML，我曾经索要过，但没有拿到，呵呵。但其MARC格式与UNIMARC保持一致，UNIMARC的XML转化方面有些东西还是可以查阅参考。关键是研究MARCXML与SKOS的映射（这也被我一直称为中分法SKOS化的前接问题）。

[远洋过客]

有兴趣者可以参加我们的讨论，在wiki上直接留言或者修改：
http://www.metadataetc.org/wiki/index.php5?title=CCT2_senariors。 目前内容有：
1 《中国分类主题词表》(中分法, CCT)
1.1 背景
1.2 数据模型
1.3 格式编码
2 目前决策 & 编码实例 (连接到各分页）
2.1 skos:ConceptScheme 定位
2.2 skos:Collection 使用
2.3 标示符号问题 (Identifier, URI)
2.4 组配问题
2.5 辅助表的处理
2.6 skos:notation 分类号特例
2.7 词族和族首词
3 对照表编码提案
[还未具体化]：4 利用语义wiki工具进行中分表SKOS化的研究

[雨僧]

十分赞同Caveman的看法，“以什么方式(rdf, n3, json)来传递数据都一样, 关键是提供什么样的Web Service. ” 那么，我们需要什么样的Web Service?我们是不是也要议议？
对于ＣＣＴ／ＣＴ／ＣＬＣ这三者的关系结构不尽相同，做起来难度比较大吧。pinoke 君能否给一条CCT的MARCXML样本数据？谢谢啊。其实用何种格式表达是不重要的，用ＭＡＲＣ格式、ＭＡＲＣＸＭＬ、ＳＫＯＳ或其它格式都可以，关键是如何实现互操作。

[kevenlw]

这里讨论很好，谢谢pinoke。
对于北京众多单位的众多专家，偶也是佩服的紧，有真才实学的不在少数。问题的关键在于现在的研究需要有更多的开放精神和团队合作，开放甚至意味着个体利益的部分牺牲，合作也不一定是单位内部，可以是虚拟团体。从事业发展层面上来看，各条各块的头头脑脑和占有大量资源的专家们如果只看着自己锅里碗里的，他们实际上是没有尽到责任的，他们应该在制订游戏规则、发挥行业/专业整体作用、提携后进方面，做更多的事情。

[Caveman]

最近我也在研读SKOS和"Linked Data"方面的文章。还没有比较成形的看法。不过看了lcsh.info, OCLC的术语服务后, 感觉到现在是KOS和语义网融合的时机了. 一直以来,也认为KOS是语义网走向成熟的突破点和试金石。由于lcsh.info公布实现的源码, 十分好奇的看了看. 遗憾的是lcsh.info没有提供Web Service．　对我来说,以什么方式(rdf, n3, json)来传递数据都一样, 关键是提供什么样的Web Service. 就相对简单的术语服务而言, 欧洲的项目和OCLC提供的服务接口就不一样了．统一标准术语服务的Web Service也许是一种简单但不一定可行的解决办法．基于owl-s的语义Web service或许是更好的解决方案．SPARQL是基于ＲＤＦ的相对比较底层的查询语言.直接用也没有什么，也算一定意义上的简单Web service．不过Web service更加有包容性，也支持服务的定位等．

顺便提一下，lcsh.info的查询是lucene/solr上的，在uri, prefLabel 和 altLabel做了索引．

思绪比较乱，请各位指正，谢谢