Mikrodaten versus JSON-LD

[Karl Heinz]

Hallo,

mit der von schema.org entwickelten Ontologie gibt es ja die Möglichkeit mit Hilfe von JSON-LD, HTML Microdata und RDFa Inhalte auf Websites zu kennzeichnen. Ziel dieser Kennzeichnung ist die leichtere Erkennung durch Suchmaschinen.

Anhand der nachfolgenden Anleitung von Google bin dies gerade am umsetzen.

https://support.google.com/merchants/answer/7331077

In der Anleitung steht u.a. folgender Satz:

Darüber hinaus müssen Sie entscheiden, ob JSON-LD (empfohlen) oder Mikrodaten besser für Sie geeignet sind.

Leider wird nicht erklärt, warum JSON-LD empfohlen wird. Könnt Ihr mir sagen welchen Grund es hat, dass JSON-LD und nicht Mikrodaten empfohlen werden?

Was ist eigentlich der Unterschied zwischen JSON und JSON-LD?

Viele Grüße

[MrMurphy1]

Hallo

Leider wird nicht erklärt, warum JSON-LD empfohlen wird.

JSON-LD wird von Google entwickelt, Microdata vom W3C. Du befindest dich auf einer Google-Seite.

Unterstützt werden beide Syntaxen von allen Suchmaschinen, Microdata ist am weitesten verbreitet.

JSON-LD hat aber verschiedene Vorteile.

Zum einen ist es nicht in dem gesamten HTML-Quelltext verteilt, sondern befindet sich in der Regel in einem Block am Ende des Quelltextes.

Zum anderen unterstützt JSON-LD speziell den Google-Knowledge-Graphen. Das ist der Kasten, welcher bei Suchen häufig rechts der Suchergebnisse erscheint, verschiedene Informationen zusammenfasst und häufig auch einen Link zu Wikipedia enthält. Such mal nach "Eiffelturm". Dafür bevorzugt Google JSON-LD.

Gruss

MrMurphy

[Gunnar Bittersmann]

@@MrMurphy1

JSON-LD wird von Google entwickelt

Nein.

Microdata vom W3C.

Nein, das ist auf dem Mist der WHATWG gewachsen. Oder auf Hixies persönlichem Mist. Und das, obwohl es mit RDFa schon eine Technik genau für den Zweck gab. NIH-Syndrom.

Microdata ist am weitesten verbreitet.

Was sich hoffentlich ändert. Microdata soll sterben – besser früher als später.

Zum anderen unterstützt JSON-LD speziell den Google-Knowledge-Graphen.

Die Unterstützung sollte nicht von der Syntax abhängen, sondern für JSON-LD, RDFa Microdata gleich sein.

LLAP 🖖

[Karl Heinz]

Microdata ist am weitesten verbreitet.

Was sich hoffentlich ändert. Microdata soll sterben – besser früher als später.

Warum hoffst du das bzw. was würdest du stattdessen (und vor allem aus welchem Grund) empfehlen?

[Gunnar Bittersmann]

@@Karl Heinz

Microdata ist am weitesten verbreitet.

Was sich hoffentlich ändert. Microdata soll sterben – besser früher als später.

Warum hoffst du das

Weil es nicht zwei Standards für dasselbe geben sollte. Weil RDFa (Lite) der bessere Standard ist.

bzw. was würdest du stattdessen (und vor allem aus welchem Grund) empfehlen?

Das hab ich gerade schon beantwortet, oder? 😉

LLAP 🖖

[Karl Heinz]

Hallo Gunnar

Weil es nicht zwei Standards für dasselbe geben sollte. Weil RDFa (Lite) der bessere Standard ist.

Zwei Standards? Ich dachte es gibt drei Standards:

1. JSON-LD
2. Mikrodaten
3. RDFa

[Gunnar Bittersmann]

@@Karl Heinz

Hallo Gunnar

Weil es nicht zwei Standards für dasselbe geben sollte. Weil RDFa (Lite) der bessere Standard ist.

