Re: RDF.ex

> On Jul 1, 2017, at 3:23 PM, Marcel Otto <marcelotto.de@googlemail.com> wrote:
> 
> I didn’t mean the RDF.rb eco-system at all. This is very great and I’d like to thank you for your continuous work on it. My speculative thoughts about the future of Ruby vs. Python were only meant with respect to the fields Anthony mentioned initially.
> 
> Regarding your question of missing facilities and room for improvements for the RDF.rb eco-system, I, for one, was missing a proper ORM the most. I’ve tried Spira and Tripod, but wasn’t that satisfied. I’ve worked on an object-oriented RDF mapper for Ruby myself before switching to Elixir. I think the recent RDF Shape standards, ShEx and SHACL, would be very interesting to use for an ORM.

You might check out ActiveTriples [3].

There’s also a ShEx gem [4], for which there a number of interesting things that might be done.

I also use JSON::LD::Resource from the json-ld gem [5] for a number of read-only maps from RDF, combined with an appropriate Frame, for example in the Turtle Test runner [6]. This isn’t perfect, and could use a fair bit of improvement. I started out using it for managing documents kept in Mongo, so there is some synchronization code; it could be adapted to a repository backend too.

Gregg

[3] https://github.com/ActiveTriples/ActiveTriples <https://github.com/ActiveTriples/ActiveTriples>
[4] https://github.com/ruby-rdf/shex <https://github.com/ruby-rdf/shex>
[5] https://github.com/ruby-rdf/json-ld/blob/develop/lib/json/ld/resource.rb <https://github.com/ruby-rdf/json-ld/blob/develop/lib/json/ld/resource.rb>
[6] https://github.com/ruby-rdf/rdf-turtle/blob/develop/spec/suite_helper.rb#L139-L143

> Regards,
> Marcel
> 
> 
>> On 1. Jul 2017, at 21:00, Gregg Kellogg <gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>> wrote:
>> 
>>> 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.
>