JSON Schema zum learningResourceType anpassen

[kulla]

Beim Anpassen der Metadaten-API auf serlo.org ist mir folgendes aufgefallen: In der Definition im AMB von learningResourceType werden nur Werte aus HCRT oder OEHRT akzeptiert (siehe auch https://dini-ag-kim.github.io/amb/draft/schemas/learningResourceType.json). Dies macht Sinn für AMB, um die Vokabelliste einzuschränken.

In meinem Verständnis soll AMB immer die Freiheit geben, das eigene JSON im Sinne von schema.org / JSON-LD zu erweitern. Bei learningResourceType kann ich mir gut vorstellen, dass Nutzer:innen weitere Vokabulare nutzen wollen. Ist mein Verständnis richtig? Sollte dementsprechend im Standard aus "MUSS" ein "SOll" bei den Vokabularen werden? (Wenn möglich könnte beim JSON-Schema eine Warnung angezeigt werden, wenn die Werte nicht aus der Vokabularliste kommen)

[kulla]

Eine ähnliche Frage ergibt sich auch bei anderen Eigenschaften, die auf eine Vokabelliste verweisen wie about, conditionsOfAccess, audience oder educationalLevel.

[kulla]

Vorschlag: Wie wäre es, wenn wir vorschreiben, dass mindestens ein Element aus der Vokabelliste stammt? So ist garantiert, dass Konsumenten mindestens einen Wert haben, den sie nutzen können.

[oellers]

Vorschlag: Wie wäre es, wenn wir vorschreiben, dass mindestens ein Element aus der Vokabelliste stammt? So ist garantiert, dass Konsumenten mindestens einen Wert haben, den sie nutzen können.

Ich würde bei einer grundsätzlichen Aufhebung der verpflichtenden Nutzung der benannten Vokabulare eher zu einer anderen Lösung tendieren, da diese Bedingung sonst ggf. unnötig Komplexität einführt. Zur Not könnten Anwendungen einen Sammelwert in den Wertelisten mappen (bspw. "Sonstige", sofern verfügbar) oder alternativ "Keine Angabe" o.ä. nutzen, wenn unbekannte/ungewünschte Werte und/oder kein Mapping vorliegen.

MUSS > SOLL
Hier stellt sich dann ggf. die Frage, ob Vokabular-Empfehlungen dort einfach exemplarisch benannt werden oder wir diese außerhalb in einer Datenbank sammeln und in den Specs darauf verweisen? (Vokabular <> Feld)-Empfehlungen.

Einsatzszenarien AMB
Grundsätzlich wäre der Schritt (bzgl. aller erwähnten kontrollierten Vokabular) vllt. vor dem Hintergrund des Sinns/Zwecks des AMBs zu diskutieren. Was ist das Wünschenswerte einer AMB-Konformität von Diensten? Interoperabilität? Inwieweit würde diese noch bestehen, wenn kontrollierte Vokabulare nur empfohlen und nicht verpflichtend eingefordert würden?

[acka47]

Wir haben im heutigen Treffen beschlossen, mindestens einen Wert aus der jeweiligen Liste zu verlangen und zusätzliche Werte zu erlauben.

[lummerland]

Ich lasse mal noch einen Hinweis auf #243 da, betrifft ja das gleiche Feld und könnte ggf. hier gleich mit korrigiert werden :)

[kulla]

Fixed by #245