2015-06-09 10 views
35

Sono curioso della migliore pratica per applicare JSON-LD su un sito per schema.org.Migliori pratiche JSON-LD: utilizzando più elementi <script>?

Se ho una pagina con un Article e voglio anche definire WebSite sulla mia pagina, avrei questo:

<script type="application/ld+json"> 
{ 
    "@context": "http://schema.org", 
    "@type": "WebSite", 
    "url": "http://www.example.com/", 
    "potentialAction": { 
     "@type": "SearchAction", 
     "target": "http://www.example.com/search?&q={query}", 
     "query-input": "required" 
    } 
} 
</script> 

<!- … --> 

<script type="application/ld+json"> 
{ 
    "@context": "http://schema.org", 
    "@type": "Article", 
    "author": "John Doe", 
    "interactionCount": [ 
    "UserTweets:1203", 
    "UserComments:78" 
    ], 
    "name": "How to Tie a Reef Knot" 
} 
</script> 

È questo corretto o sbagliato? C'è qualche vantaggio o bisogno di unirli nello stesso script o array di elementi?

+0

leggere questo https://www.w3.org/TR/json-ld/#h3_advanced-context -usage, basta usare una semplice lista – hsrv

risposta

23

È valido. Puoi avere tanti blocchi di dati (= script elementi) come desideri.

Un possibile vantaggio di utilizzare un solo elemento script: permette di rendere le relazioni tra gli oggetti multipli più facile (per esempio, se si decide di utilizzare hasPart o mainEntity), come avete semplicemente di nidificare gli elementi.
Tuttavia, rendere queste relazioni è ovviamente possibile anche quando si utilizzano blocchi dati separati, facendo riferimento all'URI dell'articolo con @id (thanks, @ Gregg Kellogg).

(Per riferimento, adding two or more top-level items in a single script è possibile con @graph.)

+5

Puoi anche legare insieme i nodi nel blocco di script JSON-LD usando @id. Dal punto di vista del modello, vengono tutti trattati come triple in un grafico comune. Tuttavia, i motori di ricerca possono "ottimizzare" e non così quello che ti aspetti. Utilizzando algoritmi JSON-LD probabilmente non c'è una buona ragione per usare blocchi di script separati; basta unirle in un oggetto comune o anche in una matrice di oggetti. –

+0

@GreggKellogg e unor - Grazie per le risposte! La mia preoccupazione principale era dovuta ai limiti di un CMS, dal momento che WebSite è qualcosa che specificherò a livello globale e l'articolo è specificato a livello di pagina. Non ero abbastanza sicuro di cosa aspettarmi in questo scenario. Lo strumento Strutturato per i dati di Google è ok, ma io sono sempre un po 'scettico lì :) –

+0

@GreggKellogg quindi è il 2017, la raccomandazione ora è' @ graph' o una serie di oggetti? La discussione pertinente è stata fatta nel 2012 (https://github.com/json-ld/json-ld.org/issues/96), e il consenso da parte mia è stato '@ graph' per più oggetti di primo livello. Grazie in anticipo. –

23

Non v'è alcun vantaggio ad avere blocchi di dati singoli o multipli, diversi da limitazioni intorno a come si potrebbe archiviare e gestire i dati dello schema nel tuo sito web.

Ad esempio, potrebbe essere necessario separarli se componenti diversi all'interno del sito Web sono responsabili della generazione di ciascun blocco di dati in modo indipendente. In alternativa, se il tuo sito web è in grado di gestire tutti gli schemi per una pagina in un unico posto, potrebbe essere più semplice gestire un singolo blocco di dati e renderlo come un singolo elemento script.

È possibile combinare questi in un singolo script elencando ogni schema come un array come questo:

<script type="application/ld+json"> 
[ 
    { 
    "@context": "http://schema.org", 
    "@type": "WebSite", 
    "url": "http://www.example.com/", 
    "potentialAction": { 
     "@type": "SearchAction", 
     "target": "http://www.example.com/search?&q={query}", 
     "query-input": "required" 
    } 
    }, 
    { 
    "@context": "http://schema.org", 
    "@type": "Article", 
    "author": "John Doe", 
    "interactionCount": [ 
     "UserTweets:1203", 
     "UserComments:78" 
    ], 
    "name": "How to Tie a Reef Knot" 
    } 
] 
</script>