À quoi sert @id dans la syntaxe json-ld?

16

Je suis vraiment confus à quoi @idsert la syntaxe json-ld. Échantillon sur apple.com. Que @idreprésente réellement. Toute aide est la bienvenue?

<script type="application/ld+json">
{
    "@context": "http://schema.org",
    "@id": "http://www.apple.com/#organization",
    "@type": "Organization",
    "url": "http://www.apple.com/",
    "logo": "https://www.apple.com/ac/structured-data/images/knowledge_graph_logo.png?201608191052",
    "contactPoint": [
        {
            "@type": "ContactPoint",
            "telephone": "+1-800-692-7753",
            "contactType": "sales",
            "areaServed": [ "US" ]
        }
    ],
    "sameAs": [
        "http://www.wikidata.org/entity/Q312",
        "https://www.youtube.com/user/Apple",
        "https://www.linkedin.com/company/apple"
    ]
}

schema.org json-ld

— Ishan
source

27

le @id mot-clé vous permet de donner un URI à un nœud. Cet URI identifie le nœud.

Voir Identificateurs de nœud dans la spécification JSON-LD.

(L'équivalent en microdonnées est le itemid attribut, et l'équivalent dans RDFa Lite est l' resourceattribut.)

Pourquoi les identifiants sont-ils utiles?

Vous pouvez référencer un nœud au lieu de le répéter ( voir mon exemple ).
D'autres auteurs peuvent faire de même (sur des sites externes): lorsqu'ils utilisent l'URI que vous avez spécifié, il est clair qu'ils parlent de la même chose.
Les consommateurs peuvent apprendre que différents nœuds sont à peu près la même chose.

C'est également l'un des concepts fondamentaux des données liées et du Web sémantique. Si vous vous souciez de cela, vous voudrez peut-être utiliser des URI qui différencient la chose réelle et la page à propos de cette chose ( voir mon explication ).

C'est ce que fait Apple dans l'exemple. L'URI http://www.apple.com/#organizationreprésente l'organisation réelle, pas une page (et pas une partie de cette page) sur l'organisation. Il s'agit d'une URL de hachage , et c'est un moyen populaire de faire la distinction entre la chose et la page sur la chose. Si vous voulez dire dans votre JSON-LD que vous aimez Apple, vous pouvez utiliser http://www.apple.com/#organizationpour identifier Apple. Si vous l'utilisiez à la http://www.apple.com/place, ce serait la page d'accueil d'Apple que vous aimez.

— unor
source

Essayer de comprendre votre dernier paragraphe, donc, une page devrait avoir les mêmes valeurs '@id' et 'url'? Je pensais que si nous fournissons «url», nous pouvons avoir un identifiant basé sur le hachage. Cela aide à garder les choses uniformes.

— Ethan Collins

1

@EthanCollins: C'est une bonne pratique de fournir à la fois ( @idet url), oui. Dans le cas des pages, elles auraient généralement le même URI que valeur; dans le cas d'autres éléments, ils auraient généralement des URI différents comme valeur ( @idpour la chose, urlpour la page à propos de cette chose). - Pour être sûr que nous sommes sur la même page: avec l'ID basé sur le hachage, vous voulez dire les URL de hachage dans le contexte des données liées, pas dans le contexte des applications d'une seule page / des sites JavaScript, non?

— unor

Merci de clarifier. J'ai également pu jeter un œil aux autres liens utiles que vous avez partagés dans vos réponses, c'est beaucoup plus clair maintenant. (pour répondre à votre dernière requête, oui, je voulais dire les URI de hachage).

— Ethan Collins

7

En lisant le lien suivant de Google Developers - Types de données - Entreprise locale dans la section Propriétés de l'entreprise locale que vous avez:

[...] L'ID doit être stable et immuable dans le temps. La recherche Google traite l'URL comme une chaîne opaque et il ne doit pas nécessairement s'agir d'un lien fonctionnel. Si l'entreprise possède plusieurs emplacements, assurez-vous que le @id est unique pour chaque emplacement.

Le @id est pour presque tous les objets

J'espère que ma réponse vous aidera :)

— benetj
source