前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >纵览全局垂直打击的组织模式(上)

纵览全局垂直打击的组织模式(上)

作者头像
ZONGLYN
修改2020-06-29 19:34:31
7450
修改2020-06-29 19:34:31
举报
文章被收录于专栏:程序萌部落程序萌部落

有人说蚂蚁的世界是二维的(非常不准确),那是因为它们永远不知道何为高矮深浅。 因为它们感官的“无能”,致使它们丧失感受世间万物的机会。

对知识系统(eg.博客)而言,良好的组织结构是极为重要的,尤其是当内容增多,关联复杂后显得尤为重要。传统的“分类(Categories)+标签(Tags)”的二级模式虽足以应付大部分用户的需求,但本质上其还是需要用户对已有分类和标签有良好的组织,这对很多用户来说是根本做不到,因为我们往往缺的就是这种“纵览全局”的能力。

分类往往越分越多,标签也是随意放置,久而久之,不仅已有的分类和标签杂乱无章,更为甚者是新增内容时根本不知从何下手,往往需要遍历过往的标签和分类,才能做出最终定夺。现在,通过图布局的方式,可以以一种近乎完美的方式对复杂的内容进行组织,详细效果请查看 该页面

纵览全局

对于知识系统(之后均以博客代指)而言,传统的模式只是简单的分支,或者称其为树形结构,在探索过程中,用户就如同“蚂蚁”一样,只得选择先从哪进入,然后再进入到哪里。对于单篇内容而言并无影响,但当需要感知全局时,往往这种模式就会出现问题。

分级/树形组织方式的不足
  • 用户开始便直接希望查阅某些内容,且不确定分类时,无法定位(局部要求) 可以通过搜索功能完成该需求。
  • 新增分类和标签时,缺少对已有项的感知能力(全局要求) 尤其对于标签,会更加的随意和杂乱,会出现重复、同义等等问题,在每次打标签时都要头疼一番。
  • 对于所打的标记,没有评价方法,永远不知道分类和标签是否匹配(全局要求) 对于已存在的标签或分类,这样打标签是否合理,由于标签的“松散”特性,不同分类中可以出现同一标签,这样在传统分级模式下,分类和标签的契合程度如何,系统的维护者无从知晓。
天然的解决方案:图布局

分级/树形标记模式本身就是一个分类过程,自己的知识内容(博客文章)是对象,维护者将其放置在不同的类别下。标签(Tags)则更像是分类过程中的副产物,更贴近文章内容,但又言简意赅,通过分级的思考方式,分类和标签和文章的关系是:

分类-标签-文章(1:M:N)

对于上述关系,分别用A、B、C表示的话,则整个系统其实就是一个“Ai-Bi-Ci”的三元组集合。该集合的好坏(即质量)就是其在语义上的契合程度,例如:

代码语言:javascript
复制

分类:军事 -> 标签:爆炸 -> 文章:伊拉克遭遇恐怖袭击
分类:娱乐 -> 标签:爆炸 -> 文章:阿富汗遭遇恐怖袭击

当抽象为网络/图之后,军事类别和娱乐类别会通过“爆炸”这一标签相连,如是,明显的会发现“爆炸”位置不对。(虽然例子很蠢,但当语义区分模糊、标签数量繁多时,极易出现该情况)。下面直接拿已完成的布局来解释:

粉红色为分类、蓝色为标签、节点半径为被使用的次数

  • 语义不符的连接点(异常的跨类标签),如果连接点对某一方语义不匹配,那么很可能该文章是特殊的,或者该标签不应该出现在该文章。(下图里可视化的文章在这儿,属于特殊文章,正常“生活分类”和“可视化”的语义并不匹配)
此处为本页面内的一张图片
此处为本页面内的一张图片
  • 合格的连接点(跨分类的标签):虽然标签出现在不同分类中是非常正常的,例如“总结”,可以出现在任何分类中。但类似“总结”这类标签往往数量很多,即多次的出现在不同的类别中,那我们就说这是一个合格的跨分类标签
