MicroFormatos

Definição de Web Semântica

No início da internet, tivemos o HTML para criar e marcar o conteúdo. Com ele, que é usado até hoje em todas as páginas existentes, é possível criar textos, links, inserir imagens e tabelas, formulários, e muito mais. Porém a classificação e o uso destes elementos permite apenas funcionalidade e não significado. Um link geralmente assume a forma de um texto ou imagem, que uma vez clicado leva a outra página, mas não diz o significado, a natureza dessa relação. Adicionar significado à relação dos elementos é a idéia principal por trás da semântica na web.

POR QUE É IMPORTANTE?

Para os usuários a diferença não é tão transparente ou mesmo útil no dia a dia. Pouca ou nenhuma funcionalidade nova é agregada para a intereção do usuário. Mas para os buscadores e indexadores, isso faz toda a diferença, e isso sim acaba afetando a qualidade da navegação dos usuários, além das relações comerciais (ou não) entre os próprios sites. Um exemplo seria procurar restaurantes, com determinada faixa de preço, com boa avaliação dos frequentadores, em determinada região. Outro exemplo seria procurar todos os artigos de um determinado autor que estão publicados sob determinada licensa de uso.

Definição de Microformatos

Microformatos são conjuntos de formatos de dados que usam tecnologias e padrões web para contextualizar informações online. As informações publicadas ganham marcações moduladas que levam em conta o seu significado em situações específicas, o que facilita a sua recuperação, seu compartilhamento e sua utilização.

Os microformatos fazem parte da "web semântica", mas ao contrário desta, procuram servir mais aos usuários do que aos programas e sistemas. Como se baseiam na grafia de XHTML, qualquer pessoa com domínio desta linguagem pode criar redes de dados de acordo com suas necessidades. Sua implementação é relativamente simples.

Os microformatos podem representar diversos tipos de conteúdo publicado em páginas web, como pessoas, eventos, links. Sua aplicação faz com que o HTML da página receba marcações compreensíveis por browsers ou ferramentas de busca compatíveis com microformatos.

O uso de microformatos pode permitir que editores de conteúdo eliminem ambiguidades no conteúdo publicado. Por exemplo, a palavra "belo horizonte" deixa de ser uma inserção neutra dentro de um texto e passa a ser reconhecida como o nome de uma cidade. Desta maneira, os resultados das buscas podem ser mais precisos e adaptados às necessidades de cada usuário.

Algumas restrições incluem o fato de que estes formatos ainda não são reconhecidos por todos os browsers. Embora possam ser lidas pelo Firefox, o Internet Explorer 7 não as reconhece (embora a Microsoft inclua esta funcionalidade no IE8).

Outro fator que dificulta a sua implementação é que as páginas precisam ser assinaladas uma a uma, embora já seja possível automatizar algumas etapas do processo.

Há ainda a dificuldade de associar todo o tipo de conteúdo publicado a estes formatos. Informações como bibliografias, por exemplo, ou a programação de filmes ainda não podem ser estruturadas (embora se possa marcar sites de filmes). Mas na medida em que mais editores forem aderindo ao seu uso, os microformatos tenderão a se adaptar a demandas cada vez mais especializadas como estas.

Definição dos microformatos hCard e hCalendar

hCard

A especificação hCard é baseado no padrão internacional conhecido como “vCard”. Trata-se de um arquivo de texto que é implementado em quase todos programas que armazenam informações de contato e qualquer sistema operacional no mundo inteiro. O propósito da especificação hCard é fornecer um padrão para compartilhar informações comerciais de alguém em páginas de HTML e XML e suas linguagens derivadas e pode representar não somente informações pessoais de contato, mas também sobre empresas, grandes corporações e lugares. Estes dados podem ser publicados em páginas web e lidos por aplicativos que compreendem o formato hCard (a ferramenta hCard Creator ajuda na criação). A formatação dos dados é feita através de estilos CSS, pois estes estão definidos por marcações padrões de XHTML.

hCalendar

A especificação hCalendar é baseado no padrão internacional para calendário e informações sobre eventos chamado de “iCalendar”. A lógica é a mesma: um hCalendar é 1:1 (um por um) 100% compatível com o padrão iCalendar utilizado em softwares como o Outlook ou o Google Calendar por exemplo. Assim como o hCard possui o seu “creator”, o hCalendar também possui o seu conhecido como hCalendar Creator. Compartilhar informações de eventos é bem comum, dado esse fato surgiu a necessidade de desenvolver um padrão microformat para se compartilhar informações de eventos.A formatação dos dados também é feita através de estilos CSS.

