search

cordawyn / spira

Fork of Spira with experimental branches, occasionally merged upstream.
http://blog.datagraph.org/2010/05/spira
The Unlicense
8 stars 2 forks source link

"Finding" is quite rudimentary and is crying for SPARQL support #6

Open cordawyn opened 12 years ago

pkordel commented 12 years ago

I'm working on a project that uses virtuoso as an rdf store. I have started a rdf-virtuoso skeleton and I think your fork would be a great match. Do you have any thoughts on how best to tackle sparql support? I have experimented with sparql-client but my intention is to integrate with your codebase in a rails/rack compliant way. So virtuoso could be one of several rdf storage adapters in a AR sort of way. Would love to get to an AREL type query builder also. This seems like a pretty big task and I'm wondering what would be a good first step. Thoughts?

cordawyn commented 12 years ago

Unless you've already seen it, the requests for SPARQL support have been around for some time, e.g.: https://github.com/datagraph/spira/issues/35 https://github.com/datagraph/spira/issues/10 There are a few interesting thoughts there.

As for this ("activemodelish") branch of Spira, there are a few points that I think should be addressed:

1) If SPARQL is introduced, it better be able to perform the whole stack of CRUD and thus completely replace the internals of Spira interaction with the storage.

2) AREL-type query builder might be a good thing, but it should be noted that: a) its interface and ideas reflect the world of SQL and is probably too restrictive for SPARQL (but we're fine with it, read on), b) Spira behavior is a trade between SQL and SPARQL - my primary concern is compatibility with the existing popular gems used in Rails projects (btw, Spira works fine with simple_form and dragonfly, among others), so the public API has to be as close as possible to ActiveRecord's new/build, update_attributes, find, etc. - all those methods that are heavily used by gems, plugins and custom projects.

I think it's OK to start with building simple strings of SPARQL internally, provided that you attempt to structure the building methods such as to be able to wrap them into AREL-like interface later. Just make it perform CRUD for starters.

pkordel commented 12 years ago

1) Agree totally. I need the full CRUD stack also. For now I'm doing just basic auth against the sparql-update endpoint, other concerns come later.

2) I'm playing around with a module I lifted from sparql client, it's in RDF::Virtuoso::Query in https://github.com/pkordel/rdf-virtuoso. Creating optimized sparql queries with a builder is a bit challenging, especially since Virtuoso keeps adding non-standard functions such as SAMPLE, GROUP_DIGEST and GROUP_CONCAT for example. I'm working on a production prototype in the context of book reviews and book metadata for a library and there are a number of challenges, which is a pretty good testbed for development. My intention is also to be as close to AR compatibility as possible. Been looking at the mongoid and neo4j projects for inspiration.

So yes, I'll probably start with overriding the query method in ::Repository for a start. Queries can quickly become quite complex with 2 or more graphs being joined, so it's a juicy challenge.