Fundación CTIC

Archivo etiqueta servicios web

Disponibles los catálogos de datasets del sector público en RDF

Ya se pueden consultar los catálogos de conjuntos de datos del sector público accesibles desde nuestro SPARQL endpoint. Todos los catálogos están definidos a través de vocabularios estándar como Dublin Core o FOAF y para la representación concreta de cada uno de ellos se utiliza una instancia de la clase http://data.fundacionctic.org/vocab/catalog/datasets#Catalog.

Para más información, consulta el esquema RDF del Vocabulario de Catálogos de Datasets.

Ejemplo de consulta SPARQL

Para visualizar las tripletas RDF de todos los catálogos disponibles, puede hacerse la siguiente llamada sobre el SPARQL endpoint:


prefix cat:<http://data.fundacionctic.org/vocab/catalog/datasets#>
select *
from <http://data.fundacionctic.org/dataset-catalog>
where
{
  ?sujeto a cat:Catalog;
        ?predicado ?objeto.
}

Tras hacer la consulta en el SPARQL endpoint, se obtendrían las tripletas de cada uno de los catálogos (en HTML).

Visualización de los catálogos

Estos resultados pueden ser tratados por cualquier aplicación para construir el catálogo según las necesidades específicas. Hemos construido un simple ejemplo donde se muestra un listado de todos los catálogos de datasets del sector público (en inglés) almacenados. Nótese que se genera instantáneamente haciendo llamadas a Geonames para enriquecer los resultados, por lo que tiene cierto tiempo de carga.

Si tienes constancia de algún catálogo de datasets de información del sector público que no esté incluido, envíanos un correo a opendata@fundacionctic.org y lo incluiremos en la base de datos.

, , , ,

No hay Comentarios

Reutilización de datos usando Servicios Web: la problemática

En el post anterior, se explicaba un ejemplo básico de reutilización de datos públicos mediante Servicios REST, donde una empresa tecnológica, que desea expandirse para tener presencia en Europa y Asia Central, desarrolla una aplicación para visualizar potenciales países donde instalarse. A continuación, se explica la construcción del ejemplo con detalles técnicos, donde se aprecia la simplicidad de la creación de este tipo de aplicaciones de consulta, mezcla, y visualización de los datos públicos. Además de esto, se muestran las dificultades encontradas.

Búsqueda de los datos

Los APIs utilizados para hacer las consultas sobre los datos son el del Banco Mundial y el de las Naciones Unidas. No existe un Google que nos permita encontrar los repositorios de catálogos de datos, así que se tiene que recorrer cada uno de los conjuntos de datos existentes y buscar la información “a ojo”.

Consultas sobre los datos

Para usar el API del Banco Mundial se requiere registro previo y usar claves necesarias para identificar las aplicaciones que usen dicho API. Como ayuda para la búsqueda de datos y composición de las llamadas a los servicios ofrecidos, existe una herramienta de creación de consultas a través de formularios con todas las opciones soportadas. De esta forma, se construyen las direcciones Web (o URLs) que posteriormente serán utilizadas en la aplicación.

La aplicación realizará llamadas secuencialmente usando consultas HTTP GET, de forma que tras recibir la respuesta desde el servidor, se tratarán los resultados (en formato XML) para filtrar los resultados y tratar los datos que se necesiten.

Se determinan los países de Europa y Asia Central cuya renta tiene unos niveles medios (Medio-Altos o UMC y Medio-Bajos o LMC). Primero se hace la búsqueda de los países dentro de esa área, para determinar la información de esos países (nombre, geoposición, datos financieros, etc.).  La llamada al interfaz, sería:

http://open.worldbank.org/countries?per_page=1000&api_key=XYZ&regions=ECA

Devuelve una lista con los 56 países englobados en esa categoría, que será filtrada tras comprobar que tengan los niveles deseados de renta (UMC o LMC). Tras el filtrado se obtiene la mitad, 23 países. El resultado obtenido con esa llamada, es un documento XML con información sobre 56 países de la zona especificada. Los registros especificados en ese documento tienen la siguiente información:

<?xml version="1.0" encoding="utf-8" ?>
    <wb:countries xmlns:wb="http://www.worldbank.org"  page="1"  pages="1"  per_page="1000"  total="56" >
    <wb:country id="ALB" >
        <wb:iso2Code>AL</wb:iso2Code>
        <wb:name>Albania</wb:name>
        <wb:region id="ECA" >Europe &amp; Central Asia</wb:region>
        <wb:incomeLevel id="LMC" >Lower middle income</wb:incomeLevel>
        <wb:lendingType id="IDB" >IDA blend</wb:lendingType>
        <wb:capitalCity>tirane</wb:capitalCity>
        <wb:longitude>19.8172226</wb:longitude>
        <wb:latitude>41.3316574</wb:latitude>
    </wb:country>
    [...]
