It’s probably time to switch back to the owlbuilder end as that’s the only way any more content is going to make its way in the online triple store.
So, the Sesame status queries were broken as a result of the Sesame upgrade, but the problem was not due to Sesame itself. In order for these jquery-based status buttons to work, a solution to the cross-origin resource sharing restriction is necessary. One solution to this would be simply to return everything via wrapped JSON (a protocol called JSONP). There are several places in the tools I work with in my day job where people have used the JSONP approach and I gave serious thought to going this way when I got back to implementing the sesame queries. Virtuoso, another triple-store (used by Phenoscape and several other projects) has a configuration to disable the cross-origin restriction, but I was never able to get it to work (either it wasn’t available in the version I could get to run on ubuntu, or there were other problems with my configuration – I suspect the later).
However, I’m serving triples with Sesame, hosted under Tomcat, so there turns out to be another option – a filter called CORS Filter, that can be (relatively) easily installed and configured in a tomcat (or other java servlet container) installation. If anyone knows any more about this module, please do leave a comment, otherwise I’m using it because it works. If it phones home or something nefarious, all it’s sharing is a bunch of annotations of spider behavior, so I’m not worried about that.
In any case, the installation involves adding some elements to the target service’s web.xml file. Since the target service is sesame-rdf, not spider-behavior (the top level web package), I had to go in and modify the web.xml file after uploading the .war file into tomcat. Adding the two required elements and restarting tomcat resolved the problem (try it).
Updated Sesame to 2.7.3 this morning. The update went fine, and there are some improvements to the rdf-workbench page (sparql queries are no longer giving authorization errors). The new workbench seems to support user authentication, which is good, but will require some more configuration work. Sadly, the jquery callbacks on the arachb test page have stopped working. Will have to debug later.
I’ve been quiet here for the past two weeks, primarily because I wanted to write my AAS report (over at ontological ethologist). Otherwise, most of my effort has been catchup at my day job and getting publications into arachadmin (all 560 entries on the old spreadsheet are now in the database though I haven’t pushed them to the triple store yet). I did pick 6 or 7 reprints and a couple of 1980 vintage conference volumes (which should be good for a couple of entries each). Didn’t spend much time talking up Arachnolingua, though I did say I was working on ‘a spider behavior database.’
There is also activity coming up on the behavior ontologies front, especially next week at the Animal Behavior meetings in Boulder.
The last couple of days I have devoted what little time I’ve had for arachnolingua to curation – moving stuff out of the spreadsheet into the database, grabbing a couple of interesting papers about several species of fly that avoid jumping spider predation by mimicking the spiders’ territorial display and no coding what so ever. That changed this evening, though it was more configuration than coding.
A couple of months back, I worked through most of the examples in maven by example, which included a couple of web application projects. In the process of working through them, I realized that, even if I didn’t actually use JSP or any Java support, it would still be simpler to put all the pages into a *.war file which the tomcat manager app would handle the deployment of. This would save me moving lots of files or archives to the server and worrying about things getting out of synch. This evening I updated the Spider-Behavior project to use maven as a build tool, did a little bit of testing using a local jetty server, then pushed a war file to the server. It worked well enough that I copied most of the other files and then worked on configuring apache, which had been serving the static file for arachnolingua all along, to proxy to the tomcat server (as I had planned ever since I chose tomcat to deploy the sesame server). It took over an hour to remember how to configure apache to do the proxies, but that seems to be sufficient for the present. Another hour of iterative tweaking and I was able to completely hide tomcat behind the firewall (and not specify the tomcat port in the ajax call backs on the sesame testing page). This should stop the extended sessions, originating from Chinese ip addresses, of attempts to break into the tomcat management tool (it’s simple enough not to use manager, admin, or tomcat as the name for your privileged tomcat account anyway).
So progress in both build automation (= repeatability) and security. All in all, a productive evening.