Die Spezifikation näher an schema.org orientieren

[CodingDive]

Ich habe ein Beispiel genommen, ein wenig angepasst und dann durch https://validator.schema.org/ laufen lassen. Da treten momentan 5 Fehler auf. Ich finde wir sollten dokumentieren wo wir uns von schema.org entfernen und warum. @kulla und ich finden, dass wir so nah wie Möglich an schema.org bleiben sollten.

{
  "@context": [
    "https://schema.org/",
    {
      "@language": "de",
      "id": "@id",
      "type": "@type"
    }
  ],
  "name": "Arbeitsblatt - Mon avenir - Französisch - tutory.de",
  "id": "https://www.tutory.de/w/fbbadf1a",
  "image": "https://www.tutory.de/worksheet/fbbadf1a-145a-463d-9a43-1ae9965c86b9.jpg?width=1000",
  "type": [
    "LearningResource"
  ],
  "creator": [
    {
      "name": "HerunterS",
      "type": "Person"
    }
  ],
  "description": "Französisch-Arbeitsblatt",
  "about": [
    {
      "id": "http://w3id.org/kim/schulfaecher/s1009",
      "prefLabel": {
        "de": "Französisch"
      },
      "type": "Concept",
      "inScheme": {
        "id": "http://w3id.org/kim/schulfaecher/"
      }
    }
  ],
  "keywords": [
    "Französisch",
    "Niveau A2"
  ],
  "learningResourceType": [{
      "id": "https://w3id.org/kim/hcrt/worksheet"
    },
    {
      "id": "http://w3id.org/openeduhub/vocabs/learningResourceType/worksheet"
    }
  ],
  "license": {
    "id": "https://creativecommons.org/publicdomain/zero/1.0/"
  },
  "conditionsOfAccess": {
    "id": "http://w3id.org/kim/conditionsOfAccess/no_login",
    "type": "Concept"
  },
  "dateCreated": "2019-07-02",
    "inLanguage": [
    "fr"
  ],
  "publisher": [
    {
      "type": "Organization",
      "name": "Tutory",
      "id": "https://www.tutory.de"
    }
  ],
  "audience": [
    {
      "id": "http://purl.org/dcx/lrmi-vocabs/educationalAudienceRole/student",
      "prefLabel": {
        "en": "student"
      },
      "type": "Concept",
      "inScheme": {
        "id": "http://purl.org/dcx/lrmi-vocabs/educationalAudienceRole/"
      }
    }
  ]
}

[kulla]

Wieso wird Concept und nicht https://schema.org/DefinedTerm verwendet. Ein Beispiel. Anstelle von

{
  "about": [
    {
      "id": "http://w3id.org/kim/schulfaecher/s1009",
      "prefLabel": {
        "de": "Französisch"
      },
      "type": "Concept",
      "inScheme": {
        "id": "http://w3id.org/kim/schulfaecher/"
      }
    }
  ]
}

Könnte man auch im Sinne von schema.org folgendes verwenden

{
  "about": [
    {
      "id": "http://w3id.org/kim/schulfaecher/s1009",
      "prefLabel": {
        "de": "Französisch"
      },
      "type": "DefinedTerm",
      "inDefinedTermSet": {
        "id": "http://w3id.org/kim/schulfaecher/"
        "type": "DefinedTermSet"
      }
    }
  ]
}