Zwei Standards? Ich dachte es gibt drei Standards:

1. JSON-LD
2. Mikrodaten
3. RDFa

Mit „für dasselbe“ war gemeint: für die sematische Auszeichnung (bezogen auf den Inhalt, nicht die Dokumentstruktur) von im Markup schon vorhandenem Inhalt, also bspw.

<main vocab="http://schema.org/" typeof="MusicComposition">
	<h1 property="name">Ode an die Freude</h1>
	<footer>
		<dl>
			<div property="lyricist" typeof="Person">
				<dt>Worte:</dt>
				<dd property="name">Friedrich von Schiller</dd>
			</div>
			<div property="composer" typeof="Person">
				<dt>Musik:</dt>
				<dd property="name">Ludwig van Beethoven</dd>
			</div>
		</dl>
	</footer>
	<div property="lyrics">
		<p>Freude, schöner Götterfunken …</p>
	</div>
</main>

Bei JSON-LD in HTML müsstest du die Informationen duplizieren:

<main>
	<script type="application/ld+json">
{
	"@context": "http://schema.org",
	"@type": "MusicComposition",
	"name": "Ode an die Freude",
	"lyricist": {
		"@type": "Person",
		"name": "Friedrich von Schiller"
	},
	"composer": {
		"@type": "Person",
		"name": "Ludwig van Beethoven"
	},
	"lyrics": "Freude, schöner Götterfunken …"
}
	</script>
	<h1>Ode an die Freude</h1>
	<footer>
		<dl>
			<div>
				<dt>Worte:</dt>
				<dd>Friedrich von Schiller</dd>
			</div>
			<div>
				<dt>Musik:</dt>
				<dd>Ludwig van Beethoven</dd>
			</div>
		</dl>
	</footer>
	<div>
		<p>Freude, schöner Götterfunken …</p>
	</div>
</main>

LLAP 🖖

[1unitedpower]

Weil es nicht zwei Standards für dasselbe geben sollte.

Wieso? Etwas Wettbewerb unter Standards kann kaum schaden.

Weil RDFa (Lite) der bessere Standard ist.

Das interessiert mich auch, aber wenn ich nach "Microdata vs. RDFa" suche, finde ich nur oberflächlische Diskussionen, hast du da gerade eine gute Quelle parat?

[1unitedpower]

Das interessiert mich auch, aber wenn ich nach "Microdata vs. RDFa" suche, finde ich nur oberflächlische Diskussionen, hast du da gerade eine gute Quelle parat?

Der beste Artikel, den ich finden konnte, stammt von 2012 von Manu Sporny, einem Mitglied der RDFa Arbeitsgruppe des W3Cs, also leider etwas veraltet und nicht ganz unvoreingenommen. Wenn es stimmt, dass die beiedn Standards Feature-äquivalent sind, dann ist für mich die Verbreitung das nächst wichtigste Kriterium und da hat sich das Blatt in den letzten Jahren offensichtlich sehr zu Gunsten von Microdata gewendet.

[Gunnar Bittersmann]

@@1unitedpower

Der beste Artikel, den ich finden konnte, stammt von 2012 von Manu Sporny, einem Mitglied der RDFa Arbeitsgruppe des W3Cs, also leider etwas veraltet

?? Nein, wieso? Oldie, but goldie. Oder anders gesagt: etwas älter ≠ etwas veraltet.

und nicht ganz unvoreingenommen.

?? Wenn ich hier jemandem Voreingenommenheit bescheinigen würde, dann Hixie, weil er Microdata ers(p)onnen hat, obwohl es schon RDFa gab. Und weil er seinen Kram per HTML5 gleich zum Standard erkoren hat.

Wenn es stimmt, dass die beiedn Standards Feature-äquivalent sind, dann ist für mich die Verbreitung das nächst wichtigste Kriterium

Für mich ist die praktische Verwendbarkeit das nächst wichtigste Kriterium. Verarbeitet werden ja RDFa Lite und Microdata gleichermaßen.

