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>
</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>
<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>
<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>
<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>
</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>
</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>
<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>
<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>
<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>
<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á:
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/
