[dini-ag-kim-lizenzen] "MARC" ueberarbeitet (war: Empfehlung Access Status: "info-repo-Vokabular")

Hohmann, Andre Andre.Hohmann at slub-dresden.de
Fri Nov 23 15:52:52 CET 2018


Lieber Reinhold,


sehr schön, vielen Dank. Das sieht sehr gut aus - aber eine Sache habe ich noch ;-)


Bezüglich 1: Es wird "Open Access", "Restricted access" und "Closed Access" genutzt. Hier würde ich "Restricted access" anpassen zu "Restricted Access". Passt Dir das?


Bezüglich der Links fällt mir leider keine Lösung ein, ohne dass die Einheitlichkeit darunter leidet. Man kann zwar die Syntaxhervorhebung ändern, aber alle Möglichkeiten, die dann kein Link erzeugen, verwenden unterschiedliche Farben, was auch wieder ablenkt. Ich bin aber unsicher, was am Ende verwirrender ist:

- ein falscher Link

- eine falsche Formatierung im Metadatenstandard


Ich überlasse Dir die Entscheidung - vermutlich ist das praktisch nicht relevant.


Viele Grüße und ebenfalls ein schönes Wochenende

André




________________________________
Von: dini-ag-kim-lizenzen <dini-ag-kim-lizenzen-bounces at lists.dnb.de> im Auftrag von Heuvelmann, Reinhold <R.Heuvelmann at dnb.de>
Gesendet: Freitag, 23. November 2018 14:41
An: Informationsaustausch der DINI AG KIM Lizenzen Gruppe
Betreff: Re: [dini-ag-kim-lizenzen] "MARC" ueberarbeitet (war: Empfehlung Access Status: "info-repo-Vokabular")

Lieber André,

danke fuer Deine Fragen.  Ich habe die Seite
https://wiki.dnb.de/pages/viewpage.action?pageId=141265054
erneut ueberarbeitet (fristgerecht ;-) ).

Bei den Formulierungen habe ich so gut es geht das „eingetragen“ vermieden, weil in MARC eher nicht eingetragen, sondern eher „transportiert“ oder „geliefert“ oder neutraler „verwendet“ wird.


> 1 Sollten die Benennungen in $a immer groß geschrieben werden? Dann würde ich noch "Restricted Access" anpassen.

Ich hatte zuvor die Schreibweise des Vokabulars übernommen, bei COAR ist die Benennung immer klein geschrieben. Gegebenenfalls sollten wir das dann in allen Metadatenstandards angleichen. Mir ist ja die Verwendung der Original-Angabe am liebsten, so spart man sich Erläuterungen, weshalb Werte angepasst werden.



rh: In MARC ist es ueblich, dass ein erstes Unterfeld $a im Feld mit Grossschreibung begonnen wird (ein Feld wird als Satz wahrgenommen (und leider deswegen manchmal auch noch mit einem Punkt abgeschlossen)).  Das ist jetzt in allen Beispielen so durchgehalten.



> 2 Kann das Spatium vor $2 entfernt werden? Ich denke, das kommt aus den zugehörigen Empfehlungen, in denen generell vor den Unterfeldern ein Spatium eingefügt ist. Ich würde es hier zur Vereinheitlichung entfernen, will aber sicher stellen, dass es nicht einen anderen Grund dafür gibt, es stehen zu lassen.

rh: Tjaaa.  Real steht in MARC _kein_ Spatium.  Leider macht das Wiki (sichtbar erst bei Mouseover) mit seiner Intelligenz daraus den URL
http://purl.org/coar/access_right/c_abf2$2star
bzw.
http://purl.org/eprint/accessRights/OpenAccess$2star
, zieht also die Zeichenfolge „$2star“ dazu, was falsch ist.  Mein Blank war als Workaround gedacht.  Ich hab‘s jetzt mal ohne Blanks, um den Effekt zu zeigen. Wenn Du oder jemand eine gute Loesung ha(s)t, das zu umgehen, dann gerne.  Sonst wuerde ich die Blanks wieder einfuegen.

---

Wenn so weit ok, schliesse ich hiermit meine Arbeit an der Seite ab, und mache das Haekchen auf
https://wiki.dnb.de/display/DINIAGKIM/2018-10-23+-+Telefonkonferenz#id-2018-10-23-Telefonkonferenz-5.ToDos   :-)

Viele Gruesse, ein schoenes Wochenende allerseits

Reinhold


Von: dini-ag-kim-lizenzen [mailto:dini-ag-kim-lizenzen-bounces at lists.dnb.de] Im Auftrag von Hohmann, Andre
Gesendet: Sonntag, 18. November 2018 10:02
An: Informationsaustausch der DINI AG KIM Lizenzen Gruppe <dini-ag-kim-lizenzen at lists.dnb.de>
Betreff: Re: [dini-ag-kim-lizenzen] "MARC" ueberarbeitet (war: Empfehlung Access Status: "info-repo-Vokabular")


