Multi-Dimension File Management System

18th February 2020 at 11:52am
Startup: Idea

多维度的文件管理系统

这个文件管理系统的目的是:更方便地组织文件、检索文件。

背景

我遇到几个使用场景,给了我一些启发。

照片管理

旅游拍了很多照片,需要归类整理。但是文件系统是树状结构,只能把文件夹当作分类来组织照片。这会导致照片没法被更好地组织起来。比如大多数人会以 “日期-事件” 来命名文件夹(比如 201607-西北旅游),但是如果你想整理出不同的旅行中的所有 “亲密合照”,那你需要去多个文件夹里面搜索并且拷贝一份副本。这样非常不灵活。

另外有一个需求是,希望能灵活检索一些文件的元信息。比如照片文件中的 EXIF 信息,或者用户为某些文件自己添加的元信息(比如作者、描述等)。对于照片的例子,如果能读取 EXIF 中的位置信息并进行位置相关的检索就更好了,再如果能结合 Google 的图片 App 进行人脸识别 + 自动分类就更赞了。

全文检索多 PDF, ePub 文件

在看李笑来的《新生》时,他提到了全文检索 ePub / PDF 的需求。我也觉得随着我看的书越来越多,知识体系越来越健全时,我会有更多的电子资料(比如 PDF 书、网页保存的 PDF 等)需要有全文检索的能力。目前几大平台应该有不错的实现了:

  • Windows 上没有去找相应的软件(但是应该有)
  • Arch Linux 上,Plasma 的搜索(Alt-F1 / Alt-F2)有全文搜索功能,但是无预览,只能知道特定的词组出现在哪些 PDF 中
  • OSX 上,Spotlight 可以实现,但是没有具体使用过

但是这个功能是如此重要,如果它整合进这个文件管理系统中,会是个非常不错的特性。

为 Tiddlywiki 提供富媒体文件服务器

Tiddlywiki 的单页应用设计,导致嵌入富媒体文件时:

  1. 如果想不依赖外部链接,需要使用 Data URI 直接嵌入到 HTML 中,导致 HTML 庞大且浏览器性能可能降低
  2. 如果想使用外部链接:
    1. 需要维护外部链接的可用性,比如你可能需要把网络上的播客文件传到你自己的 CDN 上(比如七牛),避免那个外部链接挂掉了
    2. 不方便数据的统一管理,比如不能把全部数据都放在 Dropbox 上

市面上已有的软件体验

Google 搜关键字 "tag based file system", "semantic filesystem",可以找到几个已有的实现:

  • Tagsistant: 一个特殊的文件系统,在某个空白文件夹初始化后,对这个文件夹的操作,就跟创建 tag、给文件打 tag 等行为关联起来了。感觉不够直观,操作麻烦,功能有限。
  • TMSU: 跟 Tagsistant 一样只能处理文件 tag,但是它的命令行直观得多,而且可以为文件指定 tag 值(像是 attribute)并进行查询。缺点是功能局限于 tagging。
  • TagSpaces: 看起来最不错的一个实现。高级版也支持 PDF / Word 等文件全文检索,也可以给文件打 Tag,用 Tag 查询。缺点是 UI 糟糕难用,性能非常差容易卡(应该是用了 nw.js / Electron 这类技术),同时没法给单个文件写描述。

另外对于照片的场景,我觉得 Google Photos 做得非常好,按人脸聚合以及搜索照片的功能深得我心。但是它有两个缺陷:

  1. 无法按地点搜索
  2. 可以给照片加上描述信息,但是这个描述无法被搜索到,很是鸡肋

所以,如果可能,自己做一个文件管理的软件应该是有作用的。

预期的软件体验

  1. 这个软件可以让用户无需关心文件系统层面的分类(文件夹)。用户只需要把文件丢进我的软件,再进行打 Tag 等操作来管理。
  2. 这个软件应该提供足够灵活的打 Tag + 分类功能,和组合查询功能。比如在 “照片” 分类中,查找拍摄于 2016 年的照片。
  3. 这个软件应试针对某些具体使用场景做优化,比如知识管理、照片管理。

可能的功能细节

  • Tag / Attribute + Category
    • 用户可以为每个文件设置 Tag / Attribute / Category,区别是 Category 只能有一个,并且在整个系统中呈树状结构
    • 提供给用户复合查询的能力,复合查询中需要有操作符提供(e.g. year == 2016
    • 每个文件都可以写上单独的描述(可以作为一个 description 属性),用于检索
    • 为常用的文件名后缀 / 文件类型,提供预设的 Tag Set,方便用户选择并进行标注。比如对于视频文件,可以给出 Movie Name, Movie Director 之类的 Attributes
    • Tag 是一个没有值的 Attribute,它们在底层数据结构上可以是一致的
    • 可以利用文件本身的 Meta 信息时(比如图片的 EXIF,MP3 的 ID3),尽量使用它用来存储和读取;不可以利用时,单独存储在另外的地方(这里的设计需要考虑,有些时候用户考虑隐私和文件分享,不愿意把 Meta 信息放在文件中)
  • 知识管理
    • 提供常用的富文本格式 / Plain Text 全文检索
    • 最好提供上下文语句,或者渲染出来的预览
    • 如果可以做成 Desktop App,注册一个 Schema URL,供 Tiddlywiki 呼起用来展示 PDF(不是很重要,流程难打通)
  • 照片管理
    • 提供缩略图预览的能力
    • 可能的话,提供按位置信息搜索的能力。可以读取 EXIF 中的位置信息或者自定义的 Tag。比如搜索 “时间:2016 年 + 地点:敦煌 的照片”
  • GTD / 分析文件大小占用,这些功能不重要,不要去实现
  • Tag / Attribute for search and filter. Category for navigation
  • 如果可以,尽量不要用数据库(或者只用 file based sqlite3),不在文件名上存储信息,用单独的文件夹存储。这样可以方便用各类网盘服务同步数据
  • GUI 重要,CLI 可能不重要;最好用 Web-based GUI 技术,但是需要同时考虑性能