</wb:countries>

Después de esto, se seguiría solicitando, combinando y filtrando iterativamente los datos hasta conseguir cubrir todos los requisitos. Este proceso es muy sencillo pero se convierte en muy pesado, ya que hay que almacenar localmente los resultados intermedios, realizar múltiples llamadas a los servicios (con sus respectivos tiempos de espera entre cada uno).

En el caso de necesitar modificar los criterios, simplemente habría que cambiar los parámetros en las llamadas a los APIs.

Distintas fuentes y formatos

La combinación de datos provenientes de una misma fuente y con un formato homogéneo es casi trivial. El problema surge cuando se pretende combinar datos que provienen de distintas fuentes y están especificados de diferente forma, incluso cuando estos resultados vengan estructurados en XML. Un ejemplo de esto se puede encontrar cuando se pretende enriquecer el resultado de los países anteriores con  los datos del Banco Mundial con información que proporciona las Naciones Unidas, para ello se buscarán indicadores sobre el número de investigadores en cada uno de los 19 países filtrados.

A continuación se muestra un ejemplo del documento XML que ofrece el API de las Naciones Unidas, donde se especifica el número de investigadores por cada país (se muestra el registro correspondiente a Argelia).

<ROOT>
    <data>
        <record>
            <field name="Country or Area">Algeria</field>
            <field name="Year">2005</field>
            <field name="Value">5593</field>
            <field name="Value Footnotes">1</field>
        </record>
        [...]
    </data>
</ROOT>

De forma programática se puede hacer la extracción de los datos interesantes para la aplicación, aunque se depende de la pericia del desarrollador para que sepa interpretar la estructura del documento. Además, al combinar los datos anteriores con otra fuente de datos distinta se corre el riesgo de que no todos los países contengan datos, no aparezcan esos países, o que los países tengan nombres distintos.

La interpretación de los formatos es relativamente sencilla, ya que ambos formatos de documentos están expresados en inglés. El mayor inconveniente aparece con los nombres de los países, ya que, aunque los dos utilicen sus nombres en inglés, existen discrepancias en las representaciones. En el ejemplo anterior, al comparar los nombres de los países según el API del Banco Mundial y los del API de las Naciones Unidas se encuentran las siguientes discrepancias:

  • The former Yugoslav Republic of Macedonia (Naciones Unidas) y Macedonia, FYR (Banco Mundial)
  • Slovak Republic (Naciones Unidas) y Slovakia (Banco Mundial)
  • Serbia and Montenegro (Naciones Unidas) y Montenegro/Serbia por separado (Banco Mundial)

Solución

Estas discrepancias se pueden resolver “manualmente”, ya que son pocos los registros y se pueden indentificar sin mucha dificultad.

Como este tipo de ambigüedades es común al tratar con datos de distintas fuentes, se recomienda utilizar mecanismos para hacer que los datos sean unívocos y su semántica esté claramente especificada. El caso de los países se podría resolver si ambos conjuntos de datos utilizasen repositorios de lugares, como GeoNames. GeoNames identifica lugares de forma unívoca mediante URIs y tecnologías de la Web Semántica. Por ejemplo, para referirse a Eslovaquia (o República Eslovaca, o 슬로바키아 en coreano), podemos usar el identificador único http://www.geonames.org/3057568/.

En sucesivos posts se mostrarán formas más adecuadas de exponer los datos para su reutilización y cómo tratarlos en las visualizaciones.

,

1 Comentario

Reutilización de datos usando Servicios Web

Uno de los principales beneficios de la apertura de datos es la reutilización de los mismos. Tras la aparición de las plataformas que permiten usar mapas en la Web hemos vivido un enorme crecimiento en las aplicaciones que combinan datos estructurados provenientes de distintas fuentes (‘mashups‘) y que aprovechan la facilidad de integración que ofrecen las plataformas de representación visual. Estos datos públicos son reutilizados por un amplio espectro de usuarios, desde el diseñador que por afición desarrolla un mashup con las entradas de sus contactos en Twitter representadas sobre un mapa, hasta una empresa que se basa en un modelo de negocios de prestación de servicios explotando datos gubernamentales.

Formato de los datos

Estos datos públicos siempre son útiles, aunque el procesamiento de los mismos será más sencillo y eficaz en función del formato en el que se exponen. Ejemplos de los formatos de representación que nos podemos encontrar son, entre otros:

  • (X)HTML,
  • Ficheros CSV,  XML, etc.
  • RSS,
  • interfaces REST o APIs,
  • basados en tecnologías de la Web Semántica (RDF, RDFa, GRDDL, SPARQL)