(Analog bei anderen Feldern wie https://dini-ag-kim.github.io/amb/draft/#educationallevel um sie kompatibel zu https://schema.org/educationalLevel zu machen)

[acka47]

Prinzipiell sollten wir uns m.E. nicht zu sehr von Google's schema.org-Validator beeinflussen lassen. Wir wollen ein funktionierendes, überischtliches und erweiterbares Metadatenprofil entwickeln und dabei so weit wie möglich schema.org nutzen. Da es in dieser Hinsicht aber klar hinter SKOS zurückfällt, sehe ich nicht den Nutzen. Selbst wenn unser Hauptziel SEO sein sollte (was m.E. höchstens ein netter Nebeneffekt einer AMB-Nutzung ist): Wir wissen nicht einmal, ob Google die strukturierten Daten überhaupt für die Verbesserung der Suche und Anzeige der Suchergebnisse nutzt und wenn ja, ob DefinedTerm etc. dafür überhaupt gebraucht werden.

Siehe dazu auch @sroertgen 's Frage vom Dezember 2020: https://github.com/dini-ag-kim/amb/issues/33#issuecomment-747296735

Aus meiner Antwort, die ich ähnlich auch im letzten Treffen gegeben habe:

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.

Warum SKOS? Es ist ein etablierter Standard und erledigt die Aufgabe, die zu erfüllen ist, besser als schema.org. Siehe auch das schemaorg-Ticket, in dem DefinedTerm etc. eingeführt wurden, insbesondere Dan's zusammenfassenden Kommentar: https://github.com/schemaorg/schemaorg/issues/894#issuecomment-274518908

Dazu kommt, das DefinedTerm etc. noch immer in "pending" sind bei schema.org. Ich habe das Gefühl, dass es – zu Recht – nicht allzu häufig genutzt wird.

[axel-klinger]

Der Argumentation konnte ich jetzt noch nicht entnehmen, warum es Concept und nicht DefinedTerm lauten sollte. Grundsätzlich würde ich eine internationale Kompatibilität begrüßen, wenn wir schon (noch?) nicht international sind. Änderungsvorschläge an schema.org fände ich daher besser als eine Abweichung, nur weil wir es gerne anders nennen würden. Im internationalen Kontext von OE Global, LIBER etc tue ich mich schwer zu sagen, dass wir in DE etwas inkompatibles entwickeln.

[acka47]

Zunächst mal, haben wir AMB von Anfang an wie folgt definiert (aus der Spec):

Ein bildungsbereichübergreifendes Metadatenprofil für die Beschreibung von Lehr- und Lernressourcen, das hauptsächlich auf [schema.org] bzw. Learning Resource Metadata Initiative [LRMI] basiert und zusätzlich Teile von Simple Knowledge Organization System [SKOS] nutzt.

Grundsätzlich würde ich eine internationale Kompatibilität begrüßen

SKOS ist eine W3C Recommendation, die Jahre vor schema.org veröffentlicht wurde. Mehr internationale Kompatibilität kann mensch nicht haben.

Soviel erstmal in aller Kürze. Das bereits oben verlinkte Ticket https://github.com/schemaorg/schemaorg/issues/894 enthält ja bereits viele Diskussionen zum Thema. Hier ein Zitat aus Dan Brickley's Zusammenfassung:

• in the general case for mainstream webmasters, schema.org has a reasonable usability story for doing everything in one big flat namespace
• for cases where the publishers are professional information-organizing data people, and who may already be some way along the path of using related standards, the "do it all inside schema.org" story is significantly weaker.

Wir fallen eben in die zweite Gruppe ("professional information-organizing data people") und nicht in die erste ("Mainstream webmasters").

[kulla]

Dazu kommt, das DefinedTerm etc. noch immer in "pending" sind bei schema.org. Ich habe das Gefühl, dass es – zu Recht – nicht allzu häufig genutzt wird.

Das ist ein wichtiges Detail. Ich erkenne es daran, dass https://github.com/schemaorg/schemaorg/blob/main/data/ext/pending/issue-894.ttl#L21-L26 sich im Ordner data/ext/pending befindet, richtig?

Zur Lösung: In JSON-LD habe ich den Abschnitt Open Issues entdeckt. Wie wäre es, wenn wir einen ähnlichen Abschnitt in der Spec hinzufügen und dort auf die Diskussion aufmerksam machen? Wir können hier was schreiben wie "Wir haben uns für SKOS entschieden, weil ... und DefinedTerm in schema.org noch 'pending' ist. Sollte das Konzept standardisiert werden, überlegen wir es einzubauen".

[acka47]

Das ist ein wichtiges Detail. Ich erkenne es daran, dass https://github.com/schemaorg/schemaorg/blob/main/data/ext/pending/issue-894.ttl#L21-L26 sich im Ordner data/ext/pending befindet, richtig?

Wie es aussieht ist DefinedTerm nicht (mehr) in pending. Entweder ich habe mich im April vertan, oder es hat sich seitdem etwas verädnert. Habe ein bisschen im schema-org-Repo rumgeschaut aber blicke leider nicht durch, wie ich da am besten Änderungen eines Eintrags nachvollziehen kann.

In JSON-LD habe ich den Abschnitt Open Issues entdeckt. Wie wäre es, wenn wir einen ähnlichen Abschnitt in der Spec hinzufügen und dort auf die Diskussion aufmerksam machen? Wir können hier was schreiben wie "Wir haben uns für SKOS entschieden, weil ... und DefinedTerm in schema.org noch 'pending' ist. Sollte das Konzept standardisiert werden, überlegen wir es einzubauen".

Wir können uns das gerne offen halten und so einen Abschnitt einbauen, vor allem, wenn sich noch weitere offene Fragen ergeben. Für mich war das "pending" allerdings nie das einzige – und nichtmal das größte – Problem mit dem DefinedTerm-Ansatz.

[kulla]

Nach https://github.com/dini-ag-kim/amb/pull/255 ist (wenn ich es richtig sehe) eine Änderung von Concept auf DefinedTerm kein Breaking Change mehr (nachdem Concept eine optionale Ergänzung ist und solange DefinedTerm auch optional ist). Dementsprechend könnte man die Änderung jederzeit in Zukunft vornehmen, wenn wir dies als notwendig betrachten. Aus meiner Sicht, kann dieses Issues aus dem Milestone 1.0 dementsprechend rausgenommen werden.

[acka47]

Vor Kurzem kam das Thema auch in OERSI auf, siehe https://gitlab.com/oersi/oersi-setup/-/issues/130

[acka47]

Wie bereits von @kulla erwähnt und eben im Treffen besprochen (siehe https://pad.gwdg.de/s/J1krwIj1Q#AMB-10), verschieben wir diese Diskussion und nehmen das Ticket aus dem Meilenstein heraus.

Hintergrund: Grundsätzlich wird eine andere oder zusätzliche Auszeichnung der kontrollierten Werte als DefinedTerm kein Breaking Change bedeuten, so dass die Frage später entschieden werden kann.

[AOphagen]

Wir haben gerade einen Anwendungsfall hiervon. Wir verwenden Teile aus schema.org und füllen das Amb-JSON damit auf, so ergänzen wir z.B. den type Course und dazu offers als @type offers. Und hier sind wir gerade verwirrt, weil Amb type nutzt und auch definiert und schema.org '@type nutzt. Z.B. beim publisher verwenden wir den type Organization. Sollten wir da jetzt type oder '@type schreiben?

• https://schema.org/CreativeWork#eg-0175 -> type
• https://dini-ag-kim.github.io/amb/latest/#example-beschreibung-eines-arbeitsblattes-fur-das-schulfach-franzosisch -> type

Update Sorry, @type for the shout-outs

[acka47]

Hallo @AOphagen , es wurde bereits 2015 als Best Practice diskutiert, für die JSON-LD Keywords @type und @id im JSON-LD-Kontext den Alias type bzw. id zu definieren. Das haben wir in AMB getan, siezhe https://dini-ag-kim.github.io/amb/context.jsonld, so das wir type anstatt @type und id andstatt @id verwenden können, was das JSON-LD nocht anwendungsfreundlicher macht.

Auch in schema.org wurde das angeblich auch umgesetzt, und zwar 2020, siehe https://github.com/schemaorg/schemaorg/issues/854. Allerdings kann ich es im aktuellen schema.org JSON-LD Kontext unter https://schema.org/version/latest/schemaorg-current-https.jsonld (siehe dazu auch https://schema.org/docs/developers.html) nicht finden...

Prinzipiell sollte das aber nichts an der Konformität zu Google-Anforderungen ändern. Das lässt sich mit dem schema.org-Validastor testen. Das habe ich gerade mal mit einem Beispiel aus OERSI gemacht:

https://validator.schema.org/#url=https%3A%2F%2Foersi.org%2Fresources%2FaHR0cHM6Ly9jb2RlYmVyZy5vcmcvYWNrYTQ3L21hbGlzLWl0Mi4xYQ%3D%3D%3Fformat%3Djson

Da fiel mir eine neue Fehlermeldung auf, die ich bisher nicht kannte:

Das heißt, der Validator testet das Snippet erst gar nicht, weil er den Kontext nicht kennt und das JSON-LD gar nicht erst interpretiert. Das hatten wir schonmal in #119 diskutiert. Von daher scheint es mir am dringendsten zu sein, irgendwie schema.org direkt im @context-Objekt zu nennen (und nicht erst im externen AMB-Kontext) (Option 1, Option 2, die beide dem AMB-Kontext-Schema entsprechen), um schema.org-Konformität zu erlangen. Das sollten wir am besten auch mal – informativ nicht normativ – in der Spec ergänzen.

[oellers]

Dazugehörige Diskussion: Spricht etwas dagegen mehrere @context im AMB anzugeben, ggf. mit Namespace Prefix, wenn ein Attribut identisch bzw. kompatibel zu schema.org definiert ist, um das zu kennzeichnen?

[acka47]

Spricht etwas dagegen mehrere @context im AMB anzugeben, ggf. mit Namespace Prefix, wenn ein Attribut identisch bzw. kompatibel zu schema.org definiert ist, um das zu kennzeichnen?

Prinzipiell haben wir ja bereits schema.org als Basis-Vokabular im JSON-LD-Kontext angegeben:

https://github.com/dini-ag-kim/amb/blob/2adf7ca15d18a7e5333b9f8503e8695b8061196a/context.jsonld#L5

Jede Ergänzung des Mappings einzelner Properties auf schema.org-Properties wäre redundant. Oder verstehe ich etwas falsch?

[oellers]

Jede Ergänzung des Mappings einzelner Properties auf schema.org-Properties wäre redundant. Oder verstehe ich etwas falsch?

In der Tat, ich hatte nur die Angabe multipler Kontexte im Kopf mit Präfixen, die man den Attributen zuordnet. Aber da wir ohnehin viele/fast alle aus schema.org haben, passt das sicher auch so, der Rest würde dann vmtl. separat im context deklariert.

Fraglich wäre dann aber ggf. die Ausgangssituation hier, z.B. bei Abweichungen zu schema.org, ob wir die Felder dann nicht eigentlich separat deklarieren müssten, damit die Validierung durchgeht oder ob das den Nachteil mit sich bringt, dass dann andere "bekannte" Attribute gänzlich ignoriert würden.

Beispiel sind ja die Felder mit kontrollierten Vokabularen,

• about -> "Concept" als Type (basierend auf skos:Concept)

[acka47]

Fraglich wäre dann aber ggf. die Ausgangssituation hier, z.B. bei Abweichungen zu schema.org, ob wir die Felder dann nicht eigentlich separat deklarieren müssten, damit die Validierung durchgeht oder ob das den Nachteil mit sich bringt, dass dann andere "bekannte" Attribute gänzlich ignoriert würden.

Beispiel sind ja die Felder mit kontrollierten Vokabularen,

• about -> "Concept" als Type (basierend auf skos:Concept)

Wenn ich dich richtig verstehe, tun wir dies ja bereits im JSON-LD-Kontext, sowohl für den Typ skos:Concept als auch – aus historischen Gründen – für die Properties skos:inScheme und skos:prefLabel:

https://github.com/dini-ag-kim/amb/blob/2adf7ca15d18a7e5333b9f8503e8695b8061196a/context.jsonld#L6-L13

[acka47]

Das müssen wir uns nochmal genauer anschauen, ob sich hier ein konkretes Ticket ableiten lässt, das wir zum Meilenstein für die nächste Version ergänzen. @kulla hast du da eine Meinung. Fehlt jetzt noche twas Wichtiges in Bezug auf Google-Kompatibilität?