You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Bart van Leeuwen <ba...@netage.nl> on 2015/08/19 17:14:10 UTC

Apache Tinkerpop as Jena Backend ?

Hi,

Would it be possible to use Apache Tinkerpop [1] as a Jena backend ?

[1] http://tinkerpop.incubator.apache.org/

Met Vriendelijke Groet / With Kind Regards
Bart van Leeuwen

##############################################################
# twitter: @semanticfire
# netage.nl
# http://netage.nl
# M.A. Reinaldaweg 79
# 3461AJ Linschoten
# tel. +31(0)6-53182997
##############################################################

Re: Apache Tinkerpop as Jena Backend ?

Posted by Claude Warren <cl...@xenei.com>.
Bart,

You might want to look at SDB running on one of the relational databases
that bluemix provides.  Not a good solution in terms of high performance
but one that should work.

Claude

On Sat, Aug 22, 2015 at 10:51 AM, Bart van Leeuwen <
bart_van_leeuwen@netage.nl> wrote:

> Hi Andy,
>
> Thanks for the elaborate answer!
>
> The reason that I asked is that I'm still looking for a way to have triple
> store with IBM Bluemix.
> One of their lab offerings is Tinkerpop hence the question.
>
> For now I'm probably stuck with using a cloud based triple store like
> Dydra,
> or run my own server with a triple store in a cloud based VM
>
> Met Vriendelijke Groet / With Kind Regards
> Bart van Leeuwen
>
> ##############################################################
> # twitter: @semanticfire
> # netage.nl
> # http://netage.nl
> # M.A. Reinaldaweg 79
> # 3461AJ Linschoten
> # tel. +31(0)6-53182997
> ##############################################################
>
>
>
> From:   Andy Seaborne <an...@apache.org>
> To:     "users@jena.apache.org" <us...@jena.apache.org>
> Date:   21-08-2015 12:44
> Subject:        Re: Apache Tinkerpop as Jena Backend ?
>
>
>
> On 19/08/15 16:14, Bart van Leeuwen wrote:
> > Hi,
> >
> > Would it be possible to use Apache Tinkerpop [1] as a Jena backend ?
> >
> > [1] http://tinkerpop.incubator.apache.org/
> >
> > Met Vriendelijke Groet / With Kind Regards
> > Bart van Leeuwen
>
> Short answer : there isn't code to do it that I recall anyone talking
> about.
>
> Long answer: [*]
>
> Property Graphs (PG) and RDF have a lot in common (obviously!).  Using
> one with the other would open some interesting possibilities.  A
> Gremlin+RDF-like traversal language would be great.
>
> In the direction "Jena over Tinkerpop" using a PG storage to put in RDF
> looks OK if the fact that in PG values and links are separate c.f.
> owl:DatatypeProperty and owl:ObjectProperty.
>
> If you have a schema, (and data that promised faithfully to follow the
> schema:-)), then by knowing if a RDF property is a datatypeProperty or
> an objectProperty, it looks quite easy to look in the right way to use
> RDF on PG.  Otherwise there is a risk of needing to look in two places,
> which might work for many cases but the scale implications don't look
> good.
>
> This gets to one key point - PG is not so much about data integration
> later, whereas RDF is.  Practically, to use PG, there is a data model
> design step when setting up the database and it's done for the task,
> leaving work later for integration conversion.
>
> Viewing an existing PG graph as RDF looks like more conversion is needed
> - one PG edge or value might not be one RDF triple. if edge attributes
> are being used or if multiple edges of the same name occur.
> (not that edge attributes are necessarily good modelling in PG in
> general - some useful cases, but the "email message sent" link is an
> example of bad modelling).
>
> Its all about the details - using one with the other for a constrained
> application where some compromises can be knowing made is very different
> to having a complete implementation of one data model on the other.
>
> There is a related question of whether some of the tinkerpop technology
> can be used to make a Jena backend and also whether TDB technology
> (index code, transaction framework) would make a good substrate for
> tinkerpop storage, or even the clustered version (Lizard).
>
>                  Andy
>
> [*] http://sched.co/3ztL
> "A tale of two graphs: Property Graphs and RDF"
> An ApacheCon BigData talk
> with Paolo Castagna.
>
> Budapest, Monday, September 28 • 15:00 - 16:00
>
>
>
>
>


-- 
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren

Re: Apache Tinkerpop as Jena Backend ?

Posted by Bart van Leeuwen <ba...@netage.nl>.
Hi Andy,

Thanks for the elaborate answer!

The reason that I asked is that I'm still looking for a way to have triple 
store with IBM Bluemix.
One of their lab offerings is Tinkerpop hence the question.

For now I'm probably stuck with using a cloud based triple store like 
Dydra,
or run my own server with a triple store in a cloud based VM

Met Vriendelijke Groet / With Kind Regards
Bart van Leeuwen

