Tag Archives: Linked data

GigaScience´s Impact Factor

Even though the editors of GigaScience don’t like Impact Factors (and I agree with them), GigaScience has received a very high Impact Factor, 7.46. I’m quite happy since we published a paper in GigaScience last year, Enhanced reproducibility of SADI web service workflows with Galaxy and Docker.

Tagged , , , , , , , , , , ,

Transforming CSV data to RDF with Grafter

Part of my work is to develop pipelines to transform already existing Open Data (Usually CSVs in some data portal, like CKAN) into RDF and hopefully Linked Data. If I have to do the transformation myself, interactively, I normally use Google Refine with the RDF plugin. However, what I need now is a batch pipeline that I can plug into a bigger Java platform.

Therefore, I’m looking at Grafter. Even though I have never programmed in Clojure (or any other functional language whatsoever!), Grafter’s approach seems very sensible and intuitive. Additionally, I have always wanted to use Tawny-OWL, so probably it will be easier if I learn a bit of Clojure with Grafter first. Coming from Java/Perl/Python, the functional approach felt a bit weird in the beggining, but it actually makes more sense when defining pipelines to process data.

I have gone through the Grafter guide using Leiningen in Ubuntu 14.04. So far so good (I had to install Leiningen manually though, since Ubuntu’s Leiningen package was very outdated). In order to run the Grafter example in Eclipse (Mars), or any other Clojure program, one needs to install first the CounterClockWise plugin. Note that if you want to also use GitHub, like me, there is bug that prevents the project from being properly cloned, when you choose the “New project wizard”: I cloned with the General project wizard, copied the files from another Grafter project, and surprisingly it worked (trying to convert the project to Leiningen/Clojure didn’t work!).

My progress converting data obtained in Gipuzkoa Irekia to RDF can be seen at GitHub. Also, I’m aiming at adding Data Cube SPARQL constraints as Clojure test, here.

 

Tagged , , , , ,

Publicar datos RDF con Amazon EC2 + Virtuoso

Introducción

Para publicar datos en Linked Data necesitamos un servidor web potente con un Triple Store como Virtuoso. A veces nos puede salir mejor utilizar un servicio tipo cloud como Amazon EC2 (por ejemplo meneame lo usa) que tener nuestro propio servidor (de hecho, muchas veces!). En este mini tutorial vamos a publicar un dataset RDF implementando un triple store Virtuoso en una instancia Amazon EC2. Amazon tiene una oferta “free tier” que supongo que será para todo el mundo (puede ser que la tenga por ser usuario premium?); en cualquier caso la instancia que vamos a usar es la que menos prestaciones tiene asi que sera baratísima si no tienes “free tier”. La idea es que con este primer paso luego ya puedes implementar algo más potente, con auto-scale, balanceadores de carga y todo eso.

Crear instancia Amazon EC2

Nos hacemos una cuenta en Amazon Web Services y entramos. Vamos a Services y EC2. Ahi Launch Instance (debajo de create instance). En el menú podriamos elegir una imagen que ya contiene Virtuoso, pero viene con CentOS que es un poco lo peor asi que elegimos Ubuntu Server 64 bits (deberia ser free tier). En el siguiente paso elegimos la instancia t1.micro y le damos a configurar: aquí solo asegurarse de que la instancia tendra una IP publica, “Automatically assign a public IP address to your instances”. En el paso add storage los valores por defecto valen, pero se pueden añadir hasta 30 GB con el free tier, asi que los añadimos (también podemos elegir SSD en vez de magnetico, pero en realidad para lo que vamos hacer aquí da un poco igual todo esto del rendimiento I/O). En tag instance ponemos lo que sea. En security groups hay que añadir las siquientes reglas:

– Una regla para acceder mediante SSH (Yo aqui puse “My computer” por que tengo una IP fija).

– Otra regla “Custom TCP rule”, “port range=8890”, “anywhere” (para que usuarios externos accedan a virtuoso y podamos testear el sistema con consultas SPARQL).

– Otra regla “HTTP anywhere”, por si queremos añadir un servidor Pubby, por ejemplo, para implementar Linked Data mediante negociacion de contenido.

Creamos la instancia y generamos una clave .pem para poder acceder mediante SSH.

Instalar y configurar Virtuoso

Hacemos SSH a nuestra instancia activa y:

– Instalar Virtuoso: sudo apt-get install virtuoso-opensource

– Editar /etc/virtuoso-opensource-6.1 y añadir el path del directorio donde estara el RDF que queremos cargar (nuestra home en la instancia EC2): DirsAllowed = ., /usr/share/virtuoso-opensource-6.1/vad, /home/ubuntu.

– Reiniciar virtuoso: sudo service virtuoso-opensource-6.1 restart.

Cargar RDF en virtuoso

