Na primeira parte dessa série, expliquei os problemas que o desenvolvedor enfrentam ao tentar extrair dados públicos e iniciamos um exemplo com a motivação de se tentar plotar num mapa os endereços de feiras livres de São Paulo, no dia da semana e zona da cidade que o usuário escolhesse. O principal resultado que obtivemos até esse ponto foi uma Open Table da Yahoo Query Language que nos permite realizar a pesquisa para obter os endereços. Sucintamente, ao executar a seguinte query:

USE "http://github.com/lfcipriani/yql-feira-livre-sp/raw/master/yql-feira-livre-sp.xml" AS feiras;

SELECT * FROM feiras WHERE zone = 'SUL' AND dayOfTheWeek = 'DOMINGO';

Obtemos o resultado:

<markets>

   <market>

     <dayOfTheWeek>DOMINGO</dayOfTheWeek>

     <address>RUA  CONDE DE PORTO ALEGRE, Sao Paulo, Brazil</address>

   </market>

   <market>

     <dayOfTheWeek>DOMINGO</dayOfTheWeek>

     <address>AV   AMADEU DA SILVA SAMELLO, Sao Paulo, Brazil</address>

   </market>

   ...

</markets>

Você pode relembrar como funciona o YQL executando esse exemplo diretamente no YQL Console.

A proposta dessa segunda parte é utilizar esse resultado, a conversão do HTML em uma estrutura XML fácil de ser lida por um software, no Yahoo Pipes e plotar o mapa. Dessa forma o usuário pode facilmente saber se tem uma feira livre perto da casa dele, uma vez que agora a informação está num formato mais apropriado.

Yahoo Pipes

Da própria definição no site: “Pipes é uma ferramenta poderosa de composição para agregar, manipular e misturar conteúdo (feeds, RSS, Atom, etc) da Web”.

O legal do Yahoo Pipes é que o usuário não precisa ter conhecimentos avançados de programação ou de como manipular vários formatos, pois a interface é bem fácil de usar. Basta criar conexões entre vários módulos (daí o nome Pipes), sendo que cada módulo faz alguma ação sobre o conteúdo que está passando por ele. A idéia é combinar vários desses módulos para no fim obter um novo fluxo de informações, ou um fluxo enriquecido, modificado.

Nosso objetivo é enriquecer o conteúdo, pois queremos pegar meros endereços e representá-los como pontos em um mapa. Então vamos direto ao ponto!

O mashup de feira livre

O Pipes que vamos criar deve fazer o seguinte:

• Receber do usuário o dia da semana e o zona da cidade;
• Executar a query YQL para obter os endereços de cada feira livre;
• Para cada endereço, realizar um geocoding para obter as coordenadas geográficas;
• Plotar essas coordenadas em um mapa.

Para ajudar no entendimento, você pode visualizar o Pipes de Feira Livre enquanto lê cada passo abaixo (para ver o “código-fonte” do Pipes você precisa estar logado com algum id do Yahoo). Se tiver dúvida no comportamento de um módulo, clique nele e observe a barra inferior apresentando o resultado parcial do mashup.

Recebendo do usuário o dia da semana e zona da cidade

As entradas de usuários podem ser feitas utilizando o Text Input Module, veja a figura abaixo apresentando como configuramos este módulo para as duas entradas necessárias no Pipes de feira livre.

Como se pode ver, com o Text Input, basta configurar o nome da variável, o texto que aparecerá para o usuário (prompt), um opcional valor default e por fim um valor de debug, utilizado quando o criador do Pipes está testando os resultados. Cada entrada dessa é jogada para um String Builder Module, cujo objetivo é bem simples, concatenar strings. Veja que é bem simples, no nosso caso, bastou conectar a saída do Text Input na parte da string que eu quero gerar. A string final obtida com esse módulo será a query YQL que eu vou executar. Aonde? No YQL Module, é claro. Vamos dar uma olhada como fica essa segunda parte do Pipes de feira livre.

Executando a query YQL na Open Table de feira livre

A saída do String Builder é plugada no módulo que executa YQL’s, como mostra a figura acima. O resultado da execução da YQL é uma estrutura de árvore, hierárquica, ou seja, nesta situação, há vários níveis entre a raiz da árvore e a informação que nos interessa (a estrutura XML apresentada no início desse artigo), portanto, temos que usar um Sub-element Module.