Aplicar microformats para marcação de contato (hCard), e informações sobre evento (hCalendar).

hCard

Abaixo segue um exemplo de hCard com as principais propriedades inseridas e que são utilizadas no hCard Creator. O que esta em negrito são as propriedades do hCard.

<div class="vcard">

            <img src="http://www.revolucao.etc.br/imagens/foto_henrique_costa_pereira.jpg" alt="photo" class="photo"/>

            <span class="fn n">

                        <span  class="given-name">Henrique</span> <span  class="additional-name">Costa</span> <span class="family-name">Pereira</span>

            </span>

            <div class="org">Visie</div>

            <a class="email" href="mailto:henrique.costapereira@gmail.com">henrique.costapereira@gmail.com</a>

            <div class="adr">

            <div class="street-address">Av Paulista, 1000 - Centro</div>

            <span class="locality">São Paulo</span> ,

            <span class="region">SP</span> ,

            <span class="postal-code">38400-360</span>

            <span class="country-name">Brasil</span>

            </div>

            <div class="tel">9999-9999</div>

</div>

vcard: é a propriedade obrigatória que identifica qual a especificação que está sendo utilizada. Todas as especificações microformats começam com uma tag e uma propriedade que envolve todas as outras no formato de “pai e filho”, exatamente como no exemplo acima. Todas as outras propriedades são filho da propriedade vcard, ou seja, devem ser devidamente aninhadas dentro de uma estrutura que contenha a classe “vcard” como no exemplo dado anteriormente. As sub-propriedades podem ter ainda outras propriedades dependentes dela como no caso da propriedade “adr”. Se observar a propriedade “street-address”, ela é filha da propriedade “adr”, que por sua vez é filha direta da propriedade “vcard”.

photo: significa “foto” :D . Esta propriedade geralmente é utilizada na tag <img> que contém a foto da pessoa do hCard. Este é um daqueles casos em que não faz nenhum sentido utilizar esta propriedade em outra tag que não seja a tag <img>

fn: é a abreviação de “family name”. Essa propriedade pode ser usada para compartilhar o nome completo da pessoa sem nenhuma outra sub-propriedade (ou propriedade filho) da seguinte maneira:

<span class="fn">Henrique Costa Pereira </span>

Entretanto, existe outra propriedade que pode expandir a quantidade de descrição do nome de uma pessoa. Esta propriedade chama-se “n”, que é a abreviação de “nome” apenas e é utilizado quando se quer utilizar outras propriedades que estão presente no vCard como honorific-prefix, given-name, additional-name, family-name, honorific-suffix. Por isso que no exemplo dado anteriormente temos o seguinte trecho:

<span class="fn n">

      <span  class="given-name">Henrique</span> 

      <span  class="additional-name">Costa</span> 

      <span     class="family-name">Pereira</span>
</span>

Veja outro exemplo dessas propriedades aplicadas:

<cite class="fn n">

            <span class="honorific-prefix">Dr.</span>
            <span class="given-name">John</span>
            <span class="additional-name">Philip</span>
            <span class="additional-name">Paul</span>
            <span class="family-name">Stevenson</span>,
            <span class="honorific-suffix">Jr.</span>,
            <span class="honorific-suffix">M.D.</span>,
            <span class="honorific-suffix">A.C.P.</span>
</cite>

As subpropriedades nunca devem ser aplicadas sem as propriedades pai. Você precisa sempre saber se uma propriedade depende de outra. Isso vale para todas as especificações microformats. Sempre que existir um atributo dependente de outro, será necessário a estrutura completa na markup.

Ou seja, “fn” é o seu nome completo e “n” é a propriedade necessária para poder declarar outras propriedades especificas como “given-name” (primeiro nome), “additional-name” (nome do meio) e “family-name” (sobrenome ou último nome). Com isso nós temos nosso primeiro exemplo prático de aplicação de propriedades filhas, ou seja, propriedades que dependem de outra.

Veja um exemplo do que não deve ser feito:

<div class="vcard">

     <span class="fn">
             <span  class="given-name">Henrique Costa Pereira</span>
     </span>
</div>

Você não deve utilizar a propriedade “given-name” sem a propriedade pai, que é “fn” (que está riscada). Veja o correto abaixo:

