【Mendeley方案】文献管理软件协作

可以借助Bindfs挂载一下,改变MN内置资源库的位置。

谢谢,用bindfs改掉了

你好,我想问问你,改完后就是Dropbox同步marginnote的文件吗?不再需要借助iCloud?

不是的,MN的笔记数据是特殊的数据库格式,这个不能被第三方软件同步的,第三方软件只能同步MN的文档文件。其关联笔记不受影响

我遇到的问题是 MarginNote 会打乱 Zotero 的文件存储的位置。
因为想利用 iCloud 的优势,我直接把 Zotero 的 library 设置到了 MarginNote 在 iCloud 的目录内,这样在 Mac 和 iOS 设备上都可以阅读文件。
Zotero 会把 pdf 文件存在其 storage 文件夹下的名字比较“随机”的子文件夹内。如果在 Zotero 内设置默认用 MarginNote 打开 pdf 文件后,通过 Zotero 打开 pdf 时,MarginNote 会自动把 pdf 从 Zotero 的文件夹内移动到 MarginNote 的根目录下。这时再想从 Zotero 内打开 pdf 就会失败,因为已经被 MarginNote 移走了。但如果通过 Finder 进入子文件夹,在 pdf 上选择“用 MarginNote 打开”,MarginNote 可以正常打开 pdf 并且不会移动 pdf 到根目录下。 之后在 Zotero 打开 pdf 也不会有问题。虽然通过这种办法能够实现目的,但是也相当的麻烦,不知道有没有更好的解决方法。
另外,把 Zotero 的 library 整体放在 MarginNote 文件夹内的一个副作用是,每次想在笔记本内加入新的 pdf 时,会有一大堆文件出现在列表上。

6 个赞

您好,请参考我的bindfs教程及其同步tips中关于MN同步机制的说明: @hyh3

MN不会直接读取Icloud中的文件,而是将其复制到MN资源库内。即MN实际上只能打开其资源库预制目录内的PDF,不论你采取什么方法,这都是一个基本的前提。你需要通过bindfs把相关文件投射到MN资源库内。

您好,感谢您的回复。我设置的mendeley的归档文件夹是:
/Users/用户名/Library/Mobile Documents/iCloud~QReader~MarginStudy/Documents/Mendeley Desktop

而您给的建议是:
/System/Volumes/Data/Users/用户名/Library/Containers/QReader.MarginStudyMac/Data/Documents

请问这两种方法有啥区别么?哪个才是正确的MN内置资源库文件夹?

2 个赞

zotero 的那个文件管理感觉真的有一点点乱,那个 zoteofile 还是什么插件你有试过吗?

2 个赞

zotero的本地文件管理完全看不懂啊…不如mendeley简单直接方便

尝试过。zoterofile 可以将 pdf 转存到指定的地方,并且自定文件夹结构和文件名。但是 zoterofile 操作起来有那么一些繁琐,似乎不能实现导入 pdf 自动转存,除非使用浏览器插件保存文章 pdf。再加上一些其他原因,我暂时先用 Mendeley 了。但是我感到真正麻烦的地方可能还是在于 MN。

过去我以为遇到的问题是 MN Mac 会自动把 pdf 从 Zotero 的目录下移动到 MN 的 iCloud 根目录下,这样就破坏了 Zotero 文件夹的结构,再从 Zotero 里打开就会找不到文件(我想大家希望的都是在文献管理软件中管理文献,在文献管理软件中选择用 MN 打开 pdf)。但是我后来发现这不是 Zotero 的问题。只要不是在 MN Mac 内打开,文件都会被移动到 MN 的 iCloud 根目录下。比如通过 Mac 右键菜单选择用 MarginNote 打开一个文件后,那个文件也会被自动移动到根目录下。

另一个现象是当我更改了位于 MN 的 iCloud 内 pdf 文件名称后,在 MN Mac 里看 pdf 还是原来的名称。如果在 MN 的 iCloud 内删除一个文件后,那个文件仍然可以在 MN Mac 里存在并可以被打开。后面我发现这个可能和 MN Mac 的存储机制有关。