O Sub-Element apresentado na figura irá pegar a árvore de resultado retornada pela YQL query e vai retornar apenas a sub-árvore indicada no campo dele, isto é, queremos apenas a sub-árvore que no fim será representada por uma lista de mercados (item.market), que por sua vez contêm dia da semana e endereço de uma feira livre. Nesse ponto o Pipes mostra a sua eficiência, quando focamos o campo do módulo Sub-Element, o Pipes abre um dropdown menu contendo todos os nós dessa árvore retornada pela query, facilitando muito a vida do criador do mashup.

Por fim, temos um Rename Module, e o objetivo dele é renomear atributos de um feed. Esse passo é importantíssimo para a criação desse mashup, pois o Yahoo Pipes, assim como a própria definição dele diz, é um agregador de feeds (RSS, Atom, etc). Portanto, o módulo Rename está sendo usado justamente para esta causa, que é criar o menor feed possível que o Pipes entenda, com título da entrada e descrição.

Se não realizássemos essa renomeação, o Pipes (e outros consumidores desse Pipes de feira livre) não saberia como consumir os dados. Então guarde essa dica: mesmo com a capacidade de trabalhar com várias formatações de dados, todo Pipes deve “cuspir” feeds, dessa maneira você facilita até que outros criadores de Pipes reutilize o seu mashup. Só existe uma exceção para essa regra e vamos apresentá-la na próxima etapa.

Realizando o geocoding para obter as coordenadas geográficas

Esta etapa foi a mais complicada. Inicialmente, colocamos um Loop Module, cujo objetivo é iterar sobre os elementos do feed e realizar alguma operação neles. Essa operação pode ser qualquer outro módulo do Pipes. Olhando no Loop da figura acima, temos o Google Maps Location Extractor, que se você procurar nos módulos padrões disponíveis do yahoo Pipes você não vai encontrar. A explicação é simples, esse módulo é um outro Yahoo Pipes criado por mim. Esse eu não vou explicar como eu fiz, vou apenas passar a URL pra vocês e aí fica como “lição de casa” entender como ele funciona, OK? Aí vai: http://pipes.yahoo.com/lfcipriani/gmapslocationextractor.

O único detalhe importante que vale o comentário é que esse Pipes não retorna um feed válido, mas apenas uma estrutura contendo o resultado da geolocalização, e assim, fugindo da regra citada na etapa anterior. Fiz isso porque o objetivo principal desse Pipes de geolocalização é ser reutilizado somente dentro de outro Pipes, e com restrição na forma de utilizar o seu resultado.

Mas aí vocês podem se perguntar: peraí, o Yahoo Pipes já não tem um módulo de extração de geolocalização? Sim, ele tem, e se chama Location Extractor Module, e para utilizá-lo basta plugá-lo em qualquer saída de feed que ele irá pesquisar por coordenadas geográficas nos campos do feed que são endereços. Se usássemos ele não precisaríamos criar esse Loop, pois ele itera automaticamente nos feeds, mas então porque não usamos?

A resposta é simples, após alguns testes com esse Location Extractor eu percebi que as coordenadas que ele encontrava não era do endereço correto, ou seja, o geolocation não era confiável para os endereços de feiras de São Paulo, talvez ele seja mais eficiente para outras situações. Eu testei alguns endereços no Google Maps Geocoding Webservice e ele foi capaz de acertar mais, mas ainda assim comete alguns erros de vez em quando (vocês podem ver ao executar o Pipes que alguns endereços caem em outras cidades, mas não deveria porque as feiras são todas na cidade de São Paulo). Enfim, como o Google Maps se comportou melhor, não me prendi ao Location Extractor que está disponível no Yahoo Pipes e decidi criar um outro usando um geocoding melhor para a minha necessidade.

Plotando no mapa

O Yahoo Pipes possui uma convenção para coordenadas geográficas, dessa forma, feeds que possuem os campos nesse padrão são automaticamente mapeados quando o Pipes é executado (e você achando que ia ter que aprender a API do Yahoo Maps, hein! ).

O jeito mais simples de utilizar esse padrão é criar o nó y:location e colocar dentro dele os atributos y:location.lat e y:location.lon (você também pode incluir outras informações). Como o webservice de geocoding do Google Maps não me retorna esses campos no formato que o Yahoo Pipes precisa, eu utilizo o Rename Module novamente para renomear a longitude para a forma correta e pronto! Jogo a saída disso tudo no Pipe Output e o Pipes está finalizado.

O resultado final

