DOIs for Research Software: Increasing Visibility, Connectivity, Citability
Formale Metadaten
Titel |
| |
Autor | ||
Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
Identifikatoren | 10.5446/69879 (DOI) | |
Herausgeber | ||
Erscheinungsjahr | ||
Sprache |
Inhaltliche Metadaten
Fachgebiet | ||
Genre | ||
Abstract |
|
00:00
Fächer <Mathematik>Zusammenhängender GraphSoftwareEinfach zusammenhängender RaumMultiplikationsoperatorDigital Object IdentifierCoxeter-GruppeSoftwareWeb SiteWort <Informatik>Stabilitätstheorie <Logik>Endliche ModelltheorieRechenschieberTouchscreenXMLUMLComputeranimationBesprechung/Interview
01:16
SoftwareQuellcodeProgrammbibliothekFunktion <Mathematik>FontForschungszentrum RossendorfProjektive EbeneSoftwareMetadatenKlasse <Mathematik>SpeicherabzugSoftware EngineeringInnerer PunktFunktion <Mathematik>Nationale Forschungseinrichtung für Informatik und AutomatikOffene MengeMultiplikationsoperatorPackprogrammCASE <Informatik>GeradeComputeranimation
02:43
SoftwareOpen SourceOffene MengeGruppenkeimPeer-to-Peer-NetzKontextbezogenes SystemAlgorithmusQuellcodeDigitalsignalBeschreibungskomplexitätSoftwareentwicklerGeradeCodeSoftwareOffene MengeObjekt <Kategorie>Natürliche ZahlDifferenteLuenberger-BeobachterUmwandlungsenthalpieProjektive EbeneGebäude <Mathematik>DigitalisierungOpen SourceDatenverarbeitungssystemQuellcodeProdukt <Mathematik>MAPMathematische LogikKomplex <Algebra>SchlüsselverwaltungBenutzerbeteiligungMereologieComputeranimation
05:34
Funktion <Mathematik>AssemblerProgrammSoftwareKoroutineCodeTabelleEigentliche AbbildungDrucksondierungAutomatische IndexierungModallogikKonstanteTVD-VerfahrenQuick-SortMengeOffene MengeDokumentenserverVersionsverwaltungOpen SourceProzess <Informatik>Elektronisches ForumVirtuelle MaschineSichtenkonzeptQuellcodeSoftwareCodeProgrammSoftwareentwicklerOffene MengeProzess <Informatik>UmwandlungsenthalpieMAPGrenzschichtablösungRechenschieberIdentifizierbarkeitFunktion <Mathematik>ResultanteMultiplikationsoperatorDifferenteObjekt <Kategorie>DokumentenserverDigital Object IdentifierGruppenoperationComputeranimation
07:46
BenutzeroberflächeStrategisches SpielMathematikSoftwareFunktion <Mathematik>Web logWeb-SeiteOffene MengeMeta-TagCodeSelbst organisierendes SystemMetrisches SystemProgrammverifikationMetadatenWeg <Topologie>LeistungsbewertungQuellcodeInformationsspeicherungSoftwareFunktion <Mathematik>MinimumSelbst organisierendes SystemPunktwolkeQuellcodeWeb SiteImplementierungMereologieOffene MengeKlasse <Mathematik>ForcingProjektive EbeneVerkehrsinformationCodeMultiplikationsoperatorSystemaufrufOpen SourceMeta-TagThermische ZustandsgleichungBitResultanteRechenschieberPackprogrammEinsProdukt <Mathematik>CASE <Informatik>MetadatenDateiformatWeb-SeiteAutomatische HandlungsplanungNormalvektorElektronische PublikationComputeranimation
12:05
SoftwareOpen SourceGruppenkeimArchitektur <Informatik>VideokonferenzOffice-PaketWeb-SeiteProgrammbibliothekQuellcodeHilfesystemCodeSystemplattformUmwandlungsenthalpieHauptidealringAlgorithmusURLInhalt <Mathematik>InformationSharewareCliquenweiteBenchmarkInklusion <Mathematik>Objekt <Kategorie>VersionsverwaltungVerzeichnisdienstStrom <Mathematik>AdressraumBrowserNummernsystemDatensichtgerätStandardabweichungWeb logElektronischer FingerabdruckKonfigurationsdatenbankHash-AlgorithmusElektronische PublikationSystemidentifikationNotepad-ComputerHomepageModul <Datentyp>VerschlingungSukzessive ÜberrelaxationRechenwerkMAPGasströmungMetadatenBimodulProdukt <Mathematik>IndexberechnungGeradeBildverarbeitungPatch <Software>SpezialrechnerSolitärspielOktaederDigital Object IdentifierAbstraktionsebeneRIS <Medizin, Informationssystem>Framework <Informatik>Prozess <Informatik>MaßerweiterungDatenverarbeitungssystemYouTubeSoftwareQuellcodeDifferentePackprogrammVerkehrsinformationGrundraumSystemverwaltungDokumentenserverProjektive EbeneBildverarbeitungAutorisierungIdentifizierbarkeitCASE <Informatik>TexteditorDigital Object IdentifierInteraktives FernsehenWort <Informatik>CodeYouTubeMechanismus-Design-TheorieDiagrammAttributierte GrammatikDatensatzOpen SourceSoftwareentwicklerTypentheorieMetadatenURLRechenschieberKontextbezogenes SystemHash-AlgorithmusVerzeichnisdienstMereologieMAPAlgorithmusSharewareVersionsverwaltungMaßerweiterungSystemplattformAutomatische IndexierungUmwandlungsenthalpiePhysikalische SchichtSuite <Programmpaket>Modulare ProgrammierungMaschinenschreibenExpertensystemVirtuelle MaschineElektronischer FingerabdruckXMLComputeranimationDiagramm
18:26
RechenschieberOpen SourceWikiElektronische PublikationTextur-MappingSpeicherabzugNummernsystemDigitalsignalMetadatenSoftwareLinked DataDigital Rights ManagementWeb-SeiteCodeVollständiger VerbandKontextbezogenes SystemGeradeVersionsverwaltungMetadatenDatensatzCodeProjektive EbeneSoftwareBildgebendes VerfahrenMaschinenschreibenIdentifizierbarkeitKonfigurationsdatenbankRechenschieberWort <Informatik>ZustandsmaschineMeta-TagCoxeter-GruppeFunktion <Mathematik>TabelleVersionsverwaltungTeilmengeBenutzerbeteiligungFormale SemantikMapping <Computergraphik>DifferenteMereologiePackprogrammUmsetzung <Informatik>Klasse <Mathematik>Motion CapturingKoordinatenProgramm/QuellcodeComputeranimation
21:05
ProgrammbibliothekGoogolCoxeter-GruppeFensterfunktionSichtenkonzeptSoftwareRechenschieberMaßerweiterungDateiformatElektronische PublikationDrucksondierungZusammenhängender GraphSystemidentifikationDokumentenserverElement <Gruppentheorie>Selbst organisierendes SystemEinfach zusammenhängender RaumRelation <Informatik>TypentheorieZahlenbereichKnotenmengeMetadatenHauptidealringGraphFormale SpracheVersionsverwaltungMailing-ListeSkriptspracheGerichtete MengeProzess <Informatik>Ein-AusgabeOpen SourceRuhmasseOrbit <Mathematik>KonfigurationsdatenbankSpezialrechnerObjekt <Kategorie>Coxeter-GruppeTouchscreenGemeinsamer SpeicherDigital Object IdentifierRelativitätstheorieTypentheorieCodeDifferenteInstantiierungVersionsverwaltungOpen SourcePlug inKategorie <Mathematik>InformationSystemplattformSoftwareMetadatenDatenmodellDialektProjektive EbeneSelbst organisierendes SystemWeb SiteDigital Rights ManagementDokumentenserverKonfigurationsdatenbankStatistikHydrostatikProzess <Informatik>ProgrammKlasse <Mathematik>Funktion <Mathematik>GeradeBitStrömungsrichtungMereologieFreewareKonfiguration <Informatik>EDV-BeratungWhiteboardMustererkennungWiderspruchsfreiheitElement <Gruppentheorie>Einfach zusammenhängender RaumMeta-TagElektronische PublikationVollständiger VerbandComputervirusMengeGruppenoperationDatenflussStellenringVideokonferenzObjekt <Kategorie>HilfesystemQuellcodeMAPVorzeichen <Mathematik>Notebook-ComputerAnalysisIdentifizierbarkeitVollständigkeitVerschlingungRechenschieberMailing-ListeZeiger <Informatik>CASE <Informatik>Registrierung <Bildverarbeitung>BeweistheorieImplementierungSchaltnetzAbgeschlossene MengeAutorisierungOrdnung <Mathematik>StandardabweichungSystemidentifikationMaßerweiterungPunktVerkehrsinformationGraphBildgebendes VerfahrenMomentenproblemStrategisches SpielDeskriptive StatistikEinsPhysikalismusRFIDBesprechung/InterviewComputeranimationXMLUML
28:42
TypentheorieSoftwareKonfigurationsdatenbankSpezialrechnerObjekt <Kategorie>ZeitabhängigkeitRegistrierung <Bildverarbeitung>SkriptspracheEinfache GenauigkeitFehlermeldungBinomialbaumVerteilungsfunktionInhalt <Mathematik>Umsetzung <Informatik>BitrateSchätzungLambda-KalkülStatistikAdditionKontrollstrukturMAPZählenSatellitensystemSpeicherabzugKomponente <Software>MetadatenSoftwareEinsSystemaufrufSelbst organisierendes SystemSchaltnetzMereologiePlug inPersönliche IdentifikationsnummerDeskriptive StatistikRechter WinkelBestimmtheitsmaßMathematikWeb SiteAbgeschlossene MengeRegistrierung <Bildverarbeitung>CASE <Informatik>Prozess <Informatik>Arithmetische FolgeElektronische PublikationProjektive EbeneIdentifizierbarkeitMultiplikationsoperatorOrdnung <Mathematik>EindringerkennungKonfigurationsraumSharewareMustererkennungSkeleton <Programmierung>PunktKategorie <Mathematik>GruppenoperationGeradeDifferenteAutorisierungVerzweigendes ProgrammInformationDatensatzBitBeweistheorieSystemplattformEvoluteDatenfeldAudiovisualisierungZweiRelativitätstheorieSoftwareentwicklerSuite <Programmpaket>VideokonferenzArithmetisches MittelEinfach zusammenhängender RaumDateiformatFunktion <Mathematik>DokumentenserverOpen SourceTypentheorieCodeKonfigurationsdatenbankThermische ZustandsgleichungResultanteDigital Object IdentifierElektronischer ProgrammführerRechenschieberHeegaard-ZerlegungVerschlingungStetige FunktionBenutzeroberflächeKontinuierliche IntegrationTermSpeicherabzugFensterfunktionZehnVersionsverwaltungInklusion <Mathematik>Kollaboration <Informatik>Mailing-ListeCoxeter-GruppeComputeranimation
35:54
ZählenSpeicherabzugKomponente <Software>EinflussgrößeFensterfunktionSichtenkonzeptMailing-ListeAggregatzustandZoomTabelleSoftwareSchreib-Lese-KopfOffene MengeDokumentenserverTetraederWort <Informatik>Coxeter-GruppeGruppenoperationElektronische PublikationVererbungshierarchieDatensatzVersionsverwaltungTouchscreenQuellcodeInformationZweiMetadatenAutorisierungCASE <Informatik>Kontinuierliche IntegrationOpen SourceKonfigurationsraumRechter WinkelDifferenteWellenpaketBildschirmmaskeMAPSoftwareSoftwareentwicklerOrdnung <Mathematik>RechenwerkImplementierungSpeicherabzugProjektive EbeneMultiplikationsoperatorRechenschieberMereologiePhysikalisches SystemÄhnlichkeitsgeometrieBeweistheorieResultanteDokumentenserverExogene VariableLesen <Datenverarbeitung>AnalogieschlussMaterialisation <Physik>SoftwaretestTemplateEinsGanze FunktionComputeranimationBesprechung/InterviewVorlesung/KonferenzXML
37:55
SoftwareDokumentenserverDienst <Informatik>SoftwareentwicklerVerdünnung <Bildverarbeitung>InformationQuellcodeProgrammbibliothekDreieckSchreiben <Datenverarbeitung>SoftwareAutorisierungSelbst organisierendes SystemPlug inDokumentenserverPhysikalisches SystemRechter WinkelSoftwareentwicklerDreieckWeb SiteDigital Rights ManagementProzess <Informatik>TouchscreenMultiplikationsoperatorBitCoxeter-GruppeProgrammbibliothekPerspektiveGarbentheorieQuick-SortTypentheorieInformationVersionsverwaltungGanze FunktionOpen SourceQuellcodeTrennschärfe <Statistik>Kollaboration <Informatik>Verdünnung <Bildverarbeitung>EindringerkennungIdentifizierbarkeitEinfache GenauigkeitRohdatenZeichenketteDatensatzURLMetadatenMereologieEinfügungsdämpfungComputeranimationDiagramm
40:03
InformationSoftwarePhysikalisches SystemSystemplattformDigital Object IdentifierDichte <Stochastik>Produkt <Mathematik>Inklusion <Mathematik>Produkt <Mathematik>Quick-SortRechenschieberSoftwareCodierungBitDifferentePhysikalisches SystemRechter WinkelDigital Rights ManagementMetadatenZeichenketteOffene MengeAutomatische HandlungsplanungDeskriptive StatistikSystemplattformEinfach zusammenhängender RaumDatensatzVirtuelle MaschineAutorensystemInformationMathematikComputeranimation
41:46
DokumentenserverSoftwareDienst <Informatik>SoftwareentwicklerInformationVerschlingungAttributierte GrammatikStellenringWeg <Topologie>VisualisierungStatistikProgrammbibliothekInterface <Schaltung>Dienst <Informatik>MetadatenTermStatistikMultiplikationPhysikalisches SystemFlächeninhaltVisualisierungProgrammbibliothekVerschlingungZählenWeg <Topologie>DatenbankDatensatzIdentifizierbarkeitDifferentePunktspektrumTeilmengeSoftwareZeitzoneProgrammRechter WinkelWeb SiteSystemplattformInstantiierungKonfigurationsdatenbankTypentheoriePackprogrammGüte der AnpassungDigital Rights ManagementOrdnung <Mathematik>UmwandlungsenthalpieInformationOpen SourceDigital Object IdentifierVersionsverwaltungCASE <Informatik>HilfesystemFormale SpracheComputeranimationDiagramm
43:31
DokumentenserverSoftwareDienst <Informatik>SoftwareentwicklerPhysikalisches SystemBimodulVersionsverwaltungDigital Object IdentifierPersistent identifierGasströmungOpen SourceSoftwaretestStreuungPlot <Graphische Darstellung>Offene MengeCodeVerdünnung <Bildverarbeitung>SoftwareDynamisches SystemURLCASE <Informatik>Digital Rights ManagementFunktion <Mathematik>IdentifizierbarkeitGüte der AnpassungWiederherstellung <Informatik>TermMereologieOrdnung <Mathematik>CodeKollaboration <Informatik>SystemplattformKlasse <Mathematik>HilfesystemKontextbezogenes SystemBitMultiplikationsoperatorSprachsynthesePerspektiveRechter WinkelPackprogrammSoftwareentwicklerVerschlingungProdukt <Mathematik>ZählenDigital Object IdentifierComputeranimationDiagramm
45:25
SoftwareDienst <Informatik>SoftwareentwicklerDokumentenserverSchreiben <Datenverarbeitung>DatenflussMetadatenFunktion <Mathematik>EinfügungsdämpfungMengeIdentifizierbarkeitInformationDifferenteSoftwarePhysikalisches SystemVerschlingungDokumentenserverPunktSoftwareentwicklerRechter WinkelGemeinsamer SpeicherChatten <Kommunikation>QuaderCoxeter-GruppeModulare ProgrammierungService providerIntegralOffene MengeTypentheorieAutorisierungFokalpunktOpen SourceKette <Mathematik>Ganze FunktionPackprogrammInstantiierungResultanteZahlenbereichVideokonferenzComputeranimationDiagramm
47:11
GruppenoperationComputersicherheitCodeSichtenkonzeptDokumentenserverSmith-DiagrammSoftwarePASS <Programm>Patch <Software>Serviceorientierte ArchitekturFormation <Mathematik>CachingGewicht <Ausgleichsrechnung>HorizontaleExzentrizitätBinärdatenSystemidentifikationFrequenzVariablePrognoseverfahrenSatellitensystemMultiplikationRandwertUnordnungKompakter RaumVirtuelle MaschineNichtlineares GleichungssystemAggregatzustandNebenbedingungDichte <Physik>Digital Object IdentifierVersionsverwaltungWeb-SeiteMetadatenAlgorithmusSoftwareSystemplattformDokumentenserverOffene MengeMAPVerschlingungVersionsverwaltungInformationPhysikalisches SystemDifferenteObjekt <Kategorie>InstantiierungMereologieIdentifizierbarkeitRFIDElektronische PublikationQuellcodeCASE <Informatik>IterationSchwebungAutorisierungOrdnung <Mathematik>PackprogrammSoftwaretestIntegralMultiplikationsoperatorIndexberechnungSoftware EngineeringProzess <Informatik>Repository <Informatik>CodeGemeinsamer SpeicherMultiplikationMeta-TagComputeranimation
49:21
SoftwareSoftwareentwicklerCodeOpen SourceSchreiben <Datenverarbeitung>DokumentenserverSpeicherabzugObjekt <Kategorie>Wort <Informatik>Projektive EbeneThermische ZustandsgleichungSoftwareDesktop-PublishingMetadatenRechenzentrumGarbentheorieWeb SiteMathematikPunktRechenschieberInformationDigital Object IdentifierOffene MengeSichtenkonzeptDokumentenserverVerschlingungRegistrierung <Bildverarbeitung>Coxeter-GruppeElektronische PublikationTermIntegralMultiplikationsoperatorProgrammSystemplattformE-MailSharewareGemeinsamer SpeicherDatensatzQuellcodeComputeranimationVorlesung/KonferenzBesprechung/Interview
51:24
SoftwareMetadatenEinfügungsdämpfungSharewareMultiplikationsoperatorRechter WinkelSoftwareImplementierungGemeinsamer SpeicherAutomatische HandlungsplanungBeweistheorieKontextbezogenes SystemDigital Object IdentifierMailing-ListeArithmetisches MittelPackprogrammAutorisierungSchlüsselverwaltungIndexberechnungMetadatenDesktop-PublishingVersionsverwaltungIdentifizierbarkeitComputeranimation
53:59
SpeicherabzugGewicht <Ausgleichsrechnung>OrdinalzahlMulti-Tier-ArchitekturKugelkappeMetadatenSoftwareVersionsverwaltungSchriftzeichenerkennungDokumentenserverPersistent identifierDigital Object IdentifierSystemplattformQuellcodeSoftwareVersionsverwaltungMetadatenOpen SourceKontextbezogenes SystemSystemplattformProjektive EbeneDokumentenserverCASE <Informatik>MomentenproblemIntegralGüte der AnpassungProzess <Informatik>TeilbarkeitTermUmwandlungsenthalpieOrdnung <Mathematik>IdentifizierbarkeitBitFunktion <Mathematik>SpeicherabzugSoftware EngineeringQuick-SortCodeQuellcodeÜberlagerung <Mathematik>Computeranimation
56:59
Algebraisches ModellSoftwareOpen SourceDämpfungMetadatenElektronische PublikationDateiformatStetige FunktionVersionsverwaltungDigital Object IdentifierEreignishorizontMessage-PassingQuellcodeDokumentenserverSystemplattformSoftwareProzessautomationMetadatenInternetworkingBildschirmmaskeDateiformatIntegralMultiplikationsoperatorElektronische PublikationTypentheorieProjektive EbeneStichprobenfehlerKartesische KoordinatenDifferenteDokumentenserverProzess <Informatik>InformationVersionsverwaltungSystemplattformOpen SourceMeta-TagCodeQuellcodeKontinuierliche IntegrationSoftware EngineeringE-MailZeichenketteDeskriptive StatistikUmwandlungsenthalpieGeradeInstantiierungCASE <Informatik>RechenschieberVerschlingungHydrostatikAnalysisDigital Rights ManagementVorzeichen <Mathematik>SchaltnetzPatch <Software>FreewareComputeranimation
01:02:15
SoftwareMetadatenImplementierungElektronische PublikationMAPOrdnung <Mathematik>BitVersionsverwaltungDatenmodellDifferenteAutorisierungKonfigurationsraumMetadatenImplementierungProzess <Informatik>BeweistheorieDokumentenserverOpen SourceVerkehrsinformationMengePunktCodeEinsMeta-TagStrategisches SpielPlug inMomentenproblemFlussdiagramm
01:04:58
SoftwareMetadatenBeweistheorieGruppenoperationSystemplattformKollaboration <Informatik>SummierbarkeitSchätzungPOKETrigonometrische FunktionEnergieerhaltungProzess <Informatik>KonfigurationsraumProzessautomationSharewareArchitektur <Informatik>EntscheidungstheorieWeb SiteSoftwareentwicklerDatenmodellVerzeichnisdienstCachingDokumentenserverToken-RingInhalt <Mathematik>DatenmissbrauchComputersicherheitTermZusammenhängender GraphWikiCodeElektronischer FingerabdruckGeradeTextur-MappingRückkopplungAffine AbbildungVersionsverwaltungMessage-PassingElektronische PublikationSchaltnetzMereologieEinsProjektive EbeneBeweistheorieMetadatenElektronische PublikationMathematikRechter WinkelFensterfunktionBestimmtheitsmaßSharewarePunktSoftwareVerschlingungKonfigurationsraumDokumentenserverMultiplikationsoperatorVerzweigendes ProgrammDigital Object IdentifierVersionsverwaltungSystemplattformComputeranimation
01:08:29
WikiComputersicherheitGeradeCodeSoftwareDokumentenserverZusammenhängender GraphSharewareGruppenoperationTopologieTemplateVerzeichnisdienstEreignishorizontTypentheorieVerzweigendes ProgrammDigitalfilterDigital Rights ManagementCachingProzess <Informatik>Umsetzung <Informatik>MetadatenOffene MengeElektronische PublikationE-MailMeta-TagMinkowski-MetrikSchreiben <Datenverarbeitung>BeweistheorieVerzweigendes ProgrammGruppenoperationDokumentenserverKontinuierliche IntegrationOpen SourceElektronische PublikationMetadatenCodeMeta-TagMultiplikationsoperatorHinterlegungsverfahren <Kryptologie>DifferenteZweiSoftwareComputeranimation
01:10:45
MeterVerzweigendes ProgrammMetadatenSharewareGruppenoperationSoftwareMeta-TagSmileyToken-RingKontinuierliche IntegrationSoftwareentwicklerGruppenoperationResultanteTermPerfekte GruppeDatensatzProgramm/Quellcode
01:12:13
Digital Object IdentifierAutomatische IndexierungSoftwareDokumentenserverZehnSharewareSichtenkonzeptZusammenhängender GraphMetadatenElektronische PublikationVersionsverwaltungPROMGruppenoperationInstallation <Informatik>CodeWikiComputersicherheitDigitalfilterProzess <Informatik>Quick-SortMinkowski-MetrikBinärdatenPlug inImplementierungSystemplattformSoftwaretestKollaboration <Informatik>Statistische HypotheseBeweistheorieOpen SourceTemplateSystemprogrammierungKontinuierliche IntegrationRechnernetzElektronische PublikationVersionsverwaltungMetadatenInformationQuellcodeAutorisierungResultanteDatensatzMultiplikationsoperatorRechenschieberDigital Object IdentifierKonfigurationsraumPhysikalisches SystemMaterialisation <Physik>ImplementierungOpen SourceEigentliche AbbildungBeweistheorieKontinuierliche IntegrationSoftwaretestDifferenteWellenpaketBildschirmmaskePlug inGarbentheorieProjektive EbeneCoxeter-GruppeWeb SiteKollaboration <Informatik>TouchscreenFunktion <Mathematik>Interface <Schaltung>DokumentenserverComputeranimation
01:14:47
Elektronische PublikationSichtenkonzeptFensterfunktionLesezeichen <Internet>SoftwareAutomatische HandlungsplanungSondierungATMOrdnungsreduktionVersionsverwaltungFamilie <Mathematik>Stetige FunktionInformationStichprobenumfangStichprobeÜberlagerung <Mathematik>FokalpunktDualitätssatzOpen SourceComputervirusExogene VariableWeb-SeiteOperations ResearchVerschiebungsoperatorAdressraumResiduumDokumentenserverRückkopplungStatistikCodeTotal <Mathematik>SpezialrechnerDatentypOffice-PaketGruppenoperationDienst <Informatik>DatenmodellMetadatenTermKonditionszahlSystemprogrammierungDatenmissbrauchHorizontaleDatensatzWeb SiteTypentheorieTrennschärfe <Statistik>RechenschieberDokumentenserverMetadatenSoftwareBesprechung/InterviewComputeranimationXML
01:16:23
SystemplattformOffene MengeAutomatische HandlungsplanungImplementierungDifferenzkernSoftwareBitHyperbelverfahrenBesprechung/InterviewVorlesung/Konferenz
01:17:41
MetadatenTermOpen SourceSoftwareSystemplattformUmwandlungsenthalpieDigital Object IdentifierProgrammGüte der AnpassungDigital Rights ManagementTypentheorieHilfesystemPackprogrammBesprechung/Interview
01:18:55
MagnetbandlaufwerkAggregatzustandProgrammbibliothekKonfigurationsdatenbankTermCASE <Informatik>Funktion <Mathematik>CodeSoftwareSystemplattformBesprechung/Interview
01:20:27
Digital Rights ManagementProdukt <Mathematik>HilfesystemPackprogrammSprachsyntheseMetadatenMengeFunktion <Mathematik>Besprechung/Interview
01:21:44
Abstimmung <Frequenz>TypentheorieGemeinsamer SpeicherIntegralRechter WinkelFokalpunktSoftwareModulare ProgrammierungZahlenbereichInformationBesprechung/InterviewVorlesung/Konferenz
01:23:15
SoftwareMetadatenMAPAlgorithmusVersionsverwaltungProzess <Informatik>VerschlingungGemeinsamer SpeicherSoftware EngineeringZweiIterationSoftwaretestOffene MengeSupercomputerIndexberechnungBesprechung/Interview
01:24:36
BootenProgrammbibliothekRepository <Informatik>AggregatzustandSukzessive ÜberrelaxationObjekt <Kategorie>DokumentenserverCASE <Informatik>TermSoftwareRFIDRepository <Informatik>VerschlingungMetadatenOffene MengeMultiplikationsoperatorSystemaufrufInformationThermische ZustandsgleichungEinfach zusammenhängender RaumGarbentheorieBesprechung/Interview
01:26:35
VerschlingungCoxeter-GruppeSharewareProgrammGemeinsamer SpeicherRegistrierung <Bildverarbeitung>DatensatzRechenschieberChatten <Kommunikation>MultiplikationsoperatorBesprechung/Interview
Transkript: Englisch(automatisch erzeugt)
00:00
Welcome all to this webinar about DOIs for research software, increasing visibility, connectivity, and site stability. We have a great lineup of speakers. First, we'll hear from Morane Grubeter from Software Heritage.
00:21
Then I'll give a short presentation on behalf of DataSite. Lars Hall-Nielsen from CERN will continue. And last but not least, we'll have Stefan Ruskat from D-L-Air, the German Aerospace Center. And afterwards, we'll have time for questions and answers.
00:45
So without any delay, I'll give the word to Morane and I'll stop my sharing so that you can share your slides.
01:02
You're on mute, Morane. Yeah, thank you. Thank you, Gabby. I just, I'm trying to share my screen. Thank you, everyone. And I'm very excited to be here. And thank you, Gabby, for giving me the hand. And also thank you to the DataSite team for inviting me to this webinar,
01:22
presenting software as a first-class output in the scholarly ecosystem. My name is Morane Grubeter. I work for the Software Heritage team at the INRIA Research Center in France. I'm a software engineer, but I'm also a metadata specialist and I project manage the effort of Software Heritage
01:42
and INRIA in two European projects, the FAIR Impact project and in FAIR Core for EOSC. And so today within this introduction to the webinar, I'm going to discuss why
02:00
and how to make software a first-class output. So first we will look at software as a pillar of open science. We'll discuss research software and define what is software and what is research software and how it is different from data. We'll see a few use cases
02:21
where researchers need to work with research software. We will discuss archive reference versus citation and I will drop a line about the metadata, but just a very short line because I don't have too much time to discuss in depth the metadata.
02:43
So now why do we need to recognize software as a special research object? So first from the data versus software article, we see that software is different from data because software is executable and is more similar to articles by being a creative work
03:01
while data is facts and observation. So yes, there is creativity in data, of course, and that software is written by human for humans to read. Now in the opportunity note from the French National Committee for Open Science, we see that we need to make sure
03:21
the specific nature of software is recognized and not considered as just data. And this is just two examples that show why we need to acknowledge software as a research object different than data. Now, what is software? Most users look at software as magic because it's something that happens.
03:42
It happens everywhere. It happens on your phone. It happens on your computer. In research, you might use software and not know what's really happening behind it, but software is really the logic between what the human are capable to do with the software and the data. Now, there are two things that you need to keep in mind
04:02
when you think of software. Software is a concept and a project that it can have a community around it working on this software. And so this part of the software is not digital. It is not a digital artifact and we do need to identify it. With that, there are the digital artifacts
04:21
and there are a lot of digital artifacts. There are executables to use and there is the source code where you can really see how the logic works. And in the source, it's a really large collection of digital artifacts. Now, why software source code is special?
04:43
Well, because it is complex. It has a large web of dependents. It can have a large web of dependents. There are softwares that do not have a large web of dependencies, but it's something that is very usual.
05:05
And it has a very, normally a very complex history, which is the key to understand it. Now, some project can last decades. And as you can see on this meme,
05:20
sometimes a project, a small project on which a large building is dependent on might disappear. So it's important to keep the software. Now, as I said, software source code is human readable and then it can be executable knowledge.
05:42
As Harold Ebelson said, programs must be written for people to read and only incidentally for machines to execute because the view to the mind of the designer is in the source code. And this is something important. Even if you are not a software developer, you can read code.
06:01
It might seem like poetry, very complex and not understandable, but everyone, every person can read code. Now, we talked about software. What is software? What is research software? So recently with the Fair for Research Software
06:20
working group, we had an output defining research software. Now, in this definition, there was a separation between the research software, which is created during the research process or for a research purpose and software in research, which is used for research. Why we differentiate that is for the next slides
06:42
and also for the full webinar, DOIs and other very specific identifier in academia will be given to research software, not to software in research. Now, software is one of the pillars of open science.
07:01
It should be at the same level alongside publication with open access repository and data, with open data set repositories. And specific thing about software, it has multiple facets. So as I said, it can be used in research as a tool.
07:22
It can be the research outcome or the result of the research. And here is, this is the research software and it can be the object of research. And when it is the object of research, it sees more as data, something to analyze, to work on. And the thing is that software can be
07:41
those three things at the same time for different teams. Now, as I started, we want to make software a first-class output. And how do we do that? That's the challenge. We're not there yet. And here on the slide, you see the Nozick pyramid
08:01
where we need to start from the bottom or from the top or from the middle, making software a first-class output. I will start from the bottom by making it possible. So there are many initiatives and organizations that are working to make this a reality. We have the Faircore for EOS project,
08:21
creating connectors and APIs between the, with different existing infrastructures. And there are other infrastructure that I'm not going to detail here in this presentation, but you're welcome to look at the Faircore for EOS project and the serious report. Then there is making it easy by giving researchers
08:43
and other stakeholders ways to do it more easily. We have the code metavocabulary, which I will discuss later on. And you have the citation file format, which is making it easy for researchers to cite software,
09:00
to make their software citeable. Then you have communities. And this part, which is important, is making it normative. So you have also effort making it normative. Not last, you have the incentives because we need to make it rewarding. So credit is a part of that.
09:21
We had the 4C11 citation working room and the 4C11 software citation implementation working room, very long name. And there are different ways to make it rewarding by providing awards. Here it's in French, it's the award for open source software in open science,
09:43
which will be also this year in November. And finally, you have policies that needs to be in place to make software first-class output. And you have RISA, which is working behind the Adore software document. And there's the French National Plan for Open Science,
10:02
which is a policy to keep in mind. And I've only put in reinstitution, but each institution can have a policy to improve the software place in the scholarly ecosystem. And so why are we here?
10:20
And here I'm going to just touch a little bit the use cases that we have around. We have some use cases for researchers about archival and reference and finding useful software, getting credit, verifying, reproducing results. Then we have the laboratories and teams tracking the software contribution or producing reports.
10:42
And maybe those teams have webpages to maintain with these software outputs. And there's the organization, so the institution with knowing which are the software assets they are holding. And finally, but not least, there are the curators that need to verify and curate software metadata and provide some documentation, monitor research teams,
11:03
production. Now, what is at stake? This is taken directly from the Sears report. So I'm not going to take time discussing what is the Sears report. It is scholarly infrastructure for research software providing recommendation for the infrastructure,
11:22
again, making it possible. And here we need to archive to make sure we can access the software reference to make sure we can identify the artifacts, the digital ones. We need to cite for credit to make it rewarding to create software by giving credit, by having citation, maybe citing the project
11:41
and not the artifact, not only the artifacts. And then finally, the describe, which make it easy to discover the software project so for findability. Now, why archiving? Why archive is the first one and is so important because software source code is fragile. It can be lost. It can be forgotten.
12:01
It can not work anymore. So it is fragile. And we have the software heritage team. We have the software heritage archive, which is identified in the Sears report as the universal source code archive. Now it is also catering to the scholarly ecosystem, but it's catering other ecosystems as well,
12:22
like industry, public administration and cultural heritage. In the scholarly ecosystem, we strive to connect with aggregators, publishers and scholarly repository, different infrastructures so that we keep our software saved. We save our software.
12:41
So the mission of the software heritage, the archive is to collect, preserve and share all software source codes because preserving our heritage is enabling better software and better research for all. By having the software, having it, we know that we can have better research.
13:00
Now it is very easy to save with software heritage. So this is my two, my one slide about why to use and how to use a software heritage. You can save any code now, like the Wayback Machine on archive.org. You don't need to be the copyright holder of the software and it's for public software.
13:21
So something that's online with your URL. It will save all the development history and we can collect anything from Git, SVN, Mercuro, different types of origins. And then you can reference this code,
13:44
these artifacts, the digital artifact, not talking about citation yet, by going on the source code, on the archive, choosing the directory because this is the best one to choose. Then adding the context because it's important to have the context
14:01
of this artifact. And finally, copying the identifier. That's a short how to use software heritage and why to use the hash ID, the software heritage ID. It's because it's identifying the specific artifact. It's like a fingerprint, it's intrinsic, it's decentralized and it's cryptographically strong.
14:22
Now it's not enough when you come to citation because we have very different levels of granularity. We talked in the beginning that there's the part where we have the project that we want to identify and we have the part where we want to identify the artifacts.
14:40
So in this pyramid, you see the different level of granularity. Again, I'm not going to specify each one of these levels but you can understand that one project can have many files. And if you want to identify a specific algorithm which is a code fragment,
15:00
that's another thing than identifying the full project. So we need to know that there are different levels of granularity and different type of identifiers can help us identify those levels of granularity. For the use case, the reference or citation use case, we have the possibility to use two different identifiers.
15:27
So we have here in this diagram, I'm using the HAL ID because the diagram shows the interaction between software heritage and HAL, the French National Archive. But in the next slide, I will show you the same thing with a DOI.
15:41
So not the same diagram, but the same concept, having two identifiers for the same citation. Why? Because the DOI or the extrinsic identifier is for credit and attribution. It will identify the metadata record with the authors and contributors while the SWID is an intrinsic identifier
16:04
will help us identify the specific artifact that we want to identify. And for different purposes for archival and index, we need both. For credit, we need the extrinsic identifier and for reuse and reproducibility, we will need really just the specific artifact
16:22
without the extrinsic one. So now the case of the DOI and the SWID on IPOL articles is very nice because on the, well, IPOL, for those of you who just discovered this new acronym, Image Processing Online is a journal
16:42
where the researcher need to submit an article with the software with something that's working online. There will be a demo of this source code. The source code is deposited to the journal and then is archived in Software Heritage and at the end you have the citation of the article
17:02
and the citation of the software. I'm going to show you how it works. So this researcher will submit to the journal all the artifacts which will be reviewed by a committee or peer reviewed the editor
17:21
and have some interaction about that. And when it's validated, it will be saved on the platform of the journal and then in Software Heritage as well. Now, a short word about the citation in this is that you can use also the Biblattic extension
17:44
to cite different levels of granularity. In this Biblattic style, there are just four types, software, well, it's not on the slide, but it's software, software module, here, software release, which is the version
18:02
and then the software expert, excerpt, which is the code fragment. And there's a YouTube tutorial to show you all of these possibilities while you can use that, of course, with a DOI. Just didn't have an example to show on the slide, but again, we have the two, the mechanism citing
18:21
both a SWID and a DOI and an extrinsic identifier. And so a touch about the metadata, as you've seen on my background, this is the image I'm using. Metadata is very important because the identifier, the extrinsic identifier will identify the metadata records.
18:41
So it's important that to note that researchers should know more about metadata, should provide metadata, they should provide metadata in the code itself and on a registry or a scholarly repository so that the software can be understood and found. And we have now an effort with the FAIR Impact Project
19:04
about the Research Software Metadata Guidelines, which I call with a new acronym, RSMD. It's now open for the community review until May 29th, if you are interested. This will pave the way to make it normative,
19:22
again, from our first slide. And just to finish, this is one of my last, in a minute, I will finish, in a second, I will finish. Just to let you know about the Code Meta Initiative, if you haven't heard about that, the Code Meta Initiative,
19:40
well, it's a vocabulary, but it's more than that. It's also a full community. The vocabulary is a subset of schema.org to make it, well, for web semantic purposes. But the most important aspect of Code Meta is its crosswalk table mapping the metadata landscape.
20:01
So there are many mappings with different vocabularies, including CFF, and version three of the Code Meta vocabulary is expected soon. So there are different ways to capture metadata, different vocabularies, but everything, some of them, most of them, maybe not most,
20:21
but a good part is mapped to Code Meta through the Code Meta project. And now to wrap up, what's important to keep from my presentation is that we want to make software first-class output. And to do that, we need to archive the code.
20:44
We need to adopt good practices to reference and cite research software. And it will be nice if you join the research software community and reviewing the RSMD guidelines by just joining the conversation about research software and spreading the word
21:01
to begin to recognize software in academia. Thank you for having me and thank you for staying tuned for the next presentations. Thanks a lot, Moran. And now I'm going to share my screen.
21:32
Sorry, again, I'm Gabby Mejias, Community and Program Manager at DataSite. And I'm going to speak about how DataSite
21:43
supports visibility, connectivity, and siteability for research software. And before a short introduction, for those of you who might be new to DataSite, we are a global nonprofit organization.
22:01
We have currently more than 280 members across 50 countries. We are a membership organization sustained and governed by different institutions around the world. From these 280 members, 56 are consortia.
22:22
These are a group of five or more organizations that join DataSite to adopt our DOIs and metadata infrastructure in a local, national, or regional level. And overall, more than 1,200 organizations
22:40
have connected more than 2,700 repositories. Overall, there are currently 42 million, a little bit more, DOIs in our registry. And we want to help increase recognition
23:03
and connectivity for research outputs and resources. And we provide DOI and metadata registration. The DataSite metadata schema is a list of metadata properties that enable accurate
23:21
and consistent identification of resources for citation and other purposes. Important to say that our metadata schema is an international globally adopted standard. It's governed by the community through the DataSite metadata working group
23:42
that maintains this standard in consultation with our members and with our board. And currently, the most current version is 4.4. And you can see the schema can be divided
24:03
into three groups. We have the mandatory properties, the recommended, and the optional properties. So as part of the mandatory properties, we have five, including creator, title, publisher,
24:25
publication year, and resource type. And currently, our schema supports more than 20 different resource types. Software is one of them. And as Moran said, we want to make software and other kinds of outputs and resources
24:43
first-class citizens within the research landscape. Someone asked in the Q&A about Jupyter notebooks, and you can see also we have computational notebooks as a different kind of resource.
25:00
And also important to mention that metadata completeness is very important to us. So we encourage all our members to register as much metadata and as curated as possible. And also to mention that citations
25:21
and references can be created by adding related identifiers to DOI metadata. So each related identifier has a relation type, which is used to define the type of relations.
25:42
And you can add citations and references to DOI metadata when you first register the DOI, and also afterwards through updates on the metadata. And we define citations as incoming pointers
26:02
to a research output and references as outgoing pointers to other research outputs. And important also to mention that we encourage the same relation types for software citation as for data citation.
26:23
And research is intrinsically interconnected, and metadata helps make those connections visible and transparent. And the data side metadata schema includes properties that facilitate these connections
26:43
between works and other type of entities, such as individuals, organizations, and other kinds of works. And these relations in the metadata schema include other many types of persistent identifiers
27:04
that help realize the pit graph. And here you can see a snapshot of March 22. So currently there's more notes added,
27:20
and you can see, yes, software being one of the notes and all the connections to different kind of entities. And here you can see an example of the metadata for software that you can register using DOI metadata,
27:42
and you can see the resource type software. It has a relation or actually two is a new version of an DOI, and it's a version of, and another DOI, the description, and this is some of the metadata you can register.
28:03
And to give you an overview of the current adoption of DOIs for software, some statistics from our registry. So I said before, we have currently more than 42 million DOIs registered overall.
28:21
And here you have the top 10 resource types. So you see dataset is the most common, currently 14 million DOIs for datasets, followed by text, physical object, images, other preprint collection, journal articles,
28:43
and software is on the ninth place. There are almost 400,000 software resource types in the registry, and the 10th being audio visual. And to take a look at who's registering DOIs for software,
29:04
you can see the top 10 repositories. You can see Zenodo being the repository that registers the highest amount, almost, yeah, all the software items with 345,000 DOIs registered,
29:24
and it's great to have Lars on the call on the webinar and hear his presentation later on, followed by other organizations. Something interesting on this list is Hoomanum,
29:41
which is an infrastructure for humanities. And also to take a look at the evolution of DOI registration for software, we can see the progress in the last nine years.
30:03
So you can see here, there's a big leap between 2016 and 2017, and also between 2020 and 2021. Last year, we had almost 100,000 new software resources
30:22
source types in the registry, and so far, we are almost at the half of the registrations from last year. And now let me tell you how we support increasing the visibility of research software.
30:43
So this is a snapshot of DataSite Commons, which is a user interface that allows search and discovery of all the information we hold in the registry,
31:01
all the metadata. So this is an example of a software resource type. It's identified with its DOI, comes from Zenodo, and you can see the description of that item, and you can see also the license,
31:22
which is supported in the metadata. And you can also see the creators. So as Moran said, credit recognition are very important. So you can see all the individuals that contributed to that software,
31:40
and also their affiliations, and very important that when you register this kind of metadata, you can include ORCID IDs for individuals, ORIDs for organizations, and also other type of identifiers. And also, as I said before,
32:05
the DataSite metadata allows you to register relations to other kinds of outputs and other kinds of persistent identifiers. So this software item has been cited once.
32:21
Here you can see one citation and has been cited in a journal article, and you can also see the information about the journal article and the publisher. And DataSite Commons also has or offers
32:44
citation information in different formats. You can also download the metadata, and something interesting for software contributors or practitioners is that it's also possible to add this information, the metadata of this software,
33:04
to your ORCID record through this button, and that's also important to enable recognition for this kind of contribution. And to continue increasing connectivity, it's very important for software metadata
33:23
to be connected to other outputs and other identifiers. So we have 309,000 software resource types on the registry. From those, there are 363,000 that are connected
33:44
to other identifiers through the related identifier property on the metadata. And here you can see the most common connections. So DOIs and your Ls are the most common.
34:04
Missing means there's not a related identifier, and you can see other kind of identifiers being used. I checked, and we do have some suite connected to software DOIs through the URL field.
34:27
And the ask would be to continue improving discoverability and connectivity of software by registering DOIs for your software
34:43
and curating and enriching the metadata, for example, using these related identifier field. And it takes a village to increase visibility connectivity
35:04
for research software. DataSight is currently involved in many different projects. And as Moran mentioned, we're part of the FAIR Impact and FAIR Core for EOS projects.
35:22
And on this project, both Software Heritage and CERN are partners. We are also part of the Make Data Account Initiative. We've recently announced the creation of a global citation corpus.
35:42
And also the FAIR Workflows Project is aiming to improve software recognition as part of research workflows. And that's the end of my presentation. Thanks for your attention. And now I will give the word to Lars.
36:07
Thank you. You can see on my screen.
36:22
There we go. Okay. So my name is Lars Hahn-Nilsen. I'm from CERN, and I'm leading the team responsible for CERN.
36:40
So you have just heard that research software is important part of research itself. You've seen multiple different things that you can do. Okay, so the questions of course are, you know, how should you cite software? How would you cite software and what can you do about it?
37:01
And before I answer that questions, I'm gonna take you on a little tour of the infrastructure behind all this software citation. Basically, if you have to do use an analogy, how does the entire banking system look like that actually accounts for all these citations and what are some of the challenges that are involved in it?
37:22
So if you look at it at a very basic level, right, you have a researcher as an author of a scholarly manuscript who is using some piece of software developed by another researcher who wrote this piece, right? And the basic idea of software citation is that this token of credit,
37:41
the citation itself is given to the developer so they can get the highest ending, right? It's basically the monetary unity that we have in research is citations. So how can we get it along, okay? And if you look at it as a big system, right, then you have an author up in the left corner
38:00
who writes a paper. They give it to a publisher who publishes the paper. It gets indexed by some sort of a discovery system and that discovery system able to count the citations and you also have a developer who writes the software down in the bottom, right, who publishes the software and then somehow the discovery system can match this paper and citation up
38:22
and give a citation come back to the developer, okay? So in this big picture, which I'll go into details with, right, then that's basically two key systematic issues. There's a huge information loss and there's a dilution of citations where these citations being diluted along every single thing.
38:43
And I'll go a little bit in detail. So as an author, your main job is to include a citation in the paper, right? But then you have to figure out what do you cite? Do I cite a software paper? Do I cite the software itself, the software version? Do I cite the software heritage ID?
39:01
It might be your reference manager doesn't really support dealing with a software type or can't generate proper citation strengths. So there's this problem like, well, I actually don't know which part to cite. So that's the first one. And here's an example of how this can look like.
39:23
So there was a piece of software called triangle.py, that's two DUIs in Sonoto. Then it was renamed to corner.py, another three DUIs. Then there was a journal of open source software paper and there was also another identifier in this astronomy source code library, right? So which one of these do you cite?
39:42
Which one do you put in the reference, right? That creates a messy world and it makes it hard for a discovery system to then figure out is this the entire, is this all the same thing? How do we count citations to this? So then let's next look at the publisher.
40:01
So if the author manages to include the citation, then the next thing is that the publisher has to make sure that that citation is actually included in the final product. So first of all, those publishers might have policies that prevent software citations that you are not allowed to cite only papers, you cannot cite data and software. This has been changing and luckily it's getting accepted
40:25
but we're still not there. Then another important thing is that it might be that the textual description when you have a reference list, right? You have the citation string, that citation string needs to be passed by some sort of machine. And if it has to be passed just from the text,
40:42
it's very hard to ensure you get the right DUIs out of it and things like that. So what a publisher has to do is to make sure that the DUI that was somehow in your reference manager makes it into the final product in some sort of machine readable way, which is called, publishers often use JetSXML, right?
41:01
And often these final systems, they need to be adapted. So when you publish in some sort of journal, then that journal might be owned by a scientific society who outsourced the running of the journal to a publisher, who have outsourced the authoring platform to a vendor,
41:21
who have outsourced the vendor platform and the coding of the vendor platform to some other company. So if you need a change to enable proper the DUI to go all the way through to the discovery system, it can be quite daunting to actually make it through and get that change into an authoring system
41:41
and make sure that it's communicated correctly, okay? So that's some of the challenges that are there. Now let's look at the discovery services themselves. So a discovery service basically has to take a paper and inject it into their database and track citations to it.
42:00
But first of all, then they need to allow that the software need to be able to count citation to a piece of software and identifying the SLList link, right? And it might be they don't allow software at all, right? But also just understanding when to create a new record. You saw all the different persistent identifiers that you could have, is this all the same?
42:21
How do we want to model it? So just understanding how to actually attribute the link from the paper to something and count all of the citation is a non-trivial thing for these discovery systems. On top of that, then for instance, there's the C-Bone Python library for statistical data visualization.
42:42
And each of the different discovery systems basically cover different spectrum of where they count citations. So for instance, your PMC looks at a certain subset of data and they count citations for another thing, for instance, NASA ADS, they look in astronomy
43:00
and then there's data as well in Crossref about the C-Bone. And C-Bone is a tool, a statistical data visualization. So you can imagine it can be used in many different sciences. But it also means that these discovery services count citations in different areas. And in this case, only one citation was in all the different three discovery systems.
43:24
So you need basically to have a global picture of multiple systems to get a full citation count out of it. Now, if we briefly look at the developer, then they basically need to ensure that their software is citable.
43:40
And again, the problem comes in like, do I write a software paper? Do I put the software on Senodo? Do I put it in software? What do I do? Do I stick in the GitHub URL or things like that? But then there's also things like dynamic authorship. So software is often a collaboration where there's many people coming and going and making sure that who should get created.
44:04
If you just put it in the DOI initially, then how can you see that the new contributors that came in and how do they get created for being part of it, right? And then of course, people can have good ideas of changing names because it's not a good enough name
44:21
and things like that. That all complicates how we are able to count and track citations to software. Another example is that then because of all these different persistent identifiers, then essentially citations will be spread over all the different identifiers. And here's an example of a piece of software
44:41
where two different DOIs were recommended in the actual BIPTECH copy paste link, which means you get citations on both of them. Another example is what Ghost Monkey calls BIPTECH latency. So here, essentially people will take a reference
45:02
to take a software citation, take that reference, put it in the reference manager, and then they will reuse it through time and only later on pick up a new one. So what you see is that it takes time for new DOIs to do. So overall, if we want to count software citations,
45:22
it gets somewhat complicated to really cover the full ground, right? So overall, there's just systemic issues all over the place here, information loss, and that you dilute the citation over lots of different persistent identifiers.
45:42
So back to my initial question, now that I've demotivated everybody about that, that there's no point in citing software. So how should you cite software, right? And I think if that's just one thing I want you to take back with you from today is that you should just choose one of the things
46:00
that you hear in one of the presentations today and do it, okay? We, as infrastructure providers, are all working on solutions to most of these problems that I've shown you, okay? What you can do as a research software developer or a paper, as an author of a paper, right, is to just choose one of the things and do it,
46:21
and that will help move the system along. Everybody, this is a huge changing system, and if we don't all improve, then the entire system doesn't improve, okay? So each one of you has to choose just one thing and do it, that's my claim. So what could you do now that you've chosen, right?
46:41
So simple things is ask, if you are a research software developer, ask your users to cite. You can archive your software in a repository, for instance, Zenodo and Software Heritage. You saw different solutions. Choose one that fits you the best, okay? You could write an article in this journal
47:02
of open source software, which is really about like, how do you also make the software reusable for somebody else and describes it in a nice way, right? So how? Well, an easy way is if you're using GitHub, for instance, or any kind of tool,
47:22
then you can add this citation.csv file inside your repository. If you do that on GitHub, they will add this nice, cite this repository that will highlight users that they can cite it, okay? And the important thing is that it also, this file, as with the code meta file
47:40
that Maren was describing, puts in some meta data in the source code that we can use to figure out who should actually be the authors of this piece of software, who should get credit, and what do you want to call it? And it allows us to get this meta data out of it. And anybody who gets the software can get that meta data out of it, okay? And that's important in order to be able to check.
48:02
Then archive in a repository. So Zenodo, as you saw, have had great success with our GitHub integration, where essentially you go log in with your GitHub account on Zenodo, you flip a switch, and then every time you create a release
48:21
of your software on GitHub, we get notified and we will then pull it down, stick it in Zenodo and give it a DOI, okay? And if you have this citation CFF file, then we use that to basically add the meta data into the software.
48:42
Now, if you've used Zenodo and put your software there, then what we do is that we will scout currently three different discovery system for citations to your software. And we will aggregate it all. So that means that even if you have multiple versions of a piece of software,
49:01
then we'll be able to show all the citations that links to all this software. So for instance, here you see it's Matplotlib that then have 76 citations to it from different places, okay? And this is solving part of this issue with the multiple different persistent identifiers that I was talking about before.
49:23
So my last word is basically, remember, choose one thing. It doesn't have to be any of the one I presented here. Anything from the persistent and do it, okay? Here is some of the recommendations I can give. Thank you. Thank you so much, Lars.
49:40
And now we'll hear from Stefan. Hi, thank you very much indeed. I think that all was meaning to share a poll. But first let me introduce myself. I'm Stefan Driscott. I'm a doctoral researcher at the Institute of Software Technology
50:02
at the German Aerospace Center. And I will highlight a very practical point of view on the topic of using DOIs for your software, citing software, publishing software. And the thing I'm going to introduce is a project called Hermes.
50:20
I'm just going to start sharing my slides. And what we're trying to do in this project is take the idea of the GitHub Zenodo integration that Lars has just talked about one step further. Lars has described that Zenodo will pull metadata from a citation.CFF file from a repository
50:43
whenever you have it switched on. And there is a lot of metadata present in the source code repository, even beyond a CFF file. And this is metadata that we can use to make the software more findable,
51:00
more accessible, more understandable. So while you fill in the poll, and this is going to be very interesting to me because I will talk about some of the platforms you can use for automated software publication. And I'm very interested in seeing what actual solutions you use.
51:21
I will continue with my presentation in the meantime. So I'm briefly going to talk about why you should think about publishing your software in the first place. I think we've heard some great comments and great remarks on why you should do this already. I'm going to add to this, and then I'm going to introduce the Hermes automated software publication workflow.
51:44
And also give you a brief demo of our proof of concept implementation of the workflow, because what can possibly go wrong? Demoing live in front of 220 people online, right? And finally, I'll share with you what the plans are for the future.
52:01
So what do we actually mean when we talk about software publication? You should publish your software for at least these four very good reasons. Software publication, so making your software available to the public under a DOI or other persistent identifier,
52:22
enables at least these four things. It enables making your software fair, so making it findable, accessible, interoperable to some extent, and reusable. Because if you don't publish software, then nobody will know about it. Software publication, at least in the way we define it, and I'll talk about this in a second,
52:43
enables the technical sustainability at least of the softwares, meaning that it will be available in the future and be adoptable to other needs than the original needs in the context of which the software has been created. And this makes it more sustainable. So archive your software.
53:00
And we've heard some things about receiving credit for your software work. And software publication under a DOI, if you supply a list of personal author names at least, does enable academic credit for the people who created the software. And Moran was talking about the, within the context of the pyramid
53:21
in our talk about incentives. And in this context, it may be interesting for you to hear that in Germany, the Helmholtz Association of Research Centers has introduced a KPI, a key performance indicator around software publications. So starting this year,
53:41
the centers within the Helmholtz Association can leverage this indicator and start counting software publications that are citeable and are published with metadata. And finally, software publication, especially if you make software versions citeable that people actually use, enables reproducibility.
54:02
Taking, again, one step back, what do we actually mean in the context of the Hermes Project when we talk about software publication? This is something that you've heard something about already. It's mainly the publication of metadata and artifacts for software versions and publication repositories. And probably the most well-known publication repository
54:23
is Zenodo that Lars has just talked about. Why is there an asterisk behind artifacts? Because you can also, not with Zenodo, but with some other platforms, only publish the metadata for your software. And this is a good way to make your software fair,
54:43
although it may be closed source. And we know that some research software is closed source for reasons that lie within the project context. When you publish your software, you get a persistent identifier, a DOI, for each version. This is very important,
55:01
so people can actually cite the version they have used in their research. And it's important to, and I think I digress a bit from what Lars has said here, as the Hermes Project, we don't think that the following are actually software publications. Software available on a source code platform, GitHub or GitLab, for example,
55:21
is not a software publication. A paper about the software is not a software publication because it's simply a different artifact. It's a piece of text rather than a software itself. We've already heard also about the Journal of Open Source Software. This is a software journal where you can submit a specific version of your software
55:41
and write a bit of a text around it, a short paper around it. This is a very good interim solution on the way to actual software publications where you publish the software itself. And it doesn't need some sort of cover up paper to make it understandable to people
56:01
that this is an actual research output. So the idea is that you publish the software itself, you describe it with metadata to make it fair, and people then cite the software version they're using or cite the software concept if that's what they need in their specific use case. The challenge obviously here is that the usual quality assurance you get with publications
56:22
in terms of peer review is not something that works well at the moment because there is no automated peer review if you push your code to Zenodo or to another platform. This is something that needs to be solved either in the software projects themselves by employing code reviews on integrations
56:43
or new code that's coming into the project, but also the software journals, especially JAWS, make a very good job of doing some peer review, some quality assurance specifically around the software engineering factors of the software.
57:00
Right, so in Hermes we're concerned with publishing your software in an automated way with as rich metadata as possible because we believe that there is a lot of metadata that can be reused for making your software fairer and metadata rich already.
57:21
And we've already seen that if you want to not be bothered by filling in forms on the internet, typing in metadata into a form for your publication, then you can already leverage the GitHub Zenodo integration, especially if you have a citation file format file, citation.CFF.
57:42
This will improve the metadata already and you don't have to bother with manually publishing your software every time you make a release. So like I said, we're trying to take this one step further and automate this publication process via continuous integration platforms.
58:02
And this we think has different advantages. First of all, we turn the process of publication on its head. Lars has mentioned that Zenodo pulls information from the repository, from the GitHub repository if you switched on the GitHub integration, and this is great.
58:20
And if you have a CFF file, then that's great as well, but not all projects are on GitHub and not all projects have CFF files. And also Zenodo cannot possibly patch all the metadata that may be available in the source code repository. So we take an approach of pushing,
58:42
making the user push a publication to a publication platform rather than having the platform pull this information. And the way we do this, the way we think about this is this relatively complex looking concept. It's not really complex, in fact. It's something that some of you who are software creators
59:02
and work with continuous integration platforms will know. So the idea is that a user, an RSE, a research software engineer pushes the version of the software they want to publish to a source code repository. And within the source code repository, there is a continuous integration solution. So obviously a pipeline that runs whenever new code
59:21
comes into the repository based on a trigger you can define. So for example, if you make a new release or if you tag a specific version of your software and this CICD solution will then run a tool we're developing, which is the Hermes workflow, a publication workflow tool. And what the tool does is it collects metadata
59:43
from different sources. So we have metadata files such as code meta.json or citation.CFF. It also collects metadata from code files. There is metadata, for example, in license headers, in docstrings and in API.
01:00:00
descriptions and comments etc, but also it's possible to find metadata in documentation files for example, free text citation information, things like that. And interestingly there is metadata also in different platform API's or on different platforms such as static code analysis
01:00:21
platforms that you may use in your project, which may have interesting metadata regarding the software quality for example, or actually the Git API, the Git history of the source code repository platform itself. So all this metadata is being collected by the Hermes tool and then is proposed for publication because in reality in some of our projects and some of the projects we know we've been involved with,
01:00:47
you have to have your line manager sign off on publications, and therefore it's important that you are presented with this collected metadata, compiled metadata, and are able to either send it on to someone who can sign off on the metadata and the publication itself
01:01:03
or you can do this yourself. And finally then, if the metadata looks okay, it is published to the publication repository. So, like I said, one of the main aspects is that we are proactively pushing versions for publication rather than relying on the publication target platform to pull.
01:01:24
One big advantage of this solution is that it can support different platform combinations so if you host your code on GitLab for example on your institutional GitLab instance, and you want to publish on a Dataverse instance, or a DSpace instance or your institutional repository, this is something that Hermes supports.
01:01:47
And we also support, as mentioned earlier, the curation process so you can have a look at what you're actually publishing before it gets published, but also the fair publication of metadata only software publications, in the case of closed source software.
01:02:05
We've written a concept paper, there are many more details in the paper itself, the link to these slides is in the chat already, and you can have a look at the paper if you're interested to learn more in detail. We are now at a stage where we have a proof of concept implementation of this workflow in place.
01:02:24
The Hermes process workflow tool basically consists of five steps. And they're being executed in this order so first of all you have a harvest step, which takes a look at your repository and harvests all the metadata available in the repository into a common data model.
01:02:45
And then it does a bit of processing, which is mainly to collate the metadata to look for duplications, to look for conflicts you may have for example between different spellings of author names, different versions from different metadata sources so you may have a version of the Git tag, you may have a version of the CFF file, different version, and perhaps even a third version somewhere else.
01:03:06
And then you have a report that is being, or at least the compiled metadata set is being fed back to the user for curation, for signing off on the metadata, and then it is being deposited on
01:03:22
the platforming because at this point we already have a signed off on consistent metadata set for your software. You can also post process the metadata and, for example, feed it back into the repository to update your citation.CFF file to update your code meta file or update any other metadata you would want to update.
01:03:45
And specifically every single step is extensible. This is important because we want to target different metadata sources, not just CFF and code meta and Git, which are the ones that we have in place right now. You want to be able to implement different merging strategies for the metadata you have, so this is extensible as well via plugins.
01:04:08
The curation is very basic at the moment, I will show you in a minute. So we are in the process of setting up a concept for developing a curation UI so that people that are not familiar with code meta
01:04:23
.json metadata files can have a better way, a nicer way to to work with the metadata and look at them and sign off on them. And finally, obviously, depositing, we want to target different platforms, so there is an Invenio plugin at the moment which targets Zenodo, which can target different other Invenio RDM instances, but we're developing a Dataverse plugin as well, and you can plug in your own solutions there.
01:04:47
And finally, post processing. You can already feed back metadata into the CFF file and into the Hermes configuration itself, but this is something that's a very important concept to be able to
01:05:00
make this workable for your combination of platforms, which is kind of why I've asked these polling questions at the beginning. Just very briefly, the project is a collaborative project between three German research centers, all part of the Helmholtz Association. We're being funded by an incubator project called the Helmholtz Metadata Collaboration.
01:05:20
And where we are now is that we have a proof of concept publication workflow tool, we will develop by the end of the project CI support for these three CI solutions, so GitHub actions, GitLab CI, Jenkins, and that's just because we think these are the most commonly used ones, and we will support Invenio RDM based platforms and
01:05:41
Dataverse based platforms, because those are the ones that are being used in Helmholtz the most. But, how does this actually look to you as a user, as a software creator? In practice, and I'm going to start the demo in just a second. And what you do is you push to the repository, then the GitHub action, in this case,
01:06:01
runs Hermes, the Hermes workflow tool which harvests and processes metadata, creates a pull request for you. And then you can curate the metadata within the pull request and then decide whether you want to close the pull request without further action, which will abort the publication process, for example, if you have faulty metadata in there, if something went wrong, then you can just close the pull request.
01:06:24
If you want to accept the metadata that has been compiled, you can merge the pull request and Hermes will then run the publication, the depositing step, which will give you a publication and also will run post-processing, which will again then create a new pull
01:06:41
request for you to sign off on the changes that post-processing will have made. Right. Let's dive right in. I have prepared a demo repository, which has been set up to use Hermes and published to Zenodo sandbox. This is a link to the tutorial, and I've actually add my own dog food and use this tutorial to set up a repository.
01:07:04
So I'm going to quickly share a different window. And you can now see the publication, the demo repository, which is really, really just a skeleton. So you have a basic, very basic readme file.
01:07:23
I can quickly show you the Hermes tunnel configuration file, which is at this point kind of configures the different steps. So we harvest metadata from Git and the CFF file. We want to deposit on an Invenu-based platform and specifically the Zenodo sandbox.
01:07:41
It's a bit bigger. And we want to do some post-processing because, as we've heard, Zenodo will give you a DOI for your version, but also for the concept. And so the next time you publish your software, you want to publish another same concept DOI to make sure that the version is counted as belonging to the same software project.
01:08:06
This is a very, very basic citation.CFF file. It's a YAML file, which gives you some basic metadata. And I will now try the demo for which I will just adapt the readme.nb file.
01:08:22
I'm just deleting a blank line, and I will push it straight to the main branch. And because I have configured the Hermes workflow here in this GitHub action file, which is still a bit long, but like I said, it's a proof of concept. We're going to wrap this
01:08:44
a lot nicer so you can use this more easily. And we've configured this to run every time you push to the main branch. And so I will have a look at the CI pipeline. And you can see it has picked up my new commit and is now
01:09:07
running the software publication step, which has just succeeded. And as you can see, it has created a new pull request for this specific commit. And this is now the curation step. So we're now going to look at the metadata
01:09:24
that's been compiled, and we'll then sign off on it. I'll quickly show you what's happened. You now have a code meta.json file with the compiled metadata from different sources in your repository. This is stuff related to contributors rather than authors.
01:09:45
It comes from the Git metadata source. There are different roles in Git for people that interact with the repository. And then there is more metadata coming in here from the CFF file.
01:10:04
And so now I've looked at the metadata. I think it's looking fine. And I will continue to merge this pull request and fingers crossed the action won't run too long. And I will have a publication in a minute.
01:10:20
So going back to the CI overview, I can now see that because I have curated this pull request, I've curated the metadata and I've merged it, so it's signed off on it. And Hermas has now started trying to publish the software. And this will run for a couple of
01:10:44
seconds. I can show you the details. It basically sets up the Hermas workflow in the continuous integration pipeline. And it will then... Maybe Stefan, in the meantime, we can share the pull results. Oh yeah, that sounds great. Yeah.
01:11:02
Perfect. Maybe you can... Or I can go through it. Oh, that's fine. I can do it if you feel like. Yes, it's interesting. So we have relatively even split in terms of continuous integration solutions between using GitHub Actions and using GitLab CI. And I think that's probably because a lot of institutions use GitLab for software development.
01:11:25
And then there are... There's around a third of the people who don't use continuous integration yet. And this... We're able to gather repositories. It's interesting to see that, according to the data side slides, Zenodo is obviously the most liked publication target.
01:11:48
And there are people that don't publish yet. And there is a relatively even split between different other solutions. Interesting. I'll definitely keep these answers on. So in the meantime, the action has run through.
01:12:06
And we can have a look at the actual deposit step that the Hermas has run and see that there is now a published record on Zenodo. And this is basically populated with metadata from the citation.CFF file.
01:12:21
So author information in this case, like I said, it's a very, very short file if you have a new version. And also going back to the source code repository, there is now a new pull request which gives you the post-processing results from Hermas. And this is basically changing the Hermas configuration to include the Zenodo sandbox record ID.
01:12:46
So next time I publish a new version of my software, this is going under the same concept DOI. Right, quickly going back to my slides. So as you've seen, we are now ready for very cautious user testing. This is still a proof of concept.
01:13:04
So make sure that you read through the tutorial carefully if you want to try this out. It should work with Zenodo proper already. So you can actually, if you use GitHub and Zenodo, then you can do this. We'll be finished with the project by the end of June and have the proof of concept implementation ready with more metadata sources.
01:13:22
So harvesting from different other sources. We will provide templates, not just for GitHub actions, but also for different other continuous integration systems. We'll have documentation and training materials ready in the form of a Carpentries lesson. And then we're looking to collaborate further with different other institutions and actors to support other publication repository
01:13:42
solutions such as myCORE, which is a project with the Technik University in Braunschweig, and supposedly also support dSpace. We are looking into working with the Carpentries who are interested in using Hermas to publish some of their outputs. And so they need a custom plugin for this. And we are definitely looking into improved metadata curation
01:14:06
possibilities, potentially via a dedicated user interface like a website where the metadata is being sent for curation. And we will do some preliminary work at DLR, but are also looking for collaboration partners in this respect. Thank you very much for your attention, and I'm happy to answer questions in the Q&A section.
01:14:28
Thank you so much, Stefan, for the presentation and the demo, and also thanks to Lars and Moran. And now we have some time for Q&A.
01:14:43
Maybe Stefan, if you can stop sharing your screen. Thank you. And I can quickly start because some people have asked questions about Commons
01:15:02
and how the search works and how to claim works to your working record. So here you can see data site commands. So the URL is commands.datasite.org and it's possible to search by works.
01:15:27
So this is connected with DOIs, people, through ORCID IDs, organization, through ORIDs, and through repositories. And this is connected to W3Data. So I've entered COVID as the keyword, and I can filter by resource type.
01:15:49
So I'm selecting software and I can, for example, select this one. And here I come to the snapshot I shared on my slide.
01:16:06
And you can select add to your ORCID record, and then this information, you need to authorize the connection, and then these metadata will be added to your ORCID record.
01:16:21
So that's what I wanted to quickly share. And now let's go to the other questions. There's a question about what are the biggest shortcomings that publishing platforms have. And if we're aware of plans to implement desirable practices in open publishing platforms, such as OJS or research equals.
01:16:49
And I think, Lars, you've spoken about this topic and obviously Stefan as well. So I don't know if you would like to answer this.
01:17:04
Yes, so I'm not sure if it's only if it's really the publishing platforms like OJS or it's in general, right? So I think there was also some questions a bit later on. I think each platform has different pros and cons, and there's not one size that really fits all. So you have to see where it fits in.
01:17:22
It's also about what is your purpose of the software citation. This is for credit or reproducibility. It's like there's not one size that fits all. So, yeah, I'm not sure if that answers the question.
01:17:41
Thanks. And I don't know if Stefan, you would like to add something. So in terms of having a rich metadata set that's actually presented on publications platforms, I think one of the shortcomings is that there isn't yet enough support for the software type in all of the platforms that are out there and are being used in research and in academic institutions.
01:18:08
And specifically, things like having versioning and having versioned DOIs is something that would be really good to have in more platforms and being able to, you know, push metadata that's software specific such as license information, programming language, etc.
01:18:25
Zenodo does really support this in a very nice way. And so I guess this is one of the reasons why we see so many software publications on Zenodo rather than other platforms. Thank you. And another question. What would be good sources for discovery tool managers to activate to
01:18:47
help make archive software more visible? Moran, I don't know if you'd like to say something about this. Thanks, Gabby, for giving me the question, even though I'm not sure how we can help
01:19:02
with that yet. With Software Heritage, we are indexing the metadata, but not yet providing tools for discovery. The discovery is done with registries and on data side, for example, or on other aggregators. So this question specifically is more for you, Gabby. I wanted to say just a short thing about publishing because
01:19:28
of the last question. We need to really divide publishing like an article, like on Joss or on other platforms that are publisher where there is a code review and an article review of the research output and sharing the code.
01:19:47
Sharing the code is possible in Zenodo. It's self-archive. It is better because then it is findable because Zenodo also you have discovery tools in terms of it's indexed and you can find the software easily.
01:20:01
It's better with Zenodo than with Software Heritage for findability purposes, but it's still just sharing and self-archiving and not publishing in terms of having people looking into the artifacts and reviewing the software. So we need to really differentiate these two use cases.
01:20:26
Thank you. And coming back to the questions, or to the question for Discovery Tool Managers, and we have Christian Garza, who is our Product Design Manager.
01:20:41
Christian, I don't know if you have any recommendations for Discovery Tool Managers to help make archive software more visible? Sorry, I was muted. But actually, I don't. I mean, do you think of something Stefan,
01:21:02
that it could be? I have Stefan in front of me, so I'm taking that one. It's definitely a tricky one. So, from my context, speaking from my perspective, it would have to be a solution around metadata and, you know, considering a set
01:21:30
of very basic metadata that can be then reused to identify the output itself, maybe, but I don't have any ready-made solutions.
01:21:41
It's a tricky one. Thank you. And we can continue discussing this. We have a notepad available, so for the questions that we won't be able to answer live, we'll share some comments on the notepad, on the chat box. Thanks, Paul.
01:22:01
And a question for Lars. What is the actual status of the GitLab Zenodo integration? Yeah, I wanted to type the answer, and then I clicked the wrong button, so then I couldn't come back. So, there's currently no assigned effort to do it.
01:22:22
Okay, so that's in Helmholtz, they have a GitLab integration on a VinoRDM. It's something we're looking at. Yes, but the big thing for Zenodo right now is that in September, we will be doing a large upgrade, which will add a lot of features into communities and things like that. So that's the main focus right now.
01:22:42
So, nothing concrete. Thank you. And then there were some questions about the poll in itself, but Stefan already shared the results, but there's another question for Stefan about Helmholtz KPI for software publications.
01:23:02
How are you counting published software per package per version? Do you consider a number of citations for the software package and any other information you can share? Yes, I will look up the link and share the link to the Helmholtz Open Science Policy, which details that in a second.
01:23:24
But just very basically, so the first iteration of this KPI, so to speak, is looking at just published software versions that are citeable and have a DOI and relatively decent metadata attached, so it's really just counting beans at this stage.
01:23:43
But they're in the process of developing a KPI that will also look at quality. And to me, it's not quite clear what this will end up being. It's definitely a very hard question to answer, how to automatically define the
01:24:03
quality of a software, because there are so many levels with regard to that. You have the software engineering quality, test coverage, that kind of thing. But that's also things that can be gamed. And then you have different qualities. Is the algorithm that the software implements correct, for example?
01:24:21
Is it sufficiently fast to execute on an HPC platform, for example? So this is going to be a very interesting discussion to have in the future, how a better indicator will look like. Thanks, Stefan. And there's a comment from Ugo.
01:24:47
If we treat software repository the same way as we do with data, we should make a distinction between a repository of records, such as Zenodo, where the main objective is citation and dissemination use cases and long term preservation of the same object or artifact.
01:25:03
Software heritage happens to satisfy both use cases, but if the publication copy is in a repository that does not explicitly offer long term preservation, which includes aspects of sustainability funding, etc. We should also put a copy into software heritage and link that pit as the long term preservation object.
01:25:30
Well, it's not a question, it's a comment, but I will answer it with the fair call for EOS project, which we are working on these connections between the different infrastructure so that the artifact that are deposited or submitted in a scholarly infrastructure
01:25:46
will be then also transferred for long term preservation in software heritage and also Lars has answered one of the other questions in the answered section that this is something that we are working with CERN, and we dance, and with also publisher like DAX tool, and at the sciences
01:26:03
and with aggregators we do data side, and with SME math, and finally also with open air so that it's very important for interoperability that all these infrastructure can relate the the the metadata and the information between on research software and also keep
01:26:24
the artifacts in a way that it's preserved for the long term so yes, there is, we're working on on that. Great, thank you so much, and the time's running up so we don't have any more time to answer questions but we'll
01:26:42
continue answering those on the notepad thanks all for joining us today and special thanks to Lars Stefan and Moran for your presentations and demos and for contributing to this discussion. As I said before, we'll share the recording and the slides for email, and we
01:27:04
also have two webinars coming up in June, featuring the global access program and how we're going to work with partners from Africa and Latin America. You can see their registration links on the chat.
01:27:23
So thank you all for joining us today, and see you next time.