🔖 | 《陆犯焉识》严歌苓

作者:  严歌苓

字数:29.3w

初版年份:2011


大草漠上的所有活物都把一切当作天条,也就是理所当然,因此它们漫不经意地开销、挥霍它们与生俱来的自由。

婉喻看着申请书上的娟秀小楷被烧得疼痛扭动,变形变色,由黑的变成了白的。她把字迹的骨灰倒进一个杯子,冲上水,当偏方喝了下去。带焦糊味的偏方该根治她的妄想症。

他们吃完狗肉,在候车室里拉屎,拉出的屎又成了捕狗的诱饵,圆满的食物环链就在这个二十平方的世界形成。

他把她的纯洁外壳剥去,放在竹席子上,要他把她当个器皿,只用来盛装他的欲望。

梦游者们的理解力和语言似乎跟看守隔着许多生物代,都不懂他叫喊的是什么,仍然以他们失重的步子走他们的老路。我祖父在回忆录里说,那史前人的示威或送葬的队伍,与看守隔着一层抽象的时空,无法穿越。

秋季的胡萝卜和洋白菜丛里,从此躺了一个老犯人老几。太阳从玻璃房顶、玻璃墙壁照射进来,照在莲花一样的洋白菜上,叶瓣上都是黄色的尿珠和莹白的水珠,每一颗珠子里都有一个太阳。◼️

🔖 | 《倾听》辽京

全文指路:《芙蓉杂志》2021第3期


女人是器具,这句话是很多年后突然冒出来的,好像上千年的世间精义突然从黑暗中浮现,她拿着一根蜡烛就照亮了传统的废墟,废墟底下压着无数先人。

她被“女朋友”这三个字按住了。关于恋爱,她一切的知识来自童话和偶像剧,她努力地想寻找论据,想为自己的意愿找到合理的解释,他已经把裤子褪到脚底,依旧笑着,努力制造一种轻松的气氛,让她觉得自己是在小题大做。

我后悔了,不该打断她的告白,就让她继续绕圈子,像不停盘旋的鸟,累极了,自然就会落地。可是我等不及了,把它一枪击落,不加掩饰的语言就是子弹。

浑圆的月亮露出来了,光彩明净,毫无瑕疵。这不对劲,我想,真的月亮上怎会没有阴影,倒像一只光洁的瓷盘子。有人把它举起来,朝童童脸上扔过来,继而落地,砸得粉碎。她说,频繁的暴力开始了。那枚月亮是假的。

如果第一次就没有反抗,后面的反抗还有意义吗?

那把刀并没有碰过她的身体,却长久地插在她的心上,结痂了,锈住了,拔不下来。邱刚将双手枕在脑后,眯起眼睛,笑嘻嘻地等着她,她想到的却是夺门而逃。来不及呀,她想,要穿外套,穿鞋子,外面那么冷,他一下子就抓住我了。

第一波巨浪袭来,听得见船舷上传来轰然巨响,像一声炸雷,大海只不过舔了一下舌头,我就觉得末日降临了。

她想过找个借口,比如要去卫生间,卫生间就在大门旁边,或许可以找机会逃掉。她说了,邱刚回答:“去卫生间可以,但是不许穿衣服。”然后就放开她。

◼️

🔖 | 《遍地风流》阿城

作者:  阿城

出版社:作家出版社

字数:13.8w

初版年份:1998


不过依我的经验,青春这件事,多的是恶。这种恶,来源于青春的盲目。盲目的恶,即本能的发散,好像老鼠的啃东西,好像猫发情时的搅扰,受扰者皆会有怒气。

《自序》

人要学了鱼,赶明儿可就是鱼打人了。把人网上来,开膛,煺毛,抹上盐,晾干了,男人女人堆一块儿,鱼穿着袄,喝着酒,一筷子一筷子吃人,有熏人,有蒸人,有红烧人,有人汤。

《湖底》

