Is there a Sesame SAIL for Jena TDB? - jena

Does anybody know of a Sesame SAIL implementation for the Jena TDB triple store? Even a beta version would be helpful to get started with.
[EDIT]
To satisfy whoever voted this question down for lack of research: I've queried the Jena archives, searched Stackoverflow, and googled a LOT, and did find only this: http://sjadapter.sourceforge.net/ but it's as old as dirt and does not seem like a reasonable starting point.

Well, there is this, which is almost as old as time, itself. That's probably as close to something as you'll find without implementing it yourself from scratch. Given how old it is, you'll probably still be implementing it from scratch, with this just serving as an example.

You could use SPARQL and run TDB with Fuseki, then access from Sesame over HTTP.

Related

Building and extending a Knowledge Graph with entity extraction while Neo4j for my database

My goal is to build an automated Knowledge Graph. I have decided to use Neo4j as my database. I am intending to load a json file from my local directory to Neo4j. The data I will be using are the yelp datasets(the json files are quite large).
I have seen some Neo4j examples with Graphaware and OpenNLP. I read that Neo4j has a good support for JAVA apps. I have also read that Neoj supports python(I am intending to use nltk). Is it advisable to use Neo4j with JAVA maven/gradle and OpenNLP? Or should I use it with py2neo with nltk.
I am really sorry that I don't have any prior experience with these tools. Any advice or recommendation will be greatly appreciated. Thank you so much!
Welcome to Stack Overflow! Unfortunately, this question is a suggestion/opinion question so isn't appropriate for this forum.
However, this is an area I have worked in so I can confidently say that Java (or Kotlin) is the best way to go for Neo. The reason being, it is the native language for Neo and there is significantly more support in terms of the community for questions and libraries available out there.
However, NLTK is much more powerful than OpenNLP. So, if your usecase is simple enough for OpenNLP, then purely Java/Kotlin is a perfect approach. Alternatively, you can utilize java as an interfacing layer for the stored graph, but use python with NLTK for language work feeding into the graph. This would, of course, dramatically increase the complexity of your project.
Ultimately, the best approach depends on your exact use-case and which trade-offs make the most sense for you.

Flutter standard packages

As I see several dart packages published at dart package website, I am curious to know what packages does flutter endorse?
The question would be vague, so I would like to focus on a specific package dio. I have contacted few flutter developers, and have been told that the package is not yet a industry standard, also I was introduced to some packages that were published just hours back, for example jaguar_retrofit. I also see dart https package used frequently in flutter documentation.
This weighs me to look at what would be the most promising in the future.
Can someone solve the package mystery for me, any flutter insights available?
This is a valid question, but not one that you'll probably find a final answer to on stackoverflow (and it may be closed as off-topic although I won't cast that vote). You might find better luck at https://softwarerecs.stackexchange.com/ although there may not be too many dart/flutter specific people there; I don't know for sure.
But realistically, no-one knows what might happen to the packages in the future other than the people maintaining them. That would probably be a good first step - make contact with the developers as they will be able to give you a better indication of how committed to maintaining their code they are.
Other than that, what I'd look for is who the publisher of the package is (see below, under the "Author").
If it is the 'Dart Team' or 'Flutter Team', there's a fairly good chance it will be maintained. If it isn't, but the uploader has a '#google.com' email address, there's a chance it's just one of their 20% projects, but there's still a better chance of it being maintained than a random dev.
And finally, if the package's licence allows for it (which pretty much everything on pub should) you may be able to help the developer with it in the future, in which case everyone wins =).
It helps to look at the official documentation:
Fetch data from the internet
JSON and serialization
More in the cookbook.
Some time ago, I took a look at the dio source code and I'm not really convinced that it is a good option. Basically it is just a thin wrapper around the standard http library.
The retrofit clone seems to rely on a custom JSON serializer code generator, instead of using one of the standard solutions.

Is Scribe sticking around for a while?

Simple question - I have dabbled with the awesome scribe library before but am now thinking of committing to this for an oauth-dependent production grails app. Is there enough community support to keep this library going with all the API changes the likes of Facebook seem to be doing these days? I'd hate to have to revert to something spring security for oauth but, in the same sentence, would not want to have to keep customising scribe for my own once API changes are released by providers.
I ask this because the core code (which is probably perfectly fine at the moment) is about 4 years old. Is this project here to stay?
With the exception of hearing from the Scribe team it's nearly impossible to answer this question with a simple yes/no.
However, I think it's better to look at it from this perspective to arrive at a valid answer.
Does it meet your needs today?
Do you have access to the source code?
Does it have an active community?
Do you have other options if you need to replace it in the future?
Should you need to, can you modify the source to meet your own needs in the future?
Given the fact you do have access to the source, and you do have other options I'd say it doesn't really matter if it's going to stick around because you have options for the future.
Of course, the answer depends on your own abilities and risk assessment, but I think it would be safe to say you can arrive at an answer.
Hope this helps.

Can anyone recommend best practices for profiling Ruby on Rails software under Passenger/nginx combination in a live server environment?