LLAP 🖖

[Gunnar Bittersmann]

@@1unitedpower

Weil RDFa (Lite) der bessere Standard ist.

Das interessiert mich auch, aber wenn ich nach "Microdata vs. RDFa" suche, finde ich nur oberflächlische Diskussionen, hast du da gerade eine gute Quelle parat?

“When Schema started, it was ‘use microdata’… We’ve recognized that was a dumb idea and we’re sorry.” —Chaals in Q&A nach meinem Vortrag, ab 30:18

Chaals hat mir irgendwann auch mal zu erklären versucht, warum es sinnvoll ist, Microdata trotzdem erstmal zu speccen, damit man es schneller sterben lassen kann. Ich hab das aber nicht so ganz verstanden.

LLAP 🖖

[Gunnar Bittersmann]

@@1unitedpower

Weil RDFa (Lite) der bessere Standard ist.

Das interessiert mich auch, aber wenn ich nach "Microdata vs. RDFa" suche, finde ich nur oberflächlische Diskussionen, hast du da gerade eine gute Quelle parat?

Gerade zufällig nochmal auf Chaals gestoßen: Schema.org - What, How, Why? (ab 33:20)

“…it makes the complex things possible which is what we need and what Microdata is really bad for.”

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Gerade zufällig nochmal auf Chaals gestoßen: Schema.org - What, How, Why? (ab 33:20)

Und nochmal in den Q&A (ab 42:00)

“If you start anew tody, I would definetely encourage you not to use Microdata.”

LLAP 🖖

[Karl Heinz]

Hallo,

auf der Seite https://www.luna-park.de/blog/29207-strukturierte-daten/ habe ich zwei interesssante Abschnitte zum Thema gefunden:

Der Standard für strukturierte Daten: Schema.org

Schema.org wurde von Google, Yahoo, Bing und Yandex mitentwickelt, damit Internetseiten Betreiber einen Standard erhalten, um Inhalte zu strukturieren und mit anderen Daten zu verbinden. Die Initiative war ein enormer Erfolg: Millionen von Domains nutzen diesen Standard, um Daten in einen semantischen Zusammenhang zu setzen.

Auf Schema.org findet ihr über 600 verschiedene Datentypen, wie z.B. Rezepte, Bewertungen oder Produkte und eine vollständige Dokumentation über die richtige Verwendung und Implementierung. Schema.org wird kontinuierlich erweitert, bleibt kostenfrei und ist bereits ein zukunftssicherer Standard. Um die richtige Implementierung zu überprüfen, bietet Google ein eigenes Testing Tool an.

Google unterstützt die Formate JSON-LD, Microdata und RDFa für strukturierte Daten. Alle Formate haben ihre Vor- und Nachteile und letztendlich muss eure IT entscheiden, welchen Weg sie geht. Das Ergebnis bleibt bei allen Formaten gleich, aber Google empfiehlt JSON-LD.

JSON-LD über Google Tag Manager implementieren

Der Hauptvorteil dieses Formats besteht darin, dass JSON-LD nicht direkt am angezeigten HTML eingebunden wird. Metadaten werden stattdessen separat vom Webseiteninhalt implementiert. Sie lassen sich dadurch besser pflegen und ihr seid unabhängiger von Template-Dateien, die sehr unübersichtlich werden können.

Außerdem könnt ihr JSON-LD über den Google Tag Manager implementieren. Dies hat enorme Vorteile, da die Implementierung ohne die IT-Abteilung oder einen Drittanbieter umgesetzt und erweitert werden kann. Die Implementierung geht dadurch schneller, Fehler sind einfacher zu beheben und das Markup lässt sich besser erweitern.

Ein Nachteil besteht leider darin, dass JSON-LD zurzeit nur von Google interpretiert wird. Andere Suchmaschinen sind bisher lediglich in der Lage Microdata oder RDFa interpretieren.

[Gunnar Bittersmann]

@@Karl Heinz

