ReSpec-Spezifikation ergänzen

[acka47]

Wir sind jetzt mit dem JSON Schema weit genug, um eine menschenlesbare Dokumentation zu ergänzen. Als Orientierung bietet sich https://github.com/dini-ag-kim/oer-service-card an.

[TobiasNx]

@acka47 : Ich bin gerade etwas verwirrt im Vokabular mit den type-Beschreibungen der einzelnen Elemente, ich glaube ich habe beim ersten Set-Up ein paar Mal

string[] (URL)

und

object[](URL)

geschrieben.
Aber das macht keinen Sinn.

Ich ergänze mal Steffen zudem als Revier für den PR.

[sroertgen]

Wollen wir beim learningResourceType und der audience so streng sein, dass wir nur Werte aus "unseren" Vokabularen zulassen?

Beim learningResourceTypewird momentan string[] und bei audience wird string[] (URI) in unserem Profil gefordert. Nach schema.org würde ja bei audience ein Objekt vom Typ Audience erwartet werden, bei learningResourceType wären Text oder DefinedTerm möglich. Mir stellen sich daher folgende Fragen:

• Wollen wir uns an diesen Stellen von schema.org lösen? Dann sollten wir das eventuell in der Spezifikation kennzeichnen(?)
• Wenn wir an beiden Stellen sagen, dass wir nur Werte aus unseren Wertelisten zulassen, dann sollte an beiden Stellen die gleichen Typen gefordert werden.
• Wenn wir nicht ganz so streng sein wollen und auch Werte außerhalb der Wertelisten zulassen, dann sollten wir nicht die URI fordern (oder?)
• Auf jeden Fall bin ich für eine starke Empfehlung der Nutzung der Wertelisten

Ich habe hier auch noch keine abschließende Meinung, wollte die Gedanken aber mal hier als Diskussionsgrundlage da lassen.

[acka47]

Beim learningResourceType wird momentan string[] und bei audience wird string[] (URI) in unserem Profil gefordert.

Müssen wir nochmal diskutieren. Wir könnten das hier durchaus lockern und auf die existierenden Vokabulare mit SOLL verweisen. (Kannst du noch ein Link zu eurem jetzigen Profil liefern?)

Nach schema.org würde ja bei audience ein Objekt vom Typ Audience erwartet werden, bei learningResourceType wären Text oder DefinedTerm möglich. Mir stellen sich daher folgende Fragen:

• Wollen wir uns an diesen Stellen von schema.org lösen? Dann sollten wir das eventuell in der Spezifikation kennzeichnen(?)

Was heißt hier "lösen"? schema.org ist ja gewollt unspezifisch, indem sie von "expected values" (im RDF rangeIncludes) sprechen. Das heißt, es ist intendiert, dass es auch anders genutzt wird. Von daher würde ich da nicht unbedingt näher drauf eingehen. Wir könnten höchstens mal überlegen, ob wir da nicht eine Anpassung in schema.org vorschlagen.

• Wenn wir an beiden Stellen sagen, dass wir nur Werte aus unseren Wertelisten zulassen, dann sollte an beiden Stellen die gleichen Typen gefordert werden.

