You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Claude Warren <cl...@xenei.com> on 2013/04/02 14:13:05 UTC
jdbc4sparql
Rob,
I took a quick look at your JDBC experimental project. I didn't see where
it provided a SQL interface. Am I missing something?
I have a JDBC4SPARQL project as well -- due to the SQL parser it is not
entirely Apache licensed -- the instance I have talks so SPARQL endpoints
or any Jena readable RDF format file. It presents a compliant JDBC driver
that allows BI tools and other JDBC consumers to view the graph as a
relational database. The mechanism for creating virtual tables is
pluggable -- currently is assumes that all "class" instances are tables and
all properties of the instances are columns.
If you want to take a look it is at: https://github.com/Claudenw/jdbc4sparql
I would be more than happy to contribute it to the JDBC experimental
project if you think it would help.
-- Claude
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
Identity: https://www.identify.nu/user.php?claude@xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: jdbc4sparql
Posted by Claude Warren <cl...@xenei.com>.
My experience with determining what resources should be within a single
table stems from several papers and research projects I saw when I worked
at DERI (http://www.deri.ie).
I came to realize that an arbitrary SPARQL query can be viewed as the
equivalent of a table in a relational DB. The issue is in building the
SPARQL to represent what you want to query, and there are probably 2x as
many ways to do that as there are researchers interested.
The upshot is that the code I have allows you to plug in a "schema builder"
that defines the "tables" as deconstructed SPARQL queries. The default
implementation is dumb simple and sees all "rdfs:type"'s as tables and all
properties of any object with that type as columns. (This strategy allows
the default engine to work with any SPARQL endpoint or RDF file without
knowing about any associated schema -- RDF type schema not DB schema).
Other implementations could very easily use declarative processes using
R2RML. Other implementations could very easily use a more complex method
of determining table construction from the RDF data.
-- Claude
On Wed, Apr 3, 2013 at 2:19 PM, Paul Gearon <ge...@ieee.org> wrote:
> Hi,
>
> Rob... this sounds interesting, though I missed the link for the project.
> Pointer please?
>
> My own attempt a this a few years ago is at:
> https://code.google.com/p/scon/wiki/Introduction
>
> Feel free to ransack it for code. :-)
>
> Claude... in terms of automatically providing an RDBMS view of RDF, it
> seems to me that the inferencing in the schema builder would be limited.
> Have you found this? I would think that something like R2RML would provide
> a more consistent mapping (though this has been defined for mapping in the
> opposite direction). I'm interested to hear your experiences.
>
> Regards,
> Paul Gearon
>
> On Tue, Apr 2, 2013 at 12:47 PM, Rob Vesse <rv...@yarcdata.com> wrote:
>
> > Reformatted so you can actually tell who said what:
> >
> >
> > On 4/2/13 9:30 AM, "Rob Vesse" <rv...@cray.com> wrote:
> >
> > >Comments inline:
> > >
> > >From: Claude Warren <cl...@xenei.com>>
> > >Date: Tuesday, April 2, 2013 5:13 AM
> > >To: Rob Vesse <rv...@yarcdata.com>>,
> > >"jena-users@apache.org<ma...@apache.org>"
> > ><je...@apache.org>>
> > >Subject: jdbc4sparql
> > >
> > >Rob,
> > >
> > >I took a quick look at your JDBC experimental project. I didn't see
> > >where it provided a SQL interface. Am I missing something?
> >
> > Nope it intentionally doesn't have one, the aim of my design is to
> provide
> > a JDBC wrapper around SPARQL and not to try and present any kind of fake
> > SQL abstraction layer on top of it.
> >
> > >
> > >
> > >I have a JDBC4SPARQL project as well -- due to the SQL parser it is not
> > >entirely Apache licensed -- the instance I have talks so SPARQL
> endpoints
> > >or any Jena readable RDF format file. It presents a compliant JDBC
> > >driver that allows BI tools and other JDBC consumers to view the graph
> as
> > >a relational database. The mechanism for creating virtual tables is
> > >pluggable -- currently is assumes that all "class" instances are tables
> > >and all properties of the instances are columns.
> > >
> > >If you want to take a look it is at:
> > >https://github.com/Claudenw/jdbc4sparql
> > >
> > >I would be more than happy to contribute it to the JDBC experimental
> > >project if you think it would help.
> > >
> >
> > Adding some sort of layer on top of what I am building to provide the SQL
> > abstraction on top of it might be a nice future extension but right now I
> > am trying to concentrate on getting a solid basic implementation of JDBC
> > to SPARQL going
> >
> > Rob
> >
> > >
> > >
> > >-- Claude
> > >
> > >--
> > >I like: Like Like - The likeliest place on the
> > >web<http://like-like.xenei.com>
> > >Identity: https://www.identify.nu/user.php?claude@xenei.com
> > >LinkedIn: http://www.linkedin.com/in/claudewarren
> >
> >
>
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
Identity: https://www.identify.nu/user.php?claude@xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: jdbc4sparql
Posted by Rob Vesse <rv...@yarcdata.com>.
It's an experimental module in SVN only at the moment, there is minimal
documentation and it is pretty early stage still
See http://svn.apache.org/repos/asf/jena/Experimental/jena-jdbc
There is a README that summarizes the aims, (very) basic design overview
and drivers provided plus my personal TODO list
I seem to be suddenly flooded with peoples JDBC to SPARQL efforts, kinda
useful for seeing how people tackled some of the thornier things I haven't
got to yet.
Rob
On 4/3/13 6:19 AM, "Paul Gearon" <ge...@ieee.org> wrote:
>Hi,
>
>Rob... this sounds interesting, though I missed the link for the project.
>Pointer please?
>
>My own attempt a this a few years ago is at:
> https://code.google.com/p/scon/wiki/Introduction
>
>Feel free to ransack it for code. :-)
>
>Claude... in terms of automatically providing an RDBMS view of RDF, it
>seems to me that the inferencing in the schema builder would be limited.
>Have you found this? I would think that something like R2RML would provide
>a more consistent mapping (though this has been defined for mapping in the
>opposite direction). I'm interested to hear your experiences.
>
>Regards,
>Paul Gearon
>
>On Tue, Apr 2, 2013 at 12:47 PM, Rob Vesse <rv...@yarcdata.com> wrote:
>
>> Reformatted so you can actually tell who said what:
>>
>>
>> On 4/2/13 9:30 AM, "Rob Vesse" <rv...@cray.com> wrote:
>>
>> >Comments inline:
>> >
>> >From: Claude Warren <cl...@xenei.com>>
>> >Date: Tuesday, April 2, 2013 5:13 AM
>> >To: Rob Vesse <rv...@yarcdata.com>>,
>> >"jena-users@apache.org<ma...@apache.org>"
>> ><je...@apache.org>>
>> >Subject: jdbc4sparql
>> >
>> >Rob,
>> >
>> >I took a quick look at your JDBC experimental project. I didn't see
>> >where it provided a SQL interface. Am I missing something?
>>
>> Nope it intentionally doesn't have one, the aim of my design is to
>>provide
>> a JDBC wrapper around SPARQL and not to try and present any kind of fake
>> SQL abstraction layer on top of it.
>>
>> >
>> >
>> >I have a JDBC4SPARQL project as well -- due to the SQL parser it is not
>> >entirely Apache licensed -- the instance I have talks so SPARQL
>>endpoints
>> >or any Jena readable RDF format file. It presents a compliant JDBC
>> >driver that allows BI tools and other JDBC consumers to view the graph
>>as
>> >a relational database. The mechanism for creating virtual tables is
>> >pluggable -- currently is assumes that all "class" instances are tables
>> >and all properties of the instances are columns.
>> >
>> >If you want to take a look it is at:
>> >https://github.com/Claudenw/jdbc4sparql
>> >
>> >I would be more than happy to contribute it to the JDBC experimental
>> >project if you think it would help.
>> >
>>
>> Adding some sort of layer on top of what I am building to provide the
>>SQL
>> abstraction on top of it might be a nice future extension but right now
>>I
>> am trying to concentrate on getting a solid basic implementation of JDBC
>> to SPARQL going
>>
>> Rob
>>
>> >
>> >
>> >-- Claude
>> >
>> >--
>> >I like: Like Like - The likeliest place on the
>> >web<http://like-like.xenei.com>
>> >Identity: https://www.identify.nu/user.php?claude@xenei.com
>> >LinkedIn: http://www.linkedin.com/in/claudewarren
>>
>>
Re: jdbc4sparql
Posted by Paul Gearon <ge...@ieee.org>.
Hi,
Rob... this sounds interesting, though I missed the link for the project.
Pointer please?
My own attempt a this a few years ago is at:
https://code.google.com/p/scon/wiki/Introduction
Feel free to ransack it for code. :-)
Claude... in terms of automatically providing an RDBMS view of RDF, it
seems to me that the inferencing in the schema builder would be limited.
Have you found this? I would think that something like R2RML would provide
a more consistent mapping (though this has been defined for mapping in the
opposite direction). I'm interested to hear your experiences.
Regards,
Paul Gearon
On Tue, Apr 2, 2013 at 12:47 PM, Rob Vesse <rv...@yarcdata.com> wrote:
> Reformatted so you can actually tell who said what:
>
>
> On 4/2/13 9:30 AM, "Rob Vesse" <rv...@cray.com> wrote:
>
> >Comments inline:
> >
> >From: Claude Warren <cl...@xenei.com>>
> >Date: Tuesday, April 2, 2013 5:13 AM
> >To: Rob Vesse <rv...@yarcdata.com>>,
> >"jena-users@apache.org<ma...@apache.org>"
> ><je...@apache.org>>
> >Subject: jdbc4sparql
> >
> >Rob,
> >
> >I took a quick look at your JDBC experimental project. I didn't see
> >where it provided a SQL interface. Am I missing something?
>
> Nope it intentionally doesn't have one, the aim of my design is to provide
> a JDBC wrapper around SPARQL and not to try and present any kind of fake
> SQL abstraction layer on top of it.
>
> >
> >
> >I have a JDBC4SPARQL project as well -- due to the SQL parser it is not
> >entirely Apache licensed -- the instance I have talks so SPARQL endpoints
> >or any Jena readable RDF format file. It presents a compliant JDBC
> >driver that allows BI tools and other JDBC consumers to view the graph as
> >a relational database. The mechanism for creating virtual tables is
> >pluggable -- currently is assumes that all "class" instances are tables
> >and all properties of the instances are columns.
> >
> >If you want to take a look it is at:
> >https://github.com/Claudenw/jdbc4sparql
> >
> >I would be more than happy to contribute it to the JDBC experimental
> >project if you think it would help.
> >
>
> Adding some sort of layer on top of what I am building to provide the SQL
> abstraction on top of it might be a nice future extension but right now I
> am trying to concentrate on getting a solid basic implementation of JDBC
> to SPARQL going
>
> Rob
>
> >
> >
> >-- Claude
> >
> >--
> >I like: Like Like - The likeliest place on the
> >web<http://like-like.xenei.com>
> >Identity: https://www.identify.nu/user.php?claude@xenei.com
> >LinkedIn: http://www.linkedin.com/in/claudewarren
>
>
Re: jdbc4sparql
Posted by Rob Vesse <rv...@yarcdata.com>.
Reformatted so you can actually tell who said what:
On 4/2/13 9:30 AM, "Rob Vesse" <rv...@cray.com> wrote:
>Comments inline:
>
>From: Claude Warren <cl...@xenei.com>>
>Date: Tuesday, April 2, 2013 5:13 AM
>To: Rob Vesse <rv...@yarcdata.com>>,
>"jena-users@apache.org<ma...@apache.org>"
><je...@apache.org>>
>Subject: jdbc4sparql
>
>Rob,
>
>I took a quick look at your JDBC experimental project. I didn't see
>where it provided a SQL interface. Am I missing something?
Nope it intentionally doesn't have one, the aim of my design is to provide
a JDBC wrapper around SPARQL and not to try and present any kind of fake
SQL abstraction layer on top of it.
>
>
>I have a JDBC4SPARQL project as well -- due to the SQL parser it is not
>entirely Apache licensed -- the instance I have talks so SPARQL endpoints
>or any Jena readable RDF format file. It presents a compliant JDBC
>driver that allows BI tools and other JDBC consumers to view the graph as
>a relational database. The mechanism for creating virtual tables is
>pluggable -- currently is assumes that all "class" instances are tables
>and all properties of the instances are columns.
>
>If you want to take a look it is at:
>https://github.com/Claudenw/jdbc4sparql
>
>I would be more than happy to contribute it to the JDBC experimental
>project if you think it would help.
>
Adding some sort of layer on top of what I am building to provide the SQL
abstraction on top of it might be a nice future extension but right now I
am trying to concentrate on getting a solid basic implementation of JDBC
to SPARQL going
Rob
>
>
>-- Claude
>
>--
>I like: Like Like - The likeliest place on the
>web<http://like-like.xenei.com>
>Identity: https://www.identify.nu/user.php?claude@xenei.com
>LinkedIn: http://www.linkedin.com/in/claudewarren
Re: jdbc4sparql
Posted by Rob Vesse <rv...@yarcdata.com>.
Comments inline:
From: Claude Warren <cl...@xenei.com>>
Date: Tuesday, April 2, 2013 5:13 AM
To: Rob Vesse <rv...@yarcdata.com>>, "jena-users@apache.org<ma...@apache.org>" <je...@apache.org>>
Subject: jdbc4sparql
Rob,
I took a quick look at your JDBC experimental project. I didn't see where it provided a SQL interface. Am I missing something?
Nope it intentionally doesn't have one, the aim of my design is to provide a JDBC wrapper around SPARQL and not to try and present any kind of fake SQL abstraction layer on top of it.
I have a JDBC4SPARQL project as well -- due to the SQL parser it is not entirely Apache licensed -- the instance I have talks so SPARQL endpoints or any Jena readable RDF format file. It presents a compliant JDBC driver that allows BI tools and other JDBC consumers to view the graph as a relational database. The mechanism for creating virtual tables is pluggable -- currently is assumes that all "class" instances are tables and all properties of the instances are columns.
If you want to take a look it is at: https://github.com/Claudenw/jdbc4sparql
I would be more than happy to contribute it to the JDBC experimental project if you think it would help.
Adding some sort of layer on top of what I am building to provide the SQL abstraction on top of it might be a nice future extension but right now I am trying to concentrate on getting a solid basic implementation of JDBC to SPARQL going
Rob
-- Claude
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
Identity: https://www.identify.nu/user.php?claude@xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren