Hello,
The model proposed below is in-line with TinkerPop2’s way of thinking.
Unfortunately, TinkerPop3 and more so for TinkerPop4, the Graph “structure" API
will become deprecated. This means that the notion of “wrapping the Graph API”
has gone away for TP3 and will be completely gone in TP4. In TP4, there will
not even be a Graph API — no more Vertex, Edge, Property, etc. Only the concept
of a Graph with only methods like Graph.traversal(), Graph.partitions(), etc.
Why was this route taken? In TinkerPop3, there was a need to support any
language besides Java. This was why Gremlin bytecode and the concept of the
Gremlin traversal machine was introduced. A provider simply gets Gremlin
bytecode and has to do something with it. For the Java-based Gremlin traversal
machine, this is why providers implement their own GraphStep, VertexStep, etc.
For a Python-based Gremlin traversal machine, likewise…
This means that SailGraph, GraphSail, PropertyGraphSail as stated below don’t
make sense in the current and future architectures.
The next question becomes, "well how would you turn an RDF store into a
PropertyGraph?” Easy — implement your own custom GraphStep, VertexStep, etc.
and respective ProviderStrategies that will handle the bytecode compilation
accordingly.
The next question becomes, “well how would a PropertyGraph support reasoning?”
Easy — implement your own custom DecorationStrategy that will insert reasoning
into the traversal giving the RDFS schema. For instance:
g.V().out(“likes”)
==>
g.V().out(“knows”,”likes”)
iff “likes” is a sub-property of “knows”
In essence, it is possible to do this integration of RDF and TinkerPop, it just
needs to be done at the correct level of abstraction so that it stays in line
with how TinkerPop is evolving, not how it was back in 2012.
Take care,
Marko.
http://markorodriguez <http://markorodriguez/>.com
On 2017-12-13 07:46, Joshua Shinavier <[email protected]> wrote:
> Hi Harsh,>
>
> Glad you are taking Daniel's work forward. In porting the code to the>
> TinkerPop code base, might I suggest we allow for not only SPARQL-Gremlin,>
> but a whole suite of RDF tools as in TP2. Perhaps call the module>
> rdf-gremlin. Then we could have all of:>
>
> * SPARQL-Gremlin: executes standard SPARQL queries over a Property Graph>
> database>
> * GraphSail [1,2]: stores RDF quads in the database, explicitly, and>
> enables SPARQL and triple pattern queries over the quads>
> * PropertyGraphSail [3]: exposes a Property Graph with of two mappings to>
> the RDF data model>
> * SailGraph [4]: takes an RDF triple store (not natively supporting>
> Gremlin) and enables Gremlin queries>
> * others? I have often thought that a continuous SPARQL implementation>
> built on Gremlin would be powerful>
>
> The biggest mismatch between the TP2 suite and what might be built for>
> Apache TinkerPop is that the previous suite was implemented using (Eclipse)>
> RDF4j, whereas things seem to be leaning towards (Apache) Jena now.>
> However, the same principles could be applied.>
>
> Josh>
>
>
> [1] https://github.com/tinkerpop/blueprints/wiki/Sail-Ouplementation>
> [2] https://github.com/joshsh/graphsail>
> [3]>
> https://github.com/tinkerpop/blueprints/wiki/PropertyGraphSail-Ouplementation>
>
> [4] https://github.com/tinkerpop/blueprints/wiki/Sail-Implementation
http://markorodriguez.com