Lieber Reinhold,



vielen Dank für die Ergänzungen. Ich habe die Beispiele unter Access Status noch nach Open Access/Closed Access aufgeteilt. Ich befürchte, dass beide Beispiele in einem Codeblock suggerieren, sie gehörten zusammen. Außerdem habe ich Deinen Hinweis auf die möglichen Änderungen der Felder 506 und 540 nach oben verschoben. Aus meiner Sicht sollte dies bei der Feld-Beschreibung stehen und nicht bei den Beispielen.



Bezüglich der Beispiele unter Access Status habe ich folgende Fragen:

1 Sollten die Benennungen in $a immer groß geschrieben werden? Dann würde ich noch "Restricted Access" anpassen.

Ich hatte zuvor die Schreibweise des Vokabulars übernommen, bei COAR ist die Benennung immer klein geschrieben. Gegebenenfalls sollten wir das dann in allen Metadatenstandards angleichen. Mir ist ja die Verwendung der Original-Angabe am liebsten, so spart man sich Erläuterungen, weshalb Werte angepasst werden.

2 Kann das Spatium vor $2 entfernt werden? Ich denke, das kommt aus den zugehörigen Empfehlungen, in denen generell vor den Unterfeldern ein Spatium eingefügt ist. Ich würde es hier zur Vereinheitlichung entfernen, will aber sicher stellen, dass es nicht einen anderen Grund dafür gibt, es stehen zu lassen.





Bezüglich der Verwendung der Lizenzangaben und Rechtehinweise habe ich eine Frage an alle:

Wir hatten uns ja darauf geeignet, keine Empfehlung für die verwendete Bezeichnung (codiert, Beschreibung, ...). In den Beispielen fände ich es gut, wenn einheitliche Werte vergeben werden, um zu demonstrieren, dass eine einheitliche Belegung die Konversion zwischen den Standards erleichtert.

Bei den CC-Lizenzen verwenden wir jetzt die codierte Form und die englische Kurzbezeichnung. Außerdem sind unterschiedliche Hinweise vorhanden:

  *   In dem MARC-Element <540 $a> wird zur Beschreibung der Lizenz oder des Rechtehinweises eine textliche Benennung, vorzugsweise die ausführliche Beschreibung der Lizenz oder des Rechtehinweises, verwendet. [1]
  *   In dem MODS-Element <accessCondition> (https://www.loc.gov/standards/mods/userguide/accesscondition.html) wird zur Beschreibung der Lizenz oder des Rechtehinweises immer eine offizielle Benennung (Codiert, Beschreibung, ...) eingetragen. [2]
  *   Zur Identifizierung eines Rechtehinweises sollte die EDM-Property edm:rights (http://www.europeana.eu/schemas/edm/rights) verwendet werden und in der Objektposition ein URI stehen, der durch die EDM-Class edm:WebResource (http://www.europeana.eu/schemas/edm/WebResource) definiert wird. [3]

Wenn das aus Eurer Sicht nicht so wichtig ist, kann ich damit auch leben. Ich wollte es jedoch angesprochen haben.

Viele Grüße
André

[1] https://wiki.dnb.de/pages/viewpage.action?pageId=141265054
[2] https://wiki.dnb.de/pages/viewpage.action?pageId=140645821
[3] https://wiki.dnb.de/pages/viewpage.action?pageId=145588452





________________________________
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 Effenberger, Claudia <C.Effenberger at dnb.de<mailto:C.Effenberger at dnb.de>>
Gesendet: Freitag, 16. November 2018 14:26
An: 'Informationsaustausch der DINI AG KIM Lizenzen Gruppe'
Betreff: Re: [dini-ag-kim-lizenzen] "MARC" ueberarbeitet (war: Empfehlung Access Status: "info-repo-Vokabular")

Lieber Reinhold,

ich finde die Seite sieht sehr gut strukturiert und verständlich aus. Bei den Beispielen für die Lizenz fehlt die Zwischenüberschrift „Beispiele“ (das habe ich ergänzt), sonst habe ich nichts anzumerken.

Viele Grüße,
Claudia


Von: dini-ag-kim-lizenzen [mailto:dini-ag-kim-lizenzen-bounces at lists.dnb.de] Im Auftrag von Heuvelmann, Reinhold
Gesendet: Freitag, 16. November 2018 13:45
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] "MARC" ueberarbeitet (war: Empfehlung Access Status: "info-repo-Vokabular")

Hallo,

> 3 MARC
> In MARC fehlen noch die Anpassungen an die aktuelle MARC-Spezifikation und dementsprechend die Anpassungen der Beispiele.
> @Reinhold: Könnest Du dies prüfen und anpassen? Bis zur Veröffentlichung ist es nicht mehr lange hin.

ich habe jetzt die MARC-Seite
https://wiki.dnb.de/pages/viewpage.action?pageId=141265054
gruendlich ueberarbeitet, den Text zur Einleitung, mit Links, bei den Feldern 506 und 540 habe ich Einiges angepasst, auch die Beispiele, und einen Hinweis angebracht, „there’s more to come“.

Bitte gerne gegenlesen.

---

Zusaetzlich habe ich bei der Definition
https://wiki.dnb.de/pages/viewpage.action?pageId=140645778
„hineingefunkt“, weil mir

„Der Rechtehinweis oder die Lizenz gibt an, ob und welche Restriktionen für die Nutzung einer Ressource durch einen Endnutzer oder eine Endnutzerin gelten.“

sprachlich weniger passend erschien als mein jetziger Vorschlag

„Der Rechtehinweis oder die Lizenz gibt an, ob und, wenn zutreffend, welche Restriktionen für die Nutzung einer Ressource durch einen Endnutzer oder eine Endnutzerin gelten.“

Aber darueber koennen wir sicher diskutieren ... .

Ich wuensche schon mal ein schoenes Wochenende, viele Gruesse

Reinhold


Von: dini-ag-kim-lizenzen [mailto:dini-ag-kim-lizenzen-bounces at lists.dnb.de] Im Auftrag von Hohmann, Andre
Gesendet: Montag, 12. November 2018 12:42
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] Empfehlung Access Status: "info-repo-Vokabular"