Se no modo de edição clicarmos no Pipe Output, poderemos ver na barra de debug inferior da interface do Yahoo Pipes a seguinte estrutura de resultados:

Esse é o feed final que o usuário vai obter ao executar o Pipes, que pode ser utilizado assim como qualquer outro feed na Web: assinar em um feed Reader, consumir com outro Pipes (ou software), manipular as entradas, plotar em outro tipo de mapa, Google Earth, [coloque o que quiser aqui].

Você também pode acessar o Pipes de Feiras Livres de São Paulo pelo próprio site dele, e aí obterá um resultado parecido com esse:

Obs.: Lembro vocês que o serviço da prefeitura que serve os endereços é bem instável. Eu tive problemas para acessar principalmente após a meia-noite nos dias da semana e durante o dia todo no fim de semana.

Recapitulando

Na primeira parte desse artigo, focamos em como usar a Yahoo Query Language para oferecer uma linguagem parecida com a SQL para transformar representações, no caso, um HTML desestruturado para um XML conciso e estruturado de forma melhor para ser processada por um software.

Já nesta segunda parte, utilizamos o resultado dessa query YQL para plotar os endereços das feiras livres de São Paulo. O interessante é que isso foi feito inteiramente dentro do Yahoo Pipes, sem a necessidade de escrever uma linha de código.

A minha recomendação de uso para esses serviços é a seguinte: claro que se formos construir uma aplicação mais robusta, processando muito mais dados e que terá uma alta carga num servidor, o Yahoo Pipes e talvez até o YQL não sejam as maneiras apropriadas de se fazer os mashups. Porém, como no caso do exemplo desse artigo (localização de feiras livres), a proposta for apenas de criar um mashup rápido para se ter um ganho no entendimento e visualização de uma informação, que não vai ser utilizada para fins muito críticos, aí sim, esses tipos de serviços são excelentes, pois os resultados vêm rapidamente.

Enfim, sugiro dar uma olhada nos Pipes existentes, tem sempre uma idéia interessante pra ser observada e é muito fácil ver como ela foi implementada, graças a interface que o Yahoo criou para isso. E se você criar ou já criou um Pipes, coloque num comentário desse artigo para que os leitores possam acessar também.

Menos comum mas muito importantes, mashups que utilizam dados públicos (aqueles que se utilizam de dados de órgãos públicos ou outras instituições com esse mesmo caráter) também são criados, porém os desenvolvedores enfrentam muitas dificuldades, por exemplo:

• Falta de interesse da população e dos usuários da Web;
• Nem todos os dados necessários estão publicados ou disponíveis para acesso;
• Algumas vezes os dados podem não estar atualizados ou serem pouco confiáveis;
• Servidores dos dados podem ser mal administrados e os dados podem ficar indisponíveis temporariamente;
• A forma como os dados são disponibilizados pode ser “ilegível” ou “burocrática” para um software;

Eliminar essas dificuldades depende de boa vontade desses órgãos públicos e dos cidadãos. Enquanto não temos uma solução, nós, como desenvolvedores, podemos utilizar ferramentas e nossa criatividade para extrair esses dados, certo? Sendo assim, vamos implementar uma simples extração de dados utilizando 2 ferramentas que facilitam a nossa vida: a Yahoo Query Language (YQL) e o Yahoo Pipes (Y!Pipes).

Nessa primeira parte, o foco será apenas no YQL, mas eu pretendo publicar a parte do Y!Pipes em 1 dia ou 2.

A motivação

foto por Chico Ferreira

Eu costumo ir sempre numa mesma feira livre, aqui em São paulo, nos sábados. Porém, sempre quis saber se existem feiras livres mais próximas de casa e os dias em que elas ocorrem. Tinha duas opções, ou saía de casa todo dia e andava pela redondeza procurando feiras ou dava uma “googlada” para ver se encontrava localização delas aqui em São Paulo. Acabei encontrando o seguinte site da prefeitura:

http://www.prodam.sp.gov.br/semab/mercados/pesqt.htm

Sensacional, funciona direitinho e escolhendo região e dia da semana eu obtenho uma lista com os endereços. Aí é que aparece mais um problema, eu reconheci poucas ruas e decidi procurar no Google Maps, mas isso não é muito produtivo, tinha que copiar rua por rua e isso se tornou uma tarefa tediosa. Então decidi colocar a mão na massa pra plotar todos esses endereços num mapa, utilizando o que a Web oferece.