I am attempting to determine what can possibly be the causative factor for 20+ second response times from a Rails 3 application located in EC2 using Elasticache. I have reason to believe the problem is in fact cache related, but I have no numbers to prove it. I'd like to get those numbers. For the sake of completeness, we're running the applications atop Ubuntu 12.04 .
Searching Google, I found nothing directly relevant to my situation, and no StackOverflow topics I could find were even remotely relevant to my situation. If anyone can point me to some documentation on the matter, I'd be quite appreciative. Thank you!
I've found the best tool for this to be New Relic.
http://newrelic.com/
I don't work for them and get no benefit from you trying them.
They have a free level that you can start with. If you go up to the non-free version you can literally trace all your requests through different models and into the database telling you how long the app spent in each section. It's a great tool for profiling.
Do you, by any chance have access to standard web logs including URLs and response times?
I faced a similar situation, searched the web, found nothing relevant, and eventually decided to roll my own, which I shared in this SO post:
Profiling a multi-tiered, distributed, web application (server side)
While it is far from perfect and may be too high level for some use-cases, it gave me a pretty quick and broad insight into where the application I was trying to profile is spending most of its time in, and what the slowest parts are. HTH.
The best parts of it are that:
It is 100% platform and programming language independent.
It is a 100% free software solution

How do you remember/organise Rails information to prevent wheel reinvention? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I love working with Rails but I keep tripping up against my own inefficiency: I'll spend time implementing some "useful" function only to discover subsequently that it was already in the framework, had I but known it!
Particular areas of wheel reinvention for me are
helpers and built-in class extensions
recently-released features that may not yet have lodged in my brain
plugins (a taxonomy of Rails plugins, if such a thing makes sense, would be a boon)
migration options
less-frequently used rake tasks
the options hash on just about everything
Obviously (?) we can't all remember all this stuff all the time. There are "cheat sheets", but unless they're up-to-date they can potentially compound the problem by appearing authoritative when they're really targeted at older versions.
What do you do to minimize this excise? Can anything be done?
I wondered if a set of Big Visible Charts might help, although goodness knows where I'd stick them in an open-plan office.
One thing here is to know about the existence of particular feature (plugin, gem, etc) in the first place. That's why
I try to keep up to date with the information about the edge Rails.
I follow many blogs and try to if nothing else then run over the titles every day, just to have it leave at least some tiny footprint in my memory.
That's for the passive part. Now for the active:
As I fly through the new features/plugins I try to imagine at least some use case in which it might be helpful in what am I working on right now - this exercise helps me to remember the thing, since I connect it to my actual conceptual system.
In my less serious projects I really try experiment with new things.
On SO I often answer questions I'm not sure about or I don't really know anything about but they seem interesting to me - then I do some research and extend my knowledge on that particular topic.
I don't think that "big visible charts" can help in the long run. I only use cheat sheets when learning new things and it's really only a short term thing. Exellence is a habit, as Aristotle said.
This isn't just a problem with Rails, but with any framework. Programmers I know who have worked for years with Delphi still are shocked to find simple standard functions that they'd replicated.
WRT Rails, Mike Gunderloy recently wrote about highlighting text, and ended with this wise tidbit:
It’s worth taking a dip into ActionView::Helpers occasionally to see what other bits of functionality are lurking that you’ve forgotten about.
Any time I need to do something I think should be easier than it is, I do a quick check there, as well as Google, to make sure I'm not about to waste a ton of time.
I face this problem as well- and it was a lot worse when I first started with RoR. Now after over 1.5 years, I know what's available pretty well.
Basically what I do is if I am using parts of the framework I know... no big deal. If I need to do something I will likely have to create myself, I first google it or search the Rails API. Lately I have also begun searching github and some of the plugin sites like railslodge.com.
While this does not completely solve the problem, it has helped dramatically.
I surf over the rails blogs in my RSS feed reading the headlines and just enough to figure out what the article is about. This gives me a good breadth of knowledge but pretty shallow. Still it lets me know what is out there. Like yesterday when I saw a blog post about a highlight helper (I had no idea it existed. Now I do and if I ever need it I know to look for it - even without reading the post in depth). I also open the posts I want read in depth in another tab for later (I used to use ReadItLater but it got out of hand) and as i read them i write notes in a post on my own blog more for my own benefit than for others - to get into memory and to ensure I can find it later.
The other thing I do when I am entering uncharted or forgotten territory is to I ask a question here about best practices or specific details even if I think I know the answer. For example I couldn't remember the names of the popular plugins for tracking edit histories of records (acts_as_audited and acts_as_versioned). I had the answer in 15 minutes.
It turns solo programming into programming in one of those cool noisy dev shops with a foosball table and lots of other people who know stuff i don't.
I tend to assume that most types of basic problems I'm solving have already been solved by someone else; by starting with the assumption my thoughts aren't along the lines of "how do I build this" but "where do I find it" and of course google, the wikis and the plugin and gems lists all play a part in that. I have written very little code that isn't directly related to my business domain.
I write tests first. Then code. Sometimes the framework does it for me and I don't have to write code. :)
I don't think Rails is any different than other frameworks... it takes a while to know where things are. The best you can do is read the API docs and see what's there. You don't need to learn how to use it, just what is there and get an idea of how to look for it when you need it.
Also, it's not a bad thing to write code that someone else already has. You learn from it. Later you just swap in the framework mojo and see if your tests still pass. If so, you're good and you know how the internals of one part of the framework probably work.
I believe the key to eliminate the time wasted on reinventing the wheel is to have a very handful tool to search inside the Rails helpers/capabilities.
On one hand a good choice of IDE could help a lot. On the other hand - a very good online (offline) edge documentation with an ability to quick search through it. These days one of our russian Rails programmers made one: http://railsapi.com/. The search is done in a very MacOS style, making it a very good choice for a fast diggin'.

Resources