Registry: String/objeto de citação GBIF em todos os conjuntos de dados

Discutimos um pouco isso com Andrea esta manhã, sou totalmente a favor de uma única citação recomendada, ou seja, citação padrão, que seria montada a partir dos metadados, respeitando os papéis, ordens de nomes etc. Precisamos ter certeza de que GBIF.org , talvez a data de publicação da última versão, e o DOI são as partes da citação que não podem ser modificadas, a menos que sejam republicadas. Andrea menciona um possível problema com as editoras não IPT, como as editoras ABCD e BioCASE.

Continuo a recomendar que reutilizemos o formato de citação preferido do DataCite, que atende à Declaração Conjunta de Princípios de Citação de Dados . Este é o formato que o IPT usa para gerar citações automaticamente. Mais informações sobre este formato podem ser encontradas aqui .

Acredito que, desde que comuniquemos claramente como derivamos nossa citação de EML, ABCD, etc, os editores terão a chance de adaptar seus metadados de acordo, caso seja importante para eles.

@fmendezh Caso ajude, este é o método utilizado no IPT para gerar automaticamente a citação do recurso. É claro que ele usa objetos de modelo específicos do IPT, mas felizmente eles são bastante semelhantes aos nossos objetos de modelo do Registro.

@dschigel , você já falou sobre formatos para download para software de gerenciamento de citações. Se isso é algo que realmente queremos fazer no futuro, esta é sua chance de descrever os componentes atomizados necessários que a API precisa expor para que isso aconteça.

Sim, aqui está o que escrevi em 23 de setembro, ainda válido:

Olá Morten,

Você perguntou sobre os formatos bibliográficos para os quais poderíamos exportar a citação recomendada do GBIF (desculpe que a citação em si não tenha chegado à forma final ontem).

Segue minha sugestão:

Use três formatos para os quais o Mendeley está exportando, veja a imagem anexada
O grupo Nature P está usando apenas .ris.
Além disso, precisaremos do texto livre (mas qual sistema - para verificar com os comunicados depois de decidirmos o que entra na citação do GBIF - desculpe a demora do nosso lado, como você provavelmente sabe da discussão com Andrea, esta não é uma decisão trivial) .

Esses três formatos de exportação devem ser suficientes para obter algumas das principais funcionalidades de exportação de citações para a caixa/popup planejada HowToCite etc.
A citação em si ganhará forma à medida que progredirmos com KC, KB e AH.
Se você quiser ter mais, outra imagem tem os formatos de exportação que a Science está usando.

Verifique também os botões CrossMark e Share no PLOS One no lado direito de qualquer papel:
http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0159184
Espero que Siro possa comentar isso também.

Dmitry

Pode ser uma boa opção fornecer vários formatos no site, mas para muitos propósitos precisamos apenas ser padrão. por exemplo, citado dentro de downloads ou na api. poderíamos considerar lidar com um objeto de referência complexo na API em vez de uma string para permitir várias formatações, mas atomizar referências genericamente bem é um desafio.

Feedback oportuno de Rod gbif/portal-feedback#33 sobre a adoção do CiteProc

Há também uma implementação java e JavaScript:
https://michel-kraemer.github.io/citeproc-java/
https://github.com/juris-m/citeproc-js

