Zenodo: [Funktionsanfrage] Option "In Binder öffnen" für entsprechende GitHub-Repositorys

Das wäre generell sehr cool.

Ich wäre noch mehr an (2) interessiert, damit Binder Zenodo-DOIs auflösen und direkt von diesen anstelle von Git-Repositorys starten kann. Die meiste Arbeit (auf der Binderseite) würde wahrscheinlich in repo2docker liegen, dem Werkzeug, mit dem wir die Container tatsächlich erstellen. Im Moment verwendet es git zum Abrufen von Inhalten oder verwendet ein lokales Verzeichnis.

In https://github.com/jupyterhub/binderhub/issues/216 haben wir diese Idee ein wenig für den Start von OSF.io diskutiert

Tims Kommentar unterstützen - lassen Sie das Binder-Team wissen, ob wir etwas tun können, um Ihnen zu helfen!

Ich denke, dies hängt mit der WIP-Funktion der Vorschau von .tar.gz und anderen komprimierten Formaten zusammen: https://github.com/zenodo/zenodo/issues/557.

Zugegeben, es wäre ein sehr cooles Feature. Technisch sieht es so aus, als ob Binder Repo2Docker verwendet, das, soweit ich das beurteilen kann, ein Git-Repository benötigt, um zu funktionieren. Dies ist meiner Meinung nach das Haupthindernis, da Zenodo nur einen Zip-Ball der jeweiligen Version archiviert. Die Problemumgehung wäre, einfach auf das GitHub-Repository zu verweisen (weil wir den SHA der archivierten Version haben), aber dann umgehen wir im Wesentlichen Zenodo, und es gibt keinen wirklichen Mehrwert, nur das Abzeichen im GitHub-Repository zu haben .

Vielen Dank, dass Sie sich zu diesem Thema an uns gemeldet haben, @lnielsen! Einige Gedanken:

Die Problemumgehung wäre, einfach auf das GitHub-Repository zu verweisen (da wir den SHA der archivierten Version haben) […]

Anstatt direkt auf das GitHub-Repository zu verweisen, wäre es sinnvoll, ein "Binder"-Badge auf Zenodo zu haben, das auf das spezifische Commit/Tag verweist, das auf Zenodo archiviert wurde (da Binder Branches, Tags oder Commits verarbeiten kann). Dies bedeutet, dass Sie direkt zu derselben Version des Codes/Repos springen können, die vom DOI verlinkt ist.

[…] dann umgehen wir im Wesentlichen Zenodo, und es gibt keinen wirklichen Mehrwert, nur das Abzeichen im GitHub-Repository zu haben.

Nun, wenn Sie auf das spezifische Commit/Tag zeigen, gibt es immer noch einen Wert, da die Abzeichen in GitHub normalerweise auf den neuesten Commit in master . Unter dem Punkt „Erhaltung“ und „Persistenz“, die ein DOI bieten soll, wäre es jedoch sinnvoll, wenn wir GitHub tatsächlich umgehen und das Repo direkt aus Zenodo rendern könnten, sodass der Inhalt immer noch „interaktiv“ ist, auch wenn das ursprüngliche GitHub-Repository wird entfernt.

@choldgraf , @betatim : Gibt es eine Möglichkeit, ein Git-Repo aus dem Zip-Ball zu "fälschen"? Durch das Hinzufügen eines im Wesentlichen zwecklosen* git init irgendeiner Art in den repo2docker Workflow? So:

• repo2docker entpackt Zip-Ball → repo2docker läuft git init → Binder zeigt auf Inhalt/Notebook(s).

• bearbeiten

@choldgraf , @betatim : Gibt es eine Möglichkeit, ein Git-Repo aus dem Zip-Ball zu "fälschen"? Durch das Hinzufügen einer im Wesentlichen git init irgendeiner Art im repo2docker-Workflow?

das ist eine großartige Frage - ich denke, dies wäre machbar, wahrscheinlich als Buildpack für repo2docker (das könnte entweder in r2d erfolgen oder als "Erweiterung", die in einem separaten Repository lebt). Dieses Buildpack würde die Zeilen in eine Dockerdatei einfügen, die das Entpacken usw.

Ich habe gerade dieses Thema geöffnet, um es in r2d zu diskutieren: https://github.com/jupyter/repo2docker/issues/234

Das wäre toll!