Der Hauptvorteil dieses Formats besteht darin, dass JSON-LD nicht direkt am angezeigten HTML eingebunden wird. Metadaten werden stattdessen separat vom Webseiteninhalt implementiert.

Was die einem hier als Vorteil verkaufen wollen, sehe ich eher als Nachteil.

Sie lassen sich dadurch besser pflegen

Eben nicht. Doppelte Pflege ist so gut wie niemals bessere Pflege.

Beispiel:

	<script type="application/ld+json">
{
	⋮
	"composer": {
		"@type": "Person",
		"name": "Ludwig van Betthoven"
	},
	⋮
	</script>
	⋮
			<div>
				<dt>Musik:</dt>
				<dd>Ludwig van Betthoven</dd>
			</div>

(Ich hatte tatsächlich diesen Typo im Posting drin.)

Auf der Webseite fällt der Fehler auf und wird berichtigt:

	<script type="application/ld+json">
{
	⋮
	"composer": {
		"@type": "Person",
		"name": "Ludwig van Betthoven"
	},
	⋮
	</script>
	⋮
			<div>
				<dt>Musik:</dt>
				<dd>Ludwig van Beethoven</dd>
			</div>

Dabei fällt nicht auf, dass der Fehler in JSON-LD auch berichtigt werden müsste. Daten im HTML (auf der Webseite) und in JSON-LD (Auswertung bspw. von Suchmaschinen) weichen voneinander ab.

Hat man dagegen

			<div property="composer" typeof="Person">
				<dt>Musik:</dt>
				<dd property="name">Ludwig van Betthoven</dd>
			</div>

dann wird der Fehler an der einen Stelle korrigiert und gut ist.

LLAP 🖖

[Karl Heinz]

Hat man dagegen

			<div property="composer" typeof="Person">
				<dt>Musik:</dt>
				<dd property="name">Ludwig van Betthoven</dd>
			</div>

dann wird der Fehler an der einen Stelle korrigiert und gut ist.

Stimmt, da gebe ich Dir recht.

Dann noch eine andere Frage:

Was bevorzugst du: Mikroformate oder Mikrodaten und warum?

[Gunnar Bittersmann]

@@Karl Heinz

Was bevorzugst du: Mikroformate oder Mikrodaten und warum?

Mit „Mikroformate“ meinst du microformats? Damit kann man nicht alles ausdrücken, was man mit Schema.org kann.

Mit „Mikrodaten“ meinst du Hixies Microdata-Format? Wie gesagt: weg damit; es gibt RDFa (Lite).

Neben meiner Abneigung gegenüber Hixies Alleingängen gibt es auch durchauch praktische Erwägungen, die für RDFa Lite sprechen:

1. Man muss bei Typen nicht immer den ganzen URI angeben, sondern bezieht sich auf den mittels vocab angegebenen Basis-URI (bei Verwendung von mehreren Vokabularien: prefix).

   In meinem Beispiel: RDFa Lite: <div property="composer" typeof="Person">.
   In Microdata müste man dafür schreiben:
   <div itemprop="composer" itemscope itemtype="http://schema.org/Person">.

2. Man spart das unnütze itemscope-Attribut. Ich hab jedenfalls dessen Nutzen noch nicht erkannt. Wenn es sowieso immer zusammen mit itemtype auftritt, dann ist es eigentlich überflüssig.

3. RDFa Lite ist eine Untermenge von RDFa. Falls man doch mal mehr braucht als RDFa Lite hergibt, kann man die erweiterten Möglichkeiten von RDFa nutzen (sofern das denn von einem RDFa-Parser verarbeitet wird). Bspw. ab 22:51 in meinem Vortrag. So etwas ist mit Microdata nicht möglich.

Nachteile von RDFa Lite gegenüber Microdata:

LLAP 🖖

[Karl Heinz]

Hallo Gunnar,

@@Karl Heinz

Warum schreibst du eigentlich immer @@ und nicht @?

[Gunnar Bittersmann]

@@Karl Heinz

@@Karl Heinz

Warum schreibst du eigentlich immer @@ und nicht @?

Ich habe öfter den Fall, dass ich im Archiv nach einem Posting suche, von dem ich weiß, dass es als Antwort auf ein Posting von X geschrieben wurde. Also kommt @@X mit in den Suchstring.

@Christian Kruse hat das extra mal gebaut, dass X bei @@ keine Benachrichtigung erhält.

Und wo ich den CK gerade an der Strippe habe: einige Y schreiben @X in ihre Antworten. X erhält dann die Benachrichtigung, dass Y ihn erwähnt hätte; nicht eine Benachrichtigung, dass Y geantwortet hätte. Es sollte andersrum sein, IMHO.

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Und wo ich den CK gerade an der Strippe habe: einige Y schreiben @X in ihre Antworten. X erhält dann die Benachrichtigung, dass Y ihn erwähnt hätte; nicht eine Benachrichtigung, dass Y geantwortet hätte. Es sollte andersrum sein, IMHO.

Nein. Mention schlägt Antwort. Siehe dazu Diskussion im Archiv.

LG,
CK

[Karl Heinz]

@@@Gunnar Bittersmann,

Ich habe öfter den Fall, dass ich im Archiv nach einem Posting suche, von dem ich weiß, dass es als Antwort auf ein Posting von X geschrieben wurde. Also kommt @@X mit in den Suchstring.

Für eine Person eine prima Lösung, wenn das Dir jetzt alle nachmachen, dann ist der Nutzen wieder dahin.

Ich könnte ja @@@ nehmen 😀.

Man könnte doch das von Dir gewollte auch erreichen, wenn man nur ein @ verwenden würde und stattdessen folgende Suche verwenden würdest?

author:"Gunnar Bittersmann" body:"@Karl Heinz"

Wenn ich Dich richtig verstanden habe willst du mit dem @@ vermeiden, dass die Person benachrichtigt wird, was nur bei einem @ der Fall wäre?

[Gunnar Bittersmann]

@@Karl Heinz

Ich habe öfter den Fall, dass ich im Archiv nach einem Posting suche, von dem ich weiß, dass es als Antwort auf ein Posting von X geschrieben wurde. Also kommt @@X mit in den Suchstring.

Für eine Person eine prima Lösung, wenn das Dir jetzt alle nachmachen, dann ist der Nutzen wieder dahin.

Nö, es gibt ja noch author:… …

Man könnte doch das von Dir gewollte auch erreichen, wenn man nur ein @ verwenden würde und stattdessen folgende Suche verwenden würdest?

author:"Gunnar Bittersmann" body:"@Karl Heinz"

… du sagst es. Das würde aber möglicherweise zu viel finden: auch Postings, in denen irgendwo @⁠Karl Heinz steht. Ich will aber nur diejenigen, wo das ganz am Anfang steht. Deshalb hatte ich mit @@ eine Zeichenkette gewählt, die kaum anderweitig anzutreffen ist.

Wenn ich Dich richtig verstanden habe willst du mit dem @@ vermeiden, dass die Person benachrichtigt wird, was nur bei einem @ der Fall wäre?

Die Benachrichtigungen kamen erst viel später. Und dann war’s andersrum: CK wollte vermeiden, dass die Person benachrichtigt wird, wenn ich @@ verwende.

LLAP 🖖

[Karl Heinz]

@@Gunnar,

Für eine Person eine prima Lösung, wenn das Dir jetzt alle nachmachen, dann ist der Nutzen wieder dahin.

Nö, es gibt ja noch author:… …

Dann würde ich, soforn du einverstanden bist, dem @@ Club beitreten.

[Gunnar Bittersmann]

@@Karl Heinz

Nö, es gibt ja noch author:… …

Dann würde ich, soforn du einverstanden bist, dem @@ Club beitreten.

Von mir aus gerne.

Das ist natürlich nur ein Hack. Besser wäre es, die Suchfunktion würde das Feature mitbringen: neben author:… auch sowas wie inreplyto:….

@Christian Kruse, wäre das aufwendig?

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

@Christian Kruse, wäre das aufwendig?

Ja.

LG,
CK

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Vorteil […] Nachteil […]

Auf der Webseite fällt der Fehler auf und wird berichtigt: […] Dabei fällt nicht auf, dass der Fehler in JSON-LD auch berichtigt werden müsste. Daten im HTML (auf der Webseite) und in JSON-LD (Auswertung bspw. von Suchmaschinen) weichen voneinander ab.

Wie Chaals sagt (ab 43:41):
“The benefit of RDFa is that it’s marked-up page content, stuff in the page. You look at your page, you change your page, and you see what you’re changing. It doesn’t get forgotten and lost in a corner.
“The benefit of JSON-LD is that it’s JSON.”

LLAP 🖖

[Karl Heinz]

Darüber hinaus müssen Sie entscheiden, ob JSON-LD (empfohlen) oder Mikrodaten besser für Sie geeignet sind.

Nehmen wir mal an ich entscheide mich für Mikrodaten und packe folgendes Markup auf die Arikelseite eines T-Shirts:

<span itemscope itemtype="http://schema.org/Product" class="microdata">
  <meta itemprop="image" content="t-shirt-blau-xl.png">
  <meta itemprop="name" content="T-Shirt blau XL">
  <meta itemprop="description" content="Tolles blaues T-Shirt">
  <meta itemprop="gtin" content="1111111111111">
  <span itemprop="offers" itemscope itemtype="http://schema.org/Offer">
    <meta itemprop="price" content="29.99">
    <meta itemprop="priceCurrency" content="EUR">
    <meta itemprop="availability" content="5"> 
  </span>
</span>

Gehen wir davon aus, das T-Shirt gibt es auf der gleichen Landingpage noch in anderen Varianten z.B. neben blau auch in gelb und grün und neben XL auch in M und L.

Muss ich dann den obigen Code-Block für jede Variante extra in den Quellcode packen.

Ingesamt demnach neunmal?

1. Blau / M
2. Blau / L
3. Blau / XL
4. Gelb / M
5. Gelb / L
6. Gelb / XL
7. Grün / M
8. Grün / L
9. Grün / XL

[Gunnar Bittersmann]

@@Karl Heinz

Gehen wir davon aus, das T-Shirt gibt es auf der gleichen Landingpage noch in anderen Varianten z.B. neben blau auch in gelb und grün und neben XL auch in M und L.

Ist nicht jede Variante ein anderes Product – auch mit jeweils eigener GTIN?

Muss ich dann den obigen Code-Block für jede Variante extra in den Quellcode packen.

Ingesamt demnach neunmal?

Würd ich sagen, ja.

Die Produktnamen sind ja auch unterschiedlich, die Beschreibungen, die Bilder, die Verfügbarkeit, …

LLAP 🖖

[Karl Heinz]

Hallo Gunnar,

Gehen wir davon aus, das T-Shirt gibt es auf der gleichen Landingpage noch in anderen Varianten z.B. neben blau auch in gelb und grün und neben XL auch in M und L.

Ist nicht jede Variante ein anderes Product – auch mit jeweils eigener GTIN?

Jede Variante hat seine eigene GTIN.

In diesem Google Beitrag

steht folgendes:

Befinden sich mehrere Angebote auf der Seite, muss jedes Angebot mit einer Artikelnummer oder GTIN versehen sein und das entsprechende Angebot in Ihren Google Shopping-Produktdaten muss die gleiche Artikelnummer (Attribut 'id') bzw. die gleiche GTIN (Attribut 'gtin') aufweisen. Dies kann sinnvoll sein, wenn mehrere Varianten des gleichen Produkts – z. B. unterschiedliche Größen oder Farben – auf der gleichen Zielseite angezeigt werden.

Das bedeutet wohl man muss (bezogen auf mein Beispiel) neunmal den Code-Block integrieren. Anders geht es ja nicht.