Markup Schema.org sicuro e non sicuro?

È possibile avere schemi.org itemtypeper porte sicure e non sicure? Gestisco un sito statico realizzato in Jekyll e sto implementando Schema.org nelle singole pagine. Di conseguenza, sto cercando di utilizzare quanto segue:

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

Ciò non è valido con lo strumento di test dei dati strutturati di Google . Non registra gli articoli come esistenti. Esiste un buon modo per implementare Schema.org in una pagina statica ospitata su porte SSL e non SSL?

https microdata jekyll

— Jack M.
fonte

Sono confuso, cosa non funziona? sembra funzionare bene ... google.com/webmasters/tools/…

— Simon Hayter

I rich snippet torneranno sempre http://www.example.comquando si utilizzano entrambi /file.pngo il selettore di protocollo //perché non conosce il dominio poiché il test viene eseguito sul loro server e non sul tuo ... Forse ho frainteso la domanda. Personalmente imporrei l'SSL indipendentemente dalle pagine non di input come molte aziende e siti Web stanno facendo al giorno d'oggi a prescindere, o se si è in grado di utilizzare PHP, è possibile utilizzare una variabile PHP per aggiungere https o http a seconda dell'URL a cui si accede per la prima volta, pochi modi in cui questo può essere fatto davvero.

— Simon Hayter

Avevo usato il nome sbagliato per lo strumento. Impossibile ascoltare e digitare contemporaneamente. Sto effettivamente inserendo l' https://URL nello Strumento di test dei dati strutturati e sta tornando con errori. I browser si lamentano anche dei dati non sicuri in una pagina protetta quando provo lì.

— Jack M.

Hai un URL di prova in modo che io possa dare un'occhiata?

— Simon Hayter

In genere, gli agenti utente non dovrebbero sottovalutare questi URI.

Non ci dovrebbero essere assolutamente problemi nell'uso degli URI HTTP Schema.org su un sito HTTPS. In effetti, molti altri vocabolari (usati per Microdata o RDFa) forniscono solo URI HTTP, quindi non hai scelta lì. Direi anche che è una cattiva pratica fornire URI di vocabolario multiplo per lo stesso concetto, poiché i consumatori potrebbero non cercare e "comprendere" tutte le varianti.

Consiglio di utilizzare la variante HTTP per Schema.org nel markup, perché:

Lo schema principale della " rappresentazione della macchina canonica " Schema.org definisce solo gli URI HTTP.
La variante HTTP è preferita in base a questo problema nel Schema.org GitHub :

[...] sulla base del fatto che preferiamo vedere il canonico " http://schema.org/Person " in uso diffuso, ma se qualcuno chiede l'https, diamo loro.
Tutti gli esempi, anche sulle pagine HTTPS, utilizzano HTTP (vedere, ad esempio, gli esempi su https://schema.org/Person ).
Nel contesto iniziale di RDFa , viene definita solo la variante HTTP, quindi probabilmente la maggior parte di RDFa utilizzerà la variante HTTP.

Aggiornamento 2015-11 : con la versione 2.2 è stata aggiunta una voce FAQ:

D: Dovremmo scrivere https://schema.orgo http://schema.orgnel nostro markup?

In sintesi:

Anche HTTPS è ora esplicitamente supportato.
In futuro, il sito utilizzerà HTTPS per impostazione predefinita e, per gli esempi, saranno preferiti gli URL con HTTPS.
Entrambe le varianti possono essere utilizzate:

entrambi https://schema.orge http://schema.orgvanno bene

— unor
fonte

Questa risposta è fuorviante rispetto a schema.org. È vero che la FAQ 19 afferma che gli https:IRI sono supportati, ma in realtà non sono supportati come http:IRI. Un'applicazione risolverà l'IRI per scoprire ulteriori informazioni sul termine. La pagina web trovata contiene gli attributi RDFa per facilitare ciò, ma fanno tutti riferimento alle http:versioni, indipendentemente dal fatto che siano state recuperate tramite HTTP o HTTPS. Ciò significa che le applicazioni che incontrano il https:modulo presentano uno svantaggio significativo.

— Richard

@richard: Sì, questo è ciò che descrivo nella prima parte della mia risposta. Tuttavia, Schema.org non sembra preoccuparsi molto del mondo Semantic Web / Linked Data - quando dicono "supporto", significa: gli autori possono usare gli URI HTTPS, perché gli sponsor di Schema.org (cioè i motori di ricerca ) (e probabilmente molti più consumatori, come Schema.org è ben noto / popolare), lo supportano anche. Per utilizzare i dati descritti con Schema.org, non è necessario utilizzare la sua definizione RDF e, se lo fanno, è facile per loro rendere equivalenti le varianti HTTPS. Sarebbe bello riflettere questo nel RDF, ma non è necessario.

— unor

Schema.org non è il solo a minimizzare la base RDF secondo i propri standard: Dublin Core fa lo stesso. Questo perché RDF ha avuto una cattiva stampa, in gran parte a causa dei primi usi del formato RDF / XML (ad esempio in RSS 1.0). Ma Schema.org è basato su RDF e, se scavate, lo riconoscono pubblicando definizioni RDF dei loro vocabolari. Alcuni parser lo tratteranno come RDF, mentre altri lo considereranno un insieme di attributi e IRI personalizzati. Entrambi gli approcci hanno vantaggi e nessuno dei due è sbagliato. Ma l'uso di https:IRI penalizza le applicazioni che fanno il primo senza alcun guadagno.

— Richard

@richard: sono d'accordo, motivo per cui consiglio ancora di usare i loro URI HTTP.

— unor