当一个文件被拖入 MN 的 iCloud 内后,MN Mac 会把那个文件在“/System/Volumes/Data/Users/用户名/Library/Containers/QReader.MarginStudyMac/Data/Documents”复制一份(含文件夹结构),作为本地存储。以下是我的猜想。如果不是在 MN Mac 内打开文件,比如上面举例的通过 Mac 右键菜单选择用 MarginNote 打开,MN 首先会发现“没有在我的本地存储内找到这个文件”,然后就会移动文件到本地存储的根目录下。因为开启了 iCloud 同步,这个文件又被复制到了 MN 的 iCloud 的根目录下。表面上看来就是一个在 MN 的 iCloud 下的文件夹内的文件被移动到了根目录下。这也可以解释改名和删除的现象。即使 iCloud 内的文件被删除,那个文件仍然可以在 MN 的本地存储内被找到,只不过就是不算被同步了而已。

至于为什么 MN 要这么做,一方面可能是为了性能以及符合苹果规范,另一方面可能更是和设计哲学有关系吧。MN iOS 只能使用存储在 MN 的 iCloud 内的文件及笔记本。如果想打开 iCloud 上的非 MN 目录下的文件就只能通过导入复制一份的方式。我记得有很多其他 PDF 阅读类 App 其实是可以直接访问 iCloud 内任意位置的文件的(我个人偏好按照课程来建立文件夹,而不是把所有需要阅读的文件都统一放在一个目录下。能访问 iCloud 任意位置就会很方便了。)。MN 之所以不这么做的一个可能的原因是笔记本。MN 对 pdf 的注释和笔记本是独立于 pdf 本身分开储存的。如果设计了打开外部文件功能的话,只能建立一个笔记本和源文件的链接。如果外部文件的位置变化了就会变得有些麻烦。但是这样做的代价是如果想在 Mac 上访问外部文件只能用符号链接(猜想,没试过)或者 bindfs 来实现。进一步的代价是 MN 和其他 App、软件协作很难,因为上面提到的文件存储的问题,而且注释默认不是嵌到 pdf 文件内的,其他地方也看不到。

不过我暂时没有尝试 bindfs,我觉得这样无法通过 iCloud 和 iOS 上的 MN 协作(猜想,没试过)。而且如果麻烦超过了一个阈值就想先不管了。目前我使用的是把 Mendeley 目录放在 MN 的 iCloud 目录下,并始终通过 MN Mac 打开文件的方式。至少在文献还不多的情况下还可以应付下去。

3 个赞

对于几个猜想我备注下
1,MN Mac会自动确保icloud和内部资源库目录均有一份PDF文件,哪里没有复制哪里,故如需与文献管理软件协作,关闭相关项目的Icloud可以避免复制。
2,MN不支持符号链接,唯一支持的方案是Bindfs,Bindfs也没有那么麻烦本身是一个程序,需要配置的是开机自动挂载,把文献管理软件的数据库文件夹挂载到MN内部资源库目录,此时如未开icloud,MN会视为不需要任何复制,不会破坏你的文件结构。
3,为什么要这么做:MN独立存储笔记数据库和PDF,需要PDF位于MN内部目录来关联和识别位置
4,不论使用什么文献管理软件都有一个共同要求,就是要么设置文献目录到MN的内部资源库目录下,要么用Bindfs挂载到MN的内部资源库目录下。文献存储位置最好有个共同的总目录,而不是散乱各地的,以方便一次性挂载完。尽可能别把目录直接设置在MN的icloud目录下,这样做会产生复制成本,增加出错几率。

1 个赞

MN未来一年会对学术用途逐步做优化,团队也会提供官方的,更简化的操作教程。

24 个赞

太棒了,我相信在对于高校在读本科生和在读的研究生,以及科研工作的人群来说,目前存在的笔记软件和文献管理软件之间不能很好的互通是一件难以解决的事情。当然我们并没有希望一个软件能解决所有问题,但是这样优秀的软件之间的相互支持无疑是极大地补充这种空缺。

11 个赞

可以试试 zotfile插件。 把所有论文的pdf文件从zotero的数据库从提取出来,对于zotero来说,你的pdf只是个相对链接,它不要求你的pdf放在它的数据库中。 可参考知乎的文章 :Zotero 跨平台同步附件的实现 Zotero 跨平台同步附件的实现 - 知乎

