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 <[email protected]> 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 <[email protected]> wrote: > > > Reformatted so you can actually tell who said what: > > > > > > On 4/2/13 9:30 AM, "Rob Vesse" <[email protected]> wrote: > > > > >Comments inline: > > > > > >From: Claude Warren <[email protected]<mailto:[email protected]>> > > >Date: Tuesday, April 2, 2013 5:13 AM > > >To: Rob Vesse <[email protected]<mailto:[email protected]>>, > > >"[email protected]<mailto:[email protected]>" > > ><[email protected]<mailto:[email protected]>> > > >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/[email protected] > > >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/[email protected] LinkedIn: http://www.linkedin.com/in/claudewarren
