¿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

Respuestas:

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