Jena/ARQ: Diferencia entre modelo, gráfico y conjunto de datos

Question

Estoy empezando a trabajar con el motor de Jena y creo que tengo una idea de lo que es la semántica. Sin embargo Estoy teniendo dificultades para comprender las diferentes maneras de representar un montón de triples en Jena y ARQ:

• Lo primero que se tropiezan con al arrancar es Model y la documentación dice su nombre Jenas para grafos RDF .
• Sin embargo también hay Graph que parecía ser la herramienta necesaria cuando quiero consultar una unión de modelos, sin embargo, no parecen compartir una interfaz común con Model, aunque se puede conseguir el Graph cabo de un Model
• Luego está DataSet en ARQ, que también parece ser una colección de tripletas de algún tipo.

Claro, después de echar un vistazo en la API, encontré maneras de convertir de alguna manera a otra. Sin embargo, sospecho que hay más que 3 interfaces diferentes para la misma cosa.

Entonces, la pregunta es: ¿Cuáles son las principales diferencias de diseño entre estos tres? ¿Cuándo debería usar cuál? Especialmente: cuando quiero mantener grupos individuales de triples, pero consultarlos como un gran grupo (unión), ¿cuál de estas estructuras de datos debo usar (y por qué)? Además, ¿"pierdo" algo al "convertir" de uno a otro (por ejemplo, ¿contiene model.getGraph() menos información de alguna manera que model)?

Answer 1

Jena se divide en una API, los desarrolladores de aplicaciones, y un SPI para los desarrolladores de sistemas, tales como las personas que hacen los motores de almacenamiento, etc. razonadores

DataSet, Model, Statement, Resource y Literal son interfaces API y proporcionan muchas comodidades para desarrolladores de aplicaciones.

DataSetGraph, Graph, Triple, Node son interfaces SPI. Son bastante espartanos y fáciles de implementar (como esperarías si tienes que implementar las cosas).

La gran variedad de operaciones API se resuelven en las llamadas SPI. Para dar un ejemplo, el Model interface tiene cuatro métodos diferentes contains. Internamente cada resultado en una llamada:

Graph#contains(Node, Node, Node) 

como

graph.contains(nodeS, nodeP, nodeO); // model.contains(s, p, o) or model.contains(statement) 
graph.contains(nodeS, nodeP, Node.ANY); // model.contains(s, p) 

En cuanto a su pregunta sobre la pérdida de información, con ModelGraph y no lo hace (por lo que yo recuerdo). El caso más interesante es Resource versus Node. Resources saber a qué modelo pertenecen, por lo que puede (en la api) escribir resource.addProperty(...) que finalmente se convierte en Graph#add. Node no tiene tal conveniencia, y no está asociado con un particular Graph. Por lo tanto, Resource#asNode es con pérdida.

Por último:

Cuando quiero tener racimos individuales de triples, consultarlos como una gran ramo (unión), ¿cuál de estas estructuras de datos debería utilizar (y por qué)?

Es claramente un usuario normal, por lo que desea la API. Desea almacenar triples, por lo tanto, use Model. Ahora quiere consultar los modelos como un sindicato: Usted podría:

• Model#union() todo, que copiará todas las tripletas en un nuevo modelo.
• ModelFactory.createUnion() todo, lo que creará una unión dinámica (es decir, sin copia).
• Almacene sus modelos como modelos con nombre en una tienda de datos TDB o SDB, y use la opción unionDefaultGraph.

El último de estos funciona mejor para un gran número de modelos, y un modelo grande, pero es un poco más complicado de configurar.

Answer 2

Respuesta corta: Model es simplemente un contenedor sin estado con muchos métodos de conveniencia alrededor de un Graph. ModelFactory.createModelForGraph(Graph) envuelve un gráfico en un modelo. Model.getGraph() obtiene el gráfico envuelto.

La mayoría de los programadores de aplicaciones usarían Model. Personalmente prefiero usar Graph porque es más simple. Tengo problemas para recordar todo el cruft en la clase Model.

Dataset es una colección de varios Model s: un "modelo predeterminado" y cero o más "modelos con nombre". Esto corresponde a la noción de un "conjunto de datos RDF" en SPARQL. (Técnicamente hablando, SPARQL no es un lenguaje de consulta para "gráficos RDF" sino para "conjuntos de datos RDF" que pueden ser colecciones de gráficos RDF nombrados más un gráfico predeterminado.)