Das verstehe ich nicht ganz. audience.json & learningResourceType.json sind doch bereits sehr ähnlich, nur, dass das eine einen Array erwartet (weil es eben mehrere Audiences geben kann) und das andere (zumindest momentan) nicht (weil die Typen sich weitestgehend auschließen, siehe #38.).

Wenn wir nicht ganz so streng sein wollen und auch Werte außerhalb der Wertelisten zulassen, dann sollten wir nicht die URI fordern (oder?)

Ich bin dafür, zumindest bei learningResourceType klar Werte aus maximal zwei Wertelisten zu fordern, analog zum LOM-Profil, siehe https://dini-ag-kim.github.io/hs-oer-lom-profil/latest/#das-element-learningresourcetype.

Bei Audience würde ich das auch erstmal setzen, es sei denn, das Vokabular ist nicht gut genug.

Auf jeden Fall bin ich für eine starke Empfehlung der Nutzung der Wertelisten

Da sind wir uns dann ja einig, ich bin wie gesagt sogar für eine MUSS-Empfehlung.

[acka47]

Bei Audience würde ich das auch erstmal setzen, es sei denn, das Vokabular ist nicht gut genug.

Auf jeden Fall sollten wir das dann aber auch mal in der dini-ag-kim-Organisation hosten, gerade wird ja noch auf eines verwiesen, das aus einem meiner Repos veröffentlicht wird:

https://github.com/dini-ag-kim/lrmi-profile/blob/09c10152b93075e5f81294df68b2e72df633ed28/draft/schemas/audience.json#L12

[sroertgen]

Nach schema.org würde ja bei audience ein Objekt vom Typ Audience erwartet werden, bei learningResourceType wären Text oder DefinedTerm möglich. Mir stellen sich daher folgende Fragen:

• Wollen wir uns an diesen Stellen von schema.org lösen? Dann sollten wir das eventuell in der Spezifikation kennzeichnen(?)

Was heißt hier "lösen"? schema.org ist ja gewollt unspezifisch, indem sie von "expected values" (im RDF rangeIncludes) sprechen. Das heißt, es ist intendiert, dass es auch anders genutzt wird. Von daher würde ich da nicht unbedingt näher drauf eingehen. Wir könnten höchstens mal überlegen, ob wir da nicht eine Anpassung in schema.org vorschlagen.

Du hast Recht, da habe ich schema zu strikt interpretiert. Von daher stimme ich Dir zu.

• Wenn wir an beiden Stellen sagen, dass wir nur Werte aus unseren Wertelisten zulassen, dann sollte an beiden Stellen die gleichen Typen gefordert werden.

Das verstehe ich nicht ganz. audience.json & learningResourceType.json sind doch bereits sehr ähnlich, nur, dass das eine einen Array erwartet (weil es eben mehrere Audiences geben kann) und das andere (zumindest momentan) nicht (weil die Typen sich weitestgehend auschließen, siehe #38.).

Das bezog sich darauf, dass momentan in der Spezifikation einmal string[] (URI) und einmal string[] gefordert wird:

<section data-dfn-for="learningResourceType">

### <dfn>learningResourceType</dfn>

Art des OER-Lernmittels. MUSS Wert aus dem Vokabluar der Hochschulcampus Ressourcentypen (https://w3id.org/kim/hcrt/) ODER den OpenEduHub Ressourcentypen (http://w3id.org/openeduhub/vocabs/learningResourceType/) sein.

<dl>
    <dt>Pflichtfeld</dt>
    <dd>ja</dd>
    <dt>Typ</dt>
    <dd>`string[]`</dd>
    <dt>Werte</dt>
    <dd>Wert aus <a href=" https://w3id.org/kim/hcrt/">Hochschulcampus Ressourcentypen</a> oder <a href="http://w3id.org/openeduhub/vocabs/learningResourceType/">OpenEduHub Ressourcentypen</a></dd>
</dl>

</section>

<section data-dfn-for="audience">

### <dfn>audience</dfn>

Zielgruppe(n) des Angebotes. MUSS einer *Educational Audience Role* von [[!LRMI]] entsprechen.

<dl>
    <dt>Pflichtfeld</dt>
    <dd>nein</dd>
    <dt>Typ</dt>
    <dd>`string[]` (URI)</dd>
    <dt>Werte</dt>
    <dd><a href="http://purl.org/dcx/lrmi-vocabs/educationalAudienceRole/">LRMI Educational Audience Roles</a></dd>
</dl>

</section>

Aber wenn ich dich richtig verstehe, steht string[] bei learningResourceType eh noch zur Diskussion.

Wenn wir nicht ganz so streng sein wollen und auch Werte außerhalb der Wertelisten zulassen, dann sollten wir nicht die URI fordern (oder?)

Ich bin dafür, zumindest bei learningResourceType klar Werte aus maximal zwei Wertelisten zu fordern, analog zum LOM-Profil, siehe https://dini-ag-kim.github.io/hs-oer-lom-profil/latest/#das-element-learningresourcetype.

Bei Audience würde ich das auch erstmal setzen, es sei denn, das Vokabular ist nicht gut genug.

Auf jeden Fall bin ich für eine starke Empfehlung der Nutzung der Wertelisten

Da sind wir uns dann ja einig, ich bin wie gesagt sogar für eine MUSS-Empfehlung.

Vielleicht können wir darüber (und auch über #38) einfach nochmal gemeinsam beim nächsten OER-Metadatengruppen-Treffen diskutieren. Ich kann mir gut vorstellen, dass eine Verpflichtung zur Angabe eines Wertes aus den Wertelisten sinnvoll ist, da sie zu Diskussionen über die Wertelisten führt und diese so aktuell gehalten werden.

[acka47]

Vielleicht können wir darüber (und auch über #38) einfach nochmal gemeinsam beim nächsten OER-Metadatengruppen-Treffen diskutieren. Ich kann mir gut vorstellen, dass eine Verpflichtung zur Angabe eines Wertes aus den Wertelisten sinnvoll ist, da sie zu Diskussionen über die Wertelisten führt und diese so aktuell gehalten werden.

+1, ich hab es auf die Agenda gesetzt: https://pad.gwdg.de/-DXGFNaMQ9qp-Uuc5HvoLQ?both#LRMI-Profil

[acka47]

Ansonsten werden wir ja #36 bald mergen. Wir sollten dann dieses allgemeine Ticket schließen und die einzelnen konkreten Fragen an spezifischen Tickets diskutieren.