＃1

你好!

我们运行一个使用OPS作为平台的预印服务器- SciELO预印(https://preprints.scielo.org/) -我们目前有一个PDF(厨房)每个预印本。因此，我们有一个DOI用于预印。

如果作者提交的预印本有译文(2个或更多Galleys/PDF)，我们会要求他们单独为译文重新提交，这样译文就会有自己的DOI。这是我们一直在做的。

然而，我们最近发现，OPS和OJS很像，不仅在提交级，而且在Galley级允许DOI的分配。

处理预印本翻译DOI的最佳方法是什么?

选项一:

提交- DOI 1
Galley 1(原语言)- DOI 2
厨房2(翻译)- DOI 3

选项二:

提交-不DOI
Galley 1(原语言)- DOI 1
厨房2(翻译)- DOI 2

选项3:

提交- DOI 1
Galley 1(原始语言)- DOI 1(与提交的DOI相同)
厨房2(翻译)- DOI 2

我们使用Crossref。有人知道这里最好的做法是什么吗?

＃2

“你好，”几个月后，他插嘴道。我们也使用Crossref，并一直在与他们讨论最佳实践——我们仍在积极学习这方面的知识。DOIs当然只是文档对象标识符。也就是说，它们是到某个端点的永久链接。如果愿意，您可以将DOI应用于您拥有的每个文档，包括您的隐私政策甚至博客文章，但有一个收益递减的点。

我的理解是选择一个是理想的，或者只有提交的文件有DOI的第四种选择。原因是，对最终用户来说，提交是最有用的抽象层，你可以通过外部链接到它。这意味着，如果分发提交DOI，用户将能够在下载他们喜欢的文件之前看到完整的元数据和上下文。也就是说，你可以通过各种方式向你的每一个版本发布DOIs——问题只是它对用户有用还是出于内部原因，或者即使它稀释/混淆了引用和参考统计数据。

在一天结束的时候，这取决于你和你的组织。由于每个组织都有一个DOI前缀，所以实际使用的模式和方法完全由您自己决定。所做的决定之一是您希望向哪个抽象级别添加标识符。

＃3

你好@benaltair！

谢谢你分享你的观点。

在我发表这篇文章后不久，在做了一些测试之后，我意识到选项1目前在OPS中是不可能的，因为你不能给每个厨房分配一个DOI。

事实上，你可以，但是他们没有在Crossref中正确注册，所以在一天结束的时候，DOIs将不起作用。

我不知道这是OPS还是Crossref的限制。

＃4

有趣，谢谢分享一些细节!我们使用OJS，并且只对每个问题和文章(提交)申请DOIs。有一个选项可以添加到厨房，但它并不适合我们的需要。

听起来这可能是Crossref Import插件的一个bug，因为我没有看到Crossref API中的任何限制会导致这个问题。