Unterstützung multilingualer Labels

[acka47]

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.

[acka47]

Ein einfacher Ansatz zur Angabe der jeweiligen Sprache für alle Textstrings wäre die Ergänzung einer Default-Sprache im JSON-LD-Kontext (siehe dazu den Abschnitt "String Internationalization" in der JSON-LD 1.1 Spezifikation). Mit dem in #16 vorgeschlagenen Ansatz für einen externen Kontext, könnte die Default-Sprache als Objekt im @context Array wie folgt ergänzt werden:

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

Bei einer englischsprachigen Beschreibung sähe es entsprechend so aus:

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

Dieser Ansatz ermöglicht es allerdings nicht, etwa bei einer multilingualen OER auch die Beschreibung multilingual zu erfassen. Dafür bietet sich wiederum language-maps-Ansatz in JSON-LD an:

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

Ich fänd es sinnvoll, im besten Fall beide Varianten zu erlauben (was das Schema deutlich komplizierter machen würde). Das heißt, man müsste bei bereits nach dem Schema erstellten Metadaten nur die Default language ergänzen und könnte perspektivisch auch multilinguale Beschreibungen erfassen.

[acka47]

@axel-klinger , @mirjan-hoffmann und ich, wir haben uns gerade in einem Gespräch auf folgende Lösung geeinigt: Wir werden nur die Angabe der Default-Sprache unterstützen aber bei Werten aus einem kontrollierten Vokabular eine language map erwarten. Sollte Bedarf entstehen, eine multilinguale Ressource in verschiedenen Sprachen zu erfassen, so sollen schlicht mehrere Beschreibungen mit unterschiedlichen Default-Sprachen angelegt werden.

Ich werde das Schema entsprechend anpassen.

[acka47]

In folgenden Feldern des Schemas werden Werte aus kontrollierten Vokabularen genutzt:

• about
• learningResourceType
• audience

Ich werde dementsprechend bei diesen drei Feldern die Validierung der language map für prefLabel ergänzen.

[acka47]

Dieses Ticket wurde erledigt mit #19.

[FunkMonkey]

Hallo,

Ich entwickle aktuell eine adaptive Lernumgebung und habe vor kurzem AMB als Format für die Metadatenbeschreibung entdeckt. Da es sehr gut zu meinen Zielen passt, verwende ich es bereits in meinem aktuellen Prototypen.

Ich möchte noch mal die Diskussion anstoßen, ob name und description nicht Language Maps verwenden sollten, wie von @acka47 vorgeschlagen. In meinem Prototypen benötige ich diese einfach um Namen und Inhalt der Lernressource je nach Sprache richtig darzustellen.

Sollte Bedarf entstehen, eine multilinguale Ressource in verschiedenen Sprachen zu erfassen, so sollen schlicht mehrere Beschreibungen mit unterschiedlichen Default-Sprachen angelegt werden.

Diese Lösung finde ich an sich okay, allerdings stört mich daran folgendes:

• Mehrere Beschreibungen haben ja dann unterschiedliche ids. Da aktuell die id auch der URL der Ressource ist, bräuchte man dann unterschiedliche URLs für dieselbe multilinguale Ressource
• es existiert in der Spezifikation aktuell keine Möglichkeit deutlich zu machen, dass die verschiedenen Beschreibungen (mit den unterschiedlichen ids) zusammengehörig sind. Aus Sicht meiner Lernumgebung wären es quasi zwei verschiedene Lernressourcen.

Ich freue mich auf Feedback. Vielen Dank!

[acka47]

Hallo @FunkMonkey , danke für die Anfrage. Diese Ädnerung werden wir jetzt nicht machen können, weil das grundlegende Dinge an der JSON-Struktur ändert und nicht rückwärtskompatibel ist (es sei denn, wir unterstützen bedies, was aber zu mehr Komplexität führt).

Diese Lösung finde ich an sich okay, allerdings stört mich daran folgendes:

• Mehrere Beschreibungen haben ja dann unterschiedliche ids. Da aktuell die id auch der URL der Ressource ist, bräuchte man dann unterschiedliche URLs für dieselbe multilinguale Ressource

Ja, stimmt, das ist unschön. Du könntest die IDs anhand eines mit # angehängten Suffixes unterscheiden, z.B. https://example.org/oer#de und https://example.org/oer#en. Das finde ich allerdings selbst unschön.

