信息化的本质分享 http://blog.sciencenet.cn/u/Babituo

博文

基于统一语言学设计含义库管理系统

已有 635 次阅读 2021-8-10 10:28 |个人分类:面向资源软件开发方法|系统分类:科研笔记

面向资源应用架构底层子系统的设计。语义概念讨论看似简单,但可展开内容实在太多,所以保留不展开,简言之,NLP不应该模仿人类语言在人类认知面前的苍白无力,而应转向认知本身的内蕴拓扑。本文重点关注应用软件的架构模式的变革需求,不陷入语义问题学术讨论。


基于统一语言学设计含义库管理系统


摘要

本文从应用软件的技术发展趋势分析中发现了当前应用软件架构模式与需求不相适应的矛盾:单纯以数据库为基础的架构模式与应用软件不断增长的规模体量、覆盖时空范围、整合业务数量越来越不相适应。本文提出应从架构层面引入以知识信息管理为基础服务层次,实现应用程序与业务逻辑的无关性。在统一语言学的启发下,解决了对“含义”对象进行信息建模难题。通过完成含义库管理系统的概要设计,展现了一个对当前应用软件体系结构升级改进的具体实施方案。该方案通过含义库引入模型聚合层,对应用软件的信息资源实现分层结构化组织。本文最后对升级前后两种架构模式进行了对比分析,说明了新架构模式的优势。


关键字:软件架构,统一语言学,含义库管理系统,模型聚合,分层结构化

一、引言

1. 技术背景

众所周知,在软件技术发展的历史上经历了数据与程序的分离,产生了数据库产品,推动了应用软件体系结构的第一次飞跃式进步。

随着时代的进步,人们已经认识到:数据不等于信息,信息不等于知识,知识不等于智能。作为信息系统记忆载体的通用资产,数据库管理系统DBMS目前仍占主导地位。尽管信息系统的应用需求,已经从数据管理到知识管理、再上升到智能认知的层次了,应用软件的程序却仍然要“单纯在数据层劳作”:从数据库服务器查询请求数据,通过数据挖掘和分析来得到信息,再通过事先编好的软件程序来处理信息,固化用户可重用的知识。

智能认知的终极目标,是让机器具有认知能力,让机器学会思考,其中最基础的关键环节,是让机器能理解自然语言的含义。这对应用软件的体系结构提出了新的要求。研究开发一种含义库管理系统,可在语义层融合数据,将部分数据服务转换为含义服务。使得应用软件无需关注太多的底层数据的处理,可在知识与智能的层面实现对更大范围、更大规模的应用整合,对解决应用软件需要整合的规模、范围不断扩大与开发、运行效能不断降低的矛盾将发挥重大作用。

2. 含义库管理系统设计的关键问题

含义库管理系统用于在具体应用中建立和维护含义库,并基于含义库的内容向应用程序提供含义服务。

含义服务的本质是将从程序中分离出来的知识信息模型保存在服务端,以共享公共模型方式提供的知识信息服务。含义服务器的设计目标,是让客户端应用程序在运行中遇到某个“听不懂”的含义、“搞不清”的含义关系时,可向服务端请求对含义及其关系理解的服务。

通常,对人来说,“含义”概念很好理解,就是某个“可见的表达”所代表的“隐含的意思”,是人轻易就能领会的东西。要想让计算机能理解和处理含义,就必须对含义概念进行信息建模。怎么在计算机中来准确描述“含义”这个概念呢?含义和语义是同一个概念么?含义和语义、以及语言之间到底是什么关系呢?信息建模本来就是给数据命名来赋予数据含义,并通过含义的关联来建立应用对象的数据模型的,对含义自身又怎么进行信息建模呢?这是一个基本的关键问题,看上去却存在一个循环定义的死结。

