tutorial gena fuseki batalla animal java jena

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



jena batalla (2)

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

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

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

La gran variedad de operaciones de API se resuelven en llamadas SPI. Para dar un ejemplo, la interfaz del Model tiene cuatro métodos diferentes que contains . Internamente cada uno de los resultados 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)

Con respecto a su pregunta sobre la pérdida de información, con Model and Graph no lo hace (por lo que recuerdo). El caso más interesante es el Resource frente al Node . Resources saben a qué modelo pertenecen, por lo que puede (en la api) escribir resource.addProperty(...) que se convierte eventualmente en un Graph#add . Node no tiene dicha conveniencia y no está asociado con un Graph particular. Por lo tanto, el Resource#asNode tiene pérdidas.

Finalmente:

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é)?

Claramente eres un usuario normal, así que quieres la API. Quieres almacenar triples, así que usa el Model . Ahora desea consultar los modelos como una unión: podría:

  • Model#union() todo, que copiará todos los triples 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 un almacén 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.

Estoy empezando a trabajar con el motor Jena y creo que comprendí lo que es la semántica. Sin embargo, me cuesta entender las diferentes formas de representar un montón de triples en Jena y ARQ:

  • La primera cosa con la que se topa al iniciar es Model y la documentación dice su nombre Jenas para los gráficos RDF.
  • Sin embargo, también hay un Graph que parece ser la herramienta necesaria cuando quiero consultar una unión de modelos, sin embargo, no parece compartir una interfaz común con el Model , aunque se puede obtener el Graph de un Model
  • Luego está el DataSet en ARQ, que también parece ser una colección de triples de algún tipo.

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

Entonces, la pregunta es: ¿Cuáles son las diferencias de diseño clave entre estos tres? ¿Cuándo debo 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, model.getGraph() contiene menos información de alguna manera que el model )?

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

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

Dataset es una colección de varios Model : 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).