杨树叶在水里泡了一年,酸酸的,很苦,捞在碗里下饭。以为像城里小铺子卖的橄榄,嚼嚼就会回甜,于是低下头嚼,很久很久,还是苦的,只得咽了。

《天骂》

猫干净,自己到外头土里拉屎,完了还知道自己用土盖上。金先生心想,这猫祖宗不知遭过多大的罪,才这么一代一代小心着。

《宠物》

老齐呀,你给评评理儿多少年了,没有闲工夫静下来再识字。文件精神社论指示,年年有,月月有,天天有,虱子多了不咬,反正叫识字的人念就是了。街道里识字的人出身成分不好,老老实实地念。

《扫盲》

老林问,既然手册里规定垃圾是完全丧失利用价值,为甚么还有捡垃圾的呢?大家的顶,经这五雷一轰,都说,是呀,为什么还有捡垃圾的呢?这些日子,中央不是宣传时间是检验真理的唯一标准吗?检验检验,废品研究所的说法,就不一定对。

《结婚》

老家渐渐体会到,哲学的贫困导致贫困的哲学,同理,哲学的正确导致正确的哲学,因此,前提的正确,导致几乎是所有的正确。

《定论》

所以,工作队并不轰轰烈烈地进寨子,而是悄悄的,小孙想起电影里日本人进村,“打枪的不要”。猪和鸡懂政策,悄悄地不响。狗不懂,狂吠,还扑过来。

《小雀》

◼️

🔖 | 新系列之书摘整合

这个系列将主要用来汇总读过的随便什么书的心仪句段。

很早以前,在Lofter上和几个朋友一起弄过一个书摘频道,看到喜欢的句子就发布,很随意也很零散。后来看到上面另一个主页( @食野社 ),它总是将同一本书的摘抄汇总在一起。因为不喜欢预先“断章取义”,所以多年来一直没有仔细阅读过这种形式的书摘。但是对于整理自己读过的书,却不失为一种好方法。于是多年后的今天,开始效仿!

有考虑过再开一个博客专门发书摘,但是毕竟不成规模,而且也算是自己一种的日常,最后还是决定混合在这个Blog里。

这个系列也会用emoji “🔖” 做标记,后面会标上书名,如果遇到不想读的书、不想被剧透的书,请及时止损昂~~

更新频率肯定是很慢很慢很慢,要很闲,还要读到合眼缘的书,才能做。

就这样!

Notion进阶之【大瀑布】(1/2)

这部分的结构较之前三篇庞大很多。之前的三种顶多几个小时就能完善成型,但是这一次,从初次构思到结构基本定型,总共应该说是花了几天时间(除去其间置之不理的几个月……)。目前为止,基本形成了一套相对完善的信息互联网络,其中也包含一些在当前无伤大雅的、尚未找到方案解决而暂时被搁置的问题,会在每一部分的末尾列出,将来解决了的话也会回来更新。

本部分原本想和上一部分(剪藏)合在一起作为一个大专题来写。但是这一部分有点复杂,一章搞不定,所以干脆独立出来写。

用途简介

所谓大瀑布,就是……信息大瀑布……因为我设计这一部分的目的是创造一套方便随时取用的史料整理法,随着深入的补缺补漏,整个系统的总信息量会急速膨胀,所以,不光是信息总量庞大,整体结构也将是我的Notion中史无前例的立体和细致。

这些DB所涉及的历史资料中,包含事件、人物、团体和国家(暂时不包含时事,时事相关的资料主要还是收纳在剪藏板里)。同时,也能较为便捷地从各个角度切入、根据不同的范畴来读取相关的资料。当然,这一套系统中还可以加入更多类型的内容,也一定适用于更多不同的用途。我只是就设计它时的预期和目前达到的效果来展开介绍。

核心板块

如左图所示,本资料库涉及4个核心Database:
1. 人物;
2. 组织与团体;
3. 世界史瀑布流;
4. 国家史。

为了避免单章篇幅冗长,本节将分为两个部分发布。第一部分主要介绍人物DB的结构,第二部分介绍其他三个DB的结构。


