[Durito-dev] Jena y Sesame

[ahg]

Compañeros:

He estado estudiando las funciones de los alamcenes de triples, y esoty
pensando que posiblemente hay que considerar cambiarnose de Sesame a
Jena.

Debo decir, primero, que creo que el trabajo de Miguel de evaluar estas
herramientas fue totalmente acertado y valioso: se evaluaron con base en
su performance, y eso con el tipo de almacenamiento que vamos a usar, y
con base en los criterios que le sugerimos.

Sin embargo había cosas que no se pudieron tomar en cuenta hasta que
empezáramos a hacer querys de prueba e investigar con mayor detalle los
API de ambos.

Pero ya llegado a esta etapa, parece que Jena tiene un API mucho más
desarrollado y maduro, especialmente para una aplicación que permitirá
los usuarios, a través de un interfaz, modificar los datos WS mismos.

Comparemos, por ejemplo, las funciones que tienen ambas herramientas
para trabajar con los rdf:Bag, elemento que debe usarse para agrupar los
elementos de cualquier sys:Group (superclase cuyas subclases incluyen
colecciones, áreas administrativas, etc.) Se tiene que poder agregar y
quitar los miembros de un rdf:Bag.

Sesame:
"The support for Containers (Alt, Bag, Seq) and Collections in the
Sesame Graph API is currently almost non-existent. This is something
that we plan to add later."
http://www.openrdf.org/forum/mvnforum/viewthread?thread=450#1904

Jena:
"The Jena classes offer methods for manipulating containers including
adding new members, inserting new members into the middle of a container
and removing existing members. The Jena container classes currently
ensure that the the list of ordinal properties used starts at rdf:_1 and
is contiguous."
http://jena.sourceforge.net/tutorial/RDF_API/index.html#ch-Containers


Hay otras ventajas similares. Por ejemplo, Jena también incluye un
mecanismo para "proteger" ("lock") partes del modelo contra la lectura o
la escritura. Esto puede resultar importante para aplicaciones como la
nuestra, que podrá tener múltiples usuarios simultánteos.
http://jena.sourceforge.net/how-to/concurrency.html

Otras ventajas de Jena incluyen:
- Un lenguaje de query que sigue (y amplía) la norma actualmente en
construcción para lenguajes de query del Web Semántico (SPARQL--véase
http://www.w3.org/TR/rdf-sparql-query/)
- Funciones adicionales para SPARQL--que siguen la norma para la
creación de funciones adicionales
- La posibilidad de tratar separadamente áreas de datos de tipo RDF.
Esto será muy útil para cuando se quere actualizar o respaldar por
separado las ontologías que definen las clases/propiedades, y aquélla
que contiene los datos del acervo en sí
- Ya existe una implementación parcial de Fresnel para Jena (aunque,
finalmente, no de las partes de Fresnel que nos sirven)

La desventaja de Jena puede seguir siendo el tamaño y performance, pero
eso es algo que puede cambiar conforme una herramienta se vaya
desarrollando. Y aun nos falta ver cómo funcionan estas herramientas con
las búsquedas de texto libre, que será el tipo de búsqueda más costosa
en términos de procesamiento. No he visto información sobre la
indecización interna del texto contenido en los literales, pero para que
las búsquedas en texto libre sean rápidas en acervos muy grandes, es
necesario que un almacén de triples construya índices internos para
ello.

Bien. Por lo tanto, quiero sugerir lo siguiente:
1) Que nos enfoquemos más en Jena por el momento
2) Que construyamos una capa de abstracción que permitirá en el futuro
el uso de distintos almacenes de triples.

¿Cómo ven?

Muchos saludos,
Andrew