##############################################################
# twitter: @semanticfire
# netage.nl
# http://netage.nl
# M.A. Reinaldaweg 79
# 3461AJ Linschoten
# tel. +31(0)6-53182997
##############################################################



From:   Andy Seaborne <an...@apache.org>
To:     "users@jena.apache.org" <us...@jena.apache.org>
Date:   21-08-2015 12:44
Subject:        Re: Apache Tinkerpop as Jena Backend ?



On 19/08/15 16:14, Bart van Leeuwen wrote:
> Hi,
>
> Would it be possible to use Apache Tinkerpop [1] as a Jena backend ?
>
> [1] http://tinkerpop.incubator.apache.org/
>
> Met Vriendelijke Groet / With Kind Regards
> Bart van Leeuwen

Short answer : there isn't code to do it that I recall anyone talking 
about.

Long answer: [*]

Property Graphs (PG) and RDF have a lot in common (obviously!).  Using 
one with the other would open some interesting possibilities.  A 
Gremlin+RDF-like traversal language would be great.

In the direction "Jena over Tinkerpop" using a PG storage to put in RDF 
looks OK if the fact that in PG values and links are separate c.f. 
owl:DatatypeProperty and owl:ObjectProperty.

If you have a schema, (and data that promised faithfully to follow the 
schema:-)), then by knowing if a RDF property is a datatypeProperty or 
an objectProperty, it looks quite easy to look in the right way to use 
RDF on PG.  Otherwise there is a risk of needing to look in two places, 
which might work for many cases but the scale implications don't look 
good.

This gets to one key point - PG is not so much about data integration 
later, whereas RDF is.  Practically, to use PG, there is a data model 
design step when setting up the database and it's done for the task, 
leaving work later for integration conversion.

Viewing an existing PG graph as RDF looks like more conversion is needed 
- one PG edge or value might not be one RDF triple. if edge attributes 
are being used or if multiple edges of the same name occur.
(not that edge attributes are necessarily good modelling in PG in 
general - some useful cases, but the "email message sent" link is an 
example of bad modelling).

Its all about the details - using one with the other for a constrained 
application where some compromises can be knowing made is very different 
to having a complete implementation of one data model on the other.

There is a related question of whether some of the tinkerpop technology 
can be used to make a Jena backend and also whether TDB technology 
(index code, transaction framework) would make a good substrate for 
tinkerpop storage, or even the clustered version (Lizard).

                 Andy

[*] http://sched.co/3ztL
"A tale of two graphs: Property Graphs and RDF"
An ApacheCon BigData talk
with Paolo Castagna.

Budapest, Monday, September 28 • 15:00 - 16:00





Re: Apache Tinkerpop as Jena Backend ?

Posted by Andy Seaborne <an...@apache.org>.
On 19/08/15 16:14, Bart van Leeuwen wrote:
> Hi,
>
> Would it be possible to use Apache Tinkerpop [1] as a Jena backend ?
>
> [1] http://tinkerpop.incubator.apache.org/
>
> Met Vriendelijke Groet / With Kind Regards
> Bart van Leeuwen

Short answer : there isn't code to do it that I recall anyone talking about.

Long answer: [*]

Property Graphs (PG) and RDF have a lot in common (obviously!).  Using 
one with the other would open some interesting possibilities.  A 
Gremlin+RDF-like traversal language would be great.

In the direction "Jena over Tinkerpop" using a PG storage to put in RDF 
looks OK if the fact that in PG values and links are separate c.f. 
owl:DatatypeProperty and owl:ObjectProperty.

If you have a schema, (and data that promised faithfully to follow the 
schema:-)), then by knowing if a RDF property is a datatypeProperty or 
an objectProperty, it looks quite easy to look in the right way to use 
RDF on PG.  Otherwise there is a risk of needing to look in two places, 
which might work for many cases but the scale implications don't look good.

This gets to one key point - PG is not so much about data integration 
later, whereas RDF is.  Practically, to use PG, there is a data model 
design step when setting up the database and it's done for the task, 
leaving work later for integration conversion.

Viewing an existing PG graph as RDF looks like more conversion is needed 
- one PG edge or value might not be one RDF triple. if edge attributes 
are being used or if multiple edges of the same name occur.
(not that edge attributes are necessarily good modelling in PG in 
general - some useful cases, but the "email message sent" link is an 
example of bad modelling).

Its all about the details - using one with the other for a constrained 
application where some compromises can be knowing made is very different 
to having a complete implementation of one data model on the other.

There is a related question of whether some of the tinkerpop technology 
can be used to make a Jena backend and also whether TDB technology 
(index code, transaction framework) would make a good substrate for 
tinkerpop storage, or even the clustered version (Lizard).

	Andy

[*] http://sched.co/3ztL
"A tale of two graphs: Property Graphs and RDF"
An ApacheCon BigData talk
with Paolo Castagna.

Budapest, Monday, September 28 • 15:00 - 16:00