2021年1月25日更新。更改内容:
原人物db对国家&世界史的relation改为单向引用。

人物板块

上述四个板块中,人物db内部还增加了两个子db,用以整理人物的生平和作品表。将来可能在其他板块(比如国家)下也会按需增设新的子db。先尽量简单地介绍一下这已有的4+2个互联关系。直观起见,我画了一张图。

人物Database互联关系图

构成概述

以贝多芬的资料页为例,以下是经过初次调试后刚好能用的状态。先简单介绍一下页面的结构,后面会解释如此安排的考虑。

为了方便叙述,下文将database中每个页面的标题栏称为“根prop”。

人物DB内部的“希特勒”页面。
核心Prop有:中文译名(根prop)、原文名、籍贯(古属、今属)、领域、生卒年、曾加入的团体、有一定影响的历史事件。
其中,籍贯和历史事件都是单向引用(text属性),团体为relation的结果显示。

年龄算法参考:

dateBetween(prop(“卒年”), prop(“生年”), “years”)

解释一下某些地方使用引用、某些地方使用relation的考虑。
①  国籍方面,考虑到有的早期国家在今日已被瓜分至不同的政权手中,如果仅仅录入今属国家而导致原本国籍相同的人物看上去具有了不同国籍,不太恰当。所以用引用的方式能比较灵活地作出标记。
②  历史事件方面,考虑到在人物页面中,经历同样事件的人物对该事件的影响力大小不一,有些人仅仅作为经历者,而有些人则是促成了这些事件的中坚力量之一,为了避免在事件页面堆积不必要的无关信息,所以取消了原来的relation,改为更灵活的单向引用(说是单向引用,其实被引用的页面上可以回溯,有需要的时候查看起来也很方便)。
③  至于团体之所以使用relation是因为,在我有限的认知里,人物所属的通常都是党派或者什么协会之类的团体。这类团体在网络上的资料不比国际联盟(总是会详细列出其成员国及附属国),通常只能考虑到其中最有存在感的几位。所以在这里使用relation,使其成员能无差别地在组织资料内显示,就有机会发现某些意想不到的历史关联。

人物独立的作品表Database。
“贝多芬”的这个DB的核心Prop有:作品名称(根prop)、创作年份、创作背景与时代背景。
其中,除了作品名称以外,所有的元素都是与下面这个DB——“贝多芬大事记”——互联的结果。年份是relation的直接显示,再通过rollup显示相对应的生平和时代背景。
此外可选的prop有作品号、学习状态等等,只要能想到的,都可以按需增减。

人物独立的大事记Database。算是两个子db中更为主要的一个,可以很直观地显示人物在每个阶段经历的事件及产出的作品。
核心prop有:年份(根prop)、生平事件、时代背景事件、作品和相关资料。
其中,作品是与上面的DB(“作品表”)互联的呈现,相关资料是与“剪报”db的互联呈现(以摘取平时读到的相关资料)。

一点思路&未决问题

通常情况下,根prop的默认名字“Name”以及它在页面中所处的位置,会导致潜意识地将它用作标题栏。但是,考虑到其在关联的db中所需要显示诸多的信息,全部用作标题显然会减损效率(比如基于relation的显示特征,它无法直接完整显示过长的文本)。

所以在大事记年表中,用根prop而非其他属性的Prop来显示年份,目前来看是一种较为有效的妥协。这样,在作品表prop中,关联大事记的prop直接可以标记作品年份,同时用rollup显示完整的背景资料。

尚未解决的问题主要集中在生平db和整个构架的脱节上。之所以会产生这个困难,主要是因为所有人物的子database都互相独立、且生平事件按照年份来划分。这种脱节导致的结果就是,在生平db中只能手动输入背景资料,不能直接从现成的史实db中提取信息。有利有弊。利在于录入的时候可以体现更多相关度更高的信息(比如更为小道的花边信息),因而更自由;弊端在于人物资料多了之后,必定存在一系列大事件同时对多人产生影响,你只能反复录入(被迫背书.gif,倒也不赖?🌝)。

