uso reglas quiénes quienes quien ortografía ortografica oraciones escribe cúal cuáles cuál cuales cual con como acentuacion neo4j sparql graph-databases orientdb triplestore

neo4j - reglas - Gráfico de bases de datos frente a tiendas triples: ¿cuándo usar qué?



reglas de acentuacion ortografica (1)

Sé que hay preguntas similares en Stackoverflow, pero no creo que respondan lo siguiente.

Grafica las bases de datos para entender los datos almacenados siguiendo principalmente este esquema:

Table/Collection 1: store nodes with UID Table/Collection 2: store relations referencing nodes via UID

Esto permite almacenar tipos arbitrarios de gráficos. Ahora, como entiendo, las tiendas triples no almacenan nada más que triples:

Triple/Collection 1: store triples (2 nodes, 1 relation)

Ahora vería la siguiente distinción con respecto a los casos de uso:

  • Bases de datos de gráficos: cuando lo sabe, conexiones estáticas
  • Tiendas triples: cuando tiene nodos conectados libremente y a menudo buscan nuevas conexiones

Estoy confundido por el hecho de que las personas no parecen estar discutiendo cuál usar según estos criterios. La mayoría de los artículos que encuentro están hablando de argumentos como la velocidad o la compatibilidad. ¿Pero este no es el punto más relevante?

Ponga al revés:

  • Imagine tener un gráfico claramente conectado y definido por el usuario. ¿Por qué demonios querrías almacenar eso solo como triples, perdiendo toda la información sobre las conexiones? O tener que implementar algunas soluciones personalizadas almacenando identificadores en el subject triple.
  • Imagine que tiene nodos recopilados libremente que desea consultar para relaciones desconocidas utilizando SPARQL. Las bases de datos de gráficos sí lo admiten. Pero para esto, tienen que construir otro índice, supongo, y sería más lento.

EDITAR: veo que "perder información sobre las conexiones" es la manera incorrecta de expresarlo. Si haces lo que se muestra en la respuesta aceptada e insertas varios triples para 2 nodos + 1 relación, entonces conservas toda la información y específicamente la información a la que se conectan los nodos exactos.

La principal diferencia entre las bases de datos de gráficos y las tiendas triples es cómo modelan el gráfico. En una tienda triple (o tienda cuádruple), los datos tienden a ser muy atómicos . Lo que quiero decir es que los "nodos" en el gráfico tienden a ser tipos de datos primitivos como cadena, entero, fecha, etc. Las relaciones unen primitivas, por lo que la "unidad de discurso" en una tienda triple es un triple, y no un nodo o una relación, típicamente.

Por el contrario, otras bases de datos de gráficos a menudo se llaman "tiendas de propiedades" porque los nodos son contenedores de datos que corresponden a objetos en un dominio. Un nodo representa un objeto y tiene propiedades; actúan como tipos de datos ricos especificados por los modeladores de gráficos, más que solo tipos de datos primitivos. En estas bases de datos de gráficos, los nodos y las relaciones son la "unidad de discurso".

Digamos que tengo una persona llamada "Bob" que conoce a "Susan". En RDF, sería algo como esto:

<http://example.org/person/1> :hasName "Bob". <http://example.org/person/1> foaf:knows <http://example.org/person/2>. <http://example.org/person/2> :hasName "Susan".

En una base de datos gráfica como neo4j, sería esta:

(a:Person {name: "Bob"})-[:KNOWS]->(b:Person {name: "Susan"})

Observe que en RDF, son 3 relaciones, pero solo una de esas relaciones realmente expresa semántica entre dos entidades. Las otras dos relaciones son solo propiedades de seguimiento de una sola entidad de nivel superior (la persona). En neo4j, es 1 relación entre dos nodos, con cada nodo que tiene una propiedad. En RDF tenderá a identificar cosas por URI, en neo4j es un objeto de base de datos que obtiene una ID de base de datos automáticamente. Eso es lo que quiero decir sobre la diferencia entre una tienda más atómica / primitiva (tiendas triples) y un gráfico de propiedades más rico.

Las tiendas RDF y triples se construyen principalmente para los tipos de desafíos arquitectónicos con los que te encuentras con la web semántica. Por ejemplo, el espacio de nombres XML está integrado, en la suposición arquitectónica de que combinará y combinará el uso de muchos vocabularios y espacios de nombres diferentes. (Que hay una suposición muy "web semántica"). Por lo tanto, en SPARQL y RDF verá típicamente al menos el uso xsd de xsd de xsd , rdf y rdfs , y probablemente también owl , skos y muchos otros. SPARQL y RDF / RDFS también tienen muchos ganchos y funciones que están ahí explícitamente para facilitar cosas como la inferencia de ontología. Tiende a identificar las cosas con URI como una forma de "espacio de nombres de sus identificadores", pero también porque algunas personas pueden querer desviar el URI ... nuevamente, la suposición aquí es un amplio acuerdo de intercambio de datos entre muchas partes.

Por el contrario, las tiendas de propiedades están orientadas hacia diferentes casos de uso, como el modelado flexible de datos dentro de un modelo / espacio de nombres , asignaciones entre objetos y gráficos para la persistencia de aplicaciones empresariales, rápida evolvabilidad, etc. Tiende a identificar cosas con su propio esquema (o una ID de base de datos interna). Un número entero de incremento automático puede no ser la mejor forma de identificación para cualquier consumidor aleatorio en la web (y ciertamente no se puede desreferenciar como URL) pero puede que no sea lo primero que se piense para una aplicación interna de la compañía.

Entonces, ¿qué es mejor? ¿El formato de tienda triple más atómico, o un gráfico de propiedad rico? ¿Necesita mezclar y combinar muchos vocabularios diferentes en una consulta o modelo de datos? ¿Necesita crear una ontología OWL o hacer inferencia? ¿Necesitas serializar un grupo de objetos Java en la memoria de una base de datos? ¿Necesitas hacer un recorrido rápido de caminos largos? Esos tipos de preguntas guiarían su selección.

Los gráficos son gráficos, ambos hacen gráficos, por lo que no creo que haya mucha diferencia en términos de lo que pueden representar, o cómo se trata de pensar sobre un problema en "términos gráficos". Las diferencias se reducen a la arquitectura debajo del capó, y qué tipo de casos de uso crees que necesitarás. No te diré que uno es mejor que el otro, pero elige sabiamente.