查看“︁组织与管理/标签”︁的源代码

 我不使用标签管理主要文件，仅计划作用于如memes等特殊类型文件，如果您要作用于全局或个人文件请参考[[组织与管理/参考信息#博客|其他意见]]。
　　当我说体量时，我有没有说具体的体量？例如我说浏览器收藏夹不足以处理复杂结构时，我的意思我浏览器去掉冗余数据(主流的社区、工具、同性质的流水线类站点)后仍旧3k+的链接，和成百上千个文件夹，而我现在需要对其进行近乎重构的调整。就像我说整理数据时，并不是说整理几百G的图片，而是整理几十TB的数据并让它们便于索引及备份、查阅拓展信息，可持续化发展的结构。当体量大到一定程度，传统的模式就是不足以处理，如果不想遇到分类地狱，那就讲分类的工作交给标签……可是，标签真的能处理如此规模的数据吗？
----标签的优缺点很明显：

* 优点：
** 更人性化及易于组织和管理交叉领域较多的文件；
* 缺点：
** 冗余数据，尤其是在面对是否为文件类型打标签(pdf及扫描件并不强关联可打标签会产生很多垃圾标记)的抉择，或目录、文件名及标签三者间的权重分配；
** 维护麻烦，尤其是对于不经常使用的部分——当体量到几十TB时，你总有一部分内容几个月都不曾访问，如同文件夹结构一样，标签本身（包括词汇表的设计模式）也很容易被遗忘。

因此，在体量越来越大时，标签制度管理文件很容易造成维护地狱的困境，越是深入使用，将来动结构就越麻烦。
----　　在我最初的设想中，应该是有一个标签文件管理器，或者层级目录仅作为“可被继承的特殊标签”存在，标签本身亦可被嵌套及通过嵌套关系分上下级(要解决无限递归的问题)，并且标签可以分组，例如尺寸分组、重要性分组(便于备份所有重要文件)，这过程要搭配AI及各种自动化脚本共同实现，以抵消标签制度最大的缺陷“人力成本”，具体节省多少事取决于AI发展的多给力，但仍旧解决不了臃肿的问题。

　　这个想法原型是标签制度的文件管理器，以一个主标签遵循传统文件结构来使其可以移植到其他文件系统而不影响使用，其他标签为辅标签用于替代传统文件夹结构的单一性。可以选择标签节点视图浏览、检索，元数据存储在数据库。

　　标签也分为集体属性与个体属性，集体标签会自动同步（可设置）到同文件夹、子文件夹，个体标签用于添加独特的注释。前两者预计于软件层面实现，后者写入元数据/文件标题。当然其实我更想让标签作用于作用于文件夹而不是文件，每个档案都抽象化为一个事件，标签用于描述这个事件所囊括的内容。
----　　然后我就不想了， 因为首先我在技术方便约等于0，而且归根结底，我从未大规模(也不敢)使用标签制度，因此并不熟悉如何平衡臃肿、人力成本及实用性，可预见的维护地狱就够我喝一壶了，我所能约束的只有文件命名规范及做好性质分离与精简层次，以达到可以脱离状态在任一时间点根据性质在不超过三个具体目录内找到目标文件。

　　标签仅作用于可预见的实用性大于维护成本的领域，例如memes等需要更多信息去组织及索引的文件夹；部分使用硬链接处理控制不了的交叉领域问题；项目使用专门设计的索引表统计所拥有的内容。
[[Category:组织与管理]]