– Como dataset ejemplo, usamos una proteina de UniProt: wget http://www.uniprot.org/uniprot/P08251.rdf.

– Ejecutamos isql con el usuario por defecto dba:isql-vt -U dba

– Añadimos todos los archivos que se encuentren en /home/ubuntu, que terminen en “.rdf”, al grafo http://genomic-resources.eu/uniprot: SQL> ld_dir('/home/ubuntu','*.rdf','http://genomic-resources.eu/uniprot');

– Ejecutar el trabajo propiamente dicho (este proceso es el que tarda si el dataset es grande): SQL> rdf_loader_run ();.

Consultas contra el RDF dataset almacenado en Virtuoso

Si vamos a la IP publica, al SPARQL endpoint (ej. 54.201.244.233:8890/sparql), deberia aparacer un formulario para ejecutar consultas SPARQL. Probamos con:

Pantaila-argazkia 2014-06-20 16:44:06

Deberia dar una larga lista de triples. Happy hacking!

Tagged , , ,

Crítica a Linked Data en Open Data Euskadi

A través de un txio de @alorza he llegado al anuncio que hace Open Data Euskadi sobre la publicación de algunos datasets usando tecnología Linked Data (LD). Lo que sigue es mi análisis no exhaustivo y preliminar de los problemas que he visto, con la intención de ser constructivo y que el servicio mejore. El análisis es sobre esta noticia en concreto, desconozco si el Gobierno Vasco ha publicado mas datos con LD.

Primero un inciso para los que no saben lo que es Linked Data (También se puede ver un video divulgativo). La web actual es una colección de documentos (Páginas HTML) enlazados; un sistema indiscutiblemente útil para leer documentos, pero si hay que hacer consultas un poco complejas sobre la información que representan esos documentos, solo nos queda procesar los documentos y extraer de alguna manera la información que necesitamos. LD es una serie de principios y tecnologías que da respuesta a ese problema: con Linked Data, usando la infraestrutura web ya existente (HTTP + URL), podemos publicar datos directamente en la web en vez de hacerlo a través de documentos. LD tiene dos ventajas importantes: se pueden crear enlaces entre diferentes datos (igual que con las páginas HTML) y como se usa RDF, basado en la estructura del triple, el significado de la información es explícita (por ejemplo se pueden programar agentes automáticos que consuman los datos). Esto hace que los datos publicados con LD sean fácilmente reusables e integrables con otros datos, de modo que muchos gobiernos publican sus datos con este paradigma, como es el caso del Reino Unido.

Volviendo a la noticia original, lo primero que llama la atención es la distinción que se hace sobre usuarios: a los programadores les gustan las APIs, a los periodistas Excell, y a los que trabajan en innovación (?) LD. Realmente es una distinción arbitraria donde las haya, ya que hay programadores y periodistas que trabajan con LD, y ni siquiera sé a que se refiere el autor con “innovacion”. No hay que presuponer que un tipo de usuarios vayan a acceder de una manera concreta a la información: lo mejor es proveer esa información con los mecanismos más eficientes, y LD es uno de esos mecanismos (Aunque en este caso se ha usado de una manera que limita su propia eficiencia, como veremos a continuación).

Hay otra idea discutible en la introducción: la idea que las APIs son “más avanzadas”. No voy a entrar en el debate APIs vs. Linked Data (Creo que las dos tecnologías tienen sus meritos y de hecho son complementarias) pero no creo que usar APIs sea “más avanzado”: por ejemplo, algo que se reconoce en la misma noticia, con una API los métodos de acceso son locales a ese recurso y limitados por el proveedor: con LD se puede acceder a la información completa de ese recurso, y además con una esquema que se conoce a priori (solo cambia el contenido de recurso a recurso) lo cual la hace, en mi opinión, más avanzada que una API. Por decirlo de otra manera: OWL y RDF están “autodocumentados”, lo cual no quiere decir que sea más facil programar contra ellos, simplemente los problemas se desplazan a un nivel de abstracción (para mi gusto) más manejable.

Ahora ya entrando en los datasets que se mencionan en la noticia, no entiendo por que se usa como formato de serialización Turtle (TTL), que se suele usar para datasets pequeños y dirigidos a consumo humano. Para estos datasets seria mas adecuado RDF/XML.

