dini-ag-kim / amb Goto Github PK

Derzeit kann nur eine Sprache bei inLanguage ausgewählt werden, mehrsprachige Inhalte können dadurch nicht abgebildet werden.
Deswegen schlage ich vor, inLanguage ials array zu setzen.

Das Problem tritt bei URIs mit spitzen Klammern in HTTP-Header-Beispielen auf. Input Beispiel:

https://github.com/dini-ag-kim/lrmi-profile/blob/7fc3b7832281384598e37d3b9235aff127345113/draft/index.html#L204-L207

HTML-Sicht:

Es könnte sich um das ein ähnliches Problem wie https://github.com/w3c/respec/issues/3005 handeln, das Anfang Juli 2020 behoben wurde. Müssen wir das vielleicht was im DINI-Respec-Profil nachziehen, @sebastian-meyer ?

OER entstehen häufig im Rahmen von Projekten, an denen mehrere Institutionen beteiligt sein können. In NRW – und soweit ich weiß auch in Niedersachsen – wurde angedacht, diese Projekte zu erfassen, ihnen also eigene Identifier und strukturierte Beschreibungen zu geben. Eine Anforderung wäre dann, in einem Projekt entstandene OER mit dem Projekt zu verlinken, um schließlich Materialien – etwa in OERSI – nach Projekt filtern zu können.

