:::: MENU ::::

TalkingData's Blog

现在开始,用数据说话。

Posts Categorized / Enterprise

  • 十一 08 / 2017
  • 0
Enterprise

锐眼洞察 | 为什么企业知识图谱需要语义?(翻译)

作者:Dr. Jans Aasman,CEO of Franz Inc.

原文:Why Enterprise Knowledge Graphs Need Semantics

译者:TalkingData副总裁 高铎(Ted)

本译文禁止商用,转载请注明来源与译者!

摘要:

  • 企业知识图谱的底层框架是RDF,本体提供了快速演化的模式,标准化的分类系统则促进了整个组织内部数据一致性的定义;
  • 语义工具对数据术语定义及术语与数据的对应关系进行分类,使得语义技术拥有很强的一致性能力,为后续的数据治理、数据质量控制和数据管理奠定良好的基础;
  • 知识库通过确保标准化的模型、本体(数据)的含义和类目的一致性来进行加强和演进,来保证数据驱动战略与企业目标是一个整体。

企业知识图谱建设是每个数据驱动型组织试图去做的核心:将数据资产转化为公司独有的竞争优势。

通过将企业内外数据有效连接到一个独立的知识库,可以重复使用组织的各种用例,企业知识图谱是实现这一目标的最有效机制。在硅谷,好的用例到处使用和传播,证明了这种方法的商业价值。

然而这个过程中,语义在其中发挥的作用是鲜为人知的。语义相关技术不仅支持了企业知识图谱的范式,而且贯穿在授权、生成和使用过程中。如果没有语义学的研究,企业知识图谱要么不可能实现,要么实现的不切实际无法应用。

而且,其中的图表依赖于基本语义方法是如何组成的。RDF作为底层图形框架,本体提供了快速演化的模式,标准化的分类系统则促进了整个组织内部数据一致性的定义。这些工具的组合,能协助反映和理解企业数据与业务问题的相关性,也是企业知识图谱的自然产物。

RDF(资源描述框架 Resource Description Framework)

RDF可能是语义工具箱中足最重要的一个工具,它提供了一种把孤立数据连接在一起的方法。语义图(有的地方也叫做链接数据图)依赖RDF,为任何类型或来源的相关数据,提供独特的连接方法。语义图理清了节点之间的关系,这是衍生数据元素上下文特性和相关特性的关键。RDF为整个企业中的每个数据元素提供一个唯一的机器可读的标识符(URL),使得图表能够以相同的方式链接数据,而不用考虑原始数据系统的技术、模式、多样化结构或其它特性。

语义图的链接能力消除了数据孤岛,允许将所有数据加入到一个独立知识库中。值得特别注意的是,RDF核心部分的URL是可以查询的,这可以让企业深入了解所有数据,而不用考虑其来源的差异。用单个知识库库链接企业的数据是知识建立的基础,这些知识有助于帮助理解其与业务流程的关联和应用。

类目和分类系统

RDF由很多包含数据意义和数据模型的语义标准来支撑。他们通过分类系统和类目来区分,分类系统和类目帮助厘清了RDF中链接在一起的各种数据的含义。类目的重要性在于,确保企业知识图谱中所有链接的数据,其相同的术语有相同的含义。考虑到大数据出现后,数据的来源与数据结构的变化,这个工作需要花费相当大的精力。

利用这些语义工具,对数据术语定义及术语与数据的对应关系进行分类,使得语义技术拥有很强的一致性能力,为后续的数据治理、数据质量控制和数据管理奠定良好的基础,以保证企业知识图谱的稳定性。如果没有良好的分类,图表会产生不准的查询结果、甚至相互矛盾的信息,让企业所谓的数据洞察力毫无可信度。

本体模型

本体方法是标准化的语义模型,使所有数据遵循相同的格式。它对不同类型和技术的数据进行一致性分类同样至关重要,可以通过RDF以统一的方式连接数据。本体为企业知识图谱可行带来了多重好处,它的标准化格式大大减少了格式化数据的数据工程工作量,而这(格式化数据)往往会影响其它技术工程的速度。所以,由于本体方法的发展,组织可以快速整合新的数据源以适应新的业务需求。