• es existiert in der Spezifikation aktuell keine Möglichkeit deutlich zu machen, dass die verschiedenen Beschreibungen (mit den unterschiedlichen ids) zusammengehörig sind. Aus Sicht meiner Lernumgebung wären es quasi zwei verschiedene Lernressourcen.

Dies ließe sich durch die Ergänzung von owl:sameAs-Links beheben (die tatsächlich aber in der Spec nicht enthalten sind).

Ich glaube in deiner Situation wäre es am sinnvolsten, einfach entsprechende Felder für die verschiedenen Sprachen selbst ergänzen, indem du den @context erweiterst, z.B.:

{
   "@context":[
      "https://w3id.org/kim/amb/draft/context.jsonld",
      {
         "@language":"de",
         "name_en":{
            "@id":"https://schema.org/name",
            "@language":"en"
         },
         "description_en":{
            "@id":"https://schema.org/description",
            "@language":"en"
         }
      }
   ],
   "id":"https://example.org/oer",
   "type":[
      "LearningResource",
      "Course"
   ],
   "name":"Beispiel",
   "name_en":"Example",
   "description":"Dies ist ein Beispiel",
   "description_en":"This is an example"
}

(Siehe auch das Beispiel im JSON-LDPlayground.)

Dann wäre es AMB-kompatibel und du hättest die Namen in anderen Sprachen (als Erweiterung des AMB) drin. Wäre das erstmal ein zufriedenstellender Ansatz?

[FunkMonkey]

Hallo @acka47, entschludige die späte Antwort. So ähnlich habe ich es dann auch gemacht (allerdings mit name und description als Object mit Language-Code-Keys).

Vielen Dank erst mal!

---

Ich habe kürzlich gelesen das AMB auch in OERSI verwendet wird. Ich finde, dort sieht man gut die Problematik der fehlenden Multilingualität für name und description, bspw. bei Ressourcen wie dieser hier. Gleichzeitig verstehe ich aber natürlich auch das Argument der Rückwärts-Kompatiblität.

Eine Variante zur Problemlösung fällt mir allerdings noch ein. Oben schrieb ich mit Bezug auf mehrere Metadaten-Beschreibungen pro Lernressource:

es existiert in der Spezifikation aktuell keine Möglichkeit deutlich zu machen, dass die verschiedenen Beschreibungen (mit den unterschiedlichen ids) zusammengehörig sind. Aus Sicht meiner Lernumgebung wären es quasi zwei verschiedene Lernressourcen.

Dies spiegelt in gewisser Weise auch die Diskussion in #168 wieder. Bzgl. Sprachen der Meta-Daten würde ich allerdings den Diskussionsvorschlag unterbreiten, dass man ein language-Feld mit in mainEntityOfPage aufnimmt um die Sprache der Meta-Daten zu beschreiben und somit gezielter auf verlinkte Meta-Daten zugreifen zu können. Nachteil ist allerdings, dass dieses Feld natürlich redundant ist, da die Sprache bereits im @context -> @language des verlinkten Dokuments enthalten ist. Im schlimmsten Falle wären die Felder sogar widersprüchlich...

[FunkMonkey]

@acka47

Eine Sache, die mir auch kürzlich ins Auge gefallen ist, ist der Abschnitt zu String Localization in der Spezifikation von JSON-LD 1.1. Wenn ich Beispiel 72 richtig deute, sollte dies auch mit der aktuellen AMB-Spezfikation korrekte multi-linguale Metadaten darstellen:

{
  "@context": "https://w3id.org/kim/amb/draft/context.jsonld",
  "id": "https://example.org/oer",
  "type": ["LearningResource", "Course"],
  "name": [
    {
      "@value": "Beispiel",
      "@language": "de"
    },
    {
      "@value": "Example",
      "@language": "en"
    }
  ]
}

Liege ich damit richtig?

Vielen Dank für die Info!

[acka47]

Entschuldige, dass ich auf deinen Kommentar vom 2023-03-09 nicht geantwortet hatte, das war mir durchgegangen.

Wenn ich Beispiel 72 richtig deute, sollte dies auch mit der aktuellen AMB-Spezfikation korrekte multi-linguale Metadaten darstellen

Leider ist dem nicht so. Das AMB erwartet bei name einen String und keinen Array aus Objekten.

