Balisage Schema.org sécurisé et non sécurisé?

Est-il possible d'avoir schema.org itemtypepour les ports sécurisés et non sécurisés? Je gère un site statique créé à Jekyll et j'implémente Schema.org sur les pages individuelles. En conséquence, j'essaie d'utiliser les éléments suivants:

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

Cela ne valide pas avec l' outil de test de données structurées de Google . Il n'enregistre pas les éléments comme existants. Existe-t-il un bon moyen d'implémenter Schema.org dans une page statique hébergée sur les ports SSL et non SSL?

https microdata jekyll

— Jack M.
source

Je suis confus, qu'est-ce qui ne fonctionne pas? semble bien fonctionner ... google.com/webmasters/tools/…

— Simon Hayter

Les extraits riches seront toujours renvoyés http://www.example.comlors de l'utilisation des deux /file.pngou du sélecteur de protocole //car il ne connaît pas le domaine car le test est exécuté sur leur serveur pas le vôtre ... J'ai peut-être mal compris la question. Personnellement, j'appliquerais le SSL indépendamment des pages non saisies comme de nombreuses entreprises et sites Web le font de nos jours, ou si vous êtes capable d'utiliser PHP, vous pouvez utiliser une variable PHP pour ajouter https ou http en fonction de l'URL à laquelle vous avez accédé pour la première fois, peu comment cela peut vraiment être fait.

— Simon Hayter

J'avais utilisé le mauvais nom pour l'outil. Impossible d'écouter et de taper en même temps. J'entre en fait l' https://URL dans l'outil de test de données structurées, et il revient avec des erreurs. Les navigateurs se plaignent également de données non sécurisées dans une page sécurisée lorsque j'y teste.

— Jack M.

Avez-vous une URL de test pour que je puisse y jeter un œil?

— Simon Hayter

En règle générale, les agents utilisateurs ne déréférenceraient pas ces URI.

L'utilisation d'URI HTTP Schema.org sur un site HTTPS ne devrait poser aucun problème. En fait, de nombreux autres vocabulaires (utilisés pour les microdonnées ou RDFa) ne fournissent que des URI HTTP, vous n'avez donc pas le choix. Je dirais même que c'est une mauvaise pratique de fournir plusieurs URI de vocabulaire pour le même concept, car les consommateurs pourraient ne pas chercher et "comprendre" toutes les variantes.

Je recommande d'utiliser la variante HTTP pour Schema.org dans votre balisage, car:

Le schéma de base " représentation canonique de la machine " Schema.org définit uniquement les URI HTTP.
La variante HTTP est préférée en fonction de ce problème dans le Schema.org GitHub :

[…] Sur la base que nous préférons voir le canonique « http://schema.org/Person » largement utilisé, mais si quelqu'un demande le https, nous allons le lui donner.
Tous les exemples, même sur les pages HTTPS, utilisent HTTP (voir, par exemple, les exemples sur https://schema.org/Person ).
Dans le contexte initial de RDFa , seule la variante HTTP est définie, donc la plupart des RDFa utiliseront probablement la variante HTTP.

Mise à jour 2015-11 : avec la version 2.2 , une entrée FAQ a été ajoutée:

Q: Devrions-nous écrire https://schema.orgou http://schema.orgdans notre balisage?

En résumé:

HTTPS est désormais également explicitement pris en charge.
Dans le futur, le site utilisera HTTPS par défaut, et pour les exemples, les URL avec HTTPS seront préférées.
Les deux variantes peuvent être utilisées:

les deux https://schema.orget http://schema.orgvont bien

— unor
source

Cette réponse est trompeuse en ce qui concerne schema.org. Il est vrai que la FAQ 19 dit que les https:IRI sont pris en charge, mais en vérité, ils ne sont pas pris en charge en tant http:qu'IRI. Une application va résoudre l'IRI pour en savoir plus sur le terme. La page Web trouvée contient des attributs RDFa pour faciliter cela, mais ils se réfèrent tous aux http:versions, qu'elles aient été récupérées via HTTP ou HTTPS. Cela signifie que les applications rencontrant le https:formulaire sont considérablement désavantagées.

— richard

@richard: Oui, c'est ce que je décris dans la première partie de ma réponse. Cependant, Schema.org ne semble pas se soucier beaucoup du monde du Web sémantique / des données liées - quand ils disent "support", cela signifie: les auteurs peuvent utiliser des URI HTTPS, parce que les sponsors Schema.org (c'est-à-dire les moteurs de recherche ) (et probablement beaucoup plus de consommateurs, car Schema.org est bien connu / populaire) le soutiennent également. Pour utiliser les données décrites avec Schema.org, ils ne doivent utiliser la définition de RDF, et s'ils le font, il est facile pour eux de faire les variantes HTTPS équivalent. Ce serait bien de refléter cela dans le RDF, mais pas obligatoire.

— unor

Schema.org n'est pas le seul à minimiser la base RDF par rapport à sa norme: Dublin Core fait de même. C'est parce que RDF a eu une mauvaise presse, en grande partie à cause des premières utilisations du format RDF / XML (par exemple dans RSS 1.0). Mais Schema.org est construit sur RDF, et si vous creusez, ils le reconnaissent en publiant des définitions RDF de leurs vocabulaires. Certains analyseurs le traiteront comme RDF tandis que d'autres le traiteront comme un ensemble d'attributs personnalisés et d'IRI. Les deux approches ont des avantages et aucune n'est fausse. Mais l'utilisation des https:IRI pénalise les applications faisant les premières sans gain.

— richard

@richard: Je suis d'accord, c'est pourquoi je recommande toujours d'utiliser leurs URI HTTP.

— unor