Registry: Chaîne/objet de citation GBIF sur tous les ensembles de données

Créé le 11 janv. 2017  ·  24Commentaires  ·  Source: gbif/registry

Nous avons décidé d'utiliser la citation générée par le GBIF sur tous les ensembles de données. Étant donné que c'est ainsi qu'un ensemble de données doit être cité, je pense que ces informations doivent figurer dans la réponse de l'API. Je sais que @kbraak et @aahhn-gbif ont beaucoup parlé de ce format de citation - je vous inclue donc ici.

Tous les 24 commentaires

Nous en avons discuté un peu avec Andrea ce matin, je suis tout à fait favorable à une citation recommandée unique, c'est-à-dire une citation par défaut, qui serait assemblée à partir des métadonnées, en respectant les rôles, les ordres de noms, etc. Nous devons nous assurer que GBIF.org , peut-être la date de publication de la dernière version, et le DOI sont les parties de la citation qui ne peuvent pas être modifiées, à moins d'être republiées. Andrea mentionne un problème possible avec les éditeurs non-IPT, tels que les éditeurs ABCD et BioCASE.

Je continue de recommander que nous réutilisions le format de citation préféré de DataCite, qui satisfait à la Déclaration conjointe des principes de citation de données . C'est le format que l'IPT utilise pour générer automatiquement les citations. Vous trouverez plus d'informations sur ce format ici .

Je crois que tant que nous communiquons clairement comment nous dérivons notre citation d'EML, ABCD, etc., les éditeurs auront la possibilité d'adapter leurs métadonnées en conséquence, si cela leur importe.

@fmendezh Au cas où cela aiderait, c'est la méthode utilisée dans l'IPT pour générer automatiquement la citation de la ressource. Bien sûr, il utilise des objets de modèle spécifiques à IPT, mais heureusement, ils sont assez similaires à nos objets de modèle de registre.

@dschigel , vous avez déjà parlé des formats téléchargeables pour les logiciels de gestion des citations. Si c'est quelque chose que nous voulons vraiment faire à l'avenir, c'est votre chance de décrire les composants atomisés requis que l'API doit exposer pour que cela se produise.

Oui, voici ce que j'ai écrit le 23 septembre, toujours valable :

Salut Morten,