含义服务是从软件架构模式层面提出的改进方案,需要将传统软件架构中以中间件方式实现在领域对象模型的业务逻辑知识,以标准的描述文档的方式纳入持久层管理并提供服务,使得应用程序只需通过通用的资源引擎来对标准描述文档进行解析运行,以此来实现业务逻辑与程序代码的无关性。这要求描述文档不仅要以标准化的方式描述业务静态信息组织结构,还需要能描述其动态处理过程,成为可执行的对象化模型资源。

在新的架构模式之下,应用软件可以实现为以通用的资源引擎为核心组件的程序,这是一个对模型资源的通用解析执行引擎、视图生成渲染引擎与交互操作控制引擎的自动化流水线组合体。如何设计一种标准的对象化模型资源,才能既满足业务逻辑知识表达的需求,又能被通用的模型解析引擎执行,是实现“模型驱动”的核心关键问题。

3. 当前解决方案的不足

截止到目前,应用软件实现从数据层到知识层的标准化,主要经历了如下的技术路径:

(1) 数据库管理系统技术;

(2) 基于数据仓库的商业智能BI技术;

(3) 大数据处理技术;

(4) 知识图谱技术。

其中(1)(2)(3)的技术路径是传统数据库技术路径及其扩展和延伸,体现的是单纯在数据层劳作架构模式。也正是因为应用程序单纯在数据层劳作,才导致随着应用软件整合的复杂性、体量规模、时空覆盖范围不断扩大的情况下,带来业务数据在数据源头、体量规模、类型种类与价值被隐没等方面的挑战急剧增长,应用程序的大数据处理压力越来越大,瓶颈越来越突出。

在大数据淹没信息的危机中,知识图谱技术率先在搜索引擎技术领域暂露头角。它利用语义网技术给大量分散繁杂的互联网数据添加了语义信息的脉络关系,通过建立数据的语义连接,大大提升了搜索引擎的查询效率,突显了知识信息的作用,展现了“大数据只有在经过清洗、整治、融合、梳理,抽取出有机联系的知识信息,才能发挥出其应用的价值”的规律。

知识图谱技术只是作为一种“单纯在数据层劳作”架构模式下的“补丁”技术在应用,未能完成应用软件的架构模式的变革。知识图谱与数据库技术的不同,在其将信息处理技术从数据层提升到了知识层面,为应用软件的架构模式变革带来了契机。

如果应用软件能随着其体量规模的扩大,演进出“在数据层、知识层、智能层分层递进、协同运行”的架构模式,将信息处理的压力分层标准化到各个层次,那就可以期待,目前出现的大数据挑战就可被彻底解决,甚至还可以为未来可能出现的“大知识挑战”、“大智能挑战”的危机未雨绸缪。

二、统一语言学的启示

1. 统一语言学观点

统一语言学起源于高庆狮对多语言机器翻译系统的理论研究成果的总结[1]。其着重研究了一套语义学的基础理论和方法,以确保在多种自然语言表达之间相互转换的有效性和准确性。

为了能够在多种自然语言表达之间来回切换而确保所表达的含义不变,但语言使用习惯能随之变换,高庆狮分析了各种自然语言的语义所表达的对象,都能归根到人的感觉与知觉表象,即:包括视觉、听觉、触觉、味觉、嗅觉、内觉和知觉等,被归纳为7觉的感受结果。

准确地说,这些感受结果就是人脑的认知。人脑认知被认为是语义所表达的对象。在没有“心灵感应”支持的情况下,人脑认知是隐藏的、无法被外界直接感知到的。如果某个人掌握了多门自然语言,他就可能将其头脑中某个认知做不同自然语言的不同语句的表达,这正是多语言翻译能够成立的根本所在。

按照统一语义学的上述观点,可以做如下结论:

(1) 含义不是语义,语义也不是含义。

(2) 含义是语义所表达的对象,是人头脑中的认知结果。

(3) 语义是某人用某类自然语言的语句所表达的意思,在统一语言学中被称为“句义”,即“句子的语义”的简称,可见,语义与语言和语句相关,而含义,只与人脑认知相关。