Vamos a mirar un dataset concreto, por ejemplo el que describe los consulados (http://opendata.euskadi.net/w79-contdata/es/contenidos/ds_localizaciones/consulados/es_euskadi/index.shtml). El archivo RDF (en formato TTL) usa el vocabulario vCard para listar los consulados de Euskadi, lo cual está muy bien (no todo iba a ser malo :P) ya que una de la ideas principales de LD es aumentar la interoperabilidad mediante el uso de vocabularios compartidos.

Vamos a mirar el contenido de un consulado concreto, el consulado de Suiza (Lo he transformado a la sintaxis RDF/XML):

suiza

servlet_2011834977348819428

Lo primero es que hay nodos anónimos (Blank Nodes), lo cual es una mala práctica si el modelo RDF que hemos creado va a ser consumido como LD (ver “RDF Features Best Avoided in the Linked Data Context” http://linkeddatabook.com/editions/1.0/#htoc16), aunque puede que esta decisión venga impuesta por el uso de vCard.

Vemos que hay una URI que denota al consulado de Suiza: http://www2.irekia.euskadi.net/es/entities/1047. Una de las ideas principales de Linked Data (y la que mas quebraderos de cabeza da a programadores y usuarios, pero muy importante que se implemente correctamente) es que las URIs identifican a entidades, no a sus representaciones. Cuando un agente (por ejemplo alguien navegando con su navegador web favorito) quiera acceder a esa entidad, recibira una representacion u otra (RDF si es un agente automatico, HTML si el agente es una persona, etc.) mediante negociación de contenido. Veamos que pasa si intentamos hacer un poco de negociación de contenido contra http://www2.irekia.euskadi.net/es/entities/1047 (con la ayuda de http://richard.cyganiak.de/blog/2007/02/debugging-semantic-web-sites-with-curl/):

Simulamos ser un navegador web normal, es decir un ser humano pide la entidad http://www2.irekia.euskadi.net/es/entities/1047:

curl http://www2.irekia.euskadi.net/es/entities/1047

Esto nos lleva efectivamente a la página HTML (Uno de los enlaces dentro de la página apunta al archivo TTL). Para un humano es suficiente.

Pero que pasa si un agente automático (por ejemplo un programa que consume RDF para generar estadísticas sobre consulados) quiere acceder a la entidad consulado de suiza?

curl --header "Accept: application/rdf+xml" http://www2.irekia.euskadi.net/es/entities/1047

Que recibe HTML (lo mismo que el humano), no el RDF que está pidiendo (pasa lo mismo si usamos la cabecera “Accept: text/turtle”). De modo que el programa lo tendrá dificil para generar la estadística (aunque no imposible). Se podria argumentar que puesto que el agente necesita RDF, vaya directamente a http://www2.irekia.euskadi.net/es/entities/1047-consulado-suiza.ttl, pero ese diseño va completamente en contra de LD y del sentido común, puesto que:

Otro problema con este dataset (e intuyo que con muchos de los que habla esta noticia, pero no lo he comprobado) es que no tiene ningún enlace a un dataset externo, con lo cual es tan inútil como usar HTML para escribir un documento, imprimirlo y mandarlo por fax (para eso usariamos un procesador de textos): la gracia de HTML son los enlaces, y sin ellos es una tecnología que no tiene ningun sentido. De igual manera, la gracia de RDF son los enlaces, que, acoplados al hecho de que se usa los triples para representar informacion, hará que quizás algún día toda la web se comporte como una base de datos universal. Asi que para usar RDF y no enlazar a otros datasets, mejor no usarlo: el formato vCard, por si mismo, es perfectamente válido.

De modo que este dataset, al no tener enlaces hacia otros datasets ni desde otros datasets hacia él, está completamente fuera de la red mundial de datos abiertos (http://lod-cloud.net/) y por consiguiente:

  • No pueder ser descubierto.
  • No se puede combinar informacion con facilidad. Por ejemplo, si el gobierno de suiza tiene una URI para cada consulado, se podrían integrar los datos siguiendo la filosofía LD (y asumiendo que efectivamente la negociación se implementase correctamente como he comentado más arriba).

Por último, normalmente para publicar un dataset en LD se usa una triple store para cargar todos los triples, y algo como Pubby para hacer la “magia LD” contra el SPARQL endpoint del triple store (Ver http://biordf.org/UM_LSLD/Clases/UM_Bioinformatics_LD.html#/8/9). Sin embargo, en este caso parece no haber SPARQL endpoint, de modo que tampoco se pueden hacer consultas complejas.

En resumidas cuentas, parece que se ha usado el nombre LD en vano, ya que usar archivos RDF no garantiza que estemos publicando en LD. Quizás hubiese sido mejor estrategia centrarse en unos pocos datos y publicarlos de verdad siguiendo los principios LD mas que publicar todos estos datasets con RDF, sin un beneficio claro, para “colgarse la medalla” (Dicho con todo el respeto y desde un análisis preliminar hecho en timpo libre ;-).

Tagged , ,

Special Issue on Linked Data for Health Care and the Life Sciences

I’m one of the guest editors (With Michel Dumontier and Jesualdo Tomás Fernández Breis) of the Semantic Web Journal‘s Special Issue on Linked Data for Health Care and the Life Sciences. Please, submit your best paper!

Tagged , , , ,