暂时决定让它们互相独立的原因有三:

首先,历史人物的数量不必说,每人生命中的每一年都被重复统计,怕崩溃;
其次,跨领域的人物作品形式和相关信息都是不一样的,比如科学家就不存在作品号的问题,艺术家就不存在研究成果具体所属的学科、以及实验条件等问题,综合在一起的话,会牺牲单个页面的显示效率;
再次,如果为了读取世界时间线上的信息,将每个子db都与世界互联,那么总线程上的信息会过于杂乱冗余,同样影响显示效率(毕竟在那些页面内除了prop,下面偶尔还是会写一些笔记或者存点附加资料的)。

总之,目前对database容量极限(开始影响读取速度的极限)不了解,还是会避免进行巨量页面的集合。将来如果证实神奇的Notion在此方面并无障碍,可能尝试根据学科来汇总人物的子prop。


因为本套结构其实还没有彻底完善,有可能将来还会回来修改。所以把思路写出来,主要是为了让大家了解其中的一些尝试和取舍,同时也更容易发现我没主意到的问题,作出符合自己需要的取舍和改进。

下一篇应该是整个系列最后一篇。

Notion进阶之【网页剪藏】

数据库页面参考

本章主要分享相对(超级)简单的网页剪藏。原本是打算把上图整个资料库分两部分介绍完,结果写到第二部分的时候发现第二部分真的太庞大了……所以这一部分就独立出来,不作为资料库的一个局部,而作为剪藏来介绍。

我所参考的基本都是现成网页剪藏服务——如Instapaper, Pocket等等——所共有的基础功能。

模块介绍

基本元素如左图所示。
核心元素有二:【资料类型】和【网址】。除此之外,我还增加了三种信息:
关键词:为了细化索引。如果汇总到一个属性内,将很难在一个范畴中作出细分,且会造成主题与种类这两种不同属性的混杂,造成混乱;
发布时间:为了弥补剪藏看不到原网页发布时间的缺陷。某些资料的内容和其发布的时期是分不开的。
备份网址:这个prop其实可以不要,Notion剪藏本身就是永久的备份。我主要是因为从别的软件搬家过来的时候,有些文本已经是备份在第三方网站上的(比如telegra.ph),无法确定其原始网站、发布者及发布时间,所以才开了个prop,以将这类失去源的资料区分开来。

通常情况下,转发剪藏后,page的原始状态是:标题为网页被分享后会显示的标题;网址将储存在链接属性的prop里(如果像我一样有多个链接属性的prop,在剪藏时可以手动选择要录入的位置);被转录的内容(包含图文)会存储在页面里。有时候,内容会延迟一段时间才录入完毕,总之只要是能转录的,迟早都会自动提取好,所以不用管它。

然后是基于上述“类别”与“关键词”进行文件夹式的分类,两种方案:视图和副本式分类。都是很基础的操作,不赘述了。有需要的可以去翻我之前书库那一章(点这里)关于待读和已读Database部分的分享。

我主要使用视图的方式进行粗略的归类。曾经打算用page来优化视觉上的体验,后来因为懒,放弃了……因为搜索关键词来找对应资料实在是太容易了……

一点经验&优缺点

我浏览网页使用的是ios原生safari,因此剪藏方式都是直接分享网页到剪藏板db。Chrome据说有很好的插件可以使用。MacOS的Safari还没找到剪藏的办法。至于其他系统的,就需要自己去摸索,不过我猜都是大同小异。

优点:

  1. 阅读时可以随意编辑、标记文本。这在其他专业剪藏软件里,可能是付费版的功能,而且仅仅只能涂高光和做笔记。编辑,甚至插入什么相关资料,你想都不要想……
  2. 页面互联的优势不用多提了。
  3. 能够自由地重组和梳理资料,而不用像在其他软件里一样,受困于简陋的分类方式(文件夹和标签)。
  4. 真正意义上的“剪报”,即使原文消失或被更改,都不影响已经剪藏的内容。当然,有的软件(比如Instapaper)也能做到这一点。

