Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.
Info
iconfalse
titleInhalt

Inhalt

Einwahl und Zeit

Datum: DonnerstagDienstag, 23. Oktober 2018
Uhrzeit: 15:00-17:00 Uhr
Einwahl: 030 200-97940876

...

1. Datenformate und Zuständigkeiten

FormatTemplateEmpfehlungsseitezuständigerledigt seit dem letzten TreffenToDo
DataciteLizenzen XMLDataCite Schema (Empfehlung 1.0)Friedrich nicht behandelt
EDMLizenzen LoD Francesca nicht behandelt
ESELizenzen XML  Cosmina nicht behandelt
JATSLizenzen XML  Conny wird fristgerecht zusammengestellt
KIM-Empfehlung RDF-TiteldatenLizenzen LoDKIM-RDF (Empfehlung 1.0)Jana wird fristgerecht um besprochene Beispiele ergänzt
MARC Lizenzen XML ReinholdMARC (Empfehlung 1.0)Reinholdwird fristgerecht auf MARC-IST-Zustand zugeschnitten und mit Hinweisen versehen, wo Diskussionen / Erweiterungsprozesse laufen und wann mit Änderungen zu rechen ist. 
METSLizenzen XMLMETS (Empfehlung 1.0)Stefanie wird fristgerecht um besprochene Beispiele ergänzt
MODSLizenzen XMLMODS (Empfehlung 1.0)André wird fristgerecht um besprochene Beispiele ergänzt
OAI_DCLizenzen XMLDCMES (Empfehlung 1.0)Friedrich nicht behandelt
EADLizenzen XML Oliver wird nach November weiter ausgearbeitet und zu einem späteren Zeitpunkt als V 1.0 veröffentlicht

 

2. Finalen Review der ersten Veröffentlichungsversion

3. Planung Öffentlichkeitsarbeit

3.1 Bibliothekskongressvorbereitungen

4. Nächste Schritte / ToDos

...

  • Formal festhalten, welche Beschreibungselemente in die Empfehlungen 1.0 aufgenommen werden sollen (war: rdfs:comment in KIM-RDF)
  •  Beispiele abgleichen (besonders: Werte)