<div class="vcard">

     <span class="fn">
             <span  class="given-name">Henrique Costa Pereira</span>
     </span>
</div>

Outra coisa que não deve ser feita é combinar a propriedade raiz, com outras propriedades como no exemplo:

<div class="vcard fn">

        <span  class="given-name">Henrique Costa Pereira</span>
</div>

E também não é possível combinar propriedades com suas sub-propriedades como no exemplo:

<div class="vcard">

           <span  class="fn given-name">Henrique Costa Pereira</span>
</div>

Os dois exemplos acima são “ilegais” e NUNCA devem ser utilizados dessa maneira em nenhuma especificação microformat composta.

org: significa “organização”. Ou seja, o nome da empresa. Esta proprieda possui outras 2 propriedades filhas “organization-name” e “organization-unit”. Entretanto, se nenhuma das duas propriedades filhas for encontrada (ou seja, se você não usá-las) a propriedade “org” assumirá automaticamente o valor de “organization-name”. Na maioria dos casos nenhuma das duas sub-propriedades de “org” são necessárias ou mesmo utilizadas.

email: a mais óbvia das propriedades. Geralmente esta propriedade é utilizada junto com a tag <a> como no exemplo:

<a class="email" href="mailto:henrique.costapereira@gmail.com">henrique.costapereira@gmail.com</a>

Entretanto esta não é uma obrigação.

adr: é uma sub-propriedade do hcard ao mesmo tempo em que também é um especificação microformat composta por si só que vamos ver mais á frente. Mas em resumo, ela significa endereço e possui outras propriedades filhas onde pelo menos uma propriedade filho é obrigatória. Veja um exemplo abaixo;

<div class="adr">

    <div class="street-address">665 3rd St.</div>
    <div  class="extended-address">Suite 207</div>
    <span class="locality">San Francisco</span>,
    <span class="region">CA</span>
    <span class="postal-code">94107</span>
    <div class="country-name">U.S.A.</div>
</div>

Veja o trecho do exemplo que eu havia dado anteriormente:

<div class="adr">

        <div class="street-address">Av Paulista, 1000 - Centro</div>
        <span class="locality">São Paulo</span> ,
        <span class="region">SP</span> ,
        <span class="postal-code">38400-360</span>
        <span class="country-name">Brasil</span>
</div>

As propriedades filha de “adr” são: “street-address”, significa “endereço da rua” (mesmo que seja uma avenida para os mais espertinhos). As outras são “locality” (localidade, geralmente o nome da cidade), “region” (região, geralmente o nome do estado ou província), “postal-code” (CEP) e “country-name” (nome do país). Outras propriedades aqui!

tel: significa “telefone” e possui uma sub-propriedade e uma excessão. Geralmente as pessoas utilizam a propriedade “tel” sozinha e sem nenhuma outra sub-propriedade junto como no exemplo geral que eu havia dado:

<div class="tel">9999-9999</div>

A sub-propriedade é chamada de “type” e pode receber os seguintes valores: “home” (para telefone residencial), work (para o telefone do trabalho), pref (para o telefone preferencial), fax (para o número do seu fax) , cell (seu celular) e pager (número do seu pager). Como “type” é uma subpropriedade de “tel”, é preciso de uma segunda propriedade para o número desses telefones propriamente ditos, que no caso é “value”.

Esta é uma propriedade genérica usada geralmente em sub-propriedades quando a propriedade pai não necessariamente precisa de filhos (ou sub-propriedades) para ter seu valor. Como o número do telefone é inserido na propriedade “tel”, quando ela possui uma sub-propriedade dentro, é necessário alocar este valor para outra propriedade. Então sempre que usar a sub-propriedade “type” para indicar o tipo do número do telefone que está compartilhando, será necessário usar também a sub-propriedade genérica chamada de “value” para colocar o número do telefone propriamente dito conforme o exemplo abaixo:

 <div class="tel">

    <span class="type">cell</span>
    <span class="value">9999-9999</span>
</div>

Só o conteúdo que importa!

Veja um exemplo abaixo:

<p class="vcard">

            <span class="fn">
                        <span  class="given-name">Marcos Borges será o nosso palestrante esta  noite</span>
            </span> e ele vai falar sobre biologia  marinha.
</p>

Quando um parser interpretar este trecho e remover o conteúdo relacionado a “given-name”, o resultado será:

 Marcos Borges será o nosso palestrante esta noite

A propriedade “given-name” refere-se ao nome e é somente isto que ela deve conter.