语义所关注的数据准备工作是提前完成的,这样可以保证每次数据更改,语义图都不需要重新改动,这在关系方法中经常使用。除了对数据进行标准化,当合并新数据或在数据驱动的过程中,本体也会缩短处理的时间。本体能够使企业知识图谱方便地涵盖尽量多的数据类型,提供相对较好的综合分析体验。

知识的强化

企业知识图谱的卓越特性,是能够将不同数据资产链接到一个地方,以明确彼此之间的关系和业务功能。语义技术的使用则能直接带来上述所说的好处,链接的数据图表用以支持关联数据的知识库。换句话说,知识库通过标准化的模型、本体(数据)的含义和类目的一致性来进行加强。这些机制的综合作用,可以确保数据与实现组织的目标,尽量是一个整体。

关于作者

Jans Aasman博士是Franz Inc.的首席执行官,是人工智能领域专家,Franz Inc.是语义知识库库技术的领先供应商。

  • 十二 06 / 2016
  • 0
Enterprise

TalkingData开源智能设备情景感知框架“Myna”

什么是情景

简单地说,就是与用户相关的信息:

什么人 + 在什么时候、地点 + 做什么 = 情景。

“什么人”指的是相对静态的用户属性,比如时尚辣妈、运动狂人、宅男等;“什么时候、地点”就是用户所处的环境,包括时间、地点、天气、光感等;“做什么”主要是用户的行为或状态,比如走路、跑步、休息或开车等等。

针对不同的情景,用户需要的是不同的服务内容。比如保险领域中的UBI,基于手机传感器的数据,判断司机是否有急刹车、超速、快速变道等比较危险的架势行为;还有O2O领域,比较常见的就是精准推送,比如在上班的时候,推荐一杯星巴克的咖啡劵,或者在外出旅游的时候,可以推荐一些景点及周边美食。

Continue Reading

  • 十一 24 / 2016
  • 1
Enterprise

Vue高效UI组件库——iView开发实践

作者:TalkingData 小梁

前段时间在微软参加活动,分享了 TalkingData 开源的基于 Vue.js 的高效 UI 组件库 iView 的一些开发经验,现整理成文,和大家探讨。


GitHub:https://github.com/iview/iview

关于 iView

开发历程和命名

TalkingData 可视化团队使用 Vue 有半年多时间,经历了从开始简单的使用双向绑定,到后来完全依赖 Vue 全家桶和 Webpack 的演变过程。这套开发模式验证了多个大中型项目,开发效率有了显著了提升,工作流也从半自动进化到了开发、灰度、生成环境的全自动,可以说 Vue 还是给我们带来了很愉快的开发体验。
随着组件化的不断深入,对组件的复用和维护成了一个问题,于是开始调研市面上的 UI 组件库,发现基于 Vue 的大多是移动端的,而针对 PC 中后台的,能像阿里 Ant.Design(基于React.js) 那样功能丰富而且高质量的,没有看中一款,要么就是不维护了,要么就是功能太简单,质量不够高。所以我们决定自己开发维护一套高质量的 UI 组件库。确定好这个目标,规划好1.x版本后,就开始这条不归路,最近三个多月一直投身于 iView 的开发。
至于起 iView 这个名字,其实也没多想,以 Apple 的产品命名加上 Vue 的发音,简单好记好读,同时 GitHub 还没有注册这个组织名(就为了这些,也得把它做成一个精品)。 Continue Reading

  • 十一 22 / 2016
  • 0
Enterprise

Android 基于传感器数据进行实时行为识别的实现

作者:TalkingData 小辉

背景介绍

Google 在 I/O 2016 大会上正式向开发者介绍了 Awareness API:

A unified sensing platform enabling applications to be aware of multiple aspects of a users context, while managing battery and memory health.

Google 将 Google Play Service 中和用户场景识别相关的服务和功能整合在一个统一的 API 下,为开发者从兼顾内存占用和电量消耗方面提供更高效率的方案。

Google 定义的场景识别

Google 在 Awareness API 的文档中,对智能化所需的场景是 这样描述的: Continue Reading

  • 十一 17 / 2016
  • 1
Data, Enterprise, Tech

TalkingData营销云技术实践——基于RocksDB的高效标签计算

作者:王福胜