Dir scheint das Thema internationalisierter Ressourcenbeschreibungen ja wichtig zu sein. Meinetwegen können wir das Ticket hier auch wieder öffnen und die Diskussion für eine zukünftige Version wiederaufnehmen. Ich fände es gut, wenn du einmal einen Use Case vorstellen würdest – hier im Ticket oder auch beim monatlichen Gruppentreffen –, so dass wir diskutieren können, wie die Anforderungen jetzt oder zukünftig adressiert werden können. Hier ein paar Fragen, die mich interessieren:

• Um welche Datenquelle handelt es sich?
• Wieviele Ressourcen sind es?
• Wieviele davon sind multilingual bzw. haben multilingualte Metadaten?

Ich könnte mir – wie bereits in #18 (comment) geschrieben – vorstellen, dass wir perspektivisch zusätzlich Language Maps erlauben. Wie auch oben bereits geschrieben, ist das Problem daran, dass die Spec dann an Einfachheit verliert, weil JSON-LD-Spezifizitäten mit reingezogen werden. (Bisher haben wir versucht, die Spec implementierbar zu machen, ohne sich in irgendeiner Weise mit JSON-LD oder RDF auseinandersetzen zu müssen.)

[FunkMonkey]

Entschuldige, dass ich auf deinen Kommentar vom 2023-03-09 nicht geantwortet hatte, das war mir durchgegangen.

Gar kein Problem. Ich bin ja auch immer sehr langsam im Antworten ;)

Leider ist dem nicht so. Das AMB erwartet bei name einen String und keinen Array aus Objekten.

Da das für mich noch etwas neu ist und damit ich es richtig verstehe: AMB ist ein Metadatenprofil, welches als solches die zu verwendenden Terms und deren Nutzungsweise (bspw. optional / nicht optional etc., Anzahl) definiert. Die Terms selbst stammen großteils von schema.org (von denen manche aus LRMI stammen) und sind dort einem @type zugeordnet. Der Wertebereich der Values ist teils restriktiert, bspw. durch SKOS-Vokabularien. All diese Restriktionen, sind effektiv im JSON schema von AMB definiert, welches entsprechend das eigentliche Metadatenprofil darstellt.

Für name bedeutet das also: auch wenn JSON-LD generell mehrere Werte für Properties zulässt und "string"-Werte im Sinne der Internationalisierung auch ein Array von ValueObjects mit @language sein könnten, sind aufgrund des AMB JSON schemas nur einzelne string-Werte erlaubt (type-Eigenschaft). Verstehe ich das jetzt richtig? :)

Ich fände es gut, wenn du einmal einen Use Case vorstellen würdest

Gern kurz hier.

TL;DR: Use-Case ist die direkte Verwendung von Meta-Daten (und den entsprechenden Lernressourcen) in (personalisierten) digitalen Lernumgebungen.

Ich forsche an personalisierten Lernumgebungen, welche den Lernenden u.a. automatisiert Lernpfade (Sequenzen von Lernobjekten) ausspielen können sollen. Mein Ansatz - und noch ist nicht klar, wie gut der praktisch funktionieren wird - ist es, diese Lernpfade aus vielen, teils sehr kleinen Lernobjekten zu erzeugen (teils auf der Ebene einzelner Sätze wie Definitionen oder Beispiele). Meine - noch sehr prototypische - digitale Lernumgebung nutzt dann diese Daten und dazugehörigen Metadaten für die Darstellung der Lernobjekte. Grob sieht man das in folgender (alter) Darstellung:

Aktuell ist es sehr block-basiert. Die Titel basieren bspw. auf den Meta-Daten (name bzw. about). Die Inhalte auf den Lernobjektinhalten, welche entsprechend ihrer encodingFormat dargestellt werden. Das ist alles noch nicht super kompatibel zu AMB / schema.org (bspw. habe ich prophylaktisch eigene Werte für type bzw. MIME-Types für encodingFormat definiert um die Idee zunächst zu testen).

Die Lernumgebung ist, bis auf einzelne Ausnahmen wie ein eingebettetes Video, komplett multi-lingual. Entsprechend sind sowohl die textlichen Inhalte multi-lingual, als auch die AMB Metadaten.

Das in aller Kürze. Bei Interesse können wir natürlich auch mal direkt darüber reden, aber ich hoffe der Use-Case macht meine Anforderungen halbwegs verständlich (auch wenn diese Anforderungen sicherlich unüblicher sind als die der meisten anderen AMB-Nutzer*innen) .

Vielen Dank für die nette Diskussion und die ganzen Hintergrundinformationen!