¿Para qué sirve @id en la sintaxis json-ld?

16

Estoy realmente confundido para qué se @idusa en la sintaxis json-ld. Muestra de apple.com. Lo que @idrealmente representa. ¿Alguna ayuda sería genial?

<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
fuente

26

La @idpalabra clave le permite asignar un URI a un nodo. Este URI identifica el nodo.

Consulte Identificadores de nodo en la especificación JSON-LD.

(El equivalente en Microdata es el itemidatributo, y el equivalente en RDFa Lite es el resourceatributo).

¿Por qué son útiles los identificadores?

Puede hacer referencia a un nodo en lugar de repetirlo ( consulte mi ejemplo ).
Otros autores pueden hacer lo mismo (en sitios externos): cuando usan el URI que especificó, está claro que están hablando de lo mismo.
Los consumidores pueden aprender que diferentes nodos son casi lo mismo.

También es uno de los conceptos centrales de Linked Data y la Web Semántica. Si le importa esto, es posible que desee utilizar URI que diferencien entre la cosa real y la página sobre esa cosa ( vea mi explicación ).

Esto es lo que Apple está haciendo en el ejemplo. El URI http://www.apple.com/#organizationrepresenta la organización real, no una página (y no una parte de esa página) sobre la organización. Esta es una URL Hash , y es una forma popular de hacer la distinción entre la cosa y la página sobre la cosa. Si quiere decir en su JSON-LD que le gusta Apple, puede usarlo http://www.apple.com/#organizationpara identificar Apple. Si lo http://www.apple.com/usaras, sería la página de inicio de Apple que te gusta.

— unor
fuente

Tratando de entender su último párrafo, entonces, ¿una página debe tener los mismos valores '@id' y 'url'? Estaba pensando que si proporcionamos 'url', entonces podemos tener una identificación basada en hash. Eso ayuda a mantener las cosas uniformes.

— Ethan Collins

1

@ EthanCollins: es una buena práctica proporcionar ambos ( @idy url), sí. En el caso de las páginas, normalmente tendrían el mismo URI como valor; en el caso de otros elementos, normalmente tendrían diferentes URI como valor ( @idpara la cosa, urlpara la página sobre esa cosa). - Para estar seguros de que estamos en la misma página: con la identificación basada en hash, te refieres a URL de hash en el contexto de datos vinculados, no en el contexto de aplicaciones de una sola página / sitios basados en JavaScript, ¿verdad?

— hasta el

Gracias por aclararlo. También pude echar un vistazo a los otros enlaces útiles que compartiste en tus respuestas, ahora es mucho más claro. (para responder a su última consulta, sí, quería decir URI hash).

— Ethan Collins

7

Leyendo el siguiente enlace de Google Developers - Tipos de datos - Negocio local en la sección Propiedades del negocio local que tiene:

[...] La identificación debe ser estable e inmutable con el tiempo. La Búsqueda de Google trata la URL como una cadena opaca y no tiene que ser un enlace de trabajo. Si la empresa tiene varias ubicaciones, asegúrese de que el @id sea único para cada ubicación.

El @id es para casi todos los objetos.

Espero que mi respuesta te ayude :)

— benetj
fuente