Vous avez posé des questions sur les formats bibliographiques vers lesquels nous pourrions exporter la citation recommandée par le GBIF (désolé que la citation elle-même n'ait pas obtenu sa forme définitive hier).

Voici ma suggestion :

Utilisez trois formats vers lesquels Mendeley exporte, voir l'image jointe
Le groupe Nature P utilise uniquement .ris.
De plus, nous aurons besoin du texte libre (mais quel système - pour vérifier avec les communications après avoir décidé ce qui se passe dans la citation GBIF - désolé pour le retard de notre côté, comme vous le savez probablement de la discussion avec Andrea, ce n'est pas une décision triviale) .

Ces trois formats d'exportation devraient être suffisants pour obtenir certaines fonctionnalités d'exportation de citations clés vers la boîte / popup HowToCite prévue, etc.
La citation elle-même prendra forme au fur et à mesure que nous progressons avec KC, KB et AH.
Si vous voulez en avoir plus, une autre image a les formats d'exportation utilisés par Science.

Vérifiez également les boutons CrossMark et Share dans PLOS One sur le côté droit de n'importe quel papier :
http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0159184
J'espère que Siro pourra également commenter cela.

Dmitri

Il peut être judicieux de fournir plusieurs formats sur le site Web, mais à de nombreuses fins, nous n'avons besoin que d'obéir à la norme. par exemple cité dans les téléchargements ou dans l'API. nous pourrions envisager de traiter un objet de référence complexe dans l'API au lieu d'une chaîne pour permettre divers formatages, mais bien atomiser les références de manière générique est un défi.

Commentaires opportuns de Rod gbif/portal-feedback#33 sur l'adoption de CiteProc

Il existe également une implémentation java et JavaScript :
https://michel-kraemer.github.io/citeproc-java/
https://github.com/juris-m/citeproc-js

Basé sur l'exemple pour Dataset du Joint Declaration of Data Citation Principles (https://www.force11.org/node/4771) et une version modifiée de la méthode IPT.

Pour l'ensemble de données 98333cb6-6c15-4add-aa0e-b322bf1500ba , nous générerions une citation par défaut comme :

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 : Cette approche a l'air bien. Je pense que le seul problème que cela causerait pour [les agrégateurs est qu'ils] apparaîtraient comme l'institution attribuée parce que cela provient de l'éditeur désigné, n'est-ce pas ? Dans ce cas, pourrions-nous/devrions-nous les encourager à inscrire chacune de leurs institutions contributrices, pour lesquelles nous pourrions peut-être aider avec une « approbation groupée » ?

Je remplacerais "Dataset/Occurrence" par "Occurrence dataset" plus lisible par l'homme, sans virgule.

Accessible via - est un peu redondant. Une fonction de plate-forme de publication de données, analogue à une maison d'édition, est probablement aussi importante que l'accès - notez que dans les références de livres, vous diriez simplement Taylor & Francis, et non "publié par". L'accès via sera balisé par la plupart des éditeurs de copie dans les revues.

La façon dont GBIF.org a mentionné doit-elle être la même pour les citations sur les pages des ensembles de données et sur les écrans de téléchargement et comment citer ?

Le problème avec l'exclusion de "accessible via" est que vous supprimez alors toute mention de GBIF dans la citation recommandée !

Non, je ne voulais pas supprimer GBIF.org - au contraire. Seuls les mots Accédé via sont un peu redondants - comme tout l'intérêt d'une citation pour indiquer "l'accès via". Je voulais dire:

GBIF.org, [date de la dernière version ou de la première publication]. Ensemble de données d'occurrence : http://doi.org/10.15468/ej3i4f

ou similaire

Après avoir compilé les commentaires, nous avons :

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 la date [2017-01-27] est la date d'accès, ça va ?

Pour moi cela semble bien. Cela éliminera les problèmes où les gens penseront que l'éditeur n'est pas l'institution appropriée pour obtenir le crédit principal dans la citation, mais cela peut alors inciter, par exemple, les réseaux à enregistrer leurs institutions fournisseurs séparément en tant qu'éditeurs de données.

Grâce à une discussion très utile avec @kbraak et @siro1 , et conformément aux recommandations DataCite https://schema.datacite.org/meta/kernel-3/doc/DataCite-MetadataKernel_v3.1.pdf (voir section 2.2), Je suggère que nous utilisions l'hybride suivant qui fonctionnerait à la fois pour la bibliographie et le monde des données. Voici l'exemple qui suivrait les principes de citation de données https://www.force11.org/group/joint-declaration-data-citation-principles-final. L'accès via est de retour car le DOI fait référence à un ensemble de données, et la date d'accès + le nom du portail à l'accès Web (c'est pourquoi il s'agit d'une citation hybride). Le numéro de version est ajouté pour expliquer l'utilisation de l'année dans la citation. Notez l'absence de parenthèses et de ponctuation :

Smirnov I, Golikov A, Khalikov R (2017): collections d'Ophiuroidea de l'Institut zoologique de l'Académie des sciences de Russie. Édition 1.25. Institut zoologique, Académie russe des sciences, Saint-Pétersbourg. Jeu de données d'occurrence http://doi.org/10.15468/ej3i4f , consulté via GBIF.org le 2017-01-27.

J'espère que les rôles et leur ordre dans la citation générée automatiquement et l'en-tête de la page de l'ensemble de données sont les mêmes : ORIGINATOR, METADATA AUTHOR,

Une fois que nous aurons corrigé la citation pour les ensembles de données (dernière version telle que publiée + page de l'ensemble de données), nous devrons peut-être modifier / ajouter une section ici https://demo.gbif.org/citation-guidelines @kcopas

Avons-nous besoin du côlon après les crochets ? J'exclurais et j'aurais simplement un espace.

Smirnov I, Golikov A, Khalikov R (2017) Collections d'Ophiuroidea de l'Institut zoologique de l'Académie des sciences de Russie. Édition 1.25. Institut zoologique, Académie russe des sciences, Saint-Pétersbourg. Jeu de données d'occurrence http://doi.org/10.15468/ej3i4f , consulté via GBIF.org le 2017-01-27.

Aussi, dernière partie, que diriez-vous simplement d'une virgule après GBIF.org : "GBIF.org, 2017-01-27"

@siro1 , je continuerais "on". Cette citation hybride a à la fois l'année de publication de la dernière version (2017) et la date d'accès. Remplacer "le" par une virgule suppose que l'on sache quelle date correspond à quoi, tandis que le fait est une déclaration claire sur l'accès.

Eh bien, je trouve toujours "le" superflu car une fois que vous parlez du Web et de l'accès, il s'ensuit que la date d'après sera la date d'accès. Un problème mineur mais peut économiser de l'espace et des caractères

Je suggère de fermer cette discussion ici. Nous allons maintenant dans de très petits détails. Il est toujours possible que nous ayons besoin d'une sorte de changement plus tard, mais je pense que l'espace n'est pas la plus grande économie qui puisse être réalisée à ce stade.

La réponse de l'API utilisera la citation générée pour remplacer le "citation.text" actuel :

"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."
}

Pour mémoire :
Ceci est maintenant documenté sur la FAQ de GBIF.org .

Cette page vous a été utile?
0 / 5 - 0 notes