Bom, como o objetivo das propriedades é descrever trechos de informação, você só deve deixar dentro delas o que realmente for a informação que diz respeito a propriedade. Colocar trechos de informações desnecessárias dentro de uma propriedade é o erro mais comum ao escrever microformats. Isso ocorre quando se coloca texto que não condiz com o valor da propriedade.

hCalendar

Veja um exemplo de hCalendar. Em negrito estão as propriedades do hCalendar:

<p class="vevent">     O que: <span class="summary">Festa dos blogueiros</span><br />      Quando: <abbr class="dtstart" title="2006-09-01T19:30:00">1  de setembro às 7:30 da noite!</abbr> até ás <abbr class="dtend" title="2006-09-01T21:30:00">9:30</abbr><br  />      Onde: <span class="location">Escritório da  Visie: Av Fagundes Filho, Vila Monte Alegre, nº 145, São  Paulo/SP</span>      <span class="description">Este é  o encontro oficial de todos os blog de tenconologia do Brasil, não  perca!</span> </p>

Observe que o conteúdo que não faz parte de nenhum campo, eu deixei do lado de fora de qualquer uma das propriedades como os trechos “o que”, “quando”, “onde”, assim como eu já falei anteriormente. Observe que eu utilizei a tag <br /> propositalmente também, mas poderiam não estar ali. Se quiser uma quebra de linha, é mais interessante que você utilize CSS para isso. De qualquer maneira, eu inseri a tag <br /> somente para mostrar que ela pode sim estar ali, desde que fora de qualquer propriedade.

Vamos ver mais algumas considerações. Você observou que o formato da data é o do design pattern <abbr> + date time? Pois é, por isso foi necessário trabalhar os coneitos dele lá atrás. Brian Suda (de novo o cara) criou um XSLT que extrai o conteúdo microformato de qualquer site com o padrão hCalendar e o exporta para o formato .ics (iCalendar) utilizado pelos softwares, chamado de X2V.

As únicas propriedades OBRIGATÓRIAS do hCalendar são apenas 3. Elas são “vevent”, a propriedade raiz que não pode faltar nunca, “summary” que é uma breve descrição do evento e “dstart”, que é a data do evento (sem isso como vamos saber que algo vai acontecer?). Todas as outras propriedades são opcionais.

vcalendar – Esta propriedade pode ser usada para um ou mais eventos e é aplicada como uma propriedade raiz que supõe englobar mais de um evento, onde cada evento dentro dessa propriedade “vcalendar” possui sua própria propriedade raiz “vevent”. Esta propriedade é opcional e pode ser omitida.

vevent – Esta é a propriedade raiz e sua utilização é obrigatória.

dtstart – Data de início do evento

dtend – Data do fim do evento

duration – Duração do evento

summary – Resumo do evento, ou título do evento, ou nome do evento etc.

uid – É como se fosse um identificador do evento, onde geralmente se utiliza uma url.

dtstamp – Date e hora de quando o documento sobre o evento foi criado.

method – Valores para esta propriedade são PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER, or DECLINECOUNTER. Por exemplo um valor igual a “request” indica que foi feita uma requisição para o evento ocorrer.

category – Valores comuns para esta propriedade são: MEETING, APPOINTMENT, CONFERENCE, EXPO. Esta propriedade pode repetir, onde um evento pode estar enquadrado em mais de uma categoria.

location – Diz onde o evento vai acontecer.

url – Este é óbvio. A URL dá página do evento se ouver. esta propriedade e “uid” são basicamente a mesma coisa e só foi marida no padrão hCalendar porque faz parte do padrão iCalendar.

description – Uma descrição mais detalhada e/ou uma sinopse do evento diferente da informação provida pelo campo “summary”.

last-modified – Date e hora em que a informação sobre o evento foi atualizada.

status – Valores comuns que indicam o estatus de um evento são: TENTATIVE, CONFIRMED, CANCELLED

class – Indica a classificação de um evento com os seguintes valores: PUBLIC, PRIVATE, CONFIDENTIAL.

Vamos usar a criatividade agora e ver como nós podemos expandir a especificação hCalendar misturando um hCalendar com um hCard:

<p class="vevent">

        O que: <span class="summary">Festa dos blogueiros</span><br />

        Quando: <abbr class="dtstart"  title="2006-09-01T19:30:00">1 de setembro às 7:30 da  noite!</abbr> até ás <abbr class="dtend"  title="2006-09-01T21:30:00">9:30</abbr><br />

        Onde: <span class="location vcard">

                                   Escritório da <span class="fn">Visie</span>:

                                   <address class="adr">

                                       <span class="street-address">Av Fagundes Filho</span>

                                       <span class="extended-address">Vila Monte Alegre, nº 145</span>

                                       <span class="locality">São Paulo</span>

                                       <abbr class="region" title="São Paulo">SP</abbr>

                                   </address>

              </span>

                        <span class="description">Este é o encontro oficial de  todos os blog de tenconologia do Brasil, não perca!</span>

</p>

Como foi dito anteriormente, o hCard também é para empresas. Ou seja, pegue o atributo “location” e à partir dele eu criei o hcard que poderá ser “enxergado” por parsers separadamente do evento em si. Poderíamos ter apenas colocado a especificação adr ao invés da especificação hCard? Claro que sim. Tudo vai depender do nosso interesse em manipular a informação e como nós vamos querer manipulá-la. Mas não vamos parar por aqui. Vamos colocar a especificação geo nesse bolo:

<p class="vevent">

                        O que: <span class="summary">Festa dos blogueiros</span><br />

                        Quando: <abbr class="dtstart"  title="2006-09-01T19:30:00">1 de setembro às 7:30 da  noite!</abbr> até ás <abbr class="dtend"  title="2006-09-01T21:30:00">9:30</abbr><br />

                        Onde: <span class="location vcard">

                                   Escritório da <span class="fn">Visie</span>:

                                   <address class="adr">

                                        <abbr class="geo" title="42.352163;-71.062867"><span  class="street-address">Av Fagundes Filho</span></abbr>

                                        <span class="extended-address">Vila Monte Alegre, nº 145</span>

                                        <span class="locality">São Paulo</span>

                                        <abbr class="region" title="São Paulo">SP</abbr>

                                   </address>

                        </span>

                        <span class="description">Este é o encontro oficial de  todos os blog de tenconologia do Brasil, não perca!</span>

</p>

Pronto, agora nós temos um hCalendar, mais um hCard, mais a especificação geo tudo junto! Quanta informação este trecho carrega não? Por isso que chamam este tipo de microformats de “compostos”, pela capacidade que possuem de serem modulares (podem se aplicar a qualquer contexto que possua este tipo de informação) e podem ser mesclados sem perda de dados e sem redundâncias como no exemplo.

Passo a passo: Como utilizar uma ferramenta de tradução microformatos para criar um link que permita o usuário baixar ou mover o conteúdo para outro local (por exemplo, traduzir hCard para vCard para download em um programa de catálogo de endereços).

 

Vamos supor que você quer facilitar a vida de quem acessa o seu site para pessoas que não utilizam extensions (nem o Firefox), pessoas que não possuem muito conhecimento de informática, mas pelo menos importam arquivos .vcf para seus contact book como o Outlook. Brian Suda criou um arquivo de XSLT que parseia seu HTML e transforma o hcard em um arquivo vCard que pode ser importado por qualquer aplicativo que armazena informações de contato.

Basta proceder da seguinte maneira como no exemplo:

hCard para vCard

<a type="text/directory" href="http://h2vx.com/vcf/tantek.com">Download vCard</a>

hCalendar para iCalendar

<a type="text/calendar" href="http://h2vx.com/ics/microformats.org/wiki/events">Download iCalendar</a>

Nos exemplos acima apenas passei o endereço tantek.com do hCard (que é onde hcard está no XHTML) e o endereço microformats.org/wiki/events do hCalendar pelo parser em XSLT criado por Brian Suda. Basta substituir o endereçotantek.com  e o microformats.org/wiki/events pelo endereço que você quiser fornecer vCards ou iCalendar. Se você quiser alterar o XLST (que é a parte mais difícil e que já foi pensada e implementada por Suda) e colocar suas próprias features ou hospedar no seu próprio site.

Referências:

http://www.w3c.br/Padroes/WebSemantica

http://microformats.org/

http://www.avellareduarte.com.br/projeto/conceitos/websemantica/websemantica.htm

http://www.avellareduarte.com.br/projeto/conceitos/websemantica/websemantica+microformatos.htm

http://campus.tableless.com.br/2012/05/microformats-compostos-1/

http://campus.tableless.com.br/2012/05/microformats-compostos-2/

http://microformats.org/wiki/H2VX

http://h2vx.com/vcf/

http://h2vx.com/ics/