Hi Mingli, FYI for the past 3 months I've been working almost fulltime on a lightweight, modular RDF Clojure toolkit, which I plan to opensource in the near future, once the core API has more solidified. The kit so far features:
* core RDF datatype protocols (URIs, blank nodes, literals, containers & XSD type handling via multimethods) * simple & named graphs, datasets of multiple graphs * protocol based triple store implementations: in-memory (Clojure data structures), Redis, Cassandra (WIP) * SPARQL style query & update engine: ** queries currently expressed as Clojure expressions ** SPARQL syntax parser (WIP) ** customizable query optimizations ** fixed-length property paths ** basic federation queries ** optional queries ** filter expressions, binding injection, grouping, sorting * graph -> tree mapper to turn a set of triples into nested object maps * rule based inferencing ** supplied rule set of common OWL/RDFS semantics * streaming Turtle & JSON-LD IO, SPARQL result export as CSV, XML & JSON * customizable CSV -> RDF conversion Current focus of development: * SPARQL HTTP endpoint & protocol implementation * Streamed reasoning/inferencing w/ SPARQL-T * Extend support of OWL semantics in query engine * SPIN support, allowing queries, constraints & inference rules to be defined in RDF * async distributed query processor * Library of AngularJS visualization directives/components of SPARQL results (written in CLJS) In terms of performance, I can't unfortunately share yet any real benchmark results since I've only recently started looking into that for some core components, but IMHO things are looking promising (and obviously still have lengths to go). E.g. Using the in-memory store, the standard LUBM dataset with 1 uni & 105k triples loads in avg. 4.8 secs on a 2010 MBP. With the Redis store (using the fabulous Carmine lib), the same loads in under 11 secs, but I know this will be a lot faster once I've switched to batching. So far the query engine has only been tested with smaller datasets (around 20k triples) and medium complex queries w/ around a dozen of graph patterns (incl. paths & optional queries) and hundred of results complete in < 100 ms. I will announce the release on this list once I'm comfortable with the basic setup & have spent some quality time on documentation... On 5 Aug 2013 18:13, "Timothy Baldridge" <tbaldri...@gmail.com> wrote: > This looks a re-implementation of many of the goals of Datomic. Perhaps > you can use Datomic as a datastore, and then use Datomic's datalog, or a > custom query engine (such as core.logic > https://github.com/clojure/core.logic/blob/master/src/main/clojure/clojure/core/logic/datomic.clj) > to do your queries? > > Timothy > > > On Mon, Aug 5, 2013 at 10:52 AM, David Nolen <dnolen.li...@gmail.com>wrote: > >> Very interesting. The rel feature is really still a bit of an >> experimental thing and we'd like to replace it eventually with something >> less problematic like pldb http://github.com/threatgrid/pldb. >> >> Still, core.logic isn't really a database and your needs may be better >> served by something with different goals. >> >> David >> >> >> On Mon, Aug 5, 2013 at 12:41 PM, Mingli Yuan <mingli.y...@gmail.com>wrote: >> >>> Hi, folks, >>> >>> After one night quick work, I had gave a proof-of-concept to demonstrate >>> the feasibility that we can combine Wikidata and Clojure logic programming >>> together. >>> >>> The source code is at here: >>> https://github.com/mountain/knowledge >>> >>> An example of an entity: >>> >>> https://github.com/mountain/knowledge/blob/master/src/entities/albert_einstein.clj >>> >>> Example of types: >>> https://github.com/mountain/knowledge/blob/master/src/meta/types.clj >>> >>> Example of predicates: >>> https://github.com/mountain/knowledge/blob/master/src/meta/properties.clj >>> >>> Example of inference: >>> https://github.com/mountain/knowledge/blob/master/test/knowledge/test.clj >>> >>> Also we found it is very easy to get any other language version than >>> English. >>> >>> Since I am new to Clojure logic programming, I have questions for the >>> way I take - what will happen when we have millions of triples? Should >>> I take another approach by using some RDF store? >>> >>> - How many memory will it cost? >>> - How about the performance? >>> - How about the loading process of one million clojure source file >>> or java class file? >>> >>> Hope you can give some helpful comments. Thanks in advance. >>> >>> Regards, >>> Mingli >>> >>> -- >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clojure@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