Ich denke, dafür gibt es zwei Teile:

1. Hinzufügen der Möglichkeit zum Lesen aus einer ZIP-Datei unter einer bestimmten URL zu repo2docker
2. Hinzufügen der Möglichkeit zum Lesen eines versionierten Zonodo-Identifikators zur entsprechenden ZIP-Datei + Caching-Semantik zu binderhub.

In der Zwischenzeit denke ich, dass es am einfachsten ist, einen Link zur getaggten Version auf github hinzuzufügen!

Hallo @yuvipanda. Im Moment ja, nach einem Binder-Badge zu suchen und dann auf GitHub auf die entsprechende Version zu verlinken, ist eine Zwischenlösung – je nachdem, wie @lnielsen und Co. priorisieren Sie das natürlich! :)

Betreffend:

2. Hinzufügen der Möglichkeit zum Lesen eines versionierten Zonodo [sic]-Identifikators zur entsprechenden ZIP-Datei + Caching-Semantik zu binderhub.

Zenodo greift nur dann zu Repos, wenn eine neue Version herausgegeben wird und ich denke, dass das GitHub-Badge auf dem Zenodo-Eintrag selbst auf das entsprechende tree auf GitHub verweist. Hilft das überhaupt?

Das Abzeichen wäre ziemlich einfach hinzuzufügen, wenn wir bereits wissen, dass das Github-Repository Binder unterstützt, aber es ist nicht einfach für uns zu erkennen, ob Binder unterstützt wird. Was wir tun könnten, ist das Hinzufügen von Links im Feld "Zugehörige Kennungen", die dann ein Logo wie github rendern, mit dem Sie es im Binder starten können.

@lnielsen ein paar Gedanken, die mir in den Sinn kommen:

1. Überprüfen Sie, ob ein Repository ein Binder-Badge in seiner README-Datei enthält
2. Überprüfen Sie, ob ein Repo ein Tag enthält (zB "binder-ready", "binder")
3. Überprüfen Sie, ob ein Repository eine oder mehrere der Konfigurationsdateien enthält, und versuchen Sie, es über die Binder-Build-API zu erstellen. Wenn es als erfolgreich zurückgegeben wird, fahren Sie fort.

Spucke einfach hier :-)

Ich denke, es ist für einen Computer sehr schwierig zu wissen, ob ein Repository etwas Nützliches tut, wenn Sie es auf einem BinderHub starten. viele Repositorys werden erstellt und gestartet, aber die meisten funktionieren nicht :-( Ich würde also in der README nach dem Binder-Abzeichen suchen, aber das ist auch eine grobe Heuristik (wie würde man (in großem Maßstab) Repositorys finden, die einen Binder haben? Badge, das auf eine andere Instanz als mybinder.org verweist?) -> Das menschliche Opt-in für den 'binder-ready'-Status ist wahrscheinlich das Beste und kann dann auch maschinenlesbar sein.

Gibt es ein Format/eine Datei, die zenodo untersucht, um zusätzliche Informationen für ein Repository zu extrahieren? Ähnlich einem .travis.yml oder so ähnlich?

Ich habe versucht, das Parsen der Dateien im Repository zu vermeiden :-)

Ich würde sagen, der beste Weg wäre irgendwie über CodeMeta - https://codemeta.github.io, da wir planen, das Lesen von Metadaten aus der Codemeta-Datei zu ermöglichen.

BinderHub und repo2docker unterstützen jetzt das Starten von Zenodo DOIs: https://twitter.com/mybinderteam/status/1139136841792315392

Wie in https://github.com/zenodo/zenodo/issues/1416#issuecomment -398732740 erwähnt, denke ich, dass eine vernünftige Lösung darin besteht, ein Binder-Logo mit dem richtigen mybinder-Link (ähnlich dem GitHub-Link) anzuzeigen, wenn es vorhanden ist ist ein Link zu https://mybinder.org in den "related Identifiers" (Beispieldatensatz: https://zenodo.org/record/3402938)

Meine einzige Sorge, und wahrscheinlich die des Binder-Teams (cc @betatim , @yuvipanda , @choldgraf), besteht darin, den MyBinder-Dienst viel stärker bekannt zu machen und ihn zu doSieren, was dazu führen würde, dass Benutzer einem Link zu einem "kaputten" " Seite. Stellen Sie sich vor, dass Benutzer, die auf einem Zenodo-Softwaredatensatz mit einem Binder-Logo landen, einfach aus Neugier darauf klicken.