每一个表达,不仅包含其语句符号内容信息,还包括使用人,使用场景的信息,共同决定这个语句的独特意思,当这个意思与其头脑中的某个具体认知产生了准确对应,也就是建立了“语义”与“含义”正确的映射关系时,就得到了一个成功的表达,而不是语义和含义的概念相同,同理,错误的表达就是建立了语义和含义的错误对应关系。

2. 语义与含义概念的关系

为了避免概念混淆,这里把“语义”改称更准确的名称:“句意”,即“语句所表达的意思”的简称。这样改称带来的好处是:语句是一个可数字化描述的对象,如果忽略语句特定的使用场景与个人的差异,单凭语句的类符号内容就能唯一地对应到“句意”,于是可宽泛地得到“句意”的数字化表达——语句的类符号内容。这为数字化表达含义创造了机会。

分析句意与含义的关系可知:

(1) 句意是对含义的表达,含义是内隐的,句意是外显的;

(2) 当表达正确时,句意可代表含义;当表达错误时,句意不能代表含义。

(3) 一个含义可以用多个句意来表达,一个句意也可能在不同的人和不同的场景下表达不同的含义。

由此可见,虽然含义是内隐的,但因为可用正确表达的句意来代表,在极端情况下,假设所有的句意都能正确表达含义,那么,句意就可以直接代表含义了。事实上,一个语句总能完全正确、准确地表达其含义的概率并不是很大。通常,能够找到的用来表达相同含义的语句越多,这些句意共同锁定的含义就越确切。

3. 对含义的表达方法

在统一语义学的启发下,理清了语言、语义和含义之间的概念关系,找到了两类含义的表达的方法:

(1) 客观含义表达方法:多个同义的不同语句,在表达正确的前提下,可代表一个独立的客观含义(客观真理)。

(2) 主观含义表达方法:多个已知采用人和采用场景的不同语句,在表达正确的前提下,可代表一个独立的主观含义。

上述主观表达中的采用场景,看似未能做确切描述。实际上,可以将场景当作一个含义来处理:也就是每一个主观含义的场景,都可以用一个客观或主观的含义来代替,称为“场景含义”,如果场景含义又需主观表达,则会产生递归的场景含义表达。由于场景含义只是主观含义表达的辅助因素,主观含义的定位对场景含义的敏感度远小于含义表达的语句本身,所以,经多次场景含义的递归表达后,起始场景含义就可以很快收敛到所需的精度范围内,就可以使其起始主表达语句确切确定其含义。

对含义可建立置信度属性,其表达所用语句越多,置信度就越高,其表达确切的概率也就越大。

对含义可建立置信度属性,其表达所用语句越多,置信度就越高,其表达确切的概率也就越大。

三、含义库管理系统设计

1. 图1.JPG
总体架构

 

 

 

 

 

 



 






3-1 含义库管理系统总体架构图

含义库管理系统是用来建立和维护含义库实例,底层对接通用文档服务器存取对象化含义文档,顶层向应用客户端提供含义服务的服务系统。

如图3-1所示,含义库管理系统包含服务端和管理客户端。

管理客户端包括服务器的管理用户界面,为含义库管理员提供管理维护,含义库运行状况监测,运行日志查看等功能页面。

含义库服务端分为五层模块组成。

(1) WEB服务接口模块

WEB服务接口层封装含义服务器对外的web服务接口,对外接受web服务请求。

(2) 含义服务控制器模块

含义服务控制器模块将WEB服务接口层接到的服务请求转换为对含义服务器功能的调用,并将返回结果封装为JSON格式的文档返回到客户端。

(3) 含义服务器模块

含义服务器模块解析执行含义服务请求的核心模块。它将维护性服务请求转换为对含义对象关系模型的维护操作;将查询类服务转换为对含义及含义关系的查询操作。