2 个赞

我感觉关于学术论文的优化问题,真的可以参考
Mendeley(大包大揽,所有资料和pdf都在我家才行) 或 Zotero(论文元数据在这里,pdf按相对链接指定个地方就行)的方案;
但MN不只是用于学术,可能会有很多App都由自己的资源库,如何在Mac上让多个App的资源库中的PDF通过MN打开标注,完成后再回到对应App进行文档管理,个人觉得更适合各种不同需求的方向。

6 个赞

关于自动化和插件扩展的开放接口内测征集参与者:
js定位为一种插件技术,而捷径和apple script定位为自动化技术。

3.6.5会开始支持apple script,已经在开发过程中,比较顺利(3.6.4如果没有意外会被跳版)。目前计划征集几位懂apple script的社区成员参与内测(可能未来一两周)。
另外已经比较确定MN会支持js作为内置扩展方式,类似字典扩展,制卡规则扩展都会采用js。开发者从ios的文档了解到apple已经把js bindings做的非常成熟,从而会有Jsbox这样的产品,js基本上就是apple官方指定的脚本引擎,无论从性能,稳定性,还是延展性角度,基本上可以做到通过js直接call内部methods。
js在iOS端可以和捷径结合(类似jsbox),在mac端和apple script 结合。通过目前构想的技术结构,可以很容易的把apple script实现的功能开放给js。
整个技术演进应该会跨越3.6, 3.7两个版本,分步骤来做。可能在设计实现新同步框架时借助这套扩展结构。

开放接口预计考虑对接的需求场景:

定制化搜索——统计一个词出现的频率,现有的搜索会有全部结果,但没有统计,理想的情况是给出一串关键词,统计每个词的返回结果数

笔记本数据【输出】——自动定期备份并存储至第三方云

制卡自动化——MN是自由字段,不像anki那样,所以卡片得手动选择问题部分,实际上,这个通过脚本,是可以实现自动化的,用户自己定义一些规则,然后自动化生成需要的卡片,是否填空等

笔记录入,过滤导出——文字加工【输入】——Vocabulary.com 抓取最新实时(纽约时报等各大杂志)例句注入笔记粒度卡片。——。笔记输入的入口可以提供。另外,还可以提供一些过滤笔记,执行操作的接口,比如选择过滤一些手写,自动生成笔记,选择过滤一些笔记,自动生成卡片,等等。

各位可以对上述需求场景进行补充

Regards,
MarginNote Team

2 个赞

首先超级期待MN更新,给辛苦的客服笔芯:heart:

然后提一个小小的建议,因为现在看文献基本是用endnote和mendeley,但是有些文章需要精读,然后在MN里汇集成学习本作脑图,一步步精读文献,感觉很棒的设计,但是有一点问题就是很多篇文献做完笔记之后可能就会继续读其他的文献了,过一段时间想起某篇文章的一般来说只会在mendeley和endnote里用内置阅读器查看,然后这个时候要保证在endnote和mendeley里阅读同步的话,必须要把笔记在每个pdf中先生成pdf,然后将生成的pdf传到电脑上(还有名称问题),最后在电脑上覆盖原文件。其他步骤都还能接受,不过是复制粘贴,可是笔记问题真的是很苦恼,为了让生成的pdf有笔记,必须要重新每一篇每一篇重新生成,非常慢效率很低,因此每次都很苦恼。

想求助一下客服可不可以更新一个,设置icloud端备份的pdf能否自动嵌入笔记这一选项。

感谢MN,感谢辛苦的客服。

再次笔芯:heart:

3 个赞

你好,因为目前PDF与MarginNote笔记是不同属一个格式的文档数据,所以除非进行笔记备份两者才能一起导出,iCloud同步也因此是分开存储、同步的。
Regards,
Relight

感谢MN客服及时回复!笔芯~

笔记和PDF分开存储了解啦~那请问有什么方法可以快速将PDF和笔记合成一个PDF呢?除了利用MN阅读器将PDF和笔记一起导出~