Os problemas dessa fonte de dados

Não apenas o design da página, mas todo o código HTML parece que foi criado nos anos 90. Ele utiliza frames, tags <center>, <font>, <table>’s aninhadas, em resumo, uma tristeza para qualquer programador que precisar fazer um parsing. Vamos dar uma olhada na situação:

<HTML>

<HEAD></HEAD>

<BODY>

<HEAD><TITLE>ENDERECO DAS  FEIRAS POR DIA  </TITLE>

</HEAD>

<BODY  bgcolor="f9cd8a">

<!--BODY background="/img_feiras/feiras.GIF"--><br>

<center>

<!--img src="/img_feiras/logo1.GIF" border=0 align=top><BR>

<font color=#006666 size=5><B><I>RELAÇÃO DE FEIRAS</I></B></FONT><BR-->

</CENTER>

<PRE>

<center><table border=0><tr><td>

 <CENTER><TABLE BORDER=1 background=http://www.prodam.sp.gov.br/semab/mercados/img_feiras/Gray.jpg><TR><TD ALIGN=CENTER COLSPAN=4><FONT COLOR=#006666  SIZE=5>ZONA CENTRAL</FONT></TD></TR><TR><TD ALIGN=CENTER><FONT COLOR=Black Size=3><b>DIA</b></TD>

 <TD><FONT COLOR=Black Size=3><b>ENDERECO</b></TD>

 <TD ALIGN=CENTER><FONT COLOR=Black Size=3><b>NRO.</b></TD>

 <TD ALIGN=CENTER><FONT COLOR=Black Size=3><b>BAIRRO</b></TD></TR>

 <TR>

 <TD ALIGN=CENTER><FONT COLOR=Red Size=2>DOMINGO</TD>

 <TD><FONT COLOR=Red Size=2>RUA  SANTO AMARO                  </TD>

 <TD ALIGN=CENTER><FONT COLOR=Red Size=2>  S/N&nbsp;</TD>

 <TD ALIGN=CENTER><FONT COLOR=Red Size=2>BELA VISTA          </TD>

 </TR>

 ... omiti de propósito algumas linhas que se repetem ...

Além disso, o servidor nem sempre está disponível (percebi que de fim de semana a instabilidade aumenta) e o tempo de execução médio de requisições que eu enfrentei foi de 10 a 15 segundos. Solução para esse problema, só cacheando todos os dados em outro servidor (não, obrigado) ou quando eles realizarem melhorias na infraestrutura (mas convenhamos, isso não deve ser prioridade).

O objetivo

A tarefa parece simples:

• Executo uma requisição POST passando os parâmetros de zona e dia da semana (via wget, curl, API HTTP de qualquer linguagem);
• Realizo um DOM parsing no HTML retornado, e recupero a tabela contendo os endereços (via navegação de DOM, XPATH);
• Para cada endereço, faço um geocoding usando qualquer API disponível para obter as coordenadas geográficas (via Yahoo Maps, Google Maps, Geonames, etc);
• Jogo essas coordenadas em qualquer serviço de mapas (via Yahoo Maps, Google Maps, etc).

Tinha apenas uma preguiça premissa: não queria usar nenhum programa feito por mim nem por ninguém, mas sim apenas serviços na Web.

Yahoo Query Language

A Yahoo Query Language ou apenas YQL, é uma linguagem parecida com a SQL, largamente utilizada nos bancos de dados, porém cujo objetivo é acessar fontes de dados na Internet. Por exemplo, uma query possível de se realizar com ela é:

SELECT * FROM LOCAL.search WHERE query="sushi" AND location="san francisco, ca"

Bem simples, essa query vai pesquisar por restaurantes em San Francisco, California, que servem sushi. O interessante é que o serviço da YQL centraliza as fontes de dados e fornece uma interface única para todos eles, facilitando a vida do programador, pois fica muito mais fácil utilizar os resultados das queries e também de combinar vários serviços. Se você ainda não conhece, sugiro dar uma brincada com o YQL Console, que possui inúmeros exemplos.

Para os serviços que não possuem tabelas disponíveis, o YQL nos dá duas opções. A primeira é simples, basta executar a seguinte query:

SELECT * FROM html WHERE url="[qualquer URL aqui]" AND xpath='[uma query XPATH aqui]

Com essa query obtemos o resultado da query XPATH no código HTML no formato JSON ou XML. Contudo, essa opção não nos ajuda, pois precisamos realizar uma requisição POST e passar parâmetros para ela.

