Fundación CTIC

Archivo etiqueta geonames

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