Ich habe die Zuverlässigkeitsdokumentation gelesen und die vorhandenen Ratenbegrenzungsmechanismen sehen gut aus, also ist es wohl nur eine Frage, ob die MyBinder-Dienstbetreuer damit einverstanden sind :)

Als allgemeine Regel gilt, dass Traffic-Spitzen keine allzu große Sache sein sollten, solange es sich nicht um gigantische Spitzen handelt. Welche Art von Verkehr stellen Sie sich vor, zu senden? :-)

Als Referenz können Sie sich hier eine Vorstellung von der Auslastung und "Spikiness" von Repositorys für das öffentliche Binderhub-Deployment (das auf mybinder.org) machen:

https://grafana.mybinder.org/d/fZWsQmnmz/pod-activity?refresh=1m&orgId=1&var-cluster=default
Wir hatten Leute, die ~100-200 Binder auf einmal gestartet haben, als sie ihn zum Unterrichten von Kursen und dergleichen verwendet haben. Manchmal dauert der Start länger, wenn wir auf einen neuen Knoten skalieren müssen, aber im Allgemeinen sollte es in Ordnung sein.

Die harte Grenze beträgt 100 gleichzeitige Sitzungen für ein einzelnes Repository.

... wenn in den "related Identifiers" ein Link auf https://mybinder.org vorhanden ist (Beispieldatensatz: https://zenodo.org/record/3402938)

Wäre es als verwandtes Problem möglich, spezifischere Metadaten in den "related Identifiers" für diesen Anwendungsfall zu haben? Die mit dieser URL verknüpften Metadatenwerte im Abschnitt "Verwandte/alternative Bezeichner" sind ziemlich informativ ("Ergänzendes Material" und "Sonstiges"). Wäre es möglich, neue Metadatenwerte wie "Führt diesen Upload aus" und "Live-Computing-Umgebung" hinzuzufügen, um deutlich zu machen, dass der Link dem Leser ermöglicht, die Software auszuführen? Ich denke, dies wird ein relativ häufiger Anwendungsfall werden. Vielen Dank

:+1: für den Beziehungstyp. Mein Vorschlag wäre "Interaktive (Computing-)Umgebung", da Binder für Menschen verwendet werden sollen, und keine einmalige Ausführung (was "Führt diesen Upload aus" bedeuten könnte).

Das verfügbare Beziehungstyp-Vokabular für die zugehörigen Bezeichner basiert auf dem DataCite v4.1-Schema , daher würde ich vermeiden, einen neuen "benutzerdefinierten" Beziehungstyp hinzuzufügen.

IMHO, der am besten geeignete Beziehungstyp wäre isSourceOf (dh "hat diesen Upload als Quelle" im Upload-Formular), in dem Sinne, dass der Zenodo-Datensatz die Quelle ist, die Binder verwendet, um ihn auszuführen:

Wenn wir uns darüber einig sind, können wir dies meiner Meinung nach in der nächsten Version veröffentlichen :)

PS (@choldgraf): Die heutige dumme Frage: Ist es urheberrechtlich in Ordnung, wenn wir das Binder-Logo aus Ihrem Repo verwenden ?

@slint ja, Sie können das Logo verwenden. Ohne uns etwas zu tun Extra ist es lizenziert wie diese . Was wahrscheinlich nicht ideal für Kunstwerke ist.

Wenn Sie einen "Button" für die Leute zum Drücken erstellen möchten, gibt es auch

@slint Ich hatte nicht

Ich stimme zu, dass von den verfügbaren Beziehungstypen isSourceOf am besten geeignet ist und ich habe meinen Zenodo-Datensatz aktualisiert, der als Beispiel verwendet wird.

Basiert das Ressourcentypfeld auf resourceTypeGeneral in DataCite 4.1 (Tabelle 7)? Wenn dies der Fall ist, scheint mir der Wert interactiveResource ("Eine Ressource, die eine Interaktion des Benutzers erfordert, um verstanden, ausgeführt oder erfahren zu werden"), der am besten geeignete Wert zu sein. Leider ist dies nicht in der Dropdown-Liste verfügbar, daher habe ich mich für "Sonstiges" entschieden.