Theoretically, it’s sufficient to specify only the @id
:
"author": {"@id": "http://example.com/about/#bob"}
If a consumer already knows the entity with this @id
URI (e.g., after having crawled the "about" page), they don’t need to see its properties here again.
If a consumer doesn’t already know the entity with this URI, they have the chance to learn more about it by visiting the URL and looking for an entity with the @id
URI.
In practice, however, consumers don’t necessarily 1) remember which entities they found, and/or 2) visit referenced URLs. For example, if the consumer is a search engine, they might only care about what’s on the current page (e.g., because they want to display a rich result for it), ignoring every reference to other pages for this context.
So, it can be good idea to provide more data about a referenced entity.
If you know that a consumer expects certain properties on the current page, you should of course provide (at least) these. For example, Google’s Article rich result for AMP pages requires the type and name
of an author.
If you don’t know what possible consumers expect, I think it makes sense to always provide at least the URI (@id
) and type (@type
) as well as the Schema.org properties name
and url
.
"author": {
"@type": "Person",
"@id": "http://example.com/about/#bob",
"url": "http://example.com/about/#author-bob",
"name": "Bob"
}
(@id
and url
have different values, because @id
represents the actual person, while url
represents the page (or page section) about this person.)
@id
for a book in the library page?