Die Spezifikation näher an schema.org orientieren #204
Comments
|
Wieso wird {
"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) |
|
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 Siehe dazu auch @sroertgen 's Frage vom Dezember 2020: #33 (comment) Aus meiner Antwort, die ich ähnlich auch im letzten Treffen gegeben habe:
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 Dazu kommt, das |
|
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. |
|
Zunächst mal, haben wir AMB von Anfang an wie folgt definiert (aus der Spec):
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 schemaorg/schemaorg#894 enthält ja bereits viele Diskussionen zum Thema. Hier ein Zitat aus Dan Brickley's Zusammenfassung:
Wir fallen eben in die zweite Gruppe ("professional information-organizing data people") und nicht in die erste ("Mainstream webmasters"). |
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 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 |
Wie es aussieht ist
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 |
|
Nach #255 ist (wenn ich es richtig sehe) eine Änderung von |
|
Vor Kurzem kam das Thema auch in OERSI auf, siehe https://gitlab.com/oersi/oersi-setup/-/issues/130 |
|
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 |
|
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
Update |
|
Hallo @AOphagen , es wurde bereits 2015 als Best Practice diskutiert, für die JSON-LD Keywords Auch in schema.org wurde das angeblich auch umgesetzt, und zwar 2020, siehe schemaorg/schemaorg#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: 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 |
|
Dazugehörige Diskussion: |
Prinzipiell haben wir ja bereits schema.org als Basis-Vokabular im JSON-LD-Kontext angegeben: Line 5 in 2adf7ca 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,
|
Wenn ich dich richtig verstehe, tun wir dies ja bereits im JSON-LD-Kontext, sowohl für den Typ Lines 6 to 13 in 2adf7ca |
|
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? |
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/" } } ] }The text was updated successfully, but these errors were encountered: