Je pense que ces champs @id sont censés être des URL valides, car W3.org dit :
Pour pouvoir référencer des nœuds externes dans un graphe, il est important que les nœuds aient un identifiant. Les IRI sont un concept fondamental des Linked Data, pour que les nœuds soient réellement liés, le déréférencement de l’identifiant devrait aboutir à une représentation de ce nœud. Cela peut permettre à une application de récupérer des informations supplémentaires sur un nœud.
Je me demande si c’est un problème avec la façon dont le validateur affiche l’id. D’après ce que je peux dire, l’id est extrait du balisage et n’est pas quelque chose que nous définissons nous-mêmes, par exemple :
Si vous cliquez sur cette section d’id dans le validateur, elle met correctement en surbrillance la publication avec l’id correspondant… donc il semble que le validateur puisse l’identifier correctement.
Je remarque ce comportement sur d’autres sites avec des valeurs @id, par exemple dans les données de schéma de cette question stackoverflow.com :
C’est intéressant. Je n’avais pas pensé à vérifier le code source HTML et j’avais juste supposé que c’était du JSON-LD.
Google utilise des données de schéma, mais je ne suis pas sûr s’ils utilisent celui-ci en particulier. La documentation de schema.org n’est pas très claire.
Il semble que Discourse place plusieurs DiscussionForumPosting sur chaque sujet, mais l’exemple dans la documentation ressemble à DiscussionForumPosting pourrait être destiné à se référer uniquement au sujet principal et non aux commentaires ? La documentation liste un champ comment avec un Comment (singulier) bien que la description soit formulée au pluriel.
Je viens de regarder comment Invison le fait et il utilise du JSON-LD, plaçant des objets Comment dans un champ comment. Il semble que ce soit beaucoup de texte supplémentaire à envoyer au navigateur.
Je ne connais pas la réponse, mais j’essaierai de faire plus de recherches plus tard.
Je traîne sur ce forum, ce qui est pratique. Je possède le code Google qui analyse cela.
Le fil de discussion lié est une bonne réponse à la digression du commentaire. Je vais aborder le reste ici.
Il est essentiellement non standard d’interpréter les attributs d’ID HTML comme des ID de nœuds. Cela a été fait dès le début de l’analyse du microdonnées par Google, probablement pour des raisons floues. Vous êtes censé utiliser itemid si vous voulez le faire explicitement. J’espère supprimer ce hack un jour, mais il est difficile de retirer quelque chose comme ça sans pertes.
Deuxièmement, les IRI ne doivent pas nécessairement être résolubles. C’est une suggestion du W3C, mais de nombreux IRI ne le sont pas et Google ne l’exige certainement pas.
Ce n’est un problème que si cela provoque la fusion involontaire de nœuds dans les données structurées, comme si vous utilisiez un itemid de la même valeur ailleurs dans le HTML. Sinon, c’est juste une bizarrerie qui peut être ignorée.
Oh, et s’il vous plaît, ne passez pas à JSON-LD. Honnêtement, c’est préférable pour le balisage riche en texte comme les forums. Avoir à dupliquer le contenu textuel est idiot. C’est juste plus facile à écrire, c’est pourquoi nous le poussons.
