[dini-ag-kim-lizenzen] Änderungen an den Empfehlungen-Seiten

Thu Oct 25 09:48:04 CEST 2018

Liebe Jana,

bezüglich Kernelement/Informationselement sollten wir überlegen, eine andere Bezeichnung zu wählen, weil aus meiner Sicht beide Interpretationen nicht so recht passen. Wir wollen damit ja die Bereiche (Access Status, Lizenz, Rechteinhaber, ...) beschreiben, für die wir Lösungen in den Metadatenstandards vorschlagen:

https://wiki.dnb.de/pages/viewpage.action?pageId=140645769

Diese hatten wir von den Use Cases abgeleitet.

Bezüglich des Satzes zur Weiterentwicklung des Wikis: Ich lösche den Satz und überlege mir eine ausführliche Beschreibung der Struktur der Empfehlung. Ich denke, dass spätestens mit den ersten weiteren Versionen der Metadatenstandards Fragen bezüglich der Struktur der Empfehlungen auftreten werden.

Viele Grüße

André

________________________________
Von: dini-ag-kim-lizenzen <dini-ag-kim-lizenzen-bounces at lists.dnb.de> im Auftrag von Hentschke, Jana <J.Hentschke at dnb.de>
Gesendet: Mittwoch, 24. Oktober 2018 14:24
An: 'Informationsaustausch der DINI AG KIM Lizenzen Gruppe'
Betreff: Re: [dini-ag-kim-lizenzen] Änderungen an den Empfehlungen-Seiten

Lieber André, liebe Gruppe,

> 1 Kernelement/Informationselement

nach meiner Interpretation der Begrifflichkeiten sind das zwei leicht unterschiedliche Dinge:

„Informationselement“ steht für die kleinste inhaltlich-strukturelle Einheit, mit der wir uns beschäftigen. Wenn es nur um MARC ginge, könnten wir stattdessen von „Feldern“ reden, wenn es nur XML-Formate wären, von „XML-Elementen“, ... Aber wir brauchen ja einen Begriff, der alles eint.

„Kernelement“ verwenden wir zumindest in den KIM RDF-Empfehlungen so: die Kernelemente sind die, die als Pflicht in einer jeden Mindestbeschreibung empfohlen werden, da zu sein. Im Gegensatz zu den Elementen aus den „Erweiterten Empfehlungen“ die „nice-to-have“/“bei Bedarf“ sind.
Haben wir uns denn hier bei den Rechteinformationen aktiv dafür entschieden, diese Abstufung zu machen? Ich persönlich könnte mir auch gut vorstellen, sie hier nicht zu machen (weil das Thema „Rechteinformationen“ inhaltlich ja eh schon sehr eng gesteckt ist und wir irgendwie keinen organisatorischen Rahmen haben, in dem etwas „Pflicht“ sein könnte ...)

Falls unsere Diskussion dabei rauskommt, dass wir kein „Kern“ brauchen, bin ich dafür, alles „Informationselement“ zu nennen. Falls „Kern“ sein soll, müsste es m.E. konsequent heißen „Informationselemente“ und „Kerninformationselemente“.

> Außerdem ist mir in der Einleitung folgender Satz aufgefallen:

>

> Die Empfehlungen sind auf diesen Wikiseiten ein lebendes Dokument, d.h. neue Erkenntnisse werden regelmäßig in die Seiten eingearbeitet.

Ah, gut aufgepasst! Den Satz hatte ich im Einleitungsentwurf mal vorgelegt, weil ich unseren Plan a) zunächst in etwas so verstanden hatte und b) die Diskussion anregen wollte, wie genau es von statten gehen soll (die dann irgendwie nicht passiert ist ;)

Der Satz müsste m.E. entweder ersetzt werden durch eine Beschreibung unseres Versionierungsvorgehens oder gestrichen werden.

Besten Gruß von
Jana

Von: dini-ag-kim-lizenzen [mailto:dini-ag-kim-lizenzen-bounces at lists.dnb.de] Im Auftrag von Hohmann, Andre
Gesendet: Mittwoch, 24. Oktober 2018 10:51
An: Informationsaustausch der DINI AG KIM Lizenzen Gruppe <dini-ag-kim-lizenzen at lists.dnb.de>
Betreff: Re: [dini-ag-kim-lizenzen] Änderungen an den Empfehlungen-Seiten

Liebe KollegInnen,

beim Anpassen der Empfehlungs-Seiten sind mir zwei Dinge aufgefallen:

1 Kernelement/Informationselement

Wir nutzen zwei Benennungen für die Kernelemente:

  *   Informationselement
https://wiki.dnb.de/pages/viewpage.action?pageId=140645986
  *   Kernelement
https://wiki.dnb.de/pages/viewpage.action?pageId=140645769

Mir ist es eigentlich egal, welche Benennung genutzt wird, habe aber den Eindruck, dass "Kernelement" n unseren Gesprächen häufiger verwendet wurde.

2 Einleitungstext:

Außerdem ist mir in der Einleitung folgender Satz aufgefallen:

  *   Die Empfehlungen sind auf diesen Wikiseiten ein lebendes Dokument, d.h. neue Erkenntnisse werden regelmäßig in die Seiten eingearbeitet.

Dies sollte noch mit den Versionierungen präzisiert werden. Es sollte nicht so verstanden werden, dass wir einfach die Seite inhaltlich anpassen.

Was meint dazu?

Viele Grüße

André

________________________________
Von: dini-ag-kim-lizenzen <dini-ag-kim-lizenzen-bounces at lists.dnb.de<mailto:dini-ag-kim-lizenzen-bounces at lists.dnb.de>> im Auftrag von Hohmann, Andre <Andre.Hohmann at slub-dresden.de<mailto:Andre.Hohmann at slub-dresden.de>>
Gesendet: Montag, 22. Oktober 2018 12:58
An: Informationsaustausch der DINI AG KIM Lizenzen Gruppe
Betreff: Re: [dini-ag-kim-lizenzen] Änderungen an den Empfehlungen-Seiten

Liebe Jana,

es ist wirklich am besten, wenn wir das morgen besprechen.
Vielleicht habe ich auch falsche Vorstellungen, weil ich an der letzten Telefonkonferenz nicht teilgenommen habe.
Ich hatte mich an den Vorschlägen in der Tabelle orientiert:
https://docs.google.com/spreadsheets/d/11x_5izs6NJfd4D_cLYrB0k3U5vPoaNQXOMDZaKW3U3g/edit#gid=414802577

Bei den anderen Formaten stellt sich die Frage nicht, weil es kein Feld für erweiterte Kommentare gibt. In MODS habe ich in den Beispielen die codierte Benennung angegeben.

Morgen sind wir dann hoffentlich schlauer.

Viele Grüße
André

Von: dini-ag-kim-lizenzen [mailto:dini-ag-kim-lizenzen-bounces at lists.dnb.de] Im Auftrag von Hentschke, Jana
Gesendet: Montag, 22. Oktober 2018 12:19
An: 'Informationsaustausch der DINI AG KIM Lizenzen Gruppe' <dini-ag-kim-lizenzen at lists.dnb.de<mailto:dini-ag-kim-lizenzen at lists.dnb.de>>
Betreff: Re: [dini-ag-kim-lizenzen] Änderungen an den Empfehlungen-Seiten

Lieber André,

> Um dem Dilemma zu entkommen, schlage ich Folgendes vor:

> - ich füge in dem vorhandenen "comment"-Feld des Rights Statements den gesamten Text ein

> - ich beschreibe explizit, dass das "comment"-Feld optional verwendbar ist, wenn es aber genutzt wird, eine offizielle Beschreibung eingefügt werden sollte

> - ich erstelle ein weiteres Beispiel ohne das "comment"-Feld

Ich nehme an, das sind Alternativen B-)

Ich bespreche mich heute Nachmittag mit Steffi und kümmere mich dann um die Anpassung der Seite. Wir können dann auch in der TelKo noch drüber reden, aber vorweg schon mal:
Die Situation erscheint mir kurios (und ich kann nicht mehr so ganz nachvollziehen, wie sie entstanden ist): wenn wir im Sinne der bisherigen KIM-Empfehlungen-Tradition handelten, würden wir gar nichts außer einer URI-Angaben empfehlen (*Linked* Data ... ). Ich hatte es so verstanden, dass es aus der Datenaustauschrealität und den anderen Formaten heraus notwendig ist, Platz für einen Text zu schaffen. Witzig, dass das KIM-Profil jetzt das einzige „Format“ sein soll, wo das überhaupt geht. Das sollte Steffi sich dann noch mal ansehen.

Besten Gruß von
Jana