瑕疵:

  1. 会有大约一成(或者更少)的网站,无法直接剪藏。这意味着,剪藏后只会转录标题和链接,内容是空的。我一般是定期处理这类的剪藏(反正有链接),挨个将原文本复制过来。
  2. safari转发到Notion的话,无法默认目标db。就是说,或许你每次要发送网页到剪藏板的时候,都得重新定位到目标剪藏板。Chrome插件则不存在这个问题。我(用safari)在最初的几个月内也是不存在这个问题的,但是这两个月开始必须每次重新选择。目前还不知道症结所在。
  3. 之前发现过一次(严格来说,只有一篇文章出现过此状况),带图片的内容转存之后,在手机端无法显示图片(提示提取失败),但是电脑端显示正常。询问过大佬,说是某些网站图片的源的问题。给出的方案是自己挨个把图存下来,重新上传。有(ji)点(qi)麻烦,不过后来也没再遇到过类似的情况,就没在意了。如果真的很重要的东西(比如某些随时会消失的资料……),费点劲存图也不是啥事。

差不多这样。

Notion进阶之【书库】

在用Notion之前,都在用豆瓣记录看过的书籍电影。其实现在豆瓣的移动端做得挺好的,ui设计得有模有样,各种形式的统计也层出不穷。唯一致命的就是审查,他们不得不随意关评的条目,不得不隐藏的内容。就跟嫌弃百度云一样,你把它当做数据库用,结果说没就没,存了个寂寞。

所以在熟悉Notion用法之后,果断搬家了。

本文和已经发布、即将发布的系列tips一样,都是进阶的、内容简洁的轻型分享,重点分享思路,不特别做基础知识普及。对notion不熟的人,如果对本用法有兴趣,需要自行搜索入门教程进行补习(推荐大佬177的视频教程)。

用途简述

平时读书的时候,总喜欢记录版本、阅读起止日期,回顾一下前一阶段读了多少书、都是哪些作者的书;还有多少翻开了没看完的书等等……

这些在Notion都得到了满足,更吊的是,它能有无限的方式为你的需求作出精确分类。

本分享涉及内容较上一篇多,可能有点长。

p. s. 本blog的菜单里有分享我的书库,随时来玩~

模块介绍

为了满足前面所提到的诸多功能,只用一个database是不够的,还需要原始database的诸多副本。所以原始database在以下简称为元database。

元Database:原始书库

因为副本众多,我以功能将它们分散在两个页面里,一个页面用来收集所有已读的书目,以及所有登记过的书目(包括未读的);另一个页面用来给所有在读、未读的书目分类。

左图是我针对每本书做的记录,其中核心元素为:
作者、阅读进度、喜恶(、书籍资源)。

书籍资源(附件属性)如果利用得好的话,相当于搭建了私人网络图书馆。

阅读进度有两种方式可以测算:

1. 如果你以阅读电子书为主,那么就有条件直接输入当前的百分比。(此时进度prop是Number属性)
2. 当你阅读的载体多样,就需要用到算法prop。为了能够计算阅读进度,两个number属性的property是不可少的:一个表示整本书的总量,一个表示当前进度。你可以选择以页码为参数,也可以kindle的位置作为参数,等等。

第二种方式的算法参考:

if(ceil(prop(“已完成”) / prop(“总量”) * 100) > 100, “error”, if(ceil(prop(“已完成”) / prop(“总量”) * 100) == 0, “🕒”, if(ceil(prop(“已完成”) / prop(“总量”) * 100) <= 5, “■ ” + slice(format(round(prop(“已完成”) / prop(“总量”) * 100)), 0, 4) + “%”, slice(“■■■■■■■■■■”, 0, round(prop(“已完成”) / prop(“总量”) * 10)) + ” ” + slice(format(round(prop(“已完成”) / prop(“总量”) * 100)), 0, 4) + “%”)))

