博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
【semantic】瘦语义网的几点想法
阅读量:6233 次
发布时间:2019-06-21

本文共 2765 字,大约阅读时间需要 9 分钟。

2013-01-31 增补:整理了一个《》, 提纲全文在上。

这一年多来在工业界的实践,我总结经验和教训为“瘦语义网”(Lean Semantic Web)。

顾名思义,这个说法是从“Lean Startup”(精益创业)引申出来的,或者说是Lean Startup在Semantic Web上的应用。所以Lean Semantic Web最合适的翻译还是“精益语义网”。不过“瘦”听起来简单点,就先这么叫吧。

是今后系统总结这个概念的地方。现在还没有什么内容,等以后自由时间多了再去填坑吧。

这里只能简单的总结几点原则问题。

瘦的意思并不只是更简单、简化现有的语义网技术。它的核心思想是Making things people want,也就是为人民服务。(参前文《》2011-12-20)

人民不仅包括用户,也包括为用户服务的工程师们。语义技术不是万灵药,不是人工智能的什么突破,也不是从天上掉下来的。好的市场和技术都是演化出来的,很少是突然的革命。如何让开发和使用这个技术最符合工程师和用户的需要,如何从现实基础演化,是语义网的最关键问题。

由此引申一些想法。

首先是用户和市场的一些想法

a.  目前结构化数据,特别是高质量图结构的数据已经成为提升用户体验的核心问题

  • 机器学习的方法无法再深入提供结构化数据所能提供的效用。

b.  智能技术在过去的成功主要是做加法(提供给用户更多的内容,如推荐和广告)。语义网的优势在做减法

  • 拿语义网技术来接着做加法,如Knowledge Graph和Graph Search,是传统Web厂商的价值体系决定的。改变这种价值体系需要很长时间。

c. 在语义网上实现突破的必然是小公司(The Next Big Thing)。现有的大公司很难服务好早期核心用户。

  • 早期的语义应用按传统价值体系来衡量性能是下降的。需要切入一个对新价值系统敏感的早期核心用户市场。
  • 大公司内部的政治结构不利于语义网技术的采用。
  • 快速验证用户需要只能由小公司来完成

d. 语义技术的突破点看似不会在继续深化社交网络(social network)这种关系上,虽然这个还很热。信息网络(information network)是个高质量数据更丰富的世界。

  • 语义网的早期核心用户可能在不活跃使用Facebook的那个人群中

e. 语义数据到目前为止还都是小数据。市场潜力最大的是小而高质量数据的集合。不要迷失在大数据的各种buzz和hype里。

  • 兵贵精而不贵多,数据也一样。认为自己数据多就能投鞭断流,是幻想。

其次是技术上的一些想法

1. 语义就是关系,知识是用来发现新关系的数据。语义数据的核心问题是数据质量。知识是数据中质量较高的部分。

  • 当前最成熟的关系表示工具是图(Graph)。树(Tree)和文档(Document)是图的特例
  • 推理是图上的运算,是添加新边和新节点的方法。

2. 实践中的语义网是NonRDF: Not-only RDF。不要拘泥于RDF这种交换格式和它的种种变化(如RDFa, Microformat)

  • 对RDF的迷信是现实扭曲力场(Reality Distortion Field)。这种迷信往往导致对迷信的失望从而否定语义技术——那也同样是一个现实扭曲力场。
  • 把其他格式数据转化为RDF而不做质量提升的工作,不能解决垃圾进,垃圾出的问题。这就是我认为LOD和开放政府数据中相当部分其实无工程意义的原因。

3. 目前阶段最有工程基础的语义数据交换格式是JSON。数据交换格式和数据存储格式可以分离。

  • 即使交换格式使用RDF,并不需要在内部存储中使用triple store
  • NLP, ML, IR, Database, Reasoner都适用这个原则

