Base de datos de gráficos: TinkerPop/Blueprints vs W3C Datos enlazados

Question

Buscando una infraestructura para el análisis de red para tipos heterogéneos (múltiples tipos de nodo (multimodo), tipo de borde múltiple (multi-relación) y múltiples descriptivas (multi-función) redes, me he dado cuenta de que hay dos pilas estándar en el mundo de base de datos: Gráfico

Por un lado tenemos la ThinkPop/Blueprintproperty graph model. Se apoya en Neo4j, OrientDB GraphDB, Dex, Titan, InfiniteGraph, etc.

La pila Tinkerpop incluye la interfaz Blueprint propiedad del modelo gráfico, el lenguaje traversal Gremlin gráfica, y el paquete de algoritmos Furnace gráfico.

Por otro lado tenemos W3C's Linked Data technology stack, que está soportado por AllegroGraph, 4store, Oracle Database Semantic Technologies, OWLIM, SYSTap BigData, etc.

semántico de datos se representa usando RDF/RDFS/OWL, y se puede consultar utilizando SPARQL En la parte superior ofrece rules y reasoning capacidades.

Supongamos ahora que quiero representar datos heterogéneos en una base de datos de gráficos y analizar tales datos (estadísticas, descubrimiento de relaciones, estructura, evolución, etc.) (sé que estos términos son amplios y vagos) - ¿Qué son? las fortalezas relativas de cada modelo para varios tipos de tareas de análisis de red? ¿Estos dos modelos se complementan?

Answer 1

Un par de cosas, sus ejemplos de pilas de datos vinculadas son todas tiendas triples. Comenzarías a construir una aplicación de datos vinculada al primero configurar tu tienda triple, pero llamar a una base de datos una pila de datos vinculada es incorrecto. También es una lista incompleta de tiendas triples, también hay Sesame, Jena, Mulgara y Stardog. El tipo de deber doble de Sesame y Jena, son las dos API de Java estándar de facto para la web semántica, pero ambas ofrecen tiendas triples que vienen incluidas con las API. También sé que tanto Cray como IBM están trabajando en tiendas triples, pero no sé mucho sobre ninguno en este momento. Sé que Stardog funciona bien con la pila TinkerPop y que básicamente se trata de una gota y comienza a escribir consultas de Gremlin contra el RDF.

creo que los puntos fuertes de RDF/OWL es que 1) obtener un lenguaje de consulta real, 2) son estándares W3C y 3) que presentamos lo mejor razonamiento, si la tienda de triple soporta, de forma gratuita (más o menos, todavía tienes que escribir una ontología).

Con RDF/OWL/SPARQL como estándares, hace que sea bastante fácil recoger y mover a una nueva tienda triple con un conjunto de características diferente si lo necesita, sus datos ya están en un formato común que todos entienden y cualquier lógica de aplicación codificada como consultas es completamente portátil. Y en la mayoría de los casos, estarías escribiendo contra las API de Sesame o Jena, o trabajando sobre el protocolo SPARQL, por lo que es posible que solo necesites cambiar tu config/init. Creo que es una gran victoria en las primeras fases de creación de prototipos.

También creo que RDF/OWL especialmente combinados con razonamiento y los tipos de consultas SPARQL complejas que puede crear con el nuevo SPARQL 1.1 realmente se adaptan bien a la construcción de aplicaciones analíticas complicadas.Además, creo que la impresión de que la mayoría de la gente tiene que las tiendas triples de RDF no se escalan ya no es correcta. La mayoría de las tiendas triples en este punto se escalan fácilmente en miles de millones de triples y también tienen números de rendimiento muy competitivos.

De acuerdo con lo que creo que podría estar haciendo, creo que semweb podría ser una mejor opción para usted. Hice un proyecto similar hace unos años usando RDF & RDFS para el backend liderado por una simple aplicación basada en Pylons y estaba muy contento con los resultados.