web-dev-qa-db-fra.com

Lorsqu'une page Web (ou un type similaire) utilise un identifiant qui correspond à un identifiant de fil d'Ariane, pourquoi la page Web fait-elle partie de la liste de navigation?

Est-ce ce qui est censé se passer? Si oui, pourquoi?

Voici un exemple ( code de test ici ):

<script type="application/ld+json">
{
    "@context": "http://schema.org",
    "@type": "WebPage",
    "@id": "http://example.com/"
}
</script>
<script type="application/ld+json">
{
 "@context": "http://schema.org",
 "@type": "BreadcrumbList",
 "itemListElement":{
   "@type": "ListItem",
   "position": 1,
   "item":{
    "@id": "http://example.com/",
    "name": "Lecture 12: Graphs, networks, incidence matrices"
    }
  }
}
</script>
3
John R Perry

Oui, je pense qu’il est logique que la SDTT de Google le fasse. C’est juste une question de facilité d’utilisation si l’élément WebPage doit également être affiché comme élément de niveau supérieur; cela n’affecte pas la sémantique.

Dans le premier bloc de données script, vous indiquez que WebPage a l'URI http://example.com/. Dans le deuxième bloc de données script, vous indiquez que la valeur de la propriété item a le même URI, http://example.com/.
Étant donné que ces deux éléments ont le même URI, ils doivent être identiques.

Vous pouvez utiliser la propriété _ (breadcrumb) pour indiquer clairement que la BreadcrumbList appartient à la WebPage:

<script type="application/ld+json">
{
 "@context": "http://schema.org",
 "@type": "WebPage",
 "@id": "http://example.com/",
 "breadcrumb": {
   "@type": "BreadcrumbList",
   "itemListElement":{
     "@type": "ListItem",
     "position": 1,
     "item":{
      "@id": "http://example.com/",
      "name": "Lecture 12: Graphs, networks, incidence matrices"
      }
    }
  }
}
</script>

Comme vous pouvez le voir dans le SDTT, les propriétés que vous fournissez pour la propriété item seront affichées sous l'élément de niveau supérieur WebPage.

(NB: le SDTT de Google semble être bogué dans les cas où différents types sont fournis pour le même URI.)

3
unor

Pensez à ID en tant que variable globale, la première fois que vous "déclarez" sa valeur, cette valeur est définie dans le document et "restitue" la valeur donnée partout où vous appelez l'ID.

<script type="application/ld+json">
{
    "@context": "http://schema.org",
    "@type": "WebPage",
    "@id": "http://example.com/" *here you give ID a value*
}
</script>
<script type="application/ld+json">
{
 "@context": "http://schema.org",
 "@type": "BreadcrumbList",
 "itemListElement":{
   "@type": "ListItem",
   "position": 1,
   "item":{
    "@id": "http://example.com/", *here you just "paste" the given value*
    "name": "Lecture 12: Graphs, networks, incidence matrices"
    }
  }
}
</script>

C'est pourquoi vous obtenez littéralement une URL complète dans un fil d'Ariane.

En fait, les identifiants devraient être TRÈS cohérent domainwise afin de lever l’ambiguïté des entités et d’épargner réellement l’effort de devoir déclarer une fois et l’autre la même chose, comme répéter plusieurs fois une URL de page d’accueil ou très probablement une adresse postale si vous faites du contenu sur LocalBusiness et d’autres types d’organisation.

Un gros avantage est que d'autres auteurs peuvent référencer cet identifiant à partir de sites/domaines extrnaux et même dans ce cas, il s'agira d'une relation univoque. Pensez grand, un peu comme si vous construisiez un lien sémantique.

Vous pouvez trouver un exemple de travail dans page de contact ZeClinics où je divise les 2 locaux de la société afin de créer un précédent à rappeler ultérieurement RDF et sur la base de l'évolution du schéma.

En outre, si vous utilisez un système de gestion de contenu pour la maintenance de sites Web, je vous conseillerais peut-être de mettre en place Breadcrumb avec RDFa (mon préféré contre microdonnées) et de garder cette trace en dehors des scripts JSON-LD, beaucoup plus souples (et donc complexes).

Ceci est absolument courant dans de nombreux WP thèmes, par exemple.
S'amuser!

0
seofreelance