4. URI做资源寻址方式是昂贵和不符合用户需要的。字符串在大多数情况满足大多数用户的需要。

  • URI命名的成本不足以justify它带来的定位唯一性的好处。何况唯一性在Web应用中并不总是重要问题
  • HTTP URI是结果而不是原因。不要对LOD产生迷信,或教条理解TBL说的。事实是,LOD虽然已经简化了,但对工业规模化还远远不够。

5. 凡是不能做到(用户感知到的)常数时间响应的系统都是胡扯

  • OWL 2 profile所设计的多项式时间子集没有在Web上的实践意义。
  • 其实整个OWL都没有Web上的实践意义。
  • 常数时间响应是通过大规模索引,大规模分布式数据分片、计算分片来实现的。

6. 语义网技术并不是单一的数据交换格式和查询。完整的应用系统,几乎都要包括自然语言处理,信息检索,结构化数据存储,结构化数据查询,数据质量的提升,隐含关系的发现(机器学习或推理),探索或启发式用户界面等模块的集成。

  • 没有单一方法能解决语义网面临的问题。做有价值的系统集成是现实选择。在微观技术(如名词提取)和宏观技术(如语义搜索)层面上都是如此。
  • 深入理解现有系统(如数据库和全文索引)对图结构化数据支持的瓶颈有利于理解语义网技术的局限和现实可行范围。

7. 现阶段能规模化的语义关系很浅,只有同义关系、分类树关系、传递关系(transitive property),至多加上路径查询(path query)。这是数据库和信息检索的基础设施决定的。先规模化这些关系,循序渐进才能处理更多的关系

8. 弱耦合的系统构架。尽可能重用现有成熟技术。尽可能利用好云计算基础设施

  • 现有的学院派语义网研究很少满足这个要求。也和工业界要求差距很远。
  • 强耦合的,Cluster的模式,如YarcData的,适用于大企业市场,也就是SEMANTIC web市场,而不是更广阔的semantic WEB市场
  • 多层次模块化(hierarchical modularization  )

9. 懒(lazy)系统. Just-in-time knowledge, just-in-time computation, pay-as-you-go benefit,减少初始投资要求

  • 懒的核心思想是减少浪费。
  • 相关概念是lean(精益)和agile(敏捷)
  • 局域化
  • 允许系统的快速演进。减少传统知识工程中的鸡生蛋,蛋生鸡的建模问题。

10. 工具系统建设是瓶颈。成熟好用的NonRDF语义网工具生态系统可能还需要5-10年的建设时间。

  • 现阶段要不耻于写小工具,写各种插件。少发明轮子,多改进轮子。
  • 特别是用好现有语言和它们的工具,比如Python和Javascript。(参《》2012-11-27)

先就抛砖引玉胡说这几句,求教于方家。

转载于:https://www.cnblogs.com/549294286/archive/2013/05/03/3057453.html

你可能感兴趣的文章
Kubeflow实战系列:阿里云上使用JupyterHub
查看>>
研究人员成功从地面入侵飞行中的飞机
查看>>
关于代码的那些低级错误,都是血泪的教训
查看>>
0322理解db file parallel read等待事件2
查看>>
浅谈script标签中的async和defer
查看>>
不忘初“芯”,共创未来,2017安创成长营4期Demo Day在杭州圆满落幕
查看>>
JDBC示例(增删查改)
查看>>
MySQL集群方案收集
查看>>
IBM称可在1个原子内存储1 bit数据
查看>>
区块链应用场景
查看>>
Java数据库连接池研究
查看>>
【CVPR 2018】用狗的数据训练AI,华盛顿大学研发模拟狗行为的AI系统
查看>>
emoji表情引发的JNI崩溃
查看>>
区块链初学者指南1
查看>>
MySQL8.0: 通过Resource Group来控制线程计算资源
查看>>
深度学习精要之CapsuleNets理论与实践(附Python代码)
查看>>
InfoQ上很不错的技术分享(待续)
查看>>
Ubuntu 16.04网络管理工具NetworkManager无法使用nm-tool的问题
查看>>
Linux下which命令使用详解(转)
查看>>
京东送货无人机曝光,正在农村进行测试
查看>>