Nos resta a segunda opção, Open Tables!

YQL Open Tables

Mais interessante que a própria YQL, são as YQL Open Tables, que permitem expor qualquer serviço ou API na web como uma tabela na YQL. Basicamente, para isso, basta criar a especificação de sua Open Table com XML, que pode inclusive possuir código javascript para permitir uma manipulação mais flexível dos dados.

Vamos então ver como fica a nossa Open Table para o caso da nossa fonte de dados de feiras livres em São Paulo. Se você está ansioso, pode acessar o código fonte final no GitHub.

O primeiro passo é colocar a meta-informação da sua Open Table, para que os usuários dela possam saber a forma correta de utilizá-la. Todos as tags XML utilizadas estão detalhadas na documentação de Open Tables da YQL, portanto, vou explicar somente aquelas mais relevantes para o entendimento deste artigo.

<table xmlns="http://query.yahooapis.com/v1/schema/table.xsd">

 <meta>

 <author>Luis Cipriani (@lfcipriani)</author>

 <description>

 Busca por Feiras Livres em São Paulo, por dia da semana e zona da cidade.

 - As zonas possíveis são: CENTRAL, NORTE, SUL, LESTE e OESTE.

 - Os dias da semana possíveis são: DOMINGO, TERCA, QUARTA, QUINTA, SEXTA, SÁBADO.

 - Deixe o dia da semana em branco para pesquisar em todos os dias de uma vez só.

 </description>

 <sampleQuery><![CDATA[ SELECT * FROM {table} WHERE zone = 'CENTRAL' ]]></sampleQuery>

 <sampleQuery><![CDATA[ SELECT * FROM {table} WHERE dayOfTheWeek = 'DOMINGO' AND zone = 'OESTE' ]]></sampleQuery>

 <documentationURL></documentationURL>

 </meta>

</table>

Agora precisamos criar a parte da especificação que cria a estrutura da query que desejamos expor para os usuários:

<table>

 <meta>...</meta>

 <bindings>

   <select itemPath="" produces="JSON" >

     <urls>

       <url>http://www3.prefeitura.sp.gov.br/feiras/feiras.asp</url>

     </urls>

     <inputs>

       <key id="dayOfTheWeek" type="xs:string" paramType="variable" default="todos" />

       <key id="zone" type="xs:string" paramType="variable" required="true" />

     </inputs>

     <execute>...</execute>

   </select>

 </bindings>

</table>

Dentro da tag <bindings> podemos ter as tags <select>, <insert>, <update> e <delete>, dependendo do tipo de queries que queremos criar, no nosso caso, somente uma query SELECT. Deixamos o attributo itemPath porque não queremos colocar nenhum namespace precedendo a resposta retornada e escolhemoso JSON como format padrão no atributo produces.

Na tag <url> colocamos a URL do serviço que vamos acessar, no caso, essa é a URL que vamos fazer a requisição POST e passar os parâmetros necessários para obter a lista de endereços de feiras livres.

Só nos falta agora definir quais os parâmetros desejamos na query, o que é feito pela tag <key>. No exemplo acima, ao atribuir o tipo variable para as duas tags, eu estou informando que dayOfTheWeek e zone são duas variáveis que podem (ou devem) ser utilizadas como cláusulas no WHERE da query.

Munido de todas as configurações de nossa query, se o tipo de fonte de dados utilizado exigir, podemos ainda incluir um código javascript para permitir um manuseio mais flexível dos dados obtidos pela query. No nosso caso, nós precisaremos fazer isso, pois a forma como o HTML é entregue após essa requisição não é muito fácil de lidar. Além disso, desejamos que ao executar essa query, o desenvolvedor obtenha apenas os dados necessário, então seria interessante retornarmos os dados limpos e bem estruturados.

Queremos, a partir do código HTML da fonte de dados apresentado acima, obter o seguinte:

<markets>

   <market>

     <dayOfTheWeek>DOMINGO</dayOfTheWeek>

     <address>RUA  CONDE DE PORTO ALEGRE, Sao Paulo, Brazil</address>

   </market>

   <market>

     <dayOfTheWeek>DOMINGO</dayOfTheWeek>

     <address>AV   AMADEU DA SILVA SAMELLO, Sao Paulo, Brazil</address>

   </market>

   ...

</markets>