(4) 含义对象文档缓冲池模块

含义对象文档缓冲池将含义服务器执行服务请求时用到的含义对象文档按类型进行缓存管理,以提高含义服务的性能。

(5) 文档数据库接口模块

文档数据库接口负责向分布式的文档服务器请求含义对象文档的持久化服务,包括存储、调出、更新和查询相关的含义对象文档。

2. 含义服务器核心模块的对象模型

图2.JPG



 

 

 

 

 

 

 

 

 

 

 








3-2 含义服务器对象模型

3-2是根据统一语义学启示建立的含义库管理系统的对象关系模型。模型分为内核层和表达层两层。内核层聚集了抽象的内隐概念及其关系;表达层聚集了表达概念及其关系。两层之间通过实例类拓展/泛化概念,通过表达类建立相互联络。

从继承关系看模型的概念拓展关系如下:

(1) 含义类是元概念类。

(2) 类型类、实例类和关系类是三类具体的基本含义类。

(3) 主体类、场景类、表达类、表达式类是四类具体的实例类。

(4) 语句类、词语类是两类具体的表达式类。

所有的概念类都是含义类的具体类,并可根据应用的需求不断拓展新的概念类。

从关联关系看模型的概念联系如下:

(1) 一个含义与多个含义存在关联,一个关联就是一个关系。

(2) 一个含义归属于一个类型,多个含义可归属同一个类型。

(3) 一个含义可用多个表达式表达,这多个表达式是同义表达式。

(4) 一个表达式可表达多个含义,这多个含义是同形含义。

(5) 一个表达式与一个含义的关联是一个表达。

(6) 一个表达由一个主体做出,一个主体可做出多个表达。

(7) 一个表达在一个场景下做出,在一个场景下可做出多个表达。

(8) 一个语句使用多个词语,一个词语可供多个语句使用。

以上的所有概念关联关系都是关系的具体类型。

在此元模型的基础之上,采用面向资源的建模方法[3],可以建立对象化模型资源描述通用标准,实现“模型驱动”的设计目标。

3. 含义服务web接口设计

含义服务web接口是提供外部应用程序调用的功能接口,用来构建维护和使用含义库。其中含义库构建维护操作包括:

(1) 新建和销毁一个含义库。

(2) 在含义库中新建和删除一个含义对象,其中的含义对象包括:类型、关系、主体、场景、语句、词语等具体含义类的对象实例,以及含义库可能拓展定义的其他具体含义类的对象实例。

含义库的使用操作如下:

(3) 开启和停用一个含义库。

(4) 在含义库中查找是否存在某个含义对象。

(5) 在含义库中查找满足含义关系条件的含义对象集。

(6) 查找一个表达对象的所有同义表达对象。

(7) 查找一个表达对象的所有同形含义对象。

(8) 查找含义对象的确切度(从一个含义对象的同义表达对象的个数推算出来的含义对象的可信度指标)

由于含义是内隐的对象,应用程序使用到含义对象用于UI界面显示时,只能用该含义对象的同义表达对象中的某一个的表达式来做语义标识。在程序内部处理中,用到含义对象时,就要在内部完成同义表达对象对含义对象的转换,使用同义表达对象中记录的含义对象索引标识进行内部的查询计算。

二、架构特征对比分析

含义库的设计目标是为应用软件系统演进出一种新的架构模式,在新的架构模式下,应用程序可在“知识层次的信息服务”的支撑下,获得更大规模体量、时空范围和复杂度的应对能力。相对传统单纯在“数据层劳作”的架构模式,新的架构模式将应用系统的业务信息资源进行了“分层结构化”的组织,运用了“分层结构化设计”[2]的设计理念和原理,可称为“分层结构化”的架构模式。

4-1描述了在数据库支撑下的“数据层劳作”典型三层应用的架构模式的应用系统架构。


 

图3.JPG

 4-1 典型三层应用的架构模式系统架构图

