search

dini-ag-kim / hs-oer-lom-profil

LOM for Higher Education OER Repositories
https://w3id.org/kim/hs-oer-lom-profil/latest/
3 stars 1 forks source link

Ergänze Angabe zum maximalen Vorkommen bei Mehrfachelementen #8

Closed acka47 closed 4 years ago

acka47 commented 4 years ago

Siehe

mic-men commented 4 years ago

Die Angaben zum max. Vorkommen kann ich noch überarbeiten. Die englische Formulierung ist da immer so:

"The element occurs 0 or more times within the element. The smallest permitted maximum is 10 instances within the element."

Wie sagt man das vernünftig in deutsch, so dass es verständlich ist: "smallest permitted maximum"? Auch im englischen muss es nochmal erläutert werden (können wir auch machen, intuitiv klar wäre besser):

"The reader's attention is called to LOM's "smallest permitted maximum" concept. Implementations are not guaranteed to handle more than a smallest permitted maximum declared for a given element or string length."

Ich bitte um Vorschläge einer guten deutschen Übersetzung. @sebastian-meyer , Du hast Dich doch schon intensiv mit der Übersetzung in Spezifikationen beschäftigt?

mic-men commented 4 years ago

Dank an Frank für die hilfreichen Annotationen! Zuerst, was ich nicht ändern möchte:

Jetzt aber zu den anderen Punkten:

sebastian-meyer commented 4 years ago

Ich kenne es aus anderen Standards so, dass zwischen Spezifikation und Implementierungsdetails unterschieden wird. Konkret würde das heißen, dass innerhalb des normativen Teils der Spezifikation - also bei der Definition des jeweiligen Elements - die tatsächlich erlaubte Anzahl genannt wird (also "0 oder mehr" ohne Maximum). Außerdem würde man dort auf einen eigenen Abschnitt "Implementierung" verweisen, in dem dann definiert wird, dass implementierende Systeme für bestimmte Felder mindestens ein bestimmtes Limit unterstützen müssen (also "mindestens 10 Iterationen").

Die Unterscheidung finde ich wichtig, weil sie ja unterschiedliche Zielgruppen betrifft: Als Metadaten-Erzeuger ist für mich nur wichtig zu wissen, dass ich prinzipiell beliebig viele <format> angeben kann. Als Implementierer eines technischen Systems, das diese Metadaten verarbeiten soll, muss ich außerdem wissen, dass das System mindestens 10 verschiedene <format> interpretieren können muss.

(Wobei ich eine solche Angabe generell etwas antiquiert finde. Heutzutage sollte ein technisches System in der Lage sein, ein beliebig oft vorkommendes Metadatenfeld auch beliebig oft interpretieren zu können. In der Praxis ist die Anzahl ja trotzdem immer endlich.)

mic-men commented 4 years ago

Im ersten Moment fand ich das Argument der Antiquiertheit einleuchtend, es sollte für ein technisches System tatsächlich kein Problem sein, diese Metadaten zu interpretieren. Nach etwas Nachdenken ist mir aber aufgegangen, dass es noch eine weitere Seite gibt. Wasmuss dem Nutzer präsentiert werden? Und da ist das Design häufig so, dass aus verschiedenen Gründen eben nicht beliebig viele Werte für manche Metadaten angezeigt werden. Z.B. ist ist häufig nur 1 Titel vorgesehen. Ein System, das nur 1 Titel anzeigt, wäre doch dann nicht mehr konform zum Profile, oder? Insofern ist für mich die Separation der Implementierung auch nicht einleuchtend. Als Anbieter sollte ich doch schon berücksichtigen, welche meiner Angaben auf jeden Fall interpretiert werden, oder? Und was gehörte in einen solchen Abschnitt "Implementierung" noch hinein? Andererseits, wenn in der Praxis sowieso jedem überlassen bleibt, was er überhaupt nutzt - was mir realistisch erscheint -, dann ist eine solche Angabe wirklich überflüssig, aber nicht aus dem Argument heraus, dass es für technische Systeme prinzipiell kein Problem wäre, alle Daten zu interpretieren. Aber dann verstehe ich auch nicht richtig das Konzept hinter "smallest permitted maximum".

Ich bitte um Kommentare und Meinungen. Wenn keine kommen, werde ich die meisten Beschränkungen fallen lassen und einfach nichts in dieser Hinsicht hineinschreiben.

sebastian-meyer commented 4 years ago

Ich finde es nicht richtig, in einem Anwendungsprofil für einen Datenstandard Anforderungen an deren Präsentation oder Weiterverarbeitung zu stellen. Daten sollten immer systemagnostisch sein, d. h. sie sollten die zu transportierenden Informationen bestmöglich strukturieren und höchstens auf bestimmte Anwendungszwecke (aber nicht konkrete Lösungen) zugeschnitten sein.

Deshalb würde ich Implementierungsempfehlungen idealerweise nicht in die Spezifikation für das Datenformat stecken - und wenn doch, dann zumindest deutlich vom normativen Standard getrennt in Form eines rein informativen Abschnitts. (In ReSpec kann man informative Absätze übrigens mit der HTML-Klasse informative kennzeichnen.)

Langer Rede kurzer Sinn: Ich stimme dir zu und würde die Beschränkungen auch einfach weglassen! ;)