待读书目Database

海量的副本来了= =+ 应该可以看出来我是个分类狂魔……

在这个db中,我通过3个层级对书目进行了分类:

1. 区分“计划要读”和“单纯的mark”
2. 在“计划要读”的内容中,区分“正在读”、“排队中”、“搁置”
3. 基于上述两大类的“文体方面”的分类

上述几个方面都是直接用filter分流(第一层)之后,以单选prop(状态prop与文体prop)来区分的。
想这么搞的请注意,因为每一层内的副本必须包含更高层级的filter,建议先设置第一层的filter,然后再以各自的副本创建第二层的副本,再以第二层副本生成第三层的副本,这样会自动复制已经设好的filter,就不用每个副本都重新设置了(挨个弄会疯的)。

截图中有一个模块的标题中均显示“🔆”,这个相当于我手动设置的“置顶”,用以标记需要优先阅读的书籍。
这个模块需要在上述filter的基础上,增加一个“标题里含有🔆”的条件。

已读书目Database

这个模块就简单很多,年度阅读时直接按照年份来显示,底下的归档是方便进行整个库的索引,保留默认设置就行。

关于按照年份来显示内容,有两个方案:

1. 直接从“完成阅读的prop(Date)”里读取年份,通过filter来实现
这种方案可以通过给副本创建不同视图来显示历年阅读记录。但弊端在于,如果你的date数据包含起止两个日期、且两个日期分属不同的年份的时候,会重复统计。可能有算法可以优化这个问题,需要研究。

2. 通过单选prop来录入年份
我就是使用这个方法,建立了一个记录完成阅读的年份的单选prop,然后直接基于这个prop来区分内容。弊端是如果你已经记录了阅读起止时间,就相当于得多记录一个重复的数据。

书单Database

先解释一下这个书单的逻辑。书单和书库联动,只需要将书目添加至相应的书单里,就能得到一个随着你的阅读完成度自动更新进度的书单。(菜单栏中同样有分享。)

从db名称可以看出来,这是新的db,它关联了书库db,并通过roll up显示了有必要的内容,为算法提供数据。

书单db的核心元素有:
书单名称、关联db(与书库关联)、roll up(统计已完成的数量)
此外我还添加了:
deadline(Date)、书单所包含的书籍总数(roll up)

关于统计完成百分比的Roll up如何选择:
用一个Prop.来将一本书标记为已完成的方案有很多,以下是两种思路:

1. “已读”复选框:
读完了就打个勾,统计已打勾的数量。从思路上最简便的方式,但如果你在书库里已经有统计阅读进度的prop,就相当于需要多操作一步。

2. 通过评分(或类似的)prop是否空白,来识别一本书是否读完:
我使用的就是这种方式,不需要进行多余的标记。但它涉及记录时的顺序问题,你需要确保在读完一本书之后才填写该prop,否则会造成数据失实;
这个方式的弊端在于,当有些书你再也不打算继续读并且想要给个差评的时候,它也会被识别成已读,因而无法与那些真正读完了的书籍作出区分。

“进度”Prop的算法分享:

slice(“■■■■■■■■■■”, 0, round(prop(“表示已读百分比的prop”) * 10)) + slice(“□□□□□□□□□□”, 0, 10 – round(prop(“表示已读百分比的prop”) * 10)) + ” ” + slice(format(prop(“表示已读百分比的prop”) * 100), 0, 4) + “%”

关于视图选择

主要是想谈谈mark的书籍的视图选择。个人认为列表(List)视图的显示效率最高,同时视觉上最简洁。

据我观察,“买书如山倒”的心态一样投射在mark书籍上,甚至因为不占地方也不费钱,比买书的增长速度还快。mark的书多了,拖延得久了,自然就忘记了当初为什么mark。在List视图上,选择显示“mark的原因”这个property,应该可以在将来找书读的时候提高效率。

衍生

权限问题

