Re: RDF.ex

> On Jul 2, 2017, at 3:53 AM, Anthony Durity <a.durity@umail.ucc.ie> wrote:
> 
> > Where it is mostly lacking is in support for robust persistent repositories, where it relies on gems to bridge to external repos. 
> 
> Could you expand on this Gregg?

RDF.rb has an built-in Repository class that is implemented in memory using a kind of Hash. There are other gems to allow this to be persisted, that have varying degrees of support:

* rdf-mongo is probably the most up-to-date and has reasonable native performance.
* rdf-do is the original example persistent repo implementation based on DataObject (basically simplistic map to SQL). It hasn’t been touched in a while, and is currently failing.
* rdf-blazegraph; promising interface to the BlazeGraph triple store, but I believe there are some open issues
* sparql-client This includes a Repository interface to access a single graph. As with other interfaces to external repos, best performance is to query using the sparql-client gem itself, rather than the Ruby SPARQL gem.
* rdf-sesame unknown status
* rdf-marmotta repo for Apache Marmotta, Work in Progress
* rdf-virtuoso hasn’t been touched in 4 years
* rdf-agraph adaptor for AllegroGraph hasn’t been touched in 4 years

There are some other adaptors listed at https://github.com/ruby-rdf <https://github.com/ruby-rdf> which are marked Obsolete.

Really, the best bet is going to be to use an external repository through SPARQL::Client::Repository, and perform queries directly using SPARQL::Client. The other gems could use community support; personally, I’d look at the RDF::BlazeGraph gem.

Note that, while Ruby RDF has a full SPARQL 1.1 implementation, it is unoptimized, and works best for querying small in-memory graphs.

Gregg


> 2017-07-01 20:00 GMT+01:00 Gregg Kellogg <gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>>:
>> On Jul 1, 2017, at 11:09 AM, Marcel Otto <marcelotto.de@googlemail.com <mailto:marcelotto.de@googlemail.com>> wrote:
>> 
>> Regarding the syntax and the capabilities for DSLs I also agree, but I wouldn’t consider these benefits a substantial technical advantage, which would justify redoing the enormous amount of work done in the Python world in these fields. What would companies or academic institutions who have invested in these tools get above some nicer syntax? 
>> 
>> Essentially there is only a difference in the underlying philosophies of the languages. Although Rubys philosophy also speaks much more to me too, I could also imagine that Python's philosophy (<https://www.python.org/dev/peps/pep-0020/ <https://www.python.org/dev/peps/pep-0020/>>) speaks more to the scientists active in the fields in question, to many of whom the language is nothing more than a necessary tool, which should get out of their way. So they use what they are trained in and believe most of their peers want to use.
>> 
>> There will always be passionate developers, who care about the language so much, that they better invest time in reimplementing these tools in the language of their choice in their free time, but IMO this won't be enough, to catch up with the actual drivers in these fields, which are companies and academia.
>> 
>> But let me be clear: I would also be happy if more tools in these fields were available in Ruby than Python, but I don’t believe that this will happen realistically. Although I now would prefer Elixir and would argue, that it indeed would have real technical advantages to offer, I am even doubtful for Elixir.
> 
> IMHO, the Ruby RDF eco-system [1] is actually pretty robust, including basic RDF concepts, serializers and deserializers, SPARQL, ShEx, reasoning, Rails tie-ins and a fair amount more. Where it is mostly lacking is in support for robust persistent repositories, where it relies on gems to bridge to external repos. Of course, there’s always room for improvement, and I, for one, would be interested to hear about missing facilities that would make it that much better.
> 
> Regarding, Elixir, I think it’s great that this exists; Ruby will never be as performant as most other systems, but following the Rails philosophy, it’s usually good enough to get quite a bit of interesting things done. In the future, I’d like to see more bridges from Ruby to higher-performing libraries; if a good Elixir bridge emerges, that might be interesting to try to exploit, particularly given that the concepts align well. The Helix project [2] is making inroads for accelerating core methods in Rust.
> 
> Gregg
> 
> [1] https://github.com/ruby-rdf <https://github.com/ruby-rdf>
> [2] https://github.com/tildeio/helix <https://github.com/tildeio/helix>
> 
>> Despite all of that, these resources might be of interest for you: 
>> 
>> - https://github.com/arbox/data-science-with-ruby <https://github.com/arbox/data-science-with-ruby>
>> - https://github.com/arbox/machine-learning-with-ruby <https://github.com/arbox/machine-learning-with-ruby>
>> - https://github.com/arbox/nlp-with-ruby <https://github.com/arbox/nlp-with-ruby>
>> 
>> Regards,
>> Marcel
>> 
>>> On 1. Jul 2017, at 11:20, Martin J. Dürst <duerst@it.aoyama.ac.jp <mailto:duerst@it.aoyama.ac.jp>> wrote:
>>> 
>>> On 2017/06/28 06:07, Marcel Otto wrote:
>>> 
>>>> Regarding your question, I'm actually not very qualified to answer that, but I don't see how Ruby could catch up with Python's huge development leap in these fields. The languages are too similar, that there's no real technical benefit Ruby could bring to the table over Python.
>>> 
>>> Ruby has a quite different syntax from Python, much more fluid. When it comes to Web applications, DHH very clearly explained that Ruby was essential for Rails. If we can leverage things such as DSLs and so on, at which Ruby is very good, then it may be possible to get an advantage on Python in some of these fields.
>>> 
>>> Regards,   Martin.
>> 
> 
> 
> 
> 
> -- 
> PhD Candidate
> Philosophy / Digital Humanities
> University College Cork
> Ireland
> +353(0)857377737 <tel:+353857377737>
> Website <http://leto.electropoiesis.org/propaganda/ecce-homo>