最近在考虑两个点的工作分别是模糊本体和本体对齐但都处于比较卡壳的状态的。再考虑到现实情况就是安全专业和以后就业需求看下加密流量的文章就我目前的了解来说加密流量的文章主要还是用数据分析的或AI的技术来做的只不过分析对象是加密流量。从应用型论文的角度来说既需要了解应用场景有需要熟悉分析技术AI是分析技术安全是应用场景很多论文都是这个路数弄出来的不能完全说灌水有些确实有用。不是看了就一定要基于这个方向弄文章只是先了解一下有充分认识之后再做后续考虑。初步了解和动机由于我做的是安全领域本体这种比较小众的方向得益于创新资助计划才沿着本体工程这个思路做了几篇文章。但是如果没有创新资助的话我曾经考虑两个事。第一沿着UCO1的思路建模模糊安全本体话说为什么我弄的论文阅读博客能在bing学术上搜到好尴尬第二做安全本体的融合也就是本体对齐匹配。这两个方向都只是想过没有实际去做感觉太难/懒。模糊本体考虑对知识的不确定性和概率建模按照UCO的展望描述安全领域确实需要这样的模糊本体。我个人觉得的难点是1高质量的建模太困难现在哪怕是UCO也只是少数的领域建模尝试如果想要作为公开的本体资源文章的话resource paper很难2实用性验证的说服力除了持续说本体的推理有可解释性之外在实际安全应用上很难看出它的优势。本体对齐做本体库很自然想到不同来源的本体库的融合问题我曾想做安全领域的本体对齐但发现行不通。我认为的难点是1和我做安全本体工程类似最难说的一点就是如何说明我的方法适用于安全领域特定领域实际上我并没有太多对安全领域的特殊考虑。便陷入这样的矛盾中若要做领域特定的方法那就必须对该领域有特别的优化否则就是通用方法能够PK过别人的方法2目前本体匹配是一个相对较卷的方向有OAEI的比赛想做出能发表的文章那就要多接触前沿的机器学习深度学习这些我这些基础目前还不太行要补上。因为我是网安专业不能做完全抛离网安的方向但现在不用受这个桎梏了。3对1补充经过初步了解一个方法的好坏不同领域有其差异性比如某OAEI轨道该方法第一换个轨道就不是第一了但只要有比较好的表现就算不错。可是从方法实现来说看不出方法对某个领域有特殊的设计所以稍微总结一下就是好的方法在不同领域都应该有不错的表现但如果是在某个领域表现好那就要体现方法实现为什么能在该领域有好的表现不是仅仅使用了该领域的数据集这么简单。加密流量最直接的任务是加密流量分类任务是个很卷的方向以后做所谓的弹性网络评估我觉得多少都会接触到一些。目前想法不需要资格论文所以可以相对稍缓一些写出后用于工作。这两个点都可以考虑并且都不是短期内可以出东西的方向。安全本体建模要达到真正可发布可复用作为长期建模优化的工作不是随便画张图设置几个概念就可以拿去水文章的本体对齐需要先复现别人的了解清楚流程细节和评估手段之后去做指标上的提升工作同样不是一时半会就能出内容的。另外只有真正有价值的工作才会被不断引用和比较。调研1模糊本体现有代表性工作和近期文章此前有关于Fuzzy OWL 2的插件的研究。搜索关键词有“fuzzy logic”、“fuzzy ontology”有很多数学占比高的文章晦涩难懂。就目前看来多数文章讨论模糊逻辑时会把不确定性和概率事件作为本体描述能力之外的内容并且把这个当做本体的问题引出模糊性的讨论。应先考虑清楚模糊安全本体应当是怎样的有什么作用文章题目年份开源问题和方案解读实验解读Fuzzy ontology representation using OWL 222011是语义Web语言需要处理模糊信息的能力要用一种标准的方式来表示这些信息。作者开发了protege的插件用于模糊本体建模与推理。实验才用的是讲解建模案例的形式这篇文章的工作量很扎实。调研2本体匹配现有代表性工作和近期文章此处列举比较有代表性的工作记录来源。可以搜索关键词“ontology alignment”、“ontology matching或者ontology fusion”都是本体匹配相关的文章文章数量挺多的。这是本体领域的“打榜类”的方向仔细了解下可以熟悉相关技术路线。文章题目年份开源问题和方案解读实验解读Ontology alignment with semantic and structural embeddings32023是声称过去工作主要是基于外部词典和本体结构的预定义规则换言之以旧方法为主而这篇文章要使用深度学习了此为方法优越。在效果上就是优于baseline。作者的说法是证明了学习语义表示和结构表示的重要性。实验仓库关注的人不多从readme来说介绍了预处理步骤看起来有可信度值得花时间去了解一下实验细节。实验先介绍了训练时间和超参数设置验证度量。随后就是在Foodon和Helis上的实验测试有Mappings数量、RecallG S ^{GS}GS、Precision≈ ^{\approx}≈、Recall≈ ^{\approx}≈、F1≈ ^{\approx}≈这些指标。而在OAEI tracks上面则是使用Total/correct、Precision、Recall、F1等指标。此外还有所谓的消融实验Ablation study看来本体对齐主题的文章都有它们算提出AI模型类的文章消融实验可能是必需品了。在Foodon和HeLis的实验上对比的方法有LogMap2、AML、LogMap-ML、RDGCN在OAEI的conference track对比的方法有AML、GMap、LogMap、Wiktionary、TOM、AMLl o c a l ^{local}local、LogMapl o c a l ^{local}local、LogMap-ML、RDGCN等对比表格分成了两大行。Ontology Matching Method Based on Deep Learning and Syntax42025否声称为解决本体异构问题文章提出一种融合循环神经网络和句法分析的混合本体的匹配方法。这里的问题是本体对齐的目的虽然这么说是对的但就缺少了针对性因为所有做本体对齐的工作都是为了解决本体异构问题的过于笼统。方案是基于深度学习的方法利用本体树结构中的入度和出度信息提取具有代表性的实体。训练数据集均来自OAEI用若干case表示。和来自OAEI的代表性方法对比包括AML、LogMap家族LogMap和LogMapBio、PhenoMF、以及基于Transformer的方法。为了比较作者提的N-gram作者将其和另外两个相似度度量方法替换并对比即SimRank基于结构和Wu-Palmer基于语义。作者也做了所谓消融实验最终还比较了LSTM和GRU的时间空间复杂度LSTMN-gram、GRUN-gram。Ontology Alignment Approach Based on Attribute Self-Adaption Mechanism and Hetergeneous Feature Fusion52025否指出本体对齐面临三个问题1、reference mapping缺乏隐式语义2、类嵌入之间错误的高相似性3、训练数据不平衡。提出主动学习本体对齐方法。在文章摘要处提及了重建reference mapping避免false positive对齐类一定程度上紧扣所提问题。使用8个数据集有来自OAEI的。对比的基线方法有String-matchEdit-similarityLogMapLtLogMapAMLLogMap-MLTruveta MapperBERTMap。能对比的话要么这些方法易于复现要么是这些方法在数据集上已经有现成的指标数据可以抄过来。实验指标采用经典的PrecisionRecall和F1-score注意reference mapping被用来计算这些指标。除此之外还有所谓的消融实验和参数实验。实验数据丰富可惜没找到开源代码若要对比只能选取其现成数据。The AgreementMakerLight Ontology Matching System62013否文章里没看到有关开源的说明但是应该至少有工具可以获取不然对比实验不好搞没有明确说问题而是说在生物医学领域本体变得越来越大带来了挑战。AML是为了处理特别大的本体而设计的同时保留原框架AgreementMaker的大部分灵活性和可扩展性。在OAEI的Anatomy和Large Biomedical Ontologies轨道上验证了AML的有效性说明AML在运行时间上很优越。在Anatomy而言AML是目前F-measure最好的系统。在Large Biomedical Ontologies上AML的F-measure也是前列的。实现AML使用了Apache Jena将本体以OntModel对象的形式维护在内存中其实这样就够了想到我用什么多叉树确实是伪需求。LogMap: Logic-Based and Scalable Ontology Matching72011不确定论文里没写。提出LogMap是唯一能够处理包含上万个甚至上百种类的语义丰富的本体的匹配系统特点是高度可扩展。相比于大多数的现有工具LogMap实现了unsatisfiability检测与修复。在NCI、FMA、SNOMED CT上实验表示LogMap可以有效地匹配现有的最大的生物医学本体。LogMap在很多情况下能够产生干净的输出映射集即LogMap的输出映射与输入本体集成后得到的本体是一致的不包含不可满足的类。Dividing the Ontology Alignment Task with Semantic Embeddings and Logic-based Modules82020英国团队的网站。Java代码、Python代码、数据集、OAEI的网站文章认为大型本体是本体对齐系统的严峻挑战因而文章针对的仍然是大本体对齐问题。文章提出的方法是结合神经嵌入模型和基于逻辑的模块的方法直观感觉是“神经”“符号”的缝合能够准确将输入本体匹配任务划分为更小且更易处理的匹配子任务。实验部分使用OAEI评估倡议的数据集进行评估再次说明OAEI在本体匹配任务的权威性你想要说明你的方法好那就用OAEI的数据集来说明。鉴于文章里附上了代码可靠性较高文章发表在ECAI会议上。Augmenting Ontology Alignment by Semantic Embedding and Distant Supervision92021是提出使用远程监督和语义嵌入的ML扩展用于增强传统的本体对齐系统。和原始LogMap以及AML v3.1比较这俩在OAEI任务中排名较高。为了精准评估两个本体的对齐效果使用了金标准mapping来计算precision和recall不过作者自己也承认金标准的Mapping也是高度不完整的这是因为其偏向于使用LogMap可以找到的映射他们还使用了近似精度和召回率即Precision≈ ^{\approx}≈和Recall≈ ^{\approx}≈。运行时间也作为系统考量的一部分毕设里也可以说一下时间效率只是提一嘴。Jointly Learning Entity and Relation Representations for Entity Alignment102019是注意该文的主题是实体对齐Entity Alignment说明它和本体对齐有很大的相似之处实体对齐是NLP的经典问题了。这篇文章发表于2019年的EMNLP是大模型爆火之前。本体对齐有个明显不一样的是它更侧重于模式层的对齐里面的节点以概念为主。这篇文章提出的方法基于图卷积网络GCN用于学习实体和关系的表示。 而不是依靠预先对齐的关系种子来学习关系表示首先使用GCN学习的实体嵌入来近似它们。然后将关系近似合并到实体中以迭代地学习两者更好的表示。实验宣称在三个真实世界的跨语言数据集上进行的实验表明该文的方法明显优于当前2019最先进的实体对齐方法。实验对比部分使用的指标是Hits1和Hits10我没有用过这个指标但是见过很多次了在知识图谱预测部分也经常出现实体和关系对齐均使用了此指标。该方法被其它文章拿来用作本体对齐的对比然而这篇文章通篇只提到两处本体对齐可见实体对齐和本体对齐有一定的兼容关系即实体对齐方法也可以拿来本体对齐。如此也可见即便大方向差不多细分方向的差别也是非常大的。GMap Results for OAEI 2021*112021是问题仍是本体对齐打榜类。GMap是一种用于本体匹配的概率性替代方案它融合了和积(sum-product)网络与噪声或(noise-or)模型。具体地作者使用和积网络基于个体集合和不相交公理来编码相似性同时运用噪声或模型来编码描述本体间实体对相互影响的概率匹配规则。方法在OAEI2021的会议和解剖学两个赛道上验证比较的指标有Precision、Recall、F.5-Measure、F1-Measure和F2-Measure。这里的.5和2的含义和用意是既然是开源的项目那就可以试试主要看其是否可以快速部署运行。Wiktionary Matcher Results for OAEI 2021122021是以Wiktionary知识库作为外部知识资源的本体对齐系统。在OAEI2021的6个轨道上做了测试。TOM Matcher Results for OAEI 2021132021否暂时没找到它叫TOM是因为它将Transformer应用于本体匹配不是TOM猫但这个缩写比较好记。在OAEI的Anatomy和Conference轨道上测试了。方法分类摘自相关文章的Related Works部分有以下类别的本体对齐方法基于字符串基于结构基于深度学习其他文章里提及的对比方法列举应该是有代表性的不然不应该拿来比AML6可扩展本体对齐系统认为词库是对齐任务的重要依赖使用外部本体作为输入本体之间的中介在OAEI track上排名靠前。LogMap7同样在OAEI上排名靠前首个能处理超过上万个类的本体的对齐工具设计了锚映射anchor mappingsM a M_aMa。LogMap和AML的输出映射通常作为训练数据来训练有监督的方法。LogMap28是LogMap和AML v3.2的修改版本modified version在OAEI任务中排名很高。LogMap-ML9对传统本体对齐系统LogMap的拓展基于机器学习使用了Siamese网络并基于OWL2Vec*嵌入来学习本体表示。RDGCN10此方法使用GCN来学习本体结构嵌入受所谓DPGCNN的影响取得了SOTA表现。从文章标题来看是实体对齐而且2019年的时候大模型还没火。GMap11OAEI2021上的GMap结果GMap结合了sum-product网络和noisy-or模型。Wiktionary12是一个本体匹配器在OAEI2021上进行了测试将Wiktionary作为知识源。TOM13OAEI2021上名为TOM的本体匹配器使用了一个zero-shot transformer-based语言模型来计算每个实例的置信度使用的预训练transformer模型paraphrase-TinyBERT-L6-v2。Siamese-GCN3即华中农业的这篇文章和以上方法做了对比。调研3加密流量和态势感知有关因为态势感知是一个大的方向说白了各种具体安全任务都可以用来支撑态势感知但如果不是特别直接的关系的话没必要硬往论文上面套。代表性现有工作和近期文章可以从相关综述入手来了解现状尽管这类文章非常多但总有一些主流的文章总被拿来对比的。深层次的调研除了看一看文章之外还应把比较有名的开源代码下载部署并解读一下趁着有服务器可以多考虑。文章题目年份开源问题和方案解读实验解读暂时空着加密流量分类很卷需要算力很多文章的设计看起来不甚合理。方法分类小结大模型技术发展特别快很多方向其实都可以被大模型统治了只要是以文本、图像、音视频之类的为输入的工作都要考虑去抱大模型的大腿。过去所谓的insight很难比得过大模型。就这几个方向而言我个人觉得反而是模糊本体受大模型冲击小些本体对齐、本体工程这些时下最好的方法都要结合大模型。加密流量分类其实仍然是数据处理方法把输入数据限定为加密流量大概率也是要被大模型统治的。在没有足够大模型资源的情况下多考虑一些相对不依赖大模型的方向。仅作为个人调研记录不涉及具体实现方案尽量避免文章灌水。待补充持续更新。https://cdn.aaai.org/ocs/ws/ws0163/12574-57427-1-PB.pdf ↩︎https://doi.org/10.1016/j.ijar.2011.05.003 ↩︎https://www.sciencedirect.com/science/article/pii/S1570826823000276 ↩︎ ↩︎https://www.mdpi.com/2504-2289/9/8/208 ↩︎https://www.sciopen.com/article/10.26599/TST.2025.9010003 ↩︎https://link.springer.com/chapter/10.1007/978-3-642-41030-7_38 ↩︎ ↩︎https://link.springer.com/chapter/10.1007/978-3-642-25073-6_18 ↩︎ ↩︎https://arxiv.org/abs/2003.05370 ↩︎ ↩︎https://link.springer.com/chapter/10.1007/978-3-030-77385-4_23 ↩︎ ↩︎https://aclanthology.org/D19-1023/ ↩︎ ↩︎http://ceur-ws.org/Vol-3063/oaei21_paper7.pdf ↩︎ ↩︎http://ceur-ws.org/Vol-3063/oaei21_paper14.pdf ↩︎ ↩︎http://ceur-ws.org/Vol-3063/oaei21_paper13.pdf ↩︎ ↩︎
最近在考虑两个点的工作分别是模糊本体和本体对齐但都处于比较卡壳的状态的。再考虑到现实情况就是安全专业和以后就业需求看下加密流量的文章就我目前的了解来说加密流量的文章主要还是用数据分析的或AI的技术来做的只不过分析对象是加密流量。从应用型论文的角度来说既需要了解应用场景有需要熟悉分析技术AI是分析技术安全是应用场景很多论文都是这个路数弄出来的不能完全说灌水有些确实有用。不是看了就一定要基于这个方向弄文章只是先了解一下有充分认识之后再做后续考虑。初步了解和动机由于我做的是安全领域本体这种比较小众的方向得益于创新资助计划才沿着本体工程这个思路做了几篇文章。但是如果没有创新资助的话我曾经考虑两个事。第一沿着UCO1的思路建模模糊安全本体话说为什么我弄的论文阅读博客能在bing学术上搜到好尴尬第二做安全本体的融合也就是本体对齐匹配。这两个方向都只是想过没有实际去做感觉太难/懒。模糊本体考虑对知识的不确定性和概率建模按照UCO的展望描述安全领域确实需要这样的模糊本体。我个人觉得的难点是1高质量的建模太困难现在哪怕是UCO也只是少数的领域建模尝试如果想要作为公开的本体资源文章的话resource paper很难2实用性验证的说服力除了持续说本体的推理有可解释性之外在实际安全应用上很难看出它的优势。本体对齐做本体库很自然想到不同来源的本体库的融合问题我曾想做安全领域的本体对齐但发现行不通。我认为的难点是1和我做安全本体工程类似最难说的一点就是如何说明我的方法适用于安全领域特定领域实际上我并没有太多对安全领域的特殊考虑。便陷入这样的矛盾中若要做领域特定的方法那就必须对该领域有特别的优化否则就是通用方法能够PK过别人的方法2目前本体匹配是一个相对较卷的方向有OAEI的比赛想做出能发表的文章那就要多接触前沿的机器学习深度学习这些我这些基础目前还不太行要补上。因为我是网安专业不能做完全抛离网安的方向但现在不用受这个桎梏了。3对1补充经过初步了解一个方法的好坏不同领域有其差异性比如某OAEI轨道该方法第一换个轨道就不是第一了但只要有比较好的表现就算不错。可是从方法实现来说看不出方法对某个领域有特殊的设计所以稍微总结一下就是好的方法在不同领域都应该有不错的表现但如果是在某个领域表现好那就要体现方法实现为什么能在该领域有好的表现不是仅仅使用了该领域的数据集这么简单。加密流量最直接的任务是加密流量分类任务是个很卷的方向以后做所谓的弹性网络评估我觉得多少都会接触到一些。目前想法不需要资格论文所以可以相对稍缓一些写出后用于工作。这两个点都可以考虑并且都不是短期内可以出东西的方向。安全本体建模要达到真正可发布可复用作为长期建模优化的工作不是随便画张图设置几个概念就可以拿去水文章的本体对齐需要先复现别人的了解清楚流程细节和评估手段之后去做指标上的提升工作同样不是一时半会就能出内容的。另外只有真正有价值的工作才会被不断引用和比较。调研1模糊本体现有代表性工作和近期文章此前有关于Fuzzy OWL 2的插件的研究。搜索关键词有“fuzzy logic”、“fuzzy ontology”有很多数学占比高的文章晦涩难懂。就目前看来多数文章讨论模糊逻辑时会把不确定性和概率事件作为本体描述能力之外的内容并且把这个当做本体的问题引出模糊性的讨论。应先考虑清楚模糊安全本体应当是怎样的有什么作用文章题目年份开源问题和方案解读实验解读Fuzzy ontology representation using OWL 222011是语义Web语言需要处理模糊信息的能力要用一种标准的方式来表示这些信息。作者开发了protege的插件用于模糊本体建模与推理。实验才用的是讲解建模案例的形式这篇文章的工作量很扎实。调研2本体匹配现有代表性工作和近期文章此处列举比较有代表性的工作记录来源。可以搜索关键词“ontology alignment”、“ontology matching或者ontology fusion”都是本体匹配相关的文章文章数量挺多的。这是本体领域的“打榜类”的方向仔细了解下可以熟悉相关技术路线。文章题目年份开源问题和方案解读实验解读Ontology alignment with semantic and structural embeddings32023是声称过去工作主要是基于外部词典和本体结构的预定义规则换言之以旧方法为主而这篇文章要使用深度学习了此为方法优越。在效果上就是优于baseline。作者的说法是证明了学习语义表示和结构表示的重要性。实验仓库关注的人不多从readme来说介绍了预处理步骤看起来有可信度值得花时间去了解一下实验细节。实验先介绍了训练时间和超参数设置验证度量。随后就是在Foodon和Helis上的实验测试有Mappings数量、RecallG S ^{GS}GS、Precision≈ ^{\approx}≈、Recall≈ ^{\approx}≈、F1≈ ^{\approx}≈这些指标。而在OAEI tracks上面则是使用Total/correct、Precision、Recall、F1等指标。此外还有所谓的消融实验Ablation study看来本体对齐主题的文章都有它们算提出AI模型类的文章消融实验可能是必需品了。在Foodon和HeLis的实验上对比的方法有LogMap2、AML、LogMap-ML、RDGCN在OAEI的conference track对比的方法有AML、GMap、LogMap、Wiktionary、TOM、AMLl o c a l ^{local}local、LogMapl o c a l ^{local}local、LogMap-ML、RDGCN等对比表格分成了两大行。Ontology Matching Method Based on Deep Learning and Syntax42025否声称为解决本体异构问题文章提出一种融合循环神经网络和句法分析的混合本体的匹配方法。这里的问题是本体对齐的目的虽然这么说是对的但就缺少了针对性因为所有做本体对齐的工作都是为了解决本体异构问题的过于笼统。方案是基于深度学习的方法利用本体树结构中的入度和出度信息提取具有代表性的实体。训练数据集均来自OAEI用若干case表示。和来自OAEI的代表性方法对比包括AML、LogMap家族LogMap和LogMapBio、PhenoMF、以及基于Transformer的方法。为了比较作者提的N-gram作者将其和另外两个相似度度量方法替换并对比即SimRank基于结构和Wu-Palmer基于语义。作者也做了所谓消融实验最终还比较了LSTM和GRU的时间空间复杂度LSTMN-gram、GRUN-gram。Ontology Alignment Approach Based on Attribute Self-Adaption Mechanism and Hetergeneous Feature Fusion52025否指出本体对齐面临三个问题1、reference mapping缺乏隐式语义2、类嵌入之间错误的高相似性3、训练数据不平衡。提出主动学习本体对齐方法。在文章摘要处提及了重建reference mapping避免false positive对齐类一定程度上紧扣所提问题。使用8个数据集有来自OAEI的。对比的基线方法有String-matchEdit-similarityLogMapLtLogMapAMLLogMap-MLTruveta MapperBERTMap。能对比的话要么这些方法易于复现要么是这些方法在数据集上已经有现成的指标数据可以抄过来。实验指标采用经典的PrecisionRecall和F1-score注意reference mapping被用来计算这些指标。除此之外还有所谓的消融实验和参数实验。实验数据丰富可惜没找到开源代码若要对比只能选取其现成数据。The AgreementMakerLight Ontology Matching System62013否文章里没看到有关开源的说明但是应该至少有工具可以获取不然对比实验不好搞没有明确说问题而是说在生物医学领域本体变得越来越大带来了挑战。AML是为了处理特别大的本体而设计的同时保留原框架AgreementMaker的大部分灵活性和可扩展性。在OAEI的Anatomy和Large Biomedical Ontologies轨道上验证了AML的有效性说明AML在运行时间上很优越。在Anatomy而言AML是目前F-measure最好的系统。在Large Biomedical Ontologies上AML的F-measure也是前列的。实现AML使用了Apache Jena将本体以OntModel对象的形式维护在内存中其实这样就够了想到我用什么多叉树确实是伪需求。LogMap: Logic-Based and Scalable Ontology Matching72011不确定论文里没写。提出LogMap是唯一能够处理包含上万个甚至上百种类的语义丰富的本体的匹配系统特点是高度可扩展。相比于大多数的现有工具LogMap实现了unsatisfiability检测与修复。在NCI、FMA、SNOMED CT上实验表示LogMap可以有效地匹配现有的最大的生物医学本体。LogMap在很多情况下能够产生干净的输出映射集即LogMap的输出映射与输入本体集成后得到的本体是一致的不包含不可满足的类。Dividing the Ontology Alignment Task with Semantic Embeddings and Logic-based Modules82020英国团队的网站。Java代码、Python代码、数据集、OAEI的网站文章认为大型本体是本体对齐系统的严峻挑战因而文章针对的仍然是大本体对齐问题。文章提出的方法是结合神经嵌入模型和基于逻辑的模块的方法直观感觉是“神经”“符号”的缝合能够准确将输入本体匹配任务划分为更小且更易处理的匹配子任务。实验部分使用OAEI评估倡议的数据集进行评估再次说明OAEI在本体匹配任务的权威性你想要说明你的方法好那就用OAEI的数据集来说明。鉴于文章里附上了代码可靠性较高文章发表在ECAI会议上。Augmenting Ontology Alignment by Semantic Embedding and Distant Supervision92021是提出使用远程监督和语义嵌入的ML扩展用于增强传统的本体对齐系统。和原始LogMap以及AML v3.1比较这俩在OAEI任务中排名较高。为了精准评估两个本体的对齐效果使用了金标准mapping来计算precision和recall不过作者自己也承认金标准的Mapping也是高度不完整的这是因为其偏向于使用LogMap可以找到的映射他们还使用了近似精度和召回率即Precision≈ ^{\approx}≈和Recall≈ ^{\approx}≈。运行时间也作为系统考量的一部分毕设里也可以说一下时间效率只是提一嘴。Jointly Learning Entity and Relation Representations for Entity Alignment102019是注意该文的主题是实体对齐Entity Alignment说明它和本体对齐有很大的相似之处实体对齐是NLP的经典问题了。这篇文章发表于2019年的EMNLP是大模型爆火之前。本体对齐有个明显不一样的是它更侧重于模式层的对齐里面的节点以概念为主。这篇文章提出的方法基于图卷积网络GCN用于学习实体和关系的表示。 而不是依靠预先对齐的关系种子来学习关系表示首先使用GCN学习的实体嵌入来近似它们。然后将关系近似合并到实体中以迭代地学习两者更好的表示。实验宣称在三个真实世界的跨语言数据集上进行的实验表明该文的方法明显优于当前2019最先进的实体对齐方法。实验对比部分使用的指标是Hits1和Hits10我没有用过这个指标但是见过很多次了在知识图谱预测部分也经常出现实体和关系对齐均使用了此指标。该方法被其它文章拿来用作本体对齐的对比然而这篇文章通篇只提到两处本体对齐可见实体对齐和本体对齐有一定的兼容关系即实体对齐方法也可以拿来本体对齐。如此也可见即便大方向差不多细分方向的差别也是非常大的。GMap Results for OAEI 2021*112021是问题仍是本体对齐打榜类。GMap是一种用于本体匹配的概率性替代方案它融合了和积(sum-product)网络与噪声或(noise-or)模型。具体地作者使用和积网络基于个体集合和不相交公理来编码相似性同时运用噪声或模型来编码描述本体间实体对相互影响的概率匹配规则。方法在OAEI2021的会议和解剖学两个赛道上验证比较的指标有Precision、Recall、F.5-Measure、F1-Measure和F2-Measure。这里的.5和2的含义和用意是既然是开源的项目那就可以试试主要看其是否可以快速部署运行。Wiktionary Matcher Results for OAEI 2021122021是以Wiktionary知识库作为外部知识资源的本体对齐系统。在OAEI2021的6个轨道上做了测试。TOM Matcher Results for OAEI 2021132021否暂时没找到它叫TOM是因为它将Transformer应用于本体匹配不是TOM猫但这个缩写比较好记。在OAEI的Anatomy和Conference轨道上测试了。方法分类摘自相关文章的Related Works部分有以下类别的本体对齐方法基于字符串基于结构基于深度学习其他文章里提及的对比方法列举应该是有代表性的不然不应该拿来比AML6可扩展本体对齐系统认为词库是对齐任务的重要依赖使用外部本体作为输入本体之间的中介在OAEI track上排名靠前。LogMap7同样在OAEI上排名靠前首个能处理超过上万个类的本体的对齐工具设计了锚映射anchor mappingsM a M_aMa。LogMap和AML的输出映射通常作为训练数据来训练有监督的方法。LogMap28是LogMap和AML v3.2的修改版本modified version在OAEI任务中排名很高。LogMap-ML9对传统本体对齐系统LogMap的拓展基于机器学习使用了Siamese网络并基于OWL2Vec*嵌入来学习本体表示。RDGCN10此方法使用GCN来学习本体结构嵌入受所谓DPGCNN的影响取得了SOTA表现。从文章标题来看是实体对齐而且2019年的时候大模型还没火。GMap11OAEI2021上的GMap结果GMap结合了sum-product网络和noisy-or模型。Wiktionary12是一个本体匹配器在OAEI2021上进行了测试将Wiktionary作为知识源。TOM13OAEI2021上名为TOM的本体匹配器使用了一个zero-shot transformer-based语言模型来计算每个实例的置信度使用的预训练transformer模型paraphrase-TinyBERT-L6-v2。Siamese-GCN3即华中农业的这篇文章和以上方法做了对比。调研3加密流量和态势感知有关因为态势感知是一个大的方向说白了各种具体安全任务都可以用来支撑态势感知但如果不是特别直接的关系的话没必要硬往论文上面套。代表性现有工作和近期文章可以从相关综述入手来了解现状尽管这类文章非常多但总有一些主流的文章总被拿来对比的。深层次的调研除了看一看文章之外还应把比较有名的开源代码下载部署并解读一下趁着有服务器可以多考虑。文章题目年份开源问题和方案解读实验解读暂时空着加密流量分类很卷需要算力很多文章的设计看起来不甚合理。方法分类小结大模型技术发展特别快很多方向其实都可以被大模型统治了只要是以文本、图像、音视频之类的为输入的工作都要考虑去抱大模型的大腿。过去所谓的insight很难比得过大模型。就这几个方向而言我个人觉得反而是模糊本体受大模型冲击小些本体对齐、本体工程这些时下最好的方法都要结合大模型。加密流量分类其实仍然是数据处理方法把输入数据限定为加密流量大概率也是要被大模型统治的。在没有足够大模型资源的情况下多考虑一些相对不依赖大模型的方向。仅作为个人调研记录不涉及具体实现方案尽量避免文章灌水。待补充持续更新。https://cdn.aaai.org/ocs/ws/ws0163/12574-57427-1-PB.pdf ↩︎https://doi.org/10.1016/j.ijar.2011.05.003 ↩︎https://www.sciencedirect.com/science/article/pii/S1570826823000276 ↩︎ ↩︎https://www.mdpi.com/2504-2289/9/8/208 ↩︎https://www.sciopen.com/article/10.26599/TST.2025.9010003 ↩︎https://link.springer.com/chapter/10.1007/978-3-642-41030-7_38 ↩︎ ↩︎https://link.springer.com/chapter/10.1007/978-3-642-25073-6_18 ↩︎ ↩︎https://arxiv.org/abs/2003.05370 ↩︎ ↩︎https://link.springer.com/chapter/10.1007/978-3-030-77385-4_23 ↩︎ ↩︎https://aclanthology.org/D19-1023/ ↩︎ ↩︎http://ceur-ws.org/Vol-3063/oaei21_paper7.pdf ↩︎ ↩︎http://ceur-ws.org/Vol-3063/oaei21_paper14.pdf ↩︎ ↩︎http://ceur-ws.org/Vol-3063/oaei21_paper13.pdf ↩︎ ↩︎