如果想要公开自己的阅读记录给别人看,那么这个元db放在什么位置,需要斟酌。
元db开放权限是所有分享行为的前提。Notion的权限是自下而上的,也就是,如果你的元db没有开放权限,访客就无法读取它的副本和内页;其次,如果是想选择性公开内容、而将隐藏的内容放在元db的话,即便元db不在页面上,访客一样可以通过db标题的箭头访问到你的元db。
所以,建议将元db用作子模块来展示(比如阶段阅读、推荐书籍等等模块),设置好filter之后,将页面上锁,再创建一个副本放在后台,将副本作为替代的元db来展示全部的内容。

与论文资料摘录db关联

如果读过上一篇关于用Notion搭建论文文摘库的分享,那么这一篇的db其实也可以与上一篇的db建立relation,读论著的时候也可以将素材整合进那个db里。

Notion进阶之【文献收纳】

用Notion断断续续已经一年了,自从半年前和几个朋友买了团队版之后,就开始密集使用,过程中逐渐演化出了许多用法,从打卡库,到基于打卡库的各种清单,到自动识别阶段的任务列表,到网页的剪藏……有些自己觉得很实用的用法想要总结,虽然写在WP,分享的效率差不多是0。但是在找到其它合适的分享地方之前,先发在这。

本文和之后有可能发布的系列tips都是进阶的,内容简洁的轻型分享,重点分享思路,不作任何基础知识普及。对notion不熟的人,如果对本用法有兴趣,需要自行搜索入门教程进行补习(推荐大佬177的视频教程)。

用途简述

正好最近在构思一篇论文,要阅读大量文献。我是一个不喜欢阅读过后整理笔记的人,但是无论是小说还是论著,阅读过程中确实会有一些值得标记的内容。所以一直苦于没有一个合适的方式和载体,去整合这些的内容,直到我发现下面的方式。

这个方式中,前期花费少量的时间,便可以将长期以来阅读过的文献中有可能有用的资料进行有效整合,以关键词(或议题)、出处等方式,随时进行索引,也能够使用database自带的搜索功能搜索特定的名词以提取所有相关内容。以上仅仅是它至少能满足的要求,diy的力量是无敌的。但是单单是以上的方式,就很适合学术研究的初期积累了。

可能它适用于某类人却不适用于其他人,所以只能期待它能给你一点启发拉~

模块介绍

首先,需要创建两个独立的Database,其中一个用以存放文献(论文阅读记录),另一个存放摘录(素材收录中心)。并用relation属性的格子将两个db链接起来。
为了视觉上减少干扰,我将两个Database分别创建于两个页面内。具体咋搞,全凭喜好和需求。

存放文献的db包含核心元素:
论文名称、论文论题/关键词、论文文本、笔记备份、relation to素材资源库。
在这个db中,可以浏览某一特定文献的所有过往摘录,如果添加了引用频度数据,便可以通过roll up属性的格子对某一文献的局部、整体引用数据一目了然。

存放摘录的db包含核心元素:
摘录内容、内容所对应的关键词、所属页码、内容元数据(源实验的信息)、以及在页面中可以记录提及该实验的完整段落。
前面说过,这个db可以综合所有来源的摘录,就某一特定的命题或关键词,进行有效索引。同时,在备注中,可以直接同相关论文互链(已有页面可以直接@),方便追溯。

衍生 & Tips

这种方式的退阶版还适用于灵感素材的收集。不少活跃在上世纪的作家,会习惯随身带一个“卡片盒”,记录随时随地的灵感什么的。这差不多和文摘是同一种功能。

一个小Tip:

当同一部著作(即同一个来源)里需要摘录的内容很多时,可以单独建立一个视图,在Filter里设置好引用来源和其他相同的信息(比如:如果大部分摘录,都会有某个相同的标签的话),然后直接在这个视图里进行条目添加,每个页面就会自带filter里设置好的条件,不需要再逐个编辑了。

刚才本来还想到什么类似的用法,忘了……回头再补吧。