32

I am really confused what is @id used for in json-ld syntax. Sample from apple.com. What does @id actually represent. Any help would be great?

<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"
    ]
}

Improve this question

2 Answers 2

Reset to default
40

The @id keyword allows you to give a node a URI. This URI identifies the node.

See Node Identifiers in the JSON-LD spec.

(The equivalent in Microdata is the itemid attribute, and the equivalent in RDFa Lite is the resource attribute.)

Why are identifiers useful?

  • You can reference a node instead of repeating it (see my example).
  • Other authors can do the same (on external sites): when they use the URI you specified, it’s clear that they are talking about the same thing.
  • Consumers can learn that different nodes are about the same thing.

It’s also one of the core concepts of Linked Data and the Semantic Web. If you care about this, you might want to use URIs that differentiate between the actual thing and the page about that thing (see my explanation).

This is what Apple is doing in the example. The URI http://www.apple.com/#organization represents the actual organization, not a page (and not a part on that page) about the organization. This is a Hash URL, and it’s a popular way to make the distinction between the thing and the page about the thing. If you want to say in your JSON-LD that you like Apple, you could use http://www.apple.com/#organization to identify Apple. If you would use http://www.apple.com/ instead, it would be Apple’s homepage you like.

Improve this answer
3
  • Trying to understand your last paragraph, so, a page should have both '@id' and 'url' same values? I was thinking that if we provide 'url', then we can have hash based id. That helps keep things uniform across.
    – Ethan Collins
    Jun 5, 2019 at 22:16
  • 1
    @EthanCollins: It’s a good practice to provide both (@id and url), yes. In the case of pages, they would typically have the same URI as value; in the case of other items, they would typically have different URIs as value (@id for the thing, url for the page about that thing). -- To be sure that we’re on the same page: With hash-based ID, you mean Hash URLs in the context of Linked Data, not in the context of single-page applications / JavaScript-based sites, right?
    – unor
    Jun 6, 2019 at 14:11
  • Thanks for clarifying. I also got to have a look at the other useful links you shared in your answers, it's much clearer now. (to answer your last query, yes I wanted to mean hash URIs).
    – Ethan Collins
    Jun 6, 2019 at 16:57
8

Reading the following link from Google Developers - Data types - Local Business in the Local business properties section you have:

[...] The ID should be stable and unchanging over time. Google Search treats the URL as an opaque string and it does not have to be a working link. If the business has multiple locations, make sure the @id is unique for each location.

The @id is for almost all object

I hope my answer helps you :)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.