“营销云”(TalkingData MarketingCloud) 是TalkingData发布的新一代广告营销数据管理平台,利用超过40亿移动终端数据的覆盖优势,实现了从人群构建、多维洞察到同步投放、客观监测的一体化解决方案。

TalkingData积累了40多亿移动设备的数据, 并且基于这些数据建立了自己的标签体系。 现有12大类超过800个受众定向标签,包括人口属性,设备属性,位置属性,兴趣,消费特征,安装的应用App等。这些标签关联的设备累加起来超过700亿。 如何利用这些标签为用户提供快速的标签人群构建,对人群进行多维度的快速画像是一个挑战。

Continue Reading

  • 十一 15 / 2016
  • 0
Enterprise, Tech

40亿移动设备的用户画像和标签架构实践

作者:王鹏

大家好,我是来自TalkingData的王鹏,很高兴在这里和大家一起探讨大数据的应用。

说起大数据的应用可能很多朋友们脑子里边第一映像就是画像,我想从以下几个方面跟大家聊聊画像相关的事情:1、什么是画像;2、画像的用处;3、如何进行用户画像;4、画像应用中的难点。

20160130141003_843c3210dbf729e2bb84eafca75c1db5_1

Continue Reading

  • 十一 04 / 2016
  • 0
Enterprise, Tech

推送架构的演进

推送架构的演进

我是来自TalkingData推送团队的工程师许建辉,在2015年初加入Push项目以来,经历了设备量、并发数的高速提升。在此过程中,我们对系统架构做了一些细微调整,并让系统的性能表现上一个台阶。本文将阐述Push的系统架构,碰到的问题和应对的办法。

架构是为了更好的为业务提供更好的服务。架构最终会以产品的方式提供给客户使用。因此,在我们开始讨论这套系统架构的演进之前,请由我对我们系统做一个简单的介绍:

图片 1TD-Push,产品代号魔推。如上图所示,TD-Push是一款为移动APP提供的一套推送营销组件。我们的SDK拥有体积小、耗电少的特点,同时支持公有、私有云的部署。对于推送内容的报文,在传输过程中是全程密文,并且每个终端的秘钥都不相同。它使用了Go语言编写,拥有部署简单,成本低廉的特点。同时它的功能丰富,能够对每次推送的效果进行跟踪。

Continue Reading

  • 二 16 / 2016
  • 0
Enterprise, Ideas

支付宝集福为什么只有80万名额?

除夕夜,当零点钟声敲响的时候,许多人或许并不是关注着新年到来,而是关心自己集福没戏了。支付宝以空前强势的运营策略,迅速深入人心——但是也同时被骂得狗血淋头。此时马云的心中只怕在咆哮,“剧本不应该是这样的啊”。的确,在笔者看来,支付宝本该上演一出完美的运营大戏,戏中这80万名额传为佳话。平心而论,谈钱,谈交易,没人是支付宝的对手。只是最后,剧本出了点小事故。

为什么这么说?难道不是支付宝乱定规则得罪数亿用户?这是用户思维,用户一定会说支付宝乱来。但是做产品的人,一定需要先理解它为什么这么做,再下评论。没有人会为了得罪人而定一个策略,支付宝这种量级、还是春节时候的大策略,几乎不可能不经高层之手。

那么马云们是怎么想的这个剧本?笔者想推测一下。

6a3846ec-79b4-4edb-83f6-0f4a56017e18

Continue Reading

  • 二 16 / 2016
  • 0
Enterprise, News

很多创业者的失败,是被APP给拖死了

前几天看了一篇文章,写的是一个26岁的创业者花了400天创业失败的教训,通过文章能感觉到这个创业者的失败原因,就是被开发App给拖死了,计划3个月就上线的App,让外包团队做,结果延迟了3个月才上线,最后上线了一堆bug,这样改bug估计又改了很长时间,这样算下来大半年甚至一年都过去了,拿的那点20万的天使投资,其实就是你拿50万,甚至100万,如果碰到这样的问题一样是失败。现在很多App创业者,对行业的了解和调研不够仔细,所以导致了小坑都能把你绊倒。

QQ截图20160130110010

 

Continue Reading

页面:123456
随时欢迎您 联系我们