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

如果MarginNote未来能够与mendeley, endnote, zotero 和 paper 等文献管理软件合作的话,应该能吸引更多人购买。

MarginNote在阅读文献方面可以说已经说已经做到了极致,但当论文非常多的时候,查找管理文献就不是很方便了。Mendeley,Endnote之类则恰恰相反,找论文很方便,但它们内置的pdf浏览器比较鸡肋。如果存在合作的可能性,是否可以使献管理软件引用条目的全文附件支持MarginNote格式,这样点开全文时能用MarginNote阅读和批注,之后又能十分有条理地分类保存在Mendeley,Endnote中,体验会非常好。

更好的情况是,MarginNote自身加入识别pdf文件后生成引文信息的功能,优化一下文件分类,甚至加入在word里插入引文信息的功能,这样的话就真的完美了。

1赞

你说的这些功能感觉不是很现实,客观原因是marginnote已经在功能非常复杂了,开发者团队很小精力有限,更新修复已有的bug都已经感觉有点儿力不从心了,不大可能添加这么大一块数据管理功能,文献识别是个大工程。

不过你目前的需求跟我一样,经过长期摸索,告诉你一个完美解决办法,看完你一定会很感谢我,哈哈哈哈哈:laughing::laughing::laughing:!你仅仅需要把mendeley的归档文件夹设置到iCloud的marginnote文件夹里就行了,一分钟搞定你的需求!以后阅读文献时,在mendeley里搜索到相应的文件,然后右键单击Open File Externally就可跳转marginnote做批注了。

5赞

好的谢谢!!我试试

我自己花了近一千多买了个正版EndNote,如果Marginnote做到这些,我再花一千也无妨(´・_・`)

1赞

感谢seantan521的建议,如果是Mac使用,还有一个更好的办法:
直接设置MN内置资源库文件夹为Mendeley的归档文件夹。MN的同步机制是复制icloud文件,故该资源库文件夹同时包括了icloud同步文档和本地文档。

/System/Volumes/Data/Users/用户 名/Library/Containers/QReader.MarginStudyMac/Data/Documents

参考

2赞

啊啊啊,看的感觉好复杂呀……我用的EndNote,本身还有EndNote自带的同步服务,会不会有冲突呀

同步方面,如果您按我给出的路径添加为资料库(不确定Endnote是否支持自定义资料库位置),MN内的同步不开启的状态下,就不冲突,但是MN的笔记和文档是独立存储的,这样笔记就需要您自行备份了、

endnote它只会同步文档,不会同步MN的笔记数据

2赞

我把Mendeley的归档文件夹设置在了dropbox里, 那可以把MarginNote的内置资源库文件夹也设置在那里吗?

可以借助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 时,会有一大堆文件出现在列表上。

1赞

您好,请参考我的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内置资源库文件夹?

1赞

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

1赞

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 打开文件的方式。至少在文献还不多的情况下还可以应付下去。

1赞

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