现状：
目前大多数隐患排查系统相对发达的生产过程尚且落后，主要依靠人工读取隐患，并依赖上报人员的个人经验，来保证上报隐患内容准确性。
问题：
由于人工读取的局限性，往往会出现以下问题：
（1）描述对象指代不明（例如：“三孔插头电线损坏，只接两根线”中没有能指明出现的对象）
（2）描述内容不规范（例如：“插座没安装漏保”中“漏保”应当写全称“漏电保护器”）
（3）描述现象模糊（例如：“插座设置不合理，必须安装在配电箱内”中没有写明隐患时出现在插座安装的位置上
以上问题，都将产生降低安全隐患排查的工作效率，并影响企业的生产效率和利益。
解决方案：
解决上述问题，首先，需要掌握一系列的背景知识，例如：设备信息、隐患信息、设备与设备之间的关系、设备与隐患之间的关系等，这些背景知识的本质是由设备实体、隐患实体及其存在的关系交织而成的一张语义关系网。然后，在上报过程中，上报人能在语义网中根据实际情况进行信息检索，并构建出包一条含实体和关系的合理描述，完成一次准确的隐患上报。因此，找出一种有效的方法来描述实体、实体与实体之间的关系成为解决这个问题的关键，而知识图谱便在这之中脱颖而出，它不仅可以为使用者提供了海量背景知识的大规模精确检索能力，而且还可以为隐患描述文本中的设备实体规定符合实际情况的约束范围，从而达到规范化的目的。
接下来，根据实际需求，本文将会依次介绍知识图谱、管理思想、系统架构这三方面的内容。
知识图谱介绍
（1）知识图谱定义
知识图谱，是结构化的语义知识库，用于以符号形式描述物理世界中的概念及其相互关系，其基本组成单位是『实体-关系-实体』三元组，以及实体及其相关属性-值对，实体之间通过关系相互联结，构成网状的知识结构。
如图所示，你可以看到，如果两个节点之间存在关系，他们就会被一条无向边连接在一起，那么这个节点，我们就称为实体（Entity），它们之间的这条边，我们就称为关系（Relationship）。
知识图谱的应用价值在于，它能够改变现有的信息检索方式，一方面通过推理实现概念检索（相对于现有的字符串模糊匹配方式而言）；另一方面以图形化方式向用户展示经过分类整理的结构化知识，从而使人们从人工过滤网页寻找答案的模式中解脱出来。
因此，通过构建安全隐患知识图谱，可以将设备信息以及相关的隐患信息用图数据库的形式组织起来。设备和隐患讲义实体的形式存在于知识图谱的节点中，设备和设备的关系、设备与隐患的关系表示为节点与节点之间的连线。当使用者从利用上报隐患时，例如：“货运电梯灭火器保险栓缺失”，知识图谱不仅将为使用者提供“货运电梯”实体的信息，而且可以检索出“货运电梯”与“灭火器”之间的“所属”关系、“灭火器”与“保险栓”的“所属”关系，并使用检索到实体的其他“所属”关系对上报的文本描述语义进行规范化。而这些实体与关系的信息构成，确保提交的安全隐患信息准确有效。
（2）知识图谱的数据类型
知识图谱的原始数据类型一般来说有三类：
1．结构化数据，如关系数据库
2．非结构化数据，如图片、音频、视频
3．半结构化数据 如XML、JSON、百科
（3）知识图谱的数据存储
1. 通过RDF（资源描述框架）这样的规范存储格式来进行存储，主要有五种：RDF/XML，N-Triples（N-3元组），Turtle（三元组），N-Quads，JSON-LD等。
以RDF/XML为例，它用主体、谓词、客体的三元组来描述一个数据的元数据。比如John Smith创建了某个网页，用自然语言来描述是“http://www.example.org has a creator whose value is John Smith”。这里，网页是一个主体，即一个数据，而John Smith是一个客体，creator则是一个谓词。客体和谓词都是主体的属性。
比较常用的有Jena，它是Apache负责的一个知识图谱管理系统，包含知识图谱存储API以及知识图谱查询终端组件。
2.使用图数据库来进行存储，常用的有Neo4j，它 是一个高性能的、NOSQL图形数据库，它将结构化数据存储在网络上而不是表中。它借助功能强大的Cypher查询语言，用户就可以使用与SQL几乎一样的查询方式获得更强大的关系搜索能力，下图是Neo4j数据库中存储的实体和关系的可视化表示。
（3）关系型数据库与非关系型数据库存储知识图谱对比
用关系数据库来存储知识图谱，尤其是存储简单的知识图谱，从技术上来说是完全没问题的。但需要注意的是，一旦知识图谱变复杂，图数据库在关联查询的效率上会比传统的关系数据存储方式有显著的提高。当我们涉及到2,3度的关联查询，基于知识图谱的查询效率会高出几千倍甚至几百万倍。除此之外，基于图的存储在设计上会非常灵活，一般只需要局部的改动即可。
因此,如果数据量较大，用图数据库来进行存储知识图谱比较合适。
（4）知识图谱的架构
1.逻辑架构
知识图谱的逻辑结构分为两个层次：数据层和模式层。
模式层:在数据层之上，是知识图谱的核心，在模式层存储的是经过提炼的知识，通常采用本体库来管理知识图谱的模式层，借助本体库对公理、规则和约束条件的支持能力来规范实体、关系以及实体的类型和属性等对象之间的联系。
数据层:作为知识实体的存储层，主要作用是将知识用三元组的形式（如[实体-关系-实体]或[实体-属性-值]）存储在数据库, 构成庞大的实体关系网络，形成知识的图谱。
2.技术架构
从图中可知：数据的来源可能是结构化的、非结构化的以及半结构化的数据，并基于这些数据来构建知识图谱，这主要是通过一系列自动化或半自动化的技术手段，来从原始数据中提取出知识要素，即一堆实体关系，并将其存入我们的知识库的模式层和数据层。构建知识图谱是一个迭代更新的过程，根据知识获取的逻辑，每一轮迭代包含三个阶段：信息抽取、知识融合、知识融合。
（5）知识图谱的构建
知识图谱的构建技术主要有自顶向下和自底向上两种。其中自顶向下构建是指借助百科类网站等结构化数据源，从高质量数据中提取本体和模式信息，加入到知识库里。而自底向上构建，则是借助一定的技术手段，从公开采集的数据中提取出资源模式，选择其中置信度较高的信息，加入到知识库中。
在知识图谱技术发展初期，多数参与企业和科研机构主要采用自顶向下的方式构建基础知识库，如Freebase。随着自动知识抽取与加工技术的不断成熟，当前的知识图谱大多采用自底向上的方式构建，如Google的Knowledge Vault和微软的Satori知识库。
本文主要介绍自底向上的知识图谱构建技术，按照知识获取的过程分为3个层次：信息抽取、知识融合以及知识加工。
（1）信息抽取：从各种类型的数据源中提取出实体、属性以及实体间的相互关系，在此基础上形成本体化的知识表达。
（2）知识融合：在获得新知识之后，需要对其进行整合，以消除矛盾和歧义，比如某些实体可能有多种表达，某个特定称谓也许对应于多个不同的实体等。
（3）知识加工：对于经过融合的新知识，需要经过质量评估之后（部分需要人工参与甄别），才能将合格的部分加入到知识库中，以确保知识库的质量。
5.1信息抽取
信息抽取是知识图谱构建的第一步，其中的关键问题是如何从异构数据源中自动抽取信息得到候选知识单元。信息抽取是一种自动化地从半结构化和无结构数据中抽取实体、关系以及实体属性等结构化信息的技术。涉及的关键技术包括：命名实体识别、关系抽取和属性抽取。
5.1.1命名实体识别（实体抽取）
命名实体识别（named entityrecognition，NER）也称实体抽取，是指从文本数据集中自动识别出命名实体。实体抽取的质量（准确率和召回率）对后续的知识获取效率和质量影响极大，因此是信息抽取中最为基础和关键的部分。
一种思路是根据已知的实体实例进行特征建模，利用该模型处理海量数据集得到新的命名实体列表，然后针对新实体建模，迭代地生成实体标注语料库。
另一种思路是利用搜索引擎的服务器日志，事先并不给出实体分类等信息，而是基于实体的语义特征从搜索日志中识别出命名实体，然后采用聚类算法对识别出的实体对象进行聚类。
5.1.2关系抽取
文本语料经过实体抽取，得到的是一系列离散的命名实体，为了得到语义信息，还需要从相关的语料中提取出实体之间的关联关系，通过关联关系将实体（概念）联系起来，才能够形成网状的知识结构，研究关系抽取技术的目的，就是解决如何从文本语料中抽取实体间的关系这一基本问题。
5.1.3属性抽取
属性抽取的目标是从不同信息源中采集特定实体的属性信息。例如针对某个公众人物，可以从网络公开信息中得到其昵称、生日、国籍、教育背景等信息。属性抽取技术能够从多种数据来源中汇集这些信息，实现对实体属性的完整勾画。
由于可以将实体的属性视为实体与属性值之间的一种名词性关系，因此也可以将属性抽取问题视为关系抽取问题。
5.2知识融合
通过信息抽取，实现了从非结构化和半结构化数据中获取实体、关系以及实体属性信息的目标，然而，这些结果中可能包含大量的冗余和错误信息，数据之间的关系也是扁平化的，缺乏层次性和逻辑性，因此有必要对其进行清理和整合。
知识融合包含2部分内容：实体链接和知识合并。
5.2.1实体链接
实体链接（entity linking）是指对于从文本中抽取得到的实体对象，将其链接到知识库中对应的正确实体对象的操作。
实体链接的基本思想是首先根据给定的实体指称项，从知识库中选出一组候选实体对象，然后通过相似度计算将指称项链接到正确的实体对象。
实体链接的一般流程是：
步骤1：从文本中通过实体抽取得到实体指称项
步骤2：进行实体消歧和共指消解，判断知识库中的同名实体与之是否代表不同的含义，以及知识库中是否存在其他命名实体与之表示相同的含义
步骤3：在确认知识库中对应正确实体对象之后，将该实体指称链接到知识库中对应实体。
实体消歧：是专门用于解决同名实体产生歧义问题的技术，通过实体消歧，就可以根据当前的语境，准确建立实体链接，实体消歧主要采用聚类法。
共指消解：主要用于解决多个指称对应同一实体对象的问题。在一次会话中，多个指称可能指向的是同一实体对象。利用共指消解技术，可以将这些指称项关联（合并）到正确的实体对象。
5.2.2知识合并
在构建知识图谱时，可以从第三方知识库产品或已有结构化数据获取知识输入。常见的知识合并需求有两个，一个是合并外部知识库，另一个是合并关系数据库。
合并外部知识库：将外部知识库融合到本地知识库需要处理两个层面的问题：
（1）数据层的融合，包括实体的指称、属性、关系以及所属类别等，主要的问题是如何避免实例以及关系的冲突问题，造成不必要的冗余
（2）通过模式层的融合，将新得到的本体融入已有的本体库中
合并关系数据库：在知识图谱构建过程中，一个重要的高质量知识来源是企业或者机构自己的关系数据库。为了将这些结构化的历史数据融入到知识图谱中，可以采用资源描述框架（RDF）作为数据模型。业界和学术界将这一数据转换过程形象地称为RDB2RDF，其实质就是将关系数据库的数据换成RDF的三元组数据。
5.3知识加工
通过信息抽取，可以从原始语料中提取出实体、关系与属性等知识要素，再经过知识融合，可以消除实体指称项与实体对象之间的歧义，得到一系列基本的事实表达。然而事实本身并不等于知识，要想最终获得结构化，网络化的知识体系，还需要经历知识加工的过程。知识加工主要包括3方面内容：本体构建、知识推理和质量评估。
5.3.1本体构建
本体（ontology）是对概念进行建模的规范，是描述客观世界的抽象模型，以形式化的方式对概念及其之间的联系给出明确定义。本体最大的特点在于它是共享的，本体反映的知识是一种明确定义的共识。
本体是同一领域内的不同主体之间进行交流的语义基础。本体是树状结构，相邻层次的节点（概念）之间有严格的『IsA』关系。在知识图谱中，本体位于模式层，用于描述概念层次体系，是知识库中知识的概念模板。
本体可以采用人工编辑的方式手动构建（借助本体编辑软件），也可以以数据驱动的自动化方式构建本体，其包含3个阶段：实体并列关系相似度计算、实体上下位关系抽取以及本体的生成。
5.3.2知识推理
知识推理是指从知识库中已有的实体关系数据出发，进行计算机推理，建立实体间的新关联，从而拓展和丰富知识网络。知识推理是知识图谱构建的重要手段和关键环节，通过知识推理，能够从现有知识中发现新的知识。
知识推理的对象并不局限于实体间的关系，也可以是实体的属性值，本体的概念层次关系等。
知识的推理方法可以分为2大类：基于逻辑的推理和基于图的推理。 基于逻辑的推理主要包括一阶逻辑谓词、描述逻辑以及基于规则的推理。基于图的推理方法主要PathRanking算法或基于神经网络模型。
5.3.3质量评估
质量评估也是知识库构建技术的重要组成部分。其意义在于：可以对知识的可信度进行量化，通过舍弃置信度较低的知识，可以保障知识库的质量
管理思想
对于安全隐患排查，如何进行有效的监督和管理，是一个非常值得研究问题。
根据《利用互联网+ 创新管理模式研发使用安全质量隐患排查治理系统》一文中，利用“互联网+”，通过规范化、标准化、信息化的技术手段，加大对建筑工程项目安全质量隐患排查治理工作管控力度，防止和杜绝安全质量事故的发生。该文章中提到许多管理方法和技术，也非常值得我们借鉴学习。
一、企业各层级隐患排查治理职责定位明确
文章中提到，建立不同层级的工作管理组织机构（文章根据实际需求，分为了局、公司、项目经理三层管理机构），明确各自分工；明确不同岗位、不同业务部门的责任分工，强化管理责任。
二、隐患排查治理系统功能完善
（1）基础信息管理功能：基础信息完备后，系统将自动生成个人的隐患排查任务。
（2）隐患排查治理功能：设计多种工作流程和路径，满足企业各级单位隐患排查治理工作的需要。
其中，文章将安全质量隐患分四级管理：Ⅰ级、Ⅱ级、Ⅲ级、Ⅳ级。项目经理对Ⅰ级、Ⅱ级隐患于6h在系统平台予以响应。对Ⅲ级、Ⅳ级隐患，由项目有关领导（总工程师、安全总监等）于12h在系统平台予以响应。
（3）考核管理功能：系统可根据管理办法的扣分规则进行扣分设置，对隐患排查治理过程中的每一个环节智能打分。
（4）查询统计功能：可以查询不同周期的个人排查记录、单位排查记录、隐患治理记录、隐患发生频数表等，可以直观判断隐患分布的趋势和治理工作情况。
（5）移动办公功能：移动端APP 具有随手拍、随时报、随时处理、随时查询功能，实现了便捷高效的移动办公功能。
（6）]其他辅助功能：根据管理需要，可以开发通知公告、待办事项、已办事项、消息列表等辅助功能，实现系统使用直观、便捷、人性化，易于推行和掌握。
三、系统运转方式
（1）隐患分类、清单管理：将隐患内容与清单编码一一对应。
（2）量化管理、规范行为
1.量化隐患排查频次
2.量化响应时效
3．流程对应、责任绑定
该系统实行下来的主要优点有:
（1）项目经理部主要管理人员都参与到隐患排查工作中，人人管安全；
（2）建立了详细的隐患分类、分级标准，规范了具体工作流程，变原有的随机检查为量化检查，工作规范，管理有序；
（3）明确了责任部门、责任人、排查频次、整改时限等，所有节点工作都与具体岗位建立了一 一对应的关系，并通过信息化平台进行绑定，从而有效减少了工作中的推诿扯皮，提高了管理效率；
（4）提高了工作的时效性，管理人员可以随时随地查看、处理隐患治理流程，督促相关人员快速高效地完成隐患治理工作；
（6）为责任追究提供了依据，所有项目的安全质量隐患排查记录均分类保存在系统内，后期如发现工程存在缺陷和隐患，可精确追溯，追究相关人员责任，也提高了人员责任心。
总而言之，该问文章给我们提供了许多良好的管理方法，例如分工明确、责任到人，反馈及时等，这些都有很大的借鉴意义。
系统架构
目前，我们已有的研究基础是杨浩伟师兄的工业隐患上报系统，该系统重点在于知识图谱的构建以及隐患录入组件的实现。即在用户录入隐患描述时，实时获取用户描述中出现的工业领域实体，通过已经建成的知识图谱，实现对工业领域实体识别和消歧，从而实时对用户输入的实体进行语义上的更正和补全，实现工业隐患规录入的规范化。同时把规范化过后的工业隐患实体进行数据库存储。
该系统是基于web技术实现的，前端框架是基于MVVM框架Vue.js,后端接口实现是基于SpringBoot框架。其中：
（1）前端模块主要负责交互工作，采用了组件化的形式，负责用户进行文本输入时的实时更正和补全。
（2）后端模块负责前端模块与数据库的数据交互，主要负责用户输入文本的自然语言处理工作，包括工业领域实体识别和实体消歧等任务。
（3）数据库由中间数据库和图谱数据库组成，知识图谱数据库用于存放知识图谱相关数据，中间数据库用于存放自然语言处理产生的中间数据。后端模块主要负责用户输入文本的自然语言处理工作，包括工业领域实体识别和消歧等任务。
（4）软件环境如下图所示。
随着时间推移，对安全隐患排查的需求将会越来越多，就像上面管理思想中提到的，需要有基础信息服务、考核管理服务、移动办公服务等，简单的软件架构将满足不了实际需求，这时，面向服务的架构（SOA）便脱颖而出。
面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
用途：SOA解决多服务凌乱问题，SOA架构解决数据服务的复杂程度，同时SOA又有一个名字，叫做服务治理。
SOA主要的使用场景
通过上面的图，可以看出，多个子系统直接相互交互，相互调用非常凌乱，所以我们可以用SOA架构，SOA又叫服务治理，SOA就是把服务之间调用的乱七八糟的关系给治理起来，然后提供一个统一的标准，把服务治理成下图所示，以前的服务是互相交互，现在是只对数据总线进行交互，这样系统就变得统一起来。
统一标准：各系统的协议、地址、交互方式。
新的交互方式：各个系统分别根据统一标准向数据总线进行注册，各子系统调用其他子系统时，我们并不关心如果找到其他子系统，我们只招数据总线，数据总线再根据统一标准找其他子系统，所以数据总线在这里充当一个只路人的作用。
SOA的优点：
1、降低用户成本，用户不需要关心各服务之间是什么语言的、不需要知道如果调用他们，只要通过统一标准找数据总线就可以了。
2、程序之间关系服务简单
3、识别哪些程序有问题（挂掉）
SOA的缺点 ：提示了系统的复杂程度，性能有相应影响。
如果系统基于SOA（面向服务）的架构，就必须实现两个子系统之间的远程通信。
那么问题来了：如何实现子系统之间的远程通信？
解决办法：
1. WebService：效率不高，基于soap协议，项目中不建议使用。多用于跨语言跨平台之间的通信，比如两个公司之间的通信。
2. restful形式的服务：http+json可以使用springMVC或者cxf 实现，就是一个风格、一种形式（URL中包含一些参数，并且 URL是没有后缀），本质其实就是get请求传json数据。缺点： 如果服务太多，服务之间调用关系混乱，需要治理服务。
3. Dubbo：基于rpc协议进行远程通信，底层使用socket通信， 传输效率高。具有服务的治理工具（注册中心）进行统一管理， 并且可以统计出系统之间的调用关系、调用次数。
所以，根据上面的比较，我们应该选择Dubbo,来实现SOA架构，接下来将会对Dubbo进行一些简单地了解。
（1）Dubbo是什么
百度百科给出的定义：Dubbo是一个开源的高性能优秀 的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。
（2）走进Dubbo
随着互联网的发展，网站应用的规模不断扩大，常规的垂直应 用架构已无法应对，分布式服务架构以及流动计算架构势在必 行，亟需一个治理系统确保架构有条不紊的演进。
以下是Dubbo官网给出的一张图：
1. 单一应用架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。
2. 垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的 Web框架(MVC)是关键。
3. 分布式服务架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
4. 流动计算架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。
Dubbo就是资源调度和治理中心的管理工具。
（3）Dubbo的架构
节点角色说明：
（1）Provider:暴露服务的服务提供方。
（2）Consumer:调用远程服务的服务消费方。
（3）Registry:服务注册与发现的注册中心（类似于房产中介的作用）。
（4）Monitor: 统计服务的调用次调和调用时间的监控中心。
（5）Container: 服务运行容器（在这里其实就是指的spring）。
调用关系说明：
（0）服务容器负责启动，加载，运行服务提供者。也就是说当我们初始化一个Spring容器的时候，服务就发布了。
（1）服务提供者在启动时，向注册中心注册自己提供的服务。
（2）服务消费者在启动时，向注册中心订阅自己所需的服务。
（3）注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
（4）服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
（5）服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
（4）使用方法
其实Dubbo就是几个jar包，需要我们服务端加入Dubbo jar包来发布服务，客户端如果需要调用服务端分布的服务，也需要Dubbo的jar包。至于注册中心是一个独立的服务，因此还需要zookeeper作为注册中心。
本文内容主要参考来自于：
1. 《浅谈知识图谱基础》》 作者：我偏笑_NSNirvana https://www.jianshu.com/p/4f09043e22ea
2.《一文揭秘！自底向上构建知识图谱全过程》 作者：薇拉 阿里技术 https://mp.weixin.qq.com/s/lBeV6XWzk5bqNGiIMok-zw
3.《深入浅出SOA》 作者：君子如兰 https://www.cnblogs.com/renzhitian/p/6853289.html
4.《Dubbo是什么？能做什么？》作者：洛离Carlos https://blog.csdn.net/houshaolin/article/details/76408399
5. 《Dubbo入门---搭建一个最简单的Demo框架》作者：是Guava不是瓜娃https://blog.csdn.net/noaman_wgs/article/details/70214612
6. 刘峤,李杨,段宏,刘瑶,秦志光. 知识图谱构建技术综述[J]. 计算机研究与发展,2016,(03):582-600.
网友评论