4-2描述了在含义库支撑下的“分层结构化”多层应用的架构模式的应用系统架构。

图4.JPG
 

 

 

 

 














 

4-2分层结构化多层应用的架构模式应用系统架构图

4-1对两种架构模式的特征进行了对比分析,由于含义库管理系统尚在设计阶段,其中应用性能对比为定性分析,量化分析对比需待实践开发后进行。

 4-1 两种架构模式的特征对比分析

序号

方面

对比特征项

数据层劳作

分层结构化

备注

1

架构层次

表现层

基于WEB前端页面应用

2

业务逻辑层

原生编程业务逻辑与数据服务

3

模型聚合层

含义关系建立对象化资源模型

4

数据持久层

数据持久化与查询服务

5

服务组件

系统管理

包括用。户、权限、文档管理等

6

领域管理

包括业务逻辑代码实现

7

资源引擎

包含模型、控制、视图引擎

8

含义服务器

包括含义服务器管理服务接口

9

应用特性

原生开发

支持

支持

使用编程语言编写前端页面和应用服务

10

数据服务

支持

支持

包括文档服务

11

含义理解

不支持

支持

同义表达与同形含义转换,含义关系感知

12

模型驱动开发

不支持

支持

用建模工具低代码开发资源模型

13

服务生成

不支持

支持

通过模型引擎动态生成服务

14

页面生成

不支持

支持

通过视图引擎动态生成前端页面

15

数据融合

不支持

支持

跨应用通过含义库资源模型融合数据

16

模型聚合

不支持

支持

将分布式部分模型聚合为完整统一虚拟整体模型

17

应用性能

可演进性

不支持

支持

架构的迭代演进无需代码重构

18

开放性

较差

较好

系统边界可拓展、可融合能力

19

灵活性(柔性)

较差

较好

系统功能调整变更拓展方便快速

20

复杂性

较低

较高

开发运维的工作的繁杂与实现需求功能的复杂度同比。

21

规模

较小

较大

应用功能数量,覆盖业务范围。

22

信息密度

较小

较大

单位数据量包含可用信息量

三、总结

本文从应用软件的技术发展趋势分析中,发现了以数据库为基础的当前应用软件架构给应用程序带来的数据处理任务不断攀升,与应用软件不断增长的规模体量、覆盖时空范围、整合业务数量上的需求不相适应,造成应用软件的开发效能不断下降的矛盾。本文提出应建立以知识信息持久化为基础服务层次,实现应用程序与业务逻辑的无关性。在统一语言学的启发下解决了含义对象的信息化表达难题,通过设计开发一种含义库管理系统来实现对一般应用软件体系结构的升级改进,以期对应用软件系统的信息资源实现分层结构化的组织,最后完成了含义库管理系统的概要设计,并对两种架构模式进行了分析对比。

在此工作基础上,后续的工作需要进行系统的详细设计并编码实现。在实现含义库管理系统之后,再将其作为一个通用的服务组件来开发试点应用系统,首个试点应用系统就可以尝试开发一个多语言翻译系统平台。

参考文献

1】《统一语言学基础》

2】《变值体系理论基础及其应用》

3】《面向资源的应用软件开发方法》


当含义库积累的含义数量达到一定数量后,就可以展开“语义拓扑”的研究了。
参考:黎曼面和语义拓扑。http://blog.sciencenet.cn/blog-33982-1290073.html



http://blog.sciencenet.cn/blog-33982-1299105.html

上一篇:突破终极限制的数——极数
下一篇:重新理解普利高津“非平衡是有序之源”

1 郑智捷

该博文允许注册用户评论 请点击登录 评论 (4 个评论)

数据加载中...
扫一扫,分享此博文

Archiver|手机版|科学网 ( 京ICP备07017567号-12 )

GMT+8, 2021-10-21 16:36

Powered by ScienceNet.cn

Copyright © 2007- 中国科学报社

返回顶部