Semantic Turkey Frequently Asked Questions
Building
Q. I see I need to use Maven to build Semantic Turkey. I don't know how to use it and, frankly, I don't want to learn a new technology, I just want to use <replace_here_with_your_favourite_IDE>. May I skip this step?
Yes, in theory you can. You can just check all the dependencies written in the pom.xml file of each project, search them on the web, download them (make a prayer hoping you downloaded the exact version of everything, all the required dependencies etc..), then import them in <replace_here_with_your_favourite_IDE>, inside the project that you just created to hold the sources, then import the sources etc...
...though..let us be a bit evangelists...Maven may be a big beast if you start to love it, you get addicted to it, and start thinking things like "I want to prepare a beer with it" (we are sure there is a Maven plugin even for that...), but, if you are an end user of Maven and just need it to build a project, the time you need to download and install it, is so short you will get immediately paid back for the time you would need to build this single project in the traditional way. See the build instructions to see how quick is to build Semantic Turkey (and most other projects you will find out there) with Maven.
Last but not the least, Maven is today a de facto standard for releasing source code.
...and..oh, yes, almost probably there is a Maven plugin for <replace_here_with_your_favourite_IDE> !
Running the System
Q. I installed ST, I ran the batch, no error msg is shown, but nothing further is written, and the server seems not to be listening on its port.
Semantic Turkey, on its first run, creates (unless it finds it already there) a new "SemanticTurkeyData" folder in the same directory where it is being installed. So, you should check if this directory is not write-protected.
E.g., in Windows, usually the root of the C: unit is write-protected, so having the following installation:
C:\semanticturkey-<ver>
is not recommended, as it will (try to) create the SemanticTurkeyData directory directly on C:, thus failing.
Q. Can I start the system as a service?
The system administration manual has a dedicated section for this.
General
Q. Can Semantic Turkey connect to other triplestores than RDF4J or GraphDB?
A question coming to many curious users willing to use ST with other technologies is: why not other triple stores? and if yes, which ones? why not many others have been explored? why not a more agnostic access to different technologies?
The answer "passes" through the years of experience with the (more than decennial) beta versions of Semantic Turkey (before 1.0).
Semantic Turkey was initially based on another project of the ART group, the OWLART api, a thin middleware over different RDF frameworks. This layer did not implement any storage facility and delegated to the underlying implementations (i.e. wrapper for notable frameworks such as Jena and Sesame, the precursor to RDF4J) most of the business logic. The first versions of Semantic Turkey, developed before SPARQL was a recommendation, were based on use of graph API, thus making it easier to switch among different technologies, providing that the semantics of basic operations such as addTriple(), deleteTriple(), listStatements() etc.. were consistent among them. When differences arose, we developed the wrappers so that these could conform to the semantics we provided in our API. The experience has been effort-demanding, and in the end it resulted in:
- drifting us away too often from our objective, which is ST and not an RDF API
- losing much of the new interesting stuff coming from each of the single wrapped technologies, as we had to conform to the common denominator of all of them
- progressively managing to keep in track only few of the wrapped technologies, until we ended up with Sesame alone, some always-slightly-outdated Jena stuff, and none of the others
It was then with much relief that, from version 1.0, we decided to abandon the OWLART project and move to RDF4J as the native, stable solution for RDF management within ST. We can finally focus on ST's features alone, standing on top of a mature library such as RDF4J and directly benefiting from all of its improvements by simply upgrading to its new versions.
A set of facilities has been developed over RDF4J repository connection and query classes in order to simplify the development of services specifically for ST, requiring SPARQL for exploiting them at their best.
So, Semantic Turkey allows - in theory - for connections to any triple store accessible through a RDF4J remote connection and triple storescompliant with the Sail stack framework (such as GraphDB) are to be preferred. Various triplestores may have further requirements.
A complete description of the requirements for connectable triplestores is provided here.
Bug and Issues
Q. When reconnecting to ST, I cannot see the effects of the last changes I brought to my dataset
If your project uses a local repository backed by NativeStore, then most probably this is due to a bug in RDF4J for which NativeStore repositories might not be properly persisted if the server is closed abruptely, without closing the project holding the repository first.
As we suggest in the installation instructions, it is better for your stable projects to adopt a separate triple store, as described in the system administrator manual.
In any case, projects with local repositories using in-memory store are not affected by this issue.