Liebe Kolleginnen und Kollegen,

Friedrich hat empfohlen, das „info-repo-Vokabular“ aus der Empfehlung zu entfernen, weil „bei den Access Rights das COAR Vokabular referenziert wird und das bisherige OpenAire Vokabular nicht mehr erwähnt wird“. Siehe dazu „DRAFT: OpenAIRE Guidelines for Literature Repository Managers v4 “ [1, 2]

Dementsprechend habe ich folgende Änderungen an unseren Empfehlungen vorgenommen:

1.       Anpassung der Empfehlung Access Status [3]: Entfernen des info-repo-Vokabulars.

2.       Anpassung der Beispiele in den Empfehlungen für alle Metadatenstandards: Entfernen der info-repo-Beispiele.

3.       Ergänzung des ToDo-Punktes im Protokoll der Telefonkonferenz

Bei der Umsetzung der Änderungen ist mir Folgendes aufgefallen, das von den jeweiligen Bearbeitern geprüft werden sollte:

1 EDM
In EDM wird keine Empfehlung für den Access Status formuliert, obwohl in dem Template [5] Beispiele aufgelistet sind.
@Francesca: Ist das beabsichtigt?

2 JATS
Die Texte in den Beispielen zu „COAR“ und „Eprints AccessRights Vocabulary Encoding Scheme“ entsprechen nicht den offiziellen Texten. Gegebenenfalls müssten die Texte oder die Überschriften der Beispiele angepasst werden.
Außerdem sollten die URI in dem Attribut „xlink:href“ hinzugefügt werden, um unserer Empfehlung zu entsprechen. Unter „Rechtehinweis/Lizenz“ wird das Attribut angewendet.
@Conny: Kannst Du Dir das noch einmal ansehen? Ich könnte es auch korrigieren, wenn es Dir lieber ist.

3 MARC
In MARC fehlen noch die Anpassungen an die aktuelle MARC-Spezifikation und dementsprechend die Anpassungen der Beispiele.
@Reinhold: Könnest Du dies prüfen und anpassen? Bis zur Veröffentlichung ist es nicht mehr lange hin.

Vielen Dank und viele Grüße
André

[1] https://openaire-guidelines-for-literature-repository-managers.readthedocs.io/en/latest/
[2] https://openaire-guidelines-for-literature-repository-managers.readthedocs.io/en/latest/field_accessrights.html#dci-accessrights
[3] https://wiki.dnb.de/pages/viewpage.action?pageId=140645773
[4] https://wiki.dnb.de/display/DINIAGKIM/2018-10-23+-+Telefonkonferenz#id-2018-10-23-Telefonkonferenz-5.ToDos
[5] https://docs.google.com/spreadsheets/d/11x_5izs6NJfd4D_cLYrB0k3U5vPoaNQXOMDZaKW3U3g/edit#gid=0




--
André Hohmann

Sächsische Landesbibliothek –
Staats- und Universitätsbibliothek Dresden (SLUB)
Abteilung Bestandsentwicklung und Metadaten, 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/20181123/0fb1098d/attachment-0001.html>


More information about the dini-ag-kim-lizenzen mailing list