Von: dini-ag-kim-lizenzen [mailto:dini-ag-kim-lizenzen-bounces at lists.dnb.de] Im Auftrag von Hohmann, Andre
Gesendet: Freitag, 19. Oktober 2018 18:27
An: Informationsaustausch der DINI AG KIM Lizenzen Gruppe <dini-ag-kim-lizenzen at lists.dnb.de<mailto:dini-ag-kim-lizenzen at lists.dnb.de>>
Betreff: Re: [dini-ag-kim-lizenzen] Änderungen an den Empfehlungen-Seiten

Liebe Jana,

vielen Dank für die Blumen, aber ich muss zugeben, dass hier ein Eigeninteresse motivierend wirkt ;-)

Deine Frage ist durchaus berechtigt und wir hatten auch schon umfangreichere Beschreibungen/Empfehlungen zur Anwendung des Vokabulars für die Lizenzen und den Access Status. Wegen der unterschiedlichen Anforderungen in den Institutionen (Anzeige, maschinelle Auswertung, ...) haben wir vor ausführlichen Empfehlungen abgesehen - es sollte nur darauf geachtet werden, dass offizielle Beschreibungen/Benennungen verwendet werden.

Da zudem die Belegung von den Metadatenformaten abhängt - ein "comment"-Feld ist nur in wenigen Formaten verfügbar - müsste zum Beispiel unter Lizenzen/Rechtehinweis eine Metadatenformat-abhängige Empfehlungen formuliert werden. Das empfinde ich als uneleganter.

Außerdem hatte ich die Rights Statements bei der Erstellung der Seiten nicht berücksichtigt und somit war mir die sehr umfangreiche Beschreibung nicht bewusst. Darüber bin ich erst bei Erstellung des Beispiels gestolpert, was aber sehr gut ist, weil ansonsten die Anwender darüber stolpern.

Hier kann ich mir vorstellen, das "comment"-Feld als optional zu empfehlen, aber trotzdem ein Beispiel zu geben, wie es aussehen könnte.

Vermutlich habe ich hier auch aus einer Mücke einen Elefanten gemacht.

Um dem Dilemma zu entkommen, schlage ich Folgendes vor:

- ich füge in dem vorhandenen "comment"-Feld des Rights Statements den gesamten Text ein

- ich beschreibe explizit, dass das "comment"-Feld optional verwendbar ist, wenn es aber genutzt wird, eine offizielle Beschreibung eingefügt werden sollte

- ich erstelle ein weiteres Beispiel ohne das "comment"-Feld

Ich denke, dass damit klar ist, wie das Feld zu verwenden ist.

Was meinst Du? Wir können das auch am Dienstag besprechen - am Telefon ist das vielleicht besser zu erklären als durch E-Mail.

Viele Grüße und ein schönes Wochenende

André

Von: dini-ag-kim-lizenzen <dini-ag-kim-lizenzen-bounces at lists.dnb.de<mailto:dini-ag-kim-lizenzen-bounces at lists.dnb.de>> im Auftrag von Hentschke, Jana <J.Hentschke at dnb.de<mailto:J.Hentschke at dnb.de>>
Gesendet: Freitag, 19. Oktober 2018 11:05
An: Informationsaustausch der DINI AG KIM Lizenzen Gruppe
Betreff: Re: [dini-ag-kim-lizenzen] Änderungen an den Empfehlungen-Seiten

Danke André! Du hältst den Laden echt zusammen und machst, dass es gut wird. ;)

Vorweg: ich bin an der RDF-Seite noch dran.

Derweil aber schon mal eine Vorgehens-Verständnis-Frage:

> KIM-RDF [5]
> Hier bin ich nicht sicher, welchen "comment" man eintragen sollte. Die ganze Beschreibung, oder nur den ersten Satz?

Wieso entsteht die Situation, hier auf Ebene der einzelnen Metadatenformat-Seiten ein (nachgelagertes) Informationselement definieren zu müssen? An der befragten Stelle "comment" befasst sich die KIM-RDF-Empfehlung mit den Stellen

  „Access-Status“ > „Beschreibung“
und
   „Rechtehinweis/Lizenz“ > „Beschreibung“

aus unserem Template. Dort stehen die Verwendungshinweise „Textliche Beschreibung der Verfügbarkeit.“ und „Textliche Beschreibung der Nutzungsbedingungen.“

Sollten wir die Elemente „URI“, „Bezeichnung/Code“, „Quelle/Authority, aus der der Wert kommt“ und „Beschreibung“ nicht auch global erläutern und dann auf den Unterseiten einbinden?

Besten Gruß von
Jana

