我想向公众展示这本书的片段:
企业本体建模:方法和技术[正文]:专着/ [S。 V. Gorshkov,S。S. Kralin,O。I. Mushtak等; 执行编辑S. V. Gorshkov]。 -叶卡捷琳堡:乌拉尔大学出版社,2019年.-- 234页:伊利诺伊州,Tab。 20厘米-授权 表示在山雀的背面。 s -图书馆 在章末。 -ISBN 978-5-7996-2580-1:200份。
在Habré上计算此片段的目的是三方面的:
- 收集问题和评论,以便在其他出版物中以修订形式包含此文本时予以考虑。
- 要添加与印刷的专着格式不太兼容的附加内容:主题注释(在扰流器下方)和超链接; 以及进行更正(以下均未突出显示)。
- 语义Web和链接数据的许多拥护者仍然认为他们的圈子如此狭窄,主要是因为仍然没有很好地解释公众对语义Web和链接数据的理解。 该片段的作者虽然属于这个圈子,但他并不坚持这样的观点,但是尽管如此,他还是认为自己有义务再做一次尝试。
段落内容
语义网
关联数据
RDF
RDFS
SPARQL
wl
链接企业数据
连接企业数据
文学作品
语义网
互联网的发展可以表示如下(或谈论其细分,按以下顺序组成):
- Internet上的文档 。 关键技术-Gopher,FTP等
互联网是共享本地资源的全球网络。 - 互联网文件 。 关键技术是HTML和HTTP。
公开资源的性质考虑了其传输介质的特征。 - 互联网上的数据 。 关键技术-REST和SOAP API,XHR等
可以说,不仅人们成为资源的消费者。 - 互联网数据 。 关键技术是链接数据技术。
第二阶段的关键技术的创建者和W3C的负责人伯纳斯·李(Berners-Lee)预测,第四阶段被称为语义网。 链接数据技术旨在使Web数据不仅可以机读,而且可以“机读”。
语义网死了吗?搜索引擎非常成功地迫使网站使用RDFa和JSON-LD,并且它们自身使用类似于下文所述的技术(Google知识图,必应知识图等)。
是什么因素阻碍了这些技术在网络上的广泛和深入的使用? 作者无法回答这个问题,但可以根据个人经验发表意见。 在语义网发作的情况下可以“即开即用”地解决的任务是,但不是很广泛,面对这些任务的人对那些能够提供解决方案的人没有强制性的手段。 为后者单独提供解决方案与他们的业务模型相矛盾。
然而,链接数据技术已经超越了大众网络。 实际上,这本书专门针对这些应用程序,链接数据社区目前希望通过捕获(或宣称)Gartner趋势(例如知识图和数据结构)将这些技术在公司环境中变得更加普及。
在2011年的手册中,似乎首先提出了给定的分期: F. Bauer,M.Kaltenböck。 链接的开放数据:要点。 决策者快速入门指南 。
语义网比特定的自发性或游说性趋势更能代表对未来Internet的系统性构想,尽管它能够考虑到后者。 例如,所谓的Web 2.0的一个重要特征是“用户生成的内容”。 W3C的Web注释本体建议和诸如Solid之类的倡议被要求考虑在内。
从下面的内容中,读者将看到第二和第四阶段的关键概念的对应关系:
- URL对应的是URI,
- HTML相当于RDF,
- HTML超链接类似于RDF文档中URI的出现。
关联数据
Berners-Lee将链接数据定义为“精心制作”的语义网:实现最终目标的一系列方法和技术。 链接数据的基本原理Berners-Lee 提出了以下几点。
原则1 使用URI( 统一资源标识符 )命名实体。
URI是全局实体标识符,而不是本地字符串记录标识符。 随后,最好在Google知识图的标语“ 事物,而不是字符串 ”中表达这一原则。
原则2 在HTTP方案中使用URI,以便可以取消引用它们。
转向URI,应该有可能在该指示符后面获得指示符(这里与C中的运算符“ *
”类似)是清楚的; 更确切地说,要了解这一点的含义-取决于Accept:
HTTP标头的值。 也许随着AR / VR时代的到来,就有可能获取资源本身,目前,最有可能的是,RDF文档将是执行DESCRIBE
SPARQL查询的结果。
原则3 使用W3C标准-主要是RDF(S)和SPARQL-特别是在URI取消引用时。
下面将描述链接数据技术堆栈的这些单独的“层”,也称为语义Web层蛋糕 。
原则4 描述实体时使用对其他URI的引用。
RDF允许您以自然语言对资源进行口头描述,第四个原则鼓励不要这样做。 遵循第一个原则,在描述资源时,就有可能引用其他资源,包括“陌生人”,这就是为什么数据被称为相关数据的原因。 实际上,使用在RDFS字典中命名的URI几乎是不可避免的。
RDF
RDF (资源描述框架)是描述相关实体的形式。
关于实体及其关系的声明称为“主题谓词对象”,称为三元组。 在最简单的情况下,主题,谓词和宾语是URI。 相同的URI可以在不同的三元组中处于不同的位置:是主语,谓语和宾语; 因此,三元组形成一种称为RDF图的图。
主题和对象不仅可以是URI,还可以是所谓的空节点 ,对象也可以是文字 。 文字是由字符串表示形式和类型声明组成的原始类型的实例。
编写文字的示例(使用Turtle语法,请参见下文): "5.0"^^xsd:float
和"five"^^xsd:string
。 带有rdf:langString
也可以提供一个语言标签,在Turtle中这样写: ""@ru
和""@ru
。
空节点是没有全局标识符的“匿名”资源,但是可以要求全局标识符。 一种存在变量。
因此(实际上,这是RDF的重点):
- subject是URI或空节点,
- 谓词是URI,
- 对象是URI,空节点或文字。
为什么谓词不能为空节点?可能的原因是希望将三元组spo
非正式地理解并转化为一阶谓词逻辑的语言,例如 在哪里 -谓词 和 是常数。 关于这种理解的痕迹在文档“ LBase:语义网语言的语义 ”中,该文档的状态为W3C工作组说明。 据此,三元组sp []
(其中[]
是一个空节点)将被转换为 在哪里 是一个变量,但是如何转换s [] o
? RDF 1.1语义文档具有W3C建议的地位,提供了一种不同的转换方法,但仍未考虑谓词为空节点的可能性。
但是,Manu Sporny被允许 。
RDF是一个抽象模型。 可以使用各种语法编写(序列化) RDF : RDF / XML , Turtle (最容易被人阅读), JSON-LD , HDT (二进制)。
相同的RDF可以以各种方式在RDF / XML中进行序列化,因此,例如,生成的XML对于用XSD进行验证或尝试使用XPath检索数据毫无意义。 同样,JSON-LD不太可能满足普通Javascript开发人员使用Javascript点和方括号表示法使用RDF的愿望(尽管JSON-LD正在朝这个方向发展,这表明存在一种成帧机制)。
大多数语法提供了缩短长URI的方法。 例如,Turtle中的声明@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
将允许您写而不是<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
仅rdf:type
。
RDFS
RDFS (RDF架构)是基本的建模字典,它介绍了属性和类的概念以及诸如rdf:type
, rdfs:subClassOf
, rdfs:domain
和rdfs:range
类的属性。 例如,使用RDFS字典,可以编写以下有效表达式:
rdf:type rdf:type rdf:Property . rdf:Property rdf:type rdfs:Class . rdfs:Class rdfs:subClassOf rdfs:Resource . rdfs:subClassOf rdfs:domain rdfs:Class . rdfs:domain rdfs:domain rdf:Property . rdfs:domain rdfs:range rdfs:Class . rdfs:label rdfs:range rdfs:Literal .
RDFS是描述和建模的词典,但不是限制语言(尽管官方规范保留了这种用法的可能性)。 不应以与表达“ XML Schema”相同的含义来理解单词“ Schema”。 例如:author rdfs:range foaf:Person
表示:author
属性rdf:type
所有值的rdf:type
为foaf:Person
,但这并不意味着应提前说明。
SPARQL
SPARQL (SPARQL协议和RDF查询语言)是RDF数据的查询语言。 在简单的情况下,SPARQL查询是一组与图表的三元组进行比较的样本。 可以在样本中位于主题,谓词和宾语位置的变量中找到变量。
查询将返回这样的变量值,当这些变量值被替换为样本时,可以生成所查询的RDF图的子图(其三元组的子集)。 在不同的三元组样本中具有相同名称的变量必须具有相同的值。
例如,在上面的七个RDFS公理集中,以下查询将返回rdfs:domain
和rdfs:range
作为?s
和?p
的值:
SELECT * WHERE { ?s ?p rdfs:Class . ?p ?p rdf:Property . }
值得注意的是,SPARQL是声明性的,而不是用于描述图形遍历的语言(但是,某些RDF存储库提供了调整查询执行计划的方法)。 因此,某些标准图形任务(例如,找到最短路径)无法在SPARQL上解决,包括使用属性路径机制(但同样,单个RDF存储库提供了用于解决这些问题的特殊扩展)。
SPARQL不认同世界的开放性,而是遵循“否定即失败”的方法,因为这样的构造可能是FILTER NOT EXISTS {…}
。 使用联合查询机制考虑了数据分配。
SPARQL访问点(一种能够处理SPARQL查询的RDF存储)从第二阶段开始就没有直接的对应关系(请参阅本节的开头)。 可以根据生成HTML页面的内容将其比作数据库,但可以从外部访问。 SPARQL访问点与第三阶段的API访问点类似,但有两个主要区别。 首先,可以将多个“原子”查询组合为一个(这被认为是GraphQL的关键特征),其次,这样的API是完全自记录的(这是HATEOAS试图实现的)。
言论RDF是一种在Web上发布数据的方法,因此RDF信息库应被视为记录的DBMS。 的确,由于RDF是图形而不是树,因此它们也被证明是图形。 发生的事真令人惊奇。 谁会想到有实现空白节点的聪明人。 考德没有成功 。
功能较少的组织访问RDF数据的方法,例如, 链接数据片段 (LDF)和链接数据平台 (LDP)。
wl
OWL (Web本体语言)-知识表示的形式主义,描述性逻辑的句法版本 (下面所说的OWL 2更为正确,OWL的第一个版本基于 )
类对应于OWL中描述逻辑的概念,属性对应于角色,个人保留其以前的名字。 公理也称为公理。
例如,在用于编写OWL的所谓曼彻斯特语法中, 我们已经知道了公理 将这样写:
Class: Human Class: Parent EquivalentClass: Human and (inverse hasParent) some Human ObjectProperty: hasParent
还有其他用于编写OWL的语法,例如,官方规范中使用的功能语法和OWL / XML 。 此外,可以将OWL序列化为抽象RDF语法 ,然后再序列化为任何特定语法。
与RDF相关的OWL在两个方面起作用。 一方面,它可以看作是扩展RDFS的一种字典。 另一方面,它是一种更强大的形式主义,RDF只是一种序列化格式。 并非所有的OWL基本构造都可以使用单个RDF三元组编写。
根据允许使用OWL构造的哪个子集,它们讨论了所谓的OWL配置文件 。 标准化和最著名的是OWL EL,OWL RL和OWL QL。 配置文件的选择会影响典型任务的计算复杂性。 一套完整的OWL设计匹配 ,称为OWL DL。 有时,他们还会谈论OWL Full,其中允许在RDF固有的完全自由的情况下使用OWL构造,而没有语义和计算上的限制 。 例如,某些东西既可以是类,也可以是属性。 OWL Full无法解决。
赋予OWL效力的关键原则是接受开放世界假设( OWA )和拒绝唯一名称假设( UNA )的推定。 下面我们将看到这些原理可以导致并熟悉某些OWL构造。
让本体包含以下片段(以曼彻斯特语法):
Class: manyChildren EquivalentTo: Human that hasChild min 3 Individual: John Types: Human Facts: hasChild Alice, hasChild Bob, hasChild Carol
从上面可以得出约翰大吗? UNA的拒绝将迫使输出引擎否定地回答这个问题,因为Alice和Bob可能是同一个人。 为了进行以下操作,您需要添加以下公理:
DifferentIndividuals: Alice, Bob, Carol, John
现在,本体的片段具有以下形式(声明为John很大,但只表示了两个孩子):
Class: manyChildren EquivalentTo: Human that hasChild min 3 Individual: John Types: Human, manyChildren Facts: hasChild Alice, hasChild Bob DifferentIndividuals: Alice, Bob, Carol, John
该本体是否会不一致(可以解释为无效数据的证据)? OWA的采用将迫使输出引擎做出否定的响应:在其他地方(在另一种本体论中)“某处”应该说卡罗尔也是约翰的孩子。
为了排除这种可能性,我们添加了一个有关约翰的新事实:
Individual: John Facts: hasChild Alice, hasChild Bob, not hasChild Carol
为了排除其他孩子的外表,我们说“有孩子”财产的所有价值都是人,我们只有四个人:
ObjectProperty: hasChild Domain: Human haracteristics: Irreflexive Class: Human EquivalentTo: { Alice, Bill, Carol, John }
现在,该本体将引起争议,输出引擎将不会报告该本体。 从某种意义上说,最后一个公理是“封闭”世界,并注意如何排除约翰自己是个孩子的可能性。
链接企业数据
一组链接数据的方法和技术最初旨在在网络上发布数据。 在公司环境中使用它们面临许多困难。
例如,在封闭的公司环境中,基于OWA的采用和UNA的拒绝,OWL的演绎能力太弱了,这是由于Web的开放性和分布式性导致的决策。 在这里,以下输出是可能的。
- 赋权OWL语义,涉及放弃OWA和采用UNA,并实现相应的输出引擎。 -这样,Stardog RDF存储就可以了。
- 放弃OWL的演绎功能,转而使用规则引擎。 -Stardog支持SWRL ; Jena和GraphDB提供了自己的规则语言 。
- 拒绝OWL的演绎可能性,用于对接近RDFS的一个或另一个子集进行建模。 -稍后再看。
另一个问题是,在企业界,人们可能更加关注数据质量问题,并且在链接数据堆栈上缺少数据验证工具。 输出如下。
- 再次,在存在适当的验证输出引擎的情况下,将OWL构造与封闭世界的语义和名称的唯一性一起使用。
- 使用SHACL ,在固定了语义Web层蛋糕的层列表(但是也可以将其用作规则引擎)或ShEx之后进行标准化 。
- 意识到所有事情最终都由SPARQL查询完成,使用它们创建了我们自己的简单的数据验证机制。
但是,即使完全拒绝演绎功能和验证工具,在数据集成任务中,Linked Data堆栈在与开放式和分布式Web类似的任务中也无与伦比。
常规的公司信息系统如何?在这里,我将描述开发参与者的典型初始反应,以显示从传统IT角度来看该堆栈的外观(提醒大象的寓言):
- 业务分析师 :RDF类似于直接存储的逻辑模型。
- 系统分析员 :RDF是EAV ,只有一堆索引和便捷的查询语言。
- 开发人员 :好吧,这全是出于丰富模型和低代码概念的精神, 我最近对此有所了解。
- 项目经理 :是的,它正在崩溃 !
实践表明,堆栈最常用于与数据的分布和异构性有关的任务,例如,在构建类MDM(主数据管理)或DWH(数据仓库)的系统时。 此类任务可在任何行业中使用。
对于特定于行业的应用程序,链接数据技术当前在以下行业中最受欢迎。
- 生物医学技术(其受欢迎程度显然与主题领域的复杂性有关);
相关的这里的原因是主题领域的复杂性,例如,在上游阶段,如果我们谈论石油和天然气行业,那么简单的会计就需要具有一些CAD功能。
2008年,雪佛龙组织了一次代表安装会议 。
最终,ISO 15926对于石油和天然气行业似乎有点沉重(并发现几乎在机械工程中有更多的应用)。 只有挪威国家石油公司(Equinor)彻底坐在上面,在挪威周围形成了整个生态系统 。 其他人则试图做自己的事情。 例如,据传言,国内能源部打算建立一个“燃料和能源综合体的概念本体模型”,这显然是为电力行业创建的 。
- 金融组织(甚至XBRL也可以被视为SDMX和本体RDF Data Cube的混合体);
相关的年初以来,LinkedIn积极地给作者散布了几乎所有金融业巨头的空缺,他的名字他知道:高盛,摩根大通和/或摩根士丹利,富国银行,SWIFT / Visa /万事达卡,美国银行,花旗集团,美联储德意志银行。 顺便说一下,在知识图会议上,金融机构占据了第一天的整个上午 。
在HeadHunter上,只有Sberbank遇到了一些有趣的事情,那就是“具有类似RDF的数据模型的EAV存储”。
国内外金融机构对相应技术的热爱程度差异可能是由于后者活动的跨国性所致。 显然,跨越国界的整合需要本质上不同的组织和技术解决方案。
- 具有商业应用程序的问答系统(IBM Watson,Apple Siri,Google Knowledge Graph);
相关的顺便说一下,Siri的创建者Thomas Gruber是本体的定义(从IT角度而言)作为“概念化规范”的作者。 我认为,此定义中单词的重新排列不会改变其含义,这可能表明它不存在。
- 发布结构化数据(有充分理由可以将其归因于链接开放数据)。
相关的关联数据的忠实拥护者-所谓的GLAM:画廊,图书馆,档案馆和博物馆。 可以说,取代MARC21,国会图书馆正在推广BIBFRAME ,它为书目描述的未来提供了基础 ,当然,它是基于RDF的。
通常,作为链接开放数据领域中一个成功项目的示例,Wikidata是Wikipedia的一种机器可读版本,与DBPedia相比,Wikipedia的内容不是通过从文章的信息框导入而生成的,而是或多或少手动创建的(随后成为同一信息的信息源)信息框)。
我们还建议您熟悉Stardog网站“客户”部分中的Stardog RDF商店的用户列表 。
尽管如此,在Gartner的2016年新兴技术炒作周期中,企业分类法和本体管理处于下降的中间,陷入失望的谷底,并有望在10年后达到“生产力平稳期”。
连接企业数据
一点历史从历史的兴趣出发,他将Gartner对我们感兴趣的技术的不同年份的预测推上了表。
但是,已经在2018年的“炒作周期...”中出现了另一个上升趋势-知识图。 有一定的转机:在前者的要求和后者的习惯的影响下,图形化的DBMS引起了用户的注意和开发人员的力量,开始采用其前任竞争对手的轮廓和位置。
现在,几乎每个图形DBMS都宣称自己是构建公司“知识图”的合适平台(“链接数据”有时被“连接数据”代替),但是这样的主张有多合理?
图形数据库仍然是语义数据库,图形DBMS中的数据仍然是相同的数据孤岛。 URI , RDF- RDF-. — LPG, .
, . , SQL.
, RDF- LPG. , Blazegraph: RDF*, RDF LPG.
更多细节RDF- LPG : « RDF-» . Knowledge Graphs Data Fabric , , . , , , , . : Data Fabric — , , NoETL, Knowledge Graph — , , Data Fabric done right.
文学作品
- Halpin, H., Monnin, A. (eds.) (2014) Philosophical Engineering: Toward a Philosophy of the Web
- Allemang, D., Hendler, J. (2011) Semantic Web for the Working Ontologist (2nd ed.)
- Staab, S., Studer, R. (eds.) (2009) Handbook on Ontologies (2nd ed.)
- Wood, D. (ed.). (2011) Linking Enterprise Data
- Uschold M. (2018) Demystifying OWL for the Enterprise
- Keet, M. (2018) An Introduction to Ontology Engineering