Nehmen wir als Beispiel OER-Content.NRW, wo Materialien durch Konsortien aus mindestens drei Organisationen erstellt werden. Das Projekt "Einführung in die Betriebswirtschaftslehre" (mit der beispielhaften URI https://example.org/bwl-oer) wird etwa von einem Konsortium aus sieben Organisationen durchgeführt.

Materialien sollen nach Herkunftsprojekt gefiltert werden, d.h. ich muss das Material in den Metadaten irgendwo einem Projekt zuordnen. Dafür würde sich etwa sdo:producer anbieten (sdo:Project ist derzeit als ein Untertyp von Organization in pending eingetragen, so dass es hier auch mit dem für producer erwarteten Typ Organization passen würde):

{
    "@context": "http://schema.org",
    "id": "https://example.org/bwl-oer",
    "producer": [
        {
            "id": "http://example.org/bwl-projekt",
            "type": "Project",
            "name": "Einführung in die Betriebswirtschaftslehre"
        }
    ]
}

Besonders mit Blick auf OER-Kurse/Reihen/Playlists, deren Bestandteile wie Videos ebenfalls einzelne OERs sein können, denke ich, ist es sinnvoll auch diese Beziehung im Profil abbilden zu können.

schema.org hat folgende beiden Beziehungsklassen:
isPartOf und hasPart

Ich halte es für sinnvoll ein Element einzuführen, das sich allgemein auf die Zeit bezieht, die es in Anspruch nimmt. Da es sehr allgemein ist, kann man sowohl Kurse als auch Videos einbeziehen.

TTT HH MM SS

https://schema.org/timeRequired

Relevante Unterklassen 2. Ordnung von CreativeWork für die Type-enum-Liste ergänzen.

Vgl: https://schema.org/docs/full.html

Für die Labels aus kontrollierten Vokabularen – konkret der Fächerzuordnung in about und den Ressourcentypen in learningResourceType – ermöglicht das Schema bereits multilinguale Labels, siehe z.B. https://github.com/dini-ag-kim/lrmi-profile/blob/ee53cb9b6c343de07b7aa109a5318e2ab220d922/draft/examples/valid/tutory-example.json#L22-L33

Für andere Felder wird dies nicht unterstützt: name, description, publisher.name, creator.name.

Die Frage ist, ob das Profil konsequent Multilingualität in allen Label-Feldern unterstützen sollte.

Wir sollten in Abschnitt "3. Format und Bereitstellung" ergänzen, dass zusammen mit den Metadaten ein Link auf das genutzte Profile bzw. die genutzte Version angegeben werden MUSS.

Die Frage ist, wie wir das am besten ausdrücken. Eine fertige Spec für "Profile Negotiation" scheint es noch nicht zu geben, ich finde nur den Entwurf unter https://profilenegotiation.github.io/I-D-Profile-Negotiation/I-D-Profile-Negotiation. (@larsgsvensson, wird es da zukünftig etwas geben?). Im FAIR Signposting Profile ist etwas vom formats attribute die Rede, das hier evtl. benutzt werden könnte. Es gibt aber keine konkreteren Angaben, wie das benutzt werden soll.

Aus Abschnitt 2.1.1. Level 1 - A Minimal Set of Typed Links Pertaining to the Landing Page:

Many other bibliographic formats are in use that have text/plain, application/xml, application/json, or application/json+ld as MIME type. When providing metadata that describes the scholarly object using these MIME types, use the formats attribute on the link to convey, by means of an HTTP URI, the specific format of the metadata. For example, for metadata expressed as application/xml, provide the XML Namespace URI in the formats attribute.

(Wegen dem inkorrekten JSON-LD Mime Type habe ich übrigens schon ein Ticket gemacht.)

Wir sollten zumindest eine normative Referenz auf die JSON-LD Spec einbauen. Eine kleine Erläuterung in https://dini-ag-kim.github.io/lrmi-profile/draft/#format, dass die Anforderung nach dem JSON-LD-Format im Prinzip durch die context-Property erreicht wird, kann auch nicht schaden.

I think these are currently not validated as incorrect.

Analog zu reconciliation-api/specs@6b5985d

In ORCA wollen wir perspektivisch weitere Informationen zur Lizenz anpassen (z.B., dass sie zu einer Collection "CC-BY" gehört, in die wir alle CC-BY-Lizenzen unabhängig von Version und Land packen). Es gibt sicher auch andere Anwendungsfälle, wo so etwas nützlich ist, der einfachste wäre die Angabe eines Labels für die Lizenz in den Metadaten.

@TobiasNx , @mirjan-hoffmann und @acka47 haben deshalb beschlossen, dass die Objekt-Lösung die beste ist.

Es wird aber keinen Array geben, weil jede Ressource nur genau eine Lizenz haben soll.

JSON-LD weicht ja vom Standard-JSON dahingehend ab, dass Arrays in JSON geordnet sind, während sie in JSON-LD defaultmäßig ungeordnet sind (siehe json-ld/json-ld.org#12). Im ORCA-Kontext sollen allerdings Medientypen/learningResourceType nach Wichtigkeit geordnet werden und der erste Typ in der Liste für die Einordnung auf der Webseite genutzt werden.

Wenn das für andere Anwendungsfälle auch relevant ist, sollten wir im JSON-LD-Kontext entsprechend ergänzen:

{
  "learningResourceType":{
    "@container":"@list"
  }
}

Seit wir das Profil auch erweitern um sowohl OER als auch nicht OER abzubilden, sollten wir meiner Meinung nach auch die kostenfreie Nutzbarkeit/Zugang einer Ressource ausweisen. Es gibt Nicht-OER, die aber kostenfrei nutzbar sind. Das wird aber durch die gegenwärtigen Metadaten nicht abbildbar.

Daher mein Vorschlag, wir sollten dies in den Metadaten abbilden:

Möglich wäre zum Beispiel das Feld:

conditionsOfAccess (https://schema.org/conditionsOfAccess)

Für die Umsetzung bietet sich sdo:associatedMedia an:

A media object that encodes this CreativeWork. This property is a synonym for encoding.

Das Ergebnis könnte dann etwa so aussehen:

{
"@context": "https://w3id.org/kim/lrmi-profile/draft/context.jsonld",
  "id":"https://example.org/oer",
  "name":"Beispiel-OER",
  "description":"Beispiel-OER mit Download-Formaten HTML, Markdown und PDF",
  "associatedMedia":[
    {
      "type":"MediaObject",
      "contentUrl":"https://example.org/oer.md",
      "encodingFormat":"text/markdown"
    },
    {
      "type":"MediaObject",
      "contentUrl":"https://example.org/oer.html",
      "encodingFormat":"text/html"
    },
    {
      "type":"MediaObject",
      "contentUrl":"https://example.org/oer.pdf",
      "encodingFormat":"application/pdf"
    }
  ]
}

In der profile.md befindet sich folgendes:

<section id="type-example">
<h2>Beispiel</h2>
<pre class="example" data-include="draft/examples/valid/learningResourceType.json" data-include-format="text"></pre>
</section>

Leider wird das Beispiel aber nicht angezeigt, siehe https://dini-ag-kim.github.io/lrmi-profile/draft/#type-example oder beim okal gebauten http://localhost:8000/draft/#type-example.

Ich weiß nicht, ob es an der Art der Referenz liegt (auf eine Datei in einem Ordner auf einer anderen Ebene. Dagegen spricht, dass die Einbettung auch mit einem absoluten Link nicht funktioniert, weder mit /draft/examples/valid/learningResourceType.json noch mit /examples/valid/learningResourceType.json.

Deshalb glaube ich eher, dass das Problem daher rührt, dass die Referenz aus einem markdwon-Dokument kommt.

type ist ein array, aktuell ist aber learningResource noch nicht als fester Wert vorgegeben, da der Editor damit nicht umgehen kann.
Zudem soll learningResource idealerweise nicht nur als erster Wert erkannt werden. Ein array mit mehreren items, legt aber eine bestimmte Reihenfolge fest. Hier sollte versucht werden, mit anyOf etwas zu konstruieren.

Nach dem neuen Entwurf ist type: LearningResource als default gesetzt. Müsste dann nicht auch type als required vermerkt werden?

https://github.com/dini-ag-kim/lrmi-profile/blob/db896d8a4bb4f7e46745d5a6a2a15b40d34a8493/draft/schemas/schema.json#L13-15

Am besten geeignet dafür ist wahrscheinlich https://schema.org/keywords.

Es gibt drei relevante Datumsangaben in schema.org:

• dateCreated
• datePublished
• dateModified

Die Frage ist, welche wir nutzen

1. für die OER selbst,
2. für die Beschreibungsseite/Metadaten (siehe #6)

Momentan ist der Name "LRMI-Profil" (und die URI der aktuellen Version https://w3id.org/kim/lrmi-profile/latest/). Einige Dinge sprechen gegen diesen Namen:

• Das Profil basiert nicht vollständig auf LRMI, sondern nutzt auch SKOS und schema.org-Properties und -Klassen, die nicht bei LRMI auftauchen (z.bB. isPartOf, hasPart).
• Der Name ist nicht besonders sprechend. Besser wäre es, wenn der Name zumindest einige der folgenden Aspekte enthalten oder andeuten würde:
  • Es ist ein Metadatenprofil zur Beschreibung von Lehr- und Lernressourcen.
  • Es ist ein Profil für den deutschsprachigen Raum.
  • Es deckt die Bereiche Hochschule und allgemeinbildende Schulen ab.

Die momentane Zusammenfassung in der Spezifikation lautet entsprechend:

Ein Metadatenprofil für die Beschreibung von OER mit Fokus auf den deutschsprachigen Raum. Es basiert hauptsächlich auf [schema.org] bzw. Learning Resource Metadata Initiative [LRMI] und nutzt dazu Teile von Simple Knowledge Organization System [SKOS].

(Seitennotiz: Vielleicht sollten wir da das "OER" in der Zusammenfassung durch "Lehr- und Lernressourcen" übersetzen, da sich das Profil ja auch für die Beschreibung nicht-offener Ressourcen eignet.)

Bisher enthält das Schema als Datumsangabe für die Lernresource nur dateCreated. Oftmals ist diese Angabe gar nicht so leicht und ohnehin die Angabe des Publikationsdatums relevanter. Deshalb sollten wir zusätzlich datePublished ergänzen. (In ORCA.nrw wird datePublished auch benutzt werden.)

Im Rahmen der DINI-AG-KIM ist eine Werteliste erarbeitet worden, die für die Bezeichnung des Schulfaches in diesem Profil der DINI-AG-KIM verwendet werden sollte: https://github.com/dini-ag-kim/schulfaecher .

Diese sollte mit der projektspezifische Liste des OpenEduHub, die momentan als Referenz genannt wird, getauscht werden.

Während des KIM OER-AG Meetings wurde von @lechten vorgeschlagen, dass es ein Feld für Provenienz/provinence geben sollte, um eingebundene und verarbeitete OER zu referenzieren.

Theoretisch passt das bereits berücksichtigte Feld isBasedOn dafür.

A resource from which this work is derived or from which it is a modification or adaption.
(https://schema.org/isBasedOn)

Um aber Namen, Lizenzen, Urheber etc berücksichtigen zu können, brauchen wir ein Object-Array anstelle des String-Arrays.

Einige für Videoinhalte relevante Angaben werden bereits in #82 besprochen. Hier soll es um die videospezifischen Felder gehen. Hier zunächst mal eine Sammlung von video-relevanten Angaben mit Angabe von existierenden schema.org-Properties, wenn vorhanden:

• Spielzeit/Videolänge: sdo:duration
• Altersbeschränkungen: sdo:typicalAgeRange oder sdo:audience -> sdo:PeopleAudience -> sdo:requiredMinAge -> verschoben nach #140
• Untertitel: sdo:caption
• URL zum Einbetten eines Videos: sdo:embedUrl (erledigt mit #92)

Hier ein Beispiel als Diskussionseinstieg:

{
  "@context": [
    "https://w3id.org/kim/lrmi-profile/draft/context.jsonld",
    {
      "@language": "de"
    }
  ],
  "type": [
    "LearningResource",
    "MediaObject"
  ],
  "id": "https://mediathek.hhu.de/watch/93a697c4-cbe9-475d-b66b-0db6cebc35c0",
  "title": "Begrüßung zum Modul \"Rechnernetze, Datenbanken und Betriebssysteme\"",
  "duration": "PT19M17S",
  "caption": {
    "id": "https://example.org/subs.vtt",
    "type": "MediaObject",
    "encodingFormat": "text/vtt"
  },
  "creator": {
    "name": "Martin Mauve "
  },
  "image": "https://mediathek.hhu.de/thumbs/93a697c4-cbe9-475d-b66b-0db6cebc35c0/thumb_000.jpg",
  "audience": {
    "type": [ "PeopleAudience"],
    "requiredMinAge": 0
  },
  "typicalAgeRange": "16-99",
  "encoding":[
    {
      "type": "MediaObject",
      "encodingFormat":"video/mp4",
      "contentSize":"65MB",
      "contentUrl":"https://mediathek.hhu.de/download/93a697c4-cbe9-475d-b66b-0db6cebc35c0/mp4/v_1_100",
      "description": "hohe Qualität mit Abmessungen 1280 x 720 Pixel",
      "embedUrl":"https://mediathek.hhu.de/watch/93a697c4-cbe9-475d-b66b-0db6cebc35c0"
    },
    {
      "type": "MediaObject",
      "encodingFormat":"video/webm",
      "contentSize":"112MB",
      "contentUrl":"https://mediathek.hhu.de/download/93a697c4-cbe9-475d-b66b-0db6cebc35c0/webm/v_2_100",
      "description": "hohe Qualität mit Abmessungen 1280 x 720 Pixel"
    }
  ]
}

Zur Zeit werden GitHub Pages URLs sowohl im JSON Schema als auch im HTML benutzt, z.B. https://dini-ag-kim.github.io/lrmi-profile/draft/schemas/schema.json https://dini-ag-kim.github.io/amb/draft/schemas/schema.json. Dabei gibt es für jedes Schema auch eine W3ID, z.B. https://w3id.org/kim//lrmi-profile/draft/schemas/schema.json https://w3id.org/kim/amb/draft/schemas/schema.json .

Ich denke, wir sollten das umstellen. Das einzige Problem könnte sein, dass wegen dem redirect von w3id.org -> github.io JSON-Validatoren Probleme bekommen, was ich aber nicht glaube.

Hängt ab von/Depends on #69.

In an OERSI call today we noticed that one educational resource can have many pages describing it (e.g. it can have a separate description page in OERBW, OER-NDS and OERSI). To be able to express this in the data, we need to have an array with mainEntityOfPage.

Furthermore, in order to identify and distinguish the different sources for the different description pages, we should add a source for each description/metadata record using sdo:provider.

Momentan gibt es gemäß dem Schema keine Option, bei Urheber*innen eine affiliierte Organisation mitzugeben. Ein bedarf dazu hat sich im OERSI-Kontext ergeben. Es gibt in schema.org zwei Optionen dies zu ergänzen.

1. sourceOrganization

{
   "@context":"http://schema.org",
   "id":"https://www.oerbw.de/edu-sharing/components/render/aa665d6d-b911-4eec-a2aa-7d593721b838",
   "creator":[
      {
         "type":"Person",
         "name":"Michael Menzel"
      }
   ],
   "sourceOrganization":{
      "id":"http://www.wikidata.org/entity/Q153978",
      "name":"Universität Tübingen"
   }
}

2. affiliation

{
   "@context": "http://schema.org",
   "id":"https://www.oerbw.de/edu-sharing/components/render/aa665d6d-b911-4eec-a2aa-7d593721b838",
   "creator":[
      {
         "type":"Person",
         "name":"Michael Menzel",
         "affiliation":{
            "id":"http://www.wikidata.org/entity/Q153978",
            "name":"Universität Tübingen"
         }
      }
   ]
}

Beide Optionen haben Vor- und Nachteile.

Die HTML-Spezifikation benennet als valide Werte für learningResourceType zwei Vokabulare.

learningResourceType.json:

• Zweites Schema ergänzen

• Validierungspattern aktualisieren

• className: hidden entfernen? / learningResourceType im SkoHub-Editor anzeigen (in HTML-Spezifikation als Pflichtfeld deklariert, jedoch dort nicht vorhanden?)

Zur Zeit ist das mit dem Editor generierte JSON-LD bei den Lizenzinformationen nicht korrekt.

Es gibt mindestens zwei Probleme:

1. Die URI unter inScheme resolvt nicht.
2. Die URIs für die einzelnen Konzepte sind inkorrekt, offensichtlich hat SkoHub Editor Probleme mit der base URI https://oerworldmap.org/assets/json/licenses.json#, siehe https://github.com/acka47/license-vocab/blob/fca5ff5365936ed3b489a674cc809b520f096c3e/licenses.ttl#L1

Beispiel:

  "license": {
    "id": "https://oerworldmap.org/assets/json/cc-by-sa",
    "prefLabel": {
      "en": "Creative Commons Attribution Share-Alike",
      "de": "Creative Commons Namensnennung, Weitergabe unter gleichen Bedingungen"
    },
    "type": "Concept",
    "inScheme": {
      "id": "https://oerworldmap.org/assets/json/licenses/"
    }
  }

Mögliche Lösung: Das Vocab nach dini-ag-kim und in den Namensraum w3id.org/kim/ umziehen. Dafür sollte aber klar sein, dass dieses Vokabular so oder in einer angepasstne Form überhaupt genutzt werden soll.

Bisher berücksichtigt das Schema nicht den vor Kurzem ergänzten schema.org-Typ LearningResource. Da es sich bei allen beschriebenen Ressourcen um Lehr- oder Lernressourcen handeln sollte, kann er per Default ergänzt werden.

Die HTML-Spezifikation benennet als valide Werte für about zwei Vokabulare.

about.json:

• Zweites Schema ergänzen
• Validierungspattern aktualisieren

Momentan finden einige Parallelarbeiten im Hochschul- und Schulbereich, wo immerhin dieselben Standards, Tools und Prozesse stattfinden. Das LRMI-Profil ist für den Hochschulbereich, wie auch die darin genutzten kontrollierten Vokabulare HCRT und die Hochschulfächersystematik.

Für den Schulbereich nutzt @sroertgen auch SKOS/SkoHub (siehe https://vocabs.openeduhub.de/) und möchte auch ein JSON Schema für schema.org/LRMI-basierte Metadaten von Schul-OER als JSON-LD schreiben.

Es ist davon auszugehen, dass einige Teile des Schemas gleichermaßen für beide Bereiche (Schule/Hochschule) verwendet werden können, wohingegen andere für den jeweiligen Bereich angepasst werden müssen. Mit skohub-io/skohub-editor#55 wird es im SkoHub Editor möglich sein, modularisierte und über URLS aufeinander verweisende JSON Schemas zu verwenden. Im Branch splitUpSchema hatte ich schon einmal einen früheren Stand des Schemas aufgesplittet in modulare Bestandteile.

Wir sollten überlegen, wie und wo wir die generischen Schemabestandteile ablegen, so dass sie von beiden Schemas referenziert und sozusagen importiert werden können.

Siehe hier zum Hintergrund, warum Travis keine Lösung für die Zukunft ist: https://www.jeffgeerling.com/blog/2020/travis-cis-new-pricing-plan-threw-wrench-my-open-source-work

In einigen Kontexten hat sowohl die beschriebene OER als auch die Beschreibungsseite eine eigene URL, z.B. wenn eine Binärdatei oder eine andere Webseite beschrieben. Beispiel: https://www.oerbw.de/edu-sharing/components/render/42d0bc4a-5c46-49c8-bb01-d5b365142330 beschreibt einen Kurs, dessen Hauptseite hier ist: https://www.oncampus.de/Theoretische%2BInformatik%2B1

Die strukturierten Daten werden aber zunächst in edusharing, d.h. unter www.oerbw.de... liegen. Die URL der beschriebenen OER sollte als id benutzt werden, weil es die Ressource ist, um die es in den Aussagen geht. Aber evtl. sollen auch Aussagen über die Metadaten/Beschreibungsseite ergänzt werden. Wie kann das umgesetzt werden?

Mir ist gerade am Beispiel https://github.com/dini-ag-kim/lrmi-profile/blob/main/draft/examples/valid/parts.json aufgefallen, dass dort "license" in "isPartOf" noch als string hinterlegt ist. Wir sollten unser "license"-Schema als mögliche Feld-Option referenzieren, dann würde auch in den Beispielen "license"-Angaben invalide sein.

Da das lrmi-profil nicht mehr nur zur Erfassung von OER dienen soll, brauchen wir eine Öffnung des Vokabulars für das license-Feld, damit auch andere Lizenzen und der Verweis auf vorbehaltene Rechte mit erfasst werden können.

Das LRMI-Profil wird bereits im OERSI-Projekt erweitert und angepasst (siehe dazu z.B. https://gitlab.com/oersi/oersi-etl/-/issues/51) aber auch im ComeIn-Projekt wird es voraussichtlich – wie im heutigen Treffen besprochen – fächerspezifische Erweiterungen geben.

Neben dem Deklarieren des Profils in Instanzmetadaten (#63) wäre wünschenswert, wenn Erweiterungen des Profils ihre Verbindung zum Ursprungsschema irgendwie dokumentieren würden. Hier einige mögliche Ansätze:

1. git-basiert: "Sub-Profile" sind GitHub Forks oder git clones vom Hauptschema und Beziehungen sowie Abweichungen sind über die git History dokumentiert.
2. JSON-basiert: Im Profil selbst wird die Art der Beziehung zum Hauptprofil angegeben. Dafür gibt es in JSON Schema allerdings noch keine gängige Praxis.

Natürlich ist auch die Kombination von 1.) und 2.) möglich. Ich denke, wir sollten hier aber nur einen metadatenbasierten Ansatz (2.) spezifizieren. Ich könnte mir folgendes vorstellen, weiß aber nicht, wann dafür alle Voraussetzungen erfüllt sind.

• JSON Schemas werden als RDF/JSON-LD publiziert, dafür gibt es bereits einen Spec-Entwurf beim W3C: https://www.w3.org/2019/wot/json-schema
• Danach ließe sich mit derProperty prof:isProfileOf aus dem Profiles Vocabulary die Beziehung zum übergeordneten Profil ergänzen.

Das Problem: Sowohl "JSON Schema in RDF" als auch das "Profiles Vocabulary" sind nur in Entwurfsfassung verfügbar, und es ist unklar, ob sie in der Form schon benutzt werden sollten und ob/wann sie offizielle W3C Empfehlungen werden.

Aktuell ist learningResourceType ein Objekt, welches sowohl die id, als auch den Namen umfasst. Damit kann man aber mögliche Mischformen nicht berücksichtigen.

Mein Beispiel wäre, dass Videos auch Kurse oder Präsentationen sein können. @acka47 meinte dazu, dass es wenig Überschneidungen gebe. Video sei, wenn ein Bestandteil eines Kurses und Präsentation beziehe sich auf die Slides.

@acka47 und ich waren uns einig. dass wir es aber einmal diskutieren sollten.

Wurde im letzten Treffen der OER-Metadatengruppe gewünscht, siehe https://pad.gwdg.de/J8PBLx97T_qhkkWsNf0ujQ#LRMI-Profil

See hbz/lobid#433.

Hallo zusammen,

wie in der OER-Metadatengruppe besprochen, wollen wir noch ein Schulbeispiel in der HTML-Version ergänzen.

Ich bereite da mal was vor und werde vermutlich einfach das bereits vorhandene tutory-Beispiel nehmen.

Geht zurück auf eine Diskussion im OERSI-Kontext: https://gitlab.com/oersi/oersi-setup/-/issues/29. Um die offene Lizenzierung (CC0) von OER-Metadaten als gängige Praxis zu etablieren sollte das Profil Lizenzangaben für die Metadaten selbst unterstützen. Innerhalb des Datenmodells wäre mainEntityOfPage.license ein naheliegender Ort.

Bei der Validierung in OERSI werden folgende Warnungen zurückgemeldet:

WARN  [main] [JsonMetaSchema] Unknown keyword additionalItems - you should define your own Meta Schema. If the keyword is irrelevant for validation, just use a NonValidationKeyword
WARN  [main] [JsonMetaSchema] Unknown keyword _display - you should define your own Meta Schema. If the keyword is irrelevant for validation, just use a NonValidationKeyword
WARN  [main] [JsonMetaSchema] Unknown keyword suggested - you should define your own Meta Schema. If the keyword is irrelevant for validation, just use a NonValidationKeyword
WARN  [main] [JsonMetaSchema] Unknown keyword _widget - you should define your own Meta Schema. If the keyword is irrelevant for validation, just use a NonValidationKeyword

Man kann dabei nicht eindeutig erklären, welches Schema diese hervorruft. Aber müssen wir hier etwas tun?

So etwas kann nicht in ES indexiert werden:

{
  "@context": [ 
    "https://w3id.org/kim/lrmi-profile/draft/context.jsonld",
    {"@language": "de"}
  ],
  "name": "Beispielkurs",
  "id": "https://example.org/oer",
  "type": "Course"
}

Siehe auch https://www.elastic.co/guide/en/elasticsearch/reference/7.10/array.html:

When adding a field dynamically, the first value in the array determines the field type. All subsequent values must be of the same data type or it must at least be possible to coerce subsequent values to the same data type.

Arrays with a mixture of data types are not supported

Aus diesem Grund geht das POSTen nach SkoHub nicht mehr vollständig (weil dort ein ES-Index angeschlossen ist), siehe skohub-io/skohub-pubsub#40 (comment).

Zwar ist das valides JSON-LD und so ähnlich auch in einem Beispiel dokumentiert (https://w3c.github.io/json-ld-syntax/#example-22-combining-external-and-local-contexts), allerdings wäre es schon gut, ES-kompatibles JSON zu produzieren, weil u.a. SkoHub und OERSI auf dem Schema aufbauen. Allerdings sehe ich gerade keine Möglichkeit, das Schema so anzupassen, dass die Daten äquivalent sind und ES-kompatibel.

Zum Beispiel ist das hier kein valides JSON-LD (siehe Playground):

{
  "@context": {
    "@id": "https://w3id.org/kim/lrmi-profile/draft/context.jsonld",
    "@language": "de"
  },
  "name": "Beispielkurs",
  "id": "https://example.org/oer",
  "type": "Course"
}

Die URL des Kontext kann nicht mit @id angegeben werden.

Die einzige Lösung, die ich sehe: Die Default-Sprache in den externen Kontext eintragen und verschiedene Kontexte anbieten (context-de.jsonld, context-en.jsonld etc.)

Siehe z.B. FAIR Signposting Profile.

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.

Die Spezifikation legt nicht fest, wie Personennamen am besten angegeben werden sollten. Ich schlage vor, Personnamen vollständig in der üblichen Reihenfolge der jeweiligen Sprache (Deutsch: Vorname Nachname) zu erfassen. Siehe auch https://www.w3.org/International/questions/qa-personal-names.

Da das Metadatenprofil für OER bestimmt ist, wäre die notwendige Ausweisung einer Lizenz meiner Meinung nach sinnvoll.

Aus pragmatischer Perspektive sollte das aber ohne vorgeschriebene Werteliste sein, um offene Lizenzen jenseits von Creative Commons und im Kontext von OERSI auch ggf. Ressourcen mit vorbehaltenen Rechten berücksichtigen zu können.

Der derzeitige Ansatz macht zu viele Probleme, z.B. #53 . Wir sollten die verschiedenen Abschnitte besser nicht ind Markdown-Dateien unter /contents ablegen, sondern alles – als Markdown – in die index.html schreiben, wie in HS-OER-LOM.