Von: dini-ag-kim-lizenzen [mailto:dini-ag-kim-lizenzen-bounces at lists.dnb.de] Im Auftrag von Hohmann, Andre
Gesendet: Donnerstag, 18. Oktober 2018 18:30
An: Informationsaustausch der DINI AG KIM Lizenzen Gruppe <dini-ag-kim-lizenzen at lists.dnb.de<mailto:dini-ag-kim-lizenzen at lists.dnb.de>>
Betreff: [dini-ag-kim-lizenzen] Änderungen an den Empfehlungen-Seiten

Liebe Kolleginnen und Kollegen,

ich habe noch einige formale und inhaltliche Änderungen an den Seiten der Metadatenformate [1] unserer ersten Version der Empfehlungen vorgenommen.

Formale Änderungen

Ich habe Stefanies Formatierung der METS-Seite [2] auf allen Metadatenformat-Seiten angewendet:

  *   Änderung der Überschrift "Felder und Unterfelder" zu "Empfehlung"
  *   Einfügen der TIPP-Box als Einleitung für den Abschnitt "Empfehlung"
  *   Änderung der Hinweis-Box in der Einleitung von "Access Status" und "Rechtehinweis/Lizenz" zu Info-Box
Außerdem habe ich auf allen Seiten unter [1] den Abschnitt "Rechteinhaber" entfernt und zuvor die Inhalte der Seite in "03 Empfehlungen" der jeweiligen Metadatenformate in unserem Arbeitsbereich [3] gesichert.

Inhaltliche Änderungen
Da neben der Verwendung von Creative Commons-Lizenzen auch die Verwendung der "Rights Statements" empfohlen wird, habe ich Beispiele für die "Rights Statements" für jedes Metadatenformat erstellt. Zudem habe ich die Texte zur Beschreibung der Elemente/Attribute/Properties angepasst, weil sich diese bisher nur auf die CC-Lizenzen bezogen haben.

Dies führte zusätzlich zu einigen weiteren Änderungen in den Beschreibungen einzelner Metadatenformate:

METS [2]
Da es sich bei "Rights Statements" nicht um Lizenzen handelt, muss in PREMIS der Wert in dem Element "rightsBasis" von "license" zu "copyright" geändert werden. Als Konsequenz müssen auch die Unterelemente an "copyright" angepasst werden. Dies habe ich in dem Beispiel durchgeführt und unter der Element-Beschreibung (Empfehlung) die neuen Elemente beschrieben.

@Stefanie: Kannst Du diese Änderungen prüfen und bestätigen, beziehungsweise Korrekturen vorschlagen/durchführen?

MARC [4]
In 540 $2 wird eine Kurzform der Authority der jeweiligen Lizenz eingetragen. Im Fall der Creative Commons Lizenzen "cc". Dies gilt natürlich nicht für die Rights Statements. Für diese Rechtehinweise habe ich "rs" gewählt.

@Reinhold: Kann man das machen, oder muss das bestätigt werden? Ist es besser, wenn das Unterfeld nicht belegt wird?

KIM-RDF [5]

Hier bin ich nicht sicher, welchen "comment" man eintragen sollte. Die ganze Beschreibung, oder nur den ersten Satz? Außerdem bin ich unsicher, ob mein Beispiel formal korrekt ist.

@Jana: Kannst Du das prüfen?

Ich denke, dass dies alle Änderungen sind, die ich vorgenommen habe. Bitte prüft sie vor unserer Telefonkonferenz, so dass wir sie übernehmen/anpassen/rückgängig machen können.

Viele Grüße
André

[1] https://wiki.dnb.de/pages/viewpage.action?pageId=140645802

[2] https://wiki.dnb.de/pages/viewpage.action?pageId=140645913

[3] https://wiki.dnb.de/display/DINIAGKIM/03+Metadatenformate

[4] https://wiki.dnb.de/pages/viewpage.action?pageId=141265054

[5] https://wiki.dnb.de/pages/viewpage.action?pageId=141265009

--
André Hohmann

Sächsische Landesbibliothek –
Staats- und Universitätsbibliothek Dresden (SLUB)
Abteilung Bestandsentwicklung, Leitungsreferat
01054 Dresden
Besucheradresse: Zellescher Weg 18, 01069 Dresden
Tel.: +49 351 4677 320
E-Mail: andre.hohmann at slub-dresden.de<mailto:andre.hohmann at slub-dresden.de>

www.slub-dresden.de<http://www.slub-dresden.de>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dnb.de/pipermail/dini-ag-kim-lizenzen/attachments/20181025/62397a1c/attachment-0001.html>