Vamos então analisar por partes o código javascript, que é incluído dentro da tag <execute>. Veja bem que vamos apenas focar nas partes mais importantes:

var postData = "zona="+ zone +"&dia=" + dayOfTheWeek;

var data = request.accept('text/html').

    contentType("application/x-www-form-urlencoded").

    post(postData).response;

var xdata = y.xpath(data, "//font[@color='Red']");

Como a nossa requisição é do tipo POST e por padrão uma Open Table faz um GET, precisamos usar o objeto request fornecido pelo YQL para realizar a requisição manualmente. O objeto request possui a propriedade de chaining, então fica bem tranquilo realizar a requisição. Só lembrando que a URL utiliza é aquela especificada lá na tag URL.

Depois pegamos o resultado dessa requisição e realizamos uma query XPATH. Diante do HTML totalmente sem estrutura que recebemos da requisição, a query XPATH que busca os resultados que mais precisamos foi:

//font[@color='Red']

Ou seja, todas as tags do tipo <font> que possuem o atributo color igual a “Red”. Se o HTML fosse semanticamente válido com certeza essa query seria diferente e até faria mais sentido, mas ao extrair dados públicos é bastante comum se deparar com esse tipo de estrutura. Mas é aí tá a diversão do negócio!

Calma que ainda não acabou, agora temos que utilizar o resultado da query XPATH e recuperar dessa lista o dia da semana e estruturar o endereço de uma forma que seja ideal para o geocoding.

default xml namespace = '';

for each (var item in xdata) {

  if (i == 0) {

    day = item.toString().trim();

  } else if (i == 1) {

    address += item.toString().trim() + ", ";

  } else if (i == 2) {

    number = item.toString().trim();

    if (number != "S/N" && number.length != 0) {

      address += number + ", ";

    }

  } else if (i == 3) {

    address += "Sao Paulo, Brazil";

    marketList.push({day: day, address: address});

    address = "";

    i = -1;

  }

  i++;

}

No código acima, nós iteramos sobre o resultado da query anterior. Para cada 4 items, o primeiro é o dia da semana, e do 2o. ao 4o. constitui o endereço, que incrementamos em uma variável address para no final, montarmos um JSON que possui os atributos relevantes: dia da semana e endereço. Um leitor atento vai perceber que tem código meio estranho nesse trecho acima, o fato é que o YQL aceita na tag <execute>, além do javascript, o E4X (Ecmascript for XML), que adiciona suporte nativo ao manuseio de XML no javascript e é por isso que existe a declaração de namespace default xml namespace = ''. Vamos dar uma olhada na última parte desse algoritmo para entender melhor como o E4X funciona.

default xml namespace = '';

var result = <markets />

for (i = 0; i < marketList.length; i++) {

  result.markets += <market><dayOfTheWeek>{marketList[i].day}</dayOfTheWeek><address>{marketList[i].address}</address></market>;

}

response.object = result;

A resposta da query YQL deve ser enviada para a variável response.object e deve ser criada com o E4X, e veja que isso é feito escrevendo XML diretamente no código javascript. Esse algoritmo foi necessário apenas para converter a estrutura HTML do site de pesquisa de feiras livres para um formato XML mais adequado para ser “lido” por um software.

Pronto! A Open Table está pronta, um exemplo de query que podemos fazer é:

USE "http://github.com/lfcipriani/yql-feira-livre-sp/raw/master/yql-feira-livre-sp.xml" AS feiras;

SELECT * FROM feiras WHERE zone = 'SUL' AND dayOfTheWeek = 'DOMINGO';

Veja o resultado no YQL Console.

Ou acesse o todo o código no Github.

Conclusão

Enfim, apesar de todos os problemas com as fontes de dados públicos, é possível extraí-los e convertê-los para uma representação melhor. Vimos também que serviços na Web como o Yahoo Query Language (YQL) permitem expor esses dados com uma API tão fácil quanto realizar uma simples query SQL, por meio de uma interface padronizada e única. E só com a exposição desses dados, num formato apropriado para que possamos programar com eles, teremos vários mashups gerando novos conhecimentos, sejam eles de interesse público ou não.

Nesta primeira parte desse artigo, cobrimos somente a Yahoo Query Language, na próxima parte iremos criar um mashup com o Yahoo Pipes que irá mapear todos os endereços de feiras livres da zona da cidade que o usuário escolher. Está curioso para saber o resultado? Não se aflija. E não perca a segunda parte na qual explicaremos como criamos esse mashup.