Baseado no exemplo para Dataset do Joint Declaration of Data Citation Principles (https://www.force11.org/node/4771) e uma versão modificada do método IPT.

Para o conjunto de dados 98333cb6-6c15-4add-aa0e-b322bf1500ba , geraríamos uma citação padrão como:

Smirnov I, Golikov A, Khalikov R (2017): Ophiuroidea collections of the Zoological Institute Russian Academy of Sciences. Zoological Institute, Russian Academy of Sciences, St. Petersburg. Dataset/Occurrence, accessed via GBIF.org on [date]. http://doi.org/10.15468/ej3i4f

de @timhirsch : Essa abordagem parece boa. Eu acho que o único problema que causaria para [agregadores é que eles] saíssem como a instituição atribuída porque isso é tirado da editora designada, certo? Nesse caso, poderíamos/devemos incentivá-los a registrar cada uma de suas instituições contribuintes, para o qual talvez possamos ajudar com um 'endosso em massa'?

Eu substituiria "Dataset/Occurrence" por um "Occurrence dataset" mais legível por humanos, sem vírgula.

Acessado via - é um pouco redundante. Uma função de plataforma de publicação de dados, análoga a uma editora, provavelmente é tão importante quanto o acesso - observe que em referências de livros você diria apenas Taylor & Francis, não "publicado por". Acessado via será marcado pela maioria dos redatores das revistas.

A maneira como o GBIF.org mencionou deve ser a mesma para as citações nas páginas do conjunto de dados e nas telas de download e como citar?

O problema de excluir 'acessado via' é que você remove qualquer menção ao GBIF na citação recomendada!

Não, eu não pretendia remover o GBIF.org - pelo contrário. Apenas palavras acessadas via são um pouco redundantes - como todo o ponto de uma citação para indicar o "acesso via". Eu quis dizer:

GBIF.org, [data da última versão ou da primeira publicação]. Conjunto de dados de ocorrência: http://doi.org/10.15468/ej3i4f

ou similar

Depois de compilar o feedback, temos:

Smirnov I, Golikov A, Khalikov R (2017): Ophiuroidea collections of the Zoological Institute Russian Academy of Sciences. Zoological Institute, Russian Academy of Sciences, St. Petersburg. GBIF.org, [2017-01-27]. Occurrence Dataset. http://doi.org/10.15468/ej3i4f

@dschigel a data [2017-01-27] é a data de acesso, tudo bem?

Para mim isso parece bom. Ele irá liberar questões em que as pessoas sentirão que o editor não é a instituição apropriada para obter o crédito principal na citação, mas isso pode atuar como um incentivo para, por exemplo, as redes registrarem suas instituições fornecedoras separadamente como editores de dados.

Graças à discussão muito útil com @kbraak e @siro1 , e de acordo com as recomendações do DataCite https://schema.datacite.org/meta/kernel-3/doc/DataCite-MetadataKernel_v3.1.pdf (consulte a seção 2.2), Sugiro que usemos o seguinte híbrido que funcionaria tanto para a bibliografia quanto para os mundos de dados. Aqui está o exemplo que seguiria os princípios de citação de dados https://www.force11.org/group/joint-declaration-data-citation-principles-final. Acessado via está de volta porque o DOI se refere a um conjunto de dados, e data de acesso + nome do portal para acesso web (por isso é uma citação híbrida). O número da versão é adicionado para explicar o uso do ano na citação. Observe a falta de colchetes e pontuação:

Smirnov I, Golikov A, Khalikov R (2017): coleções Ophiuroidea do Instituto Zoológico da Academia Russa de Ciências. Versão 1.25. Instituto Zoológico, Academia Russa de Ciências, São Petersburgo. Conjunto de dados de ocorrência http://doi.org/10.15468/ej3i4f , acessado via GBIF.org em 27/01/2017.

Espero que os papéis e sua ordem na citação gerada automaticamente e no cabeçalho da página do conjunto de dados sejam os mesmos: ORIGINATOR, METADATA AUTHOR,

Depois de corrigir a citação para os conjuntos de dados (última versão publicada + página do conjunto de dados), talvez seja necessário editar / adicionar seção aqui https://demo.gbif.org/citation-guidelines @kcopas

Precisamos dos dois pontos após os colchetes? Eu excluiria e simplesmente teria um espaço.

Smirnov I, Golikov A, Khalikov R (2017) coleções Ophiuroidea do Instituto Zoológico da Academia Russa de Ciências. Versão 1.25. Instituto Zoológico, Academia Russa de Ciências, São Petersburgo. Conjunto de dados de ocorrência http://doi.org/10.15468/ej3i4f , acessado via GBIF.org em 27/01/2017.

Também última parte, que tal simplesmente uma vírgula após GBIF.org: "GBIF.org, 2017-01-27"

@siro1 , eu continuaria "ligado". A citação híbrida de Thia tem tanto o ano de publicação da última versão (2017) quanto a data de acesso. Substituir "on" por vírgula pressupõe o conhecimento de qual data é o que, enquanto on faz uma declaração clara sobre o acesso.

Bem, ainda acho "on" supérfluo porque uma vez que você fala sobre a web e acessa segue que a data posterior a essa será a data de acesso. Um problema menor, mas pode economizar espaço e caracteres

Sugiro encerrar esta discussão aqui. Estamos entrando em detalhes realmente minúsculos agora. Ainda é possível que precisemos de algum tipo de mudança mais tarde, mas sinto que o espaço não é a maior economia que pode ser feita neste momento.

A resposta da API usará a citação gerada para substituir o "citation.text" atual:

"citation": {
  "text": "Creuwels J (2016). Naturalis Biodiversity Center (NL) - Hemiptera. Naturalis Biodiversity Center. Occurrence Dataset http://doi.org/10.5072/eu7dj2 accessed via GBIF.org on 2017-02-17."
}

Para o registro:
Isso agora está documentado no FAQ do GBIF.org.