¿Marcado seguro y no seguro de Schema.org?

¿Es posible tener schema.org itemtypes para puertos seguros e inseguros? Ejecuto un sitio estático creado en Jekyll , y estoy implementando Schema.org en las páginas individuales. Como resultado, estoy tratando de usar lo siguiente:

<div itemscope itemtype="//schema.org/Organization">
    <a itemprop="url" class="navbar-brand" href="https://webmasters.stackexchange.com/">
        <img itemprop="logo" src="/images/logo.png">
    </a>
</div>

Esto no se valida con la herramienta de prueba de datos estructurados de Google . No registra los elementos como existentes. ¿Hay una buena manera de implementar Schema.org en una página estática alojada en puertos SSL y no SSL?

https microdata jekyll

— Jack M.
fuente

Estoy confundido, ¿qué no funciona? parece estar funcionando bien ... google.com/webmasters/tools/…

— Simon Hayter

Los fragmentos enriquecidos siempre volverán http://www.example.comal usar ambos /file.pngo el selector de protocolo //porque no conoce el dominio ya que la prueba se está ejecutando en su servidor, no en el suyo ... Tal vez he entendido mal la pregunta. Personalmente, haría cumplir el SSL independientemente de las páginas sin entrada, como lo hacen muchas empresas y sitios web hoy en día, o si puede usar PHP, entonces podría usar una Variable PHP para agregar https o http dependiendo de la URL a la que se accedió por primera vez, pocos maneras en que esto se puede hacer realmente.

— Simon Hayter

Había usado un nombre incorrecto para la herramienta. No puedo escuchar y escribir al mismo tiempo. En realidad estoy ingresando la https://URL en la Herramienta de prueba de datos estructurados, y está volviendo con errores. Los navegadores también se quejan de datos inseguros en una página segura cuando pruebo allí.

— Jack M.

¿Tienes una URL de prueba para que pueda echar un vistazo?

— Simon Hayter

Por lo general, los agentes de usuario no desreferenciarían estos URI.

No debería haber absolutamente ningún problema en usar los URI HTTP de Schema.org en un sitio HTTPS. De hecho, muchos otros vocabularios (utilizados para Microdata o RDFa) solo proporcionan URI de HTTP, por lo que no tiene otra opción. Incluso diría que es una mala práctica proporcionar URI de vocabulario múltiple para el mismo concepto, ya que los consumidores podrían no buscar y "comprender" todas las variantes.

Recomiendo usar la variante HTTP para Schema.org en su marcado, porque:

El esquema central de " representación de máquina canónica " Schema.org define solo los URI de HTTP.
Se prefiere la variante HTTP de acuerdo con este problema en Schema.org GitHub :

[...] sobre la base de que preferimos ver el canónico ' http://schema.org/Person ' en uso generalizado, pero si alguien solicita el https, entonces se lo daremos.
Todos los ejemplos, incluso en las páginas HTTPS, usan HTTP (ver, por ejemplo, los ejemplos en https://schema.org/Person ).
En el contexto inicial de RDFa , solo se define la variante HTTP, por lo que probablemente la mayoría de RDFa usará la variante HTTP.

Actualización 2015-11 : con la versión 2.2 , se agregó una entrada de preguntas frecuentes:

P: ¿Deberíamos escribir https://schema.orgo http://schema.orgen nuestro marcado?

En resumen:

HTTPS ahora también es explícitamente compatible.
En algún momento en el futuro, el sitio usará HTTPS de forma predeterminada, y para los ejemplos se preferirán las URL con HTTPS.
Se pueden usar ambas variantes:

ambos https://schema.orgy http://schema.orgestán bien

— unor
fuente

Esta respuesta es engañosa con respecto a schema.org. Es cierto que la pregunta frecuente 19 dice que los https:IRI son compatibles, pero en realidad no son compatibles como http:IRI. Una aplicación va a resolver el IRI para obtener más información sobre el término. La página web que encuentra contiene atributos RDFa para facilitar esto, pero todos se refieren a las http:versiones, independientemente de si se obtuvo a través de HTTP o HTTPS. Esto significa que las aplicaciones que encuentran el https:formulario están en desventaja significativa.

— richard

@richard: Sí, esto es lo que describo en la primera parte de mi respuesta. Sin embargo, a Schema.org no parece importarle mucho el mundo de la Web Semántica / Datos Vinculados: cuando dicen "soporte", significa que los autores pueden usar URI HTTPS, porque los patrocinadores de Schema.org (es decir, los motores de búsqueda ) (y probablemente muchos más consumidores, ya que Schema.org es conocido / popular) también lo respaldan. Para hacer uso de los datos descritos con Schema.org, no tienen que usar su definición RDF, y si lo hacen, es fácil para ellos hacer que las variantes HTTPS sean equivalentes. Sería bueno reflejar esto en el RDF, pero no es obligatorio.

— hasta el

Schema.org no está solo en minimizar la base RDF a su estándar: Dublin Core hace lo mismo. Esto se debe a que RDF ha tenido una mala prensa, en gran parte como resultado de los primeros usos del formato RDF / XML (por ejemplo, en RSS 1.0). Pero Schema.org se basa en RDF, y si cavas, lo reconocen publicando definiciones RDF de sus vocabularios. Algunos analizadores lo tratarán como RDF, mientras que otros lo tratarán como un conjunto de atributos personalizados e IRI. Ambos enfoques tienen ventajas y ninguno está mal. Pero el uso de https:IRI penaliza las aplicaciones que realizan las primeras sin ganancia.

— richard

@richard: Estoy de acuerdo, por eso todavía recomiendo usar sus URI de HTTP.

— hasta el