Muchas organizaciones que desean exponer los datos al público para que sean reutilizados facilitan el consumo de los mismos ofreciendo interfaces REST o APIs, que permiten hacer consultas sobre sus bases de datos, mostrando resultados estructurados para que sean procesados de forma sencilla. Además, se suelen crear herramientas de integración para trabajar directamente desde los lenguajes de programación más utilizados. Un ejemplo de esto son los listados de los métodos ofrecidos por Flickr para tratar los datos sobre las imágenes que gestiona. Con estos servicios permite el uso de la información de sus bases de datos por parte de la comunidad.

El sector público tiene un gran volumen de información que si es expuesta puede ser de gran utilidad para la ciudadanía, industria, o incluso para las propias Administraciones.

Ejemplo de reutilización de datos: expansión de una empresa

Una aplicación de la reutilización de información del sector público a nivel global, es ejemplificada con el siguiente caso que podría ser real: una empresa tecnológica de I+D que desea expandirse para tener presencia en Europa y Asia Central.

Esta empresa desea abrir una o varias sedes teniendo en cuenta ciertos requisitos establecidos por su política interna, como que el país tenga una alta densidad de investigadores, que la apertura de un nuevo laboratorio no suponga excesivo coste, que el país no tenga un alto índice de pobreza, que la renta per cápita no sea muy elevada y que exista un mínimo control de la corrupción.

Basándose en estos requisitos, un desarrollador de esta empresa puede crear una herramienta que facilite el trabajo de orientación para las tomas de decisiones, usando datos desde la Web. Esta herramienta podría ser implementada en cuestión de minutos y podría tener gran utilidad.

Búsqueda de los datos

El primer paso es la búsqueda de los sitios que contienen los datos que deseamos consultar. Como esta información es relativa a países y negocios, dos de los organismos internaciones que ofrecen información relacionada son el Banco Mundial y las Naciones Unidas. Para consultar los datos se utilizan sus respectivas interfaces REST (API del Banco Mundial/API de las Naciones Unidas).

Consultas sobre los datos

A través de una simple aplicación, se hacen llamadas REST que ofrece el API del Banco Mundial, para determinar la lista de los potenciales países para la apertura de la nueva sede. Dentro de este sitio, se permite la construcción de consultas a través de formularios con todas las opciones soportadas, muy útil para construir las URLs que serán utilizadas en nuestra aplicación.

  • Se determinan los países de Europa y Asia Central cuya renta tiene unos niveles medios (Medio-Altos y Medio-Bajos).  Se obtienen 23 países.
  • Otro de los requisitos establecidos es que en el país no exista un alto índice de corrupción, al menos dentro de lo tolerable, por lo que se establece un nivel mínimo del control de la corrupción dentro del país. Para ello se buscan los índices de control de la corrupción de los últimos años (entre 2000 y 2008) y se rechazan los que tengan un nivel bajo. Seis países son descartados en este paso.
  • Otro aspecto a valorar es que la creación de un nuevo negocio en el país sea relativamente rápido, y los trámites burocráticos no supongan un retraso de más de tres meses desde el inicio del proceso.

Finalmente, se obtienen 19 países potenciales donde establecer la nueva sede de la empresa. Para ofrecer valores cuantitativos que permitan ponderar la decisión final, se buscan indicadores sobre el número de investigadores en cada uno de esos países o el posible coste que tiene la creación de un negocio.

Visualización

Los países obtenidos, junto a los valores de referencia para éstos,  se representan visualmente utilizando una de las herramientas de visualización de datos existentes, como es el API de Visualización de Google. De esta forma se obtiene un resultado visual atractivo y adaptable a los requisitos del destinatario.

En las siguientes ilustraciones se muestra el resultado obtenido tras las consultas, filtrado de los datos y representación de los mismos.

Ejemplo de mashup: Empresa que quiere abrir nueva sede en Europa - Asia Central

Selección de países potenciales con coste porcentual de creación de nuevo negocio

Países potenciales con la intensidad del número de investigadores en cada uno

Países potenciales con la intensidad del número de investigadores en cada uno

Puedes probar este ejemplo.

Utilizando otro sistema de visualización, esta vez interactivo, se puede conseguir el siguiente resultado:

Visualización de los países potenciales con leyenda interactiva sobre los costes asociados

Visualización de los países potenciales con leyenda interactiva sobre los costes asociados

Probar este ejemplo.

Con un simple cambio en la configuración del código, es posible modificar la consulta para que en lugar de seleccionar sólo los países de Europa y Asia Central, tenga en cuenta a todos los países del mundo, pero conservando el resto de  los criterios.

Visualización interactiva de todos los países potenciales con su coste asociado (de todo el mundo)

Visualización interactiva de todos los países potenciales con su coste asociado (de todo el mundo)

Probar este ejemplo.

En el próximo post publicaremos los detalles de la implementación y los problemas encontrados.

, ,

1 Comentario