Gesprächsnotizen:

  • Übereinkommen zur formalen Umfangsabgrenzung der Versionen 1.0 der Empfehlungen: es soll der Schwerpunkt auf Empfehlungen zu URIs gelegt werden. Die in den Templates ebenfalls durchexerzierten Werte-Aspekte "Bezeichnung/Code", "Quelle/Authority" und "Beschreibung" müssen zum jetzigen Zeitpunkt nicht systematisch durch alle Metadatenstandards abgedeckt werden. Als Motto gilt zunächst "so einfach wie möglich". In den Standards, in denen auf Grund ihrer Zielgruppen / üblichen Nutzung weitere Werte-Formen naheliegen / üblich sind, werden diese eingebracht (Beispiele: Codes in MARC, anzeigbare Labels in MODS)
  • Die Versionierung soll strikt durchgezogen werden, d.h. nach Veröffentlichung und der expliziten Kennzeichnung des Status "veröffentlicht" sollen keine inhaltlichen Änderungen an den Seiten gemacht werden. Die Versionierung erfolgt auf Metadatenstandard-Ebene. Überarbeitungen gehen in die jeweils nächste Version ein. Deshalb werden die Wikiseiten benannt nach dem Schema "Metadatenstandard (Empfehlung X.X)", z.B. "DCMES (Empfehlung 1.0)". Werden in der Zukunft Änderungen an der Empfehlung zu diesem Standard vorgenommen, so wird eine neue Seite angelegt und eingebunden, die dann die Bezeichnung "DCMES (Empfehlung 1.1) erhält. Damit ist sichergestellt, dass die älteren Versionen unter demselben Link erreichbar bleiben.
  • Das GitHub-Repo ist bereit. Wer möchte, kann dort für ihren/seinen Metadatenstandard schon vollständige Beispiele ablegen und aus dem Wiki darauf verlinken. Systematisch wird das im Rahmen von Versin 1.0 nicht erfolgen.
  • Informationselement "Access-Status"
    • Das an dritter Stelle empfohlene Vokabular OpenAIRE-Vokabular scheint keine URIs für die Werte bereitzustellen. Das macht die Modellierung besonders in den RDF-Metadatenstandards komplexer (was eigentlich in V1.0 noch nicht behandelt werden sollte) und steht außerdem zu den definierten Auswahlkritieren von Vokabularen, dass sie HTTP-URIs haben sollen. Steffi kontaktiert Friedrich zum Thema. Es soll geklärt werden, ob OpenAIRE wirklich keine URIs hat oder plant. Falls dem wirklich so ist, wird es vorerst aus der Empfehlungsliste gestrichen.
    • Es scheint wichtig, auch den Status "Hybrid Open Access" zu behandeln (Anregung Reinhold). Wenn die Arbeiten nach der VÖ von Version 1.0 weitergehen, sollen Vokabulare gesucht werden, mit denen das möglich ist.
  • Informationselement "Rechtehinweis/Lizenz"
    • Der Begriff "Vokabulare" ist der richtige Oberbegriff für creativecommons.org, rightsstatements.org, ...
    • Für die Metadatenstandards, in denen eine Unterscheidung zwischen Rechtehinweis und Lizenz erforderlich ist (mindestens KIM-RDF und METS), soll dieser zunächst nur implizit, über die Beispiele deutlich werden. Zu einem späteren Zeitpunkt soll die Definitionsseite erweitert werden um Erläuterungen, z.B. dass CC0 und CC Public Domain-Mark Rechtehinweise und keine Lizenzen sind (Vgl. DDB-Seiten).
    • Möglichst alle Metadatenstandards sollen Beispiele führen für
      • Lizenz: http://creativecommons.org/licenses/by/4.0/ (statt http://creativecommons.org/licenses/by-nc-sa/3.0/de/, was das Beispiel im Template war)

      • Rechtehinweis: http://rightsstatements.org/vocab/InC/1.0/
      • Rechtehinweis: http://creativecommons.org/publicdomain/mark/1.0/
      • Rechtehinweis: http://creativecommons.org/publicdomain/zero/1.0/
    • Beispiel-Ressourcen sollten möglichst real existieren. Wenn/Wo das nicht geht, wird gefakt (à la http://meineinstitution/ressource/123)   

  • MARC21: da eine endgültige Entscheidung über die Erweiterung von MARC21 frühestens im Mai zu erwarten ist, wird die Empfehlung 1.0 nur die Kategorien berücksichtigen, die geklärt sind.
  • JATS: Eine Seite mit Kerninformationen und Beispielen soll bis zur Deadline bereitgestellt werden.

3. Vorgehen zur Veröffentlichung

Die Veröffentlichung soll Ende November, vor der AG-Sitzung am 26. November erfolgen.

Keine TelKo mehr. Restliche Absprachen per Mailingliste. Sollte es Gesprächsbedarf geben, können die "Betroffenen" kurzfristig einen Telko-Termin machen.

  • Stefanie beginnt am 21. November, die einzelnen Empfehlungsseiten der Metadatenstandards zu reviewen und ggf. Kontakt zu den Zuständigen aufzunehmen
  • Veröffentlichungsdatum ist dann der 23. November
    • Stefanie erklärt die Version für fertig
    • André setzt den Veröffentlichungsstatus auf den Seiten auf "veröffentlicht"
    • Stefanie stellt aus den Wikiseiten ein Dokument zusammen, das dann von der DINI-Geschäftsstelle für die PDF-Publikation als DINI-Schrift verarbeitet wird

4. Planung Öffentlichkeitsarbeit

3.1 Direkt nach VÖ

  • Stefanie schickt Infomail an KIM-Mailinglisten. (Inetbib später, wenn DINI-PDF zusätzlich zitierfähig? [Nachträgliche Frage von Jana] Dann sicher auch DINI-Mailingliste durch DINI-Geschäftsstelle)
  • JedeR, der möchte, twittert. DNB und DDB möglichst auch offiziell (kann dann retweetet werden)
  • (Über DDB pro darauf hinweisen?[nachträgliche Frage von Steffi])

3.2 Bibliothekskongressvorbereitungen

  • Die öffentliche Arbeitssitzung ist als Nachrücker-Veranstaltung angemeldet. Wir bekommen Mitte November Bescheid, ob sie stattfinden kann. Weitere Info und weitere Planung dann über Mailingliste.

5. ToDos

  •  Hohmann, Andre: Änderungen der Seitentitel: "DataCite Schema (Empfehlung 1.0)", "DCMES (Empfehlung 1.0)"
  •  Alle sorgen dafür das bei "Rechtehinweis/Lizenzen" die oben festgelegten 4 Beispielwerte in ihren Beispielen vorkommen (METS erledigt)
  •  Hohmann, Andre: Ändert "Einleitung" in "Definition" in allen Metadatenstandards (Abschnitte: Access Status, Rechteinformation/Lizenz, )
  •  Hohmann, Andre: Löscht die Zwischenebene Empfehlung für Rechteinformationen in Metadaten
  •  Heuvelmann, Reinhold: Passt MARC-Seite an offizielle Standards an
  •  Diebel, Cornelia erstellt JATS-Empfehlung 1.0-Seite
    JATS (Empfehlung 1.0)
  •  Rühle, Stefanie befragt Unbekannter Benutzer (summannf) bezüglich OpenAIRE-Vokabular (Auflösbarkeit des URI). Davon abhängig wird es in die Empfehlung aufgenommen oder die Aufnahme verschoben (Info/Absprache über Mailingliste)
    -> das info-repo-Vokabular wird nicht mehr empfohlen und alle diesbezüglichen Beispiele wurden gelöscht. Grund dafür ist, dass in der nächsten Version der OpenAIRE guidelines COAR referenziert wird. 

...

6. Inhaltliche Themen und Erweiterungen für die nächste Versionen

...

  • Rechteinhaber
  • Zeitliche Gültigkeit
  • Vergriffene Werke
  • Embargo
  • Hybrid Open Access
  • Vollständige Beispiele im Github-Repo