Almacenes de tripletas RDF

RDF es un modelo de metadatos basado en el concepto de sentencias de la forma «sujeto-predicado-objeto», denominadas tripetas RDF. Este modelo ofrece una adecuación mayor para la representación del conocimiento que el modelo relacional de las bases de datos tradicionales, por lo que se ha utilizado para definir otros estándares como RDFS y OWL, enfocados a la representación del conocimiento como ontologías, tal como he explicado en algún post anterior.

Las tripletas representadas mediante RDF, bien provengan de un archivo RDFS, OWL, o cualquier otro derivado, se pueden almacenar de diversas formas, aunque la serialización más habitual se basa en la utilización de archivos XML. Este modo de representación presenta inconvenientes cuando se trabajan con volúmenes de información grandes, que sin embargo, es un punto donde precisamente las bases de datos relacionales llevan muchos años dando excelentes resultados. Es por esto que desde hace unos años existen diversos productos que permiten almacenar las tripletas RDF en bases de datos, principalmente relacionales, aunque también existen algunos productos con modos de almacenamiento específicos.

Existen diferentes alternativas, como Jena, Kowari, 3Store, Sesame y el reciente SDB de Jena. Todas menos esta última están analizadas en este informe de Escalabilidad de Aplicaciones de Almacenes RDF. Este informe indica las principales características de cada producto, qué sistemas de gestión de bases de datos soportan (PostgreSQL, MySQL,…) y ofrece algunas comparativas de rendimiento. Existen también otras pruebas publicadas en diferentes sitios, algunas de ellas utilizando por ejemplo la información de la DBPedia, como éste, o el Lehigh University Benchmark (LUBM) para la evaluación de sistemas de representación del conocimiento basados en OWL.

En el caso del recientemente aparecido SDB de Jena, por ejemplo, permite utilizar bases de datos basadas en Oracle, Ms SQLServer, DB2, PostgreSQL, MySQL, Apache Derby, H2 y HSQLDB. Cada almacén RDF se almacena en una base de datos independiente. Cada una de estas bases de datos contiene un conjunto de tablas orientadas a almacenar la información de las tripletas: Triples para las tripletas, Quads para los grafos RDF y Nodes para los nodos de las tripletas y grafos. SDB ofrece también diferentes layouts o definiciones de campos para estas tablas, cada uno con sus ventajas e inconvenientes. Una vez que la información está almacenada en el almacén es posible acceder a ella a través del API de Jena o mediante la ejecución de consultas SPARQL.

En muchos casos puede ser también necesario disponer de ciertas capacidades de inferencia. SDB por ejemplo es únicamente un almacén de tripletas y no dispone de capacidades de inferencia incluidas, por lo que ante cualquier consulta SPARQL por ejemplo, únicamente se responderá con el conocimiento explícito de las tripletas almacenadas. Imaginemos por ejemplo que tenemos una ontología para representar las publicaciones de una biblioteca. En este caso podríamos tener una clase base «Publicación» y varias subclases como «Libro», «Revista», «Artículo», etc. Imaginemos ahora que alimentamos el almacén RDF con tripletas que representen que «El Quijote» es un Libro. Si hiciéramos una consulta solicitando los libros existentes aparecería, pero sin embargo si pidiésemos todas las publicaciones no lo obtendríamos como resultado, pese a ser Libro una subclase de Publicación. Para ello tendríamos que haber definido explícitamente que «El Quijote» es también una Publicación. Esto sucede así en SDB porque no utiliza el modelo de la ontología para realizar inferencias, ni a la hora de cargar las tripletas en el almacén ni tampoco en el momento de la consulta.

Existen alternativas como Sesame, que sí permite generar tripletas inferidas en tiempo de carga a partir de la ontología definida, y otras que permiten hacerlo en el momento de realizar las consultas expandiéndolas según el modelo definido por la ontología, como una propuesta bastante reciente de nombre Owlgres, que almacena únicamente las tripletas que se le proporcionan y utiliza la ontología para expandir las consultas SPARQL en el momento en que se solicitan. Ambas aproximaciones tienen también sus puntos fuertes y débiles. Por ejemplo generar las tripletas inferidas en tiempo de carga permite reducir los tiempos de consulta pero a costa de incrementar mucho el tamaño de los datos almacenados, mientras que expandir las consultas permite ahorrar ese espacio, pero penaliza los tiempos de respuesta de las consultas.