此处为本页面内的一张图片
此处为本页面内的一张图片
  • 对于分类点,以本博客为例,由于是对已存在数据进行分析,所以如果某分类下属节点不足,那么高度怀疑该分类不合理,除非是需要日后扩充的分类。这一需求在图布局的视图下非常容易分辨出来,合格的类别应该有众多叶节点,当叶节点不足,则应考虑将其降级至标签。(例如下图中的“朴素贝叶斯”,可将其降级为标签,并归类到“研究方向”中)

值得注意的一点是: 这里使用的图布局使用力导向(Force-directed)布局算法,相关则相近,无关则疏远,又完美的给布局结果以语义上的解释,即:

  • 当两个类别及其叶子节点距离很远时,其两者基本无关
  • 当两个类簇距离很近时,其高度相关
此处为本页面内的一张图片
此处为本页面内的一张图片

反推设计

上节中的分析看似很有道理,布局结果的使用也非常方便,那么如何从无到有将其构建出来?主要有以下几个方面:

  • 天然的三元组集合:文章的特性(篇幅长)决定了其不能参与整个构建和评价过程,那么剩下的二元组是天然的“关系数据”,对于关系数据的可视化,图布局算法/模式首当其冲。
  • 分析需要呈现的维度:对于任意节点(布局时类别和标签并无分别)来说,主要有以下维度信息:
    1. 自己(如果是类别)包含哪些标签;
    2. 自己是什么类型的节点(类别?标签?);
    3. 自己被使用了几次;
  • 对应的可视化要素: a. 图中节点的邻节点(点、线) b. 类别为粉色标签为蓝色(颜色) c. 次数与节点的半径成比例(圆面积)
  • 还可以附着信息(扩展维度)的要素:
    1. 节点的形状(三角形、圆、方)
    2. 连线的颜色(红、蓝)
    3. 连线的线型(虚线、实线)

上述过程中,确定“图布局”模式是基础,剩下的无非是将信息绑定到可视化元素上,例如,已实现的布局将“类别/标签”用颜色区分,其实用形状等其他可视化元素区分也完全可以。

垂直打击

到此为止,只是上层结构,类似数据库存储,搞了半天只是在搞索引,并没有触碰到数据,所以目前为止该网络并没有直通最底层(文章内容)的能力,这个问题恰好被Hexo的文件结构所解决,Hexo给每个标签和每个分类都渲染了单独的页面,关联的文章被放置在页面中,在此,直接通过节点的文本信息构造访问地址,将其绑定到文本上,即可点击后跳转到相关页面,虽然不是直接跳转文章,但也可以说具备相当的垂直打击能力了。

进阶版本:变的更强

简单粗暴的加入之前三元组被抛弃掉的文章信息,但由于加入后过于散乱,所以有必要将文章信息固定,以便于视觉呈现。如下图(d3.js实现的、用于可视化编程概念的可视化模型):

此处为本页面内的一张图片
此处为本页面内的一张图片

上图就是简单的带固定节点的力导向布局,但其实现代码比较复杂,目前处在构造数据阶段。一般的可视化模型套用的步骤:

阅读原站代码 -> 从原站抽离可视化部分 -> 搞清调用数据的方法及格式 -> 构造同样的数据 -> 独立运行 -> 放回自己的站点内

问题迎刃而解

到此,对于分级/树形分类的三点不足,可以发现很轻松就可以解决。既有全局视角,又可以同时具备直达的能力,对于组织内容数量较高(超过50)的站点非常适合该模式的导航、或辅助探索。

扯犊子完毕,下一篇(分为上下两篇)将详细说明一下如何遵循上节中的套用步骤、借助Hexo的辅助函數(Helper)来一步步实现的该可视化功能的。

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2020-01-06,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 纵览全局
    • 分级/树形组织方式的不足
      • 天然的解决方案:图布局
      • 反推设计
      • 垂直打击
      • 问题迎刃而解
      相关产品与服务
      云数据库 Redis
      腾讯云数据库 Redis(TencentDB for Redis)是腾讯云打造的兼容 Redis 协议的缓存和存储服务。丰富的数据结构能帮助您完成不同类型的业务场景开发。支持主从热备,提供自动容灾切换、数据备份、故障迁移、实例监控、在线扩容、数据回档等全套的数据库服务。
      领券
      问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档