組織與管理/標籤
我不使用标签管理主要文件，仅计划作用于如memes等特殊类型文件，如果您要作用于全局或个人文件请参考其他意见。
當我說體量時，我有沒有說具體的體量？例如我說瀏覽器收藏夾不足以處理複雜結構時，我的意思我瀏覽器去掉冗餘數據(主流的社區、工具、同性質的流水線類站點)後仍舊3k+的鏈接，和成百上千個文件夾，而我現在需要對其進行近乎重構的調整。就像我說整理數據時，並不是說整理幾百G的圖片，而是整理幾十TB的數據並讓它們便於索引及備份、查閱拓展信息，可持續化發展的結構。當體量大到一定程度，傳統的模式就是不足以處理，如果不想遇到分類地獄，那就講分類的工作交給標籤……可是，標籤真的能處理如此規模的數據嗎？
標籤的優缺點很明顯：
- 優點：
- 更人性化及易於組織和管理交叉領域較多的文件；
- 缺點：
- 冗餘數據，尤其是在面對是否為文件類型打標籤(pdf及掃描件並不強關聯可打標籤會產生很多垃圾標記)的抉擇，或目錄、文件名及標籤三者間的權重分配；
- 維護麻煩，尤其是對於不經常使用的部分——當體量到幾十TB時，你總有一部分內容幾個月都不曾訪問，如同文件夾結構一樣，標籤本身（包括詞彙表的設計模式）也很容易被遺忘。
因此，在體量越來越大時，標籤制度管理文件很容易造成維護地獄的困境，越是深入使用，將來動結構就越麻煩。
在我最初的設想中，應該是有一個標籤文件管理器，或者層級目錄僅作為「可被繼承的特殊標籤」存在，標籤本身亦可被嵌套及通過嵌套關係分上下級(要解決無限遞歸的問題)，並且標籤可以分組，例如尺寸分組、重要性分組(便於備份所有重要文件)，這過程要搭配AI及各種自動化腳本共同實現，以抵消標籤制度最大的缺陷「人力成本」，具體節省多少事取決於AI發展的多給力，但仍舊解決不了臃腫的問題。
這個想法原型是標籤制度的文件管理器，以一個主標籤遵循傳統文件結構來使其可以移植到其他文件系統而不影響使用，其他標籤為輔標籤用於替代傳統文件夾結構的單一性。可以選擇標籤節點視圖瀏覽、檢索，元數據存儲在數據庫。
標籤也分為集體屬性與個體屬性，集體標籤會自動同步（可設置）到同文件夾、子文件夾，個體標籤用於添加獨特的注釋。前兩者預計於軟件層面實現，後者寫入元數據/文件標題。當然其實我更想讓標籤作用於作用於文件夾而不是文件，每個檔案都抽象化為一個事件，標籤用於描述這個事件所囊括的內容。
然後我就不想了， 因為首先我在技術方便約等於0，而且歸根結底，我從未大規模(也不敢)使用標籤制度，因此並不熟悉如何平衡臃腫、人力成本及實用性，可預見的維護地獄就夠我喝一壺了，我所能約束的只有文件命名規範及做好性質分離與精簡層次，以達到可以脫離狀態在任一時間點根據性質在不超過三個具體目錄內找到目標文件。
標籤僅作用於可預見的實用性大於維護成本的領域，例如memes等需要更多信息去組織及索引的文件夾；部分使用硬鏈接處理控制不了的交叉領域